ECU Fuzzing Explained: Finding Bugs in UDS, DoIP and SOME/IP
How fuzz testing works for automotive ECUs, which protocols to target, how to detect crashes on real hardware and how fuzzing supports ISO/SAE 21434.
Zyberum Security Team · Published · 7 min read
Fuzz testing sends malformed, unexpected or random data to a system and watches for failures. For automotive ECUs it is one of the most effective ways to find memory-safety bugs and robustness issues in protocol stacks before attackers or the field find them.
Why fuzz ECUs?
ECUs parse untrusted input all the time: diagnostic requests over UDS, service calls over SOME/IP, frames on CAN, packets over Ethernet. These parsers are usually written in C or C++, often reused across generations and rarely tested with hostile input. A single out-of-bounds write in a diagnostic handler can lead to a denial of service, or worse, code execution on a safety-relevant controller.
What to fuzz
| Interface | Typical targets |
|---|---|
| UDS (ISO 14229) over CAN / DoIP | Session control, ReadDataByIdentifier, WriteDataByIdentifier, SecurityAccess, RoutineControl, transfer services |
| DoIP (ISO 13400) | Vehicle identification, routing activation, diagnostic message framing |
| SOME/IP and SOME/IP-SD | Service discovery, method calls, serialisation of payloads |
| CAN / CAN FD | Signal decoding, ISO-TP segmentation, gateway routing |
| Wireless (Bluetooth, Wi-Fi) | Pairing, profiles, management frames on IVI and telematics units |
Three flavours of fuzzing
- Random (dumb) fuzzing: random bytes or frames. Cheap and fast, good at finding shallow parser issues, but most inputs are rejected early.
- Protocol-aware (generation-based) fuzzing: inputs are generated from a protocol model, for example valid UDS service IDs with mutated sub-functions and lengths. It reaches much deeper code paths.
- Database-driven fuzzing: uses ODX/CDD diagnostic databases to know which DIDs and routines exist, their data types and lengths, and then mutates exactly those. This is the most efficient approach when databases are available.
Detecting failures on real hardware
Unlike software fuzzing, you usually cannot attach a sanitizer to an ECU. Instead, fuzzers use oracles:
- Liveness checks: the ECU still answers a TesterPresent or a known DID
- Unexpected resets: session drops, ECU reset responses, DTCs set
- Timing anomalies: response times far outside the baseline
- Bus-level effects: missing cyclic messages from the ECU under test
- Power and current monitoring on the bench
Every anomaly should be stored with the exact input sequence so it can be reproduced and triaged by developers.
Making fuzzing part of the release process
The biggest benefit comes when fuzzing is not a one-off activity but runs on every software release:
- Run campaigns on a bench or HIL rig in CI
- Track findings per ECU and software version
- Link results to the TARA and cybersecurity requirements for ISO/SAE 21434 evidence
That is exactly the workflow our AutoST security testing suite automates, with fuzzing engines for UDS, DoIP, SOME/IP and CAN/CAN FD. For deeper manual analysis, our team offers automotive penetration testing.
FAQ
Frequently asked questions
What is fuzz testing?
Fuzz testing (fuzzing) is an automated technique that sends large numbers of invalid, unexpected or random inputs to a program or device in order to trigger crashes, hangs or other abnormal behaviour that indicate bugs and potential security vulnerabilities.
Is fuzzing required by ISO/SAE 21434?
ISO/SAE 21434 names fuzz testing as one of the recommended methods for cybersecurity verification, alongside functional testing, vulnerability scanning and penetration testing. OEMs increasingly require fuzzing reports from suppliers.
Can fuzzing damage an ECU?
It can put an ECU into unexpected states, for example by triggering write or flash routines. That is why fuzzing should be run on bench samples, with a controlled reset mechanism, and with care when services like RoutineControl or RequestDownload are in scope.