Reverse Engineering a Viking VOIP Phone with Claude Code

In a demonstration of the power of AI in reverse engineering, Boris Starkov, from Eleven Labs, detailed his process of reverse-engineering the protocol of a Viking VOIP phone. The presentation, titled "Reverse engineering a Viking VOIP phone protocol with Claude Code," showcased how AI, specifically Claude Code, can be instrumental in dissecting and understanding complex or undocumented communication protocols.

StartupHub data

Companies working on this

Profiles of the companies named in this story, with funding and a one-liner from our database.

Twilio

$130M

Cloud communications platform providing APIs for voice, messaging, email, and video engagement.

The Challenge: A Phone with No Interface

Starkov began by introducing the Viking K-1900D-IP, an industrial hotline phone with a distinct lack of user-friendly interfaces. The phone features no screen, no buttons, and relies on Windows-only proprietary software for configuration. This presented a significant hurdle, especially for users who might not have access to a Windows environment, like Starkov, who uses a Mac.

The Problem: The Missing Link

The core issue was that the phone's configuration software was essential for setting up its network and SIP credentials, but it was inaccessible on Starkov's preferred operating system. Furthermore, the protocol itself was undocumented, leaving a crucial gap in understanding how to communicate with the device directly.

The Goal: AI-Powered Protocol Analysis

The ultimate objective was to establish a communication channel between the Viking phone and an AI agent, specifically an ElevenLabs conversational AI agent, facilitated by Twilio for SIP domain and routing. This meant deciphering the phone's protocol to allow for direct interaction and configuration, bypassing the need for the proprietary software.

The Process: Discovery and Brute Force

Starkov's approach involved several stages. First, he used Nmap to scan the phone's network ports, identifying open ports and services. He discovered that port 10001 accepted connections but reset HTTP requests, suggesting a custom protocol. By sending a simple "Hello?" string to port 10001, he received a response indicating "ER [VIKING]", which identified the device and hinted at a proprietary protocol that wasn't immediately obvious from documentation.

To understand this protocol, Starkov employed a brute-force strategy, iterating through all possible two-letter command combinations from 'AA' to 'ZZ'. This involved writing a Python script to send these commands and analyze the responses. Out of 676 combinations, he found over 80 valid registers, mapping various functionalities like SIP server details, phone numbers, and firmware information.

Unlocking the Protocol: The Text and Flash Layers

Through this process, Starkov identified that the phone's protocol had two distinct layers: a text-based protocol that interacted with RAM, and a binary protocol that communicated with flash memory. The challenge was bridging these two layers, as the text protocol alone did not offer persistence or direct access to the flash memory.

The breakthrough came when he realized that some of the control commands identified earlier, such as 'CE', 'GB', 'ME', and 'MR', were part of a save sequence. These commands, when used in conjunction with binary flash writes, allowed for persistent storage of configuration settings.

The Solution: A Man-in-the-Middle Attack

To effectively capture and analyze the traffic between the proprietary Windows software and the phone, Starkov set up a Windows virtual machine in UTM on his macOS. However, bridging Wi-Fi to the VM proved problematic, preventing direct communication. The solution was to use a TCP proxy on his Mac, which allowed him to intercept and log the traffic between the VM and the phone.

This MITM capture revealed that the Viking software wrote SIP server details like "sip.example.com" to the phone using 'TS A' commands with binary payloads, one byte at a time. He further deciphered the protocol, discovering that the checksum was a simple subtraction operation, making the data effectively plaintext once the checksum was accounted for.

The Ultimate Victory: Reprogramming from Mac

By understanding the protocol and the save sequence, Starkov was able to replicate the process from his Mac. He wrote a script to flash the SIP server settings and commit the changes, which included a factory reset and then reprogramming from his Mac. This process allowed him to configure the phone without needing the original Windows software.

What We Learned

Starkov summarized the key takeaways from his endeavor:

• The protocol has two layers: text (RAM) and binary (flash).
• The "encryption" was a simple single-byte checksum.
• Persistence was the real puzzle, not direct access.
• A MITM capture was crucial to unlocking the entire process.
• AI, specifically Claude Code, accelerated the reverse engineering process significantly.

The entire process, from initial discovery to a working solution, was packaged into a Claude Code skill, demonstrating how AI can be a powerful tool for developers and security researchers tackling complex reverse engineering challenges.