AI Engineer Europe 2026
Reverse engineering a Viking VoIP phone protocol with Claude Code — Boris Starkov, ElevenLabs
Read the talk
Reverse engineering a Viking VoIP phone with Claude Code
A phone-booth voice agent depended on configuring a legacy handset from a Mac. Port probing found the commands; capturing the vendor software’s traffic revealed how to make settings survive a reboot.
From a talk by Boris Starkov
Before you start: Basic familiarity with TCP connections, virtual machines and temporary versus persistent memory will help; no telephony or reverse-engineering background is required.
Pick up the phone and talk to an agent
Pick up the red telephone in the summit’s third-floor booth and an AI agent answers in Michael Caine’s voice. Boris Starkov, who works on voice agents at ElevenLabs, describes the voice as approved for the demo. The agent asks five questions about British AI history; answering at least one correctly earns ElevenLabs swag. The booth, introduced with a photograph of organizer swyx, is the visitor-facing result. Getting the phone configured was the harder project.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A Windows configuration tool meets a Mac-only team
Under the retro exterior, the phone has an electronic controller. Its configuration software was compatible with Windows XP, while the ElevenLabs team had Macs. An attempt to use a virtual environment also encountered driver problems. The obstacle was access to the device’s configuration interface, before any voice-agent integration could begin.
The San Francisco team had bought the phone for an event a year earlier. Starkov reports that three senior software engineers working with ChatGPT could not get it configured, leaving it unused until the London project. After the phone arrived in London, he tried Claude Code as a partner for reverse engineering the hardware.
The project conversation also became the source for the presentation: Starkov supplied it to Claude Code and asked it to generate the slides. The walkthrough follows that investigation from finding an interface to replacing the vendor’s configuration workflow.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Find a configuration interface
The intended call path was Viking phone → Twilio → ElevenLabs agent. Starkov describes the handset as placing a call to a phone number, with Twilio handling the SIP-domain complexity between the phone and the agent. That was the booth’s chosen architecture, not a requirement for every ElevenLabs telephony integration.
To configure the handset from his Mac, Starkov connected the laptop and phone through a router. Claude Code began exploring the exposed network services with Nmap. Port 1001 was an early false lead: it turned out to be an electronics tunnel. Further probing found a port that could actually communicate with the phone.
Sending a probe string produced a response. That established a useful starting point: the device had a reachable interface whose behavior could be tested. Starkov could not find publicly searchable documentation for its protocol, so the next step was to infer the command structure from those responses.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Use error responses to enumerate commands
An invalid string came back prefixed with ER, followed by the submitted string. That gave the investigation a recognizable rejection response. Further experiments suggested that the phone accepted two-letter command codes: some pairs returned the familiar error, while others returned something different.
Once the command width was known, guessing could become enumeration. Claude Code generated a program that tried every two-letter combination and separated ordinary errors from interesting responses. The core of that search can be expressed in Python without assuming the phone’s packet framing:
python
from itertools import product
def command_candidates(alphabet: str):
for letters in product(alphabet, repeat=2):
yield "".join(letters).encode("ascii")
def classify_response(response: bytes) -> str:
if not response:
return "no response"
if response.startswith(b"ER"):
return "rejected"
return "inspect"
The alphabet determines the candidate set. A non-error reply earns inspection; it does not, by itself, explain what a command does. Starkov reports that eight two-letter combinations returned non-error responses, which the investigation treated as valid commands.
Command names offered clues, but not complete semantics. Starkov tentatively associates SA with status. With a set of responsive commands in hand, the investigation moved from discovery to writing the credentials the phone would need to place a call.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Accepted settings are not necessarily saved settings
The configuration commands appeared to work. The phone accepted the settings intended to connect it to the Twilio SIP trunk. Then a reboot erased them: the writes had changed temporary memory without making the configuration persistent. A successful write response was not the success condition; surviving a reboot was.
| Test | Observed result | What it established |
|---|---|---|
| Write the settings | Accepted | The configuration could be changed temporarily |
| Reboot the phone | Settings disappeared | Persistence was still missing |
| Search additional commands | No solution found | More command guessing did not reveal the save operation |
The search for persistence took hours and expanded to three-letter combinations and plausible words. None supplied the missing behavior. Starkov identifies this as roughly the point where the earlier San Francisco effort had stopped.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Capture a working implementation
The next move changed the source of evidence. Claude proposed running the vendor’s configuration software in a Windows virtual machine. Starkov encountered a Wi-Fi bridging and connectivity obstacle in his particular macOS setup, so Claude introduced a TCP proxy on the Mac. The proxy would provide a route to the phone and a place to observe the conversation.
The vendor application already knew how to configure the device. Instead of guessing more commands, the investigation could watch that application perform the operation:
- Run the phone’s configuration software inside the Windows VM.
- Direct its connection to the TCP proxy on the Mac.
- Relay the traffic from the proxy to the Viking phone and return the replies.
- Log the bytes in both directions to identify the missing protocol behavior.
This made the proxy both a connectivity workaround and an observation point. The Windows application still performed the known workflow; the capture exposed what it sent over the network.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Infer the binary payload, then test the inference
The capture revealed a TS command carrying a binary payload that Claude had not previously understood. Most of its parameters became interpretable, but the checksum remained unexplained. The checksum occupied one byte, making a bounded search practical. Captured traffic supplied the transmitted data and the corresponding observed result, constraining the possible calculation.
Starkov describes the arithmetic in terms of a simple subtraction or addition involving a one-byte value. Although he also calls it encryption, the mechanism described here is a checksum calculation, not evidence of defeating a cryptographic protection scheme. The important experimental step came after proposing the calculation: Claude ran additional values through it to confirm the inferred behavior. The hypothesis was checked against more observations, rather than accepted because it fit one capture. At that point, Starkov considered the protocol substantially understood.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Turn the recovered protocol into repeatable setup
Understanding the vendor application’s traffic supplied more than a command list. It revealed the sequence needed to make the configuration persistent—the operation that ordinary setting writes had failed to accomplish. Starkov also reports decoding a 256-byte memory area in the phone. Together, the command behavior, persistence sequence and memory information provided a basis for programming the device directly.
The next goal was to stop launching Windows for every configuration change. With the protocol understood, Starkov could factory-reset the phone and configure it directly. He packaged the recovered knowledge as an open-source Claude Code skill, so a subsequent setup could use that knowledge without repeating the VM-based discovery process.
The resulting phone connected through Twilio to ElevenLabs. Starkov describes that final integration as straightforward, though the walkthrough concentrates on the handset rather than the telephony implementation. Starkov estimates that reverse engineering the phone took a couple of days.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
From an inaccessible interface to a reusable skill
The recovered protocol had two layers: the text commands encountered through probing and the binary behavior exposed by capture. Starkov credits the simple one-byte checksum as a favorable condition; a harder protection scheme would have made the investigation much more difficult. The intermediate server between the Windows VM and phone was the decisive tool for understanding persistence.
The final slide describes AI as making reverse engineering ten times faster, but Starkov’s spoken explanation makes a different claim: for him, it made this demo possible. He was a software engineer without a security-engineering background, unfamiliar even with the 0x notation he encountered. There is no measured speedup comparison here; the result is a project he says he could not otherwise have completed.
The lasting output was therefore both a working booth and a reusable configuration skill. Starkov proposes applying the same approach to other hardware whose vendor interface is inconvenient or inaccessible. In this case, the vendor software remained essential during discovery; the recovered protocol removed that dependency from subsequent configuration. The generalizable move is to turn observed device behavior into knowledge that can be reused.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The human supplied the hands—and the physical connection
The audience first asks how many tokens the project consumed. Starkov gives a spending estimate instead: he estimates the project used $10–$100 of model spend through ElevenLabs’ corporate account. He does not provide a token count or an itemized usage measurement.
The next question asks whether Claude controlled the Windows software running in UTM. Starkov explains that he operated it manually, following Claude’s instructions. The same division of work applied to physical observations: Claude asked him to lift the handset and count the beeps. He initially reported three, then corrected the answer to two after Claude indicated that the expected possibilities were two or four. Claude orchestrated the investigation, while Starkov supplied actions and observations it could not obtain directly. Automating the VM with computer use was a possibility he considered, not something implemented in this project.
Asked where he had to unblock Claude, Starkov distinguishes physical intervention from protocol reasoning. He could reboot the phone and control the virtual machine. He says he could not independently resolve the algorithmic reverse-engineering problems. The working loop therefore combined model-directed experiments with human operation of the software and hardware.
The final question returns to the physical connection. The phone’s black cable carried Power over Ethernet (PoE): Ethernet connectivity and power from an adapter were combined to supply the handset. The phone connected through a router, and Starkov’s laptop joined the same router over Wi-Fi. With both devices on that network, Claude checked the connected devices to locate the phone before probing its ports. That reachable network connection was the foundation for every later experiment.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
Further reading
Explains shared, host-only, emulated and bridged networking for QEMU virtual machines, including Wi-Fi bridging considerations.
The announcement of Michael Caine's participation in ElevenLabs' marketplace for licensed iconic voices.
Updates since the talk
Current instructions for SIP trunk integration, call routing, authentication and troubleshooting.
Read the complete timestamped transcript
- 0:00
[upbeat music] Hi, everyone.
- 0:15
Thank you for coming, even though there is, uh, lunch being served now. I really appreciate you coming here. Um, I'm Boris. I work for ElevenLabs. Usually, we do agents, voice agents, um, like, all things voice.
- 0:32
But for this chat, I just wanted to show you something else. Um, you might have seen, if you've been on the third floor, you might have seen this phone booth.
- 0:41
This is Swix, by the way, the organizer. Um,
- 0:45
uh, they've built it as a, as a demo, um, demo for this summit. Uh, there is this phone inside. Um, and I don't know, how many of you have went through it?
- 0:56
Did anyone? You should totally give it a try. Oh my God. Okay. But, uh, the idea is that when, when you pick it up, you actually end up talking to AI agent, uh, with the Michael Caine's voice, uh, approved, um, legal, who, who then, uh, walks you through five questions about British AI history, and then if you
- 1:19
answer at least one of them, you can get a swag from, from ElevenLabs. So that's the idea. But, uh, today I wanna show you how I actually build it.
- 1:27
So this is how it looks like now, and this is how it looked like last week. This is the, um, old... I mean, it's not that old. It still has a, a controller inside, but it's a quite old piece of hardware, this phone.
- 1:45
And the main problem when we tried to make this happen, the main problem with the, this piece of hardware was that, um, it only had a Windows, Windows XP compatible, uh, software.
- 2:02
So it was very hard to set it up, because it turned out that nobody at ElevenLabs have a Windows, uh, laptop. Uh, we all had Macs. But also when we tried to set up like, a virtual environment, you know, also had some driver issues.
- 2:15
So, uh, what happened to this phone, uh, our team in San Francisco purchased it one year ago for some other event, and three software engineers, three senior software engineers and a Claude...
- 2:26
Uh, sorry, ChatGPT at the time, they couldn't figure out how to make it work. So it was just for one year, it was just laying there, uh, waiting for, waiting to be rescued.
- 2:38
And, um, for this project, we, we, we asked them to send it to, to London. Um, and uh, then I tried to crack it, hack it, reverse engineer it using Claude Code.
- 2:51
And this is what I wanted to talk about, how to use Claude Code not just to build, uh, applications, but how to use it to actually like, uh, reverse engineer some hardware.
- 3:02
So by the way, these slides are fully, fully made by Claude Code as well. So I... The way I made them is I, um, put the whole conversation we had about this, um, process, and then asked it to, as a context, and then asked it to make slides based on that.
- 3:20
So the goal here, uh, what we want to achieve is, uh, we have this Viking phone, the,
- 3:28
uh, retro legacy Viking phone, and we want to connect it to a conversational AI agent by ElevenLabs. Uh, it can only make a phone call to a phone number, so we need to put Twilio in between just, um, to handle that SIP, SIP domain complexity.
- 3:45
So it goes Viking phone, then Twilio, then ElevenLabs.
- 3:49
Um, yeah, the problem, [laughs] I have a Mac.
- 3:55
Uh, so we couldn't really like easily set it up. Uh, so what we ended up doing, what I ended up doing instead, I, uh, connected the,
- 4:07
connected, uh, my laptop to the phone via router and, uh, started, uh, exploring. I mean, by saying I started exploring, uh, Claude Code started exploring it. So first, it, um, unmapped all of the ports that were available, uh, so port 1001, um,
- 4:30
which turn- turned out to be the wrong one. It was just a electronics tunnel.
- 4:36
Um, then it proceeded to iterate, and the next one was the actual, uh, target port that could be used to communicate with the phone. So step one, Claude Code found the way to communicate with the phone.
- 4:49
Um, then, uh, then it started discovering it. So it sent, um, some random sequence. I mean, not random Viking, but just random sequence, um, to the phone. And the phone responded.
- 5:04
So that's how Claude Code realized that, um, that this is an actual interface, a protocol. But the protocol is not, like, Googleable. You can't... There is no open documentation on what the exact protocol is, so it had to then, um, reverse engineer it, right?
- 5:22
So first thing Claude noticed is that when you send a random string to the phone, it returns, uh, this ER and then the string itself, meaning likely it's an error, error that this string is not a correct command for the phone.
- 5:38
So next, um, yeah, next Claude figured out those commands that, um,
- 5:51
that this, uh, this phone, it operates using two letter commands, command codes. Um, some of them are non-existent, then, um, it returns an error, like on this slide. Other, however, they return something else.
- 6:05
Um, the next idea was that actually if it's two-letter commands, then we can just iterate through all of them, right? Uh, brute forcing. So it, uh, wrote, uh, this, this program and, uh, literally like tried out every single combination of two letters.
- 6:23
Um, and it turned out that most of them returned error codes, but eight of them returned actual like something else, meaning they're actual valid commands.
- 6:34
Uh, those were some of them. By the way, I'm not sure...
- 6:45
Okay, I'm not sure what this is, but, uh,
- 6:49
yeah. Then it, uh, then it, uh... Some of the commands, they kinda made sense based on the,
- 6:56
on, on the name. Uh, maybe not those ones, but for example, uh,
- 7:02
SA for status kinda makes sense. I don't know if it makes sense. Yeah. Uh, then, uh, then it proceeded to try to set up the actual credentials on the phone.
- 7:15
So this is, this is, uh, this is the phone memory, and it... Basically what we're trying to do here is to put the right credentials to the phone memory so that it knows where to call.
- 7:25
We want to call Twilio SIP trunk, right? Um, and it turned out that, yes, these commands, they worked, and, uh, all of the settings got accepted. But the problem is the moment the phone got rebooted, they all were gone.
- 7:40
So they were not saved in the memory. They were just wrote to the temporary memory. And then, uh, we started, me and Claude Code, we started like a multi-hour operation of trying to figure out how to actually save what you put to the- put, put to this like s- temporary memory, how to make it actually, um, uh,
- 8:06
persistent, like how to save it to the long-term memory of the phone. It tried everything. It tried different commands. Then it... I don't know if the slides g- are gonna show this, but it tried three-letter commands.
- 8:19
It iterated over all three-letter commands, over all reasonable words, and it didn't find anything.
- 8:28
Uh, so this was the dead-end situation. This was around the place where, uh, our team in San Francisco, when we just started, uh, exploring it the first time, um,
- 8:43
they, they could, they couldn't figure out what to do next. But that was one year ago, and, um, it was only ChatGPT. Now with Claude. Claude didn't give up at this point.
- 8:54
Claude suggested that, uh, there is a... Yeah, Claude figure, figured out the problem, and then it suggested a solution. So the solution at this, uh, step was, was to set up a Windows virtual machine.
- 9:12
However, uh, the main problem with, with Windows virtual machine is that you can't bridge Wi-Fi, uh, to macOS, so there is no internet connection in the Windows virtual machine.
- 9:23
So what Claude did next was actually a very smart thing. It set up a TCP proxy on the Mac so that the, uh, traffic from the virtual machine... Oh, why are we setting up virtual machine?
- 9:36
Because in the virtual, in the Windows virtual machine, we can set... We can, um, run the software of this phone that actually knows how to communicate with it. So the solution, uh, so what we are trying to do now, we are trying to, uh, put like a meet in the middle attack kind of, to intercept the traffic
- 9:55
between the software and the phone, to analyze it and to figure out how, how it communicates, how it works.
- 10:03
So the software is running in Windows virtual machine now. Then it, 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's the protocol is.
- 10:22
What are the... What is the missing piece?
- 10:25
Um, very simple code. And then, yeah, then it started capturing the
- 10:33
communication, and it, uh, figured out that there was this command that, uh, that, uh, Claude didn't understand before, which is TS, uh, which had like some weird binary payload.
- 10:50
And then that had like this format. And what you can see here is most of the,
- 11:00
most of the params of this, uh, command, they kinda make sense except for the checksum. But checksum turned out to be only, uh, one byte. So it's something that you can
- 11:12
brute force as well. Um, right. Yeah. Uh, so the way it, uh, it work, it doesn't know the checksum, but it knows which data is being sent, and it knows the result.
- 11:29
So it can, uh, easily reverse engineer the, the encryption protocol, which is just... Which turned out to be just adding a, a...
- 11:41
Yeah, basically doing a simple subtraction, like adding a sim- a simple one-byte value, uh, to the checksum. It's not just Claude Code. I want to highlight it. Claude Code didn't just figure out what the, um, format of the checksum is.
- 11:58
It actually like managed to find it, and then it confirmed it, uh, by running, uh, by running more values through it. So it, it was kinda like closed-loop iteration.
- 12:11
Um, and at this point, the phone was pretty much cracked.
- 12:17
Um, so now we managed to figure out how the software communicated to the phone.
- 12:24
And, uh, we had the list of commands, and we... What was that?
- 12:33
Yeah, and then, uh, we figured out how to actually... The, the problem I stated in the beginning, how to actually, uh, save what you, what you put to the memory.
- 12:43
You need, um, this, uh, to run this sequence of commands.
- 12:49
Um, and the last one, uh, the fun bit was that actually there is this, uh, 256 bytes, um, memory in the phone, which, um, it also happened to crack.
- 13:04
Um, and then the, the last bit, the last bit of this, uh, process was that actually I didn't want to run Windows, uh, virtual machine every time. So the last bit was actually, uh, now when I know the protocol, I know how to talk to the phone, I can just factory reset it, and now I can use
- 13:25
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, um, now everyone, if any of you by any chance have a Viking phone, you don't have to set up Windows machine.
- 13:47
You can just ask Claude Code, like give this, um, skill to Claude Code, and, um, it will set it up.
- 13:55
Um, yeah, victory. Um, it works. I mean, I didn't go into much details about how this step works because it's super easy thanks to ElevenLabs. We, we really made it end video.
- 14:08
I mean, this step is super easy. This one was the most painful part. I think it took me, like, couple of days to, to reverse engineer it. I'm really trying to avoid the word hack, uh, that I hacked the phone.
- 14:22
I reverse engineered it. Um, yeah, so I mean, what we learned about the protocol, it has two layers. Um, the encryption, it... We were lucky that the encryption was just a single byte checksum because it, if it was something harder, then it would probably be much harder to break.
- 14:43
And, um, yeah, and the persistence bit, we had to run the server, intermediate server between virtual Windows machine and, and the phone. And
- 14:56
that's how, just, yeah, to comment on the step five here, um,
- 15:03
without Claude Code, it wouldn't be possible to, to, to do that demo. It, it, it's not just it made it 10 times faster. It just made it possible because I'm not a, a security, security engineer whatsoever.
- 15:18
I'm actually, like, just a normal software engineer. And I had, like... When I looked at all these, like, programs, I was like, "What, what is that? What is that?
- 15:25
What is 0x?" Okay. Um, yeah, that's it. Um, so now, uh, the outcome of this is not just a nice demo that you can see on the third floor.
- 15:37
It's also a skill that makes it much easier to,
- 15:43
to program the, this, this kind of phone. And, um, the nice part is that I think this is extendable to other hardware as well. So it's not just, like, Viking specific, but, like, if you want to crack some other hardware, I would really recommend thinking about...
- 16:01
Well, you don't... The, the difference is that one year ago you actually needed the proprietary software interface that the provide- the, the company that made the hardware provides. Now you don't need it.
- 16:13
You can connect to, to the phone, but you can... The same way you can connect to any, like, piece of hardware in your house. Um, so this is, this is cool.
- 16:23
Um, yeah, this is how it started. Uh, yeah, and the, the actual demo, again, to people who just came here. On the third floor we have, uh, this red telephone booth.
- 16:33
Uh, lets you speak to Michael Caine. Uh, how many of you have tried it? Have, has anyone? Oh my God. Okay, you should totally try it. It's, it's, it feels magical and I just, uh, told you how I, how I made it into real life.
- 16:49
Yeah. Um, any, I guess, any questions? This is the booth. And this is Twix.
- 16:57
Do, do you know how many tokens you burned? [laughs]
- 17:01
I used ElevenLabs', uh, our corporate tokens. So I, I... Yeah, I think it was an order of between $10 and $100. So quite reasonable.
- 17:12
And, and, and did, did you have the... Did you have Claude... So, so you had some software that you installed on UTM on Windows. Did you have Claude control that as well or, or, or did somebody have to manually control it?
- 17:25
It, it, it was, it was a quite interesting process because my participation in that was basically following Claude's commands.
- 17:33
Right.
- 17:33
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 and like, "Okay, I think three."
- 17:43
It was like- [laughs] ... "You idiot, it's either two or four." And I'm like, "Oh yeah, it's two." [laughs] So it was like I was actually, like, the agent for Claude.
- 17:52
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 used, like, computer use or something, I could, uh, make it fully, like, close the r- close the loop and make it control the virtual machine.
- 18:10
But I was too lazy, so I just did what it told me to do.
- 18:14
Were there any places where Claude got stuck and you had to help or is it all done for you?
- 18:21
Uh, stuck in, in what sense?
- 18:23
As in it couldn't figure out the next step.
- 18:25
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.
- 18:32
How did you just remove it?
- 18:33
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 c- I wouldn't be able to unblock it.
- 18:48
I mean, it was just smarter than me, I think. Yeah. Um...
- 18:54
How, how did you physically connect to the phone?
- 18:57
Yeah. I, I wish I had a picture. Um,
- 19:02
so this phone, you can see the black cable.
- 19:05
Yeah.
- 19:05
It's, uh, called, uh, power over Ethernet, PoE.
- 19:09
Yeah.
- 19:09
Which is, uh, 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.
- 19:20
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 Wi-Fi router as well.
- 19:32
Okay.
- 19:32
And then, yeah, and then there was this step of, uh, [clears throat]
- 19:37
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.
- 19:46
Okay. I'm gonna have to call time.
- 19:49
Yeah. Yeah.
- 19:49
Next session coming in.
- 19:50
Thanks. Thanks everyone.
- 19:51
Great. Um... [clapping] [upbeat music]