Skip to content
STIMSMITH

Black-Box Fuzzing

Concept

Black-box fuzzing is a dynamic software testing technique in which a Program Under Test is exercised with generated inputs without consulting its internal behavior. It is valued for compatibility with closed-source, embedded, network-only, and hardware targets, but its bug-finding effectiveness is constrained by the absence of internal feedback. Mainstream coverage-guided fuzzers such as AFL include a blackbox fallback mode when instrumentation is unavailable, relying on crash and hang (timeout) detection as the only signal. Recent industrial and academic systems (e.g., FieldFuzz, RISCover, Snipuzz, REST API coverage-level-guided fuzzing) extend black-box techniques to PLC runtimes, closed-source RISC-V CPUs, IoT firmware, and REST services, demonstrating both the breadth of applicability and the recurring need for proxy signals when internal coverage is unavailable.

First seen 6/6/2026
Last seen 8/19/2026
Evidence 7 chunks
Wiki v5

WIKI

Definition

Black-box fuzzing is a dynamic software testing technique in which a Program Under Test (PUT) is executed recurrently with generated inputs (seeds) in order to trigger software bugs, without taking into account the internal behavior of the program when constructing those inputs. It is described in the fuzzing literature as "the simplest variant of fuzzing." A complementary definition states that, in black-box fuzzing, the fuzzer regards the software under test as a "black box" and is unaware of its internal workings; the fuzzer therefore cannot access source code or binary internals to direct input generation. [1]

Fuzzing Toolchain and Lifecycle

READ FULL ARTICLE →

NEIGHBORHOOD

No graph connections found for this entity yet. It may appear in future ingestion runs.

explore full graph →

RELATIONSHIPS

3 connections
Structural Coverage-Based Fuzzing compares with → 90% 2e
Black-box fuzzing is shown to outperform structural coverage-based fuzzing in bug discovery speed.
coverage-guided hardware fuzzing compares with → 85% 1e
The work contrasts coverage-guided hardware fuzzing with black-box fuzzing approaches
RISC Whisk ← mentions 90% 1e
RISC Whisk mentions black-box fuzzing as a type of fuzzing technique.

LINKED ENTITIES

5 links
RISC Whisk MENTIONS Extracted graph relationship
american fuzzy lop (AFL) MENTIONS AFL is described in the evidence as including a blackbox fallback mode for non-instrumented targets.
libFuzzer MENTIONS LibFuzzer is described in the evidence as a fuzzing framework related to the LLVM project integrated into the target binary.
QEMU MENTIONS QEMU is described in the evidence as a generic machine emulator and virtualizer enabling non-native ISA fuzzing.
TaPaSCo MENTIONS TaPaSCo is identified in the evidence as the FPGA abstraction framework used for seamless hardware/software integration in TaPaFuzz.

CITATIONS

19 sources
19 citations — click to expand
[1] Black-box fuzzing is a dynamic software testing technique that runs a Program Under Test with generated inputs without consulting internal program behavior. Background chapter on fuzzing (Virginia Tech thesis material)
[2] Fuzzing consists of three major steps: input generation, input modification (mutation), and program execution, with a fuzzer program automating these via a defined security policy in a fuzz campaign. Background chapter on fuzzing (Virginia Tech thesis material)
[3] Fuzzing includes random fuzzing, mutation-based fuzzing, and feedback-based fuzzing as input-generation methods. Background chapter on fuzzing (Virginia Tech thesis material)
[4] RISC-V is an open-source processor architecture (Reduced Instruction Set Computing Five) that is royalty-free, modular, and customizable. Background chapter on fuzzing (Virginia Tech thesis material)
[5] AFL falls back onto a blackbox mode for non-instrumented targets, relying on crash and hang (timeout) detection for feedback, and provides a QEMU mode for non-native ISA targets with approximately 2x–5x runtime overhead. TaPaFuzz - An FPGA-Accelerated Framework for RISC-V IoT Graybox Fuzzing
[6] AFL++ is a community fork of AFL with a newer codebase and exposes a custom mutator API to combine new ideas with existing fuzzing technologies. TaPaFuzz - An FPGA-Accelerated Framework for RISC-V IoT Graybox Fuzzing
[7] LibFuzzer is a fuzzing framework related to the LLVM project integrated into the target binary, with the user providing an entry point from which parallel threads run with varying inputs. TaPaFuzz - An FPGA-Accelerated Framework for RISC-V IoT Graybox Fuzzing
[8] Some greybox/whitebox fuzzing techniques used by AFL++ and LibFuzzer employ compiler transformations that alter runtime behavior and may be inappropriate for real-time IoT targets. TaPaFuzz - An FPGA-Accelerated Framework for RISC-V IoT Graybox Fuzzing
[9] Coverage approaches used by greybox fuzzers include basic-block coverage (with BB histograms), CF-edge coverage, and hash digests of entire CF paths. TaPaFuzz - An FPGA-Accelerated Framework for RISC-V IoT Graybox Fuzzing
[10] TaPaFuzz is a hardware/software co-designed framework for RISC-V IoT fuzzing in which a hardware component executes firmware and captures an edge coverage map returned with the target's return value to host software driving iterative input generation. TaPaFuzz - An FPGA-Accelerated Framework for RISC-V IoT Graybox Fuzzing
[11] TaPaSCo is a freely available FPGA abstraction framework used to compose SoCs for seamless hardware/software integration in TaPaFuzz. TaPaFuzz - An FPGA-Accelerated Framework for RISC-V IoT Graybox Fuzzing
[12] Black-box fuzzing of IoT devices is viable because obtaining and emulating firmware is difficult, but existing black-box IoT fuzzers lack effective mutation optimization due to absence of feedback. Snipuzz: Black-box Fuzzing of IoT Firmware via Message Snippet Inference
[13] Snipuzz infers message snippets from device responses to drive mutation, narrows the search space without reverse engineering companion apps, and identified 5 zero-day vulnerabilities across 20 real-world IoT devices (3 exposed only by Snipuzz), all confirmed by vendors. Snipuzz: Black-box Fuzzing of IoT Firmware via Message Snippet Inference
[14] Snipuzz was compared against IoTFuzzer, BooFuzz, Doona, and Nemesys. Snipuzz: Black-box Fuzzing of IoT Firmware via Message Snippet Inference
[15] A coverage-level-guided black-box fuzzing method for REST APIs uses Test Coverage Level derived from HTTP response observations as feedback to address blind mutations, finding 89 confirmed bugs in two large open-source projects and 351 bugs across 64 APIs.guru services. REST API Fuzzing by Coverage Level Guided Blackbox Testing
[16] RISCover is a centralized differential black-box CPU fuzzer using a powerful server orchestrating multiple resource-constrained RISC-V clients that report register/memory state back, reducing client workload. RISCover: Automatic Discovery of User-exploitable Architectural Security Vulnerabilities in Closed-Source RISC-V CPUs
[17] RISCover formalizes three central challenges for black-box CPU fuzzing: C1 sequence generation without coverage feedback, C2 non-deterministic effects from microarchitectural state and OS runtime, and C3 centralized server–client orchestration. RISCover: Automatic Discovery of User-exploitable Architectural Security Vulnerabilities in Closed-Source RISC-V CPUs
[18] Bölcskei et al. (cited in RISCover) show that structural-coverage fuzzers can be slower than black-box fuzzers, motivating black-box post-silicon fuzzing, especially for RISC-V. RISCover: Automatic Discovery of User-exploitable Architectural Security Vulnerabilities in Closed-Source RISC-V CPUs
[19] Differential fuzzing compares multiple implementations of the same specification, flagging divergences as potential bugs without requiring any golden model, and prior differential-testing works on emulators vs. real hardware typically use black-box input generation. RISCover: Automatic Discovery of User-exploitable Architectural Security Vulnerabilities in Closed-Source RISC-V CPUs