Embedded- & IoT-Sicherheit.
Ihr Gerät ist nur so sicher wie seine schwächste Schnittstelle. Ich prüfe Firmware, Hardware und Protokolle mit dem Blick eines Angreifers – bevor jemand anderes es tut.
Vernetzte Geräte sind ein dankbares Ziel: Sie laufen oft jahrelang ohne Updates, verarbeiten Eingaben aus unsicheren Umgebungen und werden bei der Entwicklung selten aus Angreifersicht betrachtet. Klassische Web-Pentester hören meist bei der Cloud-Schnittstelle auf – das eigentliche Gerät bleibt außen vor.
Genau hier setze ich an. Ich komme aus der praktischen Vulnerability-Research-Arbeit und arbeite hardware-nah: Firmware auseinandernehmen, Protokolle reverse-engineeren, die reale Angriffsfläche eines Geräts bestimmen – und alles nachvollziehbar dokumentieren.
Firmware-Analyse
- Firmware extrahieren und statisch analysieren (Ghidra, Radare2)
- Hartcodierte Geheimnisse, Schlüssel und Debug-Zugänge aufspüren
- Update-Mechanismus und Signaturprüfung bewerten
- Bekannte verwundbare Komponenten und Bibliotheken identifizieren
Hardware-Angriffsfläche
- Debug-Schnittstellen prüfen (UART, JTAG, SWD)
- Secure Boot und Flash-Schutz auf Umgehbarkeit testen
- Speicher auslesen und auf sensible Daten untersuchen
- Physische Angriffswege realistisch einordnen
Protokoll- & Funk-Analyse
- Proprietäre Protokolle reverse-engineeren und dokumentieren
- Kommunikation zwischen Gerät, App und Cloud auf Schwachstellen prüfen
- Authentifizierung und Verschlüsselung der Datenwege bewerten
- Manipulations- und Replay-Szenarien durchspielen
So arbeite ich
Zuerst stecken wir den Rahmen ab: Welches Gerät, welche Firmware- Version, welches Bedrohungsmodell? Dann arbeite ich mich von der Software zur Hardware vor – erst statische Analyse und Reverse Engineering, dann die aktiven Tests an Schnittstellen und Protokollen. Sie bekommen keinen Scanner-Report, sondern einen priorisierten Bericht mit reproduzierbaren Schritten, einer ehrlichen Impact-Einordnung und konkreten Empfehlungen – plus einen kostenfreien Retest, wenn Sie nachgebessert haben.
Reverse Engineering ist bei mir keine Behauptung. Für die OpenSourceEBike-/TSDZ2-Community habe ich den Windows-only-Flasher eines E-Bike-Displays neu gebaut: das undokumentierte UART-Bootloader-Protokoll des GD32F103 reverse-engineered und als quelloffenes Python-Tool mit CLI, GUI und Geräte-Simulator ausgeliefert. Öffentlich und direkt nachprüfbar.
Bevor es andere tun.
Sie entwickeln ein vernetztes Gerät oder betreiben eines im kritischen Einsatz? Lassen Sie uns über die Angriffsfläche sprechen.