From Oscilloscope to Glitch Generator The Security of UART Under Scrutiny

Related Vendor

SIMTOS (Seoul International Machine Tool Show)

The UART interface is a powerful tool for troubleshooting and configuring embedded systems. It provides direct access to the firmware and is a primary target for attackers. But how secure are common protective measures really?

UART (Universal Asynchronous Receiver-Transmitter) is widely used in device hardware as a debugging interface. Communication is remarkably simple, relying on just three lines: Transmit (TX), Receive (RX), and Ground (GND). For attackers, however, UART represents the ultimate 'Golden Ticket,' as the interface frequently provides unauthorized low-level access—in extreme cases, even to an unauthenticated root shell. Consequently, manufacturers face the challenge of securing UART in a way that allows authorized personnel to use it while locking out malicious actors. The following analysis of a real-world case demonstrates that even a highly secured implementation is not an insurmountable obstacle.

The Physical Trace Search

The first step is to establish a physical connection to the target device. This involves searching for test pads on the circuit board, which are usually arranged in groups of three or four pins. On the examined device (Image 1), there was a promising connection area for a four-pin connector located near an eMMC chip. Identifying the pins is a classic measurement process. Ground (GND) can be quickly determined using a continuity test against a known ground plane (e.g., a grounded screw or shielding). The supply voltage (V_CC) is often identifiable by a thicker trace leading away from the pin. In this case, the testing revealed: Pin 1 carries voltage, and Pin 4 is ground.

Signal Analysis on the Oscilloscope

To differentiate between TX and RX, an oscilloscope is the most efficient tool. Since the TX pin transmits data, it displays an irregular rectangular signal during the boot process. The RX pin, on the other hand, remains passive as it only waits for incoming data. Connecting the oscilloscope probe to pin 2 of the mysterious connector confirmed the data flow: Pin 2 is TX, and consequently, pin 3 is RX.

The next challenge is decoding the data. Since UART does not use a clock signal for synchronization, the baud rate must be known. This can be determined from the square wave signal: the smallest pulse (a single data bit) is measured. As shown in Image 2, the amplitude (ΔY) was approximately 3.3 V, which is a standard voltage for UART. The measured frequency (ΔX) was about 116,280 Hz. Considering standard baud rates, a target value of 115,200 baud was determined. With these parameters, a USB-to-UART adapter was connected to monitor the device's communication via a laptop.

The Security Barriers of the Firmware

After establishing the hardware connection, there’s initial disappointment: the device's boot messages do not lead to a shell prompt or an interactive interface. A standard attack involves interrupting the automatic boot process with keyboard combinations like Ctrl+C to access the bootloader's configuration environment. Here, boot parameters could be modified to make the system launch an interactive shell (/bin/sh) instead of the standard script. However, the examined device was protected against such attempts.

The analysis of the boot messages (Image 4) revealed two key security mechanisms:

• bootdelay = -3: This value completely disables the time window for interrupting the boot process. Even massive data floods at the RX pin, a common trick to catch the boot process, prove ineffective here.
• bootstopkeysha256: Even with a successful interruption, the system requires a password. The corresponding password hash was output in the log. Although the password in this case was identified through brute-force as "password12345," the path for entry was blocked due to the missing boot delay.

Disrupting the eMMC Memory

When access is denied on the software level, manipulation must target the hardware level. A well-known method by Brad Dixon (Carve Systems) involves disrupting the firmware loading process by grounding the data line of the storage medium (in this case, the data0 pin of the eMMC) at the right moment [1]. The aim is to cause the system to abort the automatic boot process due to a read error, hoping it will fall back into a recovery bootloader shell.

Here too, the device's design proved resilient. Extensive validation checks were performed during booting:

• A Shmoo plot validation checked the functionality of the entire eMMC.
• Encryption certificates were read and verified.

Any error during these sensitive phases did not cause a fallback to a shell but instead led to an immediate system halt with the prompt: ERROR ### Please RESET the board ###. Precise timing was therefore crucial.

Automated Fault Injection

After closely examining the boot messages, an extremely short time window was identified between the completion of validation and the kernel's attempt to load the operating system. To precisely hit this window, a glitch pattern generator (Keysight DS1180A) was used [2]. This tool monitors the UART data stream in real-time. As soon as a predefined text phrase appears in the boot messages, the device automatically triggers a glitch (shorting the data0 line to ground). The standout feature: the timing is adjustable to within microsecond precision.

The analysis revealed that the time window during which the glitch can successfully stop the boot process without crashing the system is approximately four seconds. In the highly precise world of fault injection, where glitches often need to be set within nanoseconds between individual CPU instructions, this is an unusually long timeframe. Nevertheless, this automated trigger proved to be the key to success: the automatic boot process was interrupted, and access to the protected configuration was unlocked.

A Conclusion

The case highlights that UART interfaces remain vulnerable despite restrictive software configurations and password protection. The combination of classic signal analysis with an oscilloscope and modern fault injection demonstrates the limitations of purely software-based security concepts. For embedded system developers, this means that security must not only be addressed in the code but also through physical hardening of the hardware. This can be achieved, for example, by deactivating debug pins during mass production. (heh)

Sources

[1] How to Root an Embedded Linux with a Sewing Needle. (PDF).

[2] DS1180A Glitch Pattern Generator. Keysight.

*Ricky Lawshae is Principal Security Researcher at Keysight Technologies.