Binary Coverage the Wrong Way
This article explains the evolution of fuzz testing, focusing on the transition from 'dumb' random input generation to coverage-guided fuzzing. It highlights how tools like American Fuzzy Lop (AFL) use code coverage feedback to identify bugs more effectively.
Why it matters
Understanding coverage-guided fuzzing is critical for modern cybersecurity and software reliability, as it allows for automated discovery of vulnerabilities in complex codebases.
Way back in the age of the dinosaurs, if you wrote a program and wanted to test that it was correct, you mostly had two choices: you could either manually construct malformed inputs and try them in succession, or hook up a program which would randomly generate inputs and try them automatically 1 . Those programs were called fuzzers, or sometimes generators, and this was “fuzz testing”. It also for quite a long time wasn’t very good: the generator would have no feedback from the program under test except “did this random input crash or not”. This feedback, although useful, doesn’t allow the fuzzer to tell if it is making progress relative to the last random input or doing a good job, and so your fuzzer would just repeatedly hit the same shallow code. You’d leave it running for a week and then when you come back realize it was never generating inputs that would hit interesting parts of your program, and they were all immediately being thrown out or never progressing past a if(packet_header == 0xdeadbeef) check.
The content is a technical explanation of software testing methodologies.
Get smarter about the news
Sign up free for a feed built around what you actually care about, Dive Deeper research on any story, and the full text of every article.
Create free accountAlready have an account? Sign in