Introduction

Many related problems arise during the fuzzing of real applications. First, some mutation-based fuzzers will run indefinitely, endlessly modifying data and supplying it to the target application. Assuming the application never crashes, how do we know when to turn off this type of fuzzer? When is enough? Another problem that arises comes after running a finite set of fuzzed test cases, such as those generated by SPIKE or supplied by a PROTOS test suite. If the target application has not crashed, and the fuzzer is finished, what do we do next? Can we call the application secure and move on? Is it possible to measure how well the application has been fuzzed? Is there a way to make "improved" test cases based on the results of previous fuzzing runs?

The answers to all these questions can be found by closer examination of the actions of the application being fuzzed. This chapter demonstrates how to use code coverage, a measure of the amount of code executed by an application, to make decisions on how successful fuzzing has been and how this information can be used to make fuzzing even more effective.

Code Coverage

Code coverage is a metric often used by software developers and testers to help determine when applications have been sufficiently tested. Typically, code coverage information is obtained by adding additional code to the application when it is built. Adding code to a binary is called instrumenting the code. (We'll see later that there are other...