Documentation: Provide a flowchart to guide users in choosing which features to use for their fuzzers

[s1341]

LibAFL is starting to become very feature-full, and will probably continue to grow in this regard.

It would be extremely useful to have a flowchart or decision tree which helps guide users in choosing which features to use for their fuzzer, based on their requirements. This should include major runtime modes (such as frida/qemu/nyx etc.), as well as other library features (schedulers, stages, observers, feedbacks, launcher, etc.).

Ideally, the decision tree should also point out which example fuzzer demonstrates each feature.

[domenukk]

Great idea.

I'll start with some things we should discuss:

Windows/Linux/MacOS/kernel/no_std?
Binary-only/source-based? (Frida, qemu, clang)
Library/complex stateful target? (Nyx resets, qemu snapshots, forkserver)

On top, advanced topics
Scaling (LLMP, no LLMP for dev), different setups for different nodes, cmin, tmin

Then, which inputs does the target take?
Grimoire? Nautilus, token-level fuzzing, cmplog,...

Is the target leaking memory? > Restarting

[s1341]

1. It would be great to be able to trigger everything but forking/restarting_mgr to make debugging easier. This should be a launcher flag. Maybe we need a new issue for this?
2. An idea which came up on the discord was to have a 90's style wizard where you choose depending on questions, which would generate a template fuzzer... More effort, but it would go a long way towards making LibAFL more accessible.

[addisoncrump]

Instead of a flowchart, I'd recommend a sequence of menus. Reason being: many of these choices are independent. For example, suppose you're fuzzing multiple different versions of the same binary in different contexts (windows vs linux); you likely want the same fuzzer behaviour, just different platforms. Having a flowchart would either need a) multiple independent flowcharts, which may not be reasonable if some options are not available for particular platforms (e.g., fork on windows) or b) repeated sections.

Instead, it would probably make more sense to have an interactive menu system, with explanations for why certain options are not available based on previous selections. This could be implemented as a cargo generate template with a bit of scripting work, or as a standalone tool to generate full libafl crates.

[GanbaruTobi]

Besides having a guide on what features to use when, it would also be VERY useful on knowing how to develop a fuzzer (from less features to more). For example, if I see a qemu-systemmode fuzzer that spawns automatically many instances, uses many features, and works on a strange system its hard to even get a minimal example working to start testing on another target, because I have to substract everything away and often the example components are entangled. I think that would go hand in hand with the initial suggestion.