UART Header
A serial interface (TX/RX/GND) on a PCB that frequently exposes a device's debug console, boot log, or even an unauthenticated root shell, just three pins away.
A UART header is a serial interface (typically TX, RX, GND, and sometimes VCC) exposed on a PCB, usually as a row of pads or a pin header, that frequently reveals a device's debug console, boot log, or even an unauthenticated root shell. It is the same asynchronous serial link an FTDI or CP2102 adapter speaks, brought out for the manufacturer's own debugging and often left in place.
What it is
UART (Universal Asynchronous Receiver/Transmitter) is a two-wire, clockless serial link: one line for each direction (TX and RX), plus a shared GND. There is no clock wire, so both ends must agree on a baud rate and framing (almost always 8 data bits, no parity, 1 stop bit, "8N1"). Manufacturers route the SoC's debug UART to a header or a small cluster of test pads to flash and diagnose the board in the factory. On a finished product those points are frequently still connected, unlabelled but live.
Why it matters
UART is often the fastest win in hardware hacking. A live console streams the bootloader banner and the kernel log, which alone can leak the SoC model, the flash layout, and version strings. Better still, it frequently lets you interrupt the bootloader (U-Boot, for instance) to change boot arguments or drop to its command prompt, and on carelessly configured devices it lands you directly at a root shell with no password. None of that needs the flash desoldered.
How to find and use it
- Spot the header. Look for a row of 3 to 4 pads or holes near the SoC, often in a neat line, sometimes silkscreened
TX/RX/GNDorJ*/CON*. - Identify the pins. GND rings out to the ground plane with a multimeter (continuity to a shield or a large copper pour). TX is the pin that spits data on power-up: watch it on a logic analyzer or scope during boot; it is the one that toggles busily. RX is usually idle-high and takes no traffic until you type.
- Match the level. Most boards are 3.3V. Never feed 5V into a 3.3V RX line.
- Wire crossover and open a terminal:
# Adapter usually enumerates as ttyUSB0 (FTDI) or ttyUSB0/ttyACM0.
picocom -b 115200 /dev/ttyUSB0
screen /dev/ttyUSB0 115200
# Baud unknown? Sweep the common rates and watch for readable text.
for b in 115200 57600 38400 9600; do echo "== $b =="; timeout 3 picocom -qrb $b /dev/ttyUSB0; done
Readable boot text means the wiring and baud are right. Then power-cycle the board and mash a key to try to interrupt the bootloader, or wait for the login prompt.
Pitfalls
- TX/RX swap. The single most common failure: no output, or output only when you cross the two data wires. If it is silent, swap TX and RX.
- Wrong baud. Garbled but rhythmic output usually means the baud rate is off. Sweep the usual values.
- Level mismatch. 5V into a 3.3V pin can damage the SoC. Confirm the level first.
- Do not back-power. Leave VCC disconnected on a self-powered board; share only GND. A header with only three usable pins (TX/RX/GND) is normal, VCC is optional and often best skipped.
- RX not wired. Some vendors depopulate the RX line so the console is read-only. You can read the log but cannot type; that is a hardening choice, not a fault in your setup.