SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsre-hardware-io

re-hardware-io

Security & auditing

View repository

Updated 10-15 21:34

About this skill

Hardware interfaces (JTAG / UART / Flash readout)

When to use / when not to use

  • Use: you have a physical board and need to extract firmware, capture boot logs, or do hardware debugging
  • Use: JTAG/SWD debugging, UART serial port, direct flash chip readout, logic analyzer signal capture
  • Don't use: you only have a firmware file (go to [[re-fw-extract]]; hardware extraction is a last resort)
  • Don't use: the rootfs is already extracted and you only need static analysis (go to [[re-fw-rootfs]])
  • Don't use: you need to run the firmware (try [[re-fw-emulate]] first; it's safer and cheaper)

Tool preparation

Verify every tool before use. Hardware operations are high-risk: first use a multimeter to check voltage levels, ensure common ground, and verify silkscreen markings before applying power (see pitfalls 3/4). Follow [[re-analyze/platform-tips]] and start with the lightest feasible approach: only move to hardware after software methods (file → unpack → emulate) are exhausted.

openocd —— JTAG/SWD debugging

  • Linux: apt install openocd / dnf install openocd / pacman -S openocd
  • macOS: brew install openocd
  • Windows: choco install openocd(or the official Windows build)
  • Verify: openocd --version

picocom / minicom —— serial terminal

  • Linux: apt install picocom(or apt install minicom）/ dnf install picocom / pacman -S picocom
  • macOS: brew install picocom
  • Windows: choco install putty(PuTTY supports serial) or the Linux version inside WSL
  • Verify: picocom --version

flashrom —— flash chip readout

  • Linux: apt install flashrom / dnf install flashrom / pacman -S flashrom
  • macOS: brew install flashrom
  • Windows: official build or WSL (the ch341a programmer uses flashrom -p ch341a_spi）
  • Verify: flashrom --version

Logic analyzer (sigrok-cli / pulseview)

  • Linux: apt install sigrok-cli pulseview / dnf install sigrok-cli pulseview / pacman -S sigrok-cli pulseview
  • macOS: brew install sigrok-cli pulseview
  • Windows: the official sigrok Windows installer (sigrok.org)
  • Verify: sigrok-cli --version / pulseview --version

JTAGulator —— pin identification board (open-source hardware)

  • Open-source hardware project git clone https://github.com/grandideastudio/JTAGulator(includes firmware and documentation); you need to buy/make your own JTAGulator board
  • Verify: after connecting the serial port, send help to display the command list
  • Use it to automatically enumerate UART/JTAG pins on an unknown board (a handy tool for steps 1/2)

Hardware purchasing guide (common options and voltage levels)

  • USB-UART adapter: CH340 / CP2102 / FTDI chip options are all fine; choose a model that supports 3.3V TTL levels (one with a 3.3V/5V jumper is more versatile) —— plugging 5V TTL into a 3.3V board will burn out the interface (see pitfall 3)
  • Debugger: ST-Link v2 (STM32 family, supports both SWD/JTAG), J-Link (general-purpose, paid license), CMSIS-DAP/DAPLink (open-source firmware option) —— choose according to the target chip vendor
  • SPI flash programmer: ch341a (the cheapest SOIC8 option) + clip/test socket; for multi-protocol needs use an RT809H-class programmer
  • Logic analyzer: choose the sample rate according to the signal rate —— for UART 115200 and low-speed SPI, an 8-channel 24MHz class is enough; high-speed SPI (tens of MHz) requires 100MHz+ sampling (rule of thumb: sample rate at least 4 times the signal rate)
  • Level shifting: when mixing 1.8V/2.5V boards with 3.3V tools, use a TXS0108-class bidirectional level shifter module

Operation steps

Execute in order, and record the result of each step.

  1. Board disassembly and interface location：
    • Open the case and inspect the PCB: silkscreen markings (TX/RX, VCC, GND, JTAG/SWD test points), pin headers, flash chip model (e.g. W25Q128, MX25L, GD25Q)
    • Multimeter: measure the supply voltage level (3.3V is common, but 5V / 1.8V also occurs), find GND; UART TX pin characteristic —— a square wave that is pulled high to logic high level at the moment of power-on
    • Take photos for the record: silkscreen markings, pin numbering, flash model, for later wiring verification
  2. UART serial debugging (baud rate enumeration)： 
    picocom -b 115200 /dev/ttyUSB0        # 先试 115200
# 乱码 → Ctrl+A Ctrl+X 退出，换 9600 / 57600 / 38400 / 19200 / 230400
# 或 minicom -D /dev/ttyUSB0
    • TX/RX must be cross-wired (board TX ↔ adapter RX); common ground is mandatory
    • Capture the boot log at the moment of power-on—it is the fastest way to understand the system (see Pitfall 4)
  3. JTAG/SWD connection (openocd)： 
    openocd -f interface/stlink.cfg -f target/stm32f1x.cfg   # ST-Link + SWD 示例
# 其他适配器在 /usr/share/openocd/scripts/interface/ 下选对应 cfg
    • Confirm the interface type (JTAG 4/5-wire vs SWD 2-wire) and voltage level (1.8V boards require a level adapter)
    • Once connected, halt halt, read registers, dump flash (flash read_bank 0 dump.bin）
    • One-line command mode (scriptable/non-interactive): openocd -f interface/stlink.cfg -f target/stm32f1x.cfg -c "init; halt; flash read_bank 0 dump.bin; exit"
  4. flash chip reading (flashrom/programmer)： 
    # 板载 SPI flash（linux_spi 需内核 spidev 支持）：
flashrom -p linux_spi:dev=/dev/spidev0.0 -r backup.bin
# 离线读取（ch341a 编程器 + SOIC8 夹子，先断电）：
flashrom -p ch341a_spi -r backup.bin
    • Verify the chip model and package (SOIC8 clip/test socket), and do not connect the pin orientation backwards
    • Convert the read image to [[re-fw-extract]] for unpacking
  5. Boot log capture：
    • Connect the serial port → power on the board → capture the full log (picocom output tee log.txt, or capture with minicom)
    • The log contains bootloader, kernel startup, filesystem mounting, and service autostart information; compare it with the startup scripts of [[re-fw-rootfs]] to locate issues
    • No UART output → return to step 1 and recheck the wiring/baud rate, or use a logic analyzer to capture the TX pin waveform for verification

Cross-domain combination

  • [[re-firmware]]: called by this skill at workflow step 5 (when physical hardware is needed)
  • Extracted flash image → [[re-fw-extract]] unpacking → [[re-fw-rootfs]] analysis; if running is needed → [[re-fw-emulate]]
  • Communication/protocols captured on hardware → [[re-protocol]]
  • Hardware extraction is the last resort for firmware analysis: only proceed after software methods (file → unpacking → emulation) are fully exhausted
  • Physical-layer chip/PCB analysis (decap/bare die/hardware trojan detection) → [[re-hw-chip]]

Common pitfalls and traps

  • Wrong baud rate → garbled text: Symptom—serial output is all garbled or absent; Cause—baud rate/data bits mismatch, TX/RX reversed; Countermeasure—enumerate 9600 / 115200 first (fall back to 57600 / 38400 / 230400), verify by observing the TX waveform with a logic analyzer, and common ground is mandatory
  • JTAG fused/locked: Symptom—openocd cannot connect, IDCODE is all 0 or times out; Cause—production boards have JTAG fused and read protection (RDP) enabled; Countermeasure—try SWD,stm32f1x unlock unlock sequences of that type, or abandon JTAG and switch to UART + direct flash reading (step 4)
  • 5V/3.3V level misconnection burns the board: Symptom—after wiring, the board heats up/smokes/is permanently damaged; Cause—level mismatch (connecting 5V TTL to a 3.3V board), incorrect power connection, VCC/GND reversed; Countermeasure—measure the level and GND with a multimeter before wiring; use a 3.3V adapter for 3.3V systems; never hot-plug
  • Look at the boot log before taking action: Symptom—blindly desoldering flash / connecting JTAG causes damage or data loss; Cause—skipping low-cost observation and going straight to hardware methods; Countermeasure—first capture the boot log via UART to understand the system (steps 2/5), then decide whether hardware reading is needed—this is the execution in the hardware domain of [[re-analyze/platform-tips]] giving the lightest feasible solution first
  • Intel DCI debugging toolchain compatibility pitfalls: Symptom—Intel System Studio 2019 (System Debugger) fails to install/run on Win10/11, and the DCI cable cannot connect to the CPU; Cause—the software was developed based on Win7 and includes environment checks and license validation: Win11 reports a missing Win7 security patch, and the public License file is invalid on the Windows version; Workaround—use compatibility mode for installation; for running, add --noprereq to skip the environment check; the core of license validation is in issa.dll exported functions (three validation functions); after patching, simply replace them; DCI configuration is selected by platform (e.g., KBL=Kaby Lake, SPT=200 series motherboard, DBC=Debug Class cable), and for CLI debugging use the DAL directory's PythonConsole.cmd(Python 2.7 environment,itp.cores/itp.halt() and other commands); the ME side requires UTOK unlocking before it responds to debug commands (see [[re-fw-extract]])
  • For the command family quick reference and operation sequence, see [[commands]]; for tool-specific pitfalls and version differences, see [[gotchas]]