It seems afl mutator never grows a buffer about manul HOT 14 CLOSED

Yep, there is such a problem in AFL mutator. I believe the original AFL has the same issue (may be not). The whole logic is implemented here: https://github.com/mxmssh/manul/blob/master/afl_fuzz.py. I think it is a corner case that should be handled specifically. I have never expected input to be 1 byte long :)

from manul.

@mxmssh thank you for response!

I'm just playing with it and looking what it is capable of. I've verified that AFL can grow input buffer from 1 byte without any hesitation (at least it's true for WinAFL's which is using a bit outdated version of AFL 2.43b). For example, I provided input corpus of one byte and the binary was checking 16 bytes byte-by-byte and then crash, WinAFL found a crash in 2-3mins single threaded . I've also checked manul's AFL python mutator on corpus from 1 to 16 bytes. In each case it was not able to grow buffer even on a single byte. So, it may be a bug which doesn't allow to grow input bigger no matter what size it is. So far I didn't look at mutator sources it's just some conclusions basted on testing.

Can I ask how are you debugging python code? I want to use interactive debuggin and I was trying using VSCode. It can't step inside of code which is behind multiprocessing.Process(), so I just patched the code to not to use this module and then I was able to attach interactive debugging to mutator's code. I'm just curious how are you doing this? :)

Btw, should radamsa mutator work on Windows? (I'm asking this because I've quickly checked it and wasn't able to leverage it)

Thanks!

from manul.

Seems like a bug in Manul :)

I don't usually use any IDE or step-by-step debugging for Python code, static code analysis + debug printing helps me to find 99% of the problems.

from manul.

Radamsa mutator should work on windows

from manul.

It should work better now.

from manul.

It should work now.

from manul.

Thanks a lot! I've checked 9c5fe26 revison, but I couldn't verify it. It seems AFL mutator is not able neither grow nor shrink sizes of input files. The sizes of files in "queue" directory is always equal to the corresponding sample in "input" directory.

from manul.

Could you try the latest version?

from manul.

Oh, sorry it was wrong revision given. I've tried 7c6037b just now, same result. No growing, no shrinking.

from manul.

That's weird :) Can you copy-paste manul.config that you are using for fuzzing? Are you doing coverage-guided fuzzing on Linux, right?

from manul.

Can you copy-paste manul.config that you are using for fuzzing?

sure, here you are:

dbi = dynamorio
dbi_root = z:\s\tools\dr791\bin32\drrun.exe
dbi_client_root = z:\s\git\manul\dbi_clients_src\client_32\RelWithDebInfo\binafl.dll
dbi_persistence_mode = 1
dbi_target_module = manul_test.exe
dbi_target_method = fuzz
dbi_fuzz_iterations = 20000

Are you doing coverage-guided fuzzing on Linux, right?

Nope, I'm on Windows. Here is the binary if want to try along.

manul.py -i in -o out -n 1 "...manul_test.exe @@"

For input corpus try just one file with one random byte.

from manul.

I see, do you allocate 100% for AFL mutator, right?

from manul.

Yeah, correct. That part is just default:

mutator_weights=afl:10,radamsa:0

from manul.

Ok, now it is finally fixed :) I have also compared winAFL and Manul on test32.exe distributed with Manul. Both fuzzers were able to identify crash. winAFL managed to identify the problem faster than Manul due to deadlock problem in Python3. However, the implementation seems to be correct.

Please take a look into current config if you want to test it on your own.

from manul.