fuzzing_binary-only_targets.md - OpenGrok cross reference for /external/AFLplusplus/docs/fuzzing_binary-only

Lines Matching +full:qemu +full:- +full:utils
1 # Fuzzing binary-only targets
7 standard `afl-fuzz -n` (non-instrumented mode) is not effective.
9 For fast, on-the-fly instrumentation of black-box binaries, AFL++ still offers
15 FRIDA mode and QEMU mode in persistent mode are the fastest - if persistent mode
19 standard FRIDA/QEMU mode with `AFL_ENTRYPOINT` to where you need it.
21 If your target is non-linux, then use unicorn_mode.
23 ## Fuzzing binary-only targets with AFL++
25 ### QEMU mode
27 QEMU mode is the "native" solution to the program. It is available in the
28 ./qemu_mode/ directory and, once compiled, it can be accessed by the afl-fuzz -Q
30 cross-platform binaries.
33 QEMU running in the lesser-known "user space emulation" mode. QEMU is a project
41 The following setup to use QEMU mode is recommended:
43 * run 1 afl-fuzz -Q instance with CMPLOG (`-c 0` + `AFL_COMPCOV_LEVEL=2`)
44 * run 1 afl-fuzz -Q instance with QASAN (`AFL_USE_QASAN=1`)
45 * run 1 afl-fuzz -Q instance with LAF (`AFL_PRELOAD=libcmpcov.so` +
46   `AFL_COMPCOV_LEVEL=2`), alternatively you can use FRIDA mode, just switch `-Q`
47   with `-O` and remove the LAF instance
49 Then run as many instances as you have cores left with either -Q mode or - even
50 better - use a binary rewriter like Dyninst, RetroWrite, ZAFL, etc.
54 If a binary rewriter works for your target then you can use afl-fuzz normally
55 and it will have twice the speed compared to QEMU mode (but slower than QEMU
58 The speed decrease of QEMU mode is at about 50%. However, various options exist
60 - using AFL_ENTRYPOINT to move the forkserver entry to a later basic block in
61   the binary (+5-10% speed)
62 - using persistent mode
64   result in a 150-300% overall speed increase - so 3-8x the original QEMU mode
66 - using AFL_CODE_START/AFL_CODE_END to only instrument specific parts
72 approximately 2-5x slower than compile-time instrumentation, and is less
77 now has a QEMU mode, but its performance is just 1.5% ...
80 to check out our sister project libafl which supports QEMU, too:
83 ### WINE+QEMU
85 Wine mode can run Win32 PE binaries with the QEMU instrumentation. It needs
95 In FRIDA mode, you can fuzz binary-only targets as easily as with QEMU mode.
96 FRIDA mode is most of the times slightly faster than QEMU mode. It is also
111 The mode is approximately 2-5x slower than compile-time instrumentation, and is
112 less conducive to parallelization. But for binary-only fuzzing, it gives a huge
123 Working examples already exist :-)
128 built upon KVM and QEMU. It is only available on Linux and currently restricted
131 For binary-only fuzzing a special 5.10 kernel is required.
137 Unicorn is a fork of QEMU. The instrumentation is, therefore, very similar. In
138 contrast to QEMU, Unicorn does not offer a full system or even userland
141 introduced in the patched QEMU Mode of AFL++ cannot be ported over to Unicorn.
143 For non-Linux binaries, you can use AFL++'s unicorn_mode which can emulate
144 anything you want - for the price of speed and user written scripts.
160 Then you fuzz this with either FRIDA mode or QEMU mode and either use
163 Another, less precise and slower option is to fuzz it with utils/afl_untracer/
164 and use afl-untracer.c as a template. It is slower than FRIDA mode.
167 [utils/afl_untracer/README.md](../utils/afl_untracer/README.md).
172 tracer implementation available in `coresight_mode/` which is faster than QEMU,
186 ZAFL is a static rewriting platform supporting x86-64 C/C++,
187 stripped/unstripped, and PIE/non-PIE binaries. Beyond conventional
188 instrumentation, ZAFL's API enables transformation passes (e.g., laf-Intel,
191 Its baseline instrumentation speed typically averages 90-95% of
192 afl-clang-fast's.
194 [https://git.zephyr-software.com/opensrc/zafl](https://git.zephyr-software.com/opensrc/zafl)
199 have an x86_64 or arm64 binary that does not contain C++ exceptions and - if
200 x86_64 - still has it's symbols and compiled with position independent code
202 It decompiles to ASM files which can then be instrumented with afl-gcc.
205 in performance to compiler-instrumented binaries and outperform the QEMU-based
214 target at load time and then let it run - or save the binary with the changes.
219 instrumentation code in there - and then save the binary. Afterwards, just fuzz
220 the newly saved target binary with afl-fuzz. Sounds great? It is. The issue
221 though - it is a non-trivial problem to insert instructions, which change
225 The speed decrease is about 15-35%, depending on the optimization options used
226 with afl-dyninst.
228 [https://github.com/vanhauser-thc/afl-dyninst](https://github.com/vanhauser-thc/afl-dyninst)
235 [https://github.com/lifting-bits/mcsema](https://github.com/lifting-bits/mcsema)
247 has a speed decrease of 98-99%, Pintool has a speed decrease of 99.5%.
253 * [https://github.com/vanhauser-thc/afl-dynamorio](https://github.com/vanhauser-thc/afl-dynamorio)
259 * [https://github.com/vanhauser-thc/afl-pin](https://github.com/vanhauser-thc/afl-pin)
270 70-90% (depending on the implementation and other factors).
272 There are two AFL intel-pt implementations:
274 1. [https://github.com/junxzm1990/afl-pt](https://github.com/junxzm1990/afl-pt)
277 2. [https://github.com/hunter-ht-2018/ptfuzzer](https://github.com/hunter-ht-2018/ptfuzzer)
285 ## Non-AFL++ solutions
287 There are many binary-only fuzzing frameworks. Some are great for CTFs but don't
296   [https://github.com/sslab-gatech/qsym](https://github.com/sslab-gatech/qsym)