Fuzzing Monolithic Firmware

Fuzzing monolithic firmware has historically been quite challenging. This session covers the basics of firmware fuzzing and some differences compared to user-space fuzzing. Real firmware is then tested on Metalware's automated firmware fuzzing solution. An out-of-bounds write is found and further investigated with Metalware's Ghidra plugin.

What this presentation is about and why it matters

How do you fuzz monolithic firmware when there are no neat OS-style interfaces, and every peripheral looks different? Sam Lichtenheld uses a live demo to walk through an automated firmware fuzzing setup, starting from uploading an ELF or binary into a web app and then following the process through emulation, coverage feedback, and crash triage. The talk stays grounded in Cortex-M firmware, MMIO access, and debugger-assisted root cause analysis, so it is especially useful if you want to understand how fuzzing moves from theory into an embedded workflow. It suits people who care about embedded security, firmware reliability, or practical vulnerability discovery.

Who will benefit the most from this presentation

• Embedded security engineer who wants to fuzz firmware without building a custom harness for every peripheral
• Firmware developer working on Cortex-M code and wondering how fuzzing fits into existing debug workflows
• Product engineer or tech lead evaluating fuzzing for crash discovery and memory-corruption testing
• Debugger user who wants to connect emulator output, coverage, and source-level triage

What you need to know

A basic working knowledge of firmware debugging helps, especially if these terms are familiar:

• Cortex-M architecture and embedded firmware structure
• Memory-mapped I/O (MMIO)
• ELF files and raw binaries
• General debugging concepts such as breakpoints, watchpoints, and registers
• High-level familiarity with fuzzing as a testing approach

Glossary (terms used in this talk)

• Coverage guidance: A feedback loop where execution coverage determines which inputs are worth keeping and mutating further. Inputs that hit new basic blocks or branches are retained because they may lead to unexplored behavior.
• Fuzzing: A testing technique that feeds many unexpected or malformed inputs into a program to discover crashes, hangs, or surprising behavior. It is especially useful for code that parses external data or handles complex state transitions.
• Coverage-guided fuzzing: A fuzzing approach that uses execution feedback, usually code coverage, to steer future inputs toward newly reached program paths. The feedback loop helps the search dig deeper into complex code than purely random input generation.
• Emulator: A software environment that runs a target system or firmware image in a simulated form. Emulation can make it easier to observe execution, inject inputs, and automate testing without needing the physical device in hand.
• Intermediate Representation (IR): A normalized internal form used to describe programs or instructions in a way that is easier to analyze or transform than the original source or machine code. IRs are often used to make one tool architecture support many targets more easily.

Final thoughts

Practical and demo-driven, this session gives you a working view of how firmware fuzzing can be wired into an embedded security workflow. The value is less about abstract fuzzing theory and more about the shape of the process, how inputs are delivered, how feedback is used, and how a discovered crash is traced back through the system. It will help security-minded firmware engineers, debuggers, and teams exploring automated testing for embedded targets. The result is a clearer mental model for turning firmware into something you can probe systematically.

This overview is AI-generated from the session transcript. Spot an issue? Let us know.