noorqureshi/security-skills/hardware-security

Hardware debug-interface triage (UART / JTAG / SWD)

When it applies

You have physical access to a device you own or are explicitly authorized to open — a router, IoT gadget, embedded controller, or a board pulled from a larger system — and you need console access or a firmware image. Hardware work is governed by the same envelope as everything else: load tradecraft-scope-roe first and confirm the physical device and the teardown itself are in scope.txt. Never open or probe a device that isn't yours or in writing.

Why it works

Vendors leave debug and factory-test interfaces on the board: a UART serial console for boot logs (often a root shell), and JTAG/SWD for chip-level debugging and memory readout. These ports bypass all software authentication on the running system — if you can electrically reach them and match the logic levels, the device talks to you. Bootloader consoles (U-Boot) additionally let you alter boot arguments or read flash before the OS locks anything down.

Method

1. Open, photograph, label. Photograph both board sides before touching anything; note

silkscreen near pad clusters: TX RX GND VCC (UART) and TDI TDO TCK TMS (JTAG), SWDIO/SWCLK (SWD). Mind ESD — ground yourself; default to read-only probing.

1. Identify the UART pinout with a multimeter, not guesses. Find GND (continuity to a shield or

ground pour), VCC (stable rail at power-on), TX (pulses during boot — confirm with a logic analyzer if ambiguous), RX (floating/pulled line next to TX). Measure the logic level first — 1.8 V, 3.3 V, or 5 V — and match your adapter to it before connecting anything.

1. Attach read-only first. Connect only GND + the board's TX to a USB-TTL adapter and watch the

boot log: screen /dev/ttyUSB0 115200 (or minicom). If the output is garbage, sweep common baud rates (9600/38400/57600/115200) until the log is legible; record the rate. Boot logs alone leak flash layout, kernel version, and often credentials.

1. Work the console. Many devices drop to a root shell with no password. Interrupt U-Boot at

the countdown (usually any key) and dump printenv — note the environment, but do not `saveenv` casually: a wrong write bricks the boot.

1. Probe JTAG/SWD if UART is dead or locked. With a J-Link or CMSIS-DAP adapter under OpenOCD,

enumerate the chain and read the IDCODE: openocd -f interface/jlink.cfg -f target/<chip>.cfg. A populated IDCODE means the debug port is live; an all-zeros/all-ones response means it's fused off or your wiring/level is wrong.

1. Extract flash for offline analysis. In-circuit SPI dumps with a cheap programmer:

flashrom -p ch341a_spi -r dump.bin (verify with a second dump and compare hashes). Immediately record shasum -a 256 dump.bin for evidence integrity, then hand the image to reverse-eng-firmware for extraction and analysis; individual binaries go to reverse-eng-binary-triage.

1. Assess secure-boot/encrypted-flash feasibility non-destructively first (signed-image checks

in the boot log, eFuse hints from JTAG behavior) before considering chip-off or glitching — those are destructive and need explicit sign-off.

Gotchas

• Wrong logic level kills ports. Connecting a 5 V adapter to a 1.8 V UART can destroy the SoC

pins. Measure first; use a level shifter when in doubt.

• Garbage output ≠ no console — it's usually the wrong baud rate. Sweep before concluding the

port is mute. Truly silent UARTs may be disabled in firmware; fall back to JTAG.

• TX/RX are named from the board's perspective — your adapter's RX listens to the board's TX.

Read-only logging only needs GND + board TX.

• A locked JTAG (empty IDCODE) is a finding too — it tells you the vendor spent effort on

debug-lockout, which shapes the rest of the assessment (chip-off vs. software attack surface).

• Every write is a bricking risk. saveenv, flash erase/program, and eFuse operations are

one-way doors; get explicit approval and a verified dump before any of them.

Verify success

You have a labeled pinout photo with measured logic levels, the recorded baud rate, and at least one of: a working console (shell or U-Boot prompt), a live JTAG/SWD chain (valid IDCODE), or a SHA256-hashed flash dump ready for reverse-eng-firmware. If everything is locked, you can state precisely which interfaces exist and how each is disabled — that negative result is deliverable.

References

OpenOCD and flashrom documentation; reverse-eng-firmware for what to do with the dump.

_Portions adapted from reverse-skill by zhaoxuya520, MIT License._