# Fuzzing vs. Schwachstellenscan am Steuergerät: Was welche Methode findet

> Schwachstellenscan am Steuergerät heißt strukturiertes Prüfen mit gültigen Requests: Welche Sessions, Services und DIDs antworten, hat SecurityAccess einen Zähler, ist eine DID schreibbar. Er findet Konfigurations- und Zugriffsschwächen und dauert Minuten. Fuzzing heißt fehlerhafte, überlange und zufällige Eingaben über Stunden, mit Blick darauf, ob das Steuergerät resettet, hängt oder Fehlercodes wirft. Es findet Implementierungsfehler in Parsern und Stacks. ISO/SAE 21434 [RC-10-12] empfiehlt beides für Komponententests.

Ein Schwachstellenscan stellt dem Steuergerät bekannte Fragen; Fuzzing schickt fehlerhafte Eingaben und wartet auf Crashes. Warum ISO/SAE 21434 beides empfiehlt.

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

## Was ist der Unterschied?

Ein Schwachstellenscan schickt dem Steuergerät Requests, die es versteht, und liest die Antworten. `10 03`, um die Extended Session zu öffnen, `22 F1 90`, um die VIN zu lesen, `27 01`, um einen Seed anzufordern, jeden Service Identifier in jeder Session, und das Steuergerät antwortet positiv oder mit einem Negative Response Code aus ISO 14229-1 Anhang A. Der Scan interpretiert diese Codes: `0x7F` sagt, der Service existiert in einer anderen Session, `0x33` sagt, er liegt hinter SecurityAccess, `0x31` sagt, der Identifier ist unbekannt. Die Schwächen, die er findet, drehen sich um das Erlaubte: ein Service ohne Session-Wechsel erreichbar, eine schreibbare Identifikations-DID, ein Seed/Key-Tor ohne Versuchszähler, eine XCP-Schnittstelle, die niemand anlassen wollte.

Fuzzing schickt dem Steuergerät Eingaben, die es nicht erwartet. Ein `ReadDataByIdentifier` mit 120 Bytes Payload, ein ISO-TP First Frame, der 4.000 Bytes ankündigt und nie liefert, zufällige Service Identifier, ein `TransferData`-Block mit dreifacher vereinbarter Größe, zufällige CAN-Frames auf den Arbitration-IDs aus deiner DBC. Dann beobachtet es: Antwortet das Steuergerät noch auf `TesterPresent`, hat sich die DTC-Zahl geändert, ist eine Antwort ausgeblieben. Die Schwächen, die es findet, drehen sich um den Bau des Steuergeräts: Pufferbehandlung, Längenprüfungen, Zustandsmaschinen, die hängen bleiben, Watchdog-Resets.

Beides ist automatisiert. Der Unterschied ist die Frage: "Ist das erlaubt?" gegenüber "Geht das kaputt?".

## Nebeneinander

| | Schwachstellenscan (Enumeration und Prüfungen) | Fuzzing |
|---|---|---|
| Findet | Services in der falschen Session, lesbare und schreibbare DIDs, fehlende SecurityAccess-Zähler und -Verzögerungen, konstante Seeds, offenes XCP/CCP, DoIP-Routing zu gesperrten Steuergeräten, offene SOME/IP-Services | Resets und Hänger bei fehlerhaften ISO-TP-Frames, Crashes bei überlangen Payloads, Services, die nicht mehr antworten, Fehlercodes durch schlechte Eingaben, Parser-Fehler in der CAN-Signalverarbeitung |
| Übersieht | Implementierungsfehler in Parsern und Stacks; alles, was nur ungültige Eingaben auslösen | Zugriffs- und Designschwächen; ein perfekt robustes Steuergerät mit schreibbarer Seriennummer besteht jeden Fuzzing-Lauf |
| Wer macht es | Test-Engineers aus dem Dashboard; liest und klassifiziert | Test-Engineers aus dem Dashboard; braucht einen Rückweg für das Steuergerät |
| Prüfstandszeit | Minuten pro Session; etwa zehn Minuten pro Session für einen vollständigen DID-Durchlauf | Stunden pro Kampagne; ein kurzer Lauf pro Build, ein langer pro Release |
| Kosten | Teil der AutoST-Lizenz pro Komponente; freie Tools gibt es | Teil der AutoST-Lizenz pro Komponente; freie Fuzzer gibt es, aber Reproduzierbarkeit und Crash-Erkennung sind dann deine Aufgabe |
| Passt in den Release-Zyklus | Ja, schnell genug für jeden Build | Ja mit geseedeter, begrenzter Kampagne; ein langer Lauf gehört auf den Release-Branch |
| Verlangt von | ISO/SAE 21434 [RC-10-12] empfiehlt Schwachstellen-Scans für Komponententests; UN R155 verlangt Tests der umgesetzten Maßnahmen | ISO/SAE 21434 [RC-10-12] empfiehlt Fuzz-Testing; in der Praxis ab CAL 2 für Kommunikationsschnittstellen erwartet |
| Ergebnis | Eine Karte von Sessions, Services und DIDs mit Risiko-Flags und einem Score von 0 bis 10; PDF und SARIF | Findings mit Iteration, Payload, Monitor und Payload-Historie, per Seed wiederholbar; PDF und SARIF |

## Nimm den Schwachstellenscan, wenn

- du das Steuergerät zum ersten Mal siehst. Die Enumeration ist nicht-destruktiv und sagt dir, was da ist, bevor du irgendetwas darauf wirfst.
- die Frage Konfiguration ist: Hat der Zulieferer die Programming Session gesperrt, ist der Identifikationsbereich nur lesbar, sperrt SecurityAccess nach drei falschen Keys. Das sind die Findings, die wir an echten Prüfständen am häufigsten sehen, und keines davon braucht Fuzzing.
- das Steuergerät teuer oder schwer wiederherzustellen ist. Ein reiner Lesescan ändert keinen Zustand; Fuzzing kann das.
- du ein Ergebnis in Minuten brauchst, zum Beispiel als Gate bei jedem Build.

## Nimm Fuzzing, wenn

- das Steuergerät komplexe Eingaben parst: Multi-Frame-ISO-TP, `TransferData`-Blöcke, DoIP-Nachrichten, SOME/IP-Payloads, DBC-definierte Signale mit Prüfsummen und Zählern. Dort wohnen Längen- und Zustandsfehler.
- es Feldrückläufer oder Vorfälle auf Testfahrten gab, bei denen Steuergeräte resetteten oder verstummten und niemand es reproduzieren konnte. Ein geseedeter Fuzzer mit Payload-Historie ist der Weg, so etwas zu finden.
- das Steuergerät CAL 2 oder höher hat und dein Assessor nach Fuzz-Tests der Kommunikationsschnittstellen fragen wird, wie [RC-10-12] es empfiehlt.
- das Steuergerät jeden Scan bestanden hat. Eine saubere Karte sagt nichts über Robustheit.

## Beides zusammen

Es sind zwei Hälften des Komponententests, und ISO/SAE 21434 nennt sie in einem Satz. Die praktische Reihenfolge ist: erst scannen, dann fuzzen. Die Enumeration gibt dem Fuzzer seine Ziele (die Sessions, die sich öffnen, die Services, die antworten, die DIDs, die Schreibzugriffe annehmen) und sagt dir, was du ausschließen musst, damit du das Steuergerät nicht in Iteration eins resettest. In AutoST laufen beide von derselben Komponente aus und landen im selben Fix Plan, sodass eine schreibbare DID und ein Crash auf demselben Service als das erscheinen, was sie sind: zwei Findings auf einer Angriffsfläche.

Keines von beiden findet Logikfehler oder verkettete Angriffe. Dafür, und für den Seed/Key-Algorithmus selbst, brauchst du weiterhin einen Menschen, der die Firmware liest.

## FAQ

**Ist UDS-Enumeration ein Schwachstellenscan?**

Ja, im Sinn von Steuergeräten. Die Enumeration schickt gültige Requests (Session Control, jeden Service Identifier, DID-Lesezugriffe) und klassifiziert die Negative Response Codes. Der Scan-Teil ist die Interpretation: ein Service, der in der Default Session antwortet, aber Extended bräuchte, eine DID, die ohne SecurityAccess schreibbar ist, ein Seed, der sich wiederholt. Keine Eingabe ist fehlerhaft, und geschrieben wird nur, wenn du Schreibtests aktivierst.

**Kann Fuzzing das Steuergerät beschädigen?**

Es kann das Steuergerät in einen Fehlerzustand bringen, resetten oder in seltenen Fällen so hinterlassen, dass es nicht mehr bootet. Fuzzing gehört ausschließlich auf den Prüfstand, nie in ein Fahrzeug im Verkehr, und du solltest vorher einen Rückweg wie ein flashbares Image haben. Ein Schwachstellenscan mit reinen Leseprobes trägt ein viel geringeres Risiko.

**Wie lange sollte ein Fuzzing-Lauf dauern?**

Lang genug, um die relevanten Services und Längen abzudecken, also Stunden statt Minuten. Weil AutoST-Läufe geseedet sind, kannst du bei jedem Build eine kurze Smoke-Kampagne und pro Release eine lange Kampagne fahren und jeden Crash exakt wiederholen.

## Sources

- [ISO/SAE 21434:2021 Straßenfahrzeuge, Cybersecurity Engineering, Clause 10.4.2 [RC-10-12] (Fuzz-Testing und Schwachstellen-Scans)](https://www.iso.org/standard/70918.html)
- [ISO 14229-1:2020 Unified diagnostic services (UDS), Teil 1: Anwendungsschicht, Anhang A (Negative Response Codes)](https://www.iso.org/standard/72439.html)
- [ISO 15765-2:2024 Transportprotokoll und Netzwerkschichtdienste (ISO-TP)](https://www.iso.org/standard/84211.html)

## Related

- [Fuzzing (Fuzz-Testing)](https://auto-st.com/de/glossar/fuzzing)
- [NRC (Negative Response Code)](https://auto-st.com/de/glossar/nrc)
- [UDS-Fuzzing vs. CAN-Fuzzing: Welche Schicht du angreifst und was bricht](https://auto-st.com/de/vergleich/uds-fuzzing-vs-can-fuzzing)
- [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)
- [Kenne jede Tür ins ECU.](https://auto-st.com/de/uds-enumeration)

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