Embedded Systems Hacking Roadmap

Open the device and document every component of interest on the PCB.

• Review the internals - photograph and label all visible ICs
• Document part numbers, packages, and search for datasheets
• Look for development boards, user manuals, and errata documents
• Identify connections between components (traces, vias, test points)
• Note any debug headers or unpopulated pads

Determine what protocols are in use and how components communicate.

• Identify protocols and peripherals used by components of interest
• Build a block diagram of component communication
• Capture signals with a logic analyzer or oscilloscope
• Monitor voltage fluctuations with a multimeter
• Decode protocols using tools like PulseView/sigrok

Interface with identified components to extract or manipulate data.

• Determine if you can interface with identified components
• Identify existing tools to assist with analysis
• Extract flash chips via SPI, I2C, or parallel interfaces
• Connect to debug interfaces (UART, JTAG, SWD)
• Interpose and manipulate signal transmission between components

Modify data or system behavior to achieve your desired outcome.

• Analyze extracted firmware with tools like Ghidra and binwalk
• Modify firmware and reflash to the device
• Use fault injection to bypass security (voltage/clock glitching, EMFI)
• Introduce error states to modify target behavior
• Patch or backdoor firmware for persistence

Method 1: Logic Analyzer Measurement

Capture the UART signal and measure the width of the smallest pulse (one bit). The baud rate is 1 / bit_width. For example, a pulse width of ~8.68μs indicates 115200 baud.

Method 2: Common Baud Rates

Try standard rates in order: 115200, 9600, 57600, 38400, 19200. Most embedded devices use 115200 or 9600.

Method 3: PulseView Auto-detect

Use PulseView's UART decoder - it can often auto-detect the baud rate from captured signals.

# Calculate from pulse width measurement
# If smallest pulse = 8.68μs
baud = 1 / 0.00000868 = ~115200

Step 1: Visual Inspection

Look for unpopulated headers, test points labeled TCK/TMS/TDI/TDO, or 10/14/20 pin connectors. Check silkscreen for debug markings.

Step 2: Identify Ground and Power

Use a multimeter in continuity mode to find GND (connected to shield/ground plane) and VCC (typically 3.3V or 1.8V).

Step 3: Use JTAGenum or JTAGulator

Connect candidate pins to a JTAGenum device (Arduino-based) or JTAGulator. These tools brute-force pin combinations by looking for valid IDCODE responses.

# JTAG signals to identify:
TCK  - Test Clock (output from debugger)
TMS  - Test Mode Select (output)
TDI  - Test Data In (output)
TDO  - Test Data Out (input)
nTRST - Optional reset (output)

OpenOCD configs have three main components: interface, transport, and target.

# Example: STM32 with FT2232H adapter
# interface config
source [find interface/ftdi/ft2232h-module-swd.cfg]

# transport selection
transport select swd

# target config
source [find target/stm32f2x.cfg]

# adapter speed (kHz)
adapter speed 1000

For unsupported chips:

• Find a similar chip's config as a starting point
• Identify the CPU core (Cortex-M0/M3/M4, etc.)
• Set correct flash base address and size
• May need custom flash driver/algorithm

# Minimal custom target config
set CHIPNAME custom_chip
set WORKAREASIZE 0x4000

source [find target/swj-dp.tcl]
swj_newdap $CHIPNAME cpu -expected-id 0x2ba01477

target create $CHIPNAME.cpu cortex_m \
    -chain-position $CHIPNAME.cpu

SWD only requires two data pins (plus GND): SWDIO and SWCLK.

Step 1: Check Common Locations

• Near the microcontroller chip
• Unpopulated 4-6 pin headers
• Test points labeled SWD/SWDIO/SWCLK

Step 2: Identify Reset Pin

Find the reset pin (often labeled RST or nRST). Pulling it low should cause USB re-enumeration or visible device reset.

Step 3: Probe with OpenOCD

Try connecting candidate pins and running OpenOCD - it will report if it detects a valid SWD target.

# SWD pinout (4 pins minimum)
SWDIO  - Data I/O (bidirectional)
SWCLK  - Clock
GND    - Ground
VCC    - Target voltage reference (optional)

Option 1: In-Circuit Reading

Connect a programmer (Raspberry Pi, BusPirate, FT2232H) to the chip while it's soldered. May require holding the CPU in reset or powering down other components.

Option 2: Chip Removal

Desolder the chip with hot air and read it in a socket/clip. More reliable but requires rework skills.

# Using flashrom with Raspberry Pi SPI
flashrom -p linux_spi:dev=/dev/spidev0.0 -r firmware.bin

# With FT2232H
flashrom -p ft2232_spi:type=2232H -r firmware.bin

# Verify with multiple reads
flashrom -p linux_spi:dev=/dev/spidev0.0 -r fw2.bin
md5sum firmware.bin fw2.bin  # Should match!

Troubleshooting:

• Chip not detected? Check wiring and chip select line
• Garbage data? CPU may be interfering - hold in reset
• Inconsistent reads? Lower SPI speed or desolder chip

Step 1: Connect Probes

Identify the signals you want to capture (TX, RX, CLK, DATA, etc.) and connect logic analyzer channels. Always connect GND!

Step 2: Configure Capture

Set sample rate to at least 4x the expected signal frequency. For 115200 baud UART, use 1MHz+. For 10MHz SPI, use 40MHz+.

Step 3: Add Protocol Decoder

In PulseView, add a decoder matching your protocol (UART, SPI, I2C, JTAG) and configure parameters.

# Common PulseView decoders:
UART - Set baud rate, data bits, parity, stop bits
SPI  - Set CLK, MOSI, MISO, CS channels + polarity
I2C  - Set SDA and SCL channels
JTAG - Set TCK, TMS, TDI, TDO channels

Tools:

• PulseView/sigrok - Free, open-source, many protocol decoders
• Saleae Logic - Commercial, excellent UX
• FX2LA - Budget ~$10 analyzer, works with sigrok

Step 1: Initial Scan

# Scan for file signatures
binwalk firmware.bin

# Check entropy (find compressed/encrypted sections)
binwalk -E firmware.bin

Step 2: Extract Contents

# Extract all recognized files
binwalk -e firmware.bin

# Extract with Matryoshka mode (recursive)
binwalk -eM firmware.bin

Step 3: Explore Filesystem

# For SquashFS
unsquashfs filesystem.squashfs

# For JFFS2
jefferson filesystem.jffs2 -d output/

# For UBIFS
ubireader_extract_files firmware.ubi

Common Findings:

• Kernel images (uImage, zImage)
• Root filesystems (SquashFS, JFFS2, UBIFS)
• Bootloaders (U-Boot)
• Configuration data, certificates, keys

Step 1: Import the Binary

File → Import File. Select the correct processor architecture (ARM, MIPS, x86) and set the base address if known.

Step 2: Auto Analysis

Let Ghidra run auto-analysis. Enable all analyzers for initial pass. This finds functions, strings, and cross-references.

Step 3: Find Entry Points

• Check vector table (ARM: address 0x00000000 or 0x08000000)
• Search for strings ("main", "error", product name)
• Look at cross-references to hardware registers

For Embedded Firmware:

# Common ARM Cortex-M memory map
0x00000000 - Vector table / Flash alias
0x08000000 - Flash memory
0x20000000 - SRAM
0x40000000 - Peripherals

Visual Indicators:

• Headers/Test Points - Unpopulated pin headers, labeled vias
• Silk Screen Labels - TX, RX, GND, VCC, TCK, TMS, SWD, DBG
• Connector Patterns - 4-pin (UART/SWD), 10/14/20-pin (JTAG)

Electrical Testing:

# With multimeter:
1. Find GND (continuity to shield/ground plane)
2. Find VCC (steady 3.3V or 1.8V to GND)
3. UART TX often shows ~3.3V at idle
4. UART RX often pulled high or floating

Common Interfaces by Pin Count:

• 3-4 pins - UART (TX, RX, GND, VCC)
• 4-5 pins - SWD (SWDIO, SWCLK, GND, VCC, RST)
• 6 pins - SPI (CLK, MOSI, MISO, CS, GND, VCC)
• 10-20 pins - JTAG (TCK, TMS, TDI, TDO, RST, GND, VCC)

Essential Tools (~$100-200):

• Multimeter - Basic voltage/continuity testing
• Logic Analyzer - FX2LA ($10) or Saleae clone
• USB-UART Adapter - FTDI or CP2102 based
• Soldering Iron - Temperature controlled (Pinecil, TS100)
• Jumper Wires - Dupont connectors, test clips

Intermediate Tools (~$200-500):

• Raspberry Pi - SPI/I2C/UART/JTAG interface
• FT2232H Breakout - Multi-protocol adapter
• Hot Air Station - SMD rework (858D style)
• Adjustable Power Supply - Riden 6006 or similar
• Microscope - For PCB inspection

Advanced Tools (~$500+):

• Oscilloscope - Siglent/Rigol entry level
• ChipWhisperer - Fault injection platform
• JTAGulator - Pin discovery tool

Warning: Read protection bypass often requires advanced techniques and may be destructive. Always work on non-critical devices first.

Common Approaches:

• Voltage Glitching - Brief power drops during boot to skip security checks
• Clock Glitching - Inject extra clock cycles to skip instructions
• EMFI - Electromagnetic fault injection
• Debug Resurrection - Re-enable debug via glitch during RDP check

Required Equipment:

• ChipWhisperer or similar glitch platform
• Oscilloscope for power trace analysis
• Target board modifications (capacitor removal)

# General workflow:
1. Capture power traces during boot
2. Identify security check timing
3. Configure glitch parameters (width, offset)
4. Iterate until successful bypass
5. Extract firmware via debug interface

Step 1: Initial Analysis

# Look for magic bytes and patterns
hexdump -C firmware.bin | head -100
strings firmware.bin | grep -i "file\|name\|dir"

# Check entropy for compression
binwalk -E firmware.bin

Step 2: Identify Structure

• Look for repeating patterns (file headers)
• Find size fields (usually 2 or 4 bytes)
• Identify string tables or filename areas

Step 3: Use Kaitai Struct

Define the format declaratively and generate parsers:

meta:
  id: custom_fs
  endian: le
seq:
  - id: magic
    contents: "MYFS"
  - id: num_files
    type: u4
  - id: files
    type: file_entry
    repeat: expr
    repeat-expr: num_files