Signal Breaker: Fuzzing Digital Signal Processors

Fuzzing — throwing mutated random inputs at software to find crashes — has hardened almost everything except the tiny digital signal processors in phones, cars, and defense systems, because these bare-metal chips have no operating system, no emulator, and only a slow debug link, and they do not even crash cleanly; this paper (Virginia Tech — Cameron Santiago Garcia and Matthew Hicks) presents SBFUZZ, which splits the fuzzing loop so the DSP runs most of it autonomously and a host helps only periodically, fuzzing 17 times faster than prior embedded approaches and finding 34 bugs.

The argument in one glance

Problem

Fuzzing has hardened almost everything except DSPs

Fuzzing is one of the most effective ways to find software vulnerabilities: a coverage-guided fuzzer generates test inputs by randomly mutating previous ones, runs them against the software, watches which code paths each input exercises, keeps the inputs that reach new code, and mutates those further — steadily driving the program into unexplored, buggy corners and flagging crashes. It has been applied with great success to applications, operating systems, general-purpose processors, and network protocols, making it one of the most widely-adopted testing methodologies. Yet it has barely touched Digital Signal Processor (DSP) software. DSPs sit right at the boundary of hardware and software: they ingest signals from the physical world (through analog-to-digital converters), execute software instructions on those signals, and are tightly woven into data-processing pipelines. And they run in places where correctness really matters — telecommunications, transportation, and defense — so bugs in DSP software are a serious safety and security concern. The gap is not that DSPs do not need testing; it is that they are unusually hostile to the fuzzing techniques everyone else uses, so a whole class of critical, physically-connected software has gone essentially un-fuzzed.
What people did

Point an embedded-systems fuzzer at the DSP

The natural move is to reuse the fuzzers built for embedded systems and microcontrollers. Those tools typically lean on one of two things: an operating system on the device, whose process and system utilities let a fuzzing engine drive and monitor execution the way it would on a desktop; or an emulator that can "re-host" the firmware, running it on a fast host computer so the fuzzer can execute and instrument it at high speed. Either way, you attach the fuzzer, feed the device mutated inputs, and watch for crashes.
Why it fell short

DSPs break every assumption embedded fuzzers rely on

Applied to a DSP, each of those assumptions fails, for three linked reasons. First, interfaces: a DSP is bare-metal, and it exposes only limited, high-latency control and communication channels — a slow debug link to a host — so driving and observing it the way an OS-based fuzzer would is painfully slow, and every round-trip to a host to inject an input or read back coverage is expensive. Second, architecture: DSPs have unusual, specialized architectures and no operating system, so the standard instrumentation and mutation routines embedded fuzzers use do not apply — drivers and utilities would have to be written from scratch — and there is no emulator available to re-host and fuzz them at speed, removing the emulation-based path entirely. Third, bug manifestation: an ordinary program crashes with a clean signal a fuzzer can catch, but a bare-metal DSP has no such error handling — on a fault it just spins in an interrupt vector or stalls completely, and, worse, some bugs (especially hardware-style ones) do not stop the program at all but make its execution diverge from correct behavior while continuing to run. So a DSP fuzzer must detect both crashes and this divergent-yet-continuing execution. Between the slow interfaces, the missing OS and emulator, and the murky failure signals, naively pointing an embedded fuzzer at a DSP is slow, shallow, and blind to whole classes of bugs. What was missing was a fuzzer designed around the realities of a DSP.
This paper's idea

Let the DSP fuzz itself, with a host helping periodically

SBFUZZ (Signal Breaker) is a coverage-guided, mutational fuzzer built specifically for DSP software, and its central idea is a DSP-centric decomposition of the fuzzing loop. Rather than driving the DSP from a host over the slow link, SBFUZZ takes a semi-hosted approach: it splits the traditional fuzzing loop into DSP-based and host-based parts, and gives the DSP as much of the work as possible so it can run autonomously without paying for constant host round-trips. The DSP itself performs the hot inner loop — mutating test cases, executing them, and tracing coverage — while a more powerful host periodically steps in for the heavier coordination, analysis, and storage: managing the pool of interesting inputs, storing crashes, and maintaining global coverage. Because the DSP does most of the work on its own, a single host can concurrently fuzz many DSP devices, and the same design supports both physical DSPs and simulated DSPs for re-hosted fuzzing. To make this work on bare metal, SBFUZZ introduces DSP-specific instrumentation and a coverage-tracing technique that records which code was reached without the usual runtime overhead or OS support — for instance, once a location's coverage has been recorded, its tracing code is overwritten with no-ops so it stops costing time. And it is built to catch both traditional crashes and the divergent-but-continuing execution that signals hardware-style bugs. Prototyped on a Texas Instruments TMS320C5515 DSP and evaluated on 15 DSP benchmark programs, SBFUZZ achieves 17.4 times higher throughput and 2.6 times greater code coverage than prior embedded fuzzing approaches applied to DSPs, uncovering 2,491 unique crashes that yield 34 unique bugs.

Why this problem is worth solving

DSPs run critical code in the physical world and had no effective fuzzer, so closing that gap directly hardens systems that safety and security depend on.

Fuzzing has become the default way to find vulnerabilities precisely because it is automated, effective, and broadly applicable — it has hardened huge swaths of the software stack. But a technique that covers everything except one important class leaves that class as a soft target, and DSPs are exactly such a class. They are not obscure: they are the chips that turn the analog world into digital signals for phones and radios, that process sensor data in vehicles, and that run in defense systems, and they sit in the data path of pipelines where a wrong result or a hijack can have physical consequences. Because they are cyber-physical and safety-critical, a bug in DSP software is not just a crash but potentially a safety failure or a security breach in a system people rely on. Yet the very properties that make them useful — bare-metal, specialized, tightly resource-constrained — are what made them resistant to the fuzzers that harden everything else, so their software has gone largely untested by the most effective method available. Building a fuzzer that actually works on DSPs therefore extends automated vulnerability discovery to a domain that badly needs it, and the payoff is concrete: an order-of-magnitude more throughput, more coverage, and dozens of real bugs found. In security, coverage of the whole attack surface matters, and DSPs had been a blind spot.

The key realization is that the DSP’s slow host link is the enemy, so the fuzzer must run its hot loop on the DSP and touch the host only occasionally.

The instinctive way to fuzz a device is to run the fuzzing engine on a capable host and use the device just to execute test cases, because the host is fast and flexible. For most embedded targets that works, because they have an OS to cooperate with or an emulator to run them in. A DSP offers neither, and its only connection to a host is a slow, high-latency debug interface. That single fact poisons the host-driven approach: if every test case must be shipped to the DSP and every coverage result read back over that link, the fuzzer’s throughput collapses to the speed of the interface, and fuzzing is a numbers game where throughput is everything. SBFUZZ’s insight is to invert the usual split. Instead of the host doing the work and the DSP executing, the DSP does the work — mutation, execution, and coverage tracing all happen locally, in a tight loop that never leaves the chip — and the host is demoted to periodic assistance, handling only the parts that genuinely need more resources (organizing the input pool, storing crashes, aggregating global coverage) and that can tolerate being done in batches rather than every iteration. This keeps the expensive interface off the critical path. The follow-on realizations make it feasible: because the DSP has no OS and little memory, the coverage instrumentation must be custom and cheap — hence tricks like overwriting tracing code with no-ops once a block is covered — and because a DSP does not crash cleanly, the fuzzer must recognize both stalls and divergent-continuing execution as bug signals. Minimizing dependence on the slow host, by maximizing what the constrained device does itself, is what turns DSP fuzzing from impractical into fast.

What people did before, and where it broke

Use an OS-based embedded fuzzer. Rely on the device’s operating system utilities to drive and monitor fuzzing. Where it broke. DSPs are bare-metal with no OS, so those utilities do not exist and drivers would have to be written from scratch.
Re-host the firmware in an emulator. Run the DSP code on a fast host emulator to fuzz it at speed. Where it broke. DSPs lack the emulation resources embedded fuzzers rely on, so emulation-based fuzzing is not available.
Drive the DSP from a host over its debug link. Send inputs and read coverage across the device-host interface each iteration. Where it broke. That interface is limited and high-latency, so per-iteration round-trips throttle throughput, and fuzzing depends on throughput.
Detect bugs by watching for crashes. Use standard crash signals to find faults. Where it broke. A bare-metal DSP has no clean crash handling; it stalls or spins, and hardware-style bugs make it diverge while continuing to run, so crash-only detection misses them.
The gap. No fuzzer was designed around DSP realities — running the loop on-device to avoid the slow link, instrumenting without an OS, and detecting both crashes and divergent execution — leaving critical DSP software un-fuzzed.

How SBFUZZ works

From host-driven embedded fuzzing to a DSP-centric split loop

↓ →
new
↓ →
new
↓ →
new
↓ →
new
↓ →
new

The idea

Bring coverage-guided fuzzing to a critical, physically-connected target that lacked it. SBFUZZ extends the most effective vulnerability-discovery method to DSP software, a cyber-physical class of code that ordinary fuzzers could not reach. Adapting automated, coverage-guided fuzzing to a specialized embedded, physically-interfacing system that standard tools do not handle is the same enterprise the work on multi-dimensional, message-guided fuzzing for robotic programs (message-guided fuzzing) covered elsewhere on this site pursues, taking fuzzing into a cyber-physical domain with its own quirks. SBFUZZ targets DSPs, where the physical signal interface and bare-metal nature are the quirks.

Design the technique around the embedded device’s constraints instead of forcing generic tools. SBFUZZ builds custom, low-overhead instrumentation and an on-device loop shaped to a DSP’s lack of OS, emulator, and memory, rather than importing a desktop or general-embedded approach. Tailoring a security technique to the specific realities and limits of an embedded architecture, instead of applying a one-size-fits-all method, is the same principle the work on security hardening that recognizes one size does not fit all for MIPS embedded systems (embedded hardening) covered elsewhere on this site is built on, fitting the method to the device. SBFUZZ fits fuzzing to the DSP.

Detect misbehavior at the hardware-software boundary, not just clean crashes. Because a DSP can fault silently or diverge while running, SBFUZZ watches for both crashes and divergent-continuing execution, catching hardware-style bugs a crash-only fuzzer would miss. Testing a piece of hardware by looking for deviations from expected behavior — including subtle ones that do not simply crash — is the same approach the work on testing black-box CPUs against speculation contracts (Revizor) covered elsewhere on this site takes, treating divergence from a correctness expectation as the bug signal. SBFUZZ applies that mindset to bugs that surface as divergent DSP execution.

Following a test case through SBFUZZ

Fuzzing one input on the DSP

A trace, drawn from the paper, of how SBFUZZ runs the fuzzing loop on-device with periodic host help.

Step 1 of 5

The DSP mutates a test case locally

On the DSP, SBFUZZ takes an interesting input from its local pool and mutates it randomly to produce a new test case, all without contacting the host.

Keeping mutation on-device avoids the slow host round-trip.

Why it works

Keeping the loop on-device dodges the slow interface. A host-driven loop pays the high-latency link every iteration → but running mutation, execution, and coverage on the DSP → so the expensive interface leaves the critical path and throughput soars.
Periodic host help handles what the DSP cannot. The DSP is too resource-limited for pool management and storage → but a powerful host assisting in batches → so heavy coordination is done without slowing the inner loop.
Custom cheap instrumentation fits bare metal. Standard instrumentation needs an OS and adds overhead the DSP cannot afford → but tracing that self-disables (no-ops) once a block is covered → so coverage is recorded without commensurate runtime cost.
Detecting divergence finds bugs crashes miss. A DSP does not crash cleanly, so crash-only detection is blind → but treating divergent-yet-continuing execution as a signal → so hardware-style bugs are caught, not overlooked.
One host driving many DSPs scales the campaign. A host bottlenecked on one device would be idle → but autonomous DSPs needing only periodic help → so a single host concurrently fuzzes many devices, physical or simulated.

What it costs (trade-offs and scope)

It requires porting the loop onto the DSP. SBFUZZ’s speed comes from running mutation, execution, and instrumentation on bare metal without an OS, which means building the DSP-side machinery for the target architecture rather than reusing a generic engine.
The host still does essential work. The design is semi-hosted, so a host is still needed for pool management, crash storage, and global coverage; the DSP is autonomous for the inner loop but not fully independent.
Instrumentation is DSP-specific. The low-overhead coverage tracing is designed around the DSP’s memory limits and custom hardware, so it must be adapted per architecture, not applied uniformly across all DSPs.
Divergence detection defines the bug oracle. Catching hardware-style bugs relies on recognizing divergence from expected behavior; the strength of that oracle bounds which non-crashing bugs are found.
Reported figures are on a specific DSP and baseline. The 17.4-times throughput, 2.6-times coverage, 2,491 crashes, and 34 bugs are measured on a TI TMS320C5515 across 15 benchmarks against prior embedded fuzzing; results depend on the DSP, programs, and comparison.

The comparison

Fuzzing digital signal processor software

Property	OS-based embedded fuzzer	Emulator re-hosting	SBFUZZ
Works on a bare-metal DSP
Where the loop runs
Handles the slow link
Detects non-crashing bugs
Throughput and coverage

A comparison of ways to fuzz DSP software. OS-based and emulator-based embedded fuzzers do not fit bare-metal DSPs, and host-driven fuzzing over the slow debug link is throughput-bound. SBFUZZ runs the fuzzing loop on the DSP itself (mutation, execution, coverage) with a host assisting periodically, and detects both crashes and divergent execution — reaching 17.4 times the throughput and 2.6 times the coverage of prior approaches on a TI TMS320C5515, finding 34 bugs. Exact figures should be read from the paper.Underlined values explain themselves when clicked.

Where this stops working

What to keep in mind

This explainer is based on the paper’s abstract together with the author’s Master’s thesis version of the same work (hosted at Virginia Tech’s VTechWorks), used for the method; the exact ASPLOS 2026 conference paper full text was not retrieved. The described system is the authors’: SBFUZZ (Signal Breaker) is a coverage-guided, mutational fuzzer for DSP software that takes a semi-hosted approach, decomposing the fuzzing loop into DSP-based and host-based components. The DSP performs most fuzzing tasks autonomously (mutation, test-case execution, coverage tracing), while a more powerful host periodically handles coordination, analysis, and storage (input-pool management, crash storage, global coverage), so a single host can concurrently fuzz multiple devices, and the design supports both physical and simulated (re-hosted) DSPs. It uses DSP-specific instrumentation and a low-overhead coverage-tracing technique (for example, overwriting tracing code with no-ops once coverage is recorded) that avoids the usual runtime overhead and does not require an operating system, and it detects both traditional crashes and hardware-style bugs that manifest as divergent-yet-continuing execution. The headline results are from the ASPLOS paper’s abstract: implemented on a Texas Instruments TMS320C5515 and evaluated on 15 DSP benchmark programs, SBFUZZ achieves 17.4 times higher throughput and 2.6 times greater code coverage than prior embedded fuzzing approaches, uncovering 2,491 unique crashes and 34 unique bugs. (The thesis version reports the earlier, smaller evaluation — nine benchmarks and five bugs — so specific numbers here follow the conference abstract.) Background on fuzzing, coverage tracing, DSP architecture, and re-hosting is standard context. The step-by-step walkthrough is an illustration of the described mechanism. The exact instrumentation, the host-DSP protocol, the divergence oracle, and the full evaluation should be confirmed in the paper.

Background

Why fuzzing keeps expanding to the hardware-software frontier

It helps to see SBFUZZ within the long expansion of fuzzing from ordinary software toward the hardware-software boundary. Fuzzing began as a way to crash user programs, and its success came from a simple, brutal loop: generate inputs, run them, keep the interesting ones, repeat, as fast as possible. Over time researchers carried that loop into harder and harder territory — kernels, network stacks, processors, and embedded firmware — and each new target forced the same reckoning: the generic loop assumes conveniences (an operating system, an emulator, a clean crash, a fast way to run and observe the target) that the new target may not provide, so the technique has to be re-engineered around what is actually there. The recurring lesson is that fuzzing’s effectiveness is gated by throughput and by the quality of the bug oracle, and that reaching a new class of systems means finding a way to keep the loop fast and to recognize failure in that system’s own terms. DSPs are a stark case: bare-metal, specialized, slow to talk to, and prone to failing silently rather than crashing. SBFUZZ meets them by pushing the loop onto the device and redefining what counts as a bug. This drive to carry coverage-guided fuzzing into a domain that resists the standard toolchain, by rebuilding the loop around that domain’s constraints, is the same terrain the work on greybox fuzzing for concurrency testing (greybox fuzzing) covered elsewhere on this site occupies, extending feedback-driven fuzzing to a setting it did not previously fit. SBFUZZ’s particular contribution is to bring fuzzing to safety-critical DSPs, at high throughput and with a bug oracle that sees beyond crashes.

If you remember only three things

1. Fuzzing — generating mutated inputs, running them, keeping those that reach new code, and hunting for crashes — has hardened applications, operating systems, processors, and network protocols, but has barely touched Digital Signal Processor software, even though DSPs run safety- and security-critical code in telecommunications, transportation, and defense. The reason is that DSPs are hostile to standard fuzzers: they are bare-metal chips with no operating system (so OS-based embedded fuzzers do not apply), no emulator (so re-hosting is unavailable), only a limited high-latency debug link to a host (so host-driven fuzzing is throttled by the interface), unusual architectures that break standard instrumentation, and no clean crash behavior (a fault just stalls or spins, and some bugs make execution diverge while continuing to run). So a critical class of software went essentially un-fuzzed.
2. SBFUZZ (Signal Breaker) is a coverage-guided fuzzer built for DSPs, whose central idea is a DSP-centric decomposition of the fuzzing loop. Instead of driving the DSP from a host over the slow link, it runs the hot inner loop — mutation, execution, and coverage tracing — on the DSP itself so the expensive interface stays off the critical path, and a more powerful host assists only periodically with the heavier coordination, analysis, and storage (input-pool management, crash storage, global coverage). Because the DSP is autonomous, one host can fuzz many devices at once, physical or simulated. To run on bare metal, SBFUZZ uses DSP-specific, low-overhead instrumentation (for example, overwriting a location's tracing code with no-ops once its coverage is recorded), and it detects both traditional crashes and the divergent-yet-continuing execution that signals hardware-style bugs.
3. Prototyped on a Texas Instruments TMS320C5515 and evaluated on 15 DSP benchmark programs, SBFUZZ achieves 17.4 times higher throughput and 2.6 times greater code coverage than prior embedded fuzzing approaches applied to DSPs, uncovering 2,491 unique crashes that yield 34 unique bugs. The trade-offs and scope: it requires porting the loop onto the target DSP without an OS, it still needs a host for the heavier work (semi-hosted, not fully independent), its instrumentation is DSP-specific and must be adapted per architecture, and its divergence oracle bounds which non-crashing bugs it finds. This explainer draws its method from the author's thesis version of the work and its headline numbers from the conference abstract; details should be confirmed in the paper.

Check yourself

Check your understanding

1. Why had fuzzing not been applied effectively to Digital Signal Processors?
2. What is SBFUZZ's central design idea, and why does it help?
3. How does SBFUZZ handle the bare-metal constraints and detect bugs?
4. What does SBFUZZ achieve, and what are the limits of the approach?

Sources

The paper is “Signal Breaker: Fuzzing Digital Signal Processors” by Cameron Santiago Garcia and Matthew Hicks (Virginia Tech), published at ASPLOS 2026, DOI 10.1145/3779212.3790220. The author’s Master’s thesis version of the work is available in Virginia Tech’s VTechWorks repository, and the code and benchmarks are open-sourced.

This explainer’s method is drawn from the author’s thesis version of the work; the exact conference paper full text was not retrieved, and the headline numbers here follow the ASPLOS paper’s abstract. As reported, SBFUZZ is a coverage-guided, mutational fuzzer for DSP software that takes a semi-hosted approach, decomposing the fuzzing loop so the DSP autonomously performs mutation, execution, and coverage tracing while a host periodically handles coordination, analysis, and storage, allowing one host to fuzz many devices and supporting physical and simulated DSPs. It uses DSP-specific low-overhead instrumentation and detects both crashes and divergent-continuing execution. On a TI TMS320C5515 across 15 benchmarks, the paper reports 17.4 times higher throughput and 2.6 times greater coverage than prior embedded fuzzing, with 2,491 unique crashes and 34 unique bugs. Background on fuzzing, coverage tracing, and DSP architecture is standard context. The numbers are the paper’s own; exact mechanisms and full results should be confirmed in the paper.