UDS-Fuzzing vs. CAN-Fuzzing: Welche Schicht du angreifst und was bricht

Was ist der Unterschied?

UDS-Fuzzing arbeitet auf der Anwendungsschicht der ISO 14229. Der Fuzzer spricht ISO-TP korrekt genug, um eine Payload zuzustellen, und macht dann die Payload falsch: ein ReadDataByIdentifier (0x22) mit 100 Bytes statt zwei, ein RoutineControl (0x31) mit zufälligem Routine Identifier und Müll als Parameter, ein TransferData-Block (0x36), der größer ist als im RequestDownload vereinbart, Service Identifier aus den reservierten Bereichen, Sub-Funktionen mit dem Suppress-Positive-Response-Bit an seltsamen Stellen. Zwischen den Iterationen hält er die Diagnose-Session mit TesterPresent offen und betritt sie neu, wenn das Steuergerät in Default zurückfällt. Der getestete Code ist der Diagnose-Stack: Request-Parsing, Längenprüfungen, Session- und Security-Zustand, die Daten-Handler hinter jeder DID und Routine.

CAN-Fuzzing arbeitet auf der Sicherungsschicht der ISO 11898. Es gibt kein Transportprotokoll und kein Request-Response. Der Fuzzer legt Frames auf den Bus, auf den Arbitration-IDs, auf die ein Steuergerät tatsächlich hört, entnommen aus einer DBC, und mutiert die Payload: Signalwerte außerhalb des physikalischen Bereichs, rollierende Zähler, die springen, Prüfsummen, die falsch oder richtig sind, DLC-Varianten, Classic- und CAN-FD-Frames. Der getestete Code ist die Anwendung: Signaldekodierung, Plausibilitätsprüfungen, Zustandsmaschinen, die auf ein Tür-offen- oder Zündung-an-Signal reagieren, die Routing-Regeln des Gateways.

Die beiden Schichten brechen unterschiedlich. Ein UDS-Stack, der eine Längenprüfung falsch macht, liefert dir einen Reset mitten in der Diagnose-Session. Eine Anwendung, die einem Signalwert vertraut, liefert dir einen Motorregler, der auf 65.535 km/h reagiert. Nur eines davon sieht ein Diagnosetester.

Nebeneinander

	UDS-Fuzzing	CAN-Fuzzing
Findet	Resets und Hänger bei fehlerhaften Requests, Längenprüfungsfehler in DID- und Routinen-Handlern, Überläufe bei TransferData und RequestDownload, Zustandsmaschinenfehler über Sessions, Services, die nicht mehr antworten, DTCs durch Diagnose-Eingaben	Plausibilitätslücken in der Signalverarbeitung, Umgehung von Zählern und Prüfsummen, Reaktionen auf Werte außerhalb des Bereichs, Anwendungsfehler und DTCs durch Bus-Eingaben, Gateways, die Frames weiterleiten, die sie verwerfen sollten
Übersieht	Alles in der Signalverarbeitung der Anwendung; Steuergeräte ohne Diagnose-Endpunkt	Den Diagnose-Stack; alles, was einen Multi-Frame-Transport braucht
Wer macht es	Test-Engineers aus dem Dashboard; braucht die ISO-TP-Adressen des Steuergeräts, gefunden durch Enumeration	Test-Engineers aus dem Dashboard; braucht die DBC für die Eingänge des Steuergeräts
Prüfstandszeit	Stunden pro Kampagne; der Session-Wiedereintritt kostet pro Iteration etwas	Stunden pro Kampagne; Frames sind billig, also sind die Iterationszahlen hoch
Kosten	Teil der AutoST-Fuzzing-Engine, lizenziert pro Komponente; freie Fuzzer gibt es	Teil der AutoST-Fuzzing-Engine; freie Tools gibt es (can-utils, Scapy, CaringCaribou)
Passt in den Release-Zyklus	Ja, geseedet und begrenzt; ein kurzer Lauf pro Build, ein langer pro Release	Ja, gleicher Mechanismus; eine Reproduktionszahl bestätigt ein Finding, bevor es protokolliert wird
Verlangt von	ISO/SAE 21434 [RC-10-12] empfiehlt Fuzz-Tests von Komponenten; in der Praxis ab CAL 2 für Diagnoseschnittstellen erwartet	Dieselbe Empfehlung; in der Praxis für Busschnittstellen sicherheitsrelevanter Steuergeräte erwartet
Ergebnis	Findings mit Iteration, Payload, Monitor und Payload-Historie, per Seed wiederholbar; PDF und SARIF	Dasselbe, mit Arbitration-ID und Frame; per Seed wiederholbar

Nimm UDS-Fuzzing, wenn

• das Steuergerät einen Diagnose-Stack hat, der sich anzugreifen lohnt: einen Bootloader mit 0x34, 0x36, 0x37, Routinen, die Kalibrierungen starten oder Speicher löschen, eine am Prüfstand erreichbare Programming Session.
• du Findings willst, auf die ein Entwickler schnell reagieren kann. Ein UDS-Finding nennt Service, Sub-Funktion und Payload; der Handler ist leicht zu finden.
• du keine DBC hast. Die Enumeration liefert alles, was UDS-Fuzzing braucht.
• das Steuergerät über DoIP erreichbar ist. UDS-Fuzzing wandert unverändert auf Ethernet, CAN-Fuzzing nicht.

Nimm CAN-Fuzzing, wenn

• die Aufgabe des Steuergeräts ist, auf Bussignale zu reagieren: Karosserie, Fahrwerk, Antrieb, Gateway. Sein Risiko liegt darin, was es mit einem falschen Wert tut, nicht darin, was sein Diagnose-Stack sagt.
• das Steuergerät wenig oder keine Diagnoseoberfläche hat oder die Diagnose dicht ist und die offene Angriffsfläche der Bus selbst ist.
• du Gateway- oder Filterprobleme vermutest: Frames von einem weniger vertrauenswürdigen Bus erreichen einen vertrauenswürdigeren.
• du auf CAN FD mit längeren Payloads testest und sehen willst, wie Code, der für acht Bytes geschrieben wurde, mit 64-Byte-Frames umgeht.

Beides zusammen

Ein echtes Steuergerät wird auf beiden Schichten angegriffen, und eine ernsthafte Kampagne fuzzt beide. Die Reihenfolge ist Enumeration, UDS-Fuzzing, CAN-Fuzzing: Die Enumeration liefert dir die ISO-TP-Endpunkte und sagt dir, was du ausschließen musst (niemand will einen ECUReset in Iteration eins), UDS-Fuzzing übt den Diagnose-Stack bei offener Session, und CAN-Fuzzing mit der DBC übt die Anwendung. Die Crash-Erkennung ist geteilt, sodass ein Frame, der den Diagnose-Responder leise tötet, genauso auftaucht wie ein fehlerhafter Request.

AutoST fährt beide Modi von derselben Komponente aus mit gespeichertem Seed, einer Lebendigkeitsprüfung nach jeder Iteration und optionalem DTC-Monitoring, und beide landen in einem Fix Plan. Fuzzing jeder Art ist eine Prüfstandsaktivität: nie an einem Fahrzeug im Verkehr, immer mit einem Weg, das Steuergerät neu zu flashen. Und ein sauberer Fuzzing-Lauf auf beiden Schichten sagt weiterhin nichts über den Seed/Key-Algorithmus oder den Update-Pfad; dafür braucht es einen Menschen.