Bugs and Improvments for frida_libpng fuzzer

[GanbaruTobi]

I tried to build the test fuzzer with make all. The result was:

a@b:/fuzzers/frida_libpng$ make all Build the frida libpng libfuzzer fuzzer cargo build --release ... Compiling libafl v0.7.1 (/home/a/LibAFL/libafl) Compiling libafl_targets v0.7.1 (/home/a/LibAFL/libafl_targets) Compiling libafl_frida v0.7.1 (/home/a/LibAFL/libafl_frida) Compiling frida_fuzzer v0.7.1 (/home/a/LibAFL/fuzzers/frida_libpng) Finished release [optimized + debuginfo] target(s) in 1m 32s cp target/release/frida_libpng libafl_frida cp: cannot stat 'target/release/frida_libpng': No such file or directory make: *** [Makefile:25: libafl_frida] Error 1

Obviously the naming is wrong. Besides I would suggest to not name the fuzzer release build "libafl_frida", since that is a component of LibAFL.

When haven chosen a name and trying to execute the tests included in the make file, they seem to do wrong parameter parsing for the fuzzer or I build the fuzzer a wrong way.

Every run or test option in Makefile has syntax like ./fuzzer harness.so .... , but the fuzzer cli says to use ./fuzzer -H harness.so ... Since I am not certain if I use the tooling wrong, i didn't provide a Pull request.

When using with the cli-options, is there anyway to tell if the fuzzer did load the corpus? Or is actually performing? My output looks just like this:

a@b:/home/a/LibAFL/fuzzers/frida_libpng$ ./frida_libpng_fuzzer -H ./libpng-harness.so -F LLVMFuzzerTestOneInput --cores=0,1 --input=./corpus spawning on cores: Cores { cmdline: "0,1", ids: [CoreId { id: 0 }, CoreId { id: 1 }] } child spawned and bound to core 0 164221 PostFork child spawned and bound to core 1 I am broker!!. 164222 PostFork New connection: 127.0.0.1:57542/127.0.0.1:57542 New connection: 127.0.0.1:57546/127.0.0.1:57546

^C Finished fuzzing. Good bye.

[domenukk]

Can you try cargo make test instead of the Makefile?

I agree the name of the fuzzer might need to be changed to avoid confusion

[GanbaruTobi]

Ah yes, that worked. Thanks. In that case the resulting fuzzer is called frida_fuzzer.

[cargo-make] INFO - Build Done in 3.19 seconds. spawning on cores: Cores { cmdline: "0", ids: [CoreId { id: 0 }] } child spawned and bound to core 0 I am broker!!. 378413 PostFork [Stats #1] (GLOBAL) run time: 0h-0m-0s, clients: 2, corpus: 0, objectives: 0, executions: 0, exec/sec: 0 (CLIENT) corpus: 0, objectives: 0, executions: 0, exec/sec: 0, edges: 1057/65536 (1%) [Testcase #1] (GLOBAL) run time: 0h-0m-0s, clients: 2, corpus: 1, objectives: 0, executions: 1, exec/sec: 0 (CLIENT) corpus: 1, objectives: 0, executions: 1, exec/sec: 0, edges: 1057/65536 (1%) [Stats #1] (GLOBAL) run time: 0h-0m-0s, clients: 2, corpus: 1, objectives: 0, executions: 1, exec/sec: 0 (CLIENT) corpus: 1, objectives: 0, executions: 1, exec/sec: 0, edges: 1295/65536 (1%) ...

Also its working with the fuzzer build from before when -l is also used as a parameter. I thought by following the code that the harness was in the list of instrumented code by default.

a@b:/home/a/LibAFL/fuzzers/frida_libpng$ ./frida_libpng_fuzzer -H ./libpng-harness.so -l ./libpng-harness.so -F LLVMFuzzerTestOneInput --cores=0,1 --input=./corpus spawning on cores: Cores { cmdline: "0,1", ids: [CoreId { id: 0 }, CoreId { id: 1 }] } child spawned and bound to core 0 389170 PostFork child spawned and bound to core 1 I am broker!!. 389171 PostFork New connection: 127.0.0.1:57570/127.0.0.1:57570 [Stats #1] (GLOBAL) run time: 0h-0m-0s, clients: 2, corpus: 0, objectives: 0, executions: 0, exec/sec: 0 (CLIENT) corpus: 0, objectives: 0, executions: 0, exec/sec: 0, edges: 983/65536 (1%) [Testcase #1] (GLOBAL) run time: 0h-0m-0s, clients: 2, corpus: 1, objectives: 0, executions: 1, exec/sec: 0 (CLIENT) corpus: 1, objectives: 0, executions: 1, exec/sec: 0, edges: 983/65536 (1%) ...

[tokatoka]

I forgot to delete that Makefile when we start to use cargo-make.

[domenukk]

When using with the cli-options, is there anyway to tell if the fuzzer did load the corpus? Or is actually performing?

Probably related to https://github.com/AFLplusplus/LibAFL/issues/615

[tokatoka]

Sorry for confusion, we don't use make anymore. I delete it in #652