[raisedbyninjas]

I'm not familiar with how the fuzzer was monitoring the executed code path. Would this be thwarted by address space layout randomization?

[runeks]

You build the target binary using a special version of gcc:

    3) Instrumenting programs for use with AFL
    ------------------------------------------

    Instrumentation is injected by a companion tool called afl-gcc. It is meant to
    be used as a drop-in replacement for GCC, directly pluggable into the standard
    build process for any third-party code.

    [...]

    The correct way to recompile the target program will vary depending on the
    specifics of the build process, but a common approach may be:

    $ CC=/path/to/afl/afl-gcc ./configure
    $ make clean all

    [...]

[jeffmcjunkin]

No. afl requires an instrumented (compiled with extra information) executable, and watches the code paths. When fuzzing a seed finds a new code path, it will recycle that fuzzed version as a new seed.

ASLR can help prevent successful exploitation of bugs that afl might find, but it won't prevent the program from crashing in the first place.

(Plus, since afl requires compiling the binary, I doubt it bothers to enable ASLR. There's no benefit for fuzzing purposes.)

[williamsharkey]

Can you fuzz an uninstrumented executable to add instrumentation?

[f-]

You can add instrumentation to binaries using DynamoRIO or pin. This isn't currently supported by afl-fuzz out of the box, although there's nothing that makes it fundamentally difficult.

[0x0]

It's probably using OS debugging APIs for tracing/code coverage and/or instrumenting the code during load directly (there's a mention of "lightweight assembly-level instrumentation"). ASLR is unlikely to be an issue for debuggers.