Lines Matching +full:qemu +full:- +full:run

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
164 and use afl-untracer.c as a template. It is slower than FRIDA mode.
172 tracer implementation available in `coresight_mode/` which is faster than QEMU,
173 however, cannot run in parallel. Currently, only one process can be traced, it
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
223 Hence, more often than not binaries crash when they are run.
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)