Platinenanalyse
Bauteile, Testpunkte und Debug-Header identifizieren und nachverfolgen, was womit verbunden ist.
Hardware- & Embedded-Pentest
Wir öffnen das Gehäuse. Dann die Firmware.
Testpunkte, Debug-Ports, Flash-Chips und Bootloader: alles, was sich ein Angreifer mit Schraubenzieher und einem freien Wochenende ansieht. Wir machen das in unserem Labor, mit denselben Werkzeugen und mehr Geduld.
- JTAG, SWD, UART
- Firmware-Extraktion und Reverse Engineering
- Secure-Boot-Analyse
Kurz gesagt
Ein Hardware-Penetrationstest greift ein Embedded-Gerät physisch an: Debug-Schnittstellen wie UART, JTAG und SWD, Speicherchips, den Bootvorgang und die Firmware selbst. Die Ziele: Firmware und Secrets extrahieren, Secure Boot umgehen, Code ausführen und Schwachstellen finden, die jedes Gerät desselben Typs betreffen. Zyberum führt Hardware-Pentests im eigenen Labor durch, für IoT-Produkte, Fahrzeugsteuergeräte und Industriekomponenten.
Was wir tun
Von der Platine bis zur Root-Shell
Debug-Schnittstellen
UART-Konsolen, JTAG und SWD: gesperrt, offen oder nur vermeintlich gesperrt.
Firmware-Extraktion
Über den Debug-Port, die Update-Datei oder direkt aus dem Flash-Chip.
Secure Boot & Schlüssel
Prüft jede Stufe die nächste? Wo liegen die Schlüssel, und wer kann sie auslesen?
Fault Injection
Voltage- und Clock-Glitching, um Prüfungen zu überspringen, die sich per Software allein nicht umgehen lassen.
Reverse Engineering
Firmware-Analyse in Ghidra: Secrets, Update-Logik, versteckte Befehle und Speicherfehler.
Warum das zählt
Ein geöffnetes Gerät kann die ganze Flotte offenlegen
Hardware-Angriffe brauchen physischen Zugriff. Das klingt beruhigend, ist es aber nicht: Ein Angreifer kauft ein Gerät, zieht die Firmware, findet den gemeinsamen Schlüssel oder den versteckten Dienst und nutzt dieses Wissen dann gegen jedes Gerät im Feld, aus der Ferne.
Deshalb verlangt die Regulierung es inzwischen. Der Cyber Resilience Act, die Cybersecurity-Anforderungen der RED (EN 18031) und IEC 62443-4-2 erwarten geschlossene Debug-Schnittstellen, geschützte Secrets und sichere Updates.
Case Studies
Was wir auf echten Geräten gefunden haben
IoTAPI-Sicherheit
Case Study: Root auf dem Saugroboter und fremde Kameras
Voller Root-Zugriff auf dem Gerät und Zugriff auf die Live-WebRTC-Kamera fremder Nutzer über die Cloud-API.
Wir haben einen Saugroboter mit Kamera getestet: Root-Zugriff auf dem Gerät und Lücken in der Cloud-API, die die Live-Kamera fremder Nutzer öffneten. Was schieflief.
Case Study lesenIoTMQTT
Case Study: Smarte Bewässerung, die jeder steuern konnte
Über MQTT konnten wir die Geräte anderer Kunden sehen und aktivieren und orten, wo sie installiert sind.
Wir haben ein smartes Bewässerungssystem getestet: Durch ein fehlerhaftes MQTT-Setup konnten wir Geräte anderer Kunden sehen, schalten und ihren Standort ermitteln.
Case Study lesenFAQ
FAQ zum Hardware-Pentest
Wie viele Geräte braucht ihr?
Zwei oder drei. Hardware-Angriffe können ein Gerät zerstören, zum Beispiel wenn wir einen Flash-Chip auslöten.
Testet ihr auch App und Cloud?
Ja, als kompletten IoT-Produkttest. Viele der schlimmsten Findings entstehen, wenn ein Hardware-Finding auf eine Schwäche in der Cloud trifft.
Könnt ihr gesperrte Mikrocontroller testen?
Oft ja. Der Ausleseschutz lässt sich manchmal per Fault Injection oder über bekannte Schwächen des Chips umgehen. Im Scoping-Gespräch sagen wir dir, was bei deinem Gerät realistisch ist.
Jetzt starten
Dein Hardware-Pentest, in 15 Minuten abgestimmt
Erzähl uns vom Gerät, seinem Prozessor und seinen Schnittstellen. Nach dem Gespräch bekommst du ein Festpreisangebot.
- Scope nach Schnittstellen und Angriffstiefe
- Festpreisangebot nach dem Gespräch
- Zwei oder drei Mustergeräte reichen uns
Dein Gespräch führst du mitTom ZaubermannGründer & CEO, Zyberum
Oder schreib uns
Wir antworten innerhalb eines Werktags.