05 / FIRMWARE & CODE

Firmware & Source Code Review

Firmware / Produkt-Code im Scope

Gezielter Review sicherheitskritischer Firmware und Produkt-Code, einschließlich Boot- und Update-Logik, Parsern, Authentisierung, Krypto-Integration, Privilegien-Grenzen und exponierten Diensten.

Wir konzentrieren den Review auf die Codepfade, die Produkt-Vertrauen durchsetzen oder angreifergesteuerte Eingaben verarbeiten.

FirmwareBoot & UpdateParsersAuthentisierungKryptografieMemory Safety
FIRMWARE / CODEBASE 05 REVIEW PATH
review path note execution path: NETWORK INPUT → PARSER → AUTH → COMMAND → PRIVILEGED OP
INPUT / NETWORK
quelle Funk + Ethernet
exposition remote
vertrauensannahme keine
validierung nachgelagert
REVIEW-FOKUS

Sicherheitskritischer Code ist nicht gleichmäßig verteilt.

Ein kleiner Teil einer Produkt-Codebasis kontrolliert oft die wichtigsten Vertrauensentscheidungen: das Parsen angreifergesteuerter Eingaben, die Annahme von Firmware, die Etablierung von Identität, den Umgang mit Secrets oder das Freigeben privilegierter Funktionalität. Genau auf diese Pfade konzentrieren wir den Review.

review-fokus selected
INPUT
Wo angreifergesteuerte Daten in den Code gelangen. Netzwerk, Dateien, Update-Pakete, lokale Schnittstellen.
PRÜFFLÄCHE

Was wir reviewen

Boot, Update & Recovery

Secure-Boot-Logik, Firmware-Verifikation, Update-Autorisierung, Versions-Durchsetzung, Rollback-Schutz, Recovery-Pfade und Trust-Anker-Nutzung.

Parser & unvertraute Eingaben

Netzwerk-Nachrichten, Dateiformate, Protokoll-Handler, Update-Pakete, Management-Schnittstellen und andere angreifergesteuerte Datenpfade.

Authentisierung & Autorisierung

Identitätsprüfungen, Sessions, Rollen, Privilegien-Entscheidungen, Verwaltungsfunktionen und Access-Control-Logik.

Kryptografie & Secrets

Nutzung kryptografischer APIs, Zufall, Key-Handling, Secret-Speicherung, Signatur-Verifikation und Implementierung kryptografischer Vertrauensentscheidungen.

Privilegien & Memory Safety

Memory Corruption, unsichere Operationen, Privilegien-Übergänge, Prozessgrenzen, IPC und Code in privilegierten Kontexten.

Produktdienste & Sicherheitslogik

Sicherheitsrelevante Applikationslogik, interne Dienste, Management-Komponenten und Code, der Geräte-, Applikations- und Backend-Vertrauen verbindet.

Der Review wird um sicherheitsrelevante Komponenten und Angriffspfade herum gescoped, nicht um Code-Menge allein.

REVIEW-ANSATZ

Architektur zuerst. Codepfade danach.

Wir starten bei der Produktarchitektur, den angreifergesteuerten Einstiegspunkten und den Vertrauensentscheidungen, und verfolgen diese Pfade dann durch die Implementierung. Statische Analyse, gezieltes Fuzzing und weiteres Tooling unterstützen den Review, wo sie Abdeckung oder Verifikation verbessern.

arbeitsweise selected
ARCHITECTURE
Produktarchitektur, Komponenten, Vertrauensgrenzen und Exposition verstehen.
IMPLEMENTIERUNGSPFADE

Kleine Implementierungsfehler können Produkt-Vertrauen brechen.

01

Netzwerk-Input → Parser → Code-Ausführung

Ein remote erreichbarer Parser vertraut einem Längenfeld, bevor die vollständige Nachricht validiert ist. Aus einer Protokoll-Eingabe wird Memory Corruption in einer privilegierten Firmware-Komponente.

02

Update → Verifikation → Rollback

Firmware-Signaturen werden korrekt geprüft, aber die Versions-Durchsetzung erfolgt erst, nachdem ein Recovery-Pfad das Image bereits akzeptiert hat. Signierte Legacy-Firmware lässt sich wiederherstellen.

03

Authentisierung → Rollenprüfung → Privilegierte Funktion

Die Authentisierung gelingt korrekt, aber die Autorisierung wird über Management-Handler hinweg inkonsistent durchgesetzt. Eine Identität mit niedrigen Rechten erreicht eine administrative Operation.

SCOPING

Der Umfang folgt den sicherheitskritischen Codepfaden.

Komponenten

Firmware-Module, Bootloader, Update-Komponenten, Protokoll-Handler, Produktdienste oder ausgewählte Applikations-/Backend-Komponenten.

Einstiegspunkte

Funk-/Netzwerk-Input, Dateien, Update-Pakete, lokale Schnittstellen, APIs, IPC, Nutzereingaben oder eine andere angreifergesteuerte Quelle.

Review-Tiefe

Der Auftrag kann ein fokussiertes Subsystem, ein sicherheitskritisches Feature oder eine breitere Produkt-Codebasis umfassen, je nach Fragestellung.

Ein kompletter Repository-Review ist nicht immer nötig. Ausgewählte Source-Bäume, Firmware-Images und Architektur-Kontext genügen oft, um einen fokussierten Review zu definieren.

Wo Source unvollständig ist, liefern Binaries und Laufzeitverhalten zusätzliche Implementierungs-Evidenz.

ERGEBNISSE

Was Sie erhalten

Befunde auf Code-Ebene

Betroffene Komponenten, Funktionen und die relevanten Ausführungspfade.

Reproduzierbare Evidenz

Inputs, Requests, Traces, Testfälle oder Proof-of-Concept-Verhalten, mit dem sich das Problem verifizieren lässt.

Sicherheits-Auswirkung

Wie die Implementierungsschwäche die Angriffsfläche verändert oder eine Produkt-Vertrauensannahme bricht.

Remediation & Retest

Technische Remediation gebunden an den betroffenen Pfad, gefolgt von Verifikation, soweit Retesting im Umfang liegt.

FINDING 06
Recovery-Pfad erlaubt signierten Firmware-Downgrade
ENTRY
Recovery-Update-Paket
CODE PATH
parse_image() → verify_signature() → install_image() → enforce_version()
TRUST
Signatur gültig
IMPACT
angreifbare Legacy-Firmware wiederhergestellt
STATUS
reproduzierbar
Typische Anlässe

Wann dieser Review passt

Neues Firmware- oder Produkt-Release
Neuer Boot-, Update- oder Recovery-Mechanismus
Sicherheitskritischer Protokoll-Parser
Neues Authentisierungs- oder Privilegien-Modell
Änderung an Krypto-Implementierung oder Key-Handling
Großes Firmware- oder Embedded-Software-Refactoring
Legacy-Code mit Sicherheitsbezug, nie fokussiert gereviewt
Kunden-Assurance-Anforderung
Review eines Subsystems vor dem Penetrationstest
Root-Cause-Analyse eines im Testing gefundenen Befunds
PRODUCT-SECURITY-ANFORDERUNGEN

Soll der Review eine regulatorische Anforderung stützen?

Sicherheitsrelevante Implementierungs-Nachweise können technische Product-Security-Anforderungen zu Zugangskontrolle, sicheren Updates, Kryptografie und Widerstand gegen ausnutzbare Schwachstellen stützen.

CRAEN 18031IEC 62443
Technisches Testen und Nachweise. Zertifizierung ist nicht Teil des Umfangs.
Dr. Ewan Fleischmann
Technische Leitung

Dr. Ewan Fleischmann

Gründer · Product Security & Kryptografie

22+ Jahre IT-Security · PhD Kryptografie · OSCP · OSCE · CISSP

Sie bauen ein Produkt, das ernsthaften Security-Testing braucht?

Sagen Sie uns, was Sie bauen, in welcher Phase es steht und was getestet werden soll. Der Umfang folgt aus dem Produkt.

Auf Wunsch zuerst NDA.