Right now, I’m at Shmoocon, and it’s living up to all expectations. That’s a tall order — last year, the breakout talk was from [Travis Goodspeed] on his efforts to reverse engineer the firmware for a cheap Chinese radio. Four people in the room for that talk last year bought the radio on Amazon, and now there’s a legitimate open source project dedicated to building firmware and tools to support this radio.
Now that [Travis] has a few compatriots working on firmware for this radio, he has the same challenges as any other team. The project needs unit tests, and this isn’t easy to do when all the code is locked up inside a radio. Instead of setting up an entire development platform based around a cheap radio, [Travis] came up with a toolchain that’s unlike anything I’ve ever seen. Instead of reverse engineering the firmware for this radio, he’s simply emulating the ARM firmware on the desktop. Development is quick and easy, and he has the live demos to prove it.
The heart of the Tytera radio in question is an STM32F405. This is a pretty common part, and thanks to [Travis]’ work last year, he has all the firmware that ships on this radio. This doesn’t mean he has access to all the radio’s capabilities, though; there’s a black box in the code somewhere that translates .wav files to radio packets and back again. Open sourcing this would usually mean reverse engineering, but [Travis] had a better idea.
Instead of reverse engineering the entire radio, [Travis] is using QEMU to emulate an ARM microcontroller on his desktop, run the relevant code, and completely ignore any actual reverse engineering. Since this radio is already jailbroken and the community has a pretty good idea of where all the functions and subroutines are in the firmware, the most difficult part of pulling this trick off is setting up QEMU.
As a proof of concept, [Travis] downloaded raw AMBE packets from the radio to his laptop. These were then sent through the emulated radio, producing raw audio that was then converted into a .wav file. Effectively, a black box in this radio was emulated, which means [Travis] doesn’t need to know how the black box works.
All the code for this weird emulation / unit test, as well as everything the community has released for this radio is available on the GitHub. A lot of work has gone into the jailbreaking, reverse engineering, and emulation efforts here, making this radio somewhat ironically one of the most open radios you can buy.
Title clumsy. Read like there’s a reason not to attempt reverse engineering using emulation, when you’re trying to say that you can avoid direct on the hardware reverse engineering using emulation. But either way it’s reverse engineering.
I don’t understand how emulating the black box helps get rid of the black box? Or are they saying they don’t need to get rid of the black box since they can figure out how to use it in its current form?
I think it means “How to figure out the blob’s ABI without disassembling the blob”
I am not sure I fully understand the nuances of what they are doing here but at what point does this become a bad idea? This feels kind of like how some NES and other retro console emulators sort of hack and cheat to achieve “good enough:” results but they are never exact and come with their own strange quirks that are infrequently relevant or problematic. If you were then loading a binary blob into the emulator and then running it, it is going to perform similarly but not exactly the same as the original hardware. Does that matter here at all?
>>Or are they saying they don’t need to get rid of the black box since they can figure out how to use it in its current form?
Pretty much.
It’s like if instead of learning how to make a car you just bought GM. You don’t need to know how to make a car, you just need to ensure that the factories get the supplies they need so cars keep rolling off the line.
The Radio is jailbroken so they have control of the radio’s routines, they just don’t understand/can’t read how portions of it work. That doesn’t matter from the users perspective so long as you can call the routines and it return the answer.
From what I understood, they need to make some unit tests on different parts. The firmware is probably not totally reverse-engineered and there is a black box they want to test. I guess they want to send some inputs and get some outputs with a not yet reverse engineered code in a black box : using QEMU as the CPU executor of that “black box” code allows to write some unit tests on it without reverse-engineering that black box. It doesn’t mean the reverse-engineering is not needed but that it can be done later with the help of executing a unit test on the black block to check whether reverse-engineered source is correct.
Why my previous post is not showing…
I think they need to make some unit tests to help to validate their reverse-engineering. through QEMU they execute the code of a black box to which they want to provide some inputs and from which they want to get some outputs. The idea is being to able to write the reverse-engineered source of the black box later while comparing their black box unit tests between emulated code and reverse-engineered code. If they match so you’re on the right road.
There is a DSLR emulator (NikonEmulator) over at NIkon Hackers.
It’s purpose is to allow initial testing of modified firmware without the risk of bricking an expensive DSLR.
https://nikonhacker.com/wiki/NikonEmulator
This is pretty standard RE technique, I even happen to have “Using IDA’s GDB debugger with QEMU emulator” (2009 Hex-Rays SA) pdf on my desktop right now :)
What is exciting to me is a prospect of someone ripping out AMBE codec from this firmware and modding it to run on a cheap microcontroller board. Its a real shame a patented proprietary mess somehow became _the_ standard for digital HAM communication :(
The code in the picture: https://github.com/travisgoodspeed/md380tools/commit/0e763214fdd7a972e58542ff522dd17badb324dc
Yeah, as already said, confusing title.
I need waffle similar but using Baofeng or this machine. on ISM band.