What is fuzzing? You've already done some fuzzing, esteemed reader, as part of our exercises elsewhere in this book. When we were exploring our vulnerable C programs, we would fire up the GNU debugger and watch the state of the registers as we threw more and more data at the user prompt. We were modifying our input with each iteration and trying to cause a crash or at least some anomalous behavior. The inputs to the program can be malformed in some sense: an invalid format, adding unexpected or invalid characters, simply providing too much data. The fuzzing target doesn't even have to be a program: it could be a network service implementing some particular protocol, or even the encoder that generates a file in a particular format, such as PDF or JPG. If you've ever worked in software development, then the idea is immediately familiar. Fuzzing can find flaws that could negatively impact the user experience, but for security practitioners, it's a way to find exploitable flaws. 

In this chapter, we're going to dive deeper into fuzzing as an exploit research methodology. We'll explore two real-world programs with overflow vulnerabilities, but we won't reveal any specifics. It'll be up to us to discover the facts needed to write a working exploit for the programs. We'll cover the following topics:

• Mutation fuzzing over the network against a server
• Writing Python fuzzers for both client and server testing
• Debugging the target programs to monitor memory during fuzzing
• Using offset discovery tools to find the right size for our payloads