Fuzzing
Fuzzing feeds a program or device large numbers of malformed inputs to find crashes and security bugs. The methods, where standards ask for it, and how it works on ECUs.
Updated This page as Markdown
In short
Fuzzing (fuzz testing) is an automated test technique that sends large numbers of unexpected, malformed or random inputs to software or a device and watches for crashes, hangs and other abnormal behaviour that point to bugs. ISO/SAE 21434 and IEC 62443-4-1 name it among the verification methods, the Cyber Resilience Act requires regular security testing. On ECUs and IoT devices the challenge is less generating inputs than reliably detecting failures on real hardware.
What is fuzzing?
Fuzzing is a software testing technique that automatically feeds a program with unexpected, malformed or semi-malformed inputs to identify bugs, vulnerabilities and unexpected behaviour, as OWASP defines it. The fuzzer generates inputs, delivers them and observes the target: a crash, a hang, a reset, a memory error or a wrong response indicates a bug that a human tester would rarely have reached by hand.
Fuzzers differ in how they generate inputs. Mutation-based fuzzers take valid samples and flip, insert and delete bytes. Generation-based or protocol-aware fuzzers build inputs from a model of the format or protocol, so they get past the first length check and reach deeper code. Coverage-guided fuzzers such as AFL++ or libFuzzer instrument the program, keep inputs that reach new code and mutate from there; they are the most effective where the code can be compiled with instrumentation. For a device on a bench, where the code cannot be instrumented, protocol-aware fuzzing with careful failure detection is the workable approach.
Where is it defined?
No standard defines fuzzing itself, but several require it or recommend it. ISO/SAE 21434 names fuzz testing, together with functional testing, vulnerability scanning and penetration testing, among the methods for cybersecurity verification during product development (clause 10). IEC 62443-4-1 lists it within the security verification and validation practice for industrial components. The Cyber Resilience Act requires in Annex I Part II that manufacturers apply effective and regular tests and reviews of the security of the product with digital elements.
What it means in practice
Fuzzing is one of Zyberum’s core activities, and the basis of our product AutoST. On embedded targets the hard part is not generating inputs but seeing what they did. A server crashes visibly; an ECU silently resets, drops a diagnostic session or stops responding to one service while everything else keeps working. We therefore instrument the environment rather than the code: a heartbeat such as UDS TesterPresent, monitoring of reset lines or power consumption, a debugger where one is available, and comparison of every response with the expected behaviour.
Where we apply it:
- Diagnostic and vehicle protocols: UDS over CAN and DoIP, ISO-TP segmentation, SOME/IP and its service discovery. Protocol-aware fuzzing of these stacks on power-electronics ECUs has found parsers that reset the ECU on specific malformed lengths and sequences. With the diagnostic database (ODX or CDD) we fuzz exactly the identifiers and routines that exist, which is far more efficient than random bytes.
- Infotainment platforms: kernel and driver interfaces on embedded Linux and Android, and the interface between the normal world and the trusted execution environment, where a crash in a trusted application matters more than anywhere else in the system.
- IoT devices: MQTT brokers, proprietary radio protocols, Bluetooth stacks and firmware update parsers.
A fuzzing result is a starting point, not a finding. Every crash is reproduced, minimised to the shortest input, and analysed in the firmware to decide whether it is a denial of service, a memory corruption that could become code execution, or a harmless watchdog reset. The report states that assessment, the reproduction steps and the fix.
Common misunderstandings
Fuzzing does not find everything: logic flaws, weak authentication designs and missing access control are invisible to it, which is why it complements a penetration test rather than replacing one. Random bytes are not fuzzing in any useful sense on a protocol with checksums and length fields; the fuzzer must know the protocol. And a fuzzer that reports zero crashes has shown nothing unless you know what it covered; coverage, not run time, is the measure.
FAQ
Frequently asked questions
What does fuzzing find that a penetration test does not?
Memory safety and robustness bugs in parsers that a human would never hit by hand: an off-by-one in a length check, a state machine that breaks after a specific sequence of ten requests, a protocol handler that locks up on a truncated message. A penetration tester finds logic and design flaws; a fuzzer finds the thousand malformed inputs nobody thought about. Good engagements combine both.
Can fuzzing damage the device under test?
It can put it into states that are hard to recover from, for example by triggering a write or flash routine with corrupt data. That is why we fuzz bench samples, keep a controlled power and reset path, and agree in advance which services are in scope. Series ECUs in a vehicle are not fuzzed without that setup.
Is fuzzing required by a standard?
ISO/SAE 21434 names fuzz testing among the methods for cybersecurity verification in product development, IEC 62443-4-1 includes it in its vulnerability testing practice, and the Cyber Resilience Act requires effective and regular security tests of the product. None of them prescribes a tool or a duration; the manufacturer decides how, and documents it.
Sources
Related pages
- InsightsECU Fuzzing Explained: Finding Bugs in UDS, DoIP and SOME/IPHow fuzz testing works for automotive ECUs, which protocols to target, how to detect crashes on real hardware and how fuzzing supports ISO/SAE 21434.
- GlossaryUDS (Unified Diagnostic Services)UDS, Unified Diagnostic Services per ISO 14229, is the diagnostic protocol of nearly every ECU. Which services exist, how access control works and what to test.
- GlossarySAST and DASTSAST analyses source code, DAST attacks the running application. What each finds and misses, where they fit in the pipeline, and why neither replaces a penetration test.
- ComparisonsManual vs Automated Penetration Testing: What Tools Find and What People FindAutomated tools find known weaknesses fast and repeatably. Manual testers find logic flaws, chains and anything new. Where the line runs and how to combine both.
- ServicesAutomotive Security Testing, automated.AutoST automates ECU fuzzing, security tests and vulnerability scanning over UDS, CAN FD, DoIP and SOME/IP, producing evidence for UN R155 and ISO/SAE 21434.
- ServicesFind the vulnerabilities in your vehicle before attackers do.ECU and vehicle penetration testing, fuzzing, TARA and ISO/SAE 21434 consulting to meet UN R155/R156. Hands-on automotive security experts from Germany.
