Building a hardware security research bench

Many security assessments of routers, cameras, industrial controllers and other embedded devices eventually leave the network and reach the circuit board. Debug interfaces left enabled in production, unencrypted firmware in external flash and verbose boot consoles are among the most common findings. They are also some of the easiest to fix once a vendor knows about them.

This guide describes a practical bench for assessing devices you own or are authorized to test, with the purpose of finding and fixing weaknesses. It focuses on equipment and methodology, not on attacking specific products.

Ground rules

• Authorization and scope. Written permission for anything you do not own; respect coordinated disclosure when you find vulnerabilities.
• Electrical safety. Never probe mains-powered boards while connected to mains; use an isolation transformer or, better, power the logic side from a bench supply. Capacitors in power supplies can hold dangerous charge.
• ESD protection. An anti-static mat and wrist strap protect the device under test and your own equipment.
• Documentation. Photograph the board before and after every change and keep a lab notebook.

Core equipment

Buy quality where it protects you or the board (probes, power supply, soldering station) and save money on the rest.

Finding and using a UART console

Serial consoles are the most common debug interface on embedded Linux devices. A typical workflow:

1. Locate candidate headers: groups of three to four pins or pads near the SoC, often labeled TX, RX, GND, VCC, or unlabeled.
2. Find ground with continuity to a known ground (shielding, USB shell).
3. Measure voltages at power-up. VCC is steady; TX from the device typically sits at logic high and fluctuates during boot output. Note whether logic is 3.3 V or 1.8 V.
4. Confirm with a logic analyzer and measure the shortest bit width to estimate the baud rate (115200 is common).
5. Connect TX to RX, RX to TX, GND to GND. Do not connect VCC from the adapter; the board powers itself. Make sure the adapter's logic level matches.

# Linux: find the adapter, then open a console at 115200 baud, 8N1
dmesg | grep tty
screen /dev/ttyUSB0 115200
# or
picocom -b 115200 /dev/ttyUSB0

What you learn from a boot log is valuable for defenders too: bootloader versions, kernel command line, whether secure boot is enforced, and whether the console drops to an unauthenticated shell. An open root shell on the production console is a finding worth reporting.

Logic analyzers and protocol decoding

A logic analyzer samples digital lines and lets software decode protocols (UART, SPI, I2C, CAN, 1-Wire and more). The open-source sigrok project and its PulseView interface support many affordable analyzers as well as higher-end ones.

sigrok-cli --scan
# Capture 2 seconds on two channels at 24 MHz, decode UART on channel D0
sigrok-cli -d fx2lafw --config samplerate=24m --time 2s \
  -C D0,D1 -P uart:rx=D0:baudrate=115200 -A uart=rx-data

Selection criteria:

• Sample rate: at least four, ideally ten times the fastest signal you will decode.
• Voltage thresholds: 1.8 V logic is increasingly common; confirm the analyzer detects it reliably.
• Input protection: cheap analyzers can be damaged by overvoltage; buffered inputs are worth it.
• Streaming versus buffered capture: streaming depends on USB bandwidth, and long captures at high rates need onboard memory.

JTAG and SWD

JTAG (IEEE 1149.1) and Arm's two-wire Serial Wire Debug (SWD) give low-level access to processors: halting the CPU, reading memory and registers, and programming flash. On production devices they should be disabled or locked; checking that they are is a standard part of an assessment.

Common probes include SEGGER J-Link, ST-LINK, CMSIS-DAP probes, the Black Magic Probe and multi-protocol boards based on FTDI FT2232H/FT232H chips. OpenOCD is the usual open-source software layer:

# Example: connect to an STM32F1 target through an ST-LINK and open the telnet console
openocd -f interface/stlink.cfg -f target/stm32f1x.cfg
telnet localhost 4444
> halt
> flash info 0

If the connection fails with readout protection errors, that is the defense working. Report the protection level you observed, and do not attempt to bypass protections on devices outside your authorization.

Reading external flash

Many devices store firmware in an external SPI NOR flash (the common 8-pin SOIC chips). Reading it lets you review what the vendor ships: embedded credentials, outdated components, unsigned update mechanisms.

# Identify and read a SPI flash through a supported programmer
flashrom -p ch341a_spi
flashrom -p ch341a_spi -r firmware.bin
flashrom -p ch341a_spi -r firmware2.bin && sha256sum firmware.bin firmware2.bin   # read twice, compare
binwalk firmware.bin

Check the flash voltage from its datasheet first. Some inexpensive CH341A-based programmers are known to drive 5 V on data lines, which can damage 3.3 V or 1.8 V chips; use a revision with correct level shifting or a 1.8 V adapter. In-circuit reading with a test clip may back-power the whole board; if readings are unstable, lift the chip or hold the SoC in reset.

What defenders should take from this

Every tool above maps to a hardening control that manufacturers and integrators should verify before shipping:

Enterprises buying IoT and OT equipment can ask vendors directly about these controls, or include a bench assessment in procurement for critical devices.

A starter bench, in order of purchase

1. Multimeter, anti-static mat and wrist strap, basic hand tools and a set of jumper wires and test hooks.
2. USB-to-UART adapter with 3.3 V and 1.8 V support.
3. Sigrok-compatible logic analyzer (8 channels, 24 MS/s is enough to start).
4. Adjustable bench power supply with current limiting.
5. JTAG/SWD probe supported by OpenOCD.
6. SPI flash programmer with a proper level shifter and test clips.
7. Soldering station, then an oscilloscope once you need to see analog behavior.

Build up gradually, around the devices you actually need to assess.