# Fuzzing?? ### My Journey Into WinAFL and Fuzzing At the start of my journey, I tried to find a complete guide that could help me learn **WinAFL** and fuzzing concepts. I expected to find clear documentation or a simple step-by-step tutorial, but there was almost nothing. Most resources online were short, outdated, or not detailed enough. Even with this problem, I kept searching everywhere. I read blog posts, watched talks, checked GitHub issues, and looked through research papers. I slowly collected small pieces of information until the bigger picture became clear. This chapter explains the ideas I learned and how they helped me understand fuzzing better. ### Understanding Fuzzing Fundamentals Before using **WinAFL**, I had to learn what fuzzing is. Fuzzing is an automated testing method that sends many different inputs to a program to see if it crashes or behaves in a strange way. It is useful because it can find bugs that normal testing might miss. I learned about coverage-guided fuzzing, input mutation, and why instrumentation is important. These ideas became the foundation for everything I learned later. ### Different Types of Fuzzers During my learning journey, I discovered that fuzzers are not all the same. Each type follows a different method to generate inputs and explore programs. **Coverage-Guided Fuzzers** These fuzzers use code coverage feedback to improve inputs.\ Example: AFL flips a bit in the input, sees new coverage, and saves that input to explore further. **Grammar-Based Fuzzers** These fuzzers generate inputs using a defined structure or grammar.\ Example: A grammar-based fuzzer can create valid JSON objects by following rules like "object contains key and value." **Blackbox Fuzzers** These fuzzers do not use any feedback. They simply send random inputs and hope to find a crash.\ Example: Sending random bytes to a program without checking which code paths were reached. **Hybrid Fuzzers** These fuzzers mix fuzzing with other techniques like symbolic execution to solve tricky conditions.\ Example: The fuzzer gets stuck at an if statement, and symbolic execution helps find the value needed to pass the check. Learning these different types helped me see how each fuzzer has its own strengths and use cases. ### Learning What AFL Is and How It Works Since **WinAFL** is based on **AFL**, I started by studying **AFL** itself. I learned how **AFL** measures code coverage, how it evolves inputs over time, and how it selects interesting test cases. **AFL** uses a genetic-style approach where test cases improve step by step. It also keeps a queue of inputs, tracks crashes, and tries to reach new paths quickly. Understanding **AFL** made it easier to understand **WinAFL** later. ### Mutation Strategies and Their Types After learning the basics of **AFL**, I focused on mutation strategies. Mutation is the process of taking one input and changing it in different ways. The goal is to create new inputs that can explore new code paths. Here are the main types of mutations I learned. **Bit and Byte Mutations** The **fuzzer** flips individual bits in the input. {% code title="Example" %} ``` Original byte : 0101 1100 Flip bit 3 : 0101 0100 ``` {% endcode %} **Arithmetic Mutations** The fuzzer adds or subtracts from the value stored in the bits. {% code title="Example" %} ``` Original byte: 0000 1111 (decimal 15) Add 1: 0001 0000 (decimal 16) ``` {% endcode %} **Block Mutations** A larger block of bits is copied, removed, or inserted. {% code title="Example" %} ``` Original input: 001101 110010 Duplicating the first block: 001101 001101 110010 ``` {% endcode %} **Splicing** The fuzzer mixes bits from two different inputs. {% code title="Example" %} ``` Input A: 1010 1010 Input B: 1111 0000 Spliced result (first half from A, second half from B): 1010 0000 ``` {% endcode %} **Deterministic** The fuzzer flips bits in a specific order. {% code title="Example" %} ``` (flip bit 0, then bit 1, then bit 2): Start: 0110 0110 Step 1: 0110 0111 Step 2: 0110 0101 Step 3: 0110 0001 ``` {% endcode %} **Havoc** The fuzzer applies random bit operations together. {% code title="Example" %} ``` Start: 1001 0011 Random mix: flip bit 7, insert random byte, delete bit Possible result: 0001 1100 1010 ``` {% endcode %} These strategies show how small bit changes guide the fuzzer into new paths. They also helped me understand how inputs improve and why good seeds matter. ### Understanding Code Coverage and Code Paths Code coverage shows which parts of the program ran during a test case. When a new mutation hits a line or branch that was never reached before, the fuzzer treats it as new coverage. This helps the fuzzer decide which inputs are useful. Inputs that reach new areas of the program are saved, while others are ignored. Code paths are simply the different routes a program can take depending on conditions. The goal of the fuzzer is to explore as many paths as possible. Understanding coverage helped me see how fuzzers learn, improve, and move deeper into the program. ### Understanding WinAFL Layout and Workflow **WinAFL** is the Windows version of **AFL**, and it uses tools like DynamoRIO to collect coverage. I learned how the folders are organized, what each binary does, how callbacks work, and how persistent mode improves speed. Once I understood the layout, **WinAFL** became much easier to use. ### Harness Development Harness development was one of the biggest new skills I had to learn. A harness is a small program that calls the function or code you want to fuzz. It gives the fuzzer a stable and repeatable environment. I learned how to write a harness, how to use a persistent loop, how to reset memory state, and how to pass input safely to the target. This was the point where fuzzing became real hands-on work, not just theory. *** ### My First Fuzzing Session After learning the basics, I finally fuzzed my first test binary with WinAFL. I prepared a few seed files, wrote a simple harness, and ran the fuzzer. I watched it discover new paths and generate crash samples. This was the moment when all the concepts came together and the whole workflow made sense. tbc the whole fuzzing lab (showing the crash, exploiting the crash) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://iq0.gitbook.io/iq0/kaust-vsrp/fuzzing.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.