Firmware-Extraktion: Was sie verrät und wie du sie verhinderst

Die erste Frage in fast jedem Hardware-Pentest lautet, ob sich die Firmware beschaffen lässt. Sobald ein Tester das Firmware-Image hat, lässt sich der Code lesen, fest einprogrammierte Schlüssel und versteckte Kommandos treten zutage, und der Rest der Prüfung wandert von der Werkbank an den Schreibtisch. Dieser Leitfaden erklärt die Wege, die es gibt, ungefähr in der Reihenfolge, in der ein Tester sie ausprobiert, und was ein Hersteller tun muss, um jeden davon zu schließen.

Warum das zählt

In der Firmware stecken die Geheimnisse: WLAN-Zugangsdaten, MQTT-Passwörter, Cloud-API-Schlüssel, Signaturschlüssel, Debug-Konten. In IoT-Tests von ESP32-basierten Kommunikationsmodulen haben wir wiederholt Broker-Zugangsdaten gefunden, die über die gesamte Flotte geteilt wurden. Ein einziges extrahiertes Image legt dann jedes Gerät im Feld offen. Der Cyber Resilience Act macht das zum Problem des Herstellers: Anhang I, Teil I verlangt den Schutz gespeicherter Daten und der Integrität des Produkts, ein ungeschützter Flash-Chip ist also ein Compliance-Finding und nicht nur ein technisches.

Die Wege, und was sie stoppt

Wir arbeiten vom günstigsten zum aufwendigsten Weg und hören auf, sobald einer funktioniert.

Das Gerät gibt sie heraus. Oft liegt die Firmware dort, wo der Hersteller sie absichtlich hinlegt: als Update-Datei auf der Downloadseite, als Image in der Companion-App oder unter der URL, die das Gerät für ein Over-the-Air-Update abruft. Ist dieses Update ohne Signatur ausgeliefert, lässt sich auf demselben Weg veränderte Firmware aufspielen. Die Abhilfe sind signierte, verschlüsselte Update-Pakete und ein Server, der niemals ein unverschlüsseltes Image ausliefert.

Eine Debug-Konsole ist offen. Eine serielle Konsole (UART), die in eine Shell fällt, oder ein Bootloader, der Kommandos annimmt, ist weiterhin der häufigste Weg hinein. Die Abhilfe ist, die Konsole in der Produktion abzuschalten oder mit Authentifizierung zu sperren und Bootloader-Kommandos zu entfernen, die Speicher ausgeben.

On-Chip-Debug ist aktiv. JTAG und SWD geben direkten Zugriff auf Speicher und CPU. Auf vielen Chips bleiben diese Ports in ausgelieferten Produkten aktiv. Die Abhilfe ist, die passende eFuse zu brennen und die Debug-Schnittstelle abzuschalten, bevor das Gerät die Fabrik verlässt.

Der Flash wird direkt gelesen. Sind die Ports geschlossen, lässt sich der externe Flash-Chip trotzdem selbst auslesen. Die einzige echte Verteidigung ist hier eine Flash-Verschlüsselung, die an einen im Chip gehaltenen Schlüssel gebunden ist, sodass ein ausgelesenes Image für sich genommen wertlos bleibt.

Was wirklich hält

Drei Schutzmechanismen, zusammen gesetzt, machen die Extraktion ernsthaft schwer:

Schutz	Was er tut	Typischer Fehler
eFuse-abgeschaltetes Debug	Schaltet JTAG, SWD und serielle Konsole im Feld ab	Für den Service aktiv gelassen oder nur auf manchen Einheiten
Flash-Verschlüsselung	Macht ein ausgelesenes Image ohne den On-Chip-Schlüssel unlesbar	Schlüssel lesbar oder Entwicklungsmodus aktiv gelassen
Secure Boot	Verhindert, dass veränderte Firmware läuft	Signaturprüfung vorhanden, aber nicht erzwungen

Auf der ESP32-Familie heißt das zum Beispiel, die Flash-Verschlüsselung im Release-Modus (nicht im Entwicklungsmodus) und Secure Boot V2 zu aktivieren und danach zu prüfen, dass die eFuses tatsächlich gebrannt sind. Jeder dieser Schritte wird oft genug übersprungen, dass wir sie einzeln kontrollieren.

Was wir in der Praxis sehen

Das Muster über Haushaltsgeräte- und IoT-Projekte hinweg ist gleichbleibend. Debug-Ports bleiben für das Service-Team offen. Die Flash-Verschlüsselung läuft im Entwicklungsmodus, was den Schlüssel wiederherstellbar lässt. Secure Boot ist konfiguriert, die Prüfung wird aber nie erzwungen, sodass unsignierte Firmware trotzdem läuft. Jeder dieser Punkte macht aus einem tagelangen Aufwand einen minutenlangen. Bei Haushalts- und Medizingeräten haben wir Herstellern geholfen, genau diese Lücken mit eFuse-Härtung und einem abgesicherten Produktions-Image zu schließen, sodass dasselbe Gerät, das seine Firmware in der ersten Runde preisgab, im Retest hielt.

Was ein Hersteller tun sollte

• Entscheide, was die Firmware wert ist. Enthält sie flottenweite Zugangsdaten oder Signaturschlüssel, behandle die Extraktion als echte Bedrohung und plane alle drei Schutzmechanismen ein.
• Härte das Produktions-Image, nicht das Dev-Board. Die Einstellungen, die zählen (gebrannte eFuses, Release-Modus-Verschlüsselung, erzwungener Secure Boot), unterscheiden sich zwischen deiner Werkbank-Einheit und dem ausgelieferten Produkt.
• Rotiere Geheimnisse und binde sie pro Gerät. Selbst perfekter Hardware-Schutz versagt an dem Tag, an dem ein Image ausläuft, also sollte kein Geheimnis über die Flotte geteilt sein.
• Lass es testen. Ein Hardware-Pentest zeigt dir, wie weit ein motivierter Angreifer kommt, und liefert den Nachweis, den der CRA erwartet.

Zyberum testet IoT-Geräte, Module und Steuergeräte auf der Werkbank, immer mit schriftlicher Erlaubnis, und stellt keine Zertifikate oder Typgenehmigungen aus. Mehr dazu beim Hardware-Pentest, oder buch ein kostenloses Erstgespräch.