It seems afl mutator never grows a buffer

[expend20]

Hi!

I'm playing with manul, and have a simple fuzz function like this:

void fuzz() {
    FILE* fd = fopen(g_path, "r");
    static char tgt[] = "tgt";

    if (fgetc(fd) == tgt[0] && 
        fgetc(fd) == tgt[1] &&
        fgetc(fd) == tgt[2]) {
        *(char*)0 = 0;
    }

    fclose(fd);
}

I noticed that if I provide input corpus as a one file one byte long, it never grows to 2 bytes. If I provide input corpus 3 bytes long or more it finds a crash quite fast. So, it seems to me that alf mutator can't grow mutating buffer size. Could you please give me some pointers to resolve this issue?

Thanks!

[mxmssh]

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 :)

[expend20]

@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!

[mxmssh]

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.

[mxmssh]

Radamsa mutator should work on windows

[mxmssh]

It should work better now.

[mxmssh]

It should work now.

[expend20]

Thanks a lot! I've checked 9c5fe26c458ddc79651db0e8a7576ffd5f55800e 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.

[mxmssh]

Could you try the latest version?

[expend20]

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

[mxmssh]

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

[expend20]

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.

[mxmssh]

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

[expend20]

Yeah, correct. That part is just default:

mutator_weights=afl:10,radamsa:0

[mxmssh]

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.