Development Testing Simulation

Fuzzing Strategy

Target Program

Program depth (2^D paths) 7

Hidden crash bugs 3

Executions / second 150

Fuzzer Progress

Executions

Edge coverage

0.0%

Crashes found

0 / 3

Corpus size

Total edges

254

How it works

The target program is modeled as a binary control-flow tree of depth D: every execution walks from the entry node to one of 2^D leaves by resolving D branch conditions ("bits"), one per level. A handful of leaves silently contain a crash bug — exactly like real security-critical code paths, the fuzzer only learns a bug exists by actually reaching it.

Blackbox:  each bit generated uniformly at random
           P(reach one specific leaf) = 2^-D per try

Coverage-guided (AFL / libFuzzer style):
           keep any input that exercised a NEW edge in a corpus
           new input = corpus seed with ONE random bit flipped

Because a guided mutation only perturbs a single decision, the new path shares almost its entire route with an already-covered one and mostly differs in one small, previously-unexplored branch. That turns coverage growth into a roughly linear "frontier expansion" instead of blackbox's flat random guessing, which is why real fuzzers keep an edge-coverage bitmap and prioritize inputs that grow it — the exact rule this simulator's corpus follows.

Blackbox / Coverage-Guided — switch generation strategy for future executions; coverage already found is kept.
Program depth — deeper trees (more branch conditions) shrink the blackbox chance of hitting any one path exponentially, while guided fuzzing degrades far more gracefully.
Hidden crash bugs — rare leaves that register a find the moment any executed path terminates on them.
Reseed — regenerates the tree, moves the bugs, and clears all coverage and corpus state.

Unexplored edge Covered edge Crash found

⚠ Couldn't load the 3D engineThree.js failed to load from the CDN. Check your connection and reload.

Development Testing Simulation: Coverage-Guided Fuzz Testing