From 0ed0c9493ee2aeecd1a16a65e48348be8db5c662 Mon Sep 17 00:00:00 2001 From: root Date: Mon, 27 Sep 2021 06:21:12 +0300 Subject: Fix null ptr dereference of unresolved symbols on early init (linking stage) --- qemu_mode/libcompcov/libcompcov.so.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'qemu_mode') diff --git a/qemu_mode/libcompcov/libcompcov.so.c b/qemu_mode/libcompcov/libcompcov.so.c index 4fc84e62..24867cda 100644 --- a/qemu_mode/libcompcov/libcompcov.so.c +++ b/qemu_mode/libcompcov/libcompcov.so.c @@ -41,6 +41,13 @@ #error "Sorry, this library is Linux-specific for now!" #endif /* !__linux__ */ +#ifndef likely +# define likely(x) __builtin_expect((!!(x)),1) +#endif +#ifndef unlikely +# define unlikely(x) __builtin_expect((!!(x)),0) +#endif + /* Change this value to tune the compare coverage */ #define MAX_CMP_LENGTH 32 @@ -199,6 +206,7 @@ static u8 __compcov_is_in_bound(const void *ptr) { int strcmp(const char *str1, const char *str2) { + if (unlikely(!__libc_strcmp)) { __libc_strcmp = dlsym(RTLD_NEXT, "strcmp"); } void *retaddr = __builtin_return_address(0); if (__compcov_is_in_bound(retaddr) && @@ -227,6 +235,7 @@ int strcmp(const char *str1, const char *str2) { int strncmp(const char *str1, const char *str2, size_t len) { + if (unlikely(!__libc_strncmp)) { __libc_strncmp = dlsym(RTLD_NEXT, "strncmp"); } void *retaddr = __builtin_return_address(0); if (__compcov_is_in_bound(retaddr) && @@ -256,6 +265,7 @@ int strncmp(const char *str1, const char *str2, size_t len) { int strcasecmp(const char *str1, const char *str2) { + if (unlikely(!__libc_strcasecmp)) { __libc_strncasecmp = dlsym(RTLD_NEXT, "strcasecmp"); } void *retaddr = __builtin_return_address(0); if (__compcov_is_in_bound(retaddr) && @@ -286,6 +296,7 @@ int strcasecmp(const char *str1, const char *str2) { int strncasecmp(const char *str1, const char *str2, size_t len) { + if (unlikely(!__libc_strncasecmp)) { __libc_strncasecmp = dlsym(RTLD_NEXT, "strncasecmp"); } void *retaddr = __builtin_return_address(0); if (__compcov_is_in_bound(retaddr) && @@ -317,6 +328,7 @@ int strncasecmp(const char *str1, const char *str2, size_t len) { int memcmp(const void *mem1, const void *mem2, size_t len) { + if (unlikely(!__libc_memcmp)) { __libc_memcmp = dlsym(RTLD_NEXT, "memcmp"); } void *retaddr = __builtin_return_address(0); if (__compcov_is_in_bound(retaddr) && -- cgit 1.4.1 From d668f9697cc44a58ca38b42d99aa5143b13b703d Mon Sep 17 00:00:00 2001 From: Andrea Fioraldi Date: Fri, 1 Oct 2021 16:29:48 +0200 Subject: update qemuafl --- qemu_mode/QEMUAFL_VERSION | 2 +- qemu_mode/qemuafl | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) (limited to 'qemu_mode') diff --git a/qemu_mode/QEMUAFL_VERSION b/qemu_mode/QEMUAFL_VERSION index 215826cc..ade3a779 100644 --- a/qemu_mode/QEMUAFL_VERSION +++ b/qemu_mode/QEMUAFL_VERSION @@ -1 +1 @@ -a6758d1cc3 +86dead4dcb diff --git a/qemu_mode/qemuafl b/qemu_mode/qemuafl index a6758d1c..86dead4d 160000 --- a/qemu_mode/qemuafl +++ b/qemu_mode/qemuafl @@ -1 +1 @@ -Subproject commit a6758d1cc3e4dde88fca3f0b3a903581b7c8b2e5 +Subproject commit 86dead4dcb1aae7181fbf6b5f3706eee9f842e3a -- cgit 1.4.1 From 46683d651656f1876f6d4aeb24807ed71fa91237 Mon Sep 17 00:00:00 2001 From: vanhauser-thc Date: Mon, 4 Oct 2021 08:19:42 +0200 Subject: update docs --- README.md | 20 ++++++++++++++++---- docs/fuzzing_expert.md | 7 ++++++- qemu_mode/qemuafl | 2 +- unicorn_mode/unicornafl | 2 +- 4 files changed, 24 insertions(+), 7 deletions(-) (limited to 'qemu_mode') diff --git a/README.md b/README.md index db6a70b5..76ef8448 100644 --- a/README.md +++ b/README.md @@ -66,17 +66,29 @@ A common way to do this would be: make clean all 2. Get a small but valid input file that makes sense to the program. -When fuzzing verbose syntax (SQL, HTTP, etc), create a dictionary as described in [dictionaries/README.md](../dictionaries/README.md), too. +When fuzzing verbose syntax (SQL, HTTP, etc), create a dictionary as described +in [dictionaries/README.md](../dictionaries/README.md), too. 3. If the program reads from stdin, run `afl-fuzz` like so: - ./afl-fuzz -i testcase_dir -o findings_dir -- \ - /path/to/tested/program [...program's cmdline...] +``` + ./afl-fuzz -i seeds_dir -o output_dir -- \ + /path/to/tested/program [...program's cmdline...] +``` - If the program takes input from a file, you can put `@@` in the program's command line; AFL will put an auto-generated file name in there for you. + To add a dictionary, add `-x /path/to/dictionary.txt` to afl-fuzz. + + If the program takes input from a file, you can put `@@` in the program's + command line; AFL will put an auto-generated file name in there for you. 4. Investigate anything shown in red in the fuzzer UI by promptly consulting [docs/status_screen.md](docs/status_screen.md). +5. You will find found crashes and hangs in the subdirectories `crashes/` and + `hangs/` in the `-o output_dir` directory. You can replay the crashes by + feeding them to the target, e.g.: + `cat output_dir/crashes/id:000000,* | /path/to/tested/program [...program's cmdline...]` + You can generate cores or use gdb directly to follow up the crashes. + ## Contact Questions? Concerns? Bug reports? diff --git a/docs/fuzzing_expert.md b/docs/fuzzing_expert.md index 7695e21f..ca884159 100644 --- a/docs/fuzzing_expert.md +++ b/docs/fuzzing_expert.md @@ -540,6 +540,11 @@ To have only the summary use the `-s` switch e.g.: `afl-whatsup -s out/` If you have multiple servers then use the command after a sync, or you have to execute this script per server. +Another tool to inspect the current state and history of a specific instance +is afl-plot, which generates an index.html file and a graphs that show how +the fuzzing instance is performing. +The syntax is `afl-plot instance_dir web_dir`, e.g. `afl-plot out/default /srv/www/htdocs/plot` + #### e) Stopping fuzzing, restarting fuzzing, adding new seeds To stop an afl-fuzz run, simply press Control-C. @@ -620,4 +625,4 @@ This is basically all you need to know to professionally run fuzzing campaigns. If you want to know more, the tons of texts in [docs/](./) will have you covered. Note that there are also a lot of tools out there that help fuzzing with AFL++ -(some might be deprecated or unsupported), see [links_tools.md](links_tools.md). \ No newline at end of file +(some might be deprecated or unsupported), see [links_tools.md](links_tools.md). diff --git a/qemu_mode/qemuafl b/qemu_mode/qemuafl index 86dead4d..a6758d1c 160000 --- a/qemu_mode/qemuafl +++ b/qemu_mode/qemuafl @@ -1 +1 @@ -Subproject commit 86dead4dcb1aae7181fbf6b5f3706eee9f842e3a +Subproject commit a6758d1cc3e4dde88fca3f0b3a903581b7c8b2e5 diff --git a/unicorn_mode/unicornafl b/unicorn_mode/unicornafl index 1c47d1eb..c0e03d2c 160000 --- a/unicorn_mode/unicornafl +++ b/unicorn_mode/unicornafl @@ -1 +1 @@ -Subproject commit 1c47d1ebc7e904ad4efc1370f23e269fb9ac3f93 +Subproject commit c0e03d2c6b55a22025324f121746b41b1e756fb8 -- cgit 1.4.1 From 65e63b9cf107ae914630a4fff7381cee150df5fe Mon Sep 17 00:00:00 2001 From: Andrea Fioraldi Date: Wed, 6 Oct 2021 13:49:13 +0200 Subject: update qemu --- qemu_mode/QEMUAFL_VERSION | 2 +- qemu_mode/qemuafl | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) (limited to 'qemu_mode') diff --git a/qemu_mode/QEMUAFL_VERSION b/qemu_mode/QEMUAFL_VERSION index ade3a779..7bdedf7b 100644 --- a/qemu_mode/QEMUAFL_VERSION +++ b/qemu_mode/QEMUAFL_VERSION @@ -1 +1 @@ -86dead4dcb +71ed0d206f diff --git a/qemu_mode/qemuafl b/qemu_mode/qemuafl index a6758d1c..71ed0d20 160000 --- a/qemu_mode/qemuafl +++ b/qemu_mode/qemuafl @@ -1 +1 @@ -Subproject commit a6758d1cc3e4dde88fca3f0b3a903581b7c8b2e5 +Subproject commit 71ed0d206fd3d877420dceb4993a1011a4637ae6 -- cgit 1.4.1 From 00aa689f40a3c8276af257cf0b54dc655cb0423e Mon Sep 17 00:00:00 2001 From: vanhauser-thc Date: Mon, 11 Oct 2021 14:28:17 +0200 Subject: fix accidental bystander kills --- docs/Changelog.md | 2 ++ qemu_mode/qemuafl | 2 +- src/afl-forkserver.c | 6 +++--- unicorn_mode/unicornafl | 2 +- 4 files changed, 7 insertions(+), 5 deletions(-) (limited to 'qemu_mode') diff --git a/docs/Changelog.md b/docs/Changelog.md index dad5fee2..1c3830f9 100644 --- a/docs/Changelog.md +++ b/docs/Changelog.md @@ -18,6 +18,8 @@ sending a mail to . - fix -n dumb mode (nobody should use this) - afl-showmap, afl-tmin and afl-analyze now honor persistent mode for more speed. thanks to dloffre-snl for reporting! + - Prevent accidently killing non-afl/fuzz services when aborting + afl-showmap and other tools. - afl-cc: - fix for shared linking on MacOS - llvm and LTO mode verified to work with new llvm 14-dev diff --git a/qemu_mode/qemuafl b/qemu_mode/qemuafl index 71ed0d20..a6758d1c 160000 --- a/qemu_mode/qemuafl +++ b/qemu_mode/qemuafl @@ -1 +1 @@ -Subproject commit 71ed0d206fd3d877420dceb4993a1011a4637ae6 +Subproject commit a6758d1cc3e4dde88fca3f0b3a903581b7c8b2e5 diff --git a/src/afl-forkserver.c b/src/afl-forkserver.c index c8c94c08..54f510c4 100644 --- a/src/afl-forkserver.c +++ b/src/afl-forkserver.c @@ -610,12 +610,12 @@ void afl_fsrv_start(afl_forkserver_t *fsrv, char **argv, if (!time_ms) { - kill(fsrv->fsrv_pid, fsrv->kill_signal); + if (fsrv->fsrv_pid > 0) { kill(fsrv->fsrv_pid, fsrv->kill_signal); } } else if (time_ms > fsrv->init_tmout) { fsrv->last_run_timed_out = 1; - kill(fsrv->fsrv_pid, fsrv->kill_signal); + if (fsrv->fsrv_pid > 0) { kill(fsrv->fsrv_pid, fsrv->kill_signal); } } else { @@ -1248,7 +1248,7 @@ fsrv_run_result_t afl_fsrv_run_target(afl_forkserver_t *fsrv, u32 timeout, /* If there was no response from forkserver after timeout seconds, we kill the child. The forkserver should inform us afterwards */ - kill(fsrv->child_pid, fsrv->kill_signal); + if (fsrv->child_pid > 0) { kill(fsrv->child_pid, fsrv->kill_signal); } fsrv->last_run_timed_out = 1; if (read(fsrv->fsrv_st_fd, &fsrv->child_status, 4) < 4) { exec_ms = 0; } diff --git a/unicorn_mode/unicornafl b/unicorn_mode/unicornafl index f1c85364..c0e03d2c 160000 --- a/unicorn_mode/unicornafl +++ b/unicorn_mode/unicornafl @@ -1 +1 @@ -Subproject commit f1c853648a74b0157d233a2ef9f1693cfee78c11 +Subproject commit c0e03d2c6b55a22025324f121746b41b1e756fb8 -- cgit 1.4.1 From 3deca3b09b46130c9e23320c0b98f60543f9b5ba Mon Sep 17 00:00:00 2001 From: vanhauser-thc Date: Fri, 15 Oct 2021 11:25:02 +0200 Subject: fix lto cmplog stability issue --- custom_mutators/grammar_mutator/grammar_mutator | 2 +- docs/Changelog.md | 1 + qemu_mode/qemuafl | 2 +- src/afl-fuzz-run.c | 30 +++++++++++++++++++++++-- unicorn_mode/unicornafl | 2 +- 5 files changed, 32 insertions(+), 5 deletions(-) (limited to 'qemu_mode') diff --git a/custom_mutators/grammar_mutator/grammar_mutator b/custom_mutators/grammar_mutator/grammar_mutator index eedf07dd..b79d51a8 160000 --- a/custom_mutators/grammar_mutator/grammar_mutator +++ b/custom_mutators/grammar_mutator/grammar_mutator @@ -1 +1 @@ -Subproject commit eedf07ddb0fb1f437f5e76b77cfd4064cf6a5d63 +Subproject commit b79d51a8daccbd7a693f9b6765c81ead14f28e26 diff --git a/docs/Changelog.md b/docs/Changelog.md index ea58a386..df4d343a 100644 --- a/docs/Changelog.md +++ b/docs/Changelog.md @@ -16,6 +16,7 @@ sending a mail to . - fix a regression introduced in 3.10 that resulted in less coverage being detected. thanks to Collin May for reporting! - fix -n dumb mode (nobody should use this) + - fix stability issue with LTO and cmplog - afl-showmap, afl-tmin and afl-analyze now honor persistent mode for more speed. thanks to dloffre-snl for reporting! - Prevent accidently killing non-afl/fuzz services when aborting diff --git a/qemu_mode/qemuafl b/qemu_mode/qemuafl index a6758d1c..71ed0d20 160000 --- a/qemu_mode/qemuafl +++ b/qemu_mode/qemuafl @@ -1 +1 @@ -Subproject commit a6758d1cc3e4dde88fca3f0b3a903581b7c8b2e5 +Subproject commit 71ed0d206fd3d877420dceb4993a1011a4637ae6 diff --git a/src/afl-fuzz-run.c b/src/afl-fuzz-run.c index 4173f4e1..da6ba7d9 100644 --- a/src/afl-fuzz-run.c +++ b/src/afl-fuzz-run.c @@ -291,8 +291,6 @@ static void write_with_gap(afl_state_t *afl, u8 *mem, u32 len, u32 skip_at, u8 calibrate_case(afl_state_t *afl, struct queue_entry *q, u8 *use_mem, u32 handicap, u8 from_queue) { - if (unlikely(afl->shm.cmplog_mode)) { q->exec_cksum = 0; } - u8 fault = 0, new_bits = 0, var_detected = 0, hnb = 0, first_run = (q->exec_cksum == 0); u64 start_us, stop_us, diff_us; @@ -300,6 +298,8 @@ u8 calibrate_case(afl_state_t *afl, struct queue_entry *q, u8 *use_mem, u32 use_tmout = afl->fsrv.exec_tmout; u8 *old_sn = afl->stage_name; + if (unlikely(afl->shm.cmplog_mode)) { q->exec_cksum = 0; } + /* Be a bit more generous about timeouts when resuming sessions, or when trying to calibrate already-added finds. This helps avoid trouble due to intermittent latency. */ @@ -343,6 +343,32 @@ u8 calibrate_case(afl_state_t *afl, struct queue_entry *q, u8 *use_mem, } + /* we need a dummy run if this is LTO + cmplog */ + if (unlikely(afl->shm.cmplog_mode)) { + + write_to_testcase(afl, use_mem, q->len); + + fault = fuzz_run_target(afl, &afl->fsrv, use_tmout); + + /* afl->stop_soon is set by the handler for Ctrl+C. When it's pressed, + we want to bail out quickly. */ + + if (afl->stop_soon || fault != afl->crash_mode) { goto abort_calibration; } + + if (!afl->non_instrumented_mode && !afl->stage_cur && + !count_bytes(afl, afl->fsrv.trace_bits)) { + + fault = FSRV_RUN_NOINST; + goto abort_calibration; + + } + +#ifdef INTROSPECTION + if (unlikely(!q->bitsmap_size)) q->bitsmap_size = afl->bitsmap_size; +#endif + + } + if (q->exec_cksum) { memcpy(afl->first_trace, afl->fsrv.trace_bits, afl->fsrv.map_size); diff --git a/unicorn_mode/unicornafl b/unicorn_mode/unicornafl index d4915053..f1c85364 160000 --- a/unicorn_mode/unicornafl +++ b/unicorn_mode/unicornafl @@ -1 +1 @@ -Subproject commit d4915053d477dd827b3fe4b494173d3fbf9f456e +Subproject commit f1c853648a74b0157d233a2ef9f1693cfee78c11 -- cgit 1.4.1 From 45399b7a56f77652f09f6825a7bdf2ae1708ff3a Mon Sep 17 00:00:00 2001 From: vanhauser-thc Date: Wed, 3 Nov 2021 13:35:52 +0100 Subject: afl4 qemu --- qemu_mode/QEMUAFL_VERSION | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'qemu_mode') diff --git a/qemu_mode/QEMUAFL_VERSION b/qemu_mode/QEMUAFL_VERSION index 7bdedf7b..40bae8f5 100644 --- a/qemu_mode/QEMUAFL_VERSION +++ b/qemu_mode/QEMUAFL_VERSION @@ -1 +1 @@ -71ed0d206f +4eb8c66a6077157e96f8660c0e64a69f001dc06f -- cgit 1.4.1 From 6ce3d7fede6b32b522b6cc4403f7c0101cf4a4bc Mon Sep 17 00:00:00 2001 From: vanhauser-thc Date: Thu, 4 Nov 2021 15:53:17 +0100 Subject: add AFL_USE_TSAN --- TODO.md | 1 + docs/Changelog.md | 2 + docs/fuzzing_expert.md | 2 + frida_mode/src/instrument/instrument.c | 4 +- frida_mode/src/instrument/instrument_arm32.c | 2 + frida_mode/src/instrument/instrument_arm64.c | 1 + frida_mode/src/instrument/instrument_x64.c | 54 ++++++++++++++------------ frida_mode/src/instrument/instrument_x86.c | 1 + frida_mode/src/main.c | 7 ++-- frida_mode/src/prefetch.c | 6 +-- frida_mode/src/seccomp/seccomp_callback.c | 32 ++++++++------- frida_mode/src/seccomp/seccomp_filter.c | 6 +-- include/envs.h | 1 + instrumentation/SanitizerCoverageLTO.so.cc | 3 +- instrumentation/SanitizerCoveragePCGUARD.so.cc | 3 +- instrumentation/afl-llvm-pass.so.cc | 3 +- qemu_mode/libcompcov/libcompcov.so.c | 25 +++++++++--- src/afl-as.c | 1 + src/afl-cc.c | 9 +++++ utils/aflpp_driver/aflpp_qemu_driver.c | 2 +- 20 files changed, 106 insertions(+), 59 deletions(-) (limited to 'qemu_mode') diff --git a/TODO.md b/TODO.md index 1d4270b4..30676312 100644 --- a/TODO.md +++ b/TODO.md @@ -2,6 +2,7 @@ ## TODO + - AFL_USE_TSAN to docs/env_variables.md after work over - screen update during input2stage - better autodetection of shifting runtime timeout values - Update afl->pending_not_fuzzed for MOpt diff --git a/docs/Changelog.md b/docs/Changelog.md index 04b2fb2e..cfeb8cc1 100644 --- a/docs/Changelog.md +++ b/docs/Changelog.md @@ -26,7 +26,9 @@ sending a mail to . - Prevent accidently killing non-afl/fuzz services when aborting afl-showmap and other tools. - afl-cc: + - support llvm IR select instrumentation for default PCGUARD and LTO - fix for shared linking on MacOS + - added AFL_USE_TSAN thread sanitizer support - llvm and LTO mode modified to work with new llvm 14-dev (again) - added the very good grammar mutator "GramaTron" to the custom_mutators diff --git a/docs/fuzzing_expert.md b/docs/fuzzing_expert.md index 96193f88..44ebade4 100644 --- a/docs/fuzzing_expert.md +++ b/docs/fuzzing_expert.md @@ -149,6 +149,8 @@ The following sanitizers have built-in support in AFL++: vulnerabilities - which is however one of the most important and dangerous C++ memory corruption classes! Enabled with `export AFL_USE_CFISAN=1` before compiling. + * TSAN = Thread SANitizer, finds thread race conditions. + Enabled with `export AFL_USE_TSAN=1` before compiling. * LSAN = Leak SANitizer, finds memory leaks in a program. This is not really a security issue, but for developers this can be very valuable. Note that unlike the other sanitizers above this needs diff --git a/frida_mode/src/instrument/instrument.c b/frida_mode/src/instrument/instrument.c index 81d85aa1..eeebe545 100644 --- a/frida_mode/src/instrument/instrument.c +++ b/frida_mode/src/instrument/instrument.c @@ -347,8 +347,8 @@ void instrument_init(void) { #else tid = syscall(SYS_gettid); #endif - instrument_hash_seed = g_get_monotonic_time() ^ - (((guint64)getpid()) << 32) ^ tid; + instrument_hash_seed = + g_get_monotonic_time() ^ (((guint64)getpid()) << 32) ^ tid; } diff --git a/frida_mode/src/instrument/instrument_arm32.c b/frida_mode/src/instrument/instrument_arm32.c index 4b0a648e..395d56c1 100644 --- a/frida_mode/src/instrument/instrument_arm32.c +++ b/frida_mode/src/instrument/instrument_arm32.c @@ -23,7 +23,9 @@ void instrument_coverage_optimize(const cs_insn * instr, } void instrument_coverage_optimize_init(void) { + WARNF("Optimized coverage not supported on this architecture"); + } void instrument_flush(GumStalkerOutput *output) { diff --git a/frida_mode/src/instrument/instrument_arm64.c b/frida_mode/src/instrument/instrument_arm64.c index 80d1d845..358e8e6b 100644 --- a/frida_mode/src/instrument/instrument_arm64.c +++ b/frida_mode/src/instrument/instrument_arm64.c @@ -96,6 +96,7 @@ void instrument_coverage_optimize(const cs_insn * instr, } void instrument_coverage_optimize_init(void) { + } void instrument_flush(GumStalkerOutput *output) { diff --git a/frida_mode/src/instrument/instrument_x64.c b/frida_mode/src/instrument/instrument_x64.c index a7eb650a..19ec81b2 100644 --- a/frida_mode/src/instrument/instrument_x64.c +++ b/frida_mode/src/instrument/instrument_x64.c @@ -4,12 +4,12 @@ #include #if defined(__linux__) -#if !defined(__ANDROID__) -#include -#include -#else -#include -#endif + #if !defined(__ANDROID__) + #include + #include + #else + #include + #endif #endif #include "frida-gumjs.h" @@ -22,13 +22,13 @@ #if defined(__x86_64__) -#ifndef MAP_FIXED_NOREPLACE - #ifdef MAP_EXCL - #define MAP_FIXED_NOREPLACE MAP_EXCL | MAP_FIXED - #else - #define MAP_FIXED_NOREPLACE MAP_FIXED + #ifndef MAP_FIXED_NOREPLACE + #ifdef MAP_EXCL + #define MAP_FIXED_NOREPLACE MAP_EXCL | MAP_FIXED + #else + #define MAP_FIXED_NOREPLACE MAP_FIXED + #endif #endif -#endif gboolean instrument_is_coverage_optimize_supported(void) { @@ -53,15 +53,12 @@ typedef struct { // 0x7ffff6cfb08b: pushf // 0x7ffff6cfb08c: push rsi // 0x7ffff6cfb08d: mov rsi,0x228 - // 0x7ffff6cfb094: xchg QWORD PTR [rip+0x3136a5],rsi # 0x7ffff700e740 - // 0x7ffff6cfb09b: xor rsi,0x451 - // 0x7ffff6cfb0a2: add BYTE PTR [rsi+0x10000],0x1 - // 0x7ffff6cfb0a9: adc BYTE PTR [rsi+0x10000],0x0 - // 0x7ffff6cfb0b0: pop rsi - // 0x7ffff6cfb0b1: popf + // 0x7ffff6cfb094: xchg QWORD PTR [rip+0x3136a5],rsi # + // 0x7ffff700e740 0x7ffff6cfb09b: xor rsi,0x451 0x7ffff6cfb0a2: add + // BYTE PTR [rsi+0x10000],0x1 0x7ffff6cfb0a9: adc BYTE PTR + // [rsi+0x10000],0x0 0x7ffff6cfb0b0: pop rsi 0x7ffff6cfb0b1: popf // 0x7ffff6cfb0b2: lea rsp,[rsp+0x80] - uint8_t lea_rsp_rsp_sub_rz[5]; uint8_t push_fq; uint8_t push_rsi; @@ -160,16 +157,25 @@ static void instrument_coverage_optimize_map_mmap(char * shm_file_path, __afl_area_ptr = NULL; -#if !defined(__ANDROID__) + #if !defined(__ANDROID__) shm_fd = shm_open(shm_file_path, O_RDWR, DEFAULT_PERMISSION); if (shm_fd == -1) { FATAL("shm_open() failed\n"); } -#else + #else shm_fd = open("/dev/ashmem", O_RDWR); if (shm_fd == -1) { FATAL("open() failed\n"); } - if (ioctl(shm_fd, ASHMEM_SET_NAME, shm_file_path) == -1) { FATAL("ioctl(ASHMEM_SET_NAME) failed"); } - if (ioctl(shm_fd, ASHMEM_SET_SIZE, __afl_map_size) == -1) { FATAL("ioctl(ASHMEM_SET_SIZE) failed"); } + if (ioctl(shm_fd, ASHMEM_SET_NAME, shm_file_path) == -1) { -#endif + FATAL("ioctl(ASHMEM_SET_NAME) failed"); + + } + + if (ioctl(shm_fd, ASHMEM_SET_SIZE, __afl_map_size) == -1) { + + FATAL("ioctl(ASHMEM_SET_SIZE) failed"); + + } + + #endif __afl_area_ptr = mmap(address, __afl_map_size, PROT_READ | PROT_WRITE, MAP_FIXED_NOREPLACE | MAP_SHARED, shm_fd, 0); diff --git a/frida_mode/src/instrument/instrument_x86.c b/frida_mode/src/instrument/instrument_x86.c index 1ff5c920..f90c01c2 100644 --- a/frida_mode/src/instrument/instrument_x86.c +++ b/frida_mode/src/instrument/instrument_x86.c @@ -84,6 +84,7 @@ void instrument_coverage_optimize(const cs_insn * instr, } void instrument_coverage_optimize_init(void) { + } void instrument_flush(GumStalkerOutput *output) { diff --git a/frida_mode/src/main.c b/frida_mode/src/main.c index c8183d8f..3599143b 100644 --- a/frida_mode/src/main.c +++ b/frida_mode/src/main.c @@ -126,15 +126,16 @@ static void afl_print_cmdline(void) { g_free(fname); g_free(buffer); #elif defined(__APPLE__) - int idx; + int idx; char **argv = *_NSGetArgv(); - int nargv = *_NSGetArgc(); + int nargv = *_NSGetArgc(); - for (idx = 0; idx < nargv; idx ++) { + for (idx = 0; idx < nargv; idx++) { OKF("AFL - COMMANDLINE: argv[%d] = %s", idx, argv[idx]); } + #endif } diff --git a/frida_mode/src/prefetch.c b/frida_mode/src/prefetch.c index c30ca65c..1ddbd5ed 100644 --- a/frida_mode/src/prefetch.c +++ b/frida_mode/src/prefetch.c @@ -44,8 +44,8 @@ static void gum_afl_stalker_backpatcher_notify(GumStalkerObserver *self, sizeof(prefetch_data->backpatch_data) - prefetch_data->backpatch_size; if (sizeof(gsize) + size > remaining) { return; } - gsize *dst_backpatch_size = (gsize *) - &prefetch_data->backpatch_data[prefetch_data->backpatch_size]; + gsize *dst_backpatch_size = + (gsize *)&prefetch_data->backpatch_data[prefetch_data->backpatch_size]; *dst_backpatch_size = size; prefetch_data->backpatch_size += sizeof(gsize); @@ -117,7 +117,7 @@ static void prefetch_read_patches(void) { remaining = prefetch_data->backpatch_size - offset) { gsize *src_backpatch_data = (gsize *)&prefetch_data->backpatch_data[offset]; - gsize size = *src_backpatch_data; + gsize size = *src_backpatch_data; offset += sizeof(gsize); if (prefetch_data->backpatch_size - offset < size) { diff --git a/frida_mode/src/seccomp/seccomp_callback.c b/frida_mode/src/seccomp/seccomp_callback.c index 4232d842..ac0fb8bb 100644 --- a/frida_mode/src/seccomp/seccomp_callback.c +++ b/frida_mode/src/seccomp/seccomp_callback.c @@ -1,8 +1,8 @@ #if defined(__linux__) && !defined(__ANDROID__) -#if !defined(__MUSL__) - #include -#endif + #if !defined(__MUSL__) + #include + #endif #include #include "seccomp.h" @@ -16,12 +16,13 @@ static void seccomp_callback_filter(struct seccomp_notif * req, GumDebugSymbolDetails details = {0}; if (req->data.nr == SYS_OPENAT) { -#if UINTPTR_MAX == 0xffffffffffffffffu + #if UINTPTR_MAX == 0xffffffffffffffffu seccomp_print("SYS_OPENAT: (%s)\n", (char *)req->data.args[1]); -#endif -#if UINTPTR_MAX == 0xffffffff + #endif + #if UINTPTR_MAX == 0xffffffff seccomp_print("SYS_OPENAT: (%s)\n", (char *)(__u32)req->data.args[1]); -#endif + #endif + } seccomp_print( @@ -31,7 +32,7 @@ static void seccomp_callback_filter(struct seccomp_notif * req, req->data.args[0], req->data.args[1], req->data.args[2], req->data.args[3], req->data.args[4], req->data.args[5]); -#if !defined(__MUSL__) + #if !defined(__MUSL__) seccomp_print("FRAMES: (%u)\n", frames->len); char **syms = backtrace_symbols(frames->items, frames->len); if (syms == NULL) { FATAL("Failed to get symbols"); } @@ -52,23 +53,24 @@ static void seccomp_callback_filter(struct seccomp_notif * req, } free(syms); -#else + #else void **syms = (void **)__builtin_frame_address(0); - void *framep = __builtin_frame_address(1); - int i = 0; + void * framep = __builtin_frame_address(1); + int i = 0; syms = framep; while (syms) { - - framep = *syms; + + framep = *syms; syms = framep; if (!syms) break; - seccomp_print("\%3d. %s\n", i ++, (char *)framep); + seccomp_print("\%3d. %s\n", i++, (char *)framep); } -#endif + + #endif resp->error = 0; resp->val = 0; diff --git a/frida_mode/src/seccomp/seccomp_filter.c b/frida_mode/src/seccomp/seccomp_filter.c index 7ee5ead1..0dcc4cbb 100644 --- a/frida_mode/src/seccomp/seccomp_filter.c +++ b/frida_mode/src/seccomp/seccomp_filter.c @@ -2,9 +2,9 @@ #include #include -#if !defined(__MUSL__) - #include -#endif + #if !defined(__MUSL__) + #include + #endif #include #include #include diff --git a/include/envs.h b/include/envs.h index 61267a0d..25d05539 100644 --- a/include/envs.h +++ b/include/envs.h @@ -203,6 +203,7 @@ static char *afl_environment_variables[] = { "AFL_USE_MSAN", "AFL_USE_TRACE_PC", "AFL_USE_UBSAN", + "AFL_USE_TSAN", "AFL_USE_CFISAN", "AFL_USE_LSAN", "AFL_WINE_PATH", diff --git a/instrumentation/SanitizerCoverageLTO.so.cc b/instrumentation/SanitizerCoverageLTO.so.cc index ee8c317e..4e25221a 100644 --- a/instrumentation/SanitizerCoverageLTO.so.cc +++ b/instrumentation/SanitizerCoverageLTO.so.cc @@ -1142,10 +1142,11 @@ bool ModuleSanitizerCoverage::instrumentModule( else { char modeline[100]; - snprintf(modeline, sizeof(modeline), "%s%s%s%s%s", + snprintf(modeline, sizeof(modeline), "%s%s%s%s%s%s", getenv("AFL_HARDEN") ? "hardened" : "non-hardened", getenv("AFL_USE_ASAN") ? ", ASAN" : "", getenv("AFL_USE_MSAN") ? ", MSAN" : "", + getenv("AFL_USE_TSAN") ? ", TSAN" : "", getenv("AFL_USE_CFISAN") ? ", CFISAN" : "", getenv("AFL_USE_UBSAN") ? ", UBSAN" : ""); OKF("Instrumented %u locations (%u selects) without collisions (%llu " diff --git a/instrumentation/SanitizerCoveragePCGUARD.so.cc b/instrumentation/SanitizerCoveragePCGUARD.so.cc index be3f4f49..76bb2448 100644 --- a/instrumentation/SanitizerCoveragePCGUARD.so.cc +++ b/instrumentation/SanitizerCoveragePCGUARD.so.cc @@ -547,10 +547,11 @@ bool ModuleSanitizerCoverage::instrumentModule( else { char modeline[100]; - snprintf(modeline, sizeof(modeline), "%s%s%s%s%s", + snprintf(modeline, sizeof(modeline), "%s%s%s%s%s%s", getenv("AFL_HARDEN") ? "hardened" : "non-hardened", getenv("AFL_USE_ASAN") ? ", ASAN" : "", getenv("AFL_USE_MSAN") ? ", MSAN" : "", + getenv("AFL_USE_TSAN") ? ", TSAN" : "", getenv("AFL_USE_CFISAN") ? ", CFISAN" : "", getenv("AFL_USE_UBSAN") ? ", UBSAN" : ""); OKF("Instrumented %u locations with no collisions (%s mode) of which are " diff --git a/instrumentation/afl-llvm-pass.so.cc b/instrumentation/afl-llvm-pass.so.cc index ecf28f31..9b7e625e 100644 --- a/instrumentation/afl-llvm-pass.so.cc +++ b/instrumentation/afl-llvm-pass.so.cc @@ -956,11 +956,12 @@ bool AFLCoverage::runOnModule(Module &M) { else { char modeline[100]; - snprintf(modeline, sizeof(modeline), "%s%s%s%s%s", + snprintf(modeline, sizeof(modeline), "%s%s%s%s%s%s", getenv("AFL_HARDEN") ? "hardened" : "non-hardened", getenv("AFL_USE_ASAN") ? ", ASAN" : "", getenv("AFL_USE_MSAN") ? ", MSAN" : "", getenv("AFL_USE_CFISAN") ? ", CFISAN" : "", + getenv("AFL_USE_TSAN") ? ", TSAN" : "", getenv("AFL_USE_UBSAN") ? ", UBSAN" : ""); OKF("Instrumented %d locations (%s mode, ratio %u%%).", inst_blocks, modeline, inst_ratio); diff --git a/qemu_mode/libcompcov/libcompcov.so.c b/qemu_mode/libcompcov/libcompcov.so.c index 24867cda..eba3d80a 100644 --- a/qemu_mode/libcompcov/libcompcov.so.c +++ b/qemu_mode/libcompcov/libcompcov.so.c @@ -42,10 +42,10 @@ #endif /* !__linux__ */ #ifndef likely -# define likely(x) __builtin_expect((!!(x)),1) + #define likely(x) __builtin_expect((!!(x)), 1) #endif #ifndef unlikely -# define unlikely(x) __builtin_expect((!!(x)),0) + #define unlikely(x) __builtin_expect((!!(x)), 0) #endif /* Change this value to tune the compare coverage */ @@ -235,7 +235,12 @@ int strcmp(const char *str1, const char *str2) { int strncmp(const char *str1, const char *str2, size_t len) { - if (unlikely(!__libc_strncmp)) { __libc_strncmp = dlsym(RTLD_NEXT, "strncmp"); } + if (unlikely(!__libc_strncmp)) { + + __libc_strncmp = dlsym(RTLD_NEXT, "strncmp"); + + } + void *retaddr = __builtin_return_address(0); if (__compcov_is_in_bound(retaddr) && @@ -265,7 +270,12 @@ int strncmp(const char *str1, const char *str2, size_t len) { int strcasecmp(const char *str1, const char *str2) { - if (unlikely(!__libc_strcasecmp)) { __libc_strncasecmp = dlsym(RTLD_NEXT, "strcasecmp"); } + if (unlikely(!__libc_strcasecmp)) { + + __libc_strncasecmp = dlsym(RTLD_NEXT, "strcasecmp"); + + } + void *retaddr = __builtin_return_address(0); if (__compcov_is_in_bound(retaddr) && @@ -296,7 +306,12 @@ int strcasecmp(const char *str1, const char *str2) { int strncasecmp(const char *str1, const char *str2, size_t len) { - if (unlikely(!__libc_strncasecmp)) { __libc_strncasecmp = dlsym(RTLD_NEXT, "strncasecmp"); } + if (unlikely(!__libc_strncasecmp)) { + + __libc_strncasecmp = dlsym(RTLD_NEXT, "strncasecmp"); + + } + void *retaddr = __builtin_return_address(0); if (__compcov_is_in_bound(retaddr) && diff --git a/src/afl-as.c b/src/afl-as.c index 7119d630..774340ac 100644 --- a/src/afl-as.c +++ b/src/afl-as.c @@ -521,6 +521,7 @@ static void add_instrumentation(void) { getenv("AFL_HARDEN") ? "hardened" : "non-hardened", getenv("AFL_USE_ASAN") ? ", ASAN" : "", getenv("AFL_USE_MSAN") ? ", MSAN" : "", + getenv("AFL_USE_TSAN") ? ", TSAN" : "", getenv("AFL_USE_UBSAN") ? ", UBSAN" : "", getenv("AFL_USE_LSAN") ? ", LSAN" : ""); diff --git a/src/afl-cc.c b/src/afl-cc.c index e7f08aac..3837459b 100644 --- a/src/afl-cc.c +++ b/src/afl-cc.c @@ -857,6 +857,14 @@ static void edit_params(u32 argc, char **argv, char **envp) { cc_params[cc_par_cnt++] = "-fsanitize=undefined"; cc_params[cc_par_cnt++] = "-fsanitize-undefined-trap-on-error"; cc_params[cc_par_cnt++] = "-fno-sanitize-recover=all"; + cc_params[cc_par_cnt++] = "-fno-omit-frame-pointer"; + + } + + if (getenv("AFL_USE_TSAN")) { + + cc_params[cc_par_cnt++] = "-fsanitize=thread"; + cc_params[cc_par_cnt++] = "-fno-omit-frame-pointer"; } @@ -1814,6 +1822,7 @@ int main(int argc, char **argv, char **envp) { " AFL_USE_CFISAN: activate control flow sanitizer\n" " AFL_USE_MSAN: activate memory sanitizer\n" " AFL_USE_UBSAN: activate undefined behaviour sanitizer\n" + " AFL_USE_TSAN: activate thread sanitizer\n" " AFL_USE_LSAN: activate leak-checker sanitizer\n"); if (have_gcc_plugin) diff --git a/utils/aflpp_driver/aflpp_qemu_driver.c b/utils/aflpp_driver/aflpp_qemu_driver.c index 99a4c9a8..e47df1e6 100644 --- a/utils/aflpp_driver/aflpp_qemu_driver.c +++ b/utils/aflpp_driver/aflpp_qemu_driver.c @@ -22,7 +22,7 @@ int main(int argc, char **argv) { if (LLVMFuzzerInitialize) LLVMFuzzerInitialize(&argc, &argv); // Do any other expensive one-time initialization here. - if (getenv("AFL_QEMU_DRIVER_NO_HOOK")) { + if (getenv("AFL_QEMU_DRIVER_NO_HOOK") || getenv("AFL_FRIDA_DRIVER_NO_HOOK")) { afl_qemu_driver_stdin_input(); -- cgit 1.4.1 From 9325a4fcbb8eb4ed1d71f93de5301bf1a9a68253 Mon Sep 17 00:00:00 2001 From: vanhauser-thc Date: Sat, 6 Nov 2021 10:28:22 +0100 Subject: http->https --- GNUmakefile | 2 +- GNUmakefile.gcc_plugin | 2 +- GNUmakefile.llvm | 2 +- TODO.md | 1 - afl-cmin.bash | 2 +- afl-plot | 2 +- afl-whatsup | 2 +- docs/Changelog.md | 2 +- docs/INSTALL.md | 2 +- docs/best_practices.md | 2 +- docs/interpreting_output.md | 2 +- docs/known_limitations.md | 2 +- docs/sister_projects.md | 12 ++++++------ docs/technical_details.md | 12 ++++++------ frida_mode/Scripting.md | 2 +- include/afl-as.h | 4 ++-- include/afl-fuzz.h | 2 +- include/afl-prealloc.h | 2 +- include/alloc-inl.h | 2 +- include/cmplog.h | 2 +- include/common.h | 2 +- include/config.h | 2 +- include/debug.h | 2 +- include/forkserver.h | 2 +- include/hash.h | 2 +- include/list.h | 2 +- include/sharedmem.h | 2 +- include/snapshot-inl.h | 2 +- include/types.h | 2 +- instrumentation/README.llvm.md | 2 +- instrumentation/afl-compiler-rt.o.c | 2 +- instrumentation/afl-gcc-pass.so.cc | 2 +- instrumentation/afl-llvm-dict2file.so.cc | 2 +- instrumentation/afl-llvm-lto-instrumentation.so.cc | 2 +- instrumentation/afl-llvm-lto-instrumentlist.so.cc | 2 +- instrumentation/afl-llvm-pass.so.cc | 2 +- instrumentation/afl-llvm-rt-lto.o.c | 2 +- instrumentation/cmplog-instructions-pass.cc | 2 +- instrumentation/cmplog-routines-pass.cc | 2 +- instrumentation/cmplog-switches-pass.cc | 2 +- instrumentation/compare-transform-pass.so.cc | 2 +- instrumentation/split-compares-pass.so.cc | 2 +- instrumentation/split-switches-pass.so.cc | 2 +- qemu_mode/build_qemu_support.sh | 2 +- src/afl-analyze.c | 2 +- src/afl-as.c | 4 ++-- src/afl-cc.c | 2 +- src/afl-common.c | 2 +- src/afl-forkserver.c | 8 ++++---- src/afl-fuzz-bitmap.c | 2 +- src/afl-fuzz-cmplog.c | 2 +- src/afl-fuzz-extras.c | 2 +- src/afl-fuzz-init.c | 4 ++-- src/afl-fuzz-mutators.c | 2 +- src/afl-fuzz-one.c | 2 +- src/afl-fuzz-python.c | 2 +- src/afl-fuzz-queue.c | 2 +- src/afl-fuzz-redqueen.c | 2 +- src/afl-fuzz-run.c | 2 +- src/afl-fuzz-state.c | 2 +- src/afl-fuzz-stats.c | 2 +- src/afl-fuzz.c | 2 +- src/afl-gotcpu.c | 2 +- src/afl-ld-lto.c | 2 +- src/afl-performance.c | 2 +- src/afl-sharedmem.c | 2 +- src/afl-showmap.c | 2 +- src/afl-tmin.c | 2 +- test-instr.c | 2 +- unicorn_mode/build_unicorn_support.sh | 2 +- 70 files changed, 85 insertions(+), 86 deletions(-) (limited to 'qemu_mode') diff --git a/GNUmakefile b/GNUmakefile index 0a6f3950..ad2642f3 100644 --- a/GNUmakefile +++ b/GNUmakefile @@ -10,7 +10,7 @@ # you may not use this file except in compliance with the License. # You may obtain a copy of the License at: # -# http://www.apache.org/licenses/LICENSE-2.0 +# https://www.apache.org/licenses/LICENSE-2.0 # # For Heiko: diff --git a/GNUmakefile.gcc_plugin b/GNUmakefile.gcc_plugin index bce97b2f..ed2725d7 100644 --- a/GNUmakefile.gcc_plugin +++ b/GNUmakefile.gcc_plugin @@ -17,7 +17,7 @@ # you may not use this file except in compliance with the License. # You may obtain a copy of the License at: # -# http://www.apache.org/licenses/LICENSE-2.0 +# https://www.apache.org/licenses/LICENSE-2.0 # #TEST_MMAP=1 PREFIX ?= /usr/local diff --git a/GNUmakefile.llvm b/GNUmakefile.llvm index b802ef16..64e5beb2 100644 --- a/GNUmakefile.llvm +++ b/GNUmakefile.llvm @@ -12,7 +12,7 @@ # you may not use this file except in compliance with the License. # You may obtain a copy of the License at: # -# http://www.apache.org/licenses/LICENSE-2.0 +# https://www.apache.org/licenses/LICENSE-2.0 # # For Heiko: diff --git a/TODO.md b/TODO.md index 30676312..1d4270b4 100644 --- a/TODO.md +++ b/TODO.md @@ -2,7 +2,6 @@ ## TODO - - AFL_USE_TSAN to docs/env_variables.md after work over - screen update during input2stage - better autodetection of shifting runtime timeout values - Update afl->pending_not_fuzzed for MOpt diff --git a/afl-cmin.bash b/afl-cmin.bash index c77dfbc1..e25ddc74 100755 --- a/afl-cmin.bash +++ b/afl-cmin.bash @@ -11,7 +11,7 @@ # you may not use this file except in compliance with the License. # You may obtain a copy of the License at: # -# http://www.apache.org/licenses/LICENSE-2.0 +# https://www.apache.org/licenses/LICENSE-2.0 # # This tool tries to find the smallest subset of files in the input directory # that still trigger the full range of instrumentation data points seen in diff --git a/afl-plot b/afl-plot index 87b9caae..1ea1fc55 100755 --- a/afl-plot +++ b/afl-plot @@ -12,7 +12,7 @@ # you may not use this file except in compliance with the License. # You may obtain a copy of the License at: # -# http://www.apache.org/licenses/LICENSE-2.0 +# https://www.apache.org/licenses/LICENSE-2.0 # get_abs_path() { diff --git a/afl-whatsup b/afl-whatsup index 9c2564c6..10a52f83 100755 --- a/afl-whatsup +++ b/afl-whatsup @@ -12,7 +12,7 @@ # you may not use this file except in compliance with the License. # You may obtain a copy of the License at: # -# http://www.apache.org/licenses/LICENSE-2.0 +# https://www.apache.org/licenses/LICENSE-2.0 # # This tool summarizes the status of any locally-running synchronized # instances of afl-fuzz. diff --git a/docs/Changelog.md b/docs/Changelog.md index cfeb8cc1..7c77a6bf 100644 --- a/docs/Changelog.md +++ b/docs/Changelog.md @@ -2760,7 +2760,7 @@ sending a mail to . - Updated the documentation and added notes_for_asan.txt. Based on feedback from Hanno Boeck, Ben Laurie, and others. - - Moved the project to http://lcamtuf.coredump.cx/afl/. + - Moved the project to https://lcamtuf.coredump.cx/afl/. ### Version 0.46b: diff --git a/docs/INSTALL.md b/docs/INSTALL.md index 960de1af..cfa20dea 100644 --- a/docs/INSTALL.md +++ b/docs/INSTALL.md @@ -150,4 +150,4 @@ sysctl kern.sysv.shmseg=48 sysctl kern.sysv.shmall=98304 ``` -See [http://www.spy-hill.com/help/apple/SharedMemory.html](http://www.spy-hill.com/help/apple/SharedMemory.html) for documentation for these settings and how to make them permanent. \ No newline at end of file +See [https://www.spy-hill.com/help/apple/SharedMemory.html](https://www.spy-hill.com/help/apple/SharedMemory.html) for documentation for these settings and how to make them permanent. \ No newline at end of file diff --git a/docs/best_practices.md b/docs/best_practices.md index 0708d49d..5d07dd14 100644 --- a/docs/best_practices.md +++ b/docs/best_practices.md @@ -108,7 +108,7 @@ Four steps are required to do this and it also requires quite some knowledge of Follow this document on how to do this: [instrumentation/README.instrument_list.md](../instrumentation/README.instrument_list.md). If `PCGUARD` is used, then you need to follow this guide (needs llvm 12+!): - [http://clang.llvm.org/docs/SanitizerCoverage.html#partially-disabling-instrumentation](http://clang.llvm.org/docs/SanitizerCoverage.html#partially-disabling-instrumentation) + [https://clang.llvm.org/docs/SanitizerCoverage.html#partially-disabling-instrumentation](https://clang.llvm.org/docs/SanitizerCoverage.html#partially-disabling-instrumentation) Only exclude those functions from instrumentation that provide no value for coverage - that is if it does not process any fuzz data directly or indirectly (e.g. hash maps, thread management etc.). If however a function directly or indirectly handles fuzz data, then you should not put the function in a deny instrumentation list and rather live with the instability it comes with. diff --git a/docs/interpreting_output.md b/docs/interpreting_output.md index 327a0ac0..4bd705f2 100644 --- a/docs/interpreting_output.md +++ b/docs/interpreting_output.md @@ -56,7 +56,7 @@ Any existing output directory can be also used to resume aborted jobs; try: If you have gnuplot installed, you can also generate some pretty graphs for any active fuzzing task using afl-plot. For an example of how this looks like, -see [http://lcamtuf.coredump.cx/afl/plot/](http://lcamtuf.coredump.cx/afl/plot/). +see [https://lcamtuf.coredump.cx/afl/plot/](https://lcamtuf.coredump.cx/afl/plot/). You can also manually build and install afl-plot-ui, which is a helper utility for showing the graphs generated by afl-plot in a graphical window using GTK. diff --git a/docs/known_limitations.md b/docs/known_limitations.md index 2d8f84a5..a68c0a85 100644 --- a/docs/known_limitations.md +++ b/docs/known_limitations.md @@ -31,6 +31,6 @@ Here are some of the most important caveats for AFL: [https://www.fastly.com/blog/how-to-fuzz-server-american-fuzzy-lop](https://www.fastly.com/blog/how-to-fuzz-server-american-fuzzy-lop) - Occasionally, sentient machines rise against their creators. If this - happens to you, please consult [http://lcamtuf.coredump.cx/prep/](http://lcamtuf.coredump.cx/prep/). + happens to you, please consult [https://lcamtuf.coredump.cx/prep/](https://lcamtuf.coredump.cx/prep/). Beyond this, see [INSTALL.md](INSTALL.md) for platform-specific tips. diff --git a/docs/sister_projects.md b/docs/sister_projects.md index 5cb3a102..613bc778 100644 --- a/docs/sister_projects.md +++ b/docs/sister_projects.md @@ -15,7 +15,7 @@ instruction manual. Allows fuzz-testing of Python programs. Uses custom instrumentation and its own forkserver. -http://jwilk.net/software/python-afl +https://jwilk.net/software/python-afl ### Go-fuzz (Dmitry Vyukov) @@ -34,7 +34,7 @@ https://github.com/kmcallister/afl.rs Adds AFL-compatible instrumentation to OCaml programs. https://github.com/ocamllabs/opam-repo-dev/pull/23 -http://canopy.mirage.io/Posts/Fuzzing +https://canopy.mirage.io/Posts/Fuzzing ### AFL for GCJ Java and other GCC frontends (-) @@ -54,7 +54,7 @@ some programs to be fuzzed without the fork / execve overhead. (Similar functionality is now available as the "persistent" feature described in [the llvm_mode readme](../instrumentation/README.llvm.md)) -http://llvm.org/docs/LibFuzzer.html +https://llvm.org/docs/LibFuzzer.html ## TriforceAFL (Tim Newsham and Jesse Hertz) @@ -189,7 +189,7 @@ https://github.com/bshastry/afl-sancov Makes it easy to estimate memory usage limits when fuzzing with ASAN or MSAN. -http://jwilk.net/software/recidivm +https://jwilk.net/software/recidivm ### aflize (Jacek Wielemborek) @@ -274,7 +274,7 @@ https://goo.gl/j9EgFf A simple SQL shell designed specifically for fuzzing the underlying library. -http://www.sqlite.org/src/artifact/9e7e273da2030371 +https://www.sqlite.org/src/artifact/9e7e273da2030371 ### Support for Python mutation modules (Christian Holler) @@ -292,7 +292,7 @@ A similar guided approach as applied to fuzzing syscalls: https://github.com/google/syzkaller/wiki/Found-Bugs https://github.com/dvyukov/linux/commit/33787098ffaaa83b8a7ccf519913ac5fd6125931 -http://events.linuxfoundation.org/sites/events/files/slides/AFL%20filesystem%20fuzzing%2C%20Vault%202016_0.pdf +https://events.linuxfoundation.org/sites/events/files/slides/AFL%20filesystem%20fuzzing%2C%20Vault%202016_0.pdf ### Kernel Snapshot Fuzzing using Unicornafl (Security in Telecommunications) diff --git a/docs/technical_details.md b/docs/technical_details.md index b0ca493e..b9d271d9 100644 --- a/docs/technical_details.md +++ b/docs/technical_details.md @@ -161,8 +161,8 @@ features of the underlying data format, as shown in this image: Several practical examples of the results of this algorithm are discussed here: - http://lcamtuf.blogspot.com/2014/11/pulling-jpegs-out-of-thin-air.html - http://lcamtuf.blogspot.com/2014/11/afl-fuzz-nobody-expects-cdata-sections.html + https://lcamtuf.blogspot.com/2014/11/pulling-jpegs-out-of-thin-air.html + https://lcamtuf.blogspot.com/2014/11/afl-fuzz-nobody-expects-cdata-sections.html The synthetic corpus produced by this process is essentially a compact collection of "hmm, this does something new!" input files, and can be used to @@ -323,7 +323,7 @@ value of various fuzzing strategies and optimize their parameters so that they work equally well across a wide range of file types. The strategies used by afl-fuzz are generally format-agnostic and are discussed in more detail here: - http://lcamtuf.blogspot.com/2014/08/binary-fuzzing-strategies-what-works.html + https://lcamtuf.blogspot.com/2014/08/binary-fuzzing-strategies-what-works.html It is somewhat notable that especially early on, most of the work done by `afl-fuzz` is actually highly deterministic, and progresses to random stacked @@ -376,7 +376,7 @@ valid grammar for the tested parser. A discussion of how these features are implemented within afl-fuzz can be found here: - http://lcamtuf.blogspot.com/2015/01/afl-fuzz-making-up-grammar-with.html + https://lcamtuf.blogspot.com/2015/01/afl-fuzz-making-up-grammar-with.html In essence, when basic, typically easily-obtained syntax tokens are combined together in a purely random manner, the instrumentation and the evolutionary @@ -429,7 +429,7 @@ thrown away. A detailed discussion of the value of this approach can be found here: - http://lcamtuf.blogspot.com/2014/11/afl-fuzz-crash-exploration-mode.html + https://lcamtuf.blogspot.com/2014/11/afl-fuzz-crash-exploration-mode.html The method uses instrumentation feedback to explore the state of the crashing program to get past the ambiguous faulting condition and then isolate the @@ -447,7 +447,7 @@ goes through `execve()`, linking, and libc initialization only once, and is then cloned from a stopped process image by leveraging copy-on-write. The implementation is described in more detail here: - http://lcamtuf.blogspot.com/2014/10/fuzzing-binaries-without-execve.html + https://lcamtuf.blogspot.com/2014/10/fuzzing-binaries-without-execve.html The fork server is an integral aspect of the injected instrumentation and simply stops at the first instrumented function to await commands from diff --git a/frida_mode/Scripting.md b/frida_mode/Scripting.md index f6017fad..691b03d1 100644 --- a/frida_mode/Scripting.md +++ b/frida_mode/Scripting.md @@ -302,7 +302,7 @@ Consider the [following](test/js/test2.c) test code... Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 */ #include diff --git a/include/afl-as.h b/include/afl-as.h index 3c12c68f..2a2e8ad7 100644 --- a/include/afl-as.h +++ b/include/afl-as.h @@ -16,7 +16,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 This file houses the assembly-level instrumentation injected into fuzzed programs. The instrumentation stores XORed pairs of data: identifiers of the @@ -396,7 +396,7 @@ static const u8 *main_payload_32 = "\n"; /* The OpenBSD hack is due to lahf and sahf not being recognized by some - versions of binutils: http://marc.info/?l=openbsd-cvs&m=141636589924400 + versions of binutils: https://marc.info/?l=openbsd-cvs&m=141636589924400 The Apple code is a bit different when calling libc functions because they are doing relocations differently from everybody else. We also need diff --git a/include/afl-fuzz.h b/include/afl-fuzz.h index eaf55fb8..e73ea1a4 100644 --- a/include/afl-fuzz.h +++ b/include/afl-fuzz.h @@ -16,7 +16,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 This is the real deal: the program takes an instrumented binary and attempts a variety of basic fuzzing tricks, paying close attention to diff --git a/include/afl-prealloc.h b/include/afl-prealloc.h index fa6c9b70..87bbb1cc 100644 --- a/include/afl-prealloc.h +++ b/include/afl-prealloc.h @@ -16,7 +16,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 */ diff --git a/include/alloc-inl.h b/include/alloc-inl.h index c914da5f..0c540330 100644 --- a/include/alloc-inl.h +++ b/include/alloc-inl.h @@ -16,7 +16,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 This allocator is not designed to resist malicious attackers (the canaries are small and predictable), but provides a robust and portable way to detect diff --git a/include/cmplog.h b/include/cmplog.h index 878ed60c..1c15d2b8 100644 --- a/include/cmplog.h +++ b/include/cmplog.h @@ -18,7 +18,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 Shared code to handle the shared memory. This is used by the fuzzer as well the other components like afl-tmin, afl-showmap, etc... diff --git a/include/common.h b/include/common.h index 2ca44301..e3997aa4 100644 --- a/include/common.h +++ b/include/common.h @@ -16,7 +16,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 Gather some functions common to multiple executables diff --git a/include/config.h b/include/config.h index 4630da0c..3aee9b00 100644 --- a/include/config.h +++ b/include/config.h @@ -16,7 +16,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 */ diff --git a/include/debug.h b/include/debug.h index f8df5711..feb7f52d 100644 --- a/include/debug.h +++ b/include/debug.h @@ -16,7 +16,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 */ diff --git a/include/forkserver.h b/include/forkserver.h index c6f7de00..7af01cb2 100644 --- a/include/forkserver.h +++ b/include/forkserver.h @@ -18,7 +18,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 Shared code that implements a forkserver. This is used by the fuzzer as well the other components like afl-tmin. diff --git a/include/hash.h b/include/hash.h index 9319ab95..9bb34ff8 100644 --- a/include/hash.h +++ b/include/hash.h @@ -21,7 +21,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 */ diff --git a/include/list.h b/include/list.h index 7ec81cbe..d49e56da 100644 --- a/include/list.h +++ b/include/list.h @@ -16,7 +16,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 This allocator is not designed to resist malicious attackers (the canaries are small and predictable), but provides a robust and portable way to detect diff --git a/include/sharedmem.h b/include/sharedmem.h index fdc947f9..93080d0f 100644 --- a/include/sharedmem.h +++ b/include/sharedmem.h @@ -18,7 +18,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 Shared code to handle the shared memory. This is used by the fuzzer as well the other components like afl-tmin, afl-showmap, etc... diff --git a/include/snapshot-inl.h b/include/snapshot-inl.h index a18187ef..7234bbaa 100644 --- a/include/snapshot-inl.h +++ b/include/snapshot-inl.h @@ -18,7 +18,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 */ diff --git a/include/types.h b/include/types.h index 7b94fb83..e945f0f5 100644 --- a/include/types.h +++ b/include/types.h @@ -16,7 +16,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 */ diff --git a/instrumentation/README.llvm.md b/instrumentation/README.llvm.md index 5b1e60cc..dbb604f2 100644 --- a/instrumentation/README.llvm.md +++ b/instrumentation/README.llvm.md @@ -75,7 +75,7 @@ load modules (you'll see "Service unavailable" when loading afl-llvm-pass.so). To solve all your problems, you can grab pre-built binaries for your OS from: - http://llvm.org/releases/download.html + https://llvm.org/releases/download.html ...and then put the bin/ directory from the tarball at the beginning of your $PATH when compiling the feature and building packages later on. You don't need diff --git a/instrumentation/afl-compiler-rt.o.c b/instrumentation/afl-compiler-rt.o.c index 9acab4e7..b2802a29 100644 --- a/instrumentation/afl-compiler-rt.o.c +++ b/instrumentation/afl-compiler-rt.o.c @@ -9,7 +9,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 */ diff --git a/instrumentation/afl-gcc-pass.so.cc b/instrumentation/afl-gcc-pass.so.cc index 3b7eb878..df2b6f2a 100644 --- a/instrumentation/afl-gcc-pass.so.cc +++ b/instrumentation/afl-gcc-pass.so.cc @@ -30,7 +30,7 @@ GNU General Public License for more details. You should have received a copy of the GNU General Public License - along with this program. If not, see . + along with this program. If not, see . */ diff --git a/instrumentation/afl-llvm-dict2file.so.cc b/instrumentation/afl-llvm-dict2file.so.cc index 0a3e74b9..7c04c0c5 100644 --- a/instrumentation/afl-llvm-dict2file.so.cc +++ b/instrumentation/afl-llvm-dict2file.so.cc @@ -10,7 +10,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 This library is plugged into LLVM when invoking clang through afl-clang-lto. diff --git a/instrumentation/afl-llvm-lto-instrumentation.so.cc b/instrumentation/afl-llvm-lto-instrumentation.so.cc index c2f61d34..cd43b437 100644 --- a/instrumentation/afl-llvm-lto-instrumentation.so.cc +++ b/instrumentation/afl-llvm-lto-instrumentation.so.cc @@ -10,7 +10,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 This library is plugged into LLVM when invoking clang through afl-clang-lto. diff --git a/instrumentation/afl-llvm-lto-instrumentlist.so.cc b/instrumentation/afl-llvm-lto-instrumentlist.so.cc index ee2e5dd3..cf26f912 100644 --- a/instrumentation/afl-llvm-lto-instrumentlist.so.cc +++ b/instrumentation/afl-llvm-lto-instrumentlist.so.cc @@ -15,7 +15,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 This library is plugged into LLVM when invoking clang through afl-clang-fast. It tells the compiler to add code roughly equivalent to the bits discussed diff --git a/instrumentation/afl-llvm-pass.so.cc b/instrumentation/afl-llvm-pass.so.cc index 9b7e625e..21ce0cf9 100644 --- a/instrumentation/afl-llvm-pass.so.cc +++ b/instrumentation/afl-llvm-pass.so.cc @@ -18,7 +18,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 This library is plugged into LLVM when invoking clang through afl-clang-fast. It tells the compiler to add code roughly equivalent to the bits discussed diff --git a/instrumentation/afl-llvm-rt-lto.o.c b/instrumentation/afl-llvm-rt-lto.o.c index e53785ff..eb346157 100644 --- a/instrumentation/afl-llvm-rt-lto.o.c +++ b/instrumentation/afl-llvm-rt-lto.o.c @@ -6,7 +6,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 */ diff --git a/instrumentation/cmplog-instructions-pass.cc b/instrumentation/cmplog-instructions-pass.cc index 01a8a637..80af05f0 100644 --- a/instrumentation/cmplog-instructions-pass.cc +++ b/instrumentation/cmplog-instructions-pass.cc @@ -11,7 +11,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 */ diff --git a/instrumentation/cmplog-routines-pass.cc b/instrumentation/cmplog-routines-pass.cc index 1e2610f2..01b7a373 100644 --- a/instrumentation/cmplog-routines-pass.cc +++ b/instrumentation/cmplog-routines-pass.cc @@ -11,7 +11,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 */ diff --git a/instrumentation/cmplog-switches-pass.cc b/instrumentation/cmplog-switches-pass.cc index c42d44fe..aa719013 100644 --- a/instrumentation/cmplog-switches-pass.cc +++ b/instrumentation/cmplog-switches-pass.cc @@ -11,7 +11,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 */ diff --git a/instrumentation/compare-transform-pass.so.cc b/instrumentation/compare-transform-pass.so.cc index 288e8282..a1239040 100644 --- a/instrumentation/compare-transform-pass.so.cc +++ b/instrumentation/compare-transform-pass.so.cc @@ -5,7 +5,7 @@ * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * - * http://www.apache.org/licenses/LICENSE-2.0 + * https://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, diff --git a/instrumentation/split-compares-pass.so.cc b/instrumentation/split-compares-pass.so.cc index e63be98c..7c652ca2 100644 --- a/instrumentation/split-compares-pass.so.cc +++ b/instrumentation/split-compares-pass.so.cc @@ -6,7 +6,7 @@ * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * - * http://www.apache.org/licenses/LICENSE-2.0 + * https://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, diff --git a/instrumentation/split-switches-pass.so.cc b/instrumentation/split-switches-pass.so.cc index 82f198aa..1e32a31d 100644 --- a/instrumentation/split-switches-pass.so.cc +++ b/instrumentation/split-switches-pass.so.cc @@ -5,7 +5,7 @@ * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * - * http://www.apache.org/licenses/LICENSE-2.0 + * https://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, diff --git a/qemu_mode/build_qemu_support.sh b/qemu_mode/build_qemu_support.sh index 84f144be..71453a71 100755 --- a/qemu_mode/build_qemu_support.sh +++ b/qemu_mode/build_qemu_support.sh @@ -19,7 +19,7 @@ # you may not use this file except in compliance with the License. # You may obtain a copy of the License at: # -# http://www.apache.org/licenses/LICENSE-2.0 +# https://www.apache.org/licenses/LICENSE-2.0 # # This script downloads, patches, and builds a version of QEMU with # minor tweaks to allow non-instrumented binaries to be run under diff --git a/src/afl-analyze.c b/src/afl-analyze.c index 09b01541..60cb1434 100644 --- a/src/afl-analyze.c +++ b/src/afl-analyze.c @@ -15,7 +15,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 A nifty utility that grabs an input file and takes a stab at explaining its structure by observing how changes to it affect the execution path. diff --git a/src/afl-as.c b/src/afl-as.c index 9af272f2..b644b82a 100644 --- a/src/afl-as.c +++ b/src/afl-as.c @@ -15,7 +15,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 The sole purpose of this wrapper is to preprocess assembly files generated by GCC / clang and inject the instrumentation bits included from afl-as.h. It @@ -101,7 +101,7 @@ static void edit_params(int argc, char **argv) { /* On MacOS X, the Xcode cctool 'as' driver is a bit stale and does not work with the code generated by newer versions of clang that are hand-built - by the user. See the thread here: http://goo.gl/HBWDtn. + by the user. See the thread here: https://goo.gl/HBWDtn. To work around this, when using clang and running without AFL_AS specified, we will actually call 'clang -c' instead of 'as -q' to diff --git a/src/afl-cc.c b/src/afl-cc.c index 5f77b097..8ff241ba 100644 --- a/src/afl-cc.c +++ b/src/afl-cc.c @@ -11,7 +11,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 */ diff --git a/src/afl-common.c b/src/afl-common.c index 26a0d54b..ec3b2f3f 100644 --- a/src/afl-common.c +++ b/src/afl-common.c @@ -15,7 +15,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 Gather some functions common to multiple executables diff --git a/src/afl-forkserver.c b/src/afl-forkserver.c index 80b295e0..b1769bfb 100644 --- a/src/afl-forkserver.c +++ b/src/afl-forkserver.c @@ -19,7 +19,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 Shared code that implements a forkserver. This is used by the fuzzer as well the other components like afl-tmin. @@ -351,7 +351,7 @@ static void report_error_and_exit(int error) { /* Spins up fork server. The idea is explained here: - http://lcamtuf.blogspot.com/2014/10/fuzzing-binaries-without-execve.html + https://lcamtuf.blogspot.com/2014/10/fuzzing-binaries-without-execve.html In essence, the instrumentation allows us to skip execve(), and just keep cloning a stopped child. So, we just execute once, and then send commands @@ -917,7 +917,7 @@ void afl_fsrv_start(afl_forkserver_t *fsrv, char **argv, MSG_ULIMIT_USAGE " /path/to/fuzzed_app )\n\n" - " Tip: you can use http://jwilk.net/software/recidivm to " + " Tip: you can use https://jwilk.net/software/recidivm to " "quickly\n" " estimate the required amount of virtual memory for the " "binary.\n\n" @@ -1017,7 +1017,7 @@ void afl_fsrv_start(afl_forkserver_t *fsrv, char **argv, MSG_ULIMIT_USAGE " /path/to/fuzzed_app )\n\n" - " Tip: you can use http://jwilk.net/software/recidivm to quickly\n" + " Tip: you can use https://jwilk.net/software/recidivm to quickly\n" " estimate the required amount of virtual memory for the " "binary.\n\n" diff --git a/src/afl-fuzz-bitmap.c b/src/afl-fuzz-bitmap.c index 316067e4..f7b59f25 100644 --- a/src/afl-fuzz-bitmap.c +++ b/src/afl-fuzz-bitmap.c @@ -15,7 +15,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 This is the real deal: the program takes an instrumented binary and attempts a variety of basic fuzzing tricks, paying close attention to diff --git a/src/afl-fuzz-cmplog.c b/src/afl-fuzz-cmplog.c index c2e9c80f..6fc926f0 100644 --- a/src/afl-fuzz-cmplog.c +++ b/src/afl-fuzz-cmplog.c @@ -17,7 +17,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 Shared code to handle the shared memory. This is used by the fuzzer as well the other components like afl-tmin, afl-showmap, etc... diff --git a/src/afl-fuzz-extras.c b/src/afl-fuzz-extras.c index 584241d4..0f0fe331 100644 --- a/src/afl-fuzz-extras.c +++ b/src/afl-fuzz-extras.c @@ -15,7 +15,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 This is the real deal: the program takes an instrumented binary and attempts a variety of basic fuzzing tricks, paying close attention to diff --git a/src/afl-fuzz-init.c b/src/afl-fuzz-init.c index 1170715f..9262d718 100644 --- a/src/afl-fuzz-init.c +++ b/src/afl-fuzz-init.c @@ -15,7 +15,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 This is the real deal: the program takes an instrumented binary and attempts a variety of basic fuzzing tricks, paying close attention to @@ -974,7 +974,7 @@ void perform_dry_run(afl_state_t *afl) { MSG_ULIMIT_USAGE " /path/to/binary [...] . + See . This is xoshiro256++ 1.0, one of our all-purpose, rock-solid generators. It has excellent (sub-ns) speed, a state (256 bits) that is large diff --git a/src/afl-sharedmem.c b/src/afl-sharedmem.c index 22fe5a62..7fb8f821 100644 --- a/src/afl-sharedmem.c +++ b/src/afl-sharedmem.c @@ -17,7 +17,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 Shared code to handle the shared memory. This is used by the fuzzer as well the other components like afl-tmin, afl-showmap, etc... diff --git a/src/afl-showmap.c b/src/afl-showmap.c index 3826e385..23ec0df0 100644 --- a/src/afl-showmap.c +++ b/src/afl-showmap.c @@ -18,7 +18,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 A very simple tool that runs the targeted binary and displays the contents of the trace bitmap in a human-readable form. Useful in diff --git a/src/afl-tmin.c b/src/afl-tmin.c index ce2a0b8f..8ce4bdd5 100644 --- a/src/afl-tmin.c +++ b/src/afl-tmin.c @@ -18,7 +18,7 @@ you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 A simple test case minimizer that takes an input file and tries to remove as much data as possible while keeping the binary in a crashing state diff --git a/test-instr.c b/test-instr.c index 13d4eb93..eaae50ef 100644 --- a/test-instr.c +++ b/test-instr.c @@ -7,7 +7,7 @@ Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at: - http://www.apache.org/licenses/LICENSE-2.0 + https://www.apache.org/licenses/LICENSE-2.0 */ #include diff --git a/unicorn_mode/build_unicorn_support.sh b/unicorn_mode/build_unicorn_support.sh index 6c376f8d..f9c0be7f 100755 --- a/unicorn_mode/build_unicorn_support.sh +++ b/unicorn_mode/build_unicorn_support.sh @@ -20,7 +20,7 @@ # you may not use this file except in compliance with the License. # You may obtain a copy of the License at: # -# http://www.apache.org/licenses/LICENSE-2.0 +# https://www.apache.org/licenses/LICENSE-2.0 # # This script downloads, patches, and builds a version of Unicorn with # minor tweaks to allow Unicorn-emulated binaries to be run under -- cgit 1.4.1 From b5d7f6bd60e053a47996b1f1b9c70008bb106a32 Mon Sep 17 00:00:00 2001 From: vanhauser-thc Date: Sat, 6 Nov 2021 14:23:27 +0100 Subject: update qemafl --- qemu_mode/QEMUAFL_VERSION | 2 +- qemu_mode/qemuafl | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) (limited to 'qemu_mode') diff --git a/qemu_mode/QEMUAFL_VERSION b/qemu_mode/QEMUAFL_VERSION index 40bae8f5..0ffae35c 100644 --- a/qemu_mode/QEMUAFL_VERSION +++ b/qemu_mode/QEMUAFL_VERSION @@ -1 +1 @@ -4eb8c66a6077157e96f8660c0e64a69f001dc06f +8809a2b2ebf089d3427dd8f6a0044bcc2e13b389 diff --git a/qemu_mode/qemuafl b/qemu_mode/qemuafl index 71ed0d20..8809a2b2 160000 --- a/qemu_mode/qemuafl +++ b/qemu_mode/qemuafl @@ -1 +1 @@ -Subproject commit 71ed0d206fd3d877420dceb4993a1011a4637ae6 +Subproject commit 8809a2b2ebf089d3427dd8f6a0044bcc2e13b389 -- cgit 1.4.1 From 3483715789beee1bacca26a65ab215b3d51e8b34 Mon Sep 17 00:00:00 2001 From: vanhauser-thc Date: Sun, 7 Nov 2021 14:10:02 +0100 Subject: env --- include/envs.h | 1 + qemu_mode/qemuafl | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) (limited to 'qemu_mode') diff --git a/include/envs.h b/include/envs.h index 25d05539..fd459f14 100644 --- a/include/envs.h +++ b/include/envs.h @@ -54,6 +54,7 @@ static char *afl_environment_variables[] = { "AFL_FAST_CAL", "AFL_FORCE_UI", "AFL_FRIDA_DEBUG_MAPS", + "AFL_FRIDA_DRIVER_NO_HOOK", "AFL_FRIDA_EXCLUDE_RANGES", "AFL_FRIDA_INST_COVERAGE_FILE", "AFL_FRIDA_INST_DEBUG_FILE", diff --git a/qemu_mode/qemuafl b/qemu_mode/qemuafl index 8809a2b2..71ed0d20 160000 --- a/qemu_mode/qemuafl +++ b/qemu_mode/qemuafl @@ -1 +1 @@ -Subproject commit 8809a2b2ebf089d3427dd8f6a0044bcc2e13b389 +Subproject commit 71ed0d206fd3d877420dceb4993a1011a4637ae6 -- cgit 1.4.1 From 89eefe044fd99b3ebebad8afd6b339482f4879ec Mon Sep 17 00:00:00 2001 From: vanhauser-thc Date: Tue, 9 Nov 2021 11:14:25 +0100 Subject: update qemuafl --- qemu_mode/QEMUAFL_VERSION | 2 +- qemu_mode/qemuafl | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) (limited to 'qemu_mode') diff --git a/qemu_mode/QEMUAFL_VERSION b/qemu_mode/QEMUAFL_VERSION index 0ffae35c..5d6b5276 100644 --- a/qemu_mode/QEMUAFL_VERSION +++ b/qemu_mode/QEMUAFL_VERSION @@ -1 +1 @@ -8809a2b2ebf089d3427dd8f6a0044bcc2e13b389 +eb765dd8a606c12c7d43bb2748461c7f13ab0367 diff --git a/qemu_mode/qemuafl b/qemu_mode/qemuafl index 71ed0d20..eb765dd8 160000 --- a/qemu_mode/qemuafl +++ b/qemu_mode/qemuafl @@ -1 +1 @@ -Subproject commit 71ed0d206fd3d877420dceb4993a1011a4637ae6 +Subproject commit eb765dd8a606c12c7d43bb2748461c7f13ab0367 -- cgit 1.4.1 From 533e979010ca338df6fc415d87668f8187752915 Mon Sep 17 00:00:00 2001 From: vanhauser-thc Date: Wed, 10 Nov 2021 12:49:57 +0100 Subject: update qemuafl, update changelog --- docs/Changelog.md | 17 +++++++++++------ qemu_mode/QEMUAFL_VERSION | 2 +- qemu_mode/qemuafl | 2 +- 3 files changed, 13 insertions(+), 8 deletions(-) (limited to 'qemu_mode') diff --git a/docs/Changelog.md b/docs/Changelog.md index 2c72b5f2..6a9c895c 100644 --- a/docs/Changelog.md +++ b/docs/Changelog.md @@ -9,25 +9,31 @@ Want to stay in the loop on major new features? Join our mailing list by sending a mail to . ### Version ++3.15a (dev) + - documentation restructuring, made possible by Google Season of Docs :) - afl-fuzz: + - cmplog binaries will need to be recompiled for this version + (it is better!) + - fix a regression introduced in 3.10 that resulted in less + coverage being detected. thanks to Collin May for reporting! - added AFL_IGNORE_PROBLEMS plus checks to identify and abort on incorrect LTO usage setups and enhanced the READMEs for better information on how to deal with instrumenting libraries - - fix a regression introduced in 3.10 that resulted in less - coverage being detected. thanks to Collin May for reporting! - fix -n dumb mode (nobody should use this) - fix stability issue with LTO and cmplog - better banner - more effective cmplog mode - more often update the UI when in input2stage mode - - frida_mode: David Carlier added Android support :) + - frida_mode: + - better performance, bug fixes + - David Carlier added Android support :) - afl-showmap, afl-tmin and afl-analyze: - - honor persistent mode for more speed. thanks to dloffre-snl for - reporting! + - honor persistent mode for more speed. thanks to dloffre-snl + for reporting! - fix bug where targets are not killed on timeouts - Prevent accidently killing non-afl/fuzz services when aborting afl-showmap and other tools. - afl-cc: + - new cmplog mode (incompatible with older afl++ versions) - support llvm IR select instrumentation for default PCGUARD and LTO - fix for shared linking on MacOS - added AFL_USE_TSAN thread sanitizer support @@ -45,7 +51,6 @@ sending a mail to . - added uninstall target to makefile (todo: update new readme!) - removed indirections in rust callbacks for unicornafl - ### Version ++3.14c (release) - afl-fuzz: - fix -F when a '/' was part of the parameter diff --git a/qemu_mode/QEMUAFL_VERSION b/qemu_mode/QEMUAFL_VERSION index 5d6b5276..680c04d6 100644 --- a/qemu_mode/QEMUAFL_VERSION +++ b/qemu_mode/QEMUAFL_VERSION @@ -1 +1 @@ -eb765dd8a606c12c7d43bb2748461c7f13ab0367 +002e473939 diff --git a/qemu_mode/qemuafl b/qemu_mode/qemuafl index eb765dd8..002e4739 160000 --- a/qemu_mode/qemuafl +++ b/qemu_mode/qemuafl @@ -1 +1 @@ -Subproject commit eb765dd8a606c12c7d43bb2748461c7f13ab0367 +Subproject commit 002e473939a350854d56f67ce7b2e2d9706b8bca -- cgit 1.4.1 From 492dbe9fb294dec27e5c2bc7297b36526bb8e61f Mon Sep 17 00:00:00 2001 From: llzmb <46303940+llzmb@users.noreply.github.com> Date: Sun, 21 Nov 2021 18:00:01 +0100 Subject: Clean up docs folder --- README.md | 5 +- docs/FAQ.md | 5 +- docs/best_practices.md | 18 +++-- docs/parallel_fuzzing.md | 182 +++++++++++++++++++++++------------------------ qemu_mode/README.md | 5 +- 5 files changed, 109 insertions(+), 106 deletions(-) (limited to 'qemu_mode') diff --git a/README.md b/README.md index b2714787..fcb6b3c9 100644 --- a/README.md +++ b/README.md @@ -132,9 +132,6 @@ The following branches exist: * [dev](https://github.com/AFLplusplus/AFLplusplus/tree/dev): development state of AFL++ - bleeding edge and you might catch a checkout which does not compile or has a bug. *We only accept PRs in dev!!* * (any other): experimental branches to work on specific features or testing new functionality or changes. -For releases, please see the [Releases tab](https://github.com/AFLplusplus/AFLplusplus/releases). -Also take a look at the list of [important changes in AFL++](docs/important_changes.md). - ## Help wanted We have several [ideas](docs/ideas.md) we would like to see in AFL++ to make it @@ -233,4 +230,4 @@ presented at WOOT'20: } ``` - + \ No newline at end of file diff --git a/docs/FAQ.md b/docs/FAQ.md index 68ca3bad..34ed4cf5 100644 --- a/docs/FAQ.md +++ b/docs/FAQ.md @@ -83,7 +83,8 @@ If you find an interesting or important question missing, submit it via However, if there is only the binary program and no source code available, then the standard non-instrumented mode is not effective. - To learn how these binaries can be fuzzed, read [binaryonly_fuzzing.md](binaryonly_fuzzing.md). + To learn how these binaries can be fuzzed, read + [fuzzing_binary-only_targets.md](fuzzing_binary-only_targets.md).

@@ -143,7 +144,7 @@ If you find an interesting or important question missing, submit it via Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /prg/tmp/llvm-project/build/bin - clang-13: note: diagnostic msg: + clang-13: note: diagnostic msg: ******************** ``` diff --git a/docs/best_practices.md b/docs/best_practices.md index 7016f08d..5f2d45ed 100644 --- a/docs/best_practices.md +++ b/docs/best_practices.md @@ -4,20 +4,26 @@ ### Targets - * [Fuzzing a binary-only target](#fuzzing-a-binary-only-target) - * [Fuzzing a GUI program](#fuzzing-a-gui-program) - * [Fuzzing a network service](#fuzzing-a-network-service) +* [Fuzzing a target with source code available](#fuzzing-a-target-with-source-code-available) +* [Fuzzing a binary-only target](#fuzzing-a-binary-only-target) +* [Fuzzing a GUI program](#fuzzing-a-gui-program) +* [Fuzzing a network service](#fuzzing-a-network-service) ### Improvements - * [Improving speed](#improving-speed) - * [Improving stability](#improving-stability) +* [Improving speed](#improving-speed) +* [Improving stability](#improving-stability) ## Targets +### Fuzzing a target with source code available + +To learn how to fuzz a target if source code is available, see [fuzzing_in_depth.md](fuzzing_in_depth.md). + ### Fuzzing a binary-only target -For a comprehensive guide, see [binaryonly_fuzzing.md](binaryonly_fuzzing.md). +For a comprehensive guide, see +[fuzzing_binary-only_targets.md](fuzzing_binary-only_targets.md). ### Fuzzing a GUI program diff --git a/docs/parallel_fuzzing.md b/docs/parallel_fuzzing.md index d24f2837..130cb3ce 100644 --- a/docs/parallel_fuzzing.md +++ b/docs/parallel_fuzzing.md @@ -1,28 +1,28 @@ # Tips for parallel fuzzing -This document talks about synchronizing afl-fuzz jobs on a single machine -or across a fleet of systems. See README.md for the general instruction manual. +This document talks about synchronizing afl-fuzz jobs on a single machine or +across a fleet of systems. See README.md for the general instruction manual. Note that this document is rather outdated. please refer to the main document -section on multiple core usage [fuzzing_expert.md#Using multiple cores](fuzzing_expert.md#b-using-multiple-cores) +section on multiple core usage +[fuzzing_in_depth.md:b) Using multiple cores](fuzzing_in_depth.md#b-using-multiple-cores) for up to date strategies! ## 1) Introduction -Every copy of afl-fuzz will take up one CPU core. This means that on an -n-core system, you can almost always run around n concurrent fuzzing jobs with +Every copy of afl-fuzz will take up one CPU core. This means that on an n-core +system, you can almost always run around n concurrent fuzzing jobs with virtually no performance hit (you can use the afl-gotcpu tool to make sure). -In fact, if you rely on just a single job on a multi-core system, you will -be underutilizing the hardware. So, parallelization is always the right way to -go. +In fact, if you rely on just a single job on a multi-core system, you will be +underutilizing the hardware. So, parallelization is always the right way to go. When targeting multiple unrelated binaries or using the tool in "non-instrumented" (-n) mode, it is perfectly fine to just start up several -fully separate instances of afl-fuzz. The picture gets more complicated when -you want to have multiple fuzzers hammering a common target: if a hard-to-hit -but interesting test case is synthesized by one fuzzer, the remaining instances -will not be able to use that input to guide their work. +fully separate instances of afl-fuzz. The picture gets more complicated when you +want to have multiple fuzzers hammering a common target: if a hard-to-hit but +interesting test case is synthesized by one fuzzer, the remaining instances will +not be able to use that input to guide their work. To help with this problem, afl-fuzz offers a simple way to synchronize test cases on the fly. @@ -30,15 +30,15 @@ cases on the fly. It is a good idea to use different power schedules if you run several instances in parallel (`-p` option). -Alternatively running other AFL spinoffs in parallel can be of value, -e.g. Angora (https://github.com/AngoraFuzzer/Angora/) +Alternatively running other AFL spinoffs in parallel can be of value, e.g. +Angora (https://github.com/AngoraFuzzer/Angora/) ## 2) Single-system parallelization -If you wish to parallelize a single job across multiple cores on a local -system, simply create a new, empty output directory ("sync dir") that will be -shared by all the instances of afl-fuzz; and then come up with a naming scheme -for every instance - say, "fuzzer01", "fuzzer02", etc. +If you wish to parallelize a single job across multiple cores on a local system, +simply create a new, empty output directory ("sync dir") that will be shared by +all the instances of afl-fuzz; and then come up with a naming scheme for every +instance - say, "fuzzer01", "fuzzer02", etc. Run the first one ("main node", -M) like this: @@ -57,18 +57,18 @@ Each fuzzer will keep its state in a separate subdirectory, like so: /path/to/sync_dir/fuzzer01/ -Each instance will also periodically rescan the top-level sync directory -for any test cases found by other fuzzers - and will incorporate them into -its own fuzzing when they are deemed interesting enough. -For performance reasons only -M main node syncs the queue with everyone, the --S secondary nodes will only sync from the main node. +Each instance will also periodically rescan the top-level sync directory for any +test cases found by other fuzzers - and will incorporate them into its own +fuzzing when they are deemed interesting enough. For performance reasons only -M +main node syncs the queue with everyone, the -S secondary nodes will only sync +from the main node. -The difference between the -M and -S modes is that the main instance will -still perform deterministic checks; while the secondary instances will -proceed straight to random tweaks. +The difference between the -M and -S modes is that the main instance will still +perform deterministic checks; while the secondary instances will proceed +straight to random tweaks. -Note that you must always have one -M main instance! -Running multiple -M instances is wasteful! +Note that you must always have one -M main instance! Running multiple -M +instances is wasteful! You can also monitor the progress of your jobs from the command line with the provided afl-whatsup tool. When the instances are no longer finding new paths, @@ -90,18 +90,18 @@ file name. ## 3) Multiple -M mains -There is support for parallelizing the deterministic checks. -This is only needed where +There is support for parallelizing the deterministic checks. This is only needed +where 1. many new paths are found fast over a long time and it looks unlikely that main node will ever catch up, and 2. deterministic fuzzing is actively helping path discovery (you can see this in the main node for the first for lines in the "fuzzing strategy yields" - section. If the ration `found/attemps` is high, then it is effective. It + section. If the ration `found/attempts` is high, then it is effective. It most commonly isn't.) -Only if both are true it is beneficial to have more than one main. -You can leverage this by creating -M instances like so: +Only if both are true it is beneficial to have more than one main. You can +leverage this by creating -M instances like so: ``` ./afl-fuzz -i testcase_dir -o sync_dir -M mainA:1/3 [...] @@ -115,27 +115,26 @@ distribute the deterministic fuzzing across. Note that if you boot up fewer fuzzers than indicated by the second number passed to -M, you may end up with poor coverage. -## 4) Syncing with non-AFL fuzzers or independant instances +## 4) Syncing with non-AFL fuzzers or independent instances -A -M main node can be told with the `-F other_fuzzer_queue_directory` option -to sync results from other fuzzers, e.g. libfuzzer or honggfuzz. +A -M main node can be told with the `-F other_fuzzer_queue_directory` option to +sync results from other fuzzers, e.g. libfuzzer or honggfuzz. -Only the specified directory will by synced into afl, not subdirectories. -The specified directory does not need to exist yet at the start of afl. +Only the specified directory will by synced into afl, not subdirectories. The +specified directory does not need to exist yet at the start of afl. The `-F` option can be passed to the main node several times. ## 5) Multi-system parallelization -The basic operating principle for multi-system parallelization is similar to -the mechanism explained in section 2. The key difference is that you need to -write a simple script that performs two actions: +The basic operating principle for multi-system parallelization is similar to the +mechanism explained in section 2. The key difference is that you need to write a +simple script that performs two actions: - - Uses SSH with authorized_keys to connect to every machine and retrieve - a tar archive of the /path/to/sync_dir/ directory local to - the machine. - It is best to use a naming scheme that includes host name and it's being - a main node (e.g. main1, main2) in the fuzzer ID, so that you can do + - Uses SSH with authorized_keys to connect to every machine and retrieve a tar + archive of the /path/to/sync_dir/ directory local to the + machine. It is best to use a naming scheme that includes host name and it's + being a main node (e.g. main1, main2) in the fuzzer ID, so that you can do something like: ```sh @@ -163,70 +162,70 @@ There are other (older) more featured, experimental tools: However these do not support syncing just main nodes (yet). -When developing custom test case sync code, there are several optimizations -to keep in mind: +When developing custom test case sync code, there are several optimizations to +keep in mind: - - The synchronization does not have to happen very often; running the - task every 60 minutes or even less often at later fuzzing stages is - fine + - The synchronization does not have to happen very often; running the task + every 60 minutes or even less often at later fuzzing stages is fine - - There is no need to synchronize crashes/ or hangs/; you only need to - copy over queue/* (and ideally, also fuzzer_stats). + - There is no need to synchronize crashes/ or hangs/; you only need to copy + over queue/* (and ideally, also fuzzer_stats). - - It is not necessary (and not advisable!) to overwrite existing files; - the -k option in tar is a good way to avoid that. + - It is not necessary (and not advisable!) to overwrite existing files; the -k + option in tar is a good way to avoid that. - There is no need to fetch directories for fuzzers that are not running locally on a particular machine, and were simply copied over onto that system during earlier runs. - - For large fleets, you will want to consolidate tarballs for each host, - as this will let you use n SSH connections for sync, rather than n*(n-1). + - For large fleets, you will want to consolidate tarballs for each host, as + this will let you use n SSH connections for sync, rather than n*(n-1). You may also want to implement staged synchronization. For example, you - could have 10 groups of systems, with group 1 pushing test cases only - to group 2; group 2 pushing them only to group 3; and so on, with group + could have 10 groups of systems, with group 1 pushing test cases only to + group 2; group 2 pushing them only to group 3; and so on, with group eventually 10 feeding back to group 1. - This arrangement would allow test interesting cases to propagate across - the fleet without having to copy every fuzzer queue to every single host. + This arrangement would allow test interesting cases to propagate across the + fleet without having to copy every fuzzer queue to every single host. - You do not want a "main" instance of afl-fuzz on every system; you should run them all with -S, and just designate a single process somewhere within the fleet to run with -M. - - Syncing is only necessary for the main nodes on a system. It is possible - to run main-less with only secondaries. However then you need to find out - which secondary took over the temporary role to be the main node. Look for - the `is_main_node` file in the fuzzer directories, eg. `sync-dir/hostname-*/is_main_node` + - Syncing is only necessary for the main nodes on a system. It is possible to + run main-less with only secondaries. However then you need to find out which + secondary took over the temporary role to be the main node. Look for the + `is_main_node` file in the fuzzer directories, eg. + `sync-dir/hostname-*/is_main_node` It is *not* advisable to skip the synchronization script and run the fuzzers -directly on a network filesystem; unexpected latency and unkillable processes -in I/O wait state can mess things up. +directly on a network filesystem; unexpected latency and unkillable processes in +I/O wait state can mess things up. ## 6) Remote monitoring and data collection -You can use screen, nohup, tmux, or something equivalent to run remote -instances of afl-fuzz. If you redirect the program's output to a file, it will +You can use screen, nohup, tmux, or something equivalent to run remote instances +of afl-fuzz. If you redirect the program's output to a file, it will automatically switch from a fancy UI to more limited status reports. There is also basic machine-readable information which is always written to the fuzzer_stats file in the output directory. Locally, that information can be interpreted with afl-whatsup. -In principle, you can use the status screen of the main (-M) instance to -monitor the overall fuzzing progress and decide when to stop. In this -mode, the most important signal is just that no new paths are being found -for a longer while. If you do not have a main instance, just pick any -single secondary instance to watch and go by that. +In principle, you can use the status screen of the main (-M) instance to monitor +the overall fuzzing progress and decide when to stop. In this mode, the most +important signal is just that no new paths are being found for a longer while. +If you do not have a main instance, just pick any single secondary instance to +watch and go by that. -You can also rely on that instance's output directory to collect the -synthesized corpus that covers all the noteworthy paths discovered anywhere -within the fleet. Secondary (-S) instances do not require any special -monitoring, other than just making sure that they are up. +You can also rely on that instance's output directory to collect the synthesized +corpus that covers all the noteworthy paths discovered anywhere within the +fleet. Secondary (-S) instances do not require any special monitoring, other +than just making sure that they are up. -Keep in mind that crashing inputs are *not* automatically propagated to the -main instance, so you may still want to monitor for crashes fleet-wide -from within your synchronization or health checking scripts (see afl-whatsup). +Keep in mind that crashing inputs are *not* automatically propagated to the main +instance, so you may still want to monitor for crashes fleet-wide from within +your synchronization or health checking scripts (see afl-whatsup). ## 7) Asymmetric setups @@ -238,21 +237,20 @@ It is perhaps worth noting that all of the following is permitted: out_dir//queue/* and writing their own finds to sequentially numbered id:nnnnnn files in out_dir//queue/*. - - Running some of the synchronized fuzzers with different (but related) - target binaries. For example, simultaneously stress-testing several - different JPEG parsers (say, IJG jpeg and libjpeg-turbo) while sharing - the discovered test cases can have synergistic effects and improve the - overall coverage. + - Running some of the synchronized fuzzers with different (but related) target + binaries. For example, simultaneously stress-testing several different JPEG + parsers (say, IJG jpeg and libjpeg-turbo) while sharing the discovered test + cases can have synergistic effects and improve the overall coverage. (In this case, running one -M instance per target is necessary.) - - Having some of the fuzzers invoke the binary in different ways. - For example, 'djpeg' supports several DCT modes, configurable with - a command-line flag, while 'dwebp' supports incremental and one-shot - decoding. In some scenarios, going after multiple distinct modes and then - pooling test cases will improve coverage. + - Having some of the fuzzers invoke the binary in different ways. For example, + 'djpeg' supports several DCT modes, configurable with a command-line flag, + while 'dwebp' supports incremental and one-shot decoding. In some scenarios, + going after multiple distinct modes and then pooling test cases will improve + coverage. - Much less convincingly, running the synchronized fuzzers with different starting test cases (e.g., progressive and standard JPEG) or dictionaries. The synchronization mechanism ensures that the test sets will get fairly - homogeneous over time, but it introduces some initial variability. + homogeneous over time, but it introduces some initial variability. \ No newline at end of file diff --git a/qemu_mode/README.md b/qemu_mode/README.md index d28479d9..c62309a2 100644 --- a/qemu_mode/README.md +++ b/qemu_mode/README.md @@ -217,5 +217,6 @@ them at run time, can be a faster alternative. That said, static rewriting is fraught with peril, because it depends on being able to properly and fully model program control flow without actually executing each and every code path. -Checkout the "Fuzzing binary-only targets" section in our main README.md and -the docs/binaryonly_fuzzing.md document for more information and hints. +Check out +[docs/fuzzing_binary-only_targets.md](../docs/fuzzing_binary-only_targets.md) +for more information and hints. -- cgit 1.4.1 From c31f4646cbd00f591dad3258c08ff8e56aa94420 Mon Sep 17 00:00:00 2001 From: llzmb <46303940+llzmb@users.noreply.github.com> Date: Sun, 21 Nov 2021 21:11:52 +0100 Subject: Clean up docs folder --- README.md | 29 +- docs/afl-fuzz_approach.md | 540 ++++++++++++++++++++++++++- docs/custom_mutators.md | 6 +- docs/env_variables.md | 9 +- docs/features.md | 2 +- docs/fuzzing_in_depth.md | 572 +++++++++++++++-------------- docs/important_changes.md | 4 +- docs/interpreting_output.md | 71 ---- docs/status_screen.md | 444 ---------------------- docs/third_party_tools.md | 6 +- qemu_mode/libqasan/README.md | 2 +- unicorn_mode/samples/persistent/COMPILE.md | 12 +- utils/aflpp_driver/README.md | 12 +- 13 files changed, 864 insertions(+), 845 deletions(-) delete mode 100644 docs/interpreting_output.md delete mode 100644 docs/status_screen.md (limited to 'qemu_mode') diff --git a/README.md b/README.md index fcb6b3c9..e0cb4558 100644 --- a/README.md +++ b/README.md @@ -80,8 +80,10 @@ Step-by-step quick start: 1. Compile the program or library to be fuzzed using `afl-cc`. A common way to do this would be: - CC=/path/to/afl-cc CXX=/path/to/afl-c++ ./configure --disable-shared - make clean all + ``` + CC=/path/to/afl-cc CXX=/path/to/afl-c++ ./configure --disable-shared + make clean all + ``` 2. Get a small but valid input file that makes sense to the program. When fuzzing verbose syntax (SQL, HTTP, etc), create a dictionary as described in @@ -89,10 +91,10 @@ Step-by-step quick start: 3. If the program reads from stdin, run `afl-fuzz` like so: -``` + ``` ./afl-fuzz -i seeds_dir -o output_dir -- \ - /path/to/tested/program [...program's cmdline...] -``` + /path/to/tested/program [...program's cmdline...] + ``` To add a dictionary, add `-x /path/to/dictionary.txt` to afl-fuzz. @@ -100,13 +102,20 @@ Step-by-step quick start: command line; AFL will put an auto-generated file name in there for you. 4. Investigate anything shown in red in the fuzzer UI by promptly consulting - [docs/status_screen.md](docs/status_screen.md). + [docs/afl-fuzz_approach.md#understanding-the-status-screen](docs/afl-fuzz_approach.md#understanding-the-status-screen). + +5. Interpret the output, see + [docs/afl-fuzz_approach.md#interpreting-output](docs/afl-fuzz_approach.md#interpreting-output). -5. You will find found crashes and hangs in the subdirectories `crashes/` and +6. You will find found crashes and hangs in the subdirectories `crashes/` and `hangs/` in the `-o output_dir` directory. You can replay the crashes by - feeding them to the target, e.g.: `cat output_dir/crashes/id:000000,* | - /path/to/tested/program [...program's cmdline...]` You can generate cores or - use gdb directly to follow up the crashes. + feeding them to the target, e.g.: + + ``` + cat output_dir/crashes/id:000000,* | /path/to/tested/program [...program's cmdline...] + ``` + + You can generate cores or use gdb directly to follow up the crashes. ## Contact diff --git a/docs/afl-fuzz_approach.md b/docs/afl-fuzz_approach.md index 5652816b..57a275d9 100644 --- a/docs/afl-fuzz_approach.md +++ b/docs/afl-fuzz_approach.md @@ -1,37 +1,539 @@ # The afl-fuzz approach -American Fuzzy Lop is a brute-force fuzzer coupled with an exceedingly simple -but rock-solid instrumentation-guided genetic algorithm. It uses a modified -form of edge coverage to effortlessly pick up subtle, local-scale changes to -program control flow. +AFL++ is a brute-force fuzzer coupled with an exceedingly simple but rock-solid +instrumentation-guided genetic algorithm. It uses a modified form of edge +coverage to effortlessly pick up subtle, local-scale changes to program control +flow. Simplifying a bit, the overall algorithm can be summed up as: - 1) Load user-supplied initial test cases into the queue, +1) Load user-supplied initial test cases into the queue. - 2) Take the next input file from the queue, +2) Take the next input file from the queue. - 3) Attempt to trim the test case to the smallest size that doesn't alter - the measured behavior of the program, +3) Attempt to trim the test case to the smallest size that doesn't alter the + measured behavior of the program. - 4) Repeatedly mutate the file using a balanced and well-researched variety - of traditional fuzzing strategies, +4) Repeatedly mutate the file using a balanced and well-researched variety of + traditional fuzzing strategies. - 5) If any of the generated mutations resulted in a new state transition - recorded by the instrumentation, add mutated output as a new entry in the - queue. +5) If any of the generated mutations resulted in a new state transition recorded + by the instrumentation, add mutated output as a new entry in the queue. - 6) Go to 2. +6) Go to 2. The discovered test cases are also periodically culled to eliminate ones that have been obsoleted by newer, higher-coverage finds; and undergo several other instrumentation-driven effort minimization steps. As a side result of the fuzzing process, the tool creates a small, -self-contained corpus of interesting test cases. These are extremely useful -for seeding other, labor- or resource-intensive testing regimes - for example, -for stress-testing browsers, office applications, graphics suites, or -closed-source tools. +self-contained corpus of interesting test cases. These are extremely useful for +seeding other, labor- or resource-intensive testing regimes - for example, for +stress-testing browsers, office applications, graphics suites, or closed-source +tools. The fuzzer is thoroughly tested to deliver out-of-the-box performance far -superior to blind fuzzing or coverage-only tools. \ No newline at end of file +superior to blind fuzzing or coverage-only tools. + +## Understanding the status screen + +This document provides an overview of the status screen - plus tips for +troubleshooting any warnings and red text shown in the UI. See +[README.md](../README.md) for the general instruction manual. + +### A note about colors + +The status screen and error messages use colors to keep things readable and +attract your attention to the most important details. For example, red almost +always means "consult this doc" :-) + +Unfortunately, the UI will render correctly only if your terminal is using +traditional un*x palette (white text on black background) or something close to +that. + +If you are using inverse video, you may want to change your settings, say: + +- For GNOME Terminal, go to `Edit > Profile` preferences, select the "colors" + tab, and from the list of built-in schemes, choose "white on black". +- For the MacOS X Terminal app, open a new window using the "Pro" scheme via the + `Shell > New Window` menu (or make "Pro" your default). + +Alternatively, if you really like your current colors, you can edit config.h to +comment out USE_COLORS, then do `make clean all`. + +I'm not aware of any other simple way to make this work without causing other +side effects - sorry about that. + +With that out of the way, let's talk about what's actually on the screen... + +### The status bar + +``` +american fuzzy lop ++3.01a (default) [fast] {0} +``` + +The top line shows you which mode afl-fuzz is running in (normal: "american +fuzzy lop", crash exploration mode: "peruvian rabbit mode") and the version of +AFL++. Next to the version is the banner, which, if not set with -T by hand, +will either show the binary name being fuzzed, or the -M/-S main/secondary name +for parallel fuzzing. Second to last is the power schedule mode being run +(default: fast). Finally, the last item is the CPU id. + +### Process timing + +``` + +----------------------------------------------------+ + | run time : 0 days, 8 hrs, 32 min, 43 sec | + | last new path : 0 days, 0 hrs, 6 min, 40 sec | + | last uniq crash : none seen yet | + | last uniq hang : 0 days, 1 hrs, 24 min, 32 sec | + +----------------------------------------------------+ +``` + +This section is fairly self-explanatory: it tells you how long the fuzzer has +been running and how much time has elapsed since its most recent finds. This is +broken down into "paths" (a shorthand for test cases that trigger new execution +patterns), crashes, and hangs. + +When it comes to timing: there is no hard rule, but most fuzzing jobs should be +expected to run for days or weeks; in fact, for a moderately complex project, +the first pass will probably take a day or so. Every now and then, some jobs +will be allowed to run for months. + +There's one important thing to watch out for: if the tool is not finding new +paths within several minutes of starting, you're probably not invoking the +target binary correctly and it never gets to parse the input files we're +throwing at it; another possible explanations are that the default memory limit +(`-m`) is too restrictive, and the program exits after failing to allocate a +buffer very early on; or that the input files are patently invalid and always +fail a basic header check. + +If there are no new paths showing up for a while, you will eventually see a big +red warning in this section, too :-) + +### Overall results + +``` + +-----------------------+ + | cycles done : 0 | + | total paths : 2095 | + | uniq crashes : 0 | + | uniq hangs : 19 | + +-----------------------+ +``` + +The first field in this section gives you the count of queue passes done so far +- that is, the number of times the fuzzer went over all the interesting test +cases discovered so far, fuzzed them, and looped back to the very beginning. +Every fuzzing session should be allowed to complete at least one cycle; and +ideally, should run much longer than that. + +As noted earlier, the first pass can take a day or longer, so sit back and +relax. + +To help make the call on when to hit `Ctrl-C`, the cycle counter is color-coded. +It is shown in magenta during the first pass, progresses to yellow if new finds +are still being made in subsequent rounds, then blue when that ends - and +finally, turns green after the fuzzer hasn't been seeing any action for a longer +while. + +The remaining fields in this part of the screen should be pretty obvious: +there's the number of test cases ("paths") discovered so far, and the number of +unique faults. The test cases, crashes, and hangs can be explored in real-time +by browsing the output directory, as discussed in [README.md](../README.md). + +### Cycle progress + +``` + +-------------------------------------+ + | now processing : 1296 (61.86%) | + | paths timed out : 0 (0.00%) | + +-------------------------------------+ +``` + +This box tells you how far along the fuzzer is with the current queue cycle: it +shows the ID of the test case it is currently working on, plus the number of +inputs it decided to ditch because they were persistently timing out. + +The "*" suffix sometimes shown in the first line means that the currently +processed path is not "favored" (a property discussed later on). + +### Map coverage + +``` + +--------------------------------------+ + | map density : 10.15% / 29.07% | + | count coverage : 4.03 bits/tuple | + +--------------------------------------+ +``` + +The section provides some trivia about the coverage observed by the +instrumentation embedded in the target binary. + +The first line in the box tells you how many branch tuples we have already hit, +in proportion to how much the bitmap can hold. The number on the left describes +the current input; the one on the right is the value for the entire input +corpus. + +Be wary of extremes: + +- Absolute numbers below 200 or so suggest one of three things: that the program + is extremely simple; that it is not instrumented properly (e.g., due to being + linked against a non-instrumented copy of the target library); or that it is + bailing out prematurely on your input test cases. The fuzzer will try to mark + this in pink, just to make you aware. +- Percentages over 70% may very rarely happen with very complex programs that + make heavy use of template-generated code. Because high bitmap density makes + it harder for the fuzzer to reliably discern new program states, we recommend + recompiling the binary with `AFL_INST_RATIO=10` or so and trying again (see + [env_variables.md](env_variables.md)). The fuzzer will flag high percentages + in red. Chances are, you will never see that unless you're fuzzing extremely + hairy software (say, v8, perl, ffmpeg). + +The other line deals with the variability in tuple hit counts seen in the +binary. In essence, if every taken branch is always taken a fixed number of +times for all the inputs we have tried, this will read `1.00`. As we manage to +trigger other hit counts for every branch, the needle will start to move toward +`8.00` (every bit in the 8-bit map hit), but will probably never reach that +extreme. + +Together, the values can be useful for comparing the coverage of several +different fuzzing jobs that rely on the same instrumented binary. + +### Stage progress + +``` + +-------------------------------------+ + | now trying : interest 32/8 | + | stage execs : 3996/34.4k (11.62%) | + | total execs : 27.4M | + | exec speed : 891.7/sec | + +-------------------------------------+ +``` + +This part gives you an in-depth peek at what the fuzzer is actually doing right +now. It tells you about the current stage, which can be any of: + +- calibration - a pre-fuzzing stage where the execution path is examined to + detect anomalies, establish baseline execution speed, and so on. Executed very + briefly whenever a new find is being made. +- trim L/S - another pre-fuzzing stage where the test case is trimmed to the + shortest form that still produces the same execution path. The length (L) and + stepover (S) are chosen in general relationship to file size. +- bitflip L/S - deterministic bit flips. There are L bits toggled at any given + time, walking the input file with S-bit increments. The current L/S variants + are: `1/1`, `2/1`, `4/1`, `8/8`, `16/8`, `32/8`. +- arith L/8 - deterministic arithmetics. The fuzzer tries to subtract or add + small integers to 8-, 16-, and 32-bit values. The stepover is always 8 bits. +- interest L/8 - deterministic value overwrite. The fuzzer has a list of known + "interesting" 8-, 16-, and 32-bit values to try. The stepover is 8 bits. +- extras - deterministic injection of dictionary terms. This can be shown as + "user" or "auto", depending on whether the fuzzer is using a user-supplied + dictionary (`-x`) or an auto-created one. You will also see "over" or + "insert", depending on whether the dictionary words overwrite existing data or + are inserted by offsetting the remaining data to accommodate their length. +- havoc - a sort-of-fixed-length cycle with stacked random tweaks. The + operations attempted during this stage include bit flips, overwrites with + random and "interesting" integers, block deletion, block duplication, plus + assorted dictionary-related operations (if a dictionary is supplied in the + first place). +- splice - a last-resort strategy that kicks in after the first full queue cycle + with no new paths. It is equivalent to 'havoc', except that it first splices + together two random inputs from the queue at some arbitrarily selected + midpoint. +- sync - a stage used only when `-M` or `-S` is set (see + [parallel_fuzzing.md](parallel_fuzzing.md)). No real fuzzing is involved, but + the tool scans the output from other fuzzers and imports test cases as + necessary. The first time this is done, it may take several minutes or so. + +The remaining fields should be fairly self-evident: there's the exec count +progress indicator for the current stage, a global exec counter, and a benchmark +for the current program execution speed. This may fluctuate from one test case +to another, but the benchmark should be ideally over 500 execs/sec most of the +time - and if it stays below 100, the job will probably take very long. + +The fuzzer will explicitly warn you about slow targets, too. If this happens, +see the [perf_tips.md](perf_tips.md) file included with the fuzzer for ideas on +how to speed things up. + +### Findings in depth + +``` + +--------------------------------------+ + | favored paths : 879 (41.96%) | + | new edges on : 423 (20.19%) | + | total crashes : 0 (0 unique) | + | total tmouts : 24 (19 unique) | + +--------------------------------------+ +``` + +This gives you several metrics that are of interest mostly to complete nerds. +The section includes the number of paths that the fuzzer likes the most based on +a minimization algorithm baked into the code (these will get considerably more +air time), and the number of test cases that actually resulted in better edge +coverage (versus just pushing the branch hit counters up). There are also +additional, more detailed counters for crashes and timeouts. + +Note that the timeout counter is somewhat different from the hang counter; this +one includes all test cases that exceeded the timeout, even if they did not +exceed it by a margin sufficient to be classified as hangs. + +### Fuzzing strategy yields + +``` + +-----------------------------------------------------+ + | bit flips : 57/289k, 18/289k, 18/288k | + | byte flips : 0/36.2k, 4/35.7k, 7/34.6k | + | arithmetics : 53/2.54M, 0/537k, 0/55.2k | + | known ints : 8/322k, 12/1.32M, 10/1.70M | + | dictionary : 9/52k, 1/53k, 1/24k | + |havoc/splice : 1903/20.0M, 0/0 | + |py/custom/rq : unused, 53/2.54M, unused | + | trim/eff : 20.31%/9201, 17.05% | + +-----------------------------------------------------+ +``` + +This is just another nerd-targeted section keeping track of how many paths we +have netted, in proportion to the number of execs attempted, for each of the +fuzzing strategies discussed earlier on. This serves to convincingly validate +assumptions about the usefulness of the various approaches taken by afl-fuzz. + +The trim strategy stats in this section are a bit different than the rest. The +first number in this line shows the ratio of bytes removed from the input files; +the second one corresponds to the number of execs needed to achieve this goal. +Finally, the third number shows the proportion of bytes that, although not +possible to remove, were deemed to have no effect and were excluded from some of +the more expensive deterministic fuzzing steps. + +Note that when deterministic mutation mode is off (which is the default because +it is not very efficient) the first five lines display "disabled (default, +enable with -D)". + +Only what is activated will have counter shown. + +### Path geometry + +``` + +---------------------+ + | levels : 5 | + | pending : 1570 | + | pend fav : 583 | + | own finds : 0 | + | imported : 0 | + | stability : 100.00% | + +---------------------+ +``` + +The first field in this section tracks the path depth reached through the guided +fuzzing process. In essence: the initial test cases supplied by the user are +considered "level 1". The test cases that can be derived from that through +traditional fuzzing are considered "level 2"; the ones derived by using these as +inputs to subsequent fuzzing rounds are "level 3"; and so forth. The maximum +depth is therefore a rough proxy for how much value you're getting out of the +instrumentation-guided approach taken by afl-fuzz. + +The next field shows you the number of inputs that have not gone through any +fuzzing yet. The same stat is also given for "favored" entries that the fuzzer +really wants to get to in this queue cycle (the non-favored entries may have to +wait a couple of cycles to get their chance). + +Next, we have the number of new paths found during this fuzzing section and +imported from other fuzzer instances when doing parallelized fuzzing; and the +extent to which identical inputs appear to sometimes produce variable behavior +in the tested binary. + +That last bit is actually fairly interesting: it measures the consistency of +observed traces. If a program always behaves the same for the same input data, +it will earn a score of 100%. When the value is lower but still shown in purple, +the fuzzing process is unlikely to be negatively affected. If it goes into red, +you may be in trouble, since AFL will have difficulty discerning between +meaningful and "phantom" effects of tweaking the input file. + +Now, most targets will just get a 100% score, but when you see lower figures, +there are several things to look at: + +- The use of uninitialized memory in conjunction with some intrinsic sources of + entropy in the tested binary. Harmless to AFL, but could be indicative of a + security bug. +- Attempts to manipulate persistent resources, such as left over temporary files + or shared memory objects. This is usually harmless, but you may want to + double-check to make sure the program isn't bailing out prematurely. Running + out of disk space, SHM handles, or other global resources can trigger this, + too. +- Hitting some functionality that is actually designed to behave randomly. + Generally harmless. For example, when fuzzing sqlite, an input like `select + random();` will trigger a variable execution path. +- Multiple threads executing at once in semi-random order. This is harmless when + the 'stability' metric stays over 90% or so, but can become an issue if not. + Here's what to try: + * Use afl-clang-fast from [instrumentation](../instrumentation/) - it uses a + thread-local tracking model that is less prone to concurrency issues, + * See if the target can be compiled or run without threads. Common + `./configure` options include `--without-threads`, `--disable-pthreads`, or + `--disable-openmp`. + * Replace pthreads with GNU Pth (https://www.gnu.org/software/pth/), which + allows you to use a deterministic scheduler. +- In persistent mode, minor drops in the "stability" metric can be normal, + because not all the code behaves identically when re-entered; but major dips + may signify that the code within `__AFL_LOOP()` is not behaving correctly on + subsequent iterations (e.g., due to incomplete clean-up or reinitialization of + the state) and that most of the fuzzing effort goes to waste. + +The paths where variable behavior is detected are marked with a matching entry +in the `/queue/.state/variable_behavior/` directory, so you can look +them up easily. + +### CPU load + +``` + [cpu: 25%] +``` + +This tiny widget shows the apparent CPU utilization on the local system. It is +calculated by taking the number of processes in the "runnable" state, and then +comparing it to the number of logical cores on the system. + +If the value is shown in green, you are using fewer CPU cores than available on +your system and can probably parallelize to improve performance; for tips on how +to do that, see [parallel_fuzzing.md](parallel_fuzzing.md). + +If the value is shown in red, your CPU is *possibly* oversubscribed, and running +additional fuzzers may not give you any benefits. + +Of course, this benchmark is very simplistic; it tells you how many processes +are ready to run, but not how resource-hungry they may be. It also doesn't +distinguish between physical cores, logical cores, and virtualized CPUs; the +performance characteristics of each of these will differ quite a bit. + +If you want a more accurate measurement, you can run the `afl-gotcpu` utility +from the command line. + +## Interpreting output + +See [#understanding-the-status-screen](#understanding-the-status-screen) for +information on how to interpret the displayed stats and monitor the health of +the process. Be sure to consult this file especially if any UI elements are +highlighted in red. + +The fuzzing process will continue until you press Ctrl-C. At a minimum, you want +to allow the fuzzer to complete one queue cycle, which may take anywhere from a +couple of hours to a week or so. + +There are three subdirectories created within the output directory and updated +in real-time: + +- queue/ - test cases for every distinctive execution path, plus all the + starting files given by the user. This is the synthesized corpus + mentioned in section 2. + + Before using this corpus for any other purposes, you can shrink + it to a smaller size using the afl-cmin tool. The tool will find + a smaller subset of files offering equivalent edge coverage. + +- crashes/ - unique test cases that cause the tested program to receive a fatal + signal (e.g., SIGSEGV, SIGILL, SIGABRT). The entries are grouped by + the received signal. + +- hangs/ - unique test cases that cause the tested program to time out. The + default time limit before something is classified as a hang is the + larger of 1 second and the value of the -t parameter. The value can + be fine-tuned by setting AFL_HANG_TMOUT, but this is rarely + necessary. + +Crashes and hangs are considered "unique" if the associated execution paths +involve any state transitions not seen in previously-recorded faults. If a +single bug can be reached in multiple ways, there will be some count inflation +early in the process, but this should quickly taper off. + +The file names for crashes and hangs are correlated with the parent, non-faulting +queue entries. This should help with debugging. + +## Visualizing + +If you have gnuplot installed, you can also generate some pretty graphs for any +active fuzzing task using afl-plot. For an example of how this looks like, see +[https://lcamtuf.coredump.cx/afl/plot/](https://lcamtuf.coredump.cx/afl/plot/). + +You can also manually build and install afl-plot-ui, which is a helper utility +for showing the graphs generated by afl-plot in a graphical window using GTK. +You can build and install it as follows: + +```shell +sudo apt install libgtk-3-0 libgtk-3-dev pkg-config +cd utils/plot_ui +make +cd ../../ +sudo make install +``` + + +### Addendum: status and plot files + +For unattended operation, some of the key status screen information can be also +found in a machine-readable format in the fuzzer_stats file in the output +directory. This includes: + +- `start_time` - unix time indicating the start time of afl-fuzz +- `last_update` - unix time corresponding to the last update of this file +- `run_time` - run time in seconds to the last update of this file +- `fuzzer_pid` - PID of the fuzzer process +- `cycles_done` - queue cycles completed so far +- `cycles_wo_finds` - number of cycles without any new paths found +- `execs_done` - number of execve() calls attempted +- `execs_per_sec` - overall number of execs per second +- `paths_total` - total number of entries in the queue +- `paths_favored` - number of queue entries that are favored +- `paths_found` - number of entries discovered through local fuzzing +- `paths_imported` - number of entries imported from other instances +- `max_depth` - number of levels in the generated data set +- `cur_path` - currently processed entry number +- `pending_favs` - number of favored entries still waiting to be fuzzed +- `pending_total` - number of all entries waiting to be fuzzed +- `variable_paths` - number of test cases showing variable behavior +- `stability` - percentage of bitmap bytes that behave consistently +- `bitmap_cvg` - percentage of edge coverage found in the map so far +- `unique_crashes` - number of unique crashes recorded +- `unique_hangs` - number of unique hangs encountered +- `last_path` - seconds since the last path was found +- `last_crash` - seconds since the last crash was found +- `last_hang` - seconds since the last hang was found +- `execs_since_crash` - execs since the last crash was found +- `exec_timeout` - the -t command line value +- `slowest_exec_ms` - real time of the slowest execution in ms +- `peak_rss_mb` - max rss usage reached during fuzzing in MB +- `edges_found` - how many edges have been found +- `var_byte_count` - how many edges are non-deterministic +- `afl_banner` - banner text (e.g. the target name) +- `afl_version` - the version of AFL used +- `target_mode` - default, persistent, qemu, unicorn, non-instrumented +- `command_line` - full command line used for the fuzzing session + +Most of these map directly to the UI elements discussed earlier on. + +On top of that, you can also find an entry called `plot_data`, containing a +plottable history for most of these fields. If you have gnuplot installed, you +can turn this into a nice progress report with the included `afl-plot` tool. + +### Addendum: automatically sending metrics with StatsD + +In a CI environment or when running multiple fuzzers, it can be tedious to log +into each of them or deploy scripts to read the fuzzer statistics. Using +`AFL_STATSD` (and the other related environment variables `AFL_STATSD_HOST`, +`AFL_STATSD_PORT`, `AFL_STATSD_TAGS_FLAVOR`) you can automatically send metrics +to your favorite StatsD server. Depending on your StatsD server, you will be +able to monitor, trigger alerts, or perform actions based on these metrics (e.g: +alert on slow exec/s for a new build, threshold of crashes, time since last +crash > X, etc). + +The selected metrics are a subset of all the metrics found in the status and in +the plot file. The list is the following: `cycle_done`, `cycles_wo_finds`, +`execs_done`,`execs_per_sec`, `paths_total`, `paths_favored`, `paths_found`, +`paths_imported`, `max_depth`, `cur_path`, `pending_favs`, `pending_total`, +`variable_paths`, `unique_crashes`, `unique_hangs`, `total_crashes`, +`slowest_exec_ms`, `edges_found`, `var_byte_count`, `havoc_expansion`. Their +definitions can be found in the addendum above. + +When using multiple fuzzer instances with StatsD, it is *strongly* recommended +to setup the flavor (AFL_STATSD_TAGS_FLAVOR) to match your StatsD server. This +will allow you to see individual fuzzer performance, detect bad ones, see the +progress of each strategy... \ No newline at end of file diff --git a/docs/custom_mutators.md b/docs/custom_mutators.md index 8b5a4068..b1dfd309 100644 --- a/docs/custom_mutators.md +++ b/docs/custom_mutators.md @@ -127,9 +127,9 @@ def deinit(): # optional for Python - `describe` (optional): - When this function is called, it shall describe the current testcase, + When this function is called, it shall describe the current test case, generated by the last mutation. This will be called, for example, - to name the written testcase file after a crash occurred. + to name the written test case file after a crash occurred. Using it can help to reproduce crashing mutations. - `havoc_mutation` and `havoc_mutation_probability` (optional): @@ -224,7 +224,7 @@ Optionally, the following environment variables are supported: - `AFL_CUSTOM_MUTATOR_ONLY` - Disable all other mutation stages. This can prevent broken testcases + Disable all other mutation stages. This can prevent broken test cases (those that your Python module can't work with anymore) to fill up your queue. Best combined with a custom trimming routine (see below) because trimming can cause the same test breakage like havoc and splice. diff --git a/docs/env_variables.md b/docs/env_variables.md index 65cca0dc..34318cd4 100644 --- a/docs/env_variables.md +++ b/docs/env_variables.md @@ -306,8 +306,9 @@ checks or alter some of the more exotic semantics of the tool: exit soon after the first crash is found. - `AFL_CMPLOG_ONLY_NEW` will only perform the expensive cmplog feature for - newly found testcases and not for testcases that are loaded on startup (`-i - in`). This is an important feature to set when resuming a fuzzing session. + newly found test cases and not for test cases that are loaded on startup + (`-i in`). This is an important feature to set when resuming a fuzzing + session. - Setting `AFL_CRASH_EXITCODE` sets the exit code AFL treats as crash. For example, if `AFL_CRASH_EXITCODE='-1'` is set, each input resulting in a `-1` @@ -447,8 +448,8 @@ checks or alter some of the more exotic semantics of the tool: - If you are using persistent mode (you should, see [instrumentation/README.persistent_mode.md](../instrumentation/README.persistent_mode.md)), - some targets keep inherent state due which a detected crash testcase does - not crash the target again when the testcase is given. To be able to still + some targets keep inherent state due which a detected crash test case does + not crash the target again when the test case is given. To be able to still re-trigger these crashes, you can use the `AFL_PERSISTENT_RECORD` variable with a value of how many previous fuzz cases to keep prio a crash. If set to e.g. 10, then the 9 previous inputs are written to out/default/crashes as diff --git a/docs/features.md b/docs/features.md index f44e32ff..05670e6f 100644 --- a/docs/features.md +++ b/docs/features.md @@ -17,7 +17,7 @@ | Context Coverage | | x(6) | | | | | | | Auto Dictionary | | x(7) | | | | | | | Snapshot LKM Support | | (x)(8) | (x)(8) | | (x)(5) | | | - | Shared Memory Testcases | | x | x | x86[_64]/arm64 | x | x | | + | Shared Memory Test cases | | x | x | x86[_64]/arm64 | x | x | | 1. default for LLVM >= 9.0, env var for older version due an efficiency bug in previous llvm versions 2. GCC creates non-performant code, hence it is disabled in gcc_plugin diff --git a/docs/fuzzing_in_depth.md b/docs/fuzzing_in_depth.md index 5306cbef..5b4a9df7 100644 --- a/docs/fuzzing_in_depth.md +++ b/docs/fuzzing_in_depth.md @@ -1,24 +1,25 @@ # Fuzzing with AFL++ The following describes how to fuzz with a target if source code is available. -If you have a binary-only target please skip to [#Instrumenting binary-only apps](#Instrumenting binary-only apps) +If you have a binary-only target, please go to +[fuzzing_binary-only_targets.md](fuzzing_binary-only_targets.md). -Fuzzing source code is a three-step process. +Fuzzing source code is a three-step process: 1. Compile the target with a special compiler that prepares the target to be fuzzed efficiently. This step is called "instrumenting a target". 2. Prepare the fuzzing by selecting and optimizing the input corpus for the target. -3. Perform the fuzzing of the target by randomly mutating input and assessing - if a generated input was processed in a new path in the target binary. +3. Perform the fuzzing of the target by randomly mutating input and assessing if + a generated input was processed in a new path in the target binary. ### 1. Instrumenting that target #### a) Selecting the best AFL++ compiler for instrumenting the target AFL++ comes with a central compiler `afl-cc` that incorporates various different -kinds of compiler targets and and instrumentation options. -The following evaluation flow will help you to select the best possible. +kinds of compiler targets and and instrumentation options. The following +evaluation flow will help you to select the best possible. It is highly recommended to have the newest llvm version possible installed, anything below 9 is not recommended. @@ -51,132 +52,131 @@ anything below 9 is not recommended. Clickable README links for the chosen compiler: - * [LTO mode - afl-clang-lto](../instrumentation/README.lto.md) - * [LLVM mode - afl-clang-fast](../instrumentation/README.llvm.md) - * [GCC_PLUGIN mode - afl-gcc-fast](../instrumentation/README.gcc_plugin.md) - * GCC/CLANG modes (afl-gcc/afl-clang) have no README as they have no own features +* [LTO mode - afl-clang-lto](../instrumentation/README.lto.md) +* [LLVM mode - afl-clang-fast](../instrumentation/README.llvm.md) +* [GCC_PLUGIN mode - afl-gcc-fast](../instrumentation/README.gcc_plugin.md) +* GCC/CLANG modes (afl-gcc/afl-clang) have no README as they have no own + features You can select the mode for the afl-cc compiler by: - 1. use a symlink to afl-cc: afl-gcc, afl-g++, afl-clang, afl-clang++, - afl-clang-fast, afl-clang-fast++, afl-clang-lto, afl-clang-lto++, - afl-gcc-fast, afl-g++-fast (recommended!) - 2. using the environment variable AFL_CC_COMPILER with MODE - 3. passing --afl-MODE command line options to the compiler via CFLAGS/CXXFLAGS/CPPFLAGS +1. use a symlink to afl-cc: afl-gcc, afl-g++, afl-clang, afl-clang++, + afl-clang-fast, afl-clang-fast++, afl-clang-lto, afl-clang-lto++, + afl-gcc-fast, afl-g++-fast (recommended!) +2. using the environment variable AFL_CC_COMPILER with MODE +3. passing --afl-MODE command line options to the compiler via + CFLAGS/CXXFLAGS/CPPFLAGS MODE can be one of: LTO (afl-clang-lto*), LLVM (afl-clang-fast*), GCC_PLUGIN (afl-g*-fast) or GCC (afl-gcc/afl-g++) or CLANG(afl-clang/afl-clang++). -Because no AFL specific command-line options are accepted (beside the ---afl-MODE command), the compile-time tools make fairly broad use of environment -variables, which can be listed with `afl-cc -hh` or by reading [env_variables.md](env_variables.md). +Because no AFL specific command-line options are accepted (beside the --afl-MODE +command), the compile-time tools make fairly broad use of environment variables, +which can be listed with `afl-cc -hh` or by reading +[env_variables.md](env_variables.md). #### b) Selecting instrumentation options -The following options are available when you instrument with LTO mode (afl-clang-fast/afl-clang-lto): - - * Splitting integer, string, float and switch comparisons so AFL++ can easier - solve these. This is an important option if you do not have a very good - and large input corpus. This technique is called laf-intel or COMPCOV. - To use this set the following environment variable before compiling the - target: `export AFL_LLVM_LAF_ALL=1` - You can read more about this in [instrumentation/README.laf-intel.md](../instrumentation/README.laf-intel.md) - * A different technique (and usually a better one than laf-intel) is to - instrument the target so that any compare values in the target are sent to - AFL++ which then tries to put these values into the fuzzing data at different - locations. This technique is very fast and good - if the target does not - transform input data before comparison. Therefore this technique is called - `input to state` or `redqueen`. - If you want to use this technique, then you have to compile the target - twice, once specifically with/for this mode by setting `AFL_LLVM_CMPLOG=1`, - and pass this binary to afl-fuzz via the `-c` parameter. - Note that you can compile also just a cmplog binary and use that for both - however there will be a performance penality. - You can read more about this in [instrumentation/README.cmplog.md](../instrumentation/README.cmplog.md) - -If you use LTO, LLVM or GCC_PLUGIN mode (afl-clang-fast/afl-clang-lto/afl-gcc-fast) -you have the option to selectively only instrument parts of the target that you -are interested in: - - * To instrument only those parts of the target that you are interested in - create a file with all the filenames of the source code that should be - instrumented. - For afl-clang-lto and afl-gcc-fast - or afl-clang-fast if a mode other than - DEFAULT/PCGUARD is used or you have llvm > 10.0.0 - just put one - filename or function per line (no directory information necessary for - filenames9, and either set `export AFL_LLVM_ALLOWLIST=allowlist.txt` **or** - `export AFL_LLVM_DENYLIST=denylist.txt` - depending on if you want per - default to instrument unless noted (DENYLIST) or not perform instrumentation - unless requested (ALLOWLIST). - **NOTE:** During optimization functions might be inlined and then would not match! - See [instrumentation/README.instrument_list.md](../instrumentation/README.instrument_list.md) +The following options are available when you instrument with LTO mode +(afl-clang-fast/afl-clang-lto): + +* Splitting integer, string, float and switch comparisons so AFL++ can easier + solve these. This is an important option if you do not have a very good and + large input corpus. This technique is called laf-intel or COMPCOV. To use this + set the following environment variable before compiling the target: `export + AFL_LLVM_LAF_ALL=1` You can read more about this in + [instrumentation/README.laf-intel.md](../instrumentation/README.laf-intel.md). +* A different technique (and usually a better one than laf-intel) is to + instrument the target so that any compare values in the target are sent to + AFL++ which then tries to put these values into the fuzzing data at different + locations. This technique is very fast and good - if the target does not + transform input data before comparison. Therefore this technique is called + `input to state` or `redqueen`. If you want to use this technique, then you + have to compile the target twice, once specifically with/for this mode by + setting `AFL_LLVM_CMPLOG=1`, and pass this binary to afl-fuzz via the `-c` + parameter. Note that you can compile also just a cmplog binary and use that + for both however there will be a performance penality. You can read more about + this in + [instrumentation/README.cmplog.md](../instrumentation/README.cmplog.md). + +If you use LTO, LLVM or GCC_PLUGIN mode +(afl-clang-fast/afl-clang-lto/afl-gcc-fast) you have the option to selectively +only instrument parts of the target that you are interested in: + +* To instrument only those parts of the target that you are interested in create + a file with all the filenames of the source code that should be instrumented. + For afl-clang-lto and afl-gcc-fast - or afl-clang-fast if a mode other than + DEFAULT/PCGUARD is used or you have llvm > 10.0.0 - just put one filename or + function per line (no directory information necessary for filenames9, and + either set `export AFL_LLVM_ALLOWLIST=allowlist.txt` **or** `export + AFL_LLVM_DENYLIST=denylist.txt` - depending on if you want per default to + instrument unless noted (DENYLIST) or not perform instrumentation unless + requested (ALLOWLIST). **NOTE:** During optimization functions might be + inlined and then would not match! See + [instrumentation/README.instrument_list.md](../instrumentation/README.instrument_list.md) There are many more options and modes available however these are most of the time less effective. See: - * [instrumentation/README.ctx.md](../instrumentation/README.ctx.md) - * [instrumentation/README.ngram.md](../instrumentation/README.ngram.md) +* [instrumentation/README.ctx.md](../instrumentation/README.ctx.md) +* [instrumentation/README.ngram.md](../instrumentation/README.ngram.md) AFL++ performs "never zero" counting in its bitmap. You can read more about this here: - * [instrumentation/README.neverzero.md](../instrumentation/README.neverzero.md) +* [instrumentation/README.neverzero.md](../instrumentation/README.neverzero.md) #### c) Sanitizers -It is possible to use sanitizers when instrumenting targets for fuzzing, -which allows you to find bugs that would not necessarily result in a crash. +It is possible to use sanitizers when instrumenting targets for fuzzing, which +allows you to find bugs that would not necessarily result in a crash. Note that sanitizers have a huge impact on CPU (= less executions per second) -and RAM usage. Also you should only run one afl-fuzz instance per sanitizer type. -This is enough because a use-after-free bug will be picked up, e.g. by -ASAN (address sanitizer) anyway when syncing to other fuzzing instances, -so not all fuzzing instances need to be instrumented with ASAN. +and RAM usage. Also you should only run one afl-fuzz instance per sanitizer +type. This is enough because a use-after-free bug will be picked up, e.g. by +ASAN (address sanitizer) anyway when syncing to other fuzzing instances, so not +all fuzzing instances need to be instrumented with ASAN. The following sanitizers have built-in support in AFL++: - * ASAN = Address SANitizer, finds memory corruption vulnerabilities like - use-after-free, NULL pointer dereference, buffer overruns, etc. - Enabled with `export AFL_USE_ASAN=1` before compiling. - * MSAN = Memory SANitizer, finds read access to uninitialized memory, eg. - a local variable that is defined and read before it is even set. - Enabled with `export AFL_USE_MSAN=1` before compiling. - * UBSAN = Undefined Behaviour SANitizer, finds instances where - by the - C and C++ standards - undefined behaviour happens, e.g. adding two - signed integers together where the result is larger than a signed integer - can hold. - Enabled with `export AFL_USE_UBSAN=1` before compiling. - * CFISAN = Control Flow Integrity SANitizer, finds instances where the - control flow is found to be illegal. Originally this was rather to - prevent return oriented programming exploit chains from functioning, - in fuzzing this is mostly reduced to detecting type confusion - vulnerabilities - which is however one of the most important and dangerous - C++ memory corruption classes! - Enabled with `export AFL_USE_CFISAN=1` before compiling. - * TSAN = Thread SANitizer, finds thread race conditions. - Enabled with `export AFL_USE_TSAN=1` before compiling. - * LSAN = Leak SANitizer, finds memory leaks in a program. This is not really - a security issue, but for developers this can be very valuable. - Note that unlike the other sanitizers above this needs - `__AFL_LEAK_CHECK();` added to all areas of the target source code where you - find a leak check necessary! - Enabled with `export AFL_USE_LSAN=1` before compiling. - -It is possible to further modify the behaviour of the sanitizers at run-time -by setting `ASAN_OPTIONS=...`, `LSAN_OPTIONS` etc. - the available parameters -can be looked up in the sanitizer documentation of llvm/clang. -afl-fuzz however requires some specific parameters important for fuzzing to be -set. If you want to set your own, it might bail and report what it is missing. +* ASAN = Address SANitizer, finds memory corruption vulnerabilities like + use-after-free, NULL pointer dereference, buffer overruns, etc. Enabled with + `export AFL_USE_ASAN=1` before compiling. +* MSAN = Memory SANitizer, finds read access to uninitialized memory, eg. a + local variable that is defined and read before it is even set. Enabled with + `export AFL_USE_MSAN=1` before compiling. +* UBSAN = Undefined Behaviour SANitizer, finds instances where - by the C and + C++ standards - undefined behaviour happens, e.g. adding two signed integers + together where the result is larger than a signed integer can hold. Enabled + with `export AFL_USE_UBSAN=1` before compiling. +* CFISAN = Control Flow Integrity SANitizer, finds instances where the control + flow is found to be illegal. Originally this was rather to prevent return + oriented programming exploit chains from functioning, in fuzzing this is + mostly reduced to detecting type confusion vulnerabilities - which is, + however, one of the most important and dangerous C++ memory corruption + classes! Enabled with `export AFL_USE_CFISAN=1` before compiling. +* TSAN = Thread SANitizer, finds thread race conditions. Enabled with `export + AFL_USE_TSAN=1` before compiling. +* LSAN = Leak SANitizer, finds memory leaks in a program. This is not really a + security issue, but for developers this can be very valuable. Note that unlike + the other sanitizers above this needs `__AFL_LEAK_CHECK();` added to all areas + of the target source code where you find a leak check necessary! Enabled with + `export AFL_USE_LSAN=1` before compiling. + +It is possible to further modify the behaviour of the sanitizers at run-time by +setting `ASAN_OPTIONS=...`, `LSAN_OPTIONS` etc. - the available parameters can +be looked up in the sanitizer documentation of llvm/clang. afl-fuzz, however, +requires some specific parameters important for fuzzing to be set. If you want +to set your own, it might bail and report what it is missing. Note that some sanitizers cannot be used together, e.g. ASAN and MSAN, and others often cannot work together because of target weirdness, e.g. ASAN and CFISAN. You might need to experiment which sanitizers you can combine in a -target (which means more instances can be run without a sanitized target, -which is more effective). +target (which means more instances can be run without a sanitized target, which +is more effective). #### d) Modify the target -If the target has features that make fuzzing more difficult, e.g. -checksums, HMAC, etc. then modify the source code so that checks for these -values are removed. -This can even be done safely for source code used in operational products -by eliminating these checks within these AFL specific blocks: +If the target has features that make fuzzing more difficult, e.g. checksums, +HMAC, etc. then modify the source code so that checks for these values are +removed. This can even be done safely for source code used in operational +products by eliminating these checks within these AFL specific blocks: ``` #ifdef FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION @@ -193,25 +193,24 @@ All AFL++ compilers will set this preprocessor definition automatically. In this step the target source code is compiled so that it can be fuzzed. Basically you have to tell the target build system that the selected AFL++ -compiler is used. Also - if possible - you should always configure the -build system such that the target is compiled statically and not dynamically. -How to do this is described below. +compiler is used. Also - if possible - you should always configure the build +system such that the target is compiled statically and not dynamically. How to +do this is described below. -The #1 rule when instrumenting a target is: avoid instrumenting shared -libraries at all cost. You would need to set LD_LIBRARY_PATH to point to -these, you could accidently type "make install" and install them system wide - -so don't. Really don't. -**Always compile libraries you want to have instrumented as static and link -these to the target program!** +The #1 rule when instrumenting a target is: avoid instrumenting shared libraries +at all cost. You would need to set LD_LIBRARY_PATH to point to these, you could +accidentally type "make install" and install them system wide - so don't. Really +don't. **Always compile libraries you want to have instrumented as static and +link these to the target program!** Then build the target. (Usually with `make`) **NOTES** -1. sometimes configure and build systems are fickle and do not like - stderr output (and think this means a test failure) - which is something - AFL++ likes to do to show statistics. It is recommended to disable AFL++ - instrumentation reporting via `export AFL_QUIET=1`. +1. sometimes configure and build systems are fickle and do not like stderr + output (and think this means a test failure) - which is something AFL++ likes + to do to show statistics. It is recommended to disable AFL++ instrumentation + reporting via `export AFL_QUIET=1`. 2. sometimes configure and build systems error on warnings - these should be disabled (e.g. `--disable-werror` for some configure scripts). @@ -249,41 +248,46 @@ Sometimes cmake and configure do not pick up the AFL++ compiler, or the ranlib/ar that is needed - because this was just not foreseen by the developer of the target. Or they have non-standard options. Figure out if there is a non-standard way to set this, otherwise set up the build normally and edit the -generated build environment afterwards manually to point it to the right compiler -(and/or ranlib and ar). +generated build environment afterwards manually to point it to the right +compiler (and/or ranlib and ar). #### f) Better instrumentation If you just fuzz a target program as-is you are wasting a great opportunity for much more fuzzing speed. -This variant requires the usage of afl-clang-lto, afl-clang-fast or afl-gcc-fast. +This variant requires the usage of afl-clang-lto, afl-clang-fast or +afl-gcc-fast. -It is the so-called `persistent mode`, which is much, much faster but -requires that you code a source file that is specifically calling the target -functions that you want to fuzz, plus a few specific AFL++ functions around -it. See [instrumentation/README.persistent_mode.md](../instrumentation/README.persistent_mode.md) for details. +It is the so-called `persistent mode`, which is much, much faster but requires +that you code a source file that is specifically calling the target functions +that you want to fuzz, plus a few specific AFL++ functions around it. See +[instrumentation/README.persistent_mode.md](../instrumentation/README.persistent_mode.md) +for details. -Basically if you do not fuzz a target in persistent mode then you are just -doing it for a hobby and not professionally :-). +Basically if you do not fuzz a target in persistent mode then you are just doing +it for a hobby and not professionally :-). #### g) libfuzzer fuzzer harnesses with LLVMFuzzerTestOneInput() libfuzzer `LLVMFuzzerTestOneInput()` harnesses are the defacto standard for fuzzing, and they can be used with AFL++ (and honggfuzz) as well! Compiling them is as simple as: + ``` afl-clang-fast++ -fsanitize=fuzzer -o harness harness.cpp targetlib.a ``` + You can even use advanced libfuzzer features like `FuzzedDataProvider`, `LLVMFuzzerMutate()` etc. and they will work! The generated binary is fuzzed with afl-fuzz like any other fuzz target. Bonus: the target is already optimized for fuzzing due to persistent mode and -shared-memory testcases and hence gives you the fastest speed possible. +shared-memory test cases and hence gives you the fastest speed possible. -For more information see [utils/aflpp_driver/README.md](../utils/aflpp_driver/README.md) +For more information, see +[utils/aflpp_driver/README.md](../utils/aflpp_driver/README.md). ### 2. Preparing the fuzzing campaign @@ -294,8 +298,8 @@ target as possible improves the efficiency a lot. Try to gather valid inputs for the target from wherever you can. E.g. if it is the PNG picture format try to find as many png files as possible, e.g. from -reported bugs, test suites, random downloads from the internet, unit test -case data - from all kind of PNG software. +reported bugs, test suites, random downloads from the internet, unit test case +data - from all kind of PNG software. If the input format is not known, you can also modify a target program to write normal data it receives and processes to a file and use these. @@ -319,10 +323,9 @@ This step is highly recommended! #### c) Minimizing all corpus files -The shorter the input files that still traverse the same path -within the target, the better the fuzzing will be. This minimization -is done with `afl-tmin` however it is a long process as this has to -be done for every file: +The shorter the input files that still traverse the same path within the target, +the better the fuzzing will be. This minimization is done with `afl-tmin` +however it is a long process as this has to be done for every file: ``` mkdir input @@ -332,8 +335,8 @@ for i in *; do done ``` -This step can also be parallelized, e.g. with `parallel`. -Note that this step is rather optional though. +This step can also be parallelized, e.g. with `parallel`. Note that this step is +rather optional though. #### Done! @@ -343,10 +346,9 @@ to be used in fuzzing! :-) ### 3. Fuzzing the target -In this final step we fuzz the target. -There are not that many important options to run the target - unless you want -to use many CPU cores/threads for the fuzzing, which will make the fuzzing much -more useful. +In this final step we fuzz the target. There are not that many important options +to run the target - unless you want to use many CPU cores/threads for the +fuzzing, which will make the fuzzing much more useful. If you just use one CPU for fuzzing, then you are fuzzing just for fun and not seriously :-) @@ -355,19 +357,19 @@ seriously :-) Before you do even a test run of afl-fuzz execute `sudo afl-system-config` (on the host if you execute afl-fuzz in a docker container). This reconfigures the -system for optimal speed - which afl-fuzz checks and bails otherwise. -Set `export AFL_SKIP_CPUFREQ=1` for afl-fuzz to skip this check if you cannot -run afl-system-config with root privileges on the host for whatever reason. +system for optimal speed - which afl-fuzz checks and bails otherwise. Set +`export AFL_SKIP_CPUFREQ=1` for afl-fuzz to skip this check if you cannot run +afl-system-config with root privileges on the host for whatever reason. Note there is also `sudo afl-persistent-config` which sets additional permanent boot options for a much better fuzzing performance. Note that both scripts improve your fuzzing performance but also decrease your -system protection against attacks! So set strong firewall rules and only -expose SSH as a network service if you use these (which is highly recommended). +system protection against attacks! So set strong firewall rules and only expose +SSH as a network service if you use these (which is highly recommended). -If you have an input corpus from step 2 then specify this directory with the `-i` -option. Otherwise create a new directory and create a file with any content +If you have an input corpus from step 2 then specify this directory with the +`-i` option. Otherwise create a new directory and create a file with any content as test data in there. If you do not want anything special, the defaults are already usually best, @@ -387,36 +389,37 @@ same as the afl-fuzz -M/-S naming :-) For more information on screen or tmux please check their documentation. If you need to stop and re-start the fuzzing, use the same command line options -(or even change them by selecting a different power schedule or another -mutation mode!) and switch the input directory with a dash (`-`): +(or even change them by selecting a different power schedule or another mutation +mode!) and switch the input directory with a dash (`-`): `afl-fuzz -i - -o output -- bin/target -d @@` -Memory limits are not enforced by afl-fuzz by default and the system may run -out of memory. You can decrease the memory with the `-m` option, the value is -in MB. If this is too small for the target, you can usually see this by -afl-fuzz bailing with the message that it could not connect to the forkserver. +Memory limits are not enforced by afl-fuzz by default and the system may run out +of memory. You can decrease the memory with the `-m` option, the value is in MB. +If this is too small for the target, you can usually see this by afl-fuzz +bailing with the message that it could not connect to the forkserver. -Adding a dictionary is helpful. See the directory [dictionaries/](../dictionaries/) if -something is already included for your data format, and tell afl-fuzz to load -that dictionary by adding `-x dictionaries/FORMAT.dict`. With afl-clang-lto -you have an autodictionary generation for which you need to do nothing except -to use afl-clang-lto as the compiler. You also have the option to generate -a dictionary yourself, see [utils/libtokencap/README.md](../utils/libtokencap/README.md). +Adding a dictionary is helpful. See the directory +[dictionaries/](../dictionaries/) if something is already included for your data +format, and tell afl-fuzz to load that dictionary by adding `-x +dictionaries/FORMAT.dict`. With afl-clang-lto you have an autodictionary +generation for which you need to do nothing except to use afl-clang-lto as the +compiler. You also have the option to generate a dictionary yourself, see +[utils/libtokencap/README.md](../utils/libtokencap/README.md). afl-fuzz has a variety of options that help to workaround target quirks like -specific locations for the input file (`-f`), performing deterministic -fuzzing (`-D`) and many more. Check out `afl-fuzz -h`. +specific locations for the input file (`-f`), performing deterministic fuzzing +(`-D`) and many more. Check out `afl-fuzz -h`. We highly recommend that you set a memory limit for running the target with `-m` -which defines the maximum memory in MB. This prevents a potential -out-of-memory problem for your system plus helps you detect missing `malloc()` -failure handling in the target. -Play around with various -m values until you find one that safely works for all -your input seeds (if you have good ones and then double or quadrouple that. +which defines the maximum memory in MB. This prevents a potential out-of-memory +problem for your system plus helps you detect missing `malloc()` failure +handling in the target. Play around with various -m values until you find one +that safely works for all your input seeds (if you have good ones and then +double or quadruple that. -By default afl-fuzz never stops fuzzing. To terminate AFL++ simply press Control-C -or send a signal SIGINT. You can limit the number of executions or approximate runtime -in seconds with options also. +By default afl-fuzz never stops fuzzing. To terminate AFL++ simply press +Control-C or send a signal SIGINT. You can limit the number of executions or +approximate runtime in seconds with options also. When you start afl-fuzz you will see a user interface that shows what the status is: @@ -426,67 +429,67 @@ All labels are explained in [status_screen.md](status_screen.md). #### b) Using multiple cores -If you want to seriously fuzz then use as many cores/threads as possible to -fuzz your target. +If you want to seriously fuzz then use as many cores/threads as possible to fuzz +your target. On the same machine - due to the design of how AFL++ works - there is a maximum -number of CPU cores/threads that are useful, use more and the overall performance -degrades instead. This value depends on the target, and the limit is between 32 -and 64 cores per machine. +number of CPU cores/threads that are useful, use more and the overall +performance degrades instead. This value depends on the target, and the limit is +between 32 and 64 cores per machine. If you have the RAM, it is highly recommended run the instances with a caching -of the testcases. Depending on the average testcase size (and those found -during fuzzing) and their number, a value between 50-500MB is recommended. -You can set the cache size (in MB) by setting the environment variable `AFL_TESTCACHE_SIZE`. +of the test cases. Depending on the average test case size (and those found +during fuzzing) and their number, a value between 50-500MB is recommended. You +can set the cache size (in MB) by setting the environment variable +`AFL_TESTCACHE_SIZE`. -There should be one main fuzzer (`-M main-$HOSTNAME` option) and as many secondary -fuzzers (eg `-S variant1`) as you have cores that you use. -Every -M/-S entry needs a unique name (that can be whatever), however the same --o output directory location has to be used for all instances. +There should be one main fuzzer (`-M main-$HOSTNAME` option) and as many +secondary fuzzers (e.g. `-S variant1`) as you have cores that you use. Every +-M/-S entry needs a unique name (that can be whatever), however, the same -o +output directory location has to be used for all instances. For every secondary fuzzer there should be a variation, e.g.: - * one should fuzz the target that was compiled differently: with sanitizers - activated (`export AFL_USE_ASAN=1 ; export AFL_USE_UBSAN=1 ; - export AFL_USE_CFISAN=1`) - * one or two should fuzz the target with CMPLOG/redqueen (see above), at - least one cmplog instance should follow transformations (`-l AT`) - * one to three fuzzers should fuzz a target compiled with laf-intel/COMPCOV - (see above). Important note: If you run more than one laf-intel/COMPCOV - fuzzer and you want them to share their intermediate results, the main - fuzzer (`-M`) must be one of the them! (Although this is not really - recommended.) +* one should fuzz the target that was compiled differently: with sanitizers + activated (`export AFL_USE_ASAN=1 ; export AFL_USE_UBSAN=1 ; export + AFL_USE_CFISAN=1`) +* one or two should fuzz the target with CMPLOG/redqueen (see above), at least + one cmplog instance should follow transformations (`-l AT`) +* one to three fuzzers should fuzz a target compiled with laf-intel/COMPCOV (see + above). Important note: If you run more than one laf-intel/COMPCOV fuzzer and + you want them to share their intermediate results, the main fuzzer (`-M`) must + be one of the them! (Although this is not really recommended.) All other secondaries should be used like this: - * A quarter to a third with the MOpt mutator enabled: `-L 0` - * run with a different power schedule, recommended are: - `fast (default), explore, coe, lin, quad, exploit and rare` - which you can set with e.g. `-p explore` - * a few instances should use the old queue cycling with `-Z` +* a quarter to a third with the MOpt mutator enabled: `-L 0` +* run with a different power schedule, recommended are: + `fast (default), explore, coe, lin, quad, exploit and rare` which you can set + with e.g. `-p explore` +* a few instances should use the old queue cycling with `-Z` -Also it is recommended to set `export AFL_IMPORT_FIRST=1` to load testcases +Also, it is recommended to set `export AFL_IMPORT_FIRST=1` to load test cases from other fuzzers in the campaign first. If you have a large corpus, a corpus from a previous run or are fuzzing in a CI, then also set `export AFL_CMPLOG_ONLY_NEW=1` and `export AFL_FAST_CAL=1`. -You can also use different fuzzers. -If you are using AFL spinoffs or AFL conforming fuzzers, then just use the -same -o directory and give it a unique `-S` name. -Examples are: - * [Fuzzolic](https://github.com/season-lab/fuzzolic) - * [symcc](https://github.com/eurecom-s3/symcc/) - * [Eclipser](https://github.com/SoftSec-KAIST/Eclipser/) - * [AFLsmart](https://github.com/aflsmart/aflsmart) - * [FairFuzz](https://github.com/carolemieux/afl-rb) - * [Neuzz](https://github.com/Dongdongshe/neuzz) - * [Angora](https://github.com/AngoraFuzzer/Angora) - -A long list can be found at [https://github.com/Microsvuln/Awesome-AFL](https://github.com/Microsvuln/Awesome-AFL) - -However you can also sync AFL++ with honggfuzz, libfuzzer with `-entropic=1`, etc. -Just show the main fuzzer (-M) with the `-F` option where the queue/work -directory of a different fuzzer is, e.g. `-F /src/target/honggfuzz`. -Using honggfuzz (with `-n 1` or `-n 2`) and libfuzzer in parallel is highly +You can also use different fuzzers. If you are using AFL spinoffs or AFL +conforming fuzzers, then just use the same -o directory and give it a unique +`-S` name. Examples are: +* [Fuzzolic](https://github.com/season-lab/fuzzolic) +* [symcc](https://github.com/eurecom-s3/symcc/) +* [Eclipser](https://github.com/SoftSec-KAIST/Eclipser/) +* [AFLsmart](https://github.com/aflsmart/aflsmart) +* [FairFuzz](https://github.com/carolemieux/afl-rb) +* [Neuzz](https://github.com/Dongdongshe/neuzz) +* [Angora](https://github.com/AngoraFuzzer/Angora) + +A long list can be found at +[https://github.com/Microsvuln/Awesome-AFL](https://github.com/Microsvuln/Awesome-AFL). + +However, you can also sync AFL++ with honggfuzz, libfuzzer with `-entropic=1`, +etc. Just show the main fuzzer (-M) with the `-F` option where the queue/work +directory of a different fuzzer is, e.g. `-F /src/target/honggfuzz`. Using +honggfuzz (with `-n 1` or `-n 2`) and libfuzzer in parallel is highly recommended! #### c) Using multiple machines for fuzzing @@ -498,26 +501,24 @@ instance per server, and that its name is unique, hence the recommendation for `-M main-$HOSTNAME`. Now there are three strategies on how you can sync between the servers: - * never: sounds weird, but this makes every server an island and has the - chance the each follow different paths into the target. You can make - this even more interesting by even giving different seeds to each server. - * regularly (~4h): this ensures that all fuzzing campaigns on the servers - "see" the same thing. It is like fuzzing on a huge server. - * in intervals of 1/10th of the overall expected runtime of the fuzzing you - sync. This tries a bit to combine both. have some individuality of the - paths each campaign on a server explores, on the other hand if one - gets stuck where another found progress this is handed over making it - unstuck. - -The syncing process itself is very simple. -As the `-M main-$HOSTNAME` instance syncs to all `-S` secondaries as well -as to other fuzzers, you have to copy only this directory to the other -machines. - -Lets say all servers have the `-o out` directory in /target/foo/out, and -you created a file `servers.txt` which contains the hostnames of all -participating servers, plus you have an ssh key deployed to all of them, -then run: +* never: sounds weird, but this makes every server an island and has the chance + the each follow different paths into the target. You can make this even more + interesting by even giving different seeds to each server. +* regularly (~4h): this ensures that all fuzzing campaigns on the servers "see" + the same thing. It is like fuzzing on a huge server. +* in intervals of 1/10th of the overall expected runtime of the fuzzing you + sync. This tries a bit to combine both. have some individuality of the paths + each campaign on a server explores, on the other hand if one gets stuck where + another found progress this is handed over making it unstuck. + +The syncing process itself is very simple. As the `-M main-$HOSTNAME` instance +syncs to all `-S` secondaries as well as to other fuzzers, you have to copy only +this directory to the other machines. + +Lets say all servers have the `-o out` directory in /target/foo/out, and you +created a file `servers.txt` which contains the hostnames of all participating +servers, plus you have an ssh key deployed to all of them, then run: + ```bash for FROM in `cat servers.txt`; do for TO in `cat servers.txt`; do @@ -525,49 +526,52 @@ for FROM in `cat servers.txt`; do done done ``` -You can run this manually, per cron job - as you need it. -There is a more complex and configurable script in `utils/distributed_fuzzing`. + +You can run this manually, per cron job - as you need it. There is a more +complex and configurable script in `utils/distributed_fuzzing`. #### d) The status of the fuzz campaign AFL++ comes with the `afl-whatsup` script to show the status of the fuzzing campaign. -Just supply the directory that afl-fuzz is given with the -o option and -you will see a detailed status of every fuzzer in that campaign plus -a summary. +Just supply the directory that afl-fuzz is given with the -o option and you will +see a detailed status of every fuzzer in that campaign plus a summary. -To have only the summary use the `-s` switch e.g.: `afl-whatsup -s out/` +To have only the summary, use the `-s` switch, e.g. `afl-whatsup -s out/`. -If you have multiple servers then use the command after a sync, or you have -to execute this script per server. +If you have multiple servers, then use the command after a sync or you have to +execute this script per server. -Another tool to inspect the current state and history of a specific instance -is afl-plot, which generates an index.html file and a graphs that show how -the fuzzing instance is performing. -The syntax is `afl-plot instance_dir web_dir`, e.g. `afl-plot out/default /srv/www/htdocs/plot` +Another tool to inspect the current state and history of a specific instance is +afl-plot, which generates an index.html file and a graphs that show how the +fuzzing instance is performing. The syntax is `afl-plot instance_dir web_dir`, +e.g. `afl-plot out/default /srv/www/htdocs/plot`. #### e) Stopping fuzzing, restarting fuzzing, adding new seeds To stop an afl-fuzz run, simply press Control-C. -To restart an afl-fuzz run, just reuse the same command line but replace the -`-i directory` with `-i -` or set `AFL_AUTORESUME=1`. +To restart an afl-fuzz run, just reuse the same command line but replace the `-i +directory` with `-i -` or set `AFL_AUTORESUME=1`. If you want to add new seeds to a fuzzing campaign you can run a temporary -fuzzing instance, e.g. when your main fuzzer is using `-o out` and the new -seeds are in `newseeds/` directory: +fuzzing instance, e.g. when your main fuzzer is using `-o out` and the new seeds +are in `newseeds/` directory: + ``` AFL_BENCH_JUST_ONE=1 AFL_FAST_CAL=1 afl-fuzz -i newseeds -o out -S newseeds -- ./target ``` #### f) Checking the coverage of the fuzzing -The `paths found` value is a bad indicator for checking how good the coverage is. +The `paths found` value is a bad indicator for checking how good the coverage +is. A better indicator - if you use default llvm instrumentation with at least -version 9 - is to use `afl-showmap` with the collect coverage option `-C` on -the output directory: +version 9 - is to use `afl-showmap` with the collect coverage option `-C` on the +output directory: + ``` $ afl-showmap -C -i out -o /dev/null -- ./target -params @@ ... @@ -578,53 +582,67 @@ $ afl-showmap -C -i out -o /dev/null -- ./target -params @@ l'. [+] A coverage of 4331 edges were achieved out of 9960 existing (43.48%) with 7849 input files. ``` + It is even better to check out the exact lines of code that have been reached - and which have not been found so far. -An "easy" helper script for this is [https://github.com/vanhauser-thc/afl-cov](https://github.com/vanhauser-thc/afl-cov), +An "easy" helper script for this is +[https://github.com/vanhauser-thc/afl-cov](https://github.com/vanhauser-thc/afl-cov), just follow the README of that separate project. If you see that an important area or a feature has not been covered so far then try to find an input that is able to reach that and start a new secondary in that fuzzing campaign with that seed as input, let it run for a few minutes, then terminate it. The main node will pick it up and make it available to the -other secondary nodes over time. Set `export AFL_NO_AFFINITY=1` or -`export AFL_TRY_AFFINITY=1` if you have no free core. +other secondary nodes over time. Set `export AFL_NO_AFFINITY=1` or `export +AFL_TRY_AFFINITY=1` if you have no free core. Note that in nearly all cases you can never reach full coverage. A lot of -functionality is usually dependent on exclusive options that would need individual -fuzzing campaigns each with one of these options set. E.g. if you fuzz a library to -convert image formats and your target is the png to tiff API then you will not -touch any of the other library APIs and features. +functionality is usually dependent on exclusive options that would need +individual fuzzing campaigns each with one of these options set. E.g. if you +fuzz a library to convert image formats and your target is the png to tiff API +then you will not touch any of the other library APIs and features. #### g) How long to fuzz a target? -This is a difficult question. -Basically if no new path is found for a long time (e.g. for a day or a week) -then you can expect that your fuzzing won't be fruitful anymore. -However often this just means that you should switch out secondaries for -others, e.g. custom mutator modules, sync to very different fuzzers, etc. +This is a difficult question. Basically if no new path is found for a long time +(e.g. for a day or a week) then you can expect that your fuzzing won't be +fruitful anymore. However, often this just means that you should switch out +secondaries for others, e.g. custom mutator modules, sync to very different +fuzzers, etc. Keep the queue/ directory (for future fuzzings of the same or similar targets) -and use them to seed other good fuzzers like libfuzzer with the -entropic -switch or honggfuzz. +and use them to seed other good fuzzers like libfuzzer with the -entropic switch +or honggfuzz. #### h) Improve the speed! - * Use [persistent mode](../instrumentation/README.persistent_mode.md) (x2-x20 speed increase) - * If you do not use shmem persistent mode, use `AFL_TMPDIR` to point the input file on a tempfs location, see [env_variables.md](env_variables.md) - * Linux: Improve kernel performance: modify `/etc/default/grub`, set `GRUB_CMDLINE_LINUX_DEFAULT="ibpb=off ibrs=off kpti=off l1tf=off mds=off mitigations=off no_stf_barrier noibpb noibrs nopcid nopti nospec_store_bypass_disable nospectre_v1 nospectre_v2 pcid=off pti=off spec_store_bypass_disable=off spectre_v2=off stf_barrier=off"`; then `update-grub` and `reboot` (warning: makes the system more insecure) - you can also just run `sudo afl-persistent-config` - * Linux: Running on an `ext2` filesystem with `noatime` mount option will be a bit faster than on any other journaling filesystem - * Use your cores! [b) Using multiple cores](#b-using-multiple-cores) - * Run `sudo afl-system-config` before starting the first afl-fuzz instance after a reboot +* Use [persistent mode](../instrumentation/README.persistent_mode.md) (x2-x20 + speed increase) +* If you do not use shmem persistent mode, use `AFL_TMPDIR` to point the input + file on a tempfs location, see [env_variables.md](env_variables.md) +* Linux: Improve kernel performance: modify `/etc/default/grub`, set + `GRUB_CMDLINE_LINUX_DEFAULT="ibpb=off ibrs=off kpti=off l1tf=off mds=off + mitigations=off no_stf_barrier noibpb noibrs nopcid nopti + nospec_store_bypass_disable nospectre_v1 nospectre_v2 pcid=off pti=off + spec_store_bypass_disable=off spectre_v2=off stf_barrier=off"`; then + `update-grub` and `reboot` (warning: makes the system more insecure) - you can + also just run `sudo afl-persistent-config` +* Linux: Running on an `ext2` filesystem with `noatime` mount option will be a + bit faster than on any other journaling filesystem +* Use your cores! [b) Using multiple cores](#b-using-multiple-cores) +* Run `sudo afl-system-config` before starting the first afl-fuzz instance after + a reboot ### The End -Check out the [FAQ](FAQ.md) if it maybe answers your question (that -you might not even have known you had ;-) ). +Check out the [FAQ](FAQ.md) if it maybe answers your question (that you might +not even have known you had ;-) ). This is basically all you need to know to professionally run fuzzing campaigns. -If you want to know more, the tons of texts in [docs/](./) will have you covered. +If you want to know more, the tons of texts in [docs/](./) will have you +covered. Note that there are also a lot of tools out there that help fuzzing with AFL++ -(some might be deprecated or unsupported), see [third_party_tools.md](third_party_tools.md). \ No newline at end of file +(some might be deprecated or unsupported), see +[third_party_tools.md](third_party_tools.md). \ No newline at end of file diff --git a/docs/important_changes.md b/docs/important_changes.md index 0c5c2243..877dfab2 100644 --- a/docs/important_changes.md +++ b/docs/important_changes.md @@ -36,7 +36,7 @@ behaviours and defaults: shared libraries, etc. Additionally QEMU 5.1 supports more CPU targets so this is really worth it. * When instrumenting targets, afl-cc will not supersede optimizations anymore - if any were given. This allows to fuzz targets build regularly like those + if any were given. This allows to fuzz targets build regularly like those for debug or release versions. * afl-fuzz: * if neither -M or -S is specified, `-S default` is assumed, so more @@ -47,7 +47,7 @@ behaviours and defaults: * -m none is now default, set memory limits (in MB) with e.g. -m 250 * deterministic fuzzing is now disabled by default (unless using -M) and can be enabled with -D - * a caching of testcases can now be performed and can be modified by + * a caching of test cases can now be performed and can be modified by editing config.h for TESTCASE_CACHE or by specifying the env variable `AFL_TESTCACHE_SIZE` (in MB). Good values are between 50-500 (default: 50). * -M mains do not perform trimming diff --git a/docs/interpreting_output.md b/docs/interpreting_output.md deleted file mode 100644 index 4bd705f2..00000000 --- a/docs/interpreting_output.md +++ /dev/null @@ -1,71 +0,0 @@ -# Interpreting output - -See the [status_screen.md](status_screen.md) file for information on -how to interpret the displayed stats and monitor the health of the process. Be -sure to consult this file especially if any UI elements are highlighted in red. - -The fuzzing process will continue until you press Ctrl-C. At a minimum, you want -to allow the fuzzer to complete one queue cycle, which may take anywhere from a -couple of hours to a week or so. - -There are three subdirectories created within the output directory and updated -in real-time: - - - queue/ - test cases for every distinctive execution path, plus all the - starting files given by the user. This is the synthesized corpus - mentioned in section 2. - - Before using this corpus for any other purposes, you can shrink - it to a smaller size using the afl-cmin tool. The tool will find - a smaller subset of files offering equivalent edge coverage. - - - crashes/ - unique test cases that cause the tested program to receive a - fatal signal (e.g., SIGSEGV, SIGILL, SIGABRT). The entries are - grouped by the received signal. - - - hangs/ - unique test cases that cause the tested program to time out. The - default time limit before something is classified as a hang is - the larger of 1 second and the value of the -t parameter. - The value can be fine-tuned by setting AFL_HANG_TMOUT, but this - is rarely necessary. - -Crashes and hangs are considered "unique" if the associated execution paths -involve any state transitions not seen in previously-recorded faults. If a -single bug can be reached in multiple ways, there will be some count inflation -early in the process, but this should quickly taper off. - -The file names for crashes and hangs are correlated with the parent, non-faulting -queue entries. This should help with debugging. - -When you can't reproduce a crash found by afl-fuzz, the most likely cause is -that you are not setting the same memory limit as used by the tool. Try: - -```shell -LIMIT_MB=50 -( ulimit -Sv $[LIMIT_MB << 10]; /path/to/tested_binary ... ) -``` - -Change LIMIT_MB to match the -m parameter passed to afl-fuzz. On OpenBSD, -also change -Sv to -Sd. - -Any existing output directory can be also used to resume aborted jobs; try: - -```shell -./afl-fuzz -i- -o existing_output_dir [...etc...] -``` - -If you have gnuplot installed, you can also generate some pretty graphs for any -active fuzzing task using afl-plot. For an example of how this looks like, -see [https://lcamtuf.coredump.cx/afl/plot/](https://lcamtuf.coredump.cx/afl/plot/). - -You can also manually build and install afl-plot-ui, which is a helper utility -for showing the graphs generated by afl-plot in a graphical window using GTK. -You can build and install it as follows - -```shell -sudo apt install libgtk-3-0 libgtk-3-dev pkg-config -cd utils/plot_ui -make -cd ../../ -sudo make install -``` diff --git a/docs/status_screen.md b/docs/status_screen.md deleted file mode 100644 index b1cb9696..00000000 --- a/docs/status_screen.md +++ /dev/null @@ -1,444 +0,0 @@ -# Understanding the status screen - -This document provides an overview of the status screen - plus tips for -troubleshooting any warnings and red text shown in the UI. See README.md for -the general instruction manual. - -## A note about colors - -The status screen and error messages use colors to keep things readable and -attract your attention to the most important details. For example, red almost -always means "consult this doc" :-) - -Unfortunately, the UI will render correctly only if your terminal is using -traditional un*x palette (white text on black background) or something close -to that. - -If you are using inverse video, you may want to change your settings, say: - -- For GNOME Terminal, go to `Edit > Profile` preferences, select the "colors" tab, and from the list of built-in schemes, choose "white on black". -- For the MacOS X Terminal app, open a new window using the "Pro" scheme via the `Shell > New Window` menu (or make "Pro" your default). - -Alternatively, if you really like your current colors, you can edit config.h -to comment out USE_COLORS, then do `make clean all`. - -I'm not aware of any other simple way to make this work without causing -other side effects - sorry about that. - -With that out of the way, let's talk about what's actually on the screen... - -### The status bar - -``` -american fuzzy lop ++3.01a (default) [fast] {0} -``` - -The top line shows you which mode afl-fuzz is running in -(normal: "american fuzy lop", crash exploration mode: "peruvian rabbit mode") -and the version of AFL++. -Next to the version is the banner, which, if not set with -T by hand, will -either show the binary name being fuzzed, or the -M/-S main/secondary name for -parallel fuzzing. -Second to last is the power schedule mode being run (default: fast). -Finally, the last item is the CPU id. - -### Process timing - -``` - +----------------------------------------------------+ - | run time : 0 days, 8 hrs, 32 min, 43 sec | - | last new path : 0 days, 0 hrs, 6 min, 40 sec | - | last uniq crash : none seen yet | - | last uniq hang : 0 days, 1 hrs, 24 min, 32 sec | - +----------------------------------------------------+ -``` - -This section is fairly self-explanatory: it tells you how long the fuzzer has -been running and how much time has elapsed since its most recent finds. This is -broken down into "paths" (a shorthand for test cases that trigger new execution -patterns), crashes, and hangs. - -When it comes to timing: there is no hard rule, but most fuzzing jobs should be -expected to run for days or weeks; in fact, for a moderately complex project, the -first pass will probably take a day or so. Every now and then, some jobs -will be allowed to run for months. - -There's one important thing to watch out for: if the tool is not finding new -paths within several minutes of starting, you're probably not invoking the -target binary correctly and it never gets to parse the input files we're -throwing at it; another possible explanations are that the default memory limit -(`-m`) is too restrictive, and the program exits after failing to allocate a -buffer very early on; or that the input files are patently invalid and always -fail a basic header check. - -If there are no new paths showing up for a while, you will eventually see a big -red warning in this section, too :-) - -### Overall results - -``` - +-----------------------+ - | cycles done : 0 | - | total paths : 2095 | - | uniq crashes : 0 | - | uniq hangs : 19 | - +-----------------------+ -``` - -The first field in this section gives you the count of queue passes done so far - that is, the number of times the fuzzer went over all the interesting test -cases discovered so far, fuzzed them, and looped back to the very beginning. -Every fuzzing session should be allowed to complete at least one cycle; and -ideally, should run much longer than that. - -As noted earlier, the first pass can take a day or longer, so sit back and -relax. - -To help make the call on when to hit `Ctrl-C`, the cycle counter is color-coded. -It is shown in magenta during the first pass, progresses to yellow if new finds -are still being made in subsequent rounds, then blue when that ends - and -finally, turns green after the fuzzer hasn't been seeing any action for a -longer while. - -The remaining fields in this part of the screen should be pretty obvious: -there's the number of test cases ("paths") discovered so far, and the number of -unique faults. The test cases, crashes, and hangs can be explored in real-time -by browsing the output directory, as discussed in README.md. - -### Cycle progress - -``` - +-------------------------------------+ - | now processing : 1296 (61.86%) | - | paths timed out : 0 (0.00%) | - +-------------------------------------+ -``` - -This box tells you how far along the fuzzer is with the current queue cycle: it -shows the ID of the test case it is currently working on, plus the number of -inputs it decided to ditch because they were persistently timing out. - -The "*" suffix sometimes shown in the first line means that the currently -processed path is not "favored" (a property discussed later on). - -### Map coverage - -``` - +--------------------------------------+ - | map density : 10.15% / 29.07% | - | count coverage : 4.03 bits/tuple | - +--------------------------------------+ -``` - -The section provides some trivia about the coverage observed by the -instrumentation embedded in the target binary. - -The first line in the box tells you how many branch tuples we have already -hit, in proportion to how much the bitmap can hold. The number on the left -describes the current input; the one on the right is the value for the entire -input corpus. - -Be wary of extremes: - - - Absolute numbers below 200 or so suggest one of three things: that the - program is extremely simple; that it is not instrumented properly (e.g., - due to being linked against a non-instrumented copy of the target - library); or that it is bailing out prematurely on your input test cases. - The fuzzer will try to mark this in pink, just to make you aware. - - Percentages over 70% may very rarely happen with very complex programs - that make heavy use of template-generated code. - Because high bitmap density makes it harder for the fuzzer to reliably - discern new program states, I recommend recompiling the binary with - `AFL_INST_RATIO=10` or so and trying again (see env_variables.md). - The fuzzer will flag high percentages in red. Chances are, you will never - see that unless you're fuzzing extremely hairy software (say, v8, perl, - ffmpeg). - -The other line deals with the variability in tuple hit counts seen in the -binary. In essence, if every taken branch is always taken a fixed number of -times for all the inputs we have tried, this will read `1.00`. As we manage -to trigger other hit counts for every branch, the needle will start to move -toward `8.00` (every bit in the 8-bit map hit), but will probably never -reach that extreme. - -Together, the values can be useful for comparing the coverage of several -different fuzzing jobs that rely on the same instrumented binary. - -### Stage progress - -``` - +-------------------------------------+ - | now trying : interest 32/8 | - | stage execs : 3996/34.4k (11.62%) | - | total execs : 27.4M | - | exec speed : 891.7/sec | - +-------------------------------------+ -``` - -This part gives you an in-depth peek at what the fuzzer is actually doing right -now. It tells you about the current stage, which can be any of: - - - calibration - a pre-fuzzing stage where the execution path is examined - to detect anomalies, establish baseline execution speed, and so on. Executed - very briefly whenever a new find is being made. - - trim L/S - another pre-fuzzing stage where the test case is trimmed to the - shortest form that still produces the same execution path. The length (L) - and stepover (S) are chosen in general relationship to file size. - - bitflip L/S - deterministic bit flips. There are L bits toggled at any given - time, walking the input file with S-bit increments. The current L/S variants - are: `1/1`, `2/1`, `4/1`, `8/8`, `16/8`, `32/8`. - - arith L/8 - deterministic arithmetics. The fuzzer tries to subtract or add - small integers to 8-, 16-, and 32-bit values. The stepover is always 8 bits. - - interest L/8 - deterministic value overwrite. The fuzzer has a list of known - "interesting" 8-, 16-, and 32-bit values to try. The stepover is 8 bits. - - extras - deterministic injection of dictionary terms. This can be shown as - "user" or "auto", depending on whether the fuzzer is using a user-supplied - dictionary (`-x`) or an auto-created one. You will also see "over" or "insert", - depending on whether the dictionary words overwrite existing data or are - inserted by offsetting the remaining data to accommodate their length. - - havoc - a sort-of-fixed-length cycle with stacked random tweaks. The - operations attempted during this stage include bit flips, overwrites with - random and "interesting" integers, block deletion, block duplication, plus - assorted dictionary-related operations (if a dictionary is supplied in the - first place). - - splice - a last-resort strategy that kicks in after the first full queue - cycle with no new paths. It is equivalent to 'havoc', except that it first - splices together two random inputs from the queue at some arbitrarily - selected midpoint. - - sync - a stage used only when `-M` or `-S` is set (see parallel_fuzzing.md). - No real fuzzing is involved, but the tool scans the output from other - fuzzers and imports test cases as necessary. The first time this is done, - it may take several minutes or so. - -The remaining fields should be fairly self-evident: there's the exec count -progress indicator for the current stage, a global exec counter, and a -benchmark for the current program execution speed. This may fluctuate from -one test case to another, but the benchmark should be ideally over 500 execs/sec -most of the time - and if it stays below 100, the job will probably take very -long. - -The fuzzer will explicitly warn you about slow targets, too. If this happens, -see the [perf_tips.md](perf_tips.md) file included with the fuzzer for ideas on how to speed -things up. - -### Findings in depth - -``` - +--------------------------------------+ - | favored paths : 879 (41.96%) | - | new edges on : 423 (20.19%) | - | total crashes : 0 (0 unique) | - | total tmouts : 24 (19 unique) | - +--------------------------------------+ -``` - -This gives you several metrics that are of interest mostly to complete nerds. -The section includes the number of paths that the fuzzer likes the most based -on a minimization algorithm baked into the code (these will get considerably -more air time), and the number of test cases that actually resulted in better -edge coverage (versus just pushing the branch hit counters up). There are also -additional, more detailed counters for crashes and timeouts. - -Note that the timeout counter is somewhat different from the hang counter; this -one includes all test cases that exceeded the timeout, even if they did not -exceed it by a margin sufficient to be classified as hangs. - -### Fuzzing strategy yields - -``` - +-----------------------------------------------------+ - | bit flips : 57/289k, 18/289k, 18/288k | - | byte flips : 0/36.2k, 4/35.7k, 7/34.6k | - | arithmetics : 53/2.54M, 0/537k, 0/55.2k | - | known ints : 8/322k, 12/1.32M, 10/1.70M | - | dictionary : 9/52k, 1/53k, 1/24k | - |havoc/splice : 1903/20.0M, 0/0 | - |py/custom/rq : unused, 53/2.54M, unused | - | trim/eff : 20.31%/9201, 17.05% | - +-----------------------------------------------------+ -``` - -This is just another nerd-targeted section keeping track of how many paths we -have netted, in proportion to the number of execs attempted, for each of the -fuzzing strategies discussed earlier on. This serves to convincingly validate -assumptions about the usefulness of the various approaches taken by afl-fuzz. - -The trim strategy stats in this section are a bit different than the rest. -The first number in this line shows the ratio of bytes removed from the input -files; the second one corresponds to the number of execs needed to achieve this -goal. Finally, the third number shows the proportion of bytes that, although -not possible to remove, were deemed to have no effect and were excluded from -some of the more expensive deterministic fuzzing steps. - -Note that when deterministic mutation mode is off (which is the default -because it is not very efficient) the first five lines display -"disabled (default, enable with -D)". - -Only what is activated will have counter shown. - -### Path geometry - -``` - +---------------------+ - | levels : 5 | - | pending : 1570 | - | pend fav : 583 | - | own finds : 0 | - | imported : 0 | - | stability : 100.00% | - +---------------------+ -``` - -The first field in this section tracks the path depth reached through the -guided fuzzing process. In essence: the initial test cases supplied by the -user are considered "level 1". The test cases that can be derived from that -through traditional fuzzing are considered "level 2"; the ones derived by -using these as inputs to subsequent fuzzing rounds are "level 3"; and so forth. -The maximum depth is therefore a rough proxy for how much value you're getting -out of the instrumentation-guided approach taken by afl-fuzz. - -The next field shows you the number of inputs that have not gone through any -fuzzing yet. The same stat is also given for "favored" entries that the fuzzer -really wants to get to in this queue cycle (the non-favored entries may have to -wait a couple of cycles to get their chance). - -Next, we have the number of new paths found during this fuzzing section and -imported from other fuzzer instances when doing parallelized fuzzing; and the -extent to which identical inputs appear to sometimes produce variable behavior -in the tested binary. - -That last bit is actually fairly interesting: it measures the consistency of -observed traces. If a program always behaves the same for the same input data, -it will earn a score of 100%. When the value is lower but still shown in purple, -the fuzzing process is unlikely to be negatively affected. If it goes into red, -you may be in trouble, since AFL will have difficulty discerning between -meaningful and "phantom" effects of tweaking the input file. - -Now, most targets will just get a 100% score, but when you see lower figures, -there are several things to look at: - - - The use of uninitialized memory in conjunction with some intrinsic sources - of entropy in the tested binary. Harmless to AFL, but could be indicative - of a security bug. - - Attempts to manipulate persistent resources, such as left over temporary - files or shared memory objects. This is usually harmless, but you may want - to double-check to make sure the program isn't bailing out prematurely. - Running out of disk space, SHM handles, or other global resources can - trigger this, too. - - Hitting some functionality that is actually designed to behave randomly. - Generally harmless. For example, when fuzzing sqlite, an input like - `select random();` will trigger a variable execution path. - - Multiple threads executing at once in semi-random order. This is harmless - when the 'stability' metric stays over 90% or so, but can become an issue - if not. Here's what to try: - * Use afl-clang-fast from [instrumentation](../instrumentation/) - it uses a thread-local tracking - model that is less prone to concurrency issues, - * See if the target can be compiled or run without threads. Common - `./configure` options include `--without-threads`, `--disable-pthreads`, or - `--disable-openmp`. - * Replace pthreads with GNU Pth (https://www.gnu.org/software/pth/), which - allows you to use a deterministic scheduler. - - In persistent mode, minor drops in the "stability" metric can be normal, - because not all the code behaves identically when re-entered; but major - dips may signify that the code within `__AFL_LOOP()` is not behaving - correctly on subsequent iterations (e.g., due to incomplete clean-up or - reinitialization of the state) and that most of the fuzzing effort goes - to waste. - -The paths where variable behavior is detected are marked with a matching entry -in the `/queue/.state/variable_behavior/` directory, so you can look -them up easily. - -### CPU load - -``` - [cpu: 25%] -``` - -This tiny widget shows the apparent CPU utilization on the local system. It is -calculated by taking the number of processes in the "runnable" state, and then -comparing it to the number of logical cores on the system. - -If the value is shown in green, you are using fewer CPU cores than available on -your system and can probably parallelize to improve performance; for tips on -how to do that, see parallel_fuzzing.md. - -If the value is shown in red, your CPU is *possibly* oversubscribed, and -running additional fuzzers may not give you any benefits. - -Of course, this benchmark is very simplistic; it tells you how many processes -are ready to run, but not how resource-hungry they may be. It also doesn't -distinguish between physical cores, logical cores, and virtualized CPUs; the -performance characteristics of each of these will differ quite a bit. - -If you want a more accurate measurement, you can run the `afl-gotcpu` utility from the command line. - -### Addendum: status and plot files - -For unattended operation, some of the key status screen information can be also -found in a machine-readable format in the fuzzer_stats file in the output -directory. This includes: - - - `start_time` - unix time indicating the start time of afl-fuzz - - `last_update` - unix time corresponding to the last update of this file - - `run_time` - run time in seconds to the last update of this file - - `fuzzer_pid` - PID of the fuzzer process - - `cycles_done` - queue cycles completed so far - - `cycles_wo_finds` - number of cycles without any new paths found - - `execs_done` - number of execve() calls attempted - - `execs_per_sec` - overall number of execs per second - - `paths_total` - total number of entries in the queue - - `paths_favored` - number of queue entries that are favored - - `paths_found` - number of entries discovered through local fuzzing - - `paths_imported` - number of entries imported from other instances - - `max_depth` - number of levels in the generated data set - - `cur_path` - currently processed entry number - - `pending_favs` - number of favored entries still waiting to be fuzzed - - `pending_total` - number of all entries waiting to be fuzzed - - `variable_paths` - number of test cases showing variable behavior - - `stability` - percentage of bitmap bytes that behave consistently - - `bitmap_cvg` - percentage of edge coverage found in the map so far - - `unique_crashes` - number of unique crashes recorded - - `unique_hangs` - number of unique hangs encountered - - `last_path` - seconds since the last path was found - - `last_crash` - seconds since the last crash was found - - `last_hang` - seconds since the last hang was found - - `execs_since_crash` - execs since the last crash was found - - `exec_timeout` - the -t command line value - - `slowest_exec_ms` - real time of the slowest execution in ms - - `peak_rss_mb` - max rss usage reached during fuzzing in MB - - `edges_found` - how many edges have been found - - `var_byte_count` - how many edges are non-deterministic - - `afl_banner` - banner text (e.g. the target name) - - `afl_version` - the version of AFL used - - `target_mode` - default, persistent, qemu, unicorn, non-instrumented - - `command_line` - full command line used for the fuzzing session - -Most of these map directly to the UI elements discussed earlier on. - -On top of that, you can also find an entry called `plot_data`, containing a -plottable history for most of these fields. If you have gnuplot installed, you -can turn this into a nice progress report with the included `afl-plot` tool. - - -### Addendum: Automatically send metrics with StatsD - -In a CI environment or when running multiple fuzzers, it can be tedious to -log into each of them or deploy scripts to read the fuzzer statistics. -Using `AFL_STATSD` (and the other related environment variables `AFL_STATSD_HOST`, -`AFL_STATSD_PORT`, `AFL_STATSD_TAGS_FLAVOR`) you can automatically send metrics -to your favorite StatsD server. Depending on your StatsD server you will be able -to monitor, trigger alerts or perform actions based on these metrics (e.g: alert on -slow exec/s for a new build, threshold of crashes, time since last crash > X, etc). - -The selected metrics are a subset of all the metrics found in the status and in -the plot file. The list is the following: `cycle_done`, `cycles_wo_finds`, -`execs_done`,`execs_per_sec`, `paths_total`, `paths_favored`, `paths_found`, -`paths_imported`, `max_depth`, `cur_path`, `pending_favs`, `pending_total`, -`variable_paths`, `unique_crashes`, `unique_hangs`, `total_crashes`, -`slowest_exec_ms`, `edges_found`, `var_byte_count`, `havoc_expansion`. -Their definitions can be found in the addendum above. - -When using multiple fuzzer instances with StatsD it is *strongly* recommended to setup -the flavor (AFL_STATSD_TAGS_FLAVOR) to match your StatsD server. This will allow you -to see individual fuzzer performance, detect bad ones, see the progress of each -strategy... diff --git a/docs/third_party_tools.md b/docs/third_party_tools.md index ba96d0ce..446d373c 100644 --- a/docs/third_party_tools.md +++ b/docs/third_party_tools.md @@ -1,12 +1,12 @@ # Tools that help fuzzing with AFL++ Speeding up fuzzing: - * [libfiowrapper](https://github.com/marekzmyslowski/libfiowrapper) - if the function you want to fuzz requires loading a file, this allows using the shared memory testcase feature :-) - recommended. + * [libfiowrapper](https://github.com/marekzmyslowski/libfiowrapper) - if the function you want to fuzz requires loading a file, this allows using the shared memory test case feature :-) - recommended. Minimization of test cases: * [afl-pytmin](https://github.com/ilsani/afl-pytmin) - a wrapper for afl-tmin that tries to speed up the process of minimization of a single test case by using many CPU cores. - * [afl-ddmin-mod](https://github.com/MarkusTeufelberger/afl-ddmin-mod) - a variation of afl-tmin based on the ddmin algorithm. - * [halfempty](https://github.com/googleprojectzero/halfempty) - is a fast utility for minimizing test cases by Tavis Ormandy based on parallelization. + * [afl-ddmin-mod](https://github.com/MarkusTeufelberger/afl-ddmin-mod) - a variation of afl-tmin based on the ddmin algorithm. + * [halfempty](https://github.com/googleprojectzero/halfempty) - is a fast utility for minimizing test cases by Tavis Ormandy based on parallelization. Distributed execution: * [disfuzz-afl](https://github.com/MartijnB/disfuzz-afl) - distributed fuzzing for AFL. diff --git a/qemu_mode/libqasan/README.md b/qemu_mode/libqasan/README.md index 4a241233..6a65c12b 100644 --- a/qemu_mode/libqasan/README.md +++ b/qemu_mode/libqasan/README.md @@ -19,7 +19,7 @@ finding capabilities during fuzzing) is WIP. ### When should I use QASan? If your target binary is PIC x86_64, you should also give a try to -[retrowrite](https://github.com/HexHive/retrowrite) for static rewriting. +[RetroWrite](https://github.com/HexHive/retrowrite) for static rewriting. If it fails, or if your binary is for another architecture, or you want to use persistent and snapshot mode, AFL++ QASan mode is what you want/have to use. diff --git a/unicorn_mode/samples/persistent/COMPILE.md b/unicorn_mode/samples/persistent/COMPILE.md index 111dfc54..9f2ae718 100644 --- a/unicorn_mode/samples/persistent/COMPILE.md +++ b/unicorn_mode/samples/persistent/COMPILE.md @@ -1,13 +1,16 @@ # C Sample This shows a simple persistent harness for unicornafl in C. -In contrast to the normal c harness, this harness manually resets the unicorn state on each new input. -Thanks to this, we can rerun the testcase in unicorn multiple times, without the need to fork again. +In contrast to the normal c harness, this harness manually resets the unicorn +state on each new input. +Thanks to this, we can rerun the test case in unicorn multiple times, without +the need to fork again. ## Compiling sample.c The target can be built using the `make` command. Just make sure you have built unicorn support first: + ```bash cd /path/to/afl/unicorn_mode ./build_unicorn_support.sh @@ -19,6 +22,7 @@ You don't need to compile persistent_target.c since a X86_64 binary version is pre-built and shipped in this sample folder. This file documents how the binary was built in case you want to rebuild it or recompile it for any reason. -The pre-built binary (persistent_target_x86_64.bin) was built using -g -O0 in gcc. +The pre-built binary (persistent_target_x86_64.bin) was built using -g -O0 in +gcc. -We then load the binary and we execute the main function directly. +We then load the binary and we execute the main function directly. \ No newline at end of file diff --git a/utils/aflpp_driver/README.md b/utils/aflpp_driver/README.md index 30e2412f..4560be2b 100644 --- a/utils/aflpp_driver/README.md +++ b/utils/aflpp_driver/README.md @@ -7,15 +7,15 @@ targets. Just do `afl-clang-fast++ -o fuzz fuzzer_harness.cc libAFLDriver.a [plus required linking]`. -You can also sneakily do this little trick: +You can also sneakily do this little trick: If this is the clang compile command to build for libfuzzer: `clang++ -o fuzz -fsanitize=fuzzer fuzzer_harness.cc -lfoo` then just switch `clang++` with `afl-clang-fast++` and our compiler will magically insert libAFLDriver.a :) -To use shared-memory testcases, you need nothing to do. -To use stdin testcases give `-` as the only command line parameter. -To use file input testcases give `@@` as the only command line parameter. +To use shared-memory test cases, you need nothing to do. +To use stdin test cases, give `-` as the only command line parameter. +To use file input test cases, give `@@` as the only command line parameter. IMPORTANT: if you use `afl-cmin` or `afl-cmin.bash` then either pass `-` or `@@` as command line parameters. @@ -30,8 +30,8 @@ are to be fuzzed in qemu_mode. So we compile them with clang/clang++, without `clang++ -o fuzz fuzzer_harness.cc libAFLQemuDriver.a [plus required linking]`. - Then just do (where the name of the binary is `fuzz`): + ``` AFL_QEMU_PERSISTENT_ADDR=0x$(nm fuzz | grep "T LLVMFuzzerTestOneInput" | awk '{print $1}') AFL_QEMU_PERSISTENT_HOOK=/path/to/aflpp_qemu_driver_hook.so afl-fuzz -Q ... -- ./fuzz` @@ -40,4 +40,4 @@ AFL_QEMU_PERSISTENT_HOOK=/path/to/aflpp_qemu_driver_hook.so afl-fuzz -Q ... -- . if you use afl-cmin or `afl-showmap -C` with the aflpp_qemu_driver you need to set the set same AFL_QEMU_... (or AFL_FRIDA_...) environment variables. If you want to use afl-showmap (without -C) or afl-cmin.bash then you may not -set these environment variables and rather set `AFL_QEMU_DRIVER_NO_HOOK=1`. +set these environment variables and rather set `AFL_QEMU_DRIVER_NO_HOOK=1`. \ No newline at end of file -- cgit 1.4.1 From 1a57253a1c63315b5af8fdbe5081492ce0603278 Mon Sep 17 00:00:00 2001 From: llzmb <46303940+llzmb@users.noreply.github.com> Date: Thu, 25 Nov 2021 16:33:29 +0100 Subject: Edit QEMU mode READMEs --- qemu_mode/README.md | 221 +++++++++++++++++++++-------------------- qemu_mode/README.persistent.md | 141 +++++++++++++------------- qemu_mode/README.wine.md | 30 +++--- 3 files changed, 203 insertions(+), 189 deletions(-) (limited to 'qemu_mode') diff --git a/qemu_mode/README.md b/qemu_mode/README.md index d28479d9..4ade93d7 100644 --- a/qemu_mode/README.md +++ b/qemu_mode/README.md @@ -1,172 +1,180 @@ # High-performance binary-only instrumentation for afl-fuzz - (See ../README.md for the general instruction manual.) +For the general instruction manual, see [README.md](../README.md). ## 1) Introduction The code in this directory allows you to build a standalone feature that leverages the QEMU "user emulation" mode and allows callers to obtain -instrumentation output for black-box, closed-source binaries. This mechanism -can be then used by afl-fuzz to stress-test targets that couldn't be built -with afl-gcc. +instrumentation output for black-box, closed-source binaries. This mechanism can +be then used by afl-fuzz to stress-test targets that couldn't be built with +afl-gcc. -The usual performance cost is 2-5x, which is considerably better than -seen so far in experiments with tools such as DynamoRIO and PIN. +The usual performance cost is 2-5x, which is considerably better than seen so +far in experiments with tools such as DynamoRIO and PIN. -The idea and much of the initial implementation comes from Andrew Griffiths. -The actual implementation on current QEMU (shipped as qemuafl) is from -Andrea Fioraldi. Special thanks to abiondo that re-enabled TCG chaining. +The idea and much of the initial implementation comes from Andrew Griffiths. The +actual implementation on current QEMU (shipped as qemuafl) is from Andrea +Fioraldi. Special thanks to abiondo that re-enabled TCG chaining. -## 2) How to use qemu_mode +## 2) How to use QEMU mode -The feature is implemented with a patched QEMU. The simplest way -to build it is to run ./build_qemu_support.sh. The script will download, -configure, and compile the QEMU binary for you. +The feature is implemented with a patched QEMU. The simplest way to build it is +to run ./build_qemu_support.sh. The script will download, configure, and compile +the QEMU binary for you. -QEMU is a big project, so this will take a while, and you may have to -resolve a couple of dependencies (most notably, you will definitely need -libtool and glib2-devel). +QEMU is a big project, so this will take a while, and you may have to resolve a +couple of dependencies (most notably, you will definitely need libtool and +glib2-devel). Once the binaries are compiled, you can leverage the QEMU tool by calling -afl-fuzz and all the related utilities with -Q in the command line. +afl-fuzz and all the related utilities with `-Q` in the command line. -Note that QEMU requires a generous memory limit to run; somewhere around -200 MB is a good starting point, but considerably more may be needed for -more complex programs. The default -m limit will be automatically bumped up -to 200 MB when specifying -Q to afl-fuzz; be careful when overriding this. +Note that QEMU requires a generous memory limit to run; somewhere around 200 MB +is a good starting point, but considerably more may be needed for more complex +programs. The default `-m` limit will be automatically bumped up to 200 MB when +specifying `-Q` to afl-fuzz; be careful when overriding this. -In principle, if you set CPU_TARGET before calling ./build_qemu_support.sh, -you should get a build capable of running non-native binaries (say, you -can try CPU_TARGET=arm). This is also necessary for running 32-bit binaries -on a 64-bit system (CPU_TARGET=i386). If you're trying to run QEMU on a -different architecture you can also set HOST to the cross-compiler prefix -to use (for example HOST=arm-linux-gnueabi to use arm-linux-gnueabi-gcc). +In principle, if you set `CPU_TARGET` before calling ./build_qemu_support.sh, +you should get a build capable of running non-native binaries (say, you can try +`CPU_TARGET=arm`). This is also necessary for running 32-bit binaries on a +64-bit system (`CPU_TARGET=i386`). If you're trying to run QEMU on a different +architecture, you can also set `HOST` to the cross-compiler prefix to use (for +example `HOST=arm-linux-gnueabi` to use arm-linux-gnueabi-gcc). -You can also compile statically-linked binaries by setting STATIC=1. This -can be useful when compiling QEMU on a different system than the one you're -planning to run the fuzzer on and is most often used with the HOST variable. +You can also compile statically-linked binaries by setting `STATIC=1`. This can +be useful when compiling QEMU on a different system than the one you're planning +to run the fuzzer on and is most often used with the `HOST` variable. -Note: when targetting the i386 architecture, on some binaries the forkserver -handshake may fail due to the lack of reserved memory. Fix it with +Note: when targeting the i386 architecture, on some binaries the forkserver +handshake may fail due to the lack of reserved memory. Fix it with: +``` export QEMU_RESERVED_VA=0x1000000 +``` -Note: if you want the QEMU helper to be installed on your system for all -users, you need to build it before issuing 'make install' in the parent -directory. +Note: if you want the QEMU helper to be installed on your system for all users, +you need to build it before issuing `make install` in the parent directory. -If you want to specify a different path for libraries (e.g. to run an arm64 -binary on x86_64) use QEMU_LD_PREFIX. +If you want to specify a different path for libraries (e.g., to run an arm64 +binary on x86_64) use `QEMU_LD_PREFIX`. ## 3) Deferred initialization -As for LLVM mode (refer to its README.md for mode details) QEMU mode supports -the deferred initialization. +As for LLVM mode (refer to +[instrumentation/README.llvm.md](../instrumentation/README.llvm.md) for mode +details), QEMU mode supports the deferred initialization. -This can be enabled setting the environment variable AFL_ENTRYPOINT which allows -to move the forkserver to a different part, e.g. just before the file is -opened (e.g. way after command line parsing and config file loading, etc.) +This can be enabled by setting the environment variable `AFL_ENTRYPOINT` which +allows to move the forkserver to a different part, e.g., just before the file is +opened (e.g., way after command line parsing and config file loading, etc.) which can be a huge speed improvement. ## 4) Persistent mode -AFL++'s QEMU mode now supports also persistent mode for x86, x86_64, arm -and aarch64 targets. -This increases the speed by several factors, however it is a bit of work to set -up - but worth the effort. +AFL++'s QEMU mode now supports also persistent mode for x86, x86_64, arm, and +aarch64 targets. This increases the speed by several factors, however, it is a +bit of work to set up - but worth the effort. -Please see the extra documentation for it: [README.persistent.md](README.persistent.md) +For more information, see [README.persistent.md](README.persistent.md). ## 5) Snapshot mode As an extension to persistent mode, qemuafl can snapshot and restore the memory -state and brk(). Details are in the persistent mode readme. +state and brk(). For details, see [README.persistent.md](README.persistent.md). -The env var that enables the ready to use snapshot mode is AFL_QEMU_SNAPSHOT and -takes a hex address as a value that is the snapshot entrypoint. +The env var that enables the ready to use snapshot mode is `AFL_QEMU_SNAPSHOT` +and takes a hex address as a value that is the snapshot entry point. -Snapshot mode can work restoring all the writeable pages, that is typically slower than -fork() mode but, on the other hand, it can scale better with multicore. -If the AFL++ Snapshot kernel module is loaded, qemuafl will use it and, in this -case, the speed is better than fork() and also the scaling capabilities. +Snapshot mode can work restoring all the writeable pages, that is typically +slower than fork() mode but, on the other hand, it can scale better with +multicore. If the AFL++ snapshot kernel module is loaded, qemuafl will use it +and, in this case, the speed is better than fork() and also the scaling +capabilities. ## 6) Partial instrumentation You can tell QEMU to instrument only a part of the address space. -Just set AFL_QEMU_INST_RANGES=A,B,C... +Just set `AFL_QEMU_INST_RANGES=A,B,C...`. -The format of the items in the list is either a range of addresses like 0x123-0x321 -or a module name like module.so (that is matched in the mapped object filename). +The format of the items in the list is either a range of addresses like +0x123-0x321 or a module name like module.so (that is matched in the mapped +object filename). -Alternatively you can tell QEMU to ignore part of an address space for instrumentation. +Alternatively, you can tell QEMU to ignore part of an address space for +instrumentation. -Just set AFL_QEMU_EXCLUDE_RANGES=A,B,C... +Just set `AFL_QEMU_EXCLUDE_RANGES=A,B,C...`. -The format of the items on the list is the same as for AFL_QEMU_INST_RANGES, and excluding ranges -takes priority over any included ranges or AFL_INST_LIBS. +The format of the items on the list is the same as for `AFL_QEMU_INST_RANGES` +and excluding ranges takes priority over any included ranges or `AFL_INST_LIBS`. ## 7) CompareCoverage CompareCoverage is a sub-instrumentation with effects similar to laf-intel. -You have to set `AFL_PRELOAD=/path/to/libcompcov.so` together with -setting the AFL_COMPCOV_LEVEL you want to enable it. +You have to set `AFL_PRELOAD=/path/to/libcompcov.so` together with setting the +`AFL_COMPCOV_LEVEL` you want to enable it. -AFL_COMPCOV_LEVEL=1 is to instrument comparisons with only immediate -values / read-only memory. +`AFL_COMPCOV_LEVEL=1` is to instrument comparisons with only immediate +values/read-only memory. -AFL_COMPCOV_LEVEL=2 instruments all comparison instructions and memory +`AFL_COMPCOV_LEVEL=2` instruments all comparison instructions and memory comparison functions when libcompcov is preloaded. -AFL_COMPCOV_LEVEL=3 has the same effects of AFL_COMPCOV_LEVEL=2 but enables +`AFL_COMPCOV_LEVEL=3` has the same effects of `AFL_COMPCOV_LEVEL=2` but enables also the instrumentation of the floating-point comparisons on x86 and x86_64 (experimental). -Integer comparison instructions are currently instrumented only -on the x86, x86_64, arm and aarch64 targets. +Integer comparison instructions are currently instrumented only on the x86, +x86_64, arm, and aarch64 targets. Recommended, but not as good as CMPLOG mode (see below). ## 8) CMPLOG mode -Another new feature is CMPLOG, which is based on the redqueen project. -Here all immediates in CMP instructions are learned and put into a dynamic -dictionary and applied to all locations in the input that reached that -CMP, trying to solve and pass it. -This is a very effective feature and it is available for x86, x86_64, arm -and aarch64. +Another new feature is CMPLOG, which is based on the redqueen project. Here all +immediates in CMP instructions are learned and put into a dynamic dictionary and +applied to all locations in the input that reached that CMP, trying to solve and +pass it. This is a very effective feature and it is available for x86, x86_64, +arm, and aarch64. -To enable it you must pass on the command line of afl-fuzz: - -c /path/to/your/target +To enable it, you must pass on the command line of afl-fuzz: + +``` +-c /path/to/your/target +``` ## 9) Wine mode -AFL++ QEMU can use Wine to fuzz Win32 PE binaries. Use the -W flag of afl-fuzz. +AFL++ QEMU can use Wine to fuzz Win32 PE binaries. Use the `-W` flag of +afl-fuzz. -Note that some binaries require user interaction with the GUI and must be patched. +Note that some binaries require user interaction with the GUI and must be +patched. -For examples look [here](https://github.com/andreafioraldi/WineAFLplusplusDEMO). +For examples, look +[here](https://github.com/andreafioraldi/WineAFLplusplusDEMO). ## 10) Notes on linking -The feature is supported only on Linux. Supporting BSD may amount to porting -the changes made to linux-user/elfload.c and applying them to -bsd-user/elfload.c, but I have not looked into this yet. +The feature is supported only on Linux. Supporting BSD may amount to porting the +changes made to linux-user/elfload.c and applying them to bsd-user/elfload.c, +but I have not looked into this yet. The instrumentation follows only the .text section of the first ELF binary encountered in the linking process. It does not trace shared libraries. In practice, this means two things: - - Any libraries you want to analyze *must* be linked statically into the - executed ELF file (this will usually be the case for closed-source - apps). +- Any libraries you want to analyze *must* be linked statically into the + executed ELF file (this will usually be the case for closed-source apps). - - Standard C libraries and other stuff that is wasteful to instrument - should be linked dynamically - otherwise, AFL will have no way to avoid - peeking into them. +- Standard C libraries and other stuff that is wasteful to instrument should be + linked dynamically - otherwise, AFL++ will have no way to avoid peeking into + them. -Setting AFL_INST_LIBS=1 can be used to circumvent the .text detection logic +Setting `AFL_INST_LIBS=1` can be used to circumvent the .text detection logic and instrument every basic block encountered. ## 11) Benchmarking @@ -177,8 +185,10 @@ non-instrumented binary with the same optimization flags that are normally injected by afl-gcc, and make sure that the bits to be tested are statically linked into the binary. A common way to do this would be: +``` CFLAGS="-O3 -funroll-loops" ./configure --disable-shared make clean all +``` Comparative measurements of execution speed or instrumentation coverage will be fairly meaningless if the optimization levels or instrumentation scopes don't @@ -186,36 +196,37 @@ match. ## 12) Other features -With `AFL_QEMU_FORCE_DFL` you force QEMU to ignore the registered signal +With `AFL_QEMU_FORCE_DFL`, you force QEMU to ignore the registered signal handlers of the target. ## 13) Gotchas, feedback, bugs If you need to fix up checksums or do other cleanups on mutated test cases, see -`afl_custom_post_process` in custom_mutators/examples/example.c for a viable solution. +`afl_custom_post_process` in custom_mutators/examples/example.c for a viable +solution. -Do not mix QEMU mode with ASAN, MSAN, or the likes; QEMU doesn't appreciate -the "shadow VM" trick employed by the sanitizers and will probably just -run out of memory. +Do not mix QEMU mode with ASAN, MSAN, or the likes; QEMU doesn't appreciate the +"shadow VM" trick employed by the sanitizers and will probably just run out of +memory. Compared to fully-fledged virtualization, the user emulation mode is *NOT* a security boundary. The binaries can freely interact with the host OS. If you somehow need to fuzz an untrusted binary, put everything in a sandbox first. -QEMU does not necessarily support all CPU or hardware features that your -target program may be utilizing. In particular, it does not appear to have -full support for AVX2 / FMA3. Using binaries for older CPUs, or recompiling them -with -march=core2, can help. +QEMU does not necessarily support all CPU or hardware features that your target +program may be utilizing. In particular, it does not appear to have full support +for AVX2/FMA3. Using binaries for older CPUs or recompiling them with +`-march=core2`, can help. Beyond that, this is an early-stage mechanism, so fields reports are welcome. You can send them to . ## 14) Alternatives: static rewriting -Statically rewriting binaries just once, instead of attempting to translate -them at run time, can be a faster alternative. That said, static rewriting is -fraught with peril, because it depends on being able to properly and fully model -program control flow without actually executing each and every code path. +Statically rewriting binaries just once, instead of attempting to translate them +at run time, can be a faster alternative. That said, static rewriting is fraught +with peril, because it depends on being able to properly and fully model program +control flow without actually executing each and every code path. -Checkout the "Fuzzing binary-only targets" section in our main README.md and -the docs/binaryonly_fuzzing.md document for more information and hints. +For more information and hints, check out +[docs/fuzzing_binary-only_targets.md](../docs/fuzzing_binary-only_targets.md). \ No newline at end of file diff --git a/qemu_mode/README.persistent.md b/qemu_mode/README.persistent.md index 2ca5c873..7210a8cc 100644 --- a/qemu_mode/README.persistent.md +++ b/qemu_mode/README.persistent.md @@ -2,118 +2,118 @@ ## 1) Introduction -Persistent mode lets you fuzz your target persistently between two -addresses - without forking for every fuzzing attempt. -This increases the speed by a factor between x2 and x5, hence it is -very, very valuable. +Persistent mode lets you fuzz your target persistently between two addresses - +without forking for every fuzzing attempt. This increases the speed by a factor +between x2 and x5, hence it is very, very valuable. -The persistent mode is currently only available for x86/x86_64, arm -and aarch64 targets. +The persistent mode is currently only available for x86/x86_64, arm, and aarch64 +targets. ## 2) How use the persistent mode ### 2.1) The START address -The start of the persistent loop has to be set with env var AFL_QEMU_PERSISTENT_ADDR. +The start of the persistent loop has to be set with environment variable +`AFL_QEMU_PERSISTENT_ADDR`. -This address can be the address of whatever instruction. -Setting this address to the start of a function makes the usage simple. -If the address is however within a function, either RET, OFFSET or EXITS -(see below in 2.2, 2.3, 2.6) have to be set. -This address (as well as the RET address, see below) has to be defined in +This address can be the address of whatever instruction. Setting this address to +the start of a function makes the usage simple. If the address is however within +a function, either RET, OFFSET, or EXITS (see below in 2.2, 2.3, 2.6) have to be +set. This address (as well as the RET address, see below) has to be defined in hexadecimal with the 0x prefix or as a decimal value. If both RET and EXITS are not set, QEMU will assume that START points to a -function and will patch the return address (on stack or in the link register) -to return to START (like WinAFL). +function and will patch the return address (on stack or in the link register) to +return to START (like WinAFL). -*Note:* If the target is compiled with position independant code (PIE/PIC) -qemu loads these to a specific base address. -For 64 bit you have to add 0x4000000000 (9 zeroes) and for 32 bit 0x40000000 -(7 zeroes) to the address. -On strange setups the base address set by QEMU for PIE executable may change, -you can check it printing the process map using -`AFL_QEMU_DEBUG_MAPS=1 afl-qemu-trace TARGET-BINARY` +*Note:* If the target is compiled with position independent code (PIE/PIC) qemu +loads these to a specific base address. For 64 bit you have to add 0x4000000000 +(9 zeroes) and for 32 bit 0x40000000 (7 zeroes) to the address. On strange +setups the base address set by QEMU for PIE executable may change. You can check +it printing the process map using `AFL_QEMU_DEBUG_MAPS=1 afl-qemu-trace +TARGET-BINARY`. If this address is not valid, afl-fuzz will error during startup with the message that the forkserver was not found. ### 2.2) The RET address -The RET address is the last instruction of the persistent loop. -The emulator will emit a jump to START when translating the instruction at RET. -It is optional, and only needed if the return should not be -at the end of the function to which the START address points into, but earlier. +The RET address is the last instruction of the persistent loop. The emulator +will emit a jump to START when translating the instruction at RET. It is +optional and only needed if the return should not be at the end of the function +to which the START address points into, but earlier. -It is defined by setting AFL_QEMU_PERSISTENT_RET, and too 0x4000000000 has to -be set if the target is position independant. +It is defined by setting `AFL_QEMU_PERSISTENT_RET`, and too 0x4000000000 has to +be set if the target is position independent. ### 2.3) The OFFSET This option is valid only for x86/x86_64 only, arm/aarch64 do not save the return address on stack. -If the START address is *not* the beginning of a function, and *no* RET has -been set (so the end of the loop will be at the end of the function but START -will not be at the beginning of it), we need an offset from the ESP pointer -to locate the return address to patch. +If the START address is *not* the beginning of a function, and *no* RET has been +set (so the end of the loop will be at the end of the function but START will +not be at the beginning of it), we need an offset from the ESP pointer to locate +the return address to patch. The value by which the ESP pointer has to be corrected has to be set in the -variable AFL_QEMU_PERSISTENT_RETADDR_OFFSET. +variable `AFL_QEMU_PERSISTENT_RETADDR_OFFSET`. Now to get this value right here is some help: -1. use gdb on the target -2. set a breakpoint to "main" (this is required for PIE/PIC binaries so the - addresses are set up) -3. "run" the target with a valid commandline -4. set a breakpoint to the function in which START is contained -5. set a breakpoint to your START address -6. "continue" to the function start breakpoint -6. print the ESP value with `print $esp` and take note of it -7. "continue" the target until the second breakpoint -8. again print the ESP value -9. calculate the difference between the two values - and this is the offset +1. Use gdb on the target. +2. Set a breakpoint to "main" (this is required for PIE/PIC binaries so the + addresses are set up). +3. "run" the target with a valid commandline. +4. Set a breakpoint to the function in which START is contained. +5. Set a breakpoint to your START address. +6. "continue" to the function start breakpoint. +7. Print the ESP value with `print $esp` and take note of it. +8. "continue" the target until the second breakpoint. +9. Again print the ESP value. +10. Calculate the difference between the two values - and this is the offset. ### 2.4) Resetting the register state It is very, very likely you need to restore the general purpose registers state when starting a new loop. Because of this 99% of the time you should set +``` AFL_QEMU_PERSISTENT_GPR=1 +``` -An example is when you want to use main() as persistent START: +An example is when you want to use `main()` as persistent START: ```c int main(int argc, char **argv) { if (argc < 2) return 1; - + // do stuff } ``` -If you don't save and restore the registers in x86_64, the parameter `argc` -will be lost at the second execution of the loop. +If you don't save and restore the registers in x86_64, the parameter `argc` will +be lost at the second execution of the loop. ### 2.5) Resetting the memory state This option restores the memory state using the AFL++ Snapshot LKM if loaded. Otherwise, all the writeable pages are restored. -To enable this option, set AFL_QEMU_PERSISTENT_MEM=1. +To enable this option, set `AFL_QEMU_PERSISTENT_MEM=1`. ### 2.6) Reset on exit() The user can force QEMU to set the program counter to START instead of executing the exit_group syscall and exit the program. -The env variable is AFL_QEMU_PERSISTENT_EXITS. +The environment variable is `AFL_QEMU_PERSISTENT_EXITS`. ### 2.7) Snapshot -AFL_QEMU_SNAPSHOT=address is just a "syntactical sugar" env variable that is equivalent to -the following set of variables: +`AFL_QEMU_SNAPSHOT=address` is just a "syntactical sugar" environment variable +that is equivalent to the following set of variables: ``` AFL_QEMU_PERSISTENT_ADDR=address @@ -127,26 +127,27 @@ AFL_QEMU_PERSISTENT_EXITS=1 ### 3.1) Loop counter value The more stable your loop in the target, the longer you can run it, the more -unstable it is the lower the loop count should be. A low value would be 100, -the maximum value should be 10000. The default is 1000. -This value can be set with AFL_QEMU_PERSISTENT_CNT +unstable it is the lower the loop count should be. A low value would be 100, the +maximum value should be 10000. The default is 1000. This value can be set with +`AFL_QEMU_PERSISTENT_CNT`. -This is the same concept as in the llvm_mode persistent mode with __AFL_LOOP(). +This is the same concept as in the llvm_mode persistent mode with +`__AFL_LOOP()`. ### 3.2) A hook for in-memory fuzzing -You can increase the speed of the persistent mode even more by bypassing all -the reading of the fuzzing input via a file by reading directly into the -memory address space of the target process. +You can increase the speed of the persistent mode even more by bypassing all the +reading of the fuzzing input via a file by reading directly into the memory +address space of the target process. All this needs is that the START address has a register that can reach the -memory buffer or that the memory buffer is at a known location. You probably need -the value of the size of the buffer (maybe it is in a register when START is -hit). +memory buffer or that the memory buffer is at a known location. You probably +need the value of the size of the buffer (maybe it is in a register when START +is hit). -The persistent hook will execute a function on every persistent iteration -(at the start START) defined in a shared object specified with -AFL_QEMU_PERSISTENT_HOOK=/path/to/hook.so. +The persistent hook will execute a function on every persistent iteration (at +the start START) defined in a shared object specified with +`AFL_QEMU_PERSISTENT_HOOK=/path/to/hook.so`. The signature is: @@ -157,8 +158,8 @@ void afl_persistent_hook(struct ARCH_regs *regs, uint32_t input_buf_len); ``` -Where ARCH is one of x86, x86_64, arm or arm64. -You have to include `path/to/qemuafl/qemuafl/api.h`. +Where ARCH is one of x86, x86_64, arm or arm64. You have to include +`path/to/qemuafl/qemuafl/api.h`. In this hook, you can inspect and change the saved GPR state at START. @@ -168,8 +169,8 @@ with: `int afl_persistent_hook_init(void);` If this routine returns true, the shared mem fuzzing feature of AFL++ is used -and so the input_buf variables of the hook becomes meaningful. Otherwise, -you have to read the input from a file like stdin. +and so the input_buf variables of the hook becomes meaningful. Otherwise, you +have to read the input from a file like stdin. -An example that you can use with little modification for your target can -be found here: [utils/qemu_persistent_hook](../utils/qemu_persistent_hook) +An example that you can use with little modification for your target can be +found here: [utils/qemu_persistent_hook](../utils/qemu_persistent_hook) \ No newline at end of file diff --git a/qemu_mode/README.wine.md b/qemu_mode/README.wine.md index 567901cd..ee1ef58a 100644 --- a/qemu_mode/README.wine.md +++ b/qemu_mode/README.wine.md @@ -1,21 +1,23 @@ # How to troubleshoot AFL++'s wine mode ## 1) Debugging -To turn on wine debugging use the `WINEDEBUG` environment variable, -e.g. `WINEDEBUG=+timestamp,+tid,+loaddll`. + +To turn on wine debugging, use the `WINEDEBUG` environment variable, e.g., +`WINEDEBUG=+timestamp,+tid,+loaddll`. ## 2) LoadLibraryA workaround -The forked process fails to load libraries loaded via `LoadLibrary` -if the load happens after the entry point (error code: 87). To resolve -this issue, one needs to load any external libraries before the fork happens. -An early DLL load can be achieved by adding the DLL name into the `Import Directory` -in the PE file. Such an entry can be added manually in any PE editor. +The forked process fails to load libraries loaded via `LoadLibrary` if the load +happens after the entry point (error code: 87). To resolve this issue, one needs +to load any external libraries before the fork happens. + +An early DLL load can be achieved by adding the DLL name into the `Import +Directory` in the PE file. Such an entry can be added manually in any PE editor. -Alternativly, one can generate a `.lib` file from the DLL exports and link -them together with the harness to create an entry in the `Import Directory`. -Use `dumpbin /exports .dll` to extract the exports and paste the -exported function names into a `.def` file. Use `lib /def: /OUT:` -to generate a `.lib` and add the library to the linker options. Once the usage of -an export is detected (`__declspec(dllimport)`), the -linker adds the early DLL load. \ No newline at end of file +Alternatively, one can generate a `.lib` file from the DLL exports and link them +together with the harness to create an entry in the `Import Directory`. Use +`dumpbin /exports .dll` to extract the exports and paste the exported +function names into a `.def` file. Use `lib /def: /OUT:` to +generate a `.lib` and add the library to the linker options. Once the usage of +an export is detected (`__declspec(dllimport)`), the linker adds the early DLL +load. \ No newline at end of file -- cgit 1.4.1 From f2ff029cc25e81fec36abd0b8c676f1dd6a39c77 Mon Sep 17 00:00:00 2001 From: llzmb <46303940+llzmb@users.noreply.github.com> Date: Tue, 30 Nov 2021 20:17:58 +0100 Subject: Edit QEMU mode README.md --- qemu_mode/README.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'qemu_mode') diff --git a/qemu_mode/README.md b/qemu_mode/README.md index 4ade93d7..b4b5e7bf 100644 --- a/qemu_mode/README.md +++ b/qemu_mode/README.md @@ -8,7 +8,7 @@ The code in this directory allows you to build a standalone feature that leverages the QEMU "user emulation" mode and allows callers to obtain instrumentation output for black-box, closed-source binaries. This mechanism can be then used by afl-fuzz to stress-test targets that couldn't be built with -afl-gcc. +afl-cc. The usual performance cost is 2-5x, which is considerably better than seen so far in experiments with tools such as DynamoRIO and PIN. @@ -180,10 +180,10 @@ and instrument every basic block encountered. ## 11) Benchmarking If you want to compare the performance of the QEMU instrumentation with that of -afl-gcc compiled code against the same target, you need to build the +afl-clang-fast compiled code against the same target, you need to build the non-instrumented binary with the same optimization flags that are normally -injected by afl-gcc, and make sure that the bits to be tested are statically -linked into the binary. A common way to do this would be: +injected by afl-clang-fast, and make sure that the bits to be tested are +statically linked into the binary. A common way to do this would be: ``` CFLAGS="-O3 -funroll-loops" ./configure --disable-shared -- cgit 1.4.1 From d9e39be4e8dd0242877412d1a17589acc825292e Mon Sep 17 00:00:00 2001 From: llzmb <46303940+llzmb@users.noreply.github.com> Date: Thu, 2 Dec 2021 16:49:16 +0100 Subject: Remove the word "simply" --- custom_mutators/gramatron/README.md | 6 +++--- docs/env_variables.md | 10 +++++----- docs/fuzzing_binary-only_targets.md | 3 +-- docs/fuzzing_in_depth.md | 10 +++++----- frida_mode/DEBUGGING.md | 6 +++--- frida_mode/MapDensity.md | 14 +++++++------- frida_mode/README.md | 10 +++++----- frida_mode/Scripting.md | 2 +- instrumentation/README.llvm.md | 4 ++-- qemu_mode/libcompcov/README.md | 6 +++--- utils/libtokencap/README.md | 8 ++++---- 11 files changed, 39 insertions(+), 40 deletions(-) (limited to 'qemu_mode') diff --git a/custom_mutators/gramatron/README.md b/custom_mutators/gramatron/README.md index 91f93355..c8a76e3e 100644 --- a/custom_mutators/gramatron/README.md +++ b/custom_mutators/gramatron/README.md @@ -5,11 +5,11 @@ grammar-aware fuzzing. Technical details about our framework are available in the [ISSTA'21 paper](https://nebelwelt.net/files/21ISSTA.pdf). The artifact to reproduce the experiments presented in the paper are present in `artifact/`. Instructions to run a sample campaign and incorporate new -grammars is presented below: +grammars is presented below: # Compiling -Simply execute `./build_gramatron_mutator.sh` +Execute `./build_gramatron_mutator.sh` # Running @@ -25,7 +25,7 @@ afl-fuzz -i in -o out -- ./target # Adding and testing a new grammar -- Specify in a JSON format for CFG. Examples are correspond `source.json` files +- Specify in a JSON format for CFG. Examples are correspond `source.json` files - Run the automaton generation script (in `src/gramfuzz-mutator/preprocess`) which will place the generated automaton in the same folder. ``` diff --git a/docs/env_variables.md b/docs/env_variables.md index c1c70ec5..6f6110ae 100644 --- a/docs/env_variables.md +++ b/docs/env_variables.md @@ -59,9 +59,9 @@ fairly broad use of environment variables instead: otherwise. - By default, the wrapper appends `-O3` to optimize builds. Very rarely, this - will cause problems in programs built with -Werror, simply because `-O3` - enables more thorough code analysis and can spew out additional warnings. To - disable optimizations, set `AFL_DONT_OPTIMIZE`. However, if `-O...` and/or + will cause problems in programs built with -Werror, because `-O3` enables + more thorough code analysis and can spew out additional warnings. To disable + optimizations, set `AFL_DONT_OPTIMIZE`. However, if `-O...` and/or `-fno-unroll-loops` are set, these are not overridden. - Setting `AFL_HARDEN` automatically adds code hardening options when invoking @@ -651,8 +651,8 @@ call back into FRIDA to find the next block. Default is 32. * `AFL_FRIDA_STATS_FILE` - Write statistics information about the code being instrumented to the given file name. The statistics are written only for the child process when new block is instrumented (when the -`AFL_FRIDA_STATS_INTERVAL` has expired). Note that simply because a new path is -found does not mean a new block needs to be compiled. It could simply be that +`AFL_FRIDA_STATS_INTERVAL` has expired). Note that just because a new path is +found does not mean a new block needs to be compiled. It could be that the existing blocks instrumented have been executed in a different order. * `AFL_FRIDA_STATS_INTERVAL` - The maximum frequency to output statistics information. Stats will be written whenever they are updated if the given diff --git a/docs/fuzzing_binary-only_targets.md b/docs/fuzzing_binary-only_targets.md index 290c9bec..2d57d0dc 100644 --- a/docs/fuzzing_binary-only_targets.md +++ b/docs/fuzzing_binary-only_targets.md @@ -129,8 +129,7 @@ Unicorn is a fork of QEMU. The instrumentation is, therefore, very similar. In contrast to QEMU, Unicorn does not offer a full system or even userland emulation. Runtime environment and/or loaders have to be written from scratch, if needed. On top, block chaining has been removed. This means the speed boost -introduced in the patched QEMU Mode of AFL++ cannot simply be ported over to -Unicorn. +introduced in the patched QEMU Mode of AFL++ cannot be ported over to Unicorn. For non-Linux binaries, you can use AFL++'s unicorn_mode which can emulate anything you want - for the price of speed and user written scripts. diff --git a/docs/fuzzing_in_depth.md b/docs/fuzzing_in_depth.md index 251bbc1d..7aabe090 100644 --- a/docs/fuzzing_in_depth.md +++ b/docs/fuzzing_in_depth.md @@ -427,8 +427,8 @@ It can be valuable to run afl-fuzz in a screen or tmux shell so you can log off, or afl-fuzz is not aborted if you are running it in a remote ssh session where the connection fails in between. Only do that though once you have verified that your fuzzing setup works! -Simply run it like `screen -dmS afl-main -- afl-fuzz -M main-$HOSTNAME -i ...` -and it will start away in a screen session. To enter this session simply type +Run it like `screen -dmS afl-main -- afl-fuzz -M main-$HOSTNAME -i ...` +and it will start away in a screen session. To enter this session, type `screen -r afl-main`. You see - it makes sense to name the screen session same as the afl-fuzz -M/-S naming :-) For more information on screen or tmux please check their documentation. @@ -457,7 +457,7 @@ handling in the target. Play around with various -m values until you find one that safely works for all your input seeds (if you have good ones and then double or quadruple that. -By default afl-fuzz never stops fuzzing. To terminate AFL++ simply press +By default afl-fuzz never stops fuzzing. To terminate AFL++, press Control-C or send a signal SIGINT. You can limit the number of executions or approximate runtime in seconds with options also. @@ -554,7 +554,7 @@ recommended! ### d) Using multiple machines for fuzzing Maybe you have more than one machine you want to fuzz the same target on. -Simply start the `afl-fuzz` (and perhaps libfuzzer, honggfuzz, ...) +Start the `afl-fuzz` (and perhaps libfuzzer, honggfuzz, ...) orchestra as you like, just ensure that your have one and only one `-M` instance per server, and that its name is unique, hence the recommendation for `-M main-$HOSTNAME`. @@ -609,7 +609,7 @@ e.g., `afl-plot out/default /srv/www/htdocs/plot`. ### f) Stopping fuzzing, restarting fuzzing, adding new seeds -To stop an afl-fuzz run, simply press Control-C. +To stop an afl-fuzz run, press Control-C. To restart an afl-fuzz run, just reuse the same command line but replace the `-i directory` with `-i -` or set `AFL_AUTORESUME=1`. diff --git a/frida_mode/DEBUGGING.md b/frida_mode/DEBUGGING.md index 9cdc5eb6..b703ae43 100644 --- a/frida_mode/DEBUGGING.md +++ b/frida_mode/DEBUGGING.md @@ -160,9 +160,9 @@ Lastly, if your defect only occurs when using `afl-fuzz` (e.g., when using shared memory mapping being created for it to record its data), it is possible to enable the creation of a core dump for post-mortem analysis. -Firstly, check if your `/proc/sys/kernel/core_pattern` configuration is simply -set to a filename (AFL++ encourages you to set it to the value `core` in any -case since it doesn't want any handler applications getting in the way). +Firstly, check if your `/proc/sys/kernel/core_pattern` configuration is set to a +filename (AFL++ encourages you to set it to the value `core` in any case since +it doesn't want any handler applications getting in the way). Next, set `ulimit -c unlimited` to remove any size limitations for core files. diff --git a/frida_mode/MapDensity.md b/frida_mode/MapDensity.md index b6a96ca0..50f2720f 100644 --- a/frida_mode/MapDensity.md +++ b/frida_mode/MapDensity.md @@ -77,13 +77,13 @@ evenly distributed. We start with a large address and need to discard a large number of the bits to generate a block ID which is within range. But how do we choose the unique bits of the address versus those which are the same for every block? The high bits of -the address may simply be all `0s` or all `1s` to make the address canonical, -the middle portion of the address may be the same for all blocks (since if they -are all within the same binary, then they will all be adjacent in memory), and -on some systems, even the low bits may have poor entropy as some use fixed -length aligned instructions. Then we need to consider that a portion of each -binary may contain the `.data` or `.bss` sections and so may not contain any -blocks of code at all. +the address may be all `0s` or all `1s` to make the address canonical, the +middle portion of the address may be the same for all blocks (since if they are +all within the same binary, then they will all be adjacent in memory), and on +some systems, even the low bits may have poor entropy as some use fixed length +aligned instructions. Then we need to consider that a portion of each binary may +contain the `.data` or `.bss` sections and so may not contain any blocks of code +at all. ### Edge IDs diff --git a/frida_mode/README.md b/frida_mode/README.md index c19280e1..c2b98473 100644 --- a/frida_mode/README.md +++ b/frida_mode/README.md @@ -229,9 +229,9 @@ instances run CMPLOG mode and instrumentation of the binary is less frequent * `AFL_FRIDA_STATS_FILE` - Write statistics information about the code being instrumented to the given file name. The statistics are written only for the child process when new block is instrumented (when the - `AFL_FRIDA_STATS_INTERVAL` has expired). Note that simply because a new path - is found does not mean a new block needs to be compiled. It could simply be - that the existing blocks instrumented have been executed in a different order. + `AFL_FRIDA_STATS_INTERVAL` has expired). Note that just because a new path is + found does not mean a new block needs to be compiled. It could be that the + existing blocks instrumented have been executed in a different order. ``` stats @@ -359,8 +359,8 @@ An example of how to fuzz a dynamic library on OSX is included, see [test/osx-lib](test/osx-lib). This requires the use of a simple test harness executable which will load the library and call a target function within it. The dependent library can either be loaded in using `dlopen` and `dlsym` in a -function marked `__attribute__((constructor()))` or the test harness can simply -be linked against it. It is important that the target library is loaded before +function marked `__attribute__((constructor()))` or the test harness can be +linked against it. It is important that the target library is loaded before execution of `main`, since this is the point where FRIDA mode is initialized. Otherwise, it will not be possible to configure coverage for the test library using `AFL_FRIDA_INST_RANGES` or similar. diff --git a/frida_mode/Scripting.md b/frida_mode/Scripting.md index fcf8a490..fd4282db 100644 --- a/frida_mode/Scripting.md +++ b/frida_mode/Scripting.md @@ -511,7 +511,7 @@ int main(int argc, char **argv) { ``` There are a couple of obstacles with our target application. Unlike when fuzzing -source code, though, we can't simply edit it and recompile it. The following +source code, though, we can't just edit it and recompile it. The following script shows how we can use the normal functionality of FRIDA to modify any troublesome behavior. diff --git a/instrumentation/README.llvm.md b/instrumentation/README.llvm.md index 88ea0127..35f38261 100644 --- a/instrumentation/README.llvm.md +++ b/instrumentation/README.llvm.md @@ -126,8 +126,8 @@ Then there are different ways of instrumenting the target: 1. An better instrumentation strategy uses LTO and link time instrumentation. Note that not all targets can compile in this mode, however if it works it is - the best option you can use. Simply use afl-clang-lto/afl-clang-lto++ to use - this option. See [README.lto.md](README.lto.md). + the best option you can use. To go with this option, use + afl-clang-lto/afl-clang-lto++. See [README.lto.md](README.lto.md). 2. Alternatively you can choose a completely different coverage method: diff --git a/qemu_mode/libcompcov/README.md b/qemu_mode/libcompcov/README.md index fca20a69..6a72f5ff 100644 --- a/qemu_mode/libcompcov/README.md +++ b/qemu_mode/libcompcov/README.md @@ -23,7 +23,7 @@ To use this library make sure to preload it with AFL_PRELOAD. ``` export AFL_PRELOAD=/path/to/libcompcov.so export AFL_COMPCOV_LEVEL=1 - + afl-fuzz -Q -i input -o output -- ``` @@ -33,5 +33,5 @@ logs all the comparisons. The library make use of https://github.com/ouadev/proc_maps_parser and so it is Linux specific. However this is not a strict dependency, other UNIX operating -systems can be supported simply replacing the code related to the -/proc/self/maps parsing. +systems can be supported by replacing the code related to the +/proc/self/maps parsing. \ No newline at end of file diff --git a/utils/libtokencap/README.md b/utils/libtokencap/README.md index a39ed3a5..91ebebd1 100644 --- a/utils/libtokencap/README.md +++ b/utils/libtokencap/README.md @@ -40,10 +40,10 @@ when using afl-gcc. This setting specifically adds the following flags: -fno-builtin-strcasestr ``` -The next step is simply loading this library via LD_PRELOAD. The optimal usage -pattern is to allow afl-fuzz to fuzz normally for a while and build up a corpus, -and then fire off the target binary, with libtokencap.so loaded, on every file -found by AFL in that earlier run. This demonstrates the basic principle: +The next step is to load this library via LD_PRELOAD. The optimal usage pattern +is to allow afl-fuzz to fuzz normally for a while and build up a corpus, and +then fire off the target binary, with libtokencap.so loaded, on every file found +by AFL in that earlier run. This demonstrates the basic principle: ``` export AFL_TOKEN_FILE=$PWD/temp_output.txt -- cgit 1.4.1 From 7a8e4018a59fdabef395ca730d6e73f95e8daaed Mon Sep 17 00:00:00 2001 From: llzmb <46303940+llzmb@users.noreply.github.com> Date: Thu, 2 Dec 2021 17:13:12 +0100 Subject: Change the word "env var" to "environment variable" --- docs/env_variables.md | 2 +- docs/features.md | 4 ++-- docs/important_changes.md | 5 +++-- qemu_mode/README.md | 5 +++-- utils/qbdi_mode/README.md | 6 ++++-- 5 files changed, 13 insertions(+), 9 deletions(-) (limited to 'qemu_mode') diff --git a/docs/env_variables.md b/docs/env_variables.md index ec9b2b01..6c90e84c 100644 --- a/docs/env_variables.md +++ b/docs/env_variables.md @@ -564,7 +564,7 @@ The QEMU wrapper used to instrument binary-only code supports several settings: general purpose registers and restore them in each persistent cycle. - Another modality to execute the persistent loop is to specify also the - `AFL_QEMU_PERSISTENT_RET=end addr` env variable. With this variable + `AFL_QEMU_PERSISTENT_RET=end addr` environment variable. With this variable assigned, instead of patching the return address, the specified instruction is transformed to a jump towards `start addr`. diff --git a/docs/features.md b/docs/features.md index 35a869a9..fb688a64 100644 --- a/docs/features.md +++ b/docs/features.md @@ -19,8 +19,8 @@ QEMU 5.1 with laf-intel and redqueen, frida mode, unicorn mode, gcc plugin, full | Snapshot LKM Support | | (x)(8) | (x)(8) | | (x)(5) | | | | Shared Memory Test cases | | x | x | x86[_64]/arm64 | x | x | | -1. default for LLVM >= 9.0, env var for older version due an efficiency bug in - previous llvm versions +1. default for LLVM >= 9.0, environment variable for older version due an + efficiency bug in previous llvm versions 2. GCC creates non-performant code, hence it is disabled in gcc_plugin 3. with `AFL_LLVM_THREADSAFE_INST`, disables NeverZero 4. with pcguard mode and LTO mode for LLVM 11 and newer diff --git a/docs/important_changes.md b/docs/important_changes.md index 9d6bbbbe..726de64d 100644 --- a/docs/important_changes.md +++ b/docs/important_changes.md @@ -48,8 +48,9 @@ behaviors and defaults: * deterministic fuzzing is now disabled by default (unless using -M) and can be enabled with -D * a caching of test cases can now be performed and can be modified by - editing config.h for TESTCASE_CACHE or by specifying the env variable - `AFL_TESTCACHE_SIZE` (in MB). Good values are between 50-500 (default: 50). + editing config.h for TESTCASE_CACHE or by specifying the environment + variable `AFL_TESTCACHE_SIZE` (in MB). Good values are between 50-500 + (default: 50). * -M mains do not perform trimming * examples/ got renamed to utils/ * libtokencap/ libdislocator/ and qdbi_mode/ were moved to utils/ diff --git a/qemu_mode/README.md b/qemu_mode/README.md index b4b5e7bf..8e04cbf9 100644 --- a/qemu_mode/README.md +++ b/qemu_mode/README.md @@ -83,8 +83,9 @@ For more information, see [README.persistent.md](README.persistent.md). As an extension to persistent mode, qemuafl can snapshot and restore the memory state and brk(). For details, see [README.persistent.md](README.persistent.md). -The env var that enables the ready to use snapshot mode is `AFL_QEMU_SNAPSHOT` -and takes a hex address as a value that is the snapshot entry point. +The environment variable that enables the ready to use snapshot mode is +`AFL_QEMU_SNAPSHOT` and takes a hex address as a value that is the snapshot +entry point. Snapshot mode can work restoring all the writeable pages, that is typically slower than fork() mode but, on the other hand, it can scale better with diff --git a/utils/qbdi_mode/README.md b/utils/qbdi_mode/README.md index 8b768906..2e8b01d4 100755 --- a/utils/qbdi_mode/README.md +++ b/utils/qbdi_mode/README.md @@ -34,7 +34,9 @@ For x86 standalone-toolchain ./build/tools/make_standalone_toolchain.py --arch x86 --api 21 --install-dir ../android-standalone-toolchain-x86 ``` -In alternative you can also use the prebuilt toolchain, in that case make sure to set the proper CC and CXX env variables because there are many different compilers for each API version in the prebuilt toolchain. +In alternative you can also use the prebuilt toolchain, in that case make sure +to set the proper CC and CXX environment variables because there are many +different compilers for each API version in the prebuilt toolchain. For example: @@ -64,7 +66,7 @@ cd android-qbdi-sdk-x86_64/ tar xvf QBDI-0.7.0-android-X86_64.tar.gz ``` -Now set the `STANDALONE_TOOLCHAIN_PATH` to the path of standalone-toolchain +Now set the `STANDALONE_TOOLCHAIN_PATH` to the path of standalone-toolchain ``` export STANDALONE_TOOLCHAIN_PATH=/home/hac425/workspace/android-standalone-toolchain-x86_64 -- cgit 1.4.1 From a7694e299a331bd8c4826b2402ee68cd6f83d8f9 Mon Sep 17 00:00:00 2001 From: llzmb <46303940+llzmb@users.noreply.github.com> Date: Thu, 2 Dec 2021 20:45:48 +0100 Subject: Fix punctuation in connection with "however" --- docs/FAQ.md | 10 +++++++--- docs/best_practices.md | 27 ++++++++++++++++++--------- docs/custom_mutators.md | 10 +++++----- docs/fuzzing_in_depth.md | 10 +++++----- docs/important_changes.md | 4 ++-- instrumentation/README.llvm.md | 11 ++++++----- qemu_mode/README.persistent.md | 8 ++++---- qemu_mode/libcompcov/README.md | 8 ++++---- utils/afl_network_proxy/README.md | 13 +++++++------ utils/afl_untracer/README.md | 6 +++--- 10 files changed, 61 insertions(+), 46 deletions(-) (limited to 'qemu_mode') diff --git a/docs/FAQ.md b/docs/FAQ.md index ae4a77dc..49444999 100644 --- a/docs/FAQ.md +++ b/docs/FAQ.md @@ -12,7 +12,9 @@ If you find an interesting or important question missing, submit it via American Fuzzy Lop (AFL) was developed by Michał "lcamtuf" Zalewski starting in 2013/2014, and when he left Google end of 2017 he stopped developing it. - At the end of 2019, the Google fuzzing team took over maintenance of AFL, however it is only accepting PRs from the community and is not developing enhancements anymore. + At the end of 2019, the Google fuzzing team took over maintenance of AFL, + however, it is only accepting PRs from the community and is not developing + enhancements anymore. In the second quarter of 2019, 1 1/2 years later, when no further development of AFL had happened and it became clear there would none be coming, AFL++ was born, where initially community patches were collected and applied for bug fixes and enhancements. Then from various AFL spin-offs - mostly academic research - features were integrated. @@ -121,8 +123,10 @@ If you find an interesting or important question missing, submit it via Sending the same input again and again should take the exact same path through the target every time. If that is the case, the stability is 100%. - If however randomness happens, e.g. a thread reading other external data, reaction to timing, etc., then in some of the re-executions with the same data the edge coverage result will be different accross runs. - Those edges that change are then flagged "unstable". + If, however, randomness happens, e.g. a thread reading other external data, + reaction to timing, etc., then in some of the re-executions with the same data + the edge coverage result will be different accross runs. Those edges that + change are then flagged "unstable". The more "unstable" edges, the more difficult for AFL++ to identify valid new paths. diff --git a/docs/best_practices.md b/docs/best_practices.md index 979849f4..15f8870c 100644 --- a/docs/best_practices.md +++ b/docs/best_practices.md @@ -54,9 +54,11 @@ to emulate the network. This is also much faster than the real network would be. See [utils/socket_fuzzing/](../utils/socket_fuzzing/). There is an outdated AFL++ branch that implements networking if you are -desperate though: [https://github.com/AFLplusplus/AFLplusplus/tree/networking](https://github.com/AFLplusplus/AFLplusplus/tree/networking) - -however a better option is AFLnet ([https://github.com/aflnet/aflnet](https://github.com/aflnet/aflnet)) -which allows you to define network state with different type of data packets. +desperate though: +[https://github.com/AFLplusplus/AFLplusplus/tree/networking](https://github.com/AFLplusplus/AFLplusplus/tree/networking) +- however, a better option is AFLnet +([https://github.com/aflnet/aflnet](https://github.com/aflnet/aflnet)) which +allows you to define network state with different type of data packets. ## Improvements @@ -72,13 +74,16 @@ which allows you to define network state with different type of data packets. ### Improving stability -For fuzzing a 100% stable target that covers all edges is the best case. -A 90% stable target that covers all edges is however better than a 100% stable target that ignores 10% of the edges. +For fuzzing a 100% stable target that covers all edges is the best case. A 90% +stable target that covers all edges is, however, better than a 100% stable +target that ignores 10% of the edges. With instability, you basically have a partial coverage loss on an edge, with ignored functions you have a full loss on that edges. -There are functions that are unstable, but also provide value to coverage, e.g., init functions that use fuzz data as input. -If however a function that has nothing to do with the input data is the source of instability, e.g., checking jitter, or is a hash map function etc., then it should not be instrumented. +There are functions that are unstable, but also provide value to coverage, e.g., +init functions that use fuzz data as input. If, however, a function that has +nothing to do with the input data is the source of instability, e.g., checking +jitter, or is a hash map function etc., then it should not be instrumented. To be able to exclude these functions (based on AFL++'s measured stability), the following process will allow to identify functions with variable edges. @@ -116,8 +121,12 @@ Four steps are required to do this and it also requires quite some knowledge of If `PCGUARD` is used, then you need to follow this guide (needs llvm 12+!): [https://clang.llvm.org/docs/SanitizerCoverage.html#partially-disabling-instrumentation](https://clang.llvm.org/docs/SanitizerCoverage.html#partially-disabling-instrumentation) - Only exclude those functions from instrumentation that provide no value for coverage - that is if it does not process any fuzz data directly or indirectly (e.g. hash maps, thread management etc.). - If however a function directly or indirectly handles fuzz data, then you should not put the function in a deny instrumentation list and rather live with the instability it comes with. + Only exclude those functions from instrumentation that provide no value for + coverage - that is if it does not process any fuzz data directly or + indirectly (e.g. hash maps, thread management etc.). If, however, a + function directly or indirectly handles fuzz data, then you should not put + the function in a deny instrumentation list and rather live with the + instability it comes with. 4. Recompile the target diff --git a/docs/custom_mutators.md b/docs/custom_mutators.md index 4018d633..fc5ecbf9 100644 --- a/docs/custom_mutators.md +++ b/docs/custom_mutators.md @@ -112,11 +112,11 @@ def deinit(): # optional for Python - `fuzz_count` (optional): - When a queue entry is selected to be fuzzed, afl-fuzz selects the number - of fuzzing attempts with this input based on a few factors. - If however the custom mutator wants to set this number instead on how often - it is called for a specific queue entry, use this function. - This function is most useful if `AFL_CUSTOM_MUTATOR_ONLY` is **not** used. + When a queue entry is selected to be fuzzed, afl-fuzz selects the number of + fuzzing attempts with this input based on a few factors. If, however, the + custom mutator wants to set this number instead on how often it is called + for a specific queue entry, use this function. This function is most useful + if `AFL_CUSTOM_MUTATOR_ONLY` is **not** used. - `fuzz` (optional): diff --git a/docs/fuzzing_in_depth.md b/docs/fuzzing_in_depth.md index 92b3cf86..96e709ab 100644 --- a/docs/fuzzing_in_depth.md +++ b/docs/fuzzing_in_depth.md @@ -131,8 +131,8 @@ The following options are available when you instrument with LTO mode have to compile the target twice, once specifically with/for this mode by setting `AFL_LLVM_CMPLOG=1`, and pass this binary to afl-fuzz via the `-c` parameter. Note that you can compile also just a cmplog binary and use that - for both however there will be a performance penality. You can read more about - this in + for both, however, there will be a performance penality. You can read more + about this in [instrumentation/README.cmplog.md](../instrumentation/README.cmplog.md). If you use LTO, LLVM or GCC_PLUGIN mode @@ -151,7 +151,7 @@ only instrument parts of the target that you are interested in: inlined and then would not match! See [instrumentation/README.instrument_list.md](../instrumentation/README.instrument_list.md) -There are many more options and modes available however these are most of the +There are many more options and modes available, however, these are most of the time less effective. See: * [instrumentation/README.ctx.md](../instrumentation/README.ctx.md) * [instrumentation/README.ngram.md](../instrumentation/README.ngram.md) @@ -369,8 +369,8 @@ This step is highly recommended! ### c) Minimizing all corpus files The shorter the input files that still traverse the same path within the target, -the better the fuzzing will be. This minimization is done with `afl-tmin` -however it is a long process as this has to be done for every file: +the better the fuzzing will be. This minimization is done with `afl-tmin`, +however, it is a long process as this has to be done for every file: ``` mkdir input diff --git a/docs/important_changes.md b/docs/important_changes.md index 726de64d..6cd00791 100644 --- a/docs/important_changes.md +++ b/docs/important_changes.md @@ -15,8 +15,8 @@ With AFL++ 3.15 we introduced the following changes from previous behaviors: With AFL++ 3.14 we introduced the following changes from previous behaviors: * afl-fuzz: deterministic fuzzing it not a default for -M main anymore - * afl-cmin/afl-showmap -i now descends into subdirectories (afl-cmin.bash - however does not) + * afl-cmin/afl-showmap -i now descends into subdirectories (afl-cmin.bash, + however, does not) With AFL++ 3.10 we introduced the following changes from previous behaviors: * The '+' feature of the '-t' option now means to auto-calculate the timeout diff --git a/instrumentation/README.llvm.md b/instrumentation/README.llvm.md index 8133cbe4..d16049fa 100644 --- a/instrumentation/README.llvm.md +++ b/instrumentation/README.llvm.md @@ -106,9 +106,10 @@ either setting `AFL_CC_COMPILER=LLVM` or pass the parameter `--afl-llvm` via CFLAGS/CXXFLAGS/CPPFLAGS. The tool honors roughly the same environmental variables as afl-gcc (see -[docs/env_variables.md](../docs/env_variables.md)). This includes AFL_USE_ASAN, -AFL_HARDEN, and AFL_DONT_OPTIMIZE. However AFL_INST_RATIO is not honored as it -does not serve a good purpose with the more effective PCGUARD analysis. +[docs/env_variables.md](../docs/env_variables.md)). This includes +`AFL_USE_ASAN`, `AFL_HARDEN`, and `AFL_DONT_OPTIMIZE`. However, `AFL_INST_RATIO` +is not honored as it does not serve a good purpose with the more effective +PCGUARD analysis. ## 3) Options @@ -125,8 +126,8 @@ For splitting memcmp, strncmp, etc., see Then there are different ways of instrumenting the target: 1. An better instrumentation strategy uses LTO and link time instrumentation. - Note that not all targets can compile in this mode, however if it works it is - the best option you can use. To go with this option, use + Note that not all targets can compile in this mode, however, if it works it + is the best option you can use. To go with this option, use afl-clang-lto/afl-clang-lto++. See [README.lto.md](README.lto.md). 2. Alternatively you can choose a completely different coverage method: diff --git a/qemu_mode/README.persistent.md b/qemu_mode/README.persistent.md index 7210a8cc..ab45860d 100644 --- a/qemu_mode/README.persistent.md +++ b/qemu_mode/README.persistent.md @@ -17,10 +17,10 @@ The start of the persistent loop has to be set with environment variable `AFL_QEMU_PERSISTENT_ADDR`. This address can be the address of whatever instruction. Setting this address to -the start of a function makes the usage simple. If the address is however within -a function, either RET, OFFSET, or EXITS (see below in 2.2, 2.3, 2.6) have to be -set. This address (as well as the RET address, see below) has to be defined in -hexadecimal with the 0x prefix or as a decimal value. +the start of a function makes the usage simple. If the address is, however, +within a function, either RET, OFFSET, or EXITS (see below in 2.2, 2.3, 2.6) +have to be set. This address (as well as the RET address, see below) has to be +defined in hexadecimal with the 0x prefix or as a decimal value. If both RET and EXITS are not set, QEMU will assume that START points to a function and will patch the return address (on stack or in the link register) to diff --git a/qemu_mode/libcompcov/README.md b/qemu_mode/libcompcov/README.md index 6a72f5ff..50f0d802 100644 --- a/qemu_mode/libcompcov/README.md +++ b/qemu_mode/libcompcov/README.md @@ -18,7 +18,7 @@ and this module is not capable to log the coverage in this case. If you have the source code of the fuzzing target you should nto use this library and QEMU but build it with afl-clang-fast and the laf-intel options. -To use this library make sure to preload it with AFL_PRELOAD. +To use this library, make sure to preload it with AFL_PRELOAD. ``` export AFL_PRELOAD=/path/to/libcompcov.so @@ -32,6 +32,6 @@ Level 1 logs just comparison with immediates / read-only memory and level 2 logs all the comparisons. The library make use of https://github.com/ouadev/proc_maps_parser and so it is -Linux specific. However this is not a strict dependency, other UNIX operating -systems can be supported by replacing the code related to the -/proc/self/maps parsing. \ No newline at end of file +Linux specific. However, this is not a strict dependency, other UNIX operating +systems can be supported by replacing the code related to the /proc/self/maps +parsing. \ No newline at end of file diff --git a/utils/afl_network_proxy/README.md b/utils/afl_network_proxy/README.md index 05659c45..d2c00be2 100644 --- a/utils/afl_network_proxy/README.md +++ b/utils/afl_network_proxy/README.md @@ -34,16 +34,17 @@ afl-network-server -i 1111 -m 25M -t 1000 -- /bin/target -f @@ ### on the (afl-fuzz) main node -Just run afl-fuzz with your normal options, however the target should be +Just run afl-fuzz with your normal options, however, the target should be `afl-network-client` with the IP and PORT of the `afl-network-server` and increase the -t value: + ``` afl-fuzz -i in -o out -t 2000+ -- afl-network-client TARGET-IP 1111 ``` -Note the '+' on the -t parameter value. The afl-network-server will take -care of proper timeouts hence afl-fuzz should not. The '+' increases the -timeout and the value itself should be 500-1000 higher than the one on -afl-network-server. + +Note the '+' on the -t parameter value. The afl-network-server will take care of +proper timeouts hence afl-fuzz should not. The '+' increases the timeout and the +value itself should be 500-1000 higher than the one on afl-network-server. ### networking @@ -53,7 +54,7 @@ either. Note that also the outgoing interface can be specified with a '%' for Also make sure your default TCP window size is larger than your MAP_SIZE (130kb is a good value). -On Linux that is the middle value of `/proc/sys/net/ipv4/tcp_rmem` +On Linux that is the middle value of `/proc/sys/net/ipv4/tcp_rmem` ## how to compile and install diff --git a/utils/afl_untracer/README.md b/utils/afl_untracer/README.md index ada0c916..9f41618f 100644 --- a/utils/afl_untracer/README.md +++ b/utils/afl_untracer/README.md @@ -5,9 +5,9 @@ afl-untracer is an example skeleton file which can easily be used to fuzz a closed source library. -It requires less memory and is x3-5 faster than qemu_mode however it is way -more course grained and does not provide interesting features like compcov -or cmplog. +It requires less memory and is x3-5 faster than qemu_mode, however, it is way +more course grained and does not provide interesting features like compcov or +cmplog. Supported is so far Intel (i386/x86_64) and AARCH64. -- cgit 1.4.1 From aa6586a761c47da1f202221c9a449b692cacbcae Mon Sep 17 00:00:00 2001 From: llzmb <46303940+llzmb@users.noreply.github.com> Date: Thu, 2 Dec 2021 21:23:22 +0100 Subject: Fix typos - 1st run --- custom_mutators/gramatron/README.md | 6 +++--- docs/FAQ.md | 2 +- docs/fuzzing_in_depth.md | 2 +- instrumentation/README.llvm.md | 2 +- qemu_mode/libcompcov/README.md | 2 +- utils/optimin/README.md | 2 +- 6 files changed, 8 insertions(+), 8 deletions(-) (limited to 'qemu_mode') diff --git a/custom_mutators/gramatron/README.md b/custom_mutators/gramatron/README.md index 0167f620..2ed014cd 100644 --- a/custom_mutators/gramatron/README.md +++ b/custom_mutators/gramatron/README.md @@ -1,6 +1,6 @@ # GramaTron -Gramatron is a coverage-guided fuzzer that uses grammar automatons to perform +GramaTron is a coverage-guided fuzzer that uses grammar automatons to perform grammar-aware fuzzing. Technical details about our framework are available in the [ISSTA'21 paper](https://nebelwelt.net/files/21ISSTA.pdf). The artifact to reproduce the experiments presented in the paper are present @@ -9,11 +9,11 @@ grammars is presented below: # Compiling -Execute `./build_gramatron_mutator.sh` +Execute `./build_gramatron_mutator.sh`. # Running -You have to set the grammar file to use with `GRAMMATRON_AUTOMATION`: +You have to set the grammar file to use with `GRAMATRON_AUTOMATION`: ``` export AFL_DISABLE_TRIM=1 diff --git a/docs/FAQ.md b/docs/FAQ.md index 27250415..671957ef 100644 --- a/docs/FAQ.md +++ b/docs/FAQ.md @@ -125,7 +125,7 @@ If you find an interesting or important question missing, submit it via If, however, randomness happens, e.g., a thread reading other external data, reaction to timing, etc., then in some of the re-executions with the same data - the edge coverage result will be different accross runs. Those edges that + the edge coverage result will be different across runs. Those edges that change are then flagged "unstable". The more "unstable" edges, the more difficult for AFL++ to identify valid new paths. diff --git a/docs/fuzzing_in_depth.md b/docs/fuzzing_in_depth.md index 7c464d81..011ba783 100644 --- a/docs/fuzzing_in_depth.md +++ b/docs/fuzzing_in_depth.md @@ -131,7 +131,7 @@ The following options are available when you instrument with LTO mode have to compile the target twice, once specifically with/for this mode by setting `AFL_LLVM_CMPLOG=1`, and pass this binary to afl-fuzz via the `-c` parameter. Note that you can compile also just a cmplog binary and use that - for both, however, there will be a performance penality. You can read more + for both, however, there will be a performance penalty. You can read more about this in [instrumentation/README.cmplog.md](../instrumentation/README.cmplog.md). diff --git a/instrumentation/README.llvm.md b/instrumentation/README.llvm.md index ac8f2f2a..c93cd312 100644 --- a/instrumentation/README.llvm.md +++ b/instrumentation/README.llvm.md @@ -125,7 +125,7 @@ For splitting memcmp, strncmp, etc., see Then there are different ways of instrumenting the target: -1. An better instrumentation strategy uses LTO and link time instrumentation. +1. A better instrumentation strategy uses LTO and link time instrumentation. Note that not all targets can compile in this mode, however, if it works it is the best option you can use. To go with this option, use afl-clang-lto/afl-clang-lto++. See [README.lto.md](README.lto.md). diff --git a/qemu_mode/libcompcov/README.md b/qemu_mode/libcompcov/README.md index 50f0d802..bb010d8f 100644 --- a/qemu_mode/libcompcov/README.md +++ b/qemu_mode/libcompcov/README.md @@ -31,7 +31,7 @@ The AFL_COMPCOV_LEVEL tells to QEMU and libcompcov how to log comaprisons. Level 1 logs just comparison with immediates / read-only memory and level 2 logs all the comparisons. -The library make use of https://github.com/ouadev/proc_maps_parser and so it is +The library makes use of https://github.com/ouadev/proc_maps_parser and so it is Linux specific. However, this is not a strict dependency, other UNIX operating systems can be supported by replacing the code related to the /proc/self/maps parsing. \ No newline at end of file diff --git a/utils/optimin/README.md b/utils/optimin/README.md index 507cb305..340022b8 100644 --- a/utils/optimin/README.md +++ b/utils/optimin/README.md @@ -77,7 +77,7 @@ For more details, see the paper [Seed Selection for Successful Fuzzing](https://dl.acm.org/doi/10.1145/3460319.3464795). If you use OptiMin in your research, please cite this paper. -Bibtex: +BibTeX: ```bibtex @inproceedings{Herrera:2021:FuzzSeedSelection, -- cgit 1.4.1 From 6eab6a55af74754cd0229012f1c9543c0c3cb2a7 Mon Sep 17 00:00:00 2001 From: llzmb <46303940+llzmb@users.noreply.github.com> Date: Sat, 4 Dec 2021 21:14:50 +0100 Subject: Fix spelling of "FRIDA mode" and "QEMU mode" --- TODO.md | 2 +- docs/INSTALL.md | 4 ++-- docs/features.md | 8 ++++---- docs/fuzzing_binary-only_targets.md | 35 ++++++++++++++++++----------------- docs/important_changes.md | 8 ++++---- instrumentation/README.llvm.md | 2 +- qemu_mode/libqasan/README.md | 2 +- utils/README.md | 2 +- utils/afl_untracer/README.md | 2 +- utils/aflpp_driver/README.md | 4 ++-- utils/qbdi_mode/README.md | 2 +- 11 files changed, 36 insertions(+), 35 deletions(-) (limited to 'qemu_mode') diff --git a/TODO.md b/TODO.md index 04f3abab..e6b095fc 100644 --- a/TODO.md +++ b/TODO.md @@ -16,7 +16,7 @@ ## Further down the road -qemu_mode/frida_mode: +QEMU mode/FRIDA mode: - non colliding instrumentation - rename qemu specific envs to AFL_QEMU (AFL_ENTRYPOINT, AFL_CODE_START/END, AFL_COMPCOV_LEVEL?) diff --git a/docs/INSTALL.md b/docs/INSTALL.md index 08d3283e..9d1309fe 100644 --- a/docs/INSTALL.md +++ b/docs/INSTALL.md @@ -23,7 +23,7 @@ sudo apt-get install -y build-essential python3-dev automake git flex bison libg # try to install llvm 11 and install the distro default if that fails sudo apt-get install -y lld-11 llvm-11 llvm-11-dev clang-11 || sudo apt-get install -y lld llvm llvm-dev clang sudo apt-get install -y gcc-$(gcc --version|head -n1|sed 's/.* //'|sed 's/\..*//')-plugin-dev libstdc++-$(gcc --version|head -n1|sed 's/.* //'|sed 's/\..*//')-dev -sudo apt-get install -y ninja-build # for qemu_mode +sudo apt-get install -y ninja-build # for QEMU mode git clone https://github.com/AFLplusplus/AFLplusplus cd AFLplusplus make distrib @@ -33,7 +33,7 @@ sudo make install It is recommended to install the newest available gcc, clang and llvm-dev possible in your distribution! -Note that "make distrib" also builds instrumentation, qemu_mode, unicorn_mode +Note that "make distrib" also builds instrumentation, QEMU mode, unicorn_mode and more. If you just want plain AFL++, then do "make all". However, compiling and using at least instrumentation is highly recommended for much better results - hence in this case choose: diff --git a/docs/features.md b/docs/features.md index fb688a64..06b1bcbe 100644 --- a/docs/features.md +++ b/docs/features.md @@ -4,7 +4,7 @@ AFL++ supports llvm from 3.8 up to version 12, very fast binary fuzzing with QEMU 5.1 with laf-intel and redqueen, frida mode, unicorn mode, gcc plugin, full *BSD, Mac OS, Solaris and Android support and much, much, much more. -| Feature/Instrumentation | afl-gcc | llvm | gcc_plugin | frida_mode(9) | qemu_mode(10) |unicorn_mode(10) |coresight_mode(11)| +| Feature/Instrumentation | afl-gcc | llvm | gcc_plugin | FRIDA mode(9) | QEMU mode(10) |unicorn_mode(10) |coresight_mode(11)| | -------------------------|:-------:|:---------:|:----------:|:----------------:|:----------------:|:----------------:|:----------------:| | Threadsafe counters | | x(3) | | | | | | | NeverZero | x86[_64]| x(1) | x | x | x | x | | @@ -37,9 +37,9 @@ QEMU 5.1 with laf-intel and redqueen, frida mode, unicorn mode, gcc plugin, full Among others, the following features and patches have been integrated: -* NeverZero patch for afl-gcc, instrumentation, qemu_mode and unicorn_mode which +* NeverZero patch for afl-gcc, instrumentation, QEMU mode and unicorn_mode which prevents a wrapping map value to zero, increases coverage -* Persistent mode, deferred forkserver and in-memory fuzzing for qemu_mode +* Persistent mode, deferred forkserver and in-memory fuzzing for QEMU mode * Unicorn mode which allows fuzzing of binaries from completely different platforms (integration provided by domenukk) * The new CmpLog instrumentation for LLVM and QEMU inspired by @@ -51,7 +51,7 @@ Among others, the following features and patches have been integrated: [https://github.com/puppet-meteor/MOpt-AFL](https://github.com/puppet-meteor/MOpt-AFL) * LLVM mode Ngram coverage by Adrian Herrera [https://github.com/adrianherrera/afl-ngram-pass](https://github.com/adrianherrera/afl-ngram-pass) -* LAF-Intel/CompCov support for instrumentation, qemu_mode and unicorn_mode +* LAF-Intel/CompCov support for instrumentation, QEMU mode and unicorn_mode (with enhanced capabilities) * Radamsa and honggfuzz mutators (as custom mutators). * QBDI mode to fuzz android native libraries via Quarkslab's diff --git a/docs/fuzzing_binary-only_targets.md b/docs/fuzzing_binary-only_targets.md index b3d9ca02..15155111 100644 --- a/docs/fuzzing_binary-only_targets.md +++ b/docs/fuzzing_binary-only_targets.md @@ -12,18 +12,18 @@ fuzzed with AFL++. ## TL;DR: -Qemu_mode in persistent mode is the fastest - if the stability is high enough. +QEMU mode in persistent mode is the fastest - if the stability is high enough. Otherwise, try RetroWrite, Dyninst, and if these fail, too, then try standard -qemu_mode with AFL_ENTRYPOINT to where you need it. +QEMU mode with `AFL_ENTRYPOINT` to where you need it. -If your target is a library, then use frida_mode. +If your target is a library, then use FRIDA mode. If your target is non-linux, then use unicorn_mode. ## Fuzzing binary-only targets with AFL++ -### Qemu_mode +### QEMU mode -Qemu_mode is the "native" solution to the program. It is available in the +QEMU mode is the "native" solution to the program. It is available in the ./qemu_mode/ directory and, once compiled, it can be accessed by the afl-fuzz -Q command line option. It is the easiest to use alternative and even works for cross-platform binaries. @@ -37,11 +37,12 @@ cd qemu_mode ./build_qemu_support.sh ``` -The following setup to use qemu_mode is recommended: +The following setup to use QEMU mode is recommended: + * run 1 afl-fuzz -Q instance with CMPLOG (`-c 0` + `AFL_COMPCOV_LEVEL=2`) * run 1 afl-fuzz -Q instance with QASAN (`AFL_USE_QASAN=1`) * run 1 afl-fuzz -Q instance with LAF (`AFL_PRELOAD=libcmpcov.so` + - `AFL_COMPCOV_LEVEL=2`), alternatively you can use frida_mode, just switch `-Q` + `AFL_COMPCOV_LEVEL=2`), alternatively you can use FRIDA mode, just switch `-Q` with `-O` and remove the LAF instance Then run as many instances as you have cores left with either -Q mode or - even @@ -49,16 +50,16 @@ better - use a binary rewriter like Dyninst, RetroWrite, ZAFL, etc. If [afl-dyninst](https://github.com/vanhauser-thc/afl-dyninst) works for your binary, then you can use afl-fuzz normally and it will have twice the speed -compared to qemu_mode (but slower than qemu persistent mode). Note that several +compared to QEMU mode (but slower than QEMU persistent mode). Note that several other binary rewriters exist, all with their advantages and caveats. -The speed decrease of qemu_mode is at about 50%. However, various options exist +The speed decrease of QEMU mode is at about 50%. However, various options exist to increase the speed: - using AFL_ENTRYPOINT to move the forkserver entry to a later basic block in the binary (+5-10% speed) - using persistent mode [qemu_mode/README.persistent.md](../qemu_mode/README.persistent.md) this will - result in a 150-300% overall speed increase - so 3-8x the original qemu_mode + result in a 150-300% overall speed increase - so 3-8x the original QEMU mode speed! - using AFL_CODE_START/AFL_CODE_END to only instrument specific parts @@ -71,7 +72,7 @@ conducive to parallelization. Note that there is also honggfuzz: [https://github.com/google/honggfuzz](https://github.com/google/honggfuzz) which -now has a qemu_mode, but its performance is just 1.5% ... +now has a QEMU mode, but its performance is just 1.5% ... If you like to code a customized fuzzer without much work, we highly recommend to check out our sister project libafl which supports QEMU, too: @@ -87,14 +88,14 @@ It is included in AFL++. For more information, see [qemu_mode/README.wine.md](../qemu_mode/README.wine.md). -### Frida_mode +### FRIDA mode -In frida_mode, you can fuzz binary-only targets as easily as with QEMU. -Frida_mode is sometimes faster and sometimes slower than Qemu_mode. It is also +In FRIDA mode, you can fuzz binary-only targets as easily as with QEMU mode. +FRIDA mode is sometimes faster and sometimes slower than QEMU mode. It is also newer, lacks COMPCOV, and has the advantage that it works on MacOS (both intel and M1). -To build frida_mode: +To build FRIDA mode: ```shell cd frida_mode @@ -149,11 +150,11 @@ For further information, check out If the goal is to fuzz a dynamic library, then there are two options available. For both, you need to write a small harness that loads and calls the library. -Then you fuzz this with either frida_mode or qemu_mode and either use +Then you fuzz this with either FRIDA mode or QEMU mode and either use `AFL_INST_LIBS=1` or `AFL_QEMU/FRIDA_INST_RANGES`. Another, less precise and slower option is to fuzz it with utils/afl_untracer/ -and use afl-untracer.c as a template. It is slower than frida_mode. +and use afl-untracer.c as a template. It is slower than FRIDA mode. For more information, see [utils/afl_untracer/README.md](../utils/afl_untracer/README.md). diff --git a/docs/important_changes.md b/docs/important_changes.md index 203c5a66..d5e67f75 100644 --- a/docs/important_changes.md +++ b/docs/important_changes.md @@ -5,8 +5,8 @@ changes. ## From version 3.00 onwards -With AFL++ 3.13-3.20, we introduce frida_mode (-O) to have an alternative for -binary-only fuzzing. It is slower than Qemu mode but works on MacOS, Android, +With AFL++ 3.13-3.20, we introduce FRIDA mode (`-O`) to have an alternative for +binary-only fuzzing. It is slower than QEMU mode but works on MacOS, Android, iOS etc. With AFL++ 3.15, we introduced the following changes from previous behaviors: @@ -31,8 +31,8 @@ behaviors and defaults: All instrumentation source code is now in the `instrumentation/` folder. * The gcc_plugin was replaced with a new version submitted by AdaCore that supports more features. Thank you! - * qemu_mode got upgraded to QEMU 5.1, but to be able to build this a current - ninja build tool version and python3 setuptools are required. qemu_mode also + * QEMU mode got upgraded to QEMU 5.1, but to be able to build this a current + ninja build tool version and python3 setuptools are required. QEMU mode also got new options like snapshotting, instrumenting specific shared libraries, etc. Additionally QEMU 5.1 supports more CPU targets so this is really worth it. diff --git a/instrumentation/README.llvm.md b/instrumentation/README.llvm.md index c93cd312..fa025643 100644 --- a/instrumentation/README.llvm.md +++ b/instrumentation/README.llvm.md @@ -218,7 +218,7 @@ by Jinghan Wang, et. al. Note that the original implementation (available [here](https://github.com/bitsecurerlab/afl-sensitive)) is built on top of AFL's -qemu_mode. This is essentially a port that uses LLVM vectorized instructions +QEMU mode. This is essentially a port that uses LLVM vectorized instructions (available from llvm versions 4.0.1 and higher) to achieve the same results when compiling source code. diff --git a/qemu_mode/libqasan/README.md b/qemu_mode/libqasan/README.md index 6a65c12b..41195933 100644 --- a/qemu_mode/libqasan/README.md +++ b/qemu_mode/libqasan/README.md @@ -9,7 +9,7 @@ and this runtime is injected via LD_PRELOAD (so works just for dynamically linked binaries). The usage is super simple, just set the env var `AFL_USE_QASAN=1` when fuzzing -in qemu mode (-Q). afl-fuzz will automatically set AFL_PRELOAD to load this +in QEMU mode (-Q). afl-fuzz will automatically set AFL_PRELOAD to load this library and enable the QASan instrumentation in afl-qemu-trace. For debugging purposes, we still suggest to run the original QASan as the diff --git a/utils/README.md b/utils/README.md index b7eead8e..5f5745b9 100644 --- a/utils/README.md +++ b/utils/README.md @@ -16,7 +16,7 @@ Here's a quick overview of the stuff you can find in this directory: different means, e.g., hw debugger - afl_untracer - fuzz binary-only libraries much faster but with - less coverage than qemu_mode + less coverage than QEMU mode - analysis_scripts - random -o out analysis scripts diff --git a/utils/afl_untracer/README.md b/utils/afl_untracer/README.md index 9f41618f..3fff5f83 100644 --- a/utils/afl_untracer/README.md +++ b/utils/afl_untracer/README.md @@ -5,7 +5,7 @@ afl-untracer is an example skeleton file which can easily be used to fuzz a closed source library. -It requires less memory and is x3-5 faster than qemu_mode, however, it is way +It requires less memory and is x3-5 faster than QEMU mode, however, it is way more course grained and does not provide interesting features like compcov or cmplog. diff --git a/utils/aflpp_driver/README.md b/utils/aflpp_driver/README.md index d534cd7f..8b9fe15f 100644 --- a/utils/aflpp_driver/README.md +++ b/utils/aflpp_driver/README.md @@ -22,10 +22,10 @@ or `@@` as command line parameters. ## aflpp_qemu_driver -Note that you can use the driver too for frida_mode (`-O`). +Note that you can use the driver too for FRIDA mode (`-O`). aflpp_qemu_driver is used for libfuzzer `LLVMFuzzerTestOneInput()` targets that -are to be fuzzed in qemu_mode. So compile them with clang/clang++, without +are to be fuzzed in QEMU mode. So compile them with clang/clang++, without -fsantize=fuzzer or afl-clang-fast, and link in libAFLQemuDriver.a: `clang++ -o fuzz fuzzer_harness.cc libAFLQemuDriver.a [plus required linking]`. diff --git a/utils/qbdi_mode/README.md b/utils/qbdi_mode/README.md index c8d46fca..02dd3c74 100755 --- a/utils/qbdi_mode/README.md +++ b/utils/qbdi_mode/README.md @@ -2,7 +2,7 @@ NOTE: this code is outdated and first would need to be adapted to the current AFL++ versions. -Try frida_mode or fpicker [https://github.com/ttdennis/fpicker/](https://github.com/ttdennis/fpicker/) first, maybe they suite your need. +Try FRIDA mode or fpicker [https://github.com/ttdennis/fpicker/](https://github.com/ttdennis/fpicker/) first, maybe they suite your need. ## 1) Introduction -- cgit 1.4.1