search

bnagy / crashwalk

Bucket and triage on-disk crashes. OSX and Linux.
Other
349 stars 37 forks source link

Does not seem to support AFL Parallel Fuzzing Results on OSX #12

Open gdsjdunlap opened 8 years ago

gdsjdunlap commented 8 years ago

From the /sync directory

$ cwtriage -afl  -root . -workers 16 -engine lldb
2016/02/04 19:18:47 Couldn't parse AFL commandline in fuzz01/crashes/README.txt

With a readme file like:

Command line used to find this crash:

/Users/myuser/afl-1.95b/afl-fuzz -i - -o /Users/myuser/fuzzdir/sync/ -M fuzz01 ./programname -args @@

If you can't reproduce a bug outside of afl-fuzz, be sure to set the same
memory limit. The limit used for this fuzzing session was 50.0 MB. 

Need a tool to minimize test cases before investigating the crashes or sending
them to a vendor? Check out the afl-tmin that comes with the fuzzer!

Found any cool bugs in open-source tools using afl-fuzz? If yes, please drop
me a mail at <lcamtuf@coredump.cx> once the issues are fixed - I'd love to
add your finds to the gallery at: 

  http://lcamtuf.coredump.cx/afl/

Thanks :-)

Which is what AFL produces naturally. Perhaps I need to pare it down and remove the suggestions about coredump from the file to be able to use -afl?

Now, I suspected that the cause of the problem may be that I am not in the right directory, so I went to the directory where the fuzzed program lives and:

cwtriage -afl -engine lldb -root ~/fuzzdir/sync/ -workers 16

produces no output whatsoever.

as well as

cwtriage -afl -engine lldb -root ~/fuzzdir/sync/ -workers 16 -- ./program.o -tv @@

I may very well be putting the wrong cmdline arguments, but the program seems to be doing nothing at all.

bnagy commented 8 years ago

The README.TXT parser expects afl commands to have been launched with a separator -- before the target program and arguments. This is documented in the BUGS section of the crashwalk readme. It's not ideal, I know. See if that's the problem you're having (and close if it is, thanks)

gdsjdunlap commented 8 years ago

Due to the OSX issue I mentioned in my other bug, I can't test if this is the issue. I'll close this once I can confirm one way or the other.

Best I can say at the moment is that if I put the -- in the readme, instead of complaining about the README being unparseable I get a golang crash. Seems to suggest it's at least trying to work.