Reverse-Engineering An Unknown Microcontroller In E Ink Displays

For a monochrome display where refresh rate isn’t particularly important, there’s almost no better option than an E Ink display. They’re available in plenty of sizes and at various price points, but there’s almost no option cheaper than repurposing something mass-produced and widely available like an E Ink (sometime also called eInk or ePaper) price tag. At least, once all of the reverse engineering is complete.

[Dmitry Grinberg] has been making his way through a ton of different E Ink modules, unlocking their secrets as he goes. In this case he set about reverse engineering the unknown microcontroller on the small, cheap display show here. Initial research showed an obscure chip from the ZBS24x family, packaged with a SSD1623L2 E Ink controller. From there, he was able to solder to the communications wires and start talking to the device over ISP.

This endeavor is an impressive deep dive into the world of microcontrollers, from probing various registers to unlocking features one by one. It’s running an 8051 core so [Dmitry] gives a bit of background to help us all follow along, though it’s still a pretty impressive slog to fully take control of the system.

If you happen to have one of these price tags on hand it’s an invaluable resource to have to reprogram it, but it’s a great read in general as well. On the other hand, if you’re more interested in reverse-engineering various displays, take a look at this art installation which spans 50 years of working display technologies.

Using CanoPy To Visualize The CAN Bus

As cars have become more sophisticated electronically, understanding the CAN bus that forms the backbone of automotive digital systems has become more and more important for hacking cars. Inexpensive microcontroller CAN interfaces have made obtaining the raw CAN bus traffic trivial, but interpreting that traffic can be pretty challenging. In order to more easily visualize CAN traffic, [TJ Bruno] has developed CanoPy, a Python tool for visualizing CAN messages in real time.

A basic PC CAN interface simply dumps the bus’s message traffic into the terminal, while more sophisticated tools organize messages by the address of their intended recipients. Both of these approaches digitally lift the hood and let you examine what your car is thinking, but the wall-of-numbers approach makes finding the patterns that hold the keys to reverse engineering difficult. Automatically plotting the data with CanoPy makes finding correlations much easier, after which the text-based tools can be used to focus in on a few specific addresses.

Continue reading “Using CanoPy To Visualize The CAN Bus”

VME Reverse Engineering

With some free time on his hands waiting for delayed parts to arrive, [Rik] set out to reverse engineer an old VME system he had acquired. VMEbus computers are based on the standard Eurocard PCB format, which defines a wide range of card sizes — the most common being 6U height like [Rik]’s system. They usually consist of a rack-mounted card cage with a passive backplane. Originally, Motorola 68000-based CPU cards were used in VMEbus systems, but any processor could be used as long as you provided the right signals and timings to the system bus. Eurocard systems are less common these days, but are still used in some applications. In fact, if you’re into synthesizers, you may be using Eurocards today — the Eurorack standard is based on the standard 3U card size.

Back to [Rik]’s project, he had no idea what this system was nor how to use it. A bit of probing around and he found two UARTs, a system monitor, and a way to load and dump S-record files. He documents the process quite well, as the internal layout and memory map of the system is unlocked piece by piece. We also like his method of instrumenting the VMEbus signals — logic analyzers are so small today, you can just mount one inside the rack.

Spoiler alert: [Rik] succeeds in mapping out the memory, writes some small programs in 68k assembly language, and even builds his own LED accessory card so he can blink some lights (as one must do).

We wrote about modularity recently, and VMEbus + Eurocard systems are good examples of modular design. You could quickly put together a robust assembly using entirely off-the-shelf cards, or mix in your own custom cards. But technology advancements in clock speeds and miniaturization have made these card cage, passive backplane systems less and less relevant today. Do any of you still use the VMEbus, or have you designed with them in the past? Let us know down in the comments below.

Soundbar Bested By Virtual Android Bluetooth Sniffer

Out of the box, the Yamaha YAS-207 soundbar can be remotely controlled over Bluetooth, but only when using a dedicated application on iOS or Android. Users who want to command their hardware with their computer, or any other Bluetooth device for that matter, are left out in the cold. Or at least they were, before [Wejn] got on the case.

To capture the communication between the soundbar and the application, [Wejn] first installed Android-x86 in a virtual machine on his computer and then enabled the “Bluetooth HCI snoop log” within Developer Settings. From there, a netcat command running on the virtual Android device continually sent the contents of the btsnoop_hci.log file out to Wireshark on his Linux desktop. As he hit buttons in the Yamaha application, he could watch the data come in live. We’ve seen plenty of people use Android’s integrated Bluetooth packet capture in the past, but never quite like this. It’s certainly a tip worth mentally filing away for the future.

The Pi can now control the TOSLINK connected speakers.

From there, things move pretty quickly. [Wejn] is able to determine that the devices are communicating over a virtual serial port, and starts identifying individual command and response packets. It turns out the commands closely mirror the NEC IR codes that he’d previously decoded on a whim, which helped clear things up. Once the checksum was sorted out, writing some code that can talk to the soundbar from his Raspberry Pi media player was the next logical step.

[Wejn] combined this with the Shairport Sync project, which lets the Raspberry Pi turn on the speaker and switch the input over when he wants to stream AirPlay from his phone. But of course, the same technique could be applied to whatever source of digital audio captures your fancy.

This is one of those posts you should really read in its entirety to truly appreciate. While every device is going to be different, the basic principles and workflow that [Wejn] demonstrates in this project will absolutely be useful in your own reverse engineering adventures. If you’re more of a visual learner, we recently covered a series of YouTube tutorials that cover sniffing BLE devices that’s not to be missed as well.

[Ken Shirriff] Picks Apart Mystery Chip From Twitter Photo

It’s no secret that the work of [Ken Shirriff] graces the front pages of Hackaday quite frequently. He’s back again, this time reverse engineering a comparator chip from a photo on Twitter. The mysterious chip was decapped, photographed under a microscope, and subsequently posted on the internet with an open call to figure out what it did.

[Ken] stepped up, and at first glance, it was obvious that most of the chip is unused, and there appeared to be four copies of the same circuit. After identifying resistors and the different transistor types, [Ken] found differential pairs.

Differential pairs form the heart of most op-amps, and by chaining them together, you can get a strong enough signal to treat it as a logic signal. Based on the design and materials, [Ken] estimates the chip is from the 1970s. Given that it appears to be ECL (Emitter-Coupled Logic), it could just be four comparators. But there are still a few things that don’t add up as two comparators have additional inverted outputs. Searching the part number offered few if any clues, so this will remain somewhat a mystery.

We’ve covered [Ken’s] incredible chip sleuthing before here, such as the Sharp EL-8 from 1969.

Taking Reverse Engineering To The Skies: Cheap Drone Gets PX4 Autopilot

Sometimes bad software is all that is holding good hardware back. [Michael Melchior] wanted to scavenge some motors and propellers for another project, so he bought an inexpensive quadcopter intending to use it for parts. [Michael] was so surprised at the quality of the hardware contained in his $100 drone that he decided to reverse engineer his quadcopter and give the autopilot firmware a serious upgrade.

Upon stripping the drone down, [Michael] found that it came with a flight management unit based on the STM32F405RG, an Inertial Measurement Unit, magnetic compass, barometric pressure sensor, GPS, WiFi radio, camera with tilt, optical flow sensor, and ultrasonic distance sensor, plus batteries and charger! The flight management unit also had unpopulated headers for SWD, and—although the manufacturer’s firmware was protected from reading—write protection hadn’t been enabled, so [Michael] was free to flash his own firmware.

We highly recommend you take a look at [Michael]’s 10 part tour de force of reverse engineering which includes a man-in-the-middle attack with a Raspberry Pi to work out its WiFi communication, porting the open-source autopilot PX4 to the new airframe, and deciphering unknown serial protocols. There are even amusing shenanigans like putting batteries in the oven and freezer to help figure out which registers are used as temperature sensors. He achieves liftoff at the end, and we can’t wait to see what else he’s able to make it do in the future.

Of course, [Michael] is no stranger to hacking imported quadcopters, and if you’re interested in PX4 but want something quieter than a quadcopter, take a look at this autopilot-equipped glider.

Camera Hack Peels Back Layers Of Embedded Linux

Embedded Linux devices are everywhere these days, and sooner or later, you’re going to want to poke around in one of them. But how? That’s where posts like this one from [Felipe Astroza] come in. While his work is focused on the Foscam C1 security camera, the techniques and tools he outlines here will work on all sorts of gadgets that have a tiny penguin at their core.

Rather than trying to go in through the front door, [Felipe] starts his assault with the nuclear option: removing the SPI MX25L12835F flash chip from the camera’s PCB and dumping its contents with a Raspberry Pi. From there he walks through the use of different tools to determine the partition scheme of the chip and eventually extract passwords and other interesting bits of information from the various file systems within.

Getting ready to remove the flash chip.

That alone would be worth the read, but things really get interesting once [Felipe] discovers the FirmwareUpgrade program. Since the Foscam’s software updates are encrypted, he reasons that reverse engineering this binary would uncover the key and allow for the creation of custom firmware images that can be flashed through the stock interface.

Further investigation with Ghidra and friends identifies an interesting shared library linked to the executable in question, which is then disassembled in an effort to figure out how the key is being obfuscated. We won’t ruin the surprise, but [Felipe] eventually gets what he’s after.

This isn’t the first time [Felipe] has played around with the firmware on these Internet connected cameras, and we dare say it won’t be his last. For those who are really into tinkering with these sort of devices, it’s not unheard of to install a socket for the flash chip to make software modifications faster and easier.