<p dir="ltr">Fuzz testing is well-known for its ability to catch unforeseen bugs in complex programs. Its highly automated nature makes it attractive since it can execute and test large parts of the program with just a few starting inputs from the verification team. To allow a general purpose fuzzing engine like AFL++ to work with any program, a fuzzing harness exists as the interface between the fuzzing engine (which provides the mutated string of bytes) and the entry points of the program being tested (which expects inputs in a well-formatted way). However, due to poorly written harnesses, a state-of-the-art fuzzer may spend lots of computation resources and still explore only a small portion of the codebase. These unexecuted “fuzz blockers” are a well-known reason for the disparity between fuzzing’s prowess in academic research, and their performance in real-world applications.</p><p dir="ltr">Google’s OSS-Fuzz initiative helps open-source developers to fuzz their programs and provide some insights about their fuzzing results, but it is up to the developer to manually analyze why certain sections of code are fuzz blockers. This thesis provides a tool, called FuzzGauge, by which a significant portion of this analysis can be automated. The tool especially focuses on locating causes of blockers that may be due to bad harnesses. It uses the results provided by Fuzz-Introspector and builds an analysis pipeline on top of it, to provide reasons why a fuzz blocker occurs. It tells whether a blocker could be eventually fuzzed, given enough time. If it cannot, it points out any possible hardcoded values in the code or harness which cause this blocker. Using these results, we believe a developer can quickly improve their project’s fuzzability.</p>