Open Reader

Reverse engineering a Viking VOIP phone protocol with Claude Code — Boris Starkov, Eleven Labs

completed 20:11 May 29, 2026 Watch on YouTube

Current Status

completed

Video ID

V-L0INGTEOg

RAG / Chat

Enabled
Reverse engineering a Viking VOIP phone protocol with Claude Code — Boris Starkov, Eleven Labs
Description

A Viking VoIP phone sat in the ElevenLabs San Francisco office for a year. Three senior engineers and ChatGPT could not get it working. Boris from ElevenLabs cracked the undocumented protocol with Claude Code in a couple of days: brute forced all 676 possible two letter command combinations, found 80 valid ones, then set up a TCP proxy between a Windows virtual machine and the phone to intercept and log what the proprietary Windows XP software was actually sending. The last piece was a one byte checksum in the persistence command. Claude reverse engineered the formula by running known input output pairs through it, confirmed the pattern in a closed loop, and derived a simple subtraction. Boris describes his own role as being the hands: Claude orchestrated, he physically rebooted the phone and reported how many beeps he heard. The protocol is now open sourced as a Claude Code skill so anyone with a Viking phone can configure it directly without the Windows software. The outcome at AI Engineer Europe: a red phone booth on the third floor where picking up the receiver connects you to a Michael Caine voice agent that quizzes you on British AI history.

Summary

Generated by claude-sonnet-4-5

30-second take

An ElevenLabs engineer used Claude Code to reverse-engineer a legacy Viking VoIP phone (Windows XP-era hardware) that had stumped three senior engineers for a year. The actual approach: brute-forcing two-letter command codes via network sniffing, setting up a man-in-the-middle TCP proxy through a Windows VM to intercept proprietary protocol traffic, then cracking a single-byte checksum to enable persistent memory writes—all orchestrated by Claude giving step-by-step instructions while Boris acted as "the hands." The payoff: a working phone booth demo at an AI summit that connects callers to a Michael Caine voice agent, plus an open-sourced skill for programming Viking phones without Windows software. This is a rare example of AI-assisted hardware hacking, not just software development.

Key takes

  • Claude orchestrated hardware reverse-engineering end-to-end. Boris described himself as "the agent for Claude"—following instructions like counting phone beeps, rebooting hardware, controlling the VM—while Claude handled intellectual work (port scanning, brute-forcing commands, checksum cracking). He explicitly says he couldn't have unblocked Claude intellectually because "it was smarter than me" on protocol analysis.
  • Brute-force enumeration unlocked the protocol. Claude discovered the phone used two-letter command codes by sending random strings and observing "er" error responses, then iterated through all letter combinations to find 80 valid commands. This simple exhaustive approach worked because the protocol was undocumented and not Google-able.
  • Man-in-the-middle attack via Windows VM solved persistence. The phone accepted settings to temporary memory but wiped them on reboot. Claude set up a TCP proxy on macOS to relay/log traffic between the phone and its Windows XP software (run in a VM without internet), revealing a "ts" command with a binary payload and single-byte checksum that enabled writing to persistent 256-byte memory.
  • Cost was trivial: $10-100 in tokens. The entire multi-day reverse-engineering effort used ElevenLabs corporate tokens in that range, making this absurdly cheap compared to hiring security/hardware engineers.
  • The skill is now open-sourced and generalizable. Boris released the Viking phone protocol as a reusable Claude skill, eliminating the need for proprietary Windows software. He argues this approach extends to other legacy hardware—you can now control devices "the same way you connect to any piece of hardware in your house" without vendor-provided interfaces.

Useful details

  • Hardware: Viking legacy VoIP phone, Power-over-Ethernet (PoE) connection, networked via router to MacBook.
  • Stack: Claude Code, nmap for port discovery, TCP proxy on Mac, Windows XP VM (UTM), ElevenLabs conversational AI agent, Twilio SIP trunk.
  • Protocol specifics: Two-letter ASCII command codes, "ts" command with binary payload for persistent writes, single-byte checksum (simple additive encryption), 256 bytes of persistent memory.
  • Timeline: Phone sat unused for a year after three senior engineers + ChatGPT failed to crack it. Boris + Claude solved it in "a couple of days."
  • Demo setup: Red phone booth on third floor of AI Summit. Callers speak to Michael Caine voice agent, answer five British AI history questions, win ElevenLabs swag if they get ≥1 correct.
  • Presentation meta: Slides fully generated by Claude Code from the project conversation as context.

Caveats / counterpoints

  • Lucky encryption: Boris admits "we were lucky" the checksum was only a single byte. A harder encryption scheme would have been "much harder to break," possibly blocking the entire approach.
  • Manual intervention required: Claude couldn't fully close the loop—Boris had to physically reboot the phone, count beeps, control the VM. Computer Use could theoretically automate this but wasn't implemented.
  • Niche applicability: The open-sourced skill is Viking phone-specific. While Boris claims generalizability to "other hardware," he gives no concrete examples or evidence that the method works beyond this one legacy device.
  • No security engineering depth: Boris self-identifies as "just a normal software engineer" unfamiliar with security concepts (didn't know what "0x" was). This suggests Claude abstracted away complexity rather than teaching reversing skills—unclear if this is repeatable for more sophisticated protocols.
  • Token cost ambiguity: $10-100 range is wide and vague; no breakdown of token usage by task (enumeration vs. checksum cracking vs. VM setup).

Ken relevance

High for AI ops/tooling narratives, medium for practical application:

  • Agentic workflow case study: This is a clean example of human-in-the-loop AI orchestration where the human provides physical actions (rebooting, listening, moving cables) and the AI handles reasoning/iteration. Useful for pitching agent systems that "make expert work accessible to non-experts."
  • Hardware hacking as content angle: The "AI reverse-engineers legacy hardware" narrative is underexploited in AI content. Could be repurposed for videos/posts about Claude Code capabilities, especially for devtools or hardware audiences.
  • Skill/toolkit pattern: Open-sourcing the Viking phone skill as a reusable Claude artifact is a model for building agent "skill libraries" that accumulate domain knowledge. Relevant if you're exploring agent memory/tool ecosystems.
  • Cost vs. human expert comparison: $10-100 in tokens to solve what stumped three senior engineers for a year is a strong ROI story for AI tooling GTM.
  • Limited direct use: Unless you're building hardware integrations or legacy system adapters, the Viking phone protocol itself has zero utility. The method (brute-force + MITM + checksum cracking) is transferable but requires case-by-case validation.

Watch verdict

Skim. The transcript is sufficient—the demo is impressive but the technical details are fully captured in the text. Watch only if you want to see Boris's stage presence or the phone booth visual, but the intellectual content is here.

Transcript

2726 words en Processed in 244.3s

[SPEAKER_00] Hi everyone. Thank you for coming. Even though there is lunch being served now, I really appreciate you coming here. I'm Boris. I work for Elevent Labs. Usually we do agents, voice agents, all things voice. But for this chat, I just wanted to show you something else. You might have seen, if you've been on the third floor, you might have seen this phone booth. This is Swix, by the way, the organizer. They've built it as a demo for the summit. There is this phone inside. I don't know how many of you have gone through it. Did anyone? You should totally give it a try. Oh my God. Okay. But the idea is that when you pick it up, you actually end up talking to an AI agent with the Michael Caine's voice, approved legal, who then walks you through five questions about British AI history. And then if you answer at least one of them, you can get a swag from Elevent Labs. So that's the idea. But today I want to show you how I actually build it. So this is how it looks like now. And this is how it looked like last week. This is the old. I mean, it's not that old. It still has a controller inside. But it's a quite old piece of hardware, this phone. And the main problem when we tried to make this happen, the main problem with this piece of hardware was that it only had Windows XP compatible software. So it was very hard to set it up because it turned out that nobody at Elevent Labs has a Windows laptop. We all had Macs. But also when we tried to set up a virtual environment, we also had some driver issues. So what happened to this phone? Our team in San Francisco purchased it one year ago for some other event. And three senior software engineers and ChatGPT at the time, they couldn't figure out how to make it work. So for one year, it was just laying there, waiting to be rescued. And for this project, we asked them to send it to London. And then I tried to crack it, hack it, reverse engineer it using cloud code. And this is what I wanted to talk about, how to use cloud code not just to build applications, but how to actually reverse engineer some hardware. So by the way, these slides are fully made by cloud code as well. So the way I made them is I put the whole conversation we had about this process as context, and then asked it to make slides based on that. So the goal here, what we want to achieve is, we have this Viking phone, the retro legacy Viking phone. And we want to connect it to a conversational AI agent by 11labs. It can only make a phone call to a phone number. So we need to put Twilio in between, just to handle that domain complexity. So it goes Viking phone, then Twilio, then 11labs. And yeah, the problem, I have a mug. So we couldn't really easily set it up. So what we ended up doing, what I ended up doing instead, I connected my laptop to the phone by a router and started exploring. I mean, by saying I started exploring, Cloud Code started exploring it. So first, it unmapped all of the ports that were available. So port 1001, which turned out to be the wrong one. It was just an electronics tunnel. Then it proceeded to iterate, and the next one was the actual target port that could be used to communicate with the phone. So step one, Cloud Code found the way to communicate with the phone. Then it started discovering it. So it sent some random sequence, not random, but just random sequence to the phone, and the phone responded. So that's how Cloud Code realized that this is an actual interface, a protocol. But the protocol is not Google-able. There is no open documentation on what the exact protocol is. So it had to then reverse engineer it, right? So first thing Cloud noticed is that when you send a random string to the phone, it returns "er" and then the string itself, meaning likely it's an error, an error that this string is not a correct command for the phone. So next, Cloud figured out that this phone operates using two-letter command codes. Some of them are non-existent, then it returns an error, like on this slide. Other, however, they return something else. The next idea was that actually if it's two-letter commands, then we can just iterate through all of them, right? Brute-forcing. So it wrote this program and literally tried out every single combination of two letters. And it turned out that most of them returned error codes, but 80 of them returned actual something else, meaning they're actual valid commands. Those were some of them. By the way, I'm not sure. I'm not sure what this is, but yeah. [SPEAKER_01] Then some of the commands, they made sense based on the name. Maybe not those ones, but for example, "sa" for status makes sense. I don't know if it makes sense. Yeah. Then it proceeded to try to set up the actual credentials on the phone. So this is the phone memory. And basically what they're trying to do here is to put the right credentials to the phone memory, so that it knows where to call. We want to call Twilio or SeedTrunk, right? And it turned out that yes, these commands, they worked, and all of the settings got accepted. But the problem is, the moment the phone got rebooted, they all were gone. So they were not saved in the memory. They were just written to the temporary memory. And then me and Cloud Code started a multi-hour operation of trying to figure out how to actually save what you put to this temporary memory, how to make it actually persistent, how to save it to the long-term memory of the phone. It tried everything. so that it knows where to call. We want to call Twilio or SeedTrunk, right? And it turned out that yes, these comments worked, and all of the settings got accepted. But the problem is, the moment the phone got rebooted, they all were gone. So they were not saved in the memory. They were just written to the temporary memory. And then me and Cloud Code started a multi-hour operation of trying to figure out how to actually save what you put to this temporary memory, how to make it actually persistent, how to save it to the long-term memory of the phone. It tried everything. It tried different commands. I don't know if the slides are going to show this, but it tried three-letter comments. It iterated over all three-letter comments, over all reasonable words, and it didn't find anything. So this was the dead-end situation. This was around the place where our team in San Francisco, when we just started exploring it the first time, they couldn't figure out what to do next. But that was one year ago, and there was only ChatGPT. Now with Cloud, Cloud didn't give up at this point. Cloud suggested that there is a—yeah, Cloud figured out the problem, and then it suggested a solution. So the solution at this step was to set up a Windows virtual machine. However, the main problem with Windows virtual machine is that you can't bridge Wi-Fi to Mac OS, so there is no internet connection in the Windows virtual machine. So what Cloud did next was actually a very smart thing. It set up a TCP proxy on the Mac so that the traffic from the virtual machine—oh, why are we setting up virtual machine? [SPEAKER_00] Because in the virtual, in the Windows virtual machine, we can set, we can run the software of this phone that actually knows how to communicate with it. So the solution, so what we are trying to do now, we are trying to put a man in the middle attack, to intercept the traffic between the software and the phone, to analyze it, and to figure out how it communicates, how it works. So the software is running in Windows virtual machine now. Then it's directed, it communicates to the proxy on my Mac. The proxy is relaying it to the Viking phone, but also it logs everything so that to figure out what they're talking about and what the protocol is, what are the missing pieces. Very simple code. And then, yeah, then it started capturing the communication. And it figured out that there was this comment that Cloud didn't understand before, which is ts, which had some weird binary payload. And then that had this format. And what you can see here is most of the params of this comment kind of make sense, except for the checksum. But checksum turned out to be only one byte. So it's something that you can brute force as well. So, hi. Yeah. Sure. So the way it works, it doesn't know the checksum, but it knows which data is being sent, and it knows the result. So it can easily reverse engineer the encryption protocol, which turned out to be just adding a simple one byte value to the checksum. Not just Cloud Code, I want to highlight it. Cloud Code didn't just figure out what the format of the checksum is. It actually managed to find it, and then it confirmed it by running more values through it. So it was a closed loop iteration. And at this point, the phone was pretty much cracked. So now we managed to figure out how the software communicated to the phone. And we had the list of comments and we—what was that? Yeah. And then we figured out how to actually solve the problem I stated in the beginning, how to actually save what you put to the memory. We need to run this sequence of comments. And the fun bit was that actually there is this 256 bytes of memory in the phone, which also happens to crack. And then the last bit of this process was that actually I didn't want to run a Windows virtual machine every time. So the last bit was actually, now when I know the protocol, I know how to talk to the phone. I can just factor reset it. And now I can use this skill, this information to program it directly without having to run the virtual machine at all. So what I did, I put all of this as a skill and open sourced it. So that now, if any of you by any chance have a Viking phone, you don't have to set up Windows machine. You can just ask Cloud Code, give this skill to Cloud Code and it will set it up. Yeah, victory. It works. I mean, I didn't go into much details about how this step works because it's super easy. Thanks to 11 laughs. We really made it in video. I mean, this step is super easy. This one was the most painful part. I think it took me a couple of days to reverse engineer it. Yeah, so what we learned about the protocol, it has two layers. The encryption, we were lucky that the encryption was just a single byte checksum because if it was something harder, then it would probably be much harder to break. Yeah, and the persistence bit, we had to work around the server, intermediate server, between virtual Windows machine and the phone. And that's how—yeah, to comment on step five here, without Cloud Code, it wouldn't be possible to do that demo. It's not just that it made it ten times faster. It just made it possible because I'm not a security engineer whatsoever. I'm actually just a normal software engineer. And when I looked at all these programs, I was, what is that? What is that? What is zero X? Okay. Yeah, that's it. So now the outcome of this is not just a nice demo that you can see on the third floor. It wouldn't be possible to do that demo. [SPEAKER_00] It's not just that it made it 10 times faster. It made it possible because I'm not a security engineer whatsoever. I'm actually just a normal software engineer. And when I looked at all these programs, I was like, what is that? What is zero X? Okay. Yeah, that's it. So now, the outcome of this is not just a nice demo that you can see on the third floor. It's also a skill that makes it much easier to program this kind of phone. And the nice part is that I think this is extendable to other hardware as well. So it's not just Viking specific, but if you want to control some other hardware, I would really recommend thinking about it. The difference is that one year ago, you actually needed the proprietary software interface that the company that made the hardware provides. Now you don't need it. You can connect to the phone the same way you can connect to any piece of hardware in your house. So this is cool. Yeah, this is how it started. And the actual demo again, for people who just came here on the third floor, we have this red telephone booth that lets you speak to Michael Caine. How many of you have tried it? Has anyone tried it? Oh my God. Okay. You should totally try it. It feels magical. And I just told you how I made it into real life. Yeah. Any questions? This is the booth and this is six. Do you know how many tokens you burn? I used the 11 loves, our corporate tokens. Yeah, I think it was an order of between 10 and a hundred dollars. [SPEAKER_03] So quite reasonable. And did you have Claude? So you had some software that you installed on UTM on Windows. Yeah. [SPEAKER_03] Did you have Claude control that as well? [SPEAKER_03] Or did somebody have to manually? [SPEAKER_03] It was quite an interesting process because my participation in that was basically following Claude's commands. [SPEAKER_03] Right. So it would tell me like, Hey, can you take the handle and how many beeps can you hear? And I would listen and I'm like, okay, I think three. It was like, you idiot. It's either two or four. And I'm like, oh yeah, it's two. So it was like I was actually the agent for Claude. Claude was orchestrating the whole thing and answering your questions. Basically I was the hands for Claude. It couldn't really. I think if I used computer use or something, I could make it fully close the loop and make it control the virtual machine. But I was too lazy. So I just did what it told me to do. Were there any places where Claude got stuck and you had to help? What was it? [SPEAKER_01] What was it? [SPEAKER_01] What was it? [SPEAKER_01] Stuck in what sense? As in, it couldn't figure out the next step? [SPEAKER_01] So that's the thing. It was orchestrating it. [SPEAKER_01] Like I had no idea what was going on. So intellectually I couldn't unblock it. Oh, so you just unblocked it? I unblocked it by actually rebooting, physically rebooting the phone or controlling the virtual machine. But the intellectual part, which is cracking the algorithm, I couldn't unblock it. I mean, it was just smarter than me, I think. Yeah. How did you physically connect to the phone? Yeah, I wish I had a picture. So this phone, you can see the black cable. [SPEAKER_02] It's called power over ethernet, POE. Yeah. Which is basically there is an ethernet cable, the one that everyone probably has at home for home internet. And there is also a power adapter and it brings them together. And I put a router in between, which let me connect my laptop. So this was connected to the router. And my laptop was connected to the wifi router as well. Okay. And then yeah, and then there was this step of searching the network. So this was the first step. Claude just checked all of the devices connected to the router and found the phone. Okay. Yeah. Cool time. [SPEAKER_01] Yeah. Next session coming in. Thanks. [SPEAKER_00] Thanks everyone. Great. Yeah. Thank you. [SPEAKER_00] Thank you. Thank you. Thank you. following Claude's commands. Right. So it would tell me like, Hey, can you, can you like take the handle and how many beeps can you hear? And I would like listen, I'm like, okay, I think three. It was like, you idiot. It's either two or four. And I'm like, Oh yeah, it's two. So it was like, I was actually like the agent for Claude. Like Claude was orchestrating the whole thing and answering your, no answering your, basically I was the hands for Claude. It couldn't really, I think if I use like computer use or something, I could make it fully like close the, close the loop and make it control the virtual machine. But I was too lazy. So I just did what it told me to do. Were there any places where Claude got stuck and you had to help? What was it? What was it? What was it? What was it? Stuck in, in what sense? As in, it couldn't figure out the next step. So that's the thing. It, it was orchestrating it. Like I had no idea what was going on. So intellectually I couldn't unblock it. Oh, so you just unblocked it? I unblocked it by like, actually like rebooting, like physically rebooting the phone or like, controlling the virtual machine. But the intellectual part, which is like cracking the, cracking the algorithm, I couldn't, I wouldn't be able to unblock it. I mean, it was just smarter than me, I think. Yeah. Um, how did you physically connect to the phone? Yeah, I, I wish I had a picture. Um, so this phone, you can see the black cable. It's called power over ethernet, P-O-E. Yeah. Which is, basically there is an ethernet cable, the one that everyone probably has at home, for home internet. And there is also a power adapter and it brings them together. And I put a router in between, which let me connect my, so this was connected to the router. And my laptop was connected to the wifi router as well. Okay. And then, yeah, and then there was this step of, uh, searching the network. So this was the first step. Claude just checked all of the devices connected to the router and found the, the phone. Okay. Yeah. Cool time. Yeah. Next session coming in. Thanks. Thanks everyone. Great. Um, yeah. Thank you. Thank you. Thank you. Thank you.