Abstract

Welcome to the first article of Pentest IoT 101. UART is a primary entry point on most embedded boards: often the first available access and the one that yields the greatest impact. This article covers UART from all angles and aims to guide you step by step — from the multimeter to obtaining a root shell when possible.

Aware that every board has its specifics, this publication is part of a series: short follow‑up articles will present alternative methods and practical techniques to obtain a console when countermeasures are in place.

Definition and principle of UART

UART (Universal Asynchronous Receiver/Transmitter) is a widely used asynchronous serial protocol, especially for embedded debugging. It transports a stream of bytes from point A to point B and is frequently found in SoCs (System on Chip). On many PCBs running embedded Linux, UART is the main — sometimes the only — way to retrieve logs in production.

It is a simple protocol generally wired on three lines: TX (transmit), RX (receive) and GND (common ground).

Figure 1 :

The TX line sends bytes from the device, the RX line receives bytes destined for the device. To communicate, connections are crossed: TX of the adapter → RX of the target, RX of the adapter → TX of the target (GND provides the common reference). Figure 2 :

UART operates without a dedicated clock: each byte is framed by a start bit and one or more stop bits, and may include a parity bit. Synchronization is done on the edges of these bits. Essential parameters to know are baud rate (e.g., 115200, 57600, 38400, 9600), number of data bits (usually 8), parity (none/even/odd) and number of stop bits.

What is it used for?

Almost every board has an accessible UART port. It is mainly used for debugging: retrieving system and application logs (boot, drivers, error messages…), and sometimes for obtaining an interactive console. For manufacturers, it’s an easy way to display the platform state. Frequently, the UART port is placed near the SoC/microcontroller to minimize interference and keep the signal clean.

Figure 3 :

In some cases, UART not only allows reading logs but also sending commands: enabling a mode, triggering an interaction, or even obtaining a shell (sometimes a U‑Boot console, sometimes a full Linux shell).

Identification on a PCB

Sometimes UART pins are obvious — silk‑screened TX / RX / GND — and spotted at a glance. Other times you must probe the board like a detective: look for clues, test, and verify relentlessly. Most of the time these pins are grouped in threes, but there’s no infallible rule — practice is the only teacher.

Figure 4 :

Below are three simple and inexpensive methods to locate them and, crucially, to distinguish TX from RX.

1. PCB: Static analysis of the printed circuit

Static analysis of the PCB is an important — sometimes unavoidable — phase. It allows precise identification of pads and traces linked to the SoC, locating pins likely to be UART ports and reducing the risk of mistakes when connecting.

To do this, you need the datasheets of the board’s components (or, more rarely, the whole board — spoiler: almost never the case). These documents give the pin mapping and functions, which helps locate the UART resource. Once pins are identified, you can verify or trace connections with a multimeter set to continuity test to confirm the link between pads and the SoC.

Figure 5 :

It can also help to take detailed photos to virtually reconstruct the PCB. A sharp, well‑lit photo imported into an image editor lets you follow traces visually and identify interesting zones or circuits without physically manipulating the board.

Figure 6 :

Yes, it’s long and sometimes tedious. But done well, this preparatory work strongly accelerates the next reverse‑engineering steps. On complex circuits (e.g., POS terminals) with many anti‑tamper mechanisms, it’s better to map and understand flows between CPU and flash before soldering, drilling or attempting risky manipulations.

Further reading

If PCB path reverse engineering interests you, read this article: https://www.pcb-hero.com/blogs/lickys-column/how-to-reverse-engineer-a-pcb-board-1 — it explains the steps to get clean, usable results.

2. Multimeter: Operating voltage

When pins are not silk‑screened or clearly identifiable, the multimeter becomes your best ally. The idea is simple: power the board and measure voltages on different pins. This often quickly reveals active UART lines.

In practice, at SoC boot, it outputs many boot logs — so the TX pin shows a voltage that oscillates between 0 V and 3.3 V (depending on logic level). You may observe an average or RMS voltage around Ueff = Um/√2, roughly 2.7 V, indicating transmission activity.

Figure 7 :

Conversely, the RX pin, waiting for input, usually remains stable (often near 0 V) since it has not yet received any signal.

Figure 8 :

This basic method is quick and effective to differentiate UART pins. By observing electrical behavior you can identify TX (variable signal) and RX (stable) without special equipment.

3. Logic analyzer: Behavioral analysis

When pin identification is unclear or the multimeter is insufficient, analyze pin behavior over time with a logic analyzer. This tool captures signals on several pins simultaneously and visualizes pulses, transitions and repetitive patterns. It highlights characteristic behaviors of communication protocols like UART, SPI, I²C, etc.

There are many logic analyzers available, from compact affordable modules to high‑end professional units. I personally use a small 24 MHz 8‑channel logic analyzer for simple tasks and an LA1010 (1 000 MHz, 16 channels) when higher precision is required. Don’t buy top gear immediately: start with a model suited to your needs and upgrade if project complexity demands it.

Figure 9 :

On the software side, Sigrok is a reference. Download the AppImage, make it executable and run it: Sigrok usually detects the device automatically and configures it to capture the signal.

Figure 10 :

With the hardware ready, clicking “Record” produces a graph with useful information:

1. Estimated baud rate by measuring bit durations.
2. Confirmation of a UART port thanks to the start/data/stop pattern.
3. Distinction of pin roles: TX shows visible transitions, RX stays idle until transmission.

Figure 11 :

Graph analysis also reveals interference, anomalies or protections on the line, helping to understand flows between SoC and peripherals and securing later reverse steps.

Exploiting UART

To use UART from a modern computer, you must use a USB ↔ UART adapter. These adapters convert the PC’s USB signal to TTL serial compatible with the target board (often 3.3 V or 5 V), and vice versa. Without an adapter you cannot directly connect a PC to UART pins; connecting an RS‑232 port directly may damage the board.

In our context the adapter allows to:

• Receive data emitted by the board (logs, boot messages, prompts).
• Send commands or interact with the microcontroller if the console is active.

Figure 12 : Figure 13 :

Common adapter chips include FTDI, CH340, CP2102… For beginners, a simple reliable adapter is enough. I’ve used the same model for six years that cost under €10 and it helped me make many discoveries.

Wiring the converter

Wiring is simple but must be done carefully:

• Cross the lines: TX of adapter → RX of target, RX of adapter → TX of target.
• Connect grounds: GND ↔ GND.

Figure 14 : Crossed wiring of the converter

Watch the voltages!

Most embedded boards expect TTL 3.3 V; applying high voltages (±12 V) can damage the target (and end the pentest :().

Configuration and client (baud rate, framing)

After wiring, select the correct baud rate and framing (often 8 bits, no parity, 1 stop bit — 8N1).

• If a logic analyzer was used earlier, you can often estimate the baud directly.
• Otherwise, try common speeds: 115200, 57600, 38400, 9600, etc. There’s no universal method — typically a progressive sweep finds the right speed.
• Use tools like minicom, picocom or screen on Linux to open the port.

Useful tool

I developed a CLI tool to automate baud scanning and identify the best rate faster.

Road To Shell!

With correct parameters, logs should appear (bootloader, kernel, application messages). Depending on the target, you may see:

• boot messages (U‑Boot, proprietary bootloader),
• system/driver logs,
• sometimes an interactive console (prompt), offering interaction or administration options.

In most cases UART remains exploitable and provides valuable information. However, countermeasures are often present to limit access or protect sensitive data. Common protections include:

• Password‑protected console or redirection via an intermediate device.
• Signal filtering or encryption by a hardware component (e.g., FPGA, intermediate MCU) to prevent direct reading.
• Anti‑tampering protections on sensitive targets (POS, industrial gear, medical systems), sometimes combined with physical locks or lid‑open detectors.
• Temporary or selective disabling of the UART port depending on system or firmware state.

These protections don’t make exploitation impossible but require adapted methods. That’s why I cover them individually in short mini‑articles, presenting quick tips and techniques I use to bypass them and ultimately get my little root shell :D