Test Corpus minimization using dry_run

[SebastianVoigt]

Hello,
following on googleprojectzero/winafl#473:

First, this project looks like an excellent alternative for WinAFL.

I tried corpus minimization by using dry_run flag:

fuzzer.exe -in "C:\fuzzing\workspaces\XYZ\testdata" -out ..\out -t 1000 -instrument_module m1.dll -instrument_module m2.dll -target_module harness.exe -target_method main -nargs 1 -iterations 10000 -persist -loop -cmp_coverage -dry_run -- harness.exe @@

I have the impression, that is performing fuzzing, instead of doing a dry run only, as it also shows crashes and I cannot see, how the minmized test corpus is build. Any ideas.

Thanks in advance,
Sebastian

[ifratric]

The minimized corpus is going to be in out\samples
If any of the samples from input cause crashes, they will be stored in out\crashes

The dry run pipeline is the same as for fuzzing, they both start running and iteratively adding samples from input in the fuzzing queue (as ling as the inputs contain new coverage, hence the "minimization" aspect of it). The difference is, with the -dry_run, the fuzzer will exit when it's done processing the input samples, before performing mutations.

[SebastianVoigt]

Thank you for your suggestion.

For unknown reasons it is not working for me. The dry_run terminates on a crashing file. The sample folder remains empty.
As well it reports a lot of crashes, that could not be reproduced and neither are identified with WinAFL.
I will hold on on Jackalope for now, but plan to follow up later.

[ifratric]

Can you show me the output you get from Jackalope? Note that some of the flags for WinAFL and Jackalope are slightly different. Another common cause of unreproducable crashes is that the target might need -generate_unwind or -patch_return_addresses to work well under TinyInst.

[SebastianVoigt]

Here is my call:

Here is a typical section from the log:

Total execs: 314
Unique samples: 0 (0 discarded)
Crashes: 24 (1 unique)
Hangs: 0
Offsets: 0
Execs/s: 1
Exception at address 00007FF789752DB0
Access address: FFFFFFFFFFFFFFFF
Processing file: "..\\out\\input_1"

Total execs: 316
Unique samples: 0 (0 discarded)
Crashes: 24 (1 unique)
Hangs: 0
Offsets: 0
Execs/s: 2
Processing file: "..\\out\\input_1"
Processing file: "..\\out\\input_1"

Total execs: 318
Unique samples: 0 (0 discarded)
Crashes: 24 (1 unique)
Hangs: 0
Offsets: 0
Execs/s: 2
Processing file: "..\\out\\input_1"

Total execs: 320
Unique samples: 0 (0 discarded)
Crashes: 24 (1 unique)
Hangs: 0
Offsets: 0
Execs/s: 2
Processing file: "..\\out\\input_1"
Processing file: "..\\out\\input_1"

Total execs: 322
Unique samples: 0 (0 discarded)
Crashes: 24 (1 unique)
Hangs: 0
Offsets: 0
Execs/s: 2
Processing file: "..\\out\\input_1"
Processing file: "..\\out\\input_1"

Total execs: 323
Unique samples: 0 (0 discarded)
Crashes: 24 (1 unique)
Hangs: 0
Offsets: 0
Execs/s: 1
Processing file: "..\\out\\input_1"
Processing file: "..\\out\\input_1"

Total execs: 325
Unique samples: 0 (0 discarded)
Crashes: 24 (1 unique)
Hangs: 0
Offsets: 0
Execs/s: 2
[!] WARNING: Input sample resulted in a crash
[-] PROGRAM ABORT : No interesting input files
         Location : Fuzzer::SynchronizeAndGetJob(), D:\fuzzing\Jackalope\fuzzer.cpp:631

[ifratric]

Right, so the issue appears to be that all of your input files result in a crash. One issue I see in your command line is using -nargs 1 in combination with -target_method main that takes 2 arguments. Otherwise, what you could try is:

• Running without persistence, that is, without any of these flags: -target_module harness.exe -target_method main -nargs 1 -iterations 10000 -persist -loop. Success here would indicate an issue with implementing persistence in the target (e.g. not cleaning the state correctly).
• With one of the flags I mentioned in my earlier reply.

What are the filenames of the resulting crash files?

[SebastianVoigt]

Thank yo so much for spotting this dump mistake. It is working now, in combination with an increased timeout.