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

> UDS-Fuzzing schickt fehlerhafte Diagnose-Requests durch ISO-TP: falsche Längen, zufällige Service Identifier und Sub-Funktionen, überlange Payloads auf 0x22, 0x2E, 0x31 und 0x36, bei offener Session. Es findet Fehler im Diagnose-Stack. CAN-Fuzzing schickt zufällige oder mutierte rohe Frames und Signalwerte auf den Arbitration-IDs aus einer DBC, ohne Transportschicht. Es findet Fehler in Signalverarbeitung und Anwendungslogik. Die beiden Schichten versagen unterschiedlich, und eine ernsthafte Kampagne fuzzt beide, mit Crash-Erkennung, die für beide funktioniert.

UDS-Fuzzing verändert Diagnose-Requests über ISO-TP; CAN-Fuzzing verändert rohe Frames und Signale. Andere Fehler, andere Risiken, und warum eine Kampagne beides braucht.

Source: https://auto-st.com/de/vergleich/uds-fuzzing-vs-can-fuzzing · Updated: 2026-10-07

## 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.

## FAQ

**Ist ISO-TP-Fuzzing UDS-Fuzzing oder CAN-Fuzzing?**

Es liegt dazwischen und verdient eigene Testfälle: First Frames mit unmöglichen Längen, Consecutive Frames in falscher Reihenfolge, Flow Control mit Blockgröße null, Padding-Varianten. Wir sehen regelmäßig Steuergeräte, die allein bei einem fehlerhaften First Frame resetten oder hängen. AutoST übt diese Schicht als Teil des UDS-Fuzzings, weil der Transport der Weg ist, auf dem die UDS-Payload reist.

**Woher weiß der Fuzzer, dass das Steuergerät abgestürzt ist?**

AutoST prüft nach jeder Iteration die Lebendigkeit mit TesterPresent (0x3E), beobachtet optional die DTC-Zahl und protokolliert Timeouts und Transportfehler. Beim CAN-Fuzzing funktioniert das weiter, solange das Steuergerät einen Diagnose-Endpunkt hat; ohne einen sind DTC-Monitor und Timeouts das Signal.

**Warum braucht der CAN-Fuzzer eine DBC?**

Ohne sie schickt der Fuzzer zufällige Identifier, die das Steuergerät in Hardware ausfiltert, und nichts passiert. Die DBC sagt ihm, auf welche Arbitration-IDs das Steuergerät hört und wie Signale, Zähler und Prüfsummen liegen, damit Mutationen tatsächlich Anwendungscode erreichen.

## Sources

- [ISO 14229-1:2020 Unified diagnostic services (UDS), Teil 1: Anwendungsschicht](https://www.iso.org/standard/72439.html)
- [ISO 15765-2:2024 Transportprotokoll und Netzwerkschichtdienste (ISO-TP), Frame-Typen und Flow Control](https://www.iso.org/standard/84211.html)
- [ISO 11898-1:2015 Controller Area Network (CAN), Teil 1: Sicherungsschicht und physikalische Signalübertragung](https://www.iso.org/standard/63648.html)
- [ISO/SAE 21434:2021 Clause 10.4.2 [RC-10-12] (Fuzz-Testing in der Komponentenverifikation)](https://www.iso.org/standard/70918.html)

## Related

- [ISO-TP (ISO 15765-2)](https://auto-st.com/de/glossar/iso-tp)
- [CAN-Bus (Controller Area Network)](https://auto-st.com/de/glossar/can-bus)
- [Fuzzing (Fuzz-Testing)](https://auto-st.com/de/glossar/fuzzing)
- [Fuzzing vs. Schwachstellenscan am Steuergerät: Was welche Methode findet](https://auto-st.com/de/vergleich/fuzzing-vs-schwachstellenscan)
- [Eine UDS-Fuzzing-Methodik, die echte Bugs findet](https://auto-st.com/de/insights/uds-fuzzing-methodik)
- [Mach es am Prüfstand kaputt, nicht im Feld.](https://auto-st.com/de/ecu-fuzzing)

---
AutoST by Zyberum. Canonical page: https://auto-st.com/de/vergleich/uds-fuzzing-vs-can-fuzzing