AFLplusplus / AFLplusplus

The fuzzer afl++ is afl with community patches, qemu 5.1 upgrade, collision-free coverage, enhanced laf-intel & redqueen, AFLfast++ power schedules, MOpt mutators, unicorn_mode, and a lot more!

Home Page:https://aflplus.plus

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

QEMU persistent mode & libcompcov?

kokkonisd opened this issue · comments

I'm fuzzing an HTTP server binary containing an infinite loop, which is why I'm using persistent mode to only fuzz the part of the server that processes requests.

However, to get past some magic byte comparisons, I'd like to make use of libcompcov; so, intuitively, I run the fuzzer like this:

$ AFL_QEMU_SNAPSHOT=<address of the request handler> AFL_PRELOAD=aflpp/utils/socket_fuzz/socketfuzz64.so:aflpp/libcompcov.so AFL_COMPCOV_LEVEL=2 aflpp/afl-fuzz -i in -o out -Q -- server

But that seems to somehow nuke the fuzzer's ability to instrument:

last new find : none yet (odd, check syntax!)

I'm assuming this is somehow related to AFL_QEMU_PERSISTENT_MEM, since if I set every other PERSISTENT env var but that one (AFL_QEMU_PERSISTENT_ADDR=<addr> AFL_QEMU_PERSISTENT_GPR=1 AFL_QEMU_PERSISTENT_EXITS=1) libcompcov seems to work, but I get a ton of false positive crashes (which is expected, since memory is not reset between persistent iterations IIUC).

Is there a way to have both the persistent mode and libcompcov work?

P.S.: I've also tried loading libcompcov by doing AFL_TARGET_ENV="LD_PRELOAD=aflpp/libcompcov.so:$LD_PRELOAD", but I'm not sure that actually loads libcompcov properly...

@andreafioraldi should work together, right?

Thanks!

just use AFL_ENTRYPOINT and fork mode imo on the node using the library and snapshot on the others

The only problem with this is that it also needs to exit before hitting the infinite server loop, otherwise it'll time out.
Is there another environment variable to tell QEMU on which address to exit?

No that is a feature that would be nice to have … AFL_EXITPOINT …
Should not be hard to implement

I looked a bit more into this.

It seems that, when libcompcov.so is used alongside the persistent mode in QEMU mode, a part of /proc/self/maps is saved and restored which is not picked up when libcompcov.so isn't present. That part of memory seems to be the shared memory where QEMU and libcompcov.so record coverage, so this is probably why we get no new finds.

I haven't yet tested extensively but I can prepare a patch (in QEMU-AFL) if you're interested.

@kokkonisd yes please! :)

Thanks!