Over the past decade, hundreds of fuzzers have been published in top-tier security and software engineering conferences. Fuzzers are used to automatically test programs, ideally creating high-coverage input corpora and finding bugs. Modern "greybox'' fuzzers evolve a corpus of inputs by applying \emph{mutations} to inputs and then executing those new inputs while collecting coverage. New inputs that are "interesting'' (e.g. reveal new coverage) are saved to the corpus. Given their non-deterministic nature, the impact of each design decision on the fuzzer’s performance can be difficult to predict. Some design decisions (e.g. "should the fuzzer perform deterministic mutations of inputs'') are exposed to end-users as configuration flags, but others (e.g. "what kinds of random mutations to apply to inputs?'') are typically baked-in to the fuzzer code itself. This paper describes our over 12.5-CPU-year evaluation of the set of mutation operators employed by the popular AFL++ fuzzer including the \textit{havoc} phase, splicing and \redqueen, exploring the impact of adjusting some of those unexposed configurations.

In this experience paper, we propose a methodology for determining different fuzzers’ behavioral diversity with respect to branch coverage and bug detection using rigorous statistical methods. Our key finding is that, across a range of targets, disabling certain mutation operators (some of which were previously "baked-in'' to the fuzzer) resulted in inputs that cover different lines of code and reveal different bugs. A surprising result is disabling certain mutators leads to \textbf{more diverse} coverage and allows the fuzzer to find \textbf{more} bugs \textbf{faster}. We call for researchers to investigate seemingly simple design decisions in fuzzers more thoroughly and encourage fuzzer developers to expose more configuration parameters pertaining to these design decisions to end-users.