Hardware Hacking: Attacking Embedded Systems and IoT Devices

Every device with a chip is a potential target. Routers, industrial controllers, smart home devices, ATMs, medical equipment, car infotainment systems — embedded systems are everywhere, and they are often running old software with no security updates. Hardware hacking involves physically interacting with a device to extract firmware, access debug interfaces, and find vulnerabilities that exist at the silicon level. This guide introduces the practical skills and tools of the hardware hacker.

Why Hardware Hacking Matters

When you compromise software, you depend on the software’s execution environment. When you compromise hardware, you own everything above it — operating system, applications, encryption keys, everything. Hardware vulnerabilities cannot be patched with a software update. They are often permanent. This is why hardware security is one of the most consequential areas of cybersecurity and one of the least well-understood.

The Essential Hardware Hacking Toolkit

  • Bus Pirate (~$30) — universal interface for I2C, SPI, UART, JTAG protocols
  • FTDI USB-to-UART adapter (~$5) — connect to serial debug ports on devices
  • Flashcat or CH341A programmer (~$15) — read/write SPI flash chips directly
  • Multimeter — identify voltage levels, find GND/VCC/TX/RX pins
  • Logic analyzer (Saleae or clone, ~$10–$400) — capture and decode digital signals
  • Soldering iron — attach wires to test points and debug pins
  • Binwalk — firmware extraction and analysis tool (software, free)

Finding and Accessing UART Debug Ports

UART (Universal Asynchronous Receiver/Transmitter) is a serial communication interface used extensively for debugging embedded systems. Most consumer routers have an unpopulated UART header that, when connected to, drops you straight into a root Linux shell during boot. Manufacturers often leave it in production devices to simplify factory testing.

# Step 1: Open the device. Look for unpopulated 4-pin or 3-pin headers on the PCB.
# UART typically has 4 pins: VCC (3.3V or 5V), GND, TX, RX

# Step 2: Identify pins with a multimeter:
# - GND: continuity with ground plane, 0V
# - VCC: constant 3.3V or 5V
# - TX (transmit): fluctuates during boot, this is data coming OUT of the device
# - RX (receive): this is data going INTO the device

# Step 3: Connect FTDI adapter:
# Device TX → FTDI RX
# Device RX → FTDI TX  (crossed!)
# Device GND → FTDI GND
# Do NOT connect VCC to FTDI (they have different voltage regulators)

# Step 4: Find the baud rate and connect:
screen /dev/ttyUSB0 115200  # most common baud rate
# Or use minicom:
minicom -D /dev/ttyUSB0 -b 115200

# If you see garbage characters, try other baud rates: 9600, 57600, 38400
# baudrate.py can auto-detect it from a logic analyzer capture

JTAG: Full Debug Access

JTAG (Joint Test Action Group) is a debug interface that gives you powerful control: read/write memory, halt execution, single-step instructions, and dump flash contents. It was designed for chip manufacturing tests but is left accessible on many production boards.

# Find JTAG pins with JTAGulator or by searching the device's FCC filing:
# FCC ID → fcc.io → Internal Photos often show PCB with labeled test points

# Use OpenOCD to interface with JTAG:
sudo apt-get install openocd

# openocd.cfg example for common ARM target:
source [find interface/ftdi/jtagkey.cfg]
source [find target/at91sam3ax_8x.cfg]

# Start OpenOCD:
openocd -f openocd.cfg

# Connect GDB to OpenOCD:
gdb-multiarch firmware.elf
(gdb) target extended-remote :3333
(gdb) monitor halt
(gdb) info registers
(gdb) x/32xw 0x20000000  # examine memory

Firmware Extraction and Analysis

# Method 1: Download from manufacturer website (easiest)
wget https://manufacturer.com/firmware/v2.1.bin

# Method 2: Intercept update via proxy (man-in-the-middle the firmware update)
# Configure device to use your proxy, capture firmware update traffic

# Method 3: Read flash chip directly with CH341A programmer
# Identify the SPI flash chip (usually Winbond W25Q or similar, 8-pin SOIC)
# Attach clip or desolder chip
# Read with flashrom:
flashrom -p ch341a_spi -r firmware_dump.bin

# Analyze firmware with Binwalk:
binwalk firmware_dump.bin
# Output shows file systems, compressed archives, kernel images embedded

# Extract everything:
binwalk --extract --matryoshka firmware_dump.bin
# Creates _firmware_dump.bin.extracted/ directory

# Examine the extracted filesystem:
ls _firmware_dump.bin.extracted/
# Often find: Linux rootfs, /etc/passwd, /etc/config files, web server files

What to Look for in Extracted Firmware

# 1. Default credentials
grep -r "admin|root|password|default" squashfs-root/etc/ 2>/dev/null

# 2. Hardcoded private keys (backdoor access)
find squashfs-root/ -name "*.pem" -o -name "*.key" -o -name "id_rsa" 2>/dev/null

# 3. Hardcoded API keys or tokens
grep -r "API_KEY|api_key|secret|token" squashfs-root/ 2>/dev/null

# 4. Backdoor accounts in /etc/passwd or /etc/shadow
cat squashfs-root/etc/passwd | grep -v "nologin|false"
# Any account with /bin/sh or /bin/bash without "nologin" could be a backdoor

# 5. Telnet/SSH server running (remote access enabled by default)
cat squashfs-root/etc/rc.d/ | grep -i "telnetd|sshd|dropbear"

# 6. Unsafe C functions (buffer overflow potential)
# Extract and analyze binaries with checksec:
find squashfs-root/ -executable -type f 2>/dev/null | xargs file | grep ELF | cut -d: -f1 | xargs checksec --file

Responsible Disclosure for Hardware Vulnerabilities

Hardware vulnerabilities in consumer products should be reported to the manufacturer through their security disclosure program (or via CERT/CC if they have none). Hardware vulnerabilities are often difficult or impossible to patch remotely — the manufacturer may need to issue replacement hardware, updated firmware, or end-of-life announcements. Give them adequate time (90 days is standard) before public disclosure. Documenting and disclosing these vulnerabilities is a genuine public service: it forces manufacturers to take embedded security seriously and helps consumers make informed purchasing decisions.