Find bugs before attackers do: fuzzing your own code
A fuzzer is a tool that throws millions of weird, malformed inputs at a program on purpose, trying to make it crash, so you can fix the hole before anyone else finds it. In this mission you install Atheris (Google's fuzzer for Python), write a tiny parser with a bug planted in it, and watch the fuzzer discover a crashing input in a fraction of a second. Then you read the crash, shrink it to the smallest input that still breaks things, fix the code, and prove the crash is gone. This is defensive security from start to finish: you only ever attack a small program that you wrote yourself.
- Windows 11 with WSL2 (a slim Linux built into Windows). If you did the Build a hacking lab lesson you already have it. If not, open PowerShell as Administrator and run
wsl --install, then restart. On a real Linux box or a Mac you can follow along in your normal terminal instead. The Level 0 lesson Install anything from GitHub covers the terminal basics if they are new to you - Python 3 inside WSL2 (Ubuntu ships with it already). You do not need to install Python separately
- About 100MB of free disk space for Atheris and its built-in fuzzing engine
What fuzzing is, and why breaking your own code is defence
Understand the idea and the words before you install anything, so the rest of the lesson is reading, not guessing.
A fuzzer is a program that tries to break another program by feeding it a flood of random and malformed inputs, as fast as it can, watching for anything that makes the target crash. A human tester might try ten odd inputs. A fuzzer tries hundreds of thousands a second, including inputs no sane person would ever type, which is exactly where real bugs hide.
Why would you want to crash your own code? Because a crash is a bug, and a bug that a fuzzer can reach from untrusted input is often a security hole. The attacker's whole job is to find the one weird input that makes your parser, your file reader or your network handler misbehave. Fuzzing is you doing that first, to your own code, so you can fix it before anyone with bad intentions finds it. That is why this is defensive security, not offensive: the only thing under attack here is a small program you wrote, on your own machine.
Two words you will see throughout. A crash input (or "crashing input") is the specific bytes that made the program fall over. The fuzzer saves it to a file so you can reproduce the crash on demand. A corpus is the fuzzer's growing collection of inputs it has found interesting, the raw material it mutates to go deeper into your code. You start with an empty corpus and the fuzzer builds one as it learns.
There are two broad families of fuzzer, and it helps to know which you are using:
- Coverage-guided fuzzers (Atheris, libFuzzer, AFL++) watch which lines of your code each input reaches. When an input reaches somewhere new, they keep it and mutate it further. This is how a fuzzer can teach itself, with no hints, to get past a check like "the input must start with the letters PX" and then dig into the code behind it. We use this kind here.
- Property-based testing (Hypothesis in Python is the best known) is a gentler cousin. Instead of hunting for crashes blindly, you state a rule that should always hold ("decoding then re-encoding gives back the original") and the tool throws generated inputs at that rule looking for a counter-example. It is a brilliant way into the same mindset, and the last step points you at it.
The plan for the rest of the lesson is short: install the fuzzer, write a tiny target with a bug in it, let the fuzzer find the bug, read and shrink the crash, fix it, and prove the fix works. Then one step on how to do this responsibly if you ever point a fuzzer at real open-source software.
TipFuzzing found many of the most serious bugs of the last decade. Google's OSS-Fuzz project fuzzes thousands of open-source projects around the clock and has reported tens of thousands of bugs. The technique you learn here is the same one, scaled down to one laptop and one tiny program.