[dwheeler]

Fuzzers can find defects, including vulnerabilities, that might be missed by other tools. AFL used a newer technique, called being "coverage guided", that turned out to be a remarkable improvement. As a coverage guided tool it monitors how many times various code branches are taken, and if the count is different than what has seen before, the input is considered "more interesting". AFL++ inherits this capability.

An impressive demo (from AFL) is that it was able to figure out the required format for a JPEG file given only one text file (which is not a JPEG file): https://web.archive.org/web/20201210022938/https://lcamtuf.b...

If you're fuzzing open source software, you might consider applying to OSS-Fuzz https://github.com/google/oss-fuzz which provides a lot of free compute power to run fuzzers (so that vulnerabilities can be found & fixed).

[not2b]

The technique has been used for at least two decades in hardware verification, though the terminology is different. If you search the literature, you'll find terms like "constrained functional verification", "coverage directed test generation", "functional coverage directed test generation", and the like. The technique is the same, random testing, with mutation to try to hit more and more coverage points.

[pfdietz]

It goes back af least that far in software, with the original fuzzing work from U. Wisc and McKeeman's "Differential Testing for Software". Those are blackbox techniques; AFL's advance was using a general grey box approach.

[not2b]

The hardware approach isn't blackbox, it explicitly uses the reachable state space and constraint solving to reach more coverage points, to do this the exact circuit representation is needed.