Abusing Undocumented Silicon Registers for Custom ADS-B Reception

TLDR: Researchers at DEF CON 32 demonstrated how to bypass standard video-processing hardware blocks on an Allwinner T113 SoC to repurpose its internal ADC for raw signal processing. By reverse-engineering undocumented registers in the AXP2585 power management IC and the SoC itself, they achieved custom ADS-B demodulation without external hardware. This research highlights the potential for exploiting "black box" embedded components to gain unauthorized access to raw data streams.

Hardware hacking often feels like a game of working around the manufacturer's intended path. We usually assume that if a chip is designed for video processing, it is a black box that only outputs processed frames. This assumption is exactly what leads to missed opportunities in embedded security research. When you stop treating a System-on-Chip (SoC) as a locked-down appliance and start treating it as a collection of programmable logic blocks, the attack surface expands significantly.

Breaking the Black Box

The research presented at DEF CON 32 focused on the Allwinner T113 SoC, a chip typically found in automotive infotainment systems. The goal was to build a functional ADS-B receiver directly on a conference badge. ADS-B signals are transmitted at 1090 MHz using Pulse Position Modulation. Standard implementations rely on external Software Defined Radios (SDRs) like the RTL-SDR, which are power-hungry and bulky.

The team identified that the T113 has a built-in Analog-to-Digital Converter (ADC) intended for composite video input. The challenge was that this ADC is buried behind layers of hardware filters and decoders designed to output clean video, not raw signal data. To get to the raw samples, the researchers had to bypass these blocks. They discovered that the silicon manufacturer had included specific, undocumented registers that could force the chip into a "manufacturing test mode."

By writing to these registers, they effectively disabled the color correction, sync detection, and YC separation logic. This allowed them to pull raw, digitized samples directly from the ADC. The result was a functional, low-power ADS-B receiver running entirely on the badge's core processor.

The Cost of Undocumented Features

Reverse-engineering silicon is rarely a clean process. The team spent weeks debugging why their display would turn green during the boot process. It turned out to be a classic case of cross-chip interference. A driver for a sister chip was setting an undocumented bit that didn't exist on the T113 but caused a glitch in the LCD controller of the T113 itself. This glitch permanently set the green channel to high until a hard power cycle.

This is a common reality in embedded security. You are not just fighting the documentation; you are fighting the hardware's physical state. The AXP2585 power management IC presented similar hurdles. It is a complex chip that handles USB-C negotiation, battery charging, and power distribution. Because it lacks firmware, it relies entirely on I2C register configurations.

The team found that the AXP2585 datasheet was misleading regarding battery detection. The chip assumes a battery is present by default, which causes instability if you try to boot without one. Furthermore, a manufacturing defect—a poorly soldered ground pin—caused intermittent IRQ signal failures. These are the kinds of "ghost" bugs that make hardware exploitation so difficult. You can spend days debugging your code, only to find that the issue is a physical connection that passed visual inspection but failed under load.

Pentesting Embedded Targets

For a pentester, this research is a masterclass in identifying hidden capabilities. When you are auditing an embedded device, do not just look at the exposed interfaces. Look at the datasheets for every major component, especially the power management and signal processing chips. If a chip has a "test mode" or "debug mode," that is your primary target.

If you encounter a device with an Allwinner SoC or similar architecture, check the Linux kernel source for the specific driver implementation. Often, the drivers only implement the "happy path" functionality. By comparing the driver code against the full hardware datasheet, you can identify registers that are never touched by the OS but control critical hardware paths.

The impact of this type of exploitation is significant. If you can bypass hardware-level restrictions, you can turn a simple sensor or display controller into a rogue data collection device. In an industrial or automotive context, this could allow an attacker to sniff internal bus traffic or exfiltrate data that the system designer assumed was physically isolated.

Securing the Hardware Layer

Defending against this level of access is difficult because it happens below the software layer. However, you can mitigate the risk by ensuring that debug interfaces are physically disabled or fused off in production. If your device uses chips with configurable I2C registers, ensure that the bootloader locks these registers after initialization.

If you are a developer, treat your hardware configuration as part of your security model. Do not assume that "unused" registers are safe. If a register is not documented, it is a potential vector for an attacker to change the physical behavior of your device.

Hardware hacking is not about finding a single exploit; it is about understanding the physical constraints of the silicon. The next time you are looking at a device, ask yourself what the hardware is capable of doing, rather than what the manufacturer intended it to do. You might find that the most interesting features are the ones they tried to hide.