FuzzBox: Embedded Fuzzing Framework

• FuzzBox is a QEMU-based emulation fuzzing framework designed for binary-only embedded targets, enabling grey-box, coverage-guided testing without source recompilation.
• It leverages dynamic interception and guest-state manipulation through QEMU plugins to perform both pre- and post-invocation fuzzing with detailed coverage tracking.
• It proves effective for proprietary RTOS, hypervisors, and commercial firmware, achieving significant edge coverage gains and up to 2× throughput improvements over baselines.

FuzzBox is a QEMU-based, full-system emulation fuzzing framework for binary-only embedded targets that enables grey-box, coverage-guided fuzzing without source-code recompilation, in-target fuzz drivers, or hardware tracing features. Introduced by Carmine Cesarano and Roberto Natella, it blends fuzzing into emulation by intercepting target function calls during virtualized execution, injecting fuzzed parameters through guest-state modification, and collecting coverage and failure feedback inside the emulator. Its intended domain includes proprietary RTOS, hypervisor, and firmware stacks for which conventional source-based instrumentation is unavailable or impractical (Cesarano et al., 6 Sep 2025).

1. Problem setting and design goals

FuzzBox addresses a setting in which conventional coverage-guided fuzzing assumptions break down. Standard grey-box fuzzers generally rely on source-level instrumentation, binary rewriting on supported platforms, or hardware tracing and debugger support. In industrial embedded systems, those assumptions frequently fail because the target is binary-only, the toolchain is proprietary or outdated, the execution environment spans user code, kernel code, and hypervisor code, and hardware-assisted tracing interfaces may be absent. The framework is therefore organized around five recurring constraints: binary-only targets, non-intrusive testing requirements, toolchain independence, hardware independence, and full-system scope (Cesarano et al., 6 Sep 2025).

The motivating case is a proprietary VxWorks MILS environment, but the design is broader. FuzzBox is intended for targets such as full firmware images, RTOS applications, kernels, and separation kernels that can run under QEMU system emulation. This distinguishes it from user-space-only fuzzing setups and from approaches that assume recompilation with LLVM or GCC coverage instrumentation. In contextual terms, this places FuzzBox between rehosting-based firmware fuzzers that still assume access to firmware binaries and MMIO-oriented modeling pipelines, such as ES-FUZZ (Huang et al., 2024), and fully black-box approaches such as power-trace-guided firmware fuzzing, exemplified by PowerFuzz (Tharindu et al., 23 Jun 2026).

2. Architecture and execution model

FuzzBox runs unmodified targets in QEMU 7.0 full-system mode. For the MILS case study, the implementation extends QEMU with board support for the MPC8548E / SBC8548E PowerPC platform. The central instrumentation mechanism is a QEMU Tiny Code Generator plugin that observes translation blocks during dynamic translation and registers callbacks at configured fuzzing entry points. When such a callback fires, the framework pauses the virtual machine, inspects guest state, optionally overwrites guest registers or memory, and resumes execution (Cesarano et al., 6 Sep 2025).

This architecture supports both pre-invocation and post-invocation fuzzing. Pre-invocation fuzzing applies when a target function consumes caller-provided inputs. Post-invocation fuzzing applies when the function fills an output buffer, as with recvfrom(): FuzzBox records the buffer location before the call and mutates the contents after the call returns, preventing the callee from overwriting the injected test case. To make this practical inside QEMU, the implementation adds APIs such as get_cpu_register() and vcpu_read_phys_mem(), together with guest-state overwrite primitives. Function arguments may be extracted from registers, from the guest stack, or through pointer dereferences in guest memory according to architecture-specific calling conventions.

The framework’s coverage collection is derived from AFL’s QEMU mode but extended from Linux user-space binaries to full-system emulation. It supports both basic-block coverage and edge coverage. Because full-system execution includes timer interrupts, context switches, and other activity unrelated to the fuzz target, FuzzBox performs a pre-analysis phase that repeatedly runs the system with unmodified inputs and blacklists spurious blocks or edges that appear during idle or non-fuzz-related execution. This reduces noise in feedback arising from system-level nondeterminism rather than from the fuzzed interface itself (Cesarano et al., 6 Sep 2025).

3. Fuzzing workflow, seed handling, and failure detection

FuzzBox uses a two-stage workflow. In seed recording mode, the target executes normally while the framework intercepts a configured function, records its observed arguments as seeds, and may save the virtual-machine state at the interception point as an initial fuzz state for snapshot-based fuzzing. In intercept-and-fuzz mode, the framework selects recorded seeds, mutates them through LibAFL, and injects the resulting inputs at subsequent invocations of the configured entry point. Inputs that trigger new coverage are retained in the corpus in the usual grey-box style (Cesarano et al., 6 Sep 2025).

The framework does not introduce a new mutation algorithm. Its contribution lies in harnessing, input injection, full-system coverage collection, and crash observation for environments in which ordinary grey-box fuzzing would otherwise be unavailable. This makes FuzzBox an enabling architecture rather than a replacement for mutational back ends.

Failure detection is configuration-driven. The framework can intercept target-specific crash-management routines, generic functions such as abort, exit, and assert, or kernel facilities such as do_coredump(). In the MILS case study, crash detection is tied to schedSuspendVb(). This avoids relying exclusively on timeout-based liveness checks and yields a tighter failure oracle inside emulation. The framework also mentions hang detection, although the design emphasis is on intercepting internal failure events rather than on a detailed generic hang-classification mechanism (Cesarano et al., 6 Sep 2025).

A practical consequence of this architecture is that FuzzBox assumes the evaluator can identify a useful fuzzing entry point, determine the relevant arguments, and configure the interception mode. The reported setup cost for a new target is typically 30 minutes to a few hours. This suggests a model closer to target-guided interface fuzzing than to fully automatic whole-image fuzzing.

4. MILS evaluation

The principal evaluation targets Wind River VxWorks MILS, a Multiple Independent Levels of Security hypervisor used in high-assurance industrial sectors. Because the proprietary guard application could not be disclosed, the experiments use three POSIX-compliant parsing libraries ported into a simplified MILS gateway design: json-parser, sendmail, and TinyExpr. Each library appears in two vulnerable variants, labeled easy and hard, for a total of six targets. The injected bugs are LAVA-style memory-violation faults intended to resemble embedded vulnerability classes (Cesarano et al., 6 Sep 2025).

Across these six MILS targets, FuzzBox reports an average edge-coverage improvement of 57.37% over the black-box-style baseline. Within the reported time windows, the measured edge-coverage deltas are +10.66% for json_easy, +128.13% for json_hard, +123.80% for sendmail_easy, -1.52% for sendmail_hard, +4.98% for tinyexpr_easy, and +78.18% for tinyexpr_hard. The single negative result indicates that the framework is not uniformly superior in shallow cases, but the overall pattern favors FuzzBox on deeper paths and harder bugs (Cesarano et al., 6 Sep 2025).

Time-to-crash results follow the same pattern. FuzzBox is faster on json_easy, json_hard, sendmail_easy, sendmail_hard, and tinyexpr_hard, while the baseline is faster on tinyexpr_easy. The authors interpret this as evidence that FuzzBox is especially effective on hard-to-reach bugs, whereas trivial bugs may sometimes be found quickly even by a simpler setup. Throughput measurements likewise favor FuzzBox: 47.92 versus 23.05 inputs/s on json, 53.09 versus 24.65 on sendmail, and 40.68 versus 20.90 on tinyexpr, or roughly a $2\times$ advantage. The reported explanation is that emulator-side coverage and injection overhead are outweighed by the baseline’s communication and waiting overhead (Cesarano et al., 6 Sep 2025).

5. Portability to commercial IoT firmware

To evaluate portability beyond MILS, FuzzBox is applied to three commercial Linux-based firmware images: TENDA AC15 on ARM little endian, TEW-651BR on MIPS big endian, and DCS-932L on MIPS little endian. In these experiments the framework intercepts recvfrom(). Before the call it records the output-buffer address and return address; after the call it mutates the received request buffer in place. Linux crash detection is performed by intercepting do_coredump() (Cesarano et al., 6 Sep 2025).

The vulnerability targets are known CVEs in HTTP-facing handlers: CVE-2018-16333 on TENDA AC15, CVE-2019-11400 on TEW-651BR, and CVE-2019-10999 on DCS-932L. In rediscovery experiments, FuzzBox triggers the crashes in 25 versus 39 iterations, 114 versus 145 iterations, and 13 versus 13 iterations, respectively, compared with the baseline. Coverage curves are described qualitatively: FuzzBox outperforms the baseline in two of the three firmware cases and is comparable in the third (Cesarano et al., 6 Sep 2025).

These firmware experiments are less dramatic than the MILS results, but they serve a different purpose. They show that the same emulation-and-interception design is applicable across PowerPC, ARM, and MIPS targets, and across both proprietary hypervisor-style systems and commercial Linux firmware.

6. Position in the fuzzing landscape, strengths, and limitations

FuzzBox is best understood as a system-level grey-box fuzzing substrate for environments in which conventional grey-box fuzzing is otherwise infeasible. Its strengths are non-intrusiveness, toolchain and hardware independence, full-system scope, and cross-architecture applicability. It neither depends on source-code recompilation nor on hardware tracing features such as Intel PT. Compared with emulation-based firmware fuzzers that focus on MMIO or IRQ semantics, such as ES-FUZZ (Huang et al., 2024) and FIDO (Shen et al., 16 May 2026), FuzzBox operates at a lower harnessing layer: dynamic interception of entry points and guest-state manipulation inside QEMU. Compared with PowerFuzz, which reconstructs path information from external power measurements in a fully black-box physical setup, FuzzBox assumes emulatability and guest introspection but avoids laboratory side-channel instrumentation (Tharindu et al., 23 Jun 2026).

Its limitations are equally structural. Emulation fidelity is the most obvious: inaccurate peripheral or board models can cause both false positives and false negatives. The framework also assumes that useful fuzz targets can be identified manually, often with symbol information or reverse engineering. Manual configuration is required for target function addresses, argument semantics, selective offsets and lengths, architecture profiles, and crash handlers. The paper also notes complications from stripped binaries, unsupported peripherals, and ASLR. Although snapshot-based fuzzing is mentioned, the implementation does not provide a detailed fast-reset design comparable to highly optimized forkserver-based fuzzers (Cesarano et al., 6 Sep 2025).

A plausible implication is that FuzzBox is most valuable as an enabling layer in testing pipelines where binary-only constraints, proprietary toolchains, or system-level scope rule out more standard approaches. In such settings, its chief contribution is not a better mutator but the restoration of grey-box fuzzing itself as a viable testing mode.