0xricksanchez / afl_runner

Scaling best-practice AFLPlusPlus fuzzing campaigns made easy

💫 About Me:

🔭 I’m working on finding vulnerabilities and securing systems..
🌱 My self-improvement goal for 2023 is to further learn how to tame the Linux Kernel and find ways to break it
⚙️ I'm trying to stay on top of the fuzzing game
💡 I'd love to finish an in-depth educational fuzzer next
👯 Happy to collab on any cool fuzzing/exploitation ideas!
📚 Always trying to make time to blog about my infosec experiences

🌐 Socials:

💻 Tech Stack:

📊 GitHub Stats:

💰 You can support me by buying me a coffee :)!

afl_runner's Issues

Modularize message passing and TUI

The current implementation is very tightly coupled, which can make additions tough.
It would be nice to mostly decouple the message fetching/passing from the TUI component.

Maybe we can use LLMP here as well

Add tests

In particular, for the command-generation so that we can ensure the generated commands are within the expected limits.

Allow tmux run to be exited cleanly

Add a "Log" section in the TUI

Instead of hiding warnings/errors and crashing eventually, it would be nice to have a log section in the TUI

Allow crash triaging on a specific campaign

Allow adding more new seeds to running instances

If you want to add new seeds to a fuzzing campaign, you can run a temporary fuzzing instance, e.g., when your main fuzzer is using -o out and the new seeds are in newseeds/ directory:

AFL_BENCH_JUST_ONE=1 AFL_FAST_CAL=1 afl-fuzz -i newseeds -o out -S newseeds -- ./target

So we just run a temporary instance for every new seed and need to ensure we're re-using the output directory of the running campaign

Make fuzzing runs introspectable/debuggable

Plot coverage data for current corpus

web gui..?

Add generation coverage after stop fuzzing

https://clang.llvm.org/docs/SourceBasedCodeCoverage.html

Allow building the harnesses as well

Add a `remote-run` dedicated flag

Should do the exact same as run but on >=1 given remote servers. When implementing we need to:

1. Send all things to the remote (generated template, binaries, ...)
2. Update binary paths in the template/commands depending on the decided remote location
3. An updated health check
4. decide where to run the TUI
5. If we split to >1 server, decide on a corpora sync policy