Alternative way to feed inputs to AFL

[ravi prakash giri]

Hi everyone,

I have been working with AFL since last couple of weeks and trying to fuzz a binary generated from a complex library. The problem that I am facing is that, this library takes some .txt files as inputs only from a path mentioned in a configuration file of the library. My understanding about AFL is that, it needs to have inputs as command line arguments (@@ for AFL generated inputs). So, although I am able to run AFL, I am not getting any results.
Is there any way around this to ensure that the binary of this library takes inputs generated from AFL? One way could be to modify the source code of this library to take inputs as command line argument rather than from the file whose path is hardcoded in config file, but I would like to use it as my last resort.

Thanks

[Michal Zalewski]

> I have been working with AFL since last couple of weeks and trying to fuzz a
> binary generated from a complex library. The problem that I am facing is
> that, this library takes some .txt files as inputs only from a path
> mentioned in a configuration file of the library. My understanding about AFL
> is that, it needs to have inputs as command line arguments (@@ for AFL
> generated inputs). So, although I am able to run AFL, I am not getting any
> results.

You don't need to use @@. You can specify a location to write the
generated data to via the -f parameter to afl-fuzz.

Cheers,
/mz

[ravi prakash giri]

Thanks. I tried running it using -f option. So, I used the following command:

# /root/afl-2.42b/afl-fuzz -i /root/alf_in/ -o /root/afl_out ./binary_name start -f /root/afl_in/test.txt

Here, start is a command line argument that library needs to start. I hope I have used -f option correctly.
Also, I'm getting this error while running AFL for another instance of the same library.
Oops, the program crashed with one of the test cases provided. There are
    several possible explanations:

    - The test case causes known crashes under normal working conditions. If
      so, please remove it. The fuzzer should be seeded with interesting
      inputs - but not ones that cause an outright crash.

    - The current memory limit (50.0 MB) is too low for this program, causing
      it to die due to OOM when parsing valid files. To fix this, try
      bumping it up with the -m setting in the command line. If in doubt,
      try something along the lines of:

      ( ulimit -Sv $[49 << 10]; /path/to/binary [...] <testcase )

      Tip: you can use http://jwilk.net/software/recidivm to quickly
      estimate the required amount of virtual memory for the binary. Also,
      if you are using ASAN, see docs/notes_for_asan.txt.

    - Least likely, there is a horrible bug in the fuzzer. If other options
      fail, poke <lca...@coredump.cx> for troubleshooting tips.

[-] PROGRAM ABORT : Test case 'id:000000,orig:test2.txt' results in a crash
         Location : perform_dry_run(), afl-fuzz.c:2846

Any thought on this will be helpful.

Thanks
Ravi

[Michal Zalewski]

> # /root/afl-2.42b/afl-fuzz -i /root/alf_in/ -o /root/afl_out ./binary_name
> start -f /root/afl_in/test.txt

I don't understand what you're trying to do here. The -f option needs
to be passed to afl if you want it to write the test case to some
specific location. You're passing it to your target program instead.

That aside, you wouldn't want to put that file in the input directory
for the fuzzer; that's where the "seed" inputs go.

/mz

[ravi prakash giri]

Hi Michal,

Actually, the input folder name was different (alf_in). So, I corrected my above command which is now: afl-fuzz -f afl_test.txt -i in/ -o out/ ./binary_name start
So, afl_test.txt will have the test cases generated by the AFL. So, is there any way to see/verify the test cases generated in afl_test.txt? The size of this file is constantly 0byte (can't see any test cases written to it).

Also, I noticed you mentioned in the documentation that AFL can't detect crashes/hangs in child processes. So, is there any other way to detect crashes/hangs when it occurs in child processes?

Thanks
Ravi

[Michal Zalewski]

> So, afl_test.txt will have the test cases generated by the AFL. So, is there
> any way to see/verify the test cases generated in afl_test.txt?

Yes, examine the 'queue' subdirectory in the output directory. It will
contain all the generated test cases that AFL found interesting and is
using as seeds.

> The size of this file is constantly 0byte (can't see any test cases written to it).

That's not unusual, the file is constantly being overwritten.

> Also, I noticed you mentioned in the documentation that AFL can't detect
> crashes/hangs in child processes. So, is there any other way to detect
> crashes/hangs when it occurs in child processes?

Not within AFL, not in a portable way. The simplest solution is to
have a SIGCHLD handler that uses wait() to check whether the child
process was killed by a signal. This may interfere with some existing
child process handling in some cases; if so, you'd need to locate the
relevant wait / waitpid / waitid and add a check there.

When you detect that the child process died with SIGSEGV, SIGABRT, or
something like that, you can just call abort() and AFL will pick that
up.

/mz