Black-Box Fuzzing
ConceptBlack-box fuzzing is a dynamic software testing technique that generates and mutates inputs without consulting the internal behavior of the program under test. It is valued for its 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 operate a blackbox fallback mode when instrumentation is unavailable, relying solely on crash and hang (timeout) detection as feedback, and recent industrial practice (FieldFuzz, Ratel, RISCover) continues to extend black-box techniques to PLC runtimes, enterprise DBMSs, and closed-source RISC-V CPUs.
First seen 6/6/2026
Last seen 7/12/2026
Evidence 6 chunks
Wiki v4
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."
Characteristics
NEIGHBORHOOD
No graph connections found for this entity yet. It may appear in future ingestion runs.
explore full graph →RELATIONSHIPS
2 connectionsBlack-box fuzzing is shown to outperform structural coverage-based fuzzing in bug discovery speed.
The work contrasts coverage-guided hardware fuzzing with black-box fuzzing approaches
LINKED ENTITIES
3 linksAFL operates_in AFL is explicitly described as falling back to a blackbox mode for non-instrumented targets, providing crash and hang (timeout) detection as feedback.
libFuzzer related_to LibFuzzer is described as a fuzzing framework related to the LLVM project, integrated into the target binary; its compiler transformations may be inappropriate for real-time targets.
QEMU related_to QEMU is a generic machine emulator used in AFL's QEMU mode for non-native ISA fuzzing, with an approximate 2x-5x runtime overhead.
CITATIONS
14 sources14 citations — click to expand
[1] AFL falls back onto a blackbox mode for non-instrumented targets, relying on crash and hang detection (timeout) for feedback. TaPaFuzz - An FPGA-Accelerated Framework for RISC-V IoT Graybox Fuzzing
[2] AFL's QEMU mode for non-native ISA fuzzing has an approximate runtime overhead of 2x-5x. TaPaFuzz - An FPGA-Accelerated Framework for RISC-V IoT Graybox Fuzzing
[3] AFL++ is a community fork of AFL with a newer codebase and a custom mutator API. TaPaFuzz - An FPGA-Accelerated Framework for RISC-V IoT Graybox Fuzzing
[4] LibFuzzer is integrated into the target binary, the user provides an entry point from which parallel threads run with varying inputs; limitations include the target not modifying global state or providing its own reset. TaPaFuzz - An FPGA-Accelerated Framework for RISC-V IoT Graybox Fuzzing
[5] Compiler transformations used by AFL++ and LibFuzzer (e.g., CF-edge splitting across basic blocks to expose partial conditions) may be inappropriate for real-time IoT targets. TaPaFuzz - An FPGA-Accelerated Framework for RISC-V IoT Graybox Fuzzing
[6] Coverage approaches include basic-block tracking with histograms, CF edge coverage, and hash digests identifying entire CF paths. TaPaFuzz - An FPGA-Accelerated Framework for RISC-V IoT Graybox Fuzzing
[7] TaPaFuzz is an FPGA-accelerated hardware/software co-designed fuzzer for RISC-V IoT firmware that captures edge coverage in hardware and uses TaPaSCo for SoC composition. TaPaFuzz - An FPGA-Accelerated Framework for RISC-V IoT Graybox Fuzzing
[8] Bölcskei et al. show that structural-coverage fuzzers can be slower than black-box fuzzers in bug discovery on certain hardware targets. RISCover: Automatic Discovery of User-exploitable Architectural Security Vulnerabilities in Closed-Source RISC-V CPUs
[9] RISCover uses a centralized server-client design in which one server orchestrates test-case generation and multiple RISC-V clients execute instruction sequences and report results. RISCover: Automatic Discovery of User-exploitable Architectural Security Vulnerabilities in Closed-Source RISC-V CPUs
[10] RISCover identifies two central challenges for black-box CPU fuzzing: C1 (Sequence Generation, with no coverage feedback) and C2 (Non-deterministic Effects, including performance counters, prior instruction history, OS memory mappings, and values such as Linux vDSO). RISCover: Automatic Discovery of User-exploitable Architectural Security Vulnerabilities in Closed-Source RISC-V CPUs
[11] Differential fuzzing compares multiple implementations of the same specification, flagging divergences as potential bugs without requiring any golden model. RISCover: Automatic Discovery of User-exploitable Architectural Security Vulnerabilities in Closed-Source RISC-V CPUs
[12] FieldFuzz is a network-based fuzzing framework for the Codesys PLC runtime (used by over 400 devices from 80 industrial PLC vendors) that combines reverse-engineering-enabled remote control, automated command discovery via network traffic, and on-system tracing/coverage; it uncovered multiple vulnerabilities leading to three reported CVE IDs and was reproduced across a diverse set of ICS devices. FieldFuzz: In Situ Blackbox Fuzzing of Proprietary Industrial Automation Runtimes via the Network
[13] Industrial DBMS black-box fuzzers SQLsmith and SQLancer were used as baselines; the coverage-guided fuzzer Ratel covered 38.38%, 106.14%, and 583.05% more basic blocks than the best of these baselines on GaussDB, PostgreSQL, and Comdb2, respectively, and discovered 32, 42, and 5 unknown bugs. Industry Practice of Coverage-Guided Enterprise-Level DBMS Fuzzing
[14] Coverage-guided hardware fuzzing can be implemented with on-chip Coverage Collection Engines (CCEs) integrated into the SoC, providing structural coverage signals (basic blocks, edges, covergroups) for input mutation. Thesis: Coverage-Guided Hardware Fuzzing