Resources
People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!
- Fuzzing is an automated technique that provides semi invalid or bad inputs to a program to attempt to find bad program states, such as crashes, hangs or other weird behavior.
- Fuzzing is much more than simply throwing random inputs and moving on with your day though. Fuzzing is actually quite involved and takes a lot of work!
- This article dives into the details an entire fuzzing job. I'll mention what stood out to me...
- The first part of the article is about picking the target. The main questions that we should ask are:
- Is the source code readily available? This is important in order to instrument the binary.
- Are there code examples of how to use the code base?
- Are unique and interesting test cases available?
- Having high quality test cases is a very important part of the process. What exactly makes a high quality test case?
- All inputs hit unique codes paths
- The test case is as efficient as possible
- Time to run the damn fuzzers! Start multiple instances of the fuzzer, inside a bash loop, and let them go for a while. Make sure to check in periodically in order to validate the fuzzer is working as expected.
- Stopping and pruning: this is the section that the author claims to be most important part of the fuzzing. After the fuzzer has ran for a while (AFL finished first cycle), a large amount of test cases have been created. These should now be interesting code paths that hopefully have bugs lurking inside them. At this point, restart the fuzzer with several of these test cases as seeds.
- Once you have found some crashes, it is time to start triaging. Finding the actual bug that causes the program to crash is terribly annoying. Tools such as GDB (debugger), CrashWalk (determines if crash is exploitable), Valgrind (memory analyzer) and others make this process less bad at least.
