jwilk / python-afl

American Fuzzy Lop fork server and instrumentation for pure-Python code
https://jwilk.net/software/python-afl
MIT License
350 stars 33 forks source link

Fork server handshake failed #2

Closed kryptidikettu closed 8 years ago

kryptidikettu commented 8 years ago

Trying to run my own testcases (very simple ones) and testcases from here: https://github.com/tomviner/afl-fuzzing-demos with the newest AFL (Version 2.19b) results in the following error:

[-] Hmm, looks like the target binary terminated before we could complete a
    handshake with the injected code. There are two probable explanations:

    - The current memory limit (50.0 MB) is too restrictive, causing an OOM
      fault in the dynamic linker. This can be fixed with the -m option. A
      simple way to confirm the diagnosis may be:

      ( ulimit -Sv $[49 << 10]; /path/to/fuzzed_app )

      Tip: you can use http://jwilk.net/software/recidivm to quickly
      estimate the required amount of virtual memory for the binary.

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

[-] PROGRAM ABORT : Fork server handshake failed
         Location : init_forkserver(), afl-fuzz.c:2241

Increasing the memory limit does not help.

Running the same testcases with normal AFL (afl-fuzz binary) works just fine with the dumb fuzzing flag -n. I'm trying with both Python 2.7.11 and Python 3.4.2.

jwilk commented 8 years ago

I've just tested tomviner's demo against AFL 2.19b + python-afl 0.5.3 + Python 2.7 + bidict 0.12.0, and it works for me. Unfortunately AFL doesn't make it easy to debug failures like this. The most common reason (IME) is that the target script doesn't work at all: it fails with import error, or some other kind of exception. So the first debugging step is to run the target script outside (py-)afl-fuzz and double-check that it actually works.

Running the same testcases with normal AFL (afl-fuzz binary) works just fine with the dumb fuzzing flag -n.

afl-fuzz -n is happy run just about anything, so this does not rule out brokenness of the target script.

kryptidikettu commented 8 years ago

Thanks. I did manage to run those tomviner's democases (don't know why they didn't originally work for me). I will start debugging my target script.

lynngeo commented 3 years ago

I've just tested tomviner's demo against AFL 2.19b + python-afl 0.5.3 + Python 2.7 + bidict 0.12.0, and it works for me. Unfortunately AFL doesn't make it easy to debug failures like this. The most common reason (IME) is that the target script doesn't work at all: it fails with import error, or some other kind of exception. So the first debugging step is to run the target script outside (py-)afl-fuzz and double-check that it actually works.

Running the same testcases with normal AFL (afl-fuzz binary) works just fine with the dumb fuzzing flag -n.

afl-fuzz -n is happy run just about anything, so this does not rule out brokenness of the target script.

thanks,it works