When working with test equipment such as oscilloscopes and function generators, it can be useful to take a screen capture. Historically this was done with Polaroid cameras that were bolted in place, but these days it can be done over a simple USB connection. [Majenko] didn’t like the Windows-only software that shipped with their Tenma 72-14110 function generator, however, and set about reverse engineering the USB protocol to create their own.
The hack was pulled off by running the original software in a Windows VM, while running Wireshark in the host Linux OS to capture the USB traffic. Once enough data had been captured, [Majenko] set about figuring out how the function generator formatted the screen data when sending it to the PC. Based on the fact that the data changed in length depending on what was on the display, it was surmised that the data was not raw, but compressed somehow. A hunch suggested it was probably some form of Run-Length Encoding, and this proved to be correct. With a little more digging and experimentation, [Majenko] was able to put together some code that netted a clear image from the device.
It’s a useful guide for reverse engineering image data, one that could prove useful if you’re tackling a similar problem on other hardware. We’ve seen some great reverse engineering efforts over the years, on everything from old video hardware to the Sega Saturn. If you’ve been diving deep into the secrets of software or hardware yourself, be sure to drop us a line.
It could probably be done with Ghidra on the Windows executable. No need to reverse-engineer low-level USB comms.
Never heard of it. However I do know about USB. You use the tools you know.
OMG. Why the hell didn’t I ever think of logging USB with wireshark on the host, with the target running in a VM? Stroke of genius.
License agreements prevent reverse engineering of binaries. That is if people actually read them. Better to clean room reverse engineer it instead, with a USB shim, aka usb-shark/usbmon, so people can’t accuse you of copying code.
There’s no crime if no one sees you doing it.
That’s a nice bit of reverse engineering, and a good write-up. For those of us who only dabble in this, it gives good insight into the process.
I can understand the ‘Windows Only’ problem. Can be aggravating. I to have Windows 7 setup in a VM, in the rare case I might need it. Anyway, a neat bit of reverse engineering. Congrats.Your ‘hunch’ worked out very well it seems. Maybe you should be a cryptologist :) . When I worked a lot with serial protocols, I almost always had a manual to look at to ‘read’ the data stream — usually. Good job.
Reminds me of a section of Soul of a new machine.
Well it’s been a while, but thought they were chasing a glitch in the bus.
Eeek, he’s just figuring out how the pixels are stored in an image blob, not “Reverse Engineering USB Protocols On A Function Generator”
Did you miss the part where he implemented a driver using libusb and a custom c program to acquire the image data first?
Yeah, I’ve seen WireSharkl output, so I figured it was trivial from there on. Maybe it wasn’t.
“I know how to do this, therefore everyone who doesn’t is an idiot and should know it”
Any chance of reverse engineering the remote commands as well? I have a 72-14120 and I’m pretty bummed I can’t use regular SCPI to address it.
Btw, Tenma is the Farnell white label brand, the actual manufacturer in this case is Uni-T, and the actual model name of your device is UTG2000B
I am working on documenting more of the protocol at the moment. I haven’t worked out how it sends commands yet, but I can get the state of the front panel LEDs, lock the front panel controls, and get the model and serial numbers. Remote controls is one of the things I really want to try and decode.
Thanks for the Uni-T tip. They use a number of different makers for their different devices, and I hadn’t managed to find what the root maker of this one is. I like Uni-T – got a number of their DMMs…
Too bad they don’t document their functions like most instruments do. For GPIB and usually ethernet the big guys like Tektronix and HP/Agilent/Keysight publish and expose APIs to get raw data and control the devices. I would not feel bad about “reverse engineering” any device that does not publish that data. It’s just wrong in the test instrument world. Makes it difficult to integrate into an automated testing procedure that is computer driven when they tie you to a single purpose interface like that. I suspect we will see lots more of this as we see more black box type instruments and SDRs where a computer is an integral part of functionality. There are quite a few vendors out there who make great hardware but the software almost seems like an afterthought.
Yeah. You pay for the reduced equipment cost in shoddy support and documentation. Still, when you’re on a budget your choices are limited, as the saying goes.
@Majenko, nice find, though it’s a shame they only send the image. Uni-T is somewhat notorious for shitty protocols, the stories I could tell…
Tip: you can reduce by half the USB packet chatter by only showing (direction==out && type=submit) + (direction == in && type == complete). That filters out USB protocol cruft (don’t use this if the device uses control packets).
@Koenraad you surprise me. IIRC you once attended a talk at Revspace in Den Haag about reverse engineering USB protocols. You should be able to do this :-)
That’s a great tip on the USB cruft. I’m pretty much a Wireshark noob. I usually use a Beagle 480 for USB sniffing, but that’s overkill when you have a VM and Wireshark at your disposal…
Great to read and see the results!