diff options
Diffstat (limited to 'docs/binaryonly_fuzzing.txt')
| -rw-r--r-- | docs/binaryonly_fuzzing.txt | 27 |
1 files changed, 14 insertions, 13 deletions
diff --git a/docs/binaryonly_fuzzing.txt b/docs/binaryonly_fuzzing.txt index f370ec74..ae5269f0 100644 --- a/docs/binaryonly_fuzzing.txt +++ b/docs/binaryonly_fuzzing.txt @@ -11,7 +11,7 @@ then standard afl++ (dumb mode) is not effective. The following is a description of how these can be fuzzed with afl++ !!!!! -DTLR: try DYNINST with afl-dyninst. If it produces too many crashes then +TL;DR: try DYNINST with afl-dyninst. If it produces too many crashes then use afl -Q qemu_mode. !!!!! @@ -22,7 +22,7 @@ Qemu 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. The speed decrease is at about 50% -It the easiest to use alternative and even works for cross-platform binaries. +It is the easiest to use alternative and even works for cross-platform binaries. As it is included in afl++ this needs no URL. @@ -30,7 +30,7 @@ As it is included in afl++ this needs no URL. DYNINST ------- Dyninst is a binary instrumentation framework similar to Pintool and Dynamorio -(see far below). Howver whereas Pintool and Dynamorio work at runtime, dyninst +(see far below). However whereas Pintool and Dynamorio work at runtime, dyninst instruments the target at load time, and then let it run. This is great for some things, e.g. fuzzing, and not so effective for others, e.g. malware analysis. @@ -38,15 +38,15 @@ e.g. malware analysis. So what we can do with dyninst is taking every basic block, and put afl's instrumention code in there - and then save the binary. Afterwards we can just fuzz the newly saved target binary with afl-fuzz. -Sounds great? It is. The issue though - this is a non-trivial problem to -insert instructions, which changes addresses in the process space and that -everything still works afterwards. Hence more often than not binaries -crash when they are run. +Sounds great? It is. The issue though - it is a non-trivial problem to +insert instructions, which change addresses in the process space, so +everything is still working afterwards. Hence more often than not binaries +crash when they are run (because of instrumentation). The speed decrease is about 15-35%, depending on the optimization options used with afl-dyninst. -So if dyninst works, its the best option available. Otherwise it just doesn't +So if dyninst works, it is the best option available. Otherwise it just doesn't work well. https://github.com/vanhauser-thc/afl-dyninst @@ -54,13 +54,14 @@ https://github.com/vanhauser-thc/afl-dyninst INTEL-PT -------- +If you have a newer Intel CPU, you can make use of Intels processor trace. The big issue with Intel's PT is the small buffer size and the complex encoding of the debug information collected through PT. This makes the decoding very CPU intensive and hence slow. As a result, the overall speed decrease is about 70-90% (depending on -the implementation and other factors) +the implementation and other factors). -there are two afl intel-pt implementations: +There are two afl intel-pt implementations: 1. https://github.com/junxzm1990/afl-pt => this needs Ubuntu 14.04.05 without any updates and the 4.4 kernel. @@ -73,13 +74,13 @@ there are two afl intel-pt implementations: CORESIGHT --------- -Coresight is the ARM answer to Intel's PT. +Coresight is ARM's answer to Intel's PT. There is no implementation so far which handle coresight and getting -it working on an ARM Linux is very difficult due custom kernel building +it working on an ARM Linux is very difficult due to custom kernel building on embedded systems is difficult. And finding one that has coresight in the ARM chip is difficult too. My guess is that it is slower than Qemu, but faster than Intel PT. -If anyone finds any coresight implemention for afl please ping me: +If anyone finds any coresight implementation for afl please ping me: vh@thc.org |