/attacking-hardware-interfaces

name: attacking-hardware-interfaces
description: Assess the physical attack surface of embedded devices — finding and using UART consoles, JTAG/SWD debug, and SPI/I2C flash; dumping firmware off-chip; triaging secure boot; and studying sub-GHz RF replay feasibility with an SDR. Use when you have physical access to a device or board, need to identify test pads and get a serial/root shell, want to read a flash chip with flashrom, or are evaluating a fixed- vs rolling-code radio in a shielded lab.
verified: 2026-08-07

Attacking Hardware Interfaces

Physical access changes the game: the debug ports, flash chips, and boot process the vendor assumed were private are all reachable. The work is finding the interfaces on the board, using them to reach a shell or dump the firmware, and judging whether the device's secure-boot and RF designs actually hold. Almost everything here needs the device in hand and permission to open it.

When to Use

• You have physical access to an embedded device or PCB and need to find its

debug/serial/flash interfaces

• Getting a UART console or root shell, interrupting a bootloader, or halting the

CPU over JTAG/SWD

• Dumping firmware off a SPI/I2C flash chip for analysis
• Triaging a secure-boot / chain-of-trust design for bypass feasibility
• Studying sub-GHz RF replay feasibility (fixed vs rolling code) in a lab

When NOT to Use

• **Analyzing firmware you already dumped** — extraction, filesystem carving,

binary analysis — is `analyzing-firmware-images`; this skill gets the bytes off the device and hands them there.

• **Wi-Fi attacks** — `attacking-wireless-networks`.
• **Bluetooth/BLE and NFC/RFID** specifically — `attacking-bluetooth-nfc`.
• **Reversing a specific binary** pulled from the device — `analyzing-binaries`.

Find the Interfaces

Boards expose more than they should through unlabeled test pads and headers:

• **UART.** The most common win — a serial console, often a bootloader prompt or

a root shell. Identify the four lines (TX, RX, GND, VCC) with a multimeter and a logic analyzer, then connect a **USB-TTL adapter** (FTDI/CP2102) and open the console with `screen`/`minicom`/`picocom`. Detect the baud rate (115200 is common) if it is not obvious.

• **JTAG / SWD.** Full debug access — halt the CPU, read/write memory and

registers, dump firmware, patch. Identify the pinout (a **JTAGulator** brute- forces it) and drive it with **OpenOCD** and an adapter (Bus Pirate, J-Link, Black Magic Probe).

• **SPI / I2C flash.** The firmware lives on an external flash chip you can read

directly — clip a **SOIC8** test clip on and dump with **flashrom** via a CH341A or Bus Pirate, in-circuit or after chip-off.

• **Logic analyzer** (Saleae, or sigrok/PulseView with cheap hardware) to

identify and decode any of the above when the protocol or pinout is unknown.

Turn an Interface Into Access

• **UART → shell.** Many devices drop straight to a root shell or an

authenticated console. If not, **interrupt the bootloader** (U-Boot often takes a keypress) to change the kernel command line — booting into single-user mode or spawning a shell (`init=/bin/sh`) is a frequent, high-impact bypass.

• **JTAG → firmware and control.** Halt and dump flash/RAM, read secrets, or

patch a check. JTAG left enabled on production is a full compromise of the device's software protections.

• **Flash dump → firmware.** A SPI dump *is* the firmware image; hand it to

`analyzing-firmware-images` for extraction and analysis. This path works even when UART and JTAG are locked.

Secure Boot and Fault Injection

Judge whether the chain of trust actually holds:

• **Chain of trust.** ROM verifies the bootloader, which verifies the kernel,

and so on. The break is usually an unverified link — an unsigned stage, a debug path, or a check that can be skipped.

• **Fuses / lock bits.** Whether JTAG-disable and secure-boot fuses are actually

blown on production units is a common oversight; an unblown fuse reopens the debug port.

• **Fault injection (glitching).** Voltage or clock glitches (ChipWhisperer-class

tooling) can skip a signature check or a comparison at the exact instruction. This is advanced and often the only route past a correctly-implemented secure boot; scope it as a feasibility study, not a guaranteed result.

RF Replay Feasibility (SDR)

For sub-GHz radios (remotes, sensors, alarms on ISM bands like 315/433/868/915 MHz):

• **Receive and analyze** with an **RTL-SDR** (receive-only) and **Universal

Radio Hacker** or GNU Radio — capture the signal, recover the modulation and encoding.

• **The security question is fixed vs rolling code.** A fixed code replays

trivially; a rolling code (KeeLoq-style) changes every press and resists naive replay. Determine which the target uses — that is the finding.

• **Transmitting** (with a HackRF or similar) is where the law lives: you may

only transmit in a **shielded enclosure / RF-isolated lab**, never over the air on bands you are not licensed for. Frame active RF work as a lab feasibility study, because you cannot confine a real transmission to the target.

Scope and Authorization

This skill assumes a device you own or are explicitly authorized to open and modify — opening hardware is destructive-adjacent and voids assumptions the owner may care about, so get that in scope in writing. Two hard edges:

• **RF transmission is regulated.** Receiving is generally passive; transmitting

on licensed or safety-critical bands is a legal matter and a safety one. Keep active RF in a shielded lab, and treat spectrum law as a constraint you do not argue with.

• **Physical modification can brick the device.** Chip-off, glitching, and

bootloader changes can be irreversible. Confirm the owner accepts that risk on the specific unit before you start.

Rationalizations to Reject

• **"No labeled debug header, so there's no debug access."** UART and JTAG live

on u