Hardware-Pentest: So läuft er ab, Schritt für Schritt

Ein Hardware-Penetrationstest stellt eine Frage: Was kann ein Angreifer mit dem Gerät auf dem Tisch erreichen, und was bedeutet das für alle anderen Geräte im Feld? Die Antwort entsteht in einer festen Abfolge von Schritten, vom Öffnen des Gehäuses bis zum Bericht mit Fixes. So läuft ein Hardware-Pentest bei Zyberum ab, mit den typischen Findings je Phase.

Schritt 0: Umfang und was wir von dir brauchen

Der Test beginnt mit einem Scoping-Gespräch und einer schriftlichen Erlaubnis. Wir legen das Ziel fest (das ganze Gerät, eine Platine, ein Controller), die Ziele (Firmware-Extraktion, Schlüssel auslesen, Secure Boot umgehen, lokaler Root), die Tiefe (Black Box oder mit Unterlagen) und welche Geräte zerstört werden dürfen.

Was wir brauchen	Warum
Zwei bis drei Geräte, idealerweise Serienhardware	Referenz, Vermessen, zerstörende Schritte
Schaltplan oder zumindest Blockdiagramm (Grey Box)	Testpunkte und Busse schneller finden
Firmware-Image und Update-Paket, falls vorhanden	Dump mit Build vergleichen, Update-Pfad testen
Zugang zu einem Testaccount im Backend oder in der App	Bewerten, was ein kompromittiertes Gerät erreicht
Ansprechpartner für Rückfragen während des Tests	Kein Raten über das gewollte Verhalten

Ein Hardware-Test dauert typischerweise fünf bis fünfzehn Tage, je nachdem, wie viele Schutzschichten das Gerät hat und wie tief die Firmware-Analyse geht.

Schritt 1: Teardown und Bauteilidentifikation

Der erste Tag gehört Schraubendreher, Kamera und Datenblättern. Wir öffnen das Gerät, fotografieren jede Platine, lesen die Beschriftung jedes Chips und schlagen nach, was er ist: der Haupt-SoC oder Mikrocontroller, externer Flash (SPI-NOR, NAND, eMMC), RAM, Funkmodule, Power-Management, ein eventuelles Secure Element. Daraus entsteht ein Bild, wo Code und Geheimnisse liegen können und welche Busse sie verbinden.

Typisches Finding in dieser Phase: eine bestückte, aber unbeschriftete Stiftleiste neben dem Hauptcontroller. Bei den meisten Consumer- und Industriegeräten, die wir sehen, ist das ein Debug-Port.

Schritt 2: Debug- und serielle Schnittstellen

Als Nächstes suchen und testen wir jede Schnittstelle, die für die Fertigung oder den Entwickler gedacht war: UART, JTAG, SWD, manchmal ein Hersteller-Bootloader-Modus über USB.

• UART. Ein Logikanalysator identifiziert Pins und Baudrate. Allein das Boot-Log verrät Bootloader, Kernel-Version und oft die Partitionierung. Eine Shell ohne Passwort oder mit Standardpasswort ist nach wie vor eines der häufigsten Findings in unseren Tests. Bei einem Gerät eines Haushaltsgeräteherstellers lieferte die serielle Konsole Root, bevor das Gerät fertig gebootet hatte.
• JTAG und SWD. Mit der Pinbelegung aus dem Datenblatt oder einem Pin-Finder versuchen wir, einen Debug-Adapter anzuschließen. Ist der Port offen, können wir die CPU anhalten, RAM und Flash lesen und eigenen Code schreiben. Geprüft wird hier, ob Lock-Bits, eFuses oder Debug-Authentifizierung in Seriengeräten tatsächlich gesetzt sind, nicht nur im Designdokument beschrieben.
• Bootloader-Modi. Viele Controller haben einen ROM-Bootloader auf UART oder USB (Download-Modus beim ESP32, Bootstrap-Loader bei TriCore/AURIX, DFU bei STM32). Ist er erreichbar und ungeschützt, lässt sich die Vertrauenskette umgehen, bevor sie beginnt.

Schritt 3: Firmware-Extraktion

Gibt kein Debug-Port die Firmware her, holen wir sie aus dem Speicher selbst. Nach Aufwand sortiert: den externen SPI-Flash mit einem Clip in der Schaltung auslesen, den Chip auslöten und im Programmiergerät lesen, eMMC über Testpunkte oder nach Chip-off auslesen oder das Image über einen verwundbaren Update-Mechanismus ziehen. Ist Flash-Verschlüsselung aktiv, wird zum Test, ob der Schlüssel geschützt ist oder in einer lesbaren eFuse liegt, und ob das entschlüsselte Image über einen Debug-Port im RAM erreichbar ist.

Für Steuergeräte gilt dieselbe Logik mit anderen Werkzeugen: Bei Leistungselektronik-Steuergeräten mit TriCore/AURIX-Controllern haben wir den Applikations-Flash über die Debug-Schnittstelle gelesen, weil der Ausleseschutz nicht aktiviert war, und das Reverse Engineering der Firmware erklärte danach jeden UDS-Dienst, den das Steuergerät anbot.

Schritt 4: Firmware-Analyse

Mit dem Image auf der Platte wandert die Arbeit an den Rechner. Wir entpacken Dateisysteme, identifizieren Betriebssystem und Bibliotheken, extrahieren Zertifikate, Schlüssel und Zugangsdaten und analysieren die Teile, die zählen: die Update-Prüfung, die Authentifizierung der lokalen und der Cloud-Schnittstelle, die Verarbeitung von Funkpaketen. Gefundene Geheimnisse prüfen wir darauf, was sie öffnen: Ein gemeinsamer API-Key bedeutet jedes Gerät im Feld, ein gerätespezifischer Schlüssel bedeutet ein Gerät.

Häufige Findings: ein privater Schlüssel für die Cloud-Verbindung, der in jedem Gerät gleich ist, fest kodierte Zugangsdaten für eine Wartungsschnittstelle, eine Update-Prüfung, die einen Hash vergleicht, aber keine Signatur, veraltete Bibliotheken mit bekannten CVEs.

Schritt 5: Schutzmechanismen

Jetzt testen wir die Mechanismen, die Schritt 2 bis 4 hätten verhindern sollen: Secure Boot, Flash-Verschlüsselung, eFuse-Konfiguration, Anti-Rollback, Debug-Authentifizierung. Die Frage ist nicht, ob sie existieren, sondern ob sie im Seriengerät aktiviert und vollständig sind. Die häufigste Lücke ist eine Secure-Boot-Kette, die Bootloader und Kernel prüft, aber nicht das Root-Dateisystem, oder eine eFuse, die geplant war, aber in der Fertigung nie gebrannt wurde. Bei hochwertigen Zielen ergänzen wir Fault Injection (Spannungs-Glitching), um zu sehen, ob sich ein einzelner Vergleich im Boot-ROM oder Bootloader überspringen lässt.

Schritt 6: Exploit-Ketten und Auswirkung

Einzelne Findings werden zu Ketten, die die echte Auswirkung zeigen: offener UART plus unverschlüsselter Flash ergibt den Cloud-Schlüssel für die ganze Flotte; offenes SWD plus gemeinsamer Schlüssel ergibt die Möglichkeit, jedes Gerät zu imitieren. Spricht das Gerät mit einem Backend oder einer App, testen wir im autorisierten Rahmen, was ein kompromittiertes Gerät dort erreicht. Hier geht der Hardware-Test in den IoT- oder Steuergeräte-Pentest über.

Schritt 7: Bericht und Retest

Der Bericht enthält jedes Finding mit CVSS-Score und Vektor, die Schritte zum Nachstellen, Fotos und Pinbelegungen sowie einen Fix, der zu deiner Hardware passt: welche eFuses zu brennen sind, wie die Konsole im Produktions-Image abgeschaltet wird, wie du von einem gemeinsamen zu gerätespezifischen Schlüsseln kommst, was an der Update-Prüfung zu ändern ist. Findings, die eine Hardware-Revision brauchen, sind als solche markiert, denn sie bestimmen die Roadmap. Nach den Fixes testen wir die betroffenen Findings an neuen Geräten nach.

Was ein Hardware-Test nicht leistet

Er zertifiziert nichts. Er liefert dir Belege dafür, was ein Angreifer mit physischem Zugriff erreicht und was zu ändern ist, und damit genau die Nachweise, die EN 18031, der Cyber Resilience Act und der OWASP ISTG für Debug-Schnittstellen und Software-Integrität erwarten. Zyberum stellt keine Zertifikate aus und testet nie ohne schriftliche Erlaubnis.

Mehr zu Umfang und Preisen auf der Seite Hardware-Pentest, oder buch ein kostenloses 15-Minuten-Gespräch.