Firmware-Forensik: So untersuchst du einen unbekannten ESP32-Binary auf Hintertüren

---

Einleitung: Misstrauen ist der Anfang guter Sicherheit

Du hast ein günstiges IoT-Gerät im Internet bestellt. Eine smarte Steckdose, ein WiFi-Thermostat oder ein ESP32-Entwicklungsboard von einem No-Name-Hersteller. Die Hardware sieht solide aus, der Preis war verlockend – aber dann kommt der Gedanke: Was ist eigentlich auf dem Chip drauf?

Die Antwort lautet: Du weißt es nicht.

In einer Zeit, in der Lieferkettenangriffe zunehmen und selbst große Hersteller schon Malware in ihren Produkten ausgeliefert haben , ist blindes Vertrauen in fremde Firmware fahrlässig. Die gute Nachricht: Als Maker hast du die Werkzeuge und das Wissen, um selbst herauszufinden, was wirklich auf deinem ESP32 läuft.

Dieser Artikel ist ein praktischer Leitfaden für die Firmware-Forensik auf ESP32-Basis. Du lernst, wie du die Firmware aus einem unbekannten Gerät ausliest, sie analysierst, nach verdächtigen Mustern suchst und Hintertüren oder Schadcode identifizieren kannst. Wir bewegen uns dabei in der Grauzone zwischen legitimer Sicherheitsforschung und dem, was Angreifer tun – aber genau dieses Wissen macht den Unterschied.

Warnung vorab: Die hier beschriebenen Techniken sind für deine eigenen Geräte oder solche gedacht, die du untersuchen darfst. Das Umgehen von Sicherheitsmechanismen an fremden Geräten kann strafbar sein. Handle verantwortungsvoll.

---

I. Grundlagen: Was ist Firmware und wo versteckt sie sich?

1.1 Die Architektur des ESP32

Bevor wir mit der Forensik beginnen, müssen wir verstehen, wie ein ESP32 aufgebaut ist. Der Chip besteht aus mehreren Komponenten:

• Interner Speicher (ROM): Enthält den Bootloader von Espressif, ist fest verdrahtet und kann nicht verändert werden .
• Externer Flash-Speicher: Hier liegt die eigentliche Firmware. Meist ein SPI-Flash-Chip mit 4 MB bis 16 MB Größe.
• eFuses: Einmal programmierbare Speicherbereiche im Chip, die Sicherheitseinstellungen und Schlüssel enthalten .

Die Firmware, die wir untersuchen wollen, befindet sich auf dem externen Flash. Sie besteht aus mehreren Partitionen:

• Bootloader: Startet das System und führt erste Prüfungen durch
• Partitionstabelle: Definiert, wo welche Partitionen liegen
• Application (fab): Die Hauptanwendung
• OTA-Partitionen: Für Over-the-Air-Updates
• NVS (Non-Volatile Storage): Speicher für Konfigurationsdaten
• SPIFFS/LittleFS: Dateisysteme für Webseiten oder Konfigurationen

1.2 Der Angriffspfad: Wo lauern Gefahren?

Ein Angreifer, der Schadcode in ein Gerät einschleusen will, hat mehrere Möglichkeiten:

1. Direkte Manipulation der Firmware vor der Auslieferung (Supply-Chain-Angriff) 
2. Nachträgliches Eindringen über eine Schwachstelle und dauerhafte Installation
3. Bereits im Werk eingespielte Hintertüren (besonders bei Billigprodukten aus nicht vertrauenswürdigen Quellen)

Die Forensik zielt darauf ab, solche Manipulationen zu erkennen – egal, auf welchem Weg sie ins Gerät gelangt sind.

---

II. Phase 1: Firmware auslesen – Die Extraktion

Bevor wir analysieren können, müssen wir an die Firmware herankommen. Je nachdem, wie das Gerät geschützt ist, gibt es verschiedene Wege.

2.1 Der Normalfall: Lesen über UART / Serial

Bei den meisten ESP32-Entwicklungsboards und vielen einfachen IoT-Geräten ist der Zugang trivial:

Benötigte Hardware:

• USB-UART-Adapter (z.B. CP2102 oder CH340)
• Drei Jumper-Kabel

Vorgehen:

1. Pins identifizieren: Suche auf dem Board nach TX, RX, GND und VCC (meist 3,3V). Bei unbekannten Boards hilft ein Multimeter: GND erkennst du an der Verbindung zu großen Kupferflächen, VCC an der Spannung gegen GND.
2. Verbindung herstellen:
   • USB-UART TX → Board RX
   • USB-UART RX → Board TX
   • GND verbinden
3. esptool.py verwenden:

bash

# Installation
pip install esptool

# Flash-Inhalte anzeigen
esptool.py --port /dev/ttyUSB0 flash_id

# Kompletten Flash auslesen (bei 4MB)
esptool.py --port /dev/ttyUSB0 read_flash 0x0 0x400000 firmware_dump.bin

Der Parameter 0x400000 steht für 4 MB (4 × 1024 × 1024). Passe die Größe an deinen Flash an.

2.2 Der schwierigere Fall: JTAG/SWD und Schutzmaßnahmen

Moderne Geräte haben oft Sicherheitsvorkehrungen. Der ESP32 bietet zwei wichtige Schutzmechanismen:

• Secure Boot: Verhindert, dass nicht signierte Firmware ausgeführt wird 
• Flash Encryption: Verschlüsselt den Flash-Inhalt 

Wenn Flash Encryption aktiviert ist, nützt dir das direkte Auslesen wenig – du bekommst nur verschlüsselte Daten. Aber nicht alle Hersteller aktivieren diese Schutzmaßnahmen, und selbst wenn, gibt es manchmal Wege:

JTAG/SWD-Anschlüsse finden:
Viele Boards haben versteckte Testpunkte für JTAG (TMS, TCK, TDO, TDI). Mit einem Logic Analyzer kannst du während des Bootvorgangs nach Aktivität suchen. Ist JTAG nicht bewusst deaktiviert, kannst du darüber oft den Speicher auslesen .

Chip-off-Methode:
Als letzte Möglichkeit (und nur für hartnäckige Fälle) kann der Flash-Chip abgelötet und in einem programmer ausgelesen werden. Dabei fallen aber die eFuse-Schutzmechanismen des ESP32 weg – du bekommst dennoch nur verschlüsselte Daten, wenn Flash Encryption aktiv ist.

2.3 Fallback: Update-Dateien analysieren

Viele Geräte bieten Firmware-Updates zum Download an. Diese Dateien sind oft nichts anderes als vollständige Flash-Abbilder oder komprimierte Firmware-Pakete. Ein Blick auf die Support-Seite des Herstellers kann daher schon zum Ziel führen .

---

III. Phase 2: Den Dump verstehen – Formatanalyse

Du hast eine Datei firmware_dump.bin. Was jetzt?

3.1 Erste Orientierung mit strings und binwalk

Die einfachsten Werkzeuge sind oft die nützlichsten:

bash

# Zeichenbare Strings extrahieren (ab 4 Zeichen Länge)
strings -n 8 firmware_dump.bin > strings.txt

# Damit nach verdächtigen Begriffen suchen
grep -i "password\|key\|secret\|backdoor\|telnet\|root\|admin" strings.txt
grep -i "http\|192.168\|10.0\|socket\|connect" strings.txt

Binwalk ist das Schweizer Taschenmesser der Firmware-Analyse:

bash

# Analyse des Dumps
binwalk firmware_dump.bin

# Entropie-Analyse (erkennt verschlüsselte/komprimierte Bereiche)
binwalk -E firmware_dump.bin

# Automatisches Extrahieren gefundener Dateisysteme
binwalk -e firmware_dump.bin

Die Entropie-Analyse ist besonders aufschlussreich: Ein flacher Verlauf um 0,5–0,8 deutet auf normalen Code hin, ein Wert nahe 1,0 auf Verschlüsselung oder Kompression . Plötzliche Sprünge zeigen Grenzen zwischen verschiedenen Datentypen.

3.2 Partitionstabelle rekonstruieren

ESP32-Firmware folgt einer bestimmten Struktur. Die Partitionstabelle liegt normalerweise bei 0x8000:

bash

# Partitionstabelle ansehen
dd if=firmware_dump.bin of=partition_table.bin bs=1 skip=$((0x8000)) count=$((0x1000))
strings partition_table.bin

Eine typische Partitionstabelle (CSV-Format im Binärbild) enthält Einträge wie:

text

nvs,      data, nvs,     0x9000, 0x6000,
phy_init, data, phy,     0xf000, 0x1000,
factory,  app,  factory, 0x10000, 0x200000,

Damit wissen wir, wo die eigentliche Anwendung beginnt (oft bei 0x10000).

3.3 Bootloader extrahieren

Der Bootloader liegt bei 0x1000:

bash

dd if=firmware_dump.bin of=bootloader.bin bs=1 skip=$((0x1000)) count=$((0x7000))

Ein signierter Bootloader (Secure Boot V2) erkennst du an einem RSA-Signatur-Block am Ende .

---

IV. Phase 3: Tiefenanalyse – Reverse Engineering

Jetzt wird es spannend. Wir haben die Anwendungsfirmware extrahiert und wollen wissen, was sie wirklich tut.

4.1 Architektur identifizieren

Der ESP32 nutzt einen Xtensa-LX6-Prozessor. Für das Reverse Engineering brauchen wir Disassembler, die diesen Befehlssatz verstehen:

• Ghidra (mit Xtensa-Plugin): Kostenlos, mächtig, von der NSA entwickelt
• IDA Pro (kommerziell): Der Industriestandard
• Radare2 / Cutter: Open-Source, kommandozeilentauglich

In Ghidra: Lege ein neues Projekt an, importiere die Firmware-Datei und wähle als Architecture „Xtensa“ (nach Installation des Plugins).

4.2 Nach bekannten Schwachstellen suchen

4.2.1 Harte Kodierung von Zugangsdaten

Der Klassiker: In vielen IoT-Geräten finden sich hart kodierte Passwörter oder API-Keys:

bash

# Nach typischen Patterns suchen
strings firmware.bin | grep -E "pass|pwd|key|token|secret|admin"

In Ghidra: Suche nach Zeichenketten (Search → For Strings) und schaue, wo sie referenziert werden. Führt eine Zeichenkette in eine Funktion, die Verbindungen aufbaut, ist das verdächtig.

4.2.2 Versteckte Zugänge (Backdoors)

Manche Hersteller lassen bewusst Hintertüren für den Support – oder Angreifer schleusen sie ein. Typische Anzeichen:

• Telnet-Server: Suche nach telnetd, busybox telnet oder bind(23
• Ungewöhnliche offene Ports: socket(), bind() mit Portnummern > 1024
• Spezielle „magische“ Pakete: Funktionen, die auf bestimmte Befehlssequenzen reagieren

Ein Beispiel: Eine Funktion, die einen UDP-Socket öffnet und eingehende Pakete auf einen bestimmten Magic-Wert prüft:

c

// Pseudocode aus Ghidra
if (udp_data[0] == 0xDE && udp_data[1] == 0xAD && udp_data[2] == 0xBE && udp_data[3] == 0xEF) {
    execute_shell_command(udp_data+4);
}

4.2.3 Unsichere Update-Mechanismen

Eine der gefährlichsten Schwachstellen: Wie werden Updates eingespielt?

Suche nach Funktionen, die mit OTA (Over-the-Air) zu tun haben:

• esp_ota_begin(), esp_ota_write(), esp_ota_end() 
• HTTP-Clients ohne SSL (erkennbar an http:// statt https://)
• Fehlende Signaturprüfung (kein Aufruf von esp_secure_boot_verify_signature())

Wenn die Firmware Updates per HTTP lädt und nicht auf Signaturen prüft, kann jeder im selben Netzwerk Schadcode einspielen.

4.3 Dynamische Analyse im Emulator

Manchmal verrät ein Programm sein Verhalten erst, wenn es läuft. Mit Emulatoren können wir die Firmware ausführen, ohne sie auf echte Hardware zu spielen.

QEMU für Xtensa:

bash

# Emulation starten (vereinfacht)
qemu-system-xtensa -cpu esp32 -machine esp32 -kernel firmware.bin -nographic

Firmadyne / FirmAE:
Diese Frameworks emulieren komplette Linux-Firmware für IoT-Geräte – nützlich, wenn der ESP32 mit einem Linux-System (wie OpenWrt) läuft .

4.4 Statistische Analyse: Was ist ungewöhnlich?

4.4.1 Code-Abweichungen

Vergleiche den extrahierten Code mit bekannten sauberen Versionen:

bash

# Bei Open-Source-Projekten: Mit git vergleichen
git clone https://github.com/example/project
objdump -d original.elf > original.asm
objdump -d extracted.elf > extracted.asm
meld original.asm extracted.asm

4.4.2 Ungewöhnliche Funktionsnamen

In Ghidra: Exportiere die Liste aller Funktionen. Suche nach:

• Namen mit backdoor, debug, test, hidden
• Kryptische Namen wie f_12345678 (könnten verschleierter Code sein)
• Sehr viele kleine Funktionen (möglicherweise obfuskierter Code)

4.4.3 Signaturerkennung mit YARA

YARA-Regeln können nach bekannten Malware-Mustern suchen:

yara

rule ESP32_Backdoor {
    meta:
        description = "Erkennt eine bekannte ESP32-Backdoor"
    strings:
        $s1 = "telnetd -l /bin/sh" wide ascii
        $s2 = "open backdoor port" wide ascii
        $s3 = { 6a 02 6a 01 6a 06 6a 00 }  # socketcall syscall sequence
    condition:
        any of them
}

Anwendung:

bash

yara esp32_rules.yara firmware.bin

---

V. Phase 4: Netzwerkverhalten analysieren

Die Firmware allein verrät nicht alles. Was das Gerät tatsächlich tut, zeigt sich oft erst im Netzwerkverkehr.

5.1 Verkehr im Labor aufzeichnen

Aufbau:

• Das Gerät in ein isoliertes WLAN stecken
• Einen Laptop mit Wireshark im Monitor-Modus verwenden
• Allen Verkehr aufzeichnen

Worauf achten:

• Ungewöhnliche Ziele: Verbindungen zu IPs in Ländern, die nichts mit dem Hersteller zu tun haben
• DNS-Anfragen: Fragt das Gerät nach Domain-Nach hause“?
• Periodische Beaconing: Sendet es regelmäßig kleine Pakete an eine externe IP?
• Unverschlüsselte Daten: Werden Sensordaten oder gar Passwörter im Klartext übertragen?

5.2 Firmware-Updates mitschneiden

Wenn das Gerät ein Update durchführt, kannst du die heruntergeladene Datei mit Wireshark mitschneiden:

bash

# In Wireshark: File → Export Objects → HTTP
# Zeigt alle über HTTP übertragenen Dateien an

Diese Update-Datei kannst du dann separat analysieren – vielleicht ist sie weniger geschützt als die ursprüngliche Firmware.

---

VI. Praktisches Beispiel: Eine verdächtige smarte Steckdose

Nehmen wir ein konkretes Szenario: Du hast eine günstige WLAN-Steckdose gekauft und willst wissen, ob sie sicher ist.

Schritt 1: Auslesen

text

esptool.py --port /dev/ttyUSB0 read_flash 0x0 0x400000 steckdose.bin

Schritt 2: Strings extrahieren

text

strings -n 8 steckdose.bin | grep -i "cloud\|api\|token\|password"

Fundstelle: api.verdaechtiger-server.com und Authorization: Bearer 4e6f72446120697374206469652057656872

Schritt 3: Binwalk-Analyse

text

binwalk steckdose.bin

Ergebnis: Eine LZMA-komprimierte Partition bei 0x110000.

Schritt 4: Entropie-Prüfung

text

binwalk -E steckdose.bin

Die Entropie ist durchgängig hoch – ein Zeichen für Verschlüsselung oder Kompression. Aber der Bereich um 0x9000 hat niedrige Entropie: Hier liegt die Partitionstabelle im Klartext.

Schritt 5: Partitionstabelle extrahieren

text

dd if=steckdose.bin of=ptable.bin bs=1 skip=$((0x8000)) count=$((0x1000))
strings ptable.bin

Wir finden: nvs, data, nvs, 0x9000, 0x4000 und factory, app, factory, 0x10000, 0x300000

Schritt 6: Firmware extrahieren

text

dd if=steckdose.bin of=firmware.bin bs=1 skip=$((0x10000)) count=$((0x300000))

Schritt 7: In Ghidra laden

• Neues Projekt anlegen
• firmware.bin importieren, Architecture „Xtensa“
• Analyse laufen lassen

Schritt 8: Nach Backdoors suchen

Suche nach socket und bind. Wir finden eine Funktion sub_40123456, die:

1. Einen UDP-Socket auf Port 8888 öffnet
2. Auf eingehende Pakete wartet
3. Wenn die ersten 4 Bytes 0xCAFEBABE sind, führt sie den Rest des Pakets als Befehl aus

Fund: Eine klassische Backdoor.

Schritt 9: Netzwerk-Test

Im isolierten Labor zeigt Wireshark: Die Steckdose kontaktiert regelmäßig update.verdaechtiger-server.com – über unverschlüsseltes HTTP.

Fazit: Das Gerät ist kompromittiert oder bewusst mit Hintertür ausgeliefert worden.

---

VII. Werkzeugkasten für die Firmware-Forensik

Unverzichtbare Tools

Werkzeug	Zweck	Installation
esptool.py	Flash auslesen/beschreiben	pip install esptool
binwalk	Firmware analysieren/extrahieren	sudo apt install binwalk
Ghidra	Reverse Engineering	ghidra-sre.org
strings	Text extrahieren	sudo apt install binutils
xxd	Hex-Dumps	sudo apt install xxd
hexdump	Alternative zu xxd	sudo apt install bsdmainutils
YARA	Mustererkennung	sudo apt install yara
Wireshark	Netzwerkanalyse	sudo apt install wireshark
radare2	Kommandozeilen-Disassembler	sudo apt install radare2

Nützliche Zusätze

• cwe_checker : Prüft auf bekannte Schwachstellenmuster
• Firmadyne : Emulation ganzer Firmware-Images
• QEMU : Emulation einzelner Binaries
• checksec : Prüft Sicherheitsmechanismen von Binaries

---

VIII. Grenzen und Herausforderungen

8.1 Verschlüsselte Firmware

Wenn Flash Encryption aktiviert ist, bekommst du nur Kauderwelsch. Ohne den Schlüssel (in den eFuses) ist eine Analyse unmöglich . Einzige Chance: Ein bekanntes Schwachstelle im Bootrom, die den Schlüssel preisgibt – aber das ist selten.

8.2 Signierte Firmware

Secure Boot verhindert, dass manipulierte Firmware läuft . Für die Forensik ist das aber kein Hindernis – wir wollen ja nur lesen, nicht schreiben.

8.3 Obfuskation

Manche Hersteller verschleiern ihren Code absichtlich, um Reverse Engineering zu erschweren. Typische Methoden:

• Entfernen von Symbolen (haben wir sowieso)
• Kontrollfluss-Verschleierung (viele Sprünge, schwer zu folgen)
• String-Verschlüsselung (Strings sind nicht als solche erkennbar)

Hier hilft nur Geduld und Erfahrung – oder dynamische Analyse im Emulator.

8.4 Rechtliche Fallstricke

Das Umgehen von Schutzmechanismen kann gegen Gesetze verstoßen (z.B. §95c UrhG in Deutschland). Für Forschungszwecke gibt es Ausnahmen, aber informiere dich vorher. Und: Analysiere nur eigene Geräte oder solche, für die du die Erlaubnis hast.

---

IX. Prävention: Wie schütze ich meine eigenen Geräte?

Die andere Seite der Medaille: Wenn du eigene ESP32-Produkte entwickelst, solltest du die hier beschriebenen Angriffe kennen, um dich zu schützen:

1. Secure Boot aktivieren – verhindert, dass manipulierte Firmware läuft 
2. Flash Encryption einschalten – schützt vor Auslesen 
3. Signierte Updates – OTA nur mit Signaturprüfung 
4. JTAG/SWD deaktivieren – verhindert Debug-Zugriff
5. Keine hart kodierten Secrets – Nutze NVS-Partitionen mit Verschlüsselung
6. Regelmäßige Sicherheits-Updates – und Mechanismen, die sie erzwingen
7. Anti-Rollback – verhindert Rücksetzen auf alte, verwundbare Versionen 

Die Kombination aus Secure Boot und Flash Encryption bietet einen starken Schutz. Wie im vorherigen Artikel zur EMV gilt: Wer von Anfang an sicher entwickelt, spart sich später viel Ärger.

---

X. Fazit: Vertrauen ist gut, Kontrolle ist besser

Die Firmware-Forensik auf ESP32-Geräten ist keine Hexerei. Mit den richtigen Werkzeugen und etwas Geduld kannst du herausfinden, was ein unbekanntes Gerät wirklich tut. Die hier vorgestellten Methoden – vom Auslesen über die Analyse bis zur Netzwerkbeobachtung – geben dir die Kontrolle zurück.

Drei Dinge solltest du mitnehmen:

1. Jedes Gerät kann kompromittiert sein – besonders Billigware aus nicht vertrauenswürdigen Quellen.
2. Die Werkzeuge sind frei verfügbar – du brauchst kein teures Labor, nur einen Rechner und etwas Neugier.
3. Wissen schützt – wer die Angriffsvektoren kennt, kann sich besser verteidigen.

In einer Welt zunehmender Vernetzung ist die Fähigkeit, eigene Geräte zu prüfen, kein exotisches Hobby mehr, sondern eine grundlegende Kompetenz für jeden Maker. Also: Trau keinem Binary, den du nicht selbst gebaut hast – oder zumindest gründlich untersucht.

---

XI. Quellen und weiterführende Literatur

Fachartikel und Konferenzen

• Van Beijnum, Wilco: „Breaking and Remaking ESP32 Devices“ – OrangeCon 2025 
• MITRE ATT&CK: „Detection of Module Firmware (T0839)“ – ICS-Framework 
• SERMA Safety & Security: „Behind the Scenes of a Hardware Penetration Test“ – Blog-Serie 2025 

Online-Tutorials und Dokumentationen

• circuitlabs.net: „OTA Update Security for ESP32“ – Umfassende Anleitung zu signierten Updates 
• circuitlabs.net: „Secure Boot Implementation in ESP-IDF“ – Detaillierte Einführung in Secure Boot 
• Tarlogic: „OWASP FSTM, stage 3: Analyzing firmware“ – Methodik für Firmware-Analyse 
• CSDN: „安全启动+闪加密配置全流程“ – Chinesischsprachige, aber sehr technische Anleitung zu Secure Boot und Flash Encryption 

Akademische Arbeiten

• Segal et al.: „UEFI Memory Forensics: A Framework for UEFI Threat Analysis“ – arXiv 2025. Für PC-Firmware, aber die Methodik ist übertragbar 

Tools und Repositories

• Espressif: ESP-IDF Programming Guide – Offizielle Dokumentation zu Secure Boot und Flash Encryption
• Ghidra: Offizielle Website mit Xtensa-Plugin
• binwalk: GitHub-Repository
• YARA: Offizielle Dokumentation und Regeln

Universitäre Lehrmaterialien

• Universitatea Politehnica București: „Laborator 7: Secure Boot și Autentificarea Codului pentru Aplicații Mobile“ – Laborübungen zu Secure Boot auf ESP32 

---

Hinweis: Dieser Artikel dient Bildungszwecken und der Sicherheitsforschung. Die beschriebenen Techniken an Geräten anzuwenden, die dir nicht gehören, kann gegen Gesetze verstoßen. Handle verantwortungsvoll und im Rahmen der geltenden Rechtsordnung.