fuzzer | Ptrace fuzzer experiments

So, I dug a bit into the fuzz draft design. Here's some insights.

First, as recommended in the blog post, you have to run the Go tip:

Whitebox fuzzing can be done not only with symbolic execution. SAGE from Microsoft Research is an example of a whitebox fuzzer that uses concolic execution, also called dynamic symbolic execution, see NDSS08.

Yes, Whitebox Fuzzers get some seed/seeds (initial input/inputs) and symbolically execute the code with these. Concolic fuzzers also run the code with these inputs in parallel with symbolic execution.

KLEE is a whitebox fuzzer that uses symbolic execution.

AFL is a greybox fuzzer - it uses internal structure information only to calculate coverage and not to get new paths. There are tools for AFL that get constants from comparisions in the code and add these to AFLs dictionaries, but this is still not whitebox fuzzing.

Afl supports feeding inputs through files, not only stdin. To test a library that receives input through arguments, you can write a simple executable that will open an input file, read it's contents, call the needed library functions with argument values read from this file and close the file.

In this context, PC means Program Counter as explained in this blog post

In order to log coverage, the function trace_pc will log the program counter. With this information, the fuzzer knows, which paths are traversed on the given input values. Each fuzzing engine runs through this process differently.

Yes, you can do that easily by making bridges between named pipes (fifos) and TCP connections through netcat.

Create two files (named pipes):

Use something like this:

The simplest way to "port" a Docker image to Singularity is to build the Singularity image directly from the Docker image: singularity build libpng_1.2.56.sif docker://gcr.io/fuzzbench/runners/afl/libpng-1.2.56-intermediate. If the source docker image has been built locally and is not in a remote registry use docker-daemon:// instead of docker://.

The documentation also has a pretty sizable Singularity and Docker section that goes over using Docker images with Singularity and similarities/differences between a Singularity definition file and a Dockerfile.

If you want to maintain separate Dockerfile and Singularity files for creating images, keep in mind there is not always a direct equivalent. e.g,. --tag in Docker is effectively equivalent to the filename of the Singularity image, buildkit settings are specific to the Docker build process and do not have a counterpart in Singularity.

You've tried to upgrade the version of QEMU that afl-qemu uses. Because afl-qemu makes modifications to QEMU's source, this is not a trivial thing to do. In particular, these commands that you commented out:

As mentioned in comments you are most likely running out of memory: by default all executables are linked statically so lds use a lot of RAM. There are several ways to counteract this:

1. Reduce link parallelism via -DLLVM_PARALLEL_LINK_JOBS=1 to avoid starting too many links in parallel (BTW for generic codebase one could use ld-limiter to achieve the same).

2. Reduce consumed memory by using either or both of -Wl,-no-keep-memory and -Wl,--reduce-memory-overheads linker flags (add them to CMAKE_EXE_LINKER_FLAGS).

3. Switch to Gold (via -fuse-ld=gold) or lld (via -fuse-ld=lld) linkers (add switch to CMAKE_EXE_LINKER_FLAGS).

4. In case you plan to frequently rebuild Clang (e.g. for debugging), you may use -DBUILD_SHARED_LIBS=ON to use shared, instead of static, links. You'll no longer have OOMs and also incremental Clang builds are sped up by 100x (at the cost of 2-3x slower Clang runtimes).