AFLplusplus / AFLplusplus

The fuzzer afl++ is afl with community patches, qemu 5.1 upgrade, collision-free coverage, enhanced laf-intel & redqueen, AFLfast++ power schedules, MOpt mutators, unicorn_mode, and a lot more!

Home Page:https://aflplus.plus

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Delay sync stage for new runs

sagamusix opened this issue · comments

I'm running a bunch of fuzzers on my library (libopenmpt). Occasionally, when adding support for a new file format which requires some additional attention, I add a new fuzzer to the bunch which initial test cases just covering that new file format. I do add this fuzzer to my existing pool since the cross-pollination between different fuzzer instances is pretty useful in general, but I think it would be nice if the strategy when the sync stage is executed could be improved a bit for new fuzzing instances that haven't been running for a long time.

In general my observation is that afl++ spends some time on fuzzing the first test case that I provided, and then after a few minutes changes to syncing files from other fuzzers. I think it would be beneficial if at least a couple more of the initial test files were considered before the sync stage is reached for the first time - let the fuzzer first spend some time on the material it was provided before files from other fuzzers are considered. Do you think changing the fuzzing strategy in this regard would be feasible?

Do you think changing the fuzzing strategy in this regard would be feasible?

yes it is feasible. but it would not be the optimal approach, for you or anyone else (unless you can convince me otherwise) :-)

here is what should work better for you:

step 1

for a new feature, run 1-x instances of afl-fuzz independent to the general fuzzing campaign. this way there is no cross pollination.

This is still not optimal because AFL++ will still at once find other supported formats and fuzz these two, making it loosing concentration on your new feature, so we want:

Focus fuzzing

when you compile for fuzzing your new feature, use selective instrumentation (AFL_LLVM_ALLOWLIST) for the functions on the path to your target functions plus your target functions themselves.

This way you only fuzz the feature that you want.

Merging to the general fuzzing campaign

once you are satisfied with fuzzing the new feature just add that corpus to the general fuzzing campaign, e.g. afl-addseeds -i focus_fuzz/main/queue -o general_fuzz

Ah, I wasn't aware of afl-addseeds, I see that's a recent addition. I think that takes the main pain points away from running a separate fuzzing campaign in paralle, so I will stick to that. Thanks for the suggestion!