So the goal here uh what we want to achieve is uh they have this Viking phone. The uh retro legacy Viking phone. And we want to connect it to a conversational AI agent by 11 Labs. 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 a SIP SIP domain complexity. So it goes Viking phone, then Twilio, then 11 Labs. Um Yeah, the problem. I have a Mac. Uh so we couldn't really like easily set it up.

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. 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 uh Windows Windows XP compatible uh software. So it was very hard to set it up cuz it turned out that nobody at 11 Labs have a Windows uh laptop. Uh they all had Macs. But also when we tried to set up like a virtual environment, you know, also had some driver issues. So uh what happened to this phone? Um Our team in San Francisco purchased it 1 year ago for some other event. And three software engineers, three senior software engineers and a Claude uh sorry, ChatGPT at the time, they couldn't figure out how to make it work. So it was just for 1 year it was just laying there uh waiting for waiting to be rescued. And uh 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. 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.

Uh so what we ended up doing, what I ended up doing instead, I uh connected the connected my laptop to the phone via router and uh started exploring. I mean, by saying I started exploring, uh Claude code started exploring it. So first it um nmapped all of the ports that were available. Uh so port 1001. Um Which turned out to be the wrong one. It was just uh electronics tunnel. Uh 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.

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. So that's how Claude code realized that um that this is an actual interface, a protocol. But the protocol is not like Google-able. You can't There is no open documentation on what the exact protocol is. So it had to then um reverse engineer it, right? 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.

So next um Yeah, next Claude figured out those commands that um that this this phone it operates using two-letter commands, command codes. Um some of them are non-existent, then it returns an error like on this slide. Other, however, they return something else. 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 wrote this this program and literally like tried out every single combination of two letters. Um and it turned out that most of them returned error codes, but 80 of them returned actual like something else, meaning they're actual valid commands.

Then then it proceeded to try to set up the actual credentials on the phone. So this is this is uh this is the phone memory. And it 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 SIP trunk, right? Um 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 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 to this like temporary memory, how to make it actually um persistent. Like how to save it to the long-term memory of the phone. It tried everything. It tried different commands. And then it I don't know if the slides are going to show this, but it tried three-letter commands. It iterated over all three-letter commands, over all reasonable words. And it didn't find anything. Uh 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. Um They they could they couldn't figure out what to do next. But that was 1 year ago when um there was only ChatGPT. Now with Claude, Claude didn't give up at this point.

Claude suggested that uh there is a Yeah, Claude figured 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. However, uh the main problem with with Windows virtual machine is that you can't bridge Wi-Fi um to macOS. So there is no internet connection in the Windows virtual machine. 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? 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're trying to do now, we're trying to uh put like a man in the middle attack kind of to intercept the traffic between the software and the phone to analyze it and to figure out how how it communicates, how it works. 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, what are the what is the missing piece.

And it figured out that there was this command that uh that Cloud didn't understand before, which is TS. Um which had like some weird binary payload. And then that had like this format. And what you can see here is most of the most of the params of this uh command they kind of make sense except for the checksum. But checksum turned out to be only uh one byte. So, it's something that you can brute force as well.

Uh so, the way it it work 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 the encryption protocol. Which is just which turned out to be just adding a uh Yeah, basically doing a simple subtraction like adding a sim a simple one byte value uh to the checksum. It not just Cloud code, I want to highlight it. Cloud code didn't just figure out what the um format of the checksum is. 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 kind of like closed loop iteration. Um 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 uh we had the list of commands and 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. We need um this uh to run this sequence of commands.

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 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. You can just ask Cloud code like give this uh skill to Cloud code and it will set it up.

without Cloud 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 security security engineer whatsoever. I'm actually like just a normal software engineer...it was just smarter than me, I think.

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...1 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. 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.