Error while starting fuzzing session

[googleprojectzero]

Error while starting fuzzing session

[ifratric]

Looks like the sample you provided caused a crash in the target so it didn't get added to the corpus (hence the error message you are getting). If the sample isn't genuinely crashing the target, it could also mean your command line flags are incorrect, but it's impossible to tell more with the information provided.

[prksastry]

Looks like the sample you provided caused a crash in the target so it didn't get added to the corpus (hence the error message you are getting). If the sample isn't genuinely crashing the target, it could also mean your command line flags are incorrect, but it's impossible to tell more with the information provided.

instead of using shared memory, making writing the samples to disk, making the fuzzer to get started with multiple executions, but i am unable to see the fuzzing speed and other metrics, in the command line, i have eliminated -delivery shmem and -m option, and the instrument module is same as the coverage module of WinAFL and the target module is the harness/target application, i want to get clarified from you , is the method followed by me correct? since using shmem option giving me same error as that of @woznez

[ifratric]

If you post your full command line I might be able to tell you more.

[prksastry]

If you post your full command line I might be able to tell you more.

fuzzer.exe -in in -out out -t 1000 -instrument_module msxml6.dll -target_module myapp.exe -target_method main -nargs 2 -iterations 10000 -persist -loop -cmp_coverage -- /path/to/myapp.exe @@ i am following https://symeonp.github.io/2017/09/17/fuzzing-winafl.html and want to do the same thing in jackalope, is it correct?

[ifratric]

Hmm yes, I don't see anything wrong in the command line itself. If you're getting errors, you might try without -cmp_coverage or with -patch_return_addresses, and see if that behaves differently.

[woznez]

Hmm yes, I don't see anything wrong in the command line itself. If you're getting errors, you might try without -cmp_coverage or with -patch_return_addresses, and see if that behaves differently.

thanks, its working fine for me but like WinAfl how can we check map coverage for this?

[ifratric]

Exec speed, code coverage, no of paths should all be printed to the stdout every second. I guess if your target prints out a lot of stuff it might fly up too fast so you might miss it.

As for coverage map, Jackalope is not AFL-based and does not use AFL-style coverage map. Instead, coverage is represented as a set of "offsets" (e.g. basic block offsets for bb coverage, or edges for edge coverage etc.). The number of offsets should be printed together with other status lines every second.

[woznez]

> Exec speed, code coverage, no of paths should all be printed to the stdout every second. I guess if your target prints out a lot of stuff it might fly up too fast so you might miss it.

As for coverage map, Jackalope is not AFL-based and does not use AFL-style coverage map. Instead, coverage is represented as a set of "offsets" (e.g. basic block offsets for bb coverage, or edges for edge coverage etc.). The number of offsets should be printed together with other status lines every second

Exec speed, code coverage, no of paths should all be printed to the stdout every second. I guess if your target prints out a lot of stuff it might fly up too fast so you might miss it.

As for coverage map, Jackalope is not AFL-based and does not use AFL-style coverage map. Instead, coverage is represented as a set of "offsets" (e.g. basic block offsets for bb coverage, or edges for edge coverage etc.). The number of offsets should be printed together with other status lines every second.

okok i got it thanks..

[prksastry]

Exec speed, code coverage, no of paths should all be printed to the stdout every second. I guess if your target prints out a lot of stuff it might fly up too fast so you might miss it.

As for coverage map, Jackalope is not AFL-based and does not use AFL-style coverage map. Instead, coverage is represented as a set of "offsets" (e.g. basic block offsets for bb coverage, or edges for edge coverage etc.). The number of offsets should be printed together with other status lines every second.

actually i have one doubt in understanding this, coverage is measured as offsets, no of offsets in each exec is displayed in numbers, but how can one measure in percentage?, what is the denominator to which this offsets can be divided to get % coverage of the module?

[ifratric]

The percentage is, by design, not known. TinyInst is a dynamic instrumentation and it discovers offsets at runtime, it doesn't know their count in advance. If you want an estimate on the number of basic blocks, you can use another tool like IDA.

But note that AFL also won't tell you the percentage of coverage you're hitting - it will only tell you the percentage of coverage map that is filled, and the map is always the same size (64KB by default), so the percentage it show is relative to that, not the actual number of blocks/edges.