Interpreting/Reproducing Hangs

[Özge Çelenk]

Hi all, I am a beginner in fuzzing and I need to fuzz a program (written in C) which takes .pcap files as input for protocol and application classification purposes, and I am using Ubuntu as operating system. 

After following the steps in the afl manual I managed to run the fuzzer , however the target binary is horribly slow ( 14-15 execs/sec maximum) . I tried to do parallel fuzzing but that did not speed up the things noticeably, and the master fuzzer displays "odd, check syntax" warning after around 3 minutes, and the cycles end in one second or so. I also tried modifying the -t and -m variables , which leads to the same error. So I just decided to not change the default settings leave it as it is (at least for the beginning) to observe if it can find something interesting, even if it is slow.

The fuzzer has been running nearly for 10 days now and it has found 304 unique hangs so far, but no crashes listed yet.  My question is, how can I interpret these hangs and see what part of the program is causing them, and can/should I be using the crash exploration mode of the afl on these hangs? As I said I am a beginner in this and I really want to learn more, hopefully with your help. 

[Hanno Böck]

On Mon, 5 Dec 2016 04:21:46 -0800 (PST)
"Özge Çelenk" <ozgece...@gmail.com> wrote:

> I tried to do parallel fuzzing but that did not speed up
> the things noticeably, and the master fuzzer displays "odd, check
> syntax" warning after around 3 minutes, and the cycles end in one
> second or so.

If you see this message the most likely reason is that your program
doesn't really do anything with the input. Running this for days or
with parallel fuzzing is almost certainly pointless.

What program are you trying to fuzz? Is it something internal so you
can't give us any details?

With what command line are you calling afl-fuzz? Have you used a
combionation of flags to your tested program that causes an error? Or
have you simply missed to pass the placeholder for the input file?
(unless your tested programms reads from stdin you have to add @@ in
the command line, which will be replaced with the input file name)

--
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

[Özge Çelenk]

Hi Hanno , thanks for your response. Yes, the warning message I had been getting is most likely input related , however  I only receive this message when I do parallel fuzzing or when I change the default time and memory settings.I do not receive this error when I switch to fuzz with the default memory limit and timeout settings. With the default settings the fuzzer is running without an error, however it is terribly slow.  That's why I am a bit confused about it.  These are the command lines I tried so far:

           
             

afl-fuzz-i testcase_dir-o output_dir./program_name @@

When I start fuzzing with the above command the fuzzer is running slowly, without an error. 

afl-fuzz -i testcase_dir -o sync_dir -M fuzzer01 ./program_name @@  afl-fuzz -i testcase_dir -o sync_dir -S fuzzer02 ./program_name @@ When I use the above commands then I get the check syntax warning after 2 minutes or so. The program I am using is internal so at the moment I am afraid that I cant give you more details about it, but it is a C program that basically takes network traffic input(pcap file) for protocol and application classification of the given network. So with my slow fuzzer I have found so far 326 unique hangs in 13 days and still the first cycle hasn't completed. Now I am not sure what I should be doing next, how can I figure out what parts of the program are causing these hangs and how can they be fixed? I hope it is more clear now, have a nice day

[Erik Hendriks]

You probably not running this any more..

But the cycle counter is color coded, the first run it is magenta turning into yellow until it finds new paths, becomes blue when that stops and finally turns green if there's no new action for the fuzzer for a longer period of time.

See the docs
http://lcamtuf.coredump.cx/afl/status_screen.txt