UDS Fuzzing vs CAN Fuzzing: Which Layer to Attack and What Breaks

What is the difference?

UDS fuzzing works at the application layer of ISO 14229. The fuzzer speaks ISO-TP correctly enough to deliver a payload, then makes the payload wrong: a ReadDataByIdentifier (0x22) with 100 bytes instead of two, a RoutineControl (0x31) with a random routine identifier and garbage parameters, a TransferData (0x36) block larger than the RequestDownload agreed, service identifiers in the reserved ranges, sub-functions with the suppress-positive-response bit set in odd places. Between iterations it keeps the diagnostic session open with TesterPresent and re-enters it when the ECU drops back to default. The code under test is the diagnostic stack: request parsing, length checks, session and security state, the data handlers behind each DID and routine.

CAN fuzzing works at the data link layer of ISO 11898. There is no transport protocol and no request-response. The fuzzer puts frames on the bus using the arbitration IDs an ECU actually listens to, taken from a DBC, and mutates the payload: signal values out of physical range, rolling counters that skip, checksums that are wrong or right, DLC variations, classic and CAN FD frames. The code under test is the application: signal decoding, plausibility checks, state machines that react to a door-open or ignition-on signal, the gateway’s routing rules.

The two layers break differently. A UDS stack that mishandles a length check gives you a reset in the middle of a diagnostic session. An application that trusts a signal value gives you a motor controller acting on a speed of 65,535 km/h. Only one of these is visible to a diagnostic tester.

Side by side

	UDS fuzzing	CAN fuzzing
What it finds	Resets and hangs on malformed requests, length-check bugs in DID and routine handlers, TransferData and RequestDownload overflows, state-machine bugs across sessions, services that stop answering, DTCs raised by diagnostic input	Plausibility gaps in signal handling, counter and checksum bypass, reactions to out-of-range values, application faults and DTCs from bus input, gateways forwarding frames they should drop
What it misses	Everything in application signal handling; ECUs without a diagnostic endpoint	The diagnostic stack; anything that needs a multi-frame transport
Who does it	Test engineers from a dashboard; needs the ECU’s ISO-TP addresses, found by enumeration	Test engineers from a dashboard; needs the DBC for the ECU’s inputs
Bench time	Hours per campaign; session re-entry costs a little per iteration	Hours per campaign; frames are cheap, so iteration counts are high
Cost	Part of the AutoST fuzzing engine, licensed per component; free fuzzers exist	Part of the AutoST fuzzing engine; free tools exist (can-utils, Scapy, CaringCaribou)
Fits a release cycle	Yes, seeded and bounded; a short run per build, a long run per release	Yes, same mechanism; a reproduce count confirms a finding before it is logged
Required by	ISO/SAE 21434 [RC-10-12] recommends fuzz testing of components; expected for diagnostic interfaces from CAL 2 in practice	The same recommendation; expected for bus interfaces of safety-relevant ECUs in practice
Output	Findings with iteration, payload, monitor and payload history, replayable by seed; PDF and SARIF	The same, with the arbitration ID and frame; replayable by seed

Choose UDS fuzzing when

• The ECU has a diagnostic stack worth attacking: a bootloader with 0x34, 0x36, 0x37, routines that start calibrations or clear memory, a programming session reachable on the bench.
• You want findings a developer can act on quickly. A UDS finding names the service, the sub-function and the payload; the handler is easy to locate.
• You have no DBC. Enumeration gives you everything UDS fuzzing needs.
• The ECU is reachable over DoIP. UDS fuzzing moves to Ethernet unchanged, CAN fuzzing does not.

Choose CAN fuzzing when

• The ECU’s job is to react to bus signals: body, chassis, powertrain, gateway. Its risk is in what it does with a wrong value, not in what its diagnostic stack says.
• The ECU has little or no diagnostic surface, or diagnostics are locked down and the open attack surface is the bus itself.
• You suspect gateway or filtering issues: frames from a less trusted bus reaching a more trusted one.
• You test on CAN FD with longer payloads and want to see how 64-byte frames are handled by code written for eight.

Both together

A real ECU is attacked on both layers and a serious campaign fuzzes both. The order is enumeration, UDS fuzzing, CAN fuzzing: enumeration gives you the ISO-TP endpoints and tells you what to exclude (nobody wants an ECUReset on iteration one), UDS fuzzing exercises the diagnostic stack while the session is alive, and CAN fuzzing with the DBC exercises the application. The crash detection is shared, so a frame that silently kills the diagnostic responder shows up the same way as a malformed request.

AutoST runs both modes from the same component with a stored seed, a liveness check after every iteration and optional DTC monitoring, and both land in one Fix Plan. Fuzzing of any kind is a bench activity: never on a vehicle in traffic, always with a way to reflash the ECU. And a clean fuzzing run on both layers still says nothing about the seed/key algorithm or the update path; those need a person.