Fuzzing for Embedded

Overview

Automated input-generation testing (libFuzzer, AFL++, honggfuzz) adapted to firmware. Typically done by extracting parsers and protocol handlers and running them on host with sanitizers, or by fuzzing on-target through QEMU/Renode/Unicorn. Increasingly common for protocol stacks, file parsers, and bootloaders.

Benefits

• Finds crashes and sanitizer-detectable undefined behavior that humans miss
• Especially effective for security-critical input parsers (USB, BLE, CoAP, file formats)
• Pairs with ASan/UBSan/MSan for richer crash signals
• Surfaces many CRA-relevant vulnerabilities cheaply

Limitations & Risks

• Requires harness-extraction work to make embedded code host-runnable
• On-target fuzzing needs an emulator or fault-injection rig
• Coverage feedback is harder to obtain on-target than on host

Recommended Actions

Pick one or two security-critical parsers in your firmware (BLE GATT, USB descriptors, CoAP, OTA image headers), build a host-side libFuzzer harness with AddressSanitizer, and run it on every PR through CI.

Additional Notes

Strongly complements Property-Based Testing and DevSecOps. Many CRA-relevant vulnerabilities surface first in fuzzing rather than functional tests.

References & Links

• https://llvm.org/docs/LibFuzzer.html
• https://aflplus.plus/
• https://google.github.io/oss-fuzz/