4 ms·
I'm not familiar with how the fuzzer was monitoring the executed code path. Would this be thwarted by address space layout randomization?
by raisedbyninjas 12y ago
I'm not familiar with how the fuzzer was monitoring the executed code path. Would this be thwarted by address space layout randomization?
- 0x0 12y agoIt'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.
- runeks 12y agoYou 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 12y agoNo. 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 12y agoCan you fuzz an uninstrumented executable to add instrumentation?
- f- 12y agoYou 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.