# Fuzzing

> Fuzzing (Fuzz-Testing) ist eine automatisierte Testtechnik, die Software oder einem Gerät große Mengen unerwarteter, fehlerhafter oder zufälliger Eingaben schickt und auf Abstürze, Hänger und anderes abnormales Verhalten achtet, das auf Bugs hinweist. ISO/SAE 21434 und IEC 62443-4-1 nennen es unter den Verifikationsmethoden, der Cyber Resilience Act verlangt regelmäßige Sicherheitstests. Auf Steuergeräten und IoT-Geräten liegt die Schwierigkeit weniger im Erzeugen der Eingaben als im zuverlässigen Erkennen von Fehlern auf echter Hardware.

Fuzzing schickt einem Ziel massenhaft fehlerhafte Eingaben, um Abstürze und Sicherheitslücken zu finden. Wo Normen es verlangen und wie es auf Steuergeräten läuft.

Source: https://zyberum.com/de/glossar/fuzzing · Updated: 2026-10-07

## Was ist Fuzzing?

Fuzzing ist eine Softwaretesttechnik, die ein Programm automatisch mit unerwarteten, fehlerhaften oder halb fehlerhaften Eingaben versorgt, um Bugs, Schwachstellen und unerwartetes Verhalten zu finden, so die Definition von OWASP. Der Fuzzer erzeugt Eingaben, liefert sie aus und beobachtet das Ziel: Ein Absturz, ein Hänger, ein Reset, ein Speicherfehler oder eine falsche Antwort zeigt einen Bug, den ein menschlicher Tester von Hand selten erreicht hätte.

Fuzzer unterscheiden sich darin, wie sie Eingaben erzeugen. **Mutationsbasierte** Fuzzer nehmen gültige Beispiele und kippen, fügen ein und löschen Bytes. **Generierungsbasierte** oder protokollbewusste Fuzzer bauen Eingaben aus einem Modell des Formats oder Protokolls, kommen so an der ersten Längenprüfung vorbei und erreichen tieferen Code. **Coverage-geführte** Fuzzer wie AFL++ oder libFuzzer instrumentieren das Programm, behalten Eingaben, die neuen Code erreichen, und mutieren von dort weiter; sie sind am wirksamsten, wo der Code mit Instrumentierung kompiliert werden kann. Für ein Gerät auf dem Prüfstand, dessen Code sich nicht instrumentieren lässt, ist protokollbewusstes Fuzzing mit sorgfältiger Fehlererkennung der gangbare Weg.

## Wo ist es definiert?

Keine Norm definiert Fuzzing selbst, aber mehrere verlangen oder empfehlen es. ISO/SAE 21434 nennt Fuzz-Tests zusammen mit Funktionstests, Schwachstellenscans und Penetrationstests unter den Methoden der Cybersecurity-Verifikation in der Produktentwicklung (Klausel 10). IEC 62443-4-1 führt es innerhalb der Praktik zu Security-Verifikation und -Validierung für Industriekomponenten. Der Cyber Resilience Act verlangt in Anhang I Teil II, dass Hersteller wirksame und regelmäßige Tests und Überprüfungen der Sicherheit des Produkts mit digitalen Elementen durchführen. Cybersecurity-Anforderungen von OEMs an Zulieferer verlangen zunehmend Fuzzing-Berichte als Nachweis.

## Was es in der Praxis bedeutet

Fuzzing ist eine der Kerntätigkeiten von Zyberum und die Grundlage unseres Produkts AutoST. Auf Embedded-Zielen ist das Schwierige nicht, Eingaben zu erzeugen, sondern zu sehen, was sie bewirkt haben. Ein Server stürzt sichtbar ab; ein Steuergerät resettet still, verliert eine Diagnose-Session oder antwortet auf einen Dienst nicht mehr, während alles andere weiterläuft. Wir instrumentieren deshalb die Umgebung statt des Codes: einen Heartbeat wie UDS TesterPresent, Überwachung von Reset-Leitungen oder Stromaufnahme, einen Debugger, wo einer verfügbar ist, und den Vergleich jeder Antwort mit dem erwarteten Verhalten.

Wo wir es einsetzen:

- **Diagnose- und Fahrzeugprotokolle**: UDS über CAN und DoIP, ISO-TP-Segmentierung, SOME/IP und seine Service Discovery. Protokollbewusstes Fuzzing dieser Stacks auf Leistungselektronik-Steuergeräten hat Parser gefunden, die das Steuergerät bei bestimmten fehlerhaften Längen und Sequenzen resetten. Mit der Diagnosedatenbank (ODX oder CDD) fuzzen wir genau die Identifier und Routinen, die existieren, was weit effizienter ist als zufällige Bytes.
- **Infotainment-Plattformen**: Kernel- und Treiberschnittstellen auf Embedded Linux und Android sowie die Schnittstelle zwischen Normal World und Trusted Execution Environment, wo ein Absturz in einer Trusted Application mehr zählt als irgendwo sonst im System.
- **IoT-Geräte**: MQTT-Broker, proprietäre Funkprotokolle, Bluetooth-Stacks und Firmware-Update-Parser.

Ein Fuzzing-Ergebnis ist ein Ausgangspunkt, kein Finding. Jeder Absturz wird reproduziert, auf die kürzeste Eingabe minimiert und in der Firmware analysiert, um zu entscheiden, ob es ein Denial of Service ist, eine Speicherkorruption, die zu Codeausführung werden könnte, oder ein harmloser Watchdog-Reset. Der Bericht nennt diese Einschätzung, die Reproduktionsschritte und den Fix.

## Häufige Missverständnisse

Fuzzing findet nicht alles: Logikfehler, schwache Authentifizierungsdesigns und fehlende Zugriffskontrolle sind für den Fuzzer unsichtbar. Deshalb ergänzt es einen Penetrationstest, statt ihn zu ersetzen. Zufällige Bytes sind auf einem Protokoll mit Prüfsummen und Längenfeldern kein sinnvolles Fuzzing; der Fuzzer muss das Protokoll kennen. Und ein Fuzzer, der null Abstürze meldet, hat nichts gezeigt, solange du nicht weißt, was er abgedeckt hat. Abdeckung, nicht Laufzeit, ist das Maß.

## FAQ

**Was findet Fuzzing, was ein Penetrationstest nicht findet?**

Speichersicherheits- und Robustheitsfehler in Parsern, die ein Mensch von Hand nie treffen würde: ein Off-by-one in einer Längenprüfung, eine Zustandsmaschine, die nach einer bestimmten Folge von zehn Anfragen kippt, ein Protokoll-Handler, der bei einer abgeschnittenen Nachricht hängen bleibt. Ein Penetrationstester findet Logik- und Designfehler; ein Fuzzer findet die tausend fehlerhaften Eingaben, an die niemand gedacht hat. Gute Projekte kombinieren beides.

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

Es kann es in Zustände bringen, aus denen es schwer zurückkommt, etwa indem eine Schreib- oder Flash-Routine mit kaputten Daten ausgelöst wird. Deshalb fuzzen wir Prüfstandsmuster, halten einen kontrollierten Strom- und Reset-Pfad bereit und vereinbaren vorab, welche Dienste im Umfang sind. Seriensteuergeräte im Fahrzeug werden ohne diesen Aufbau nicht gefuzzt.

**Verlangt eine Norm Fuzzing?**

ISO/SAE 21434 nennt Fuzz-Tests unter den Methoden der Cybersecurity-Verifikation in der Produktentwicklung, IEC 62443-4-1 führt es in der Praktik zum Schwachstellentest, und der Cyber Resilience Act verlangt wirksame und regelmäßige Sicherheitstests des Produkts. Keine davon schreibt ein Werkzeug oder eine Dauer vor; der Hersteller entscheidet wie und dokumentiert es.

## Sources

- [OWASP: Fuzzing](https://community.owasp.org/Fuzzing)
- [ISO/SAE 21434:2021: Road vehicles, Cybersecurity engineering](https://www.iso.org/standard/70918.html)
- [IEC 62443-4-1:2018: Secure product development lifecycle requirements](https://webstore.iec.ch/en/publication/33615)
- [Verordnung (EU) 2024/2847 (Cyber Resilience Act), Anhang I Teil II](https://eur-lex.europa.eu/eli/reg/2024/2847/oj)

## Related

- [ECU-Fuzzing erklärt: Fehler in UDS, DoIP und SOME/IP finden](https://zyberum.com/de/insights/ecu-fuzzing-erklaert)
- [UDS (Unified Diagnostic Services)](https://zyberum.com/de/glossar/uds)
- [SAST und DAST](https://zyberum.com/de/glossar/sast-dast)
- [Manueller vs. automatisierter Pentest: Was Tools finden und was Menschen](https://zyberum.com/de/vergleich/manueller-vs-automatisierter-pentest)
- [Automotive Security Testing, automatisiert.](https://zyberum.com/de/autost)
- [Finde die Schwachstellen in deinem Fahrzeug, bevor Angreifer es tun.](https://zyberum.com/de/automotive-security)

---
Zyberum GmbH. Canonical page: https://zyberum.com/de/glossar/fuzzing