# Fuzzing (Fuzz Testing) > Fuzzing (fuzz testing) is a test method that sends large amounts of malformed, random or unexpected input to a system and watches for crashes, hangs, resets or other abnormal behaviour. On ECUs the input is usually UDS requests over ISO-TP or DoIP, or raw CAN and CAN FD frames. Fuzzing finds parser and state-handling bugs that no specification-based test case covers, and ISO/SAE 21434 names it among the methods for cybersecurity verification. Fuzzing sends malformed and unexpected input to an ECU and watches for crashes, resets and hangs. How UDS and CAN fuzzing work and what a reproducible run needs. Source: https://auto-st.com/glossary/fuzzing ยท Updated: 2026-10-07 ## What is fuzzing? Fuzzing is automated negative testing. A fuzzer generates input that is invalid, unexpected or random, sends it to the system under test and watches what happens. The goal is not to check that the system does the right thing with correct input, but to find input that makes it do something it should never do: crash, hang, reset, leak memory or accept a request it should reject. There are two broad approaches. Mutation-based fuzzers change valid messages (flip bits, change lengths, append bytes). Generation-based fuzzers build messages from a model of the protocol. Both need a monitor that detects failure, because a fuzzer that cannot tell a crash from a normal answer finds nothing. ## Where is it defined? Fuzzing is a method, not a protocol, so no standard defines how to do it. ISO/SAE 21434 lists fuzz testing among the test methods for cybersecurity verification during integration and verification in clause 10, next to penetration testing and vulnerability scanning. The targets are defined elsewhere: UDS in ISO 14229-1, ISO-TP framing in ISO 15765-2, CAN frames in ISO 11898-1. ## What it means in practice On an ECU, fuzzing hits two layers. UDS fuzzing sends malformed requests: wrong lengths, unknown sub-functions, oversized DID lists, service IDs the ECU does not document. CAN fuzzing sends random classic or FD frames on the arbitration IDs from the DBC, aiming at the application signal handlers. The transport is a target in its own right: we regularly see ECUs that reset or hang on malformed ISO-TP first frames, on a declared length that does not match what follows, or on oversized TransferData blocks. Detection is the hard part. An ECU can reset in 200 ms and answer normally afterwards. A good monitor checks liveness after every iteration, watches DTCs for new fault entries and records the payload and the last few requests before each failure. ## How AutoST tests it AutoST fuzzes over UDS (random payloads up to 128 bytes on selected or non-standard service IDs, with session re-entry) and over CAN and CAN FD (random frames on arbitration IDs from a DBC). Every run is seeded and reproducible. A TesterPresent liveness check runs after every iteration, an optional DTC-count monitor and timeout detection add to it, and each finding stores the payload and its history. ## Common misunderstandings Fuzzing is not the same as a vulnerability scan: a scan checks for known weaknesses, fuzzing looks for unknown ones. It also does not prove an ECU is robust. A run that finds nothing in an hour has only covered what the fuzzer sent in that hour. ## FAQ **Can I fuzz an ECU in a vehicle?** Only on a bench or a vehicle that is safely immobilised and isolated. Fuzzing can put an ECU into a fault state, trigger actuators or brick it, so it must never run on a vehicle in traffic. **How do I know a fuzzed ECU has crashed?** With a monitor that runs between iterations: a liveness check such as TesterPresent, a watch on the DTC count, and timeouts or transport errors on the fuzzed request. Without monitoring, a fuzzer only produces traffic, not findings. **Why does reproducibility matter?** A crash that cannot be replayed cannot be fixed or verified. A seeded fuzzer that stores the seed and the last payloads lets a developer replay the exact sequence and confirm the fix in a re-test. ## Sources - [ISO/SAE 21434:2021 Road vehicles, Cybersecurity engineering, clause 10 Product development (integration and verification)](https://www.iso.org/standard/70918.html) - [ISO 14229-1:2020 Road vehicles, Unified diagnostic services (UDS), Part 1: Application layer](https://www.iso.org/standard/72439.html) - [ISO 15765-2:2024 Road vehicles, Diagnostic communication over CAN (DoCAN), Part 2: Transport protocol and network layer services](https://www.iso.org/standard/84211.html) ## Related - [UDS Fuzzing vs CAN Fuzzing: Which Layer to Attack and What Breaks](https://auto-st.com/compare/uds-fuzzing-vs-can-fuzzing) - [Fuzzing vs Vulnerability Scanning on an ECU: What Each Method Finds](https://auto-st.com/compare/fuzzing-vs-vulnerability-scanning) - [A UDS fuzzing methodology that finds real bugs](https://auto-st.com/insights/uds-fuzzing-methodology) - [Break it on the bench, not in the field.](https://auto-st.com/ecu-fuzzing) - [DTC (Diagnostic Trouble Code)](https://auto-st.com/glossary/dtc) - [ISO-TP (ISO 15765-2)](https://auto-st.com/glossary/iso-tp) --- AutoST by Zyberum. Canonical page: https://auto-st.com/glossary/fuzzing