Instrumentation output varies across runs. about winafl HOT 5 CLOSED

I don't think this is due to DynamoRIO but, depending on the target, it can happen that complex programs execute different codepaths for different runs. Silly example: There is a code in the target that processes windows messages (events) and on one run it encountered a message but on another it didn't. That's why coverage_module flag can be quite important to isolate only the coverage you care about.

This can also happen in edge coverage mode, where in a multi-threaded app a previously unseen context switch is going to be interpreted as new coverage (that's why WinAFL uses basic block coverage by default)

Another option is that there is some global state being preserved across iterations and affecting codepaths. Does this still happen with fuzz_iterations 1?

from winafl.

At the moment i'm running basic block with 7z.dll as covered module.
Thanks for the tip on reducing fuzz_iterations, when i resume a campaign generated with it set to 1, every test case covers new paths. Too bad reloading the modules slows everything down by a factor of 10.

Any suggestions on how i could go about resuming persistence here? picking an offset above the extraction function that makes 7z.dll load on every iteration?

from winafl.

Actually you probably don't want to reload 7z.dll on every iteration, that way DynamoRIO would need to translate it again every time and that would be slow. TBH I wouldn't worry much about afl reporting no new coverage in some samples unless there's really a lot of them compared to "legit" samples. I'm not sure if afl-fuzz has some way to assign a lower weight to samples without new coverage when resuming the session. If not, you can periodically "clean" the sample set by copying all samples to your input directory and starting a new session, in which case (IIRC) AFL only selects the samples with new coverage.

from winafl.

I'm not that concerned about the potentially useless test cases, AFL knows to skip that. it's the false positives that worry me. I'm worried AFL might get 'false hope' by detecting useless permutations as interesting.

On a few windows executables i get the 'instrumentation varies' warning with persistent mode, even with simple console commands and narrow target functions. When it happens, it happens a lot, 10-50% of the test cases. It seems deterministic, consistently varying on the same test cases. So that does point to your example of global state being preserved. Any way around that except fuzz_iter=1?.

from winafl.

issue seems specific to the application, closing

from winafl.