Reverse Engineer That USB Device In Style

Proprietary device drivers, dedicated applications, and their ilk are the bane of the open-source hacker. If only we could snoop on every device out there, recording the “secret” USB transactions as they go over the wire, we’d have a chance.

[Emir Mrkaljević]’s tool, usb-rea, aims to make this process a whole lot less painful. The workflow is like this: you start capturing on USB, make an annotation about what action you’re taking, press the button a few times, and then move on to the next action.

sudo modprobe usbmon
usb-rea capture start -o lamp.pcapng
usb-rea mark -m lamp.pcapng.actions.json "brightness 0%"    # then click it in the vendor app
usb-rea mark -m lamp.pcapng.actions.json "brightness 50%"   # ...repeat for 3+ values per setting
usb-rea capture stop
usb-rea report lamp.pcapng -o report.md
usb-rea scaffold lamp.pcapng -o lamp_driver.py
usb-rea dissector lamp.pcapng -o lamp.lua      # Wireshark dissector for the same protocol

Usb-rea records all the USB traffic, timestamps it relative to your actions, and gives you a report, a driver, and a Wireshark protocol dissector out the back side. There is even an MCP file so that you can hand off the grunt work to the bots, possibly enabling this to work closed-loop?

Of course, you don’t want to reinvent the wheel, so it’s fun to see that there’s also a usb-rea lookup command to see if your VID:PID is already in the dataset. Most of the devices are CPU coolers, RGB controllers, and other blinged-out computer peripherals, but we imagine that it’s a lot more broadly applicable. We looked for our mouse on the list, but it’s sadly not there.

Usb-rea is not a silver bullet to bring back abandoned peripherals from the grave, because you still need to run the proprietary driver during the recording. But if you get ahead of the game and document the protocols before the manufacturers abandon them, you stand a chance. Get recording!

Borland C++ 2.0 Compiler Source Reconstructed

As the successor to Turbo C++, Borland C++ was a staple of professional IDEs for C and C++ development, starting with the initial 2.0 release in 1991. Being a commercial project the original source code for the toolchains were naturally not made available by Borland, but thanks to the efforts of [Abedegno] we have now got what is claimed to be a byte-perfect recreation, in the sense that the binaries compiled using the toolchain are identical to the original toolchain.

The process of creating the source from the original toolchain binaries is detailed in a separate document, including the use of [Abedgno]’s Claude Code-based Exhume tool to assist in the effort.

Having the source code for BC++ 2.0 available is probably most useful for projects that deal with DOS-based software from the same era, as well as for purely historic interest reason. When BC++ 2.0 was released, the C programming language had only just seen itself standardized in the form of C89, and C++’s initial standard in 1998 was still years away.

Thanks to [Stephen Walters] for the tip.

Using A Toothbrush’s NFC Chip To Unlock A Computer

Depending on which type of electric toothbrush you are using, the replaceable brushes may contain an NFC chip that the handle and possibly base station uses to track various details, such as time spent brushing and when to replace the brush. The Philips Sonicare of [Circuit Helper] is one such unit, with its NFC chip tracking aspects like runtime and pressure.

Unsurprisingly it’s easy enough to read and write this same NFC chip with a PN532 NFC reader and ESP32-S3 MCU. This reveals data fields for everything from brush type, to total runtime and expected lifetime, inviting a bit of experimentation on how certain usage patterns affects these data fields.

This much is perhaps not too shocking, but the fun part is what you can do with the chip after you have figured out how to write to its memory. How to unlock these units and their NXP NTAG213 IC has been figured out a few years ago already, so the hardest part was to figure out what to do with this information.

The demonstrated use case in the video is to unlock an Apple Macbook, which is maybe a bit too niche. Also demonstrated is taking the chip and its antenna out of the brush, which turns out to be quite easy. Perhaps salvaging just this one part of the brush is the more practical and hygienic option, as who doesn’t like building up a strategic supply of ‘free’ NFC chips?

Continue reading “Using A Toothbrush’s NFC Chip To Unlock A Computer” →

USB-C Hub Or Nintendo Switch 2 Dock? Relax, It’s Both!

[Nozomi] travels with a Nintendo Switch 2, but the official dock is bulky and doesn’t seem to be made for travel. USB-C hubs with displays are common, but they won’t work with the Switch. Not without a little hacking, anyway.

It was obvious that the hub wasn’t too far off. It will charge the Switch, so Power Delivery was working. A sniffer showed that even the DisplayPort initialization happened. A little flashing on the hub allowed it to complete the proprietary protocol, and that made TV mode work, but HDR was washed out. [Nozomi] theorized it was a mismatched color space, so that required a patch for a different chip. Another flash forces the right color tag for HDR TV, but there would have to be another patch for HDR DP.

That patch doesn’t exist. Variable refresh rate also does not work. We didn’t find the actual code for the patches, but we still thought the detective work was worth the read. Some people don’t want a more portable dock, but a less portable one.

Reverse Engineering A 1960s Diode-Transistor Logic IC

Before transistor-transistor logic (TTL) took over, diode-transistor logic (DTL) was a common sight especially in pre-IC circuits where it was a major improvement over resistor-transistor logic (RTL). That said, it’s rare to see DTL used in ICs considering how e.g. TI’s 5400 and 7400 series set the trend in the 1960s. This makes the Signetics ST680a quad-NAND gate DTL DIP IC that [Ken Shirriff] ogled recently a bit of a treat.

This was also one of the earliest ICs to use the then brand new plastic dual in-line package (PDIP) for modular convenience, even if [Ken] was none too happy about as unlike ceramic DIP, PDIP requires more extreme methods to decap to access the die for reverse-engineering.

Overall, TTL is faster and less power-hungry than DTL, but it took a while to work out its issues, including noise immunity and fan-in/out issues. Until then alternatives like DTL still made sense as a well-understood and mature technology. In the article an example is provided of how a DTL NAND gate as used in this IC works, which is really quite simple in how it uses multiple diodes to sum the inputs, which subsequently drives the transistors.

We’d like to thank [CuriousMarc] for finding this IC in his strategic reserve of unknown ICs and for doing the initial decapping using hot air, as well as [Ken] for doing the analysis and documenting of this fascinating glimpse into early semiconductor logic history.

MousePods Reverse Engineers Head Tracking Data From Stubborn AirPods

[Matteo Gaudioso] released MousePods, a Python tool which accesses the motion sensors in Apple AirPods on Linux, turning them into mouse input. No Apple host required. Doing this required reverse-engineering how the devices work and communicate, because it turns out the AirPods 3 do things differently than other models.

Everything runs in a single Linux app, no Apple host involved.

Head tracking with AirPods has been around for years. Apple uses the motion data for spatial audio and gesture detection, and there are a number of open source tools to access that data. But there was always a blind spot: no one could figure out how to talk to the AirPods 3.

[Matteo] enlisted the help of Claude Code in digging out what was different, and found Claude pretty useful for running hundreds of probes and tests to the AirPods to eventually tease out what was going on, among other things. The findings are nicely summarized here. One interesting one is how the sensor data was indirectly hidden by the fact that on Linux the default MTU (Maximum Transmission Unit) is too small to hold the whole payload complete with motion sensors. Once the Linux MTU is increased to match the considerably larger iOS default, everything appears.

There’s one other feature we like: the ability to send the data to opentrack to use as head tracking input to things like flying or racing simulators. We’ve seen this done with flight sims using headphones for head tracking, which is a great way to use sensor data that already exists without impacting the audio functionality.

Some features are still experimental, but MousePods is confirmed to work with the Apple AirPods 3 and AirPods Pro 2. Check out the MousePods website for a bit more info if you’d like to give it a try.

Translating An Old Display To A New One

A quick search through AliExpress will find PCBs that take HDMI or VGA and translate them to DSI lanes for TFT panels, and even boards that translate DSI to HDMI in the other direction. Usually they need dedicated silicon or if you’re doing it yourself, an FPGA, but depending on the display that need not be the case. As an example, [Voltage Ventures] has replaced a defective STN display with a more modern one using nothing more complex than a Raspberry Pi Pico.

The display comes as part of a Samsung cash register that looks as though it comes from the 1990s, which is in keeping with it having a monochrome STN display. A replacement was going to cost a fortune, so some way of translating between the two was in order. It has a 4-bit data bus, so there’s a description of how they sampled the bus and identified the timing used. It’s hardly the highest resolution display by today’s standards, being a meager 320 by 240 pixels. Once the format is known it’s a case of transposing it to monochrome VGA in the microcontroller. Initial work was done with an STM series chip, later this was moved to the RP2040.

We like this project, and it’s a reminder that even something broken and old can still be rescued.