Firmware Upgrade ohne Hardware-Tausch — So geht's.
Der Hersteller Ihres IoT-Geräts bietet keine Firmware-Updates mehr an. Bekannte Sicherheitslücken, veraltete Verschlüsselung, kein Secure Boot. Die Alternative — neue Hardware — kostet € 50.000–200.000. Unser Ansatz: Wir bauen die Firmware neu. Auf Ihrer bestehenden Hardware.
Schritt 1: Firmware-Extraktion
Bevor wir etwas entwickeln können, brauchen wir das Original. Es gibt mehrere Wege zur Firmware-Extraktion:
JTAG / SWD Debug-Interface
Aufwand: MittelDie meisten MCUs haben einen Debug-Port — oft nicht vollständig gesperrt (JTAG Fuse nicht gesetzt). Über JTAG lässt sich der Flash-Speicher direkt auslesen. Tools: J-Link, OpenOCD.
UART Bootloader
Aufwand: EinfachViele STM32, ESP32 und nRF-Devices haben einen ROM-Bootloader mit UART-Interface. Wenn kein Read-Protection aktiv ist, kann die Firmware direkt gelesen werden.
Flash-Chip Direktzugriff
Aufwand: HochExternes SPI-Flash (z.B. W25Q64) direkt über SOIC-Clip auslesen — ohne MCU zu involvieren. Funktioniert auch wenn der MCU-Debug-Port gesperrt ist.
OTA Update abfangen
Aufwand: VariabelWenn das Gerät OTA-Updates empfängt (unverschlüsselt oder schwach verschlüsselt), kann ein Update-Image abgefangen und als Basis verwendet werden.
Schritt 2: Static Analysis des Firmware-Images
Das extrahierte Binary analysieren wir mit IDA Pro oder Ghidra. Ziel: Alle Netzwerkdienste, Eingabeverarbeitungsroutinen und Kryptographie-Implementierungen verstehen.
# Was wir typisch suchen:
strings firmware.bin │ grep -E "(password|key|secret|admin)"
# Häufige Findings:
"admin:admin123" ← Hardcodierte Credentials (CVSS 9.8)
"RC4" ← Veraltete Verschlüsselung
"debug=1" ← Debug-Interface im Produktionsmodus
Schritt 3: Die neue Firmware — was wir anders machen
Wir schreiben keine 1:1-Kopie der alten Firmware. Wir implementieren die Funktion neu — mit moderner, sicherer Architektur:
✓ Secure Boot
RSA-2048 oder ECDSA Signierung. Nur signierte Images werden geflasht. Rollback-Schutz via OTP-Zähler.
✓ AES-256-GCM
Alle Netzwerkverbindungen verschlüsselt. RC4, DES, 3DES ersetzt. TLS 1.3 für MQTT.
✓ Certificate Auth
Hardcodierte Passwörter weg. X.509-Zertifikate, sicheres BLE-Provisioning.
✓ Input Validation
Alle Netzwerk-Endpunkte mit expliziter Längenprüfung. Risiko von Buffer Overflows signifikant reduziert.
✓ OTA Infrastructure
Signierte Updates. Rollout in Wellen. Monitoring. Automatischer Rollback bei Fehler.
✓ Audit Logging
Alle Verbindungen, Befehle und Konfigurationsänderungen geloggt. Forensisch verwertbar.
Schritt 4: OTA Rollout auf Feldgeräte
200+ Geräte im Feldeinsatz — und kein einziger Techniker-Besuch nötig. Unser OTA-Rollout-Prozess:
10 % Pilot-Gruppe
Erste Welle auf kontrollierten Testgeräten. 48h Monitoring. Keine Auffälligkeiten → weiter.
30 % zweite Welle
Erweiterte Gruppe. Vollständiges Telemetrie-Monitoring. Automatischer Rollback wenn > 1 % Fehlerrate.
100 % Final-Rollout
Alle verbleibenden Geräte. Update-Dauer: < 90 Sekunden pro Gerät. Produktionsbetrieb ungestört.
Zertifizierung & Dokumentation
CVE-Report, Penetrationstest-Ergebnis, NIS2-Compliance-Nachweis, vollständige Änderungsdokumentation.
Fazit: Die Hardware ist selten das Problem
In über 80 % der Fälle, die wir analysieren, ist die Hardware völlig in Ordnung. Was veraltet, was unsicher ist — das ist die Software. Und Software lässt sich ersetzen, ohne die Hardware anzufassen.
Das Ergebnis: Geräte, die mit bekannten Sicherheitslücken liefen, sind gehärtet. Geräte, die instabil abstürzten, laufen stabil. Und der Kunde hat seine Hardware behalten — und eine Investition von € 50.000–200.000 gespart.