documentation update
diff --git a/TODO b/TODO
index 3d1e444..42987cb 100644
--- a/TODO
+++ b/TODO
@@ -1,6 +1,6 @@
Roadmap 2.53d:
==============
- - indent all the code: clang-format -style=Google
+ - indent all the code: .clang-format
- update docs/sister_projects.txt
@@ -18,16 +18,41 @@
qemu_mode:
- deferred mode with AFL_DEFERRED_QEMU=0xaddress
+ @andrea - dont we have that already with AFL_ENTRYPOINT?
unit testing / or large testcase campaign
Roadmap 2.54d:
==============
- - expand MAP size to 256k (current L2 cache size on processors)
- -> 18 bit map
- - llvm_mode: dynamic map size and collission free basic block IDs
-
+Problem: Average targets (tiff, jpeg, unrar) go through 1500 edges.
+ At afl's default map that means ~16 collisions and ~3 wrappings.
+ Solution #1: increase map size.
+ every +1 decreases fuzzing speed by ~10% and halfs the collisions
+ birthday paradox predicts at collisions at this # of edges:
+ 2^16 = 302
+ 2^17 = 427
+ 2^18 = 603
+ 2^19 = 853
+ 2^20 = 1207
+ 2^21 = 1706
+ 2^22 = 2412
+ 2^23 = 3411
+ 2^24 = 4823
+ Its an easy solution but also not a good one.
+ Solution #2: use dynamic map size and collision free basic block IDs
+ This only works in llvm_mode and llvm >= 9 though
+ A potential good future solution
+ Solution #3: write instruction pointers to a big shared map
+ 512kb/1MB shared map and the instrumented code writes the instruction
+ pointer into the map. Map must be big enough but could be command line
+ controlled.
+ Good: complete coverage information, nothing is lost. choice of analysis
+ impacts speed, but this can be decided by user options
+ Neutral: a little bit slower but no loss of coverage
+ Bad: completely changes how afl uses the map and the scheduling.
+ Overall another very good solution
+
qemu_mode:
- persistent mode patching the return address (WinAFL style)
- instrument only comparison with immediate values by default when using compcov
diff --git a/docs/ChangeLog b/docs/ChangeLog
index 5e78610..dfebb68 100644
--- a/docs/ChangeLog
+++ b/docs/ChangeLog
@@ -17,6 +17,8 @@
Version ++2.53d (dev):
----------------------
+ - llvm 9 is now supported (still needs testing)
+ - fix building qemu on some Ubuntus (thanks to floyd!)
- custom mutator by a loaded library is now supported (thanks to kyakdan!)
- fix for a few features to support different map sized than 2^16
- afl-showmap: new option -r now shows the real values in the buckets (stock
@@ -26,7 +28,6 @@
- ... your patch? :)
-
--------------------------
Version ++2.53c (release):
--------------------------
diff --git a/docs/env_variables.txt b/docs/env_variables.txt
index 36fdc36..93066db 100644
--- a/docs/env_variables.txt
+++ b/docs/env_variables.txt
@@ -257,10 +257,14 @@
Use this if you are unsure if the entrypoint might be wrong - but
use it directly, e.g. afl-qemu-trace ./program
- - If you want to specify a specific entrypoint into the binary (this can
- be very good for the performance!), use AFL_ENTRYPOINT for this.
+ - AFL_ENTRYPOINT allows you to specify a specific entrypoint into the
+ binary (this can be very good for the performance!).
The entrypoint is specified as hex address, e.g. 0x4004110
+ - AFL_QEMU_COMPCOV is for a sub-project in qemu_mode called ./libcompcov
+ which implements laf-intel for qemu. It also needs AFL_PRELOAD and
+ you can find more information in qemu_mode/libcompcov/README.compcov
+
5) Settings for afl-cmin
------------------------
diff --git a/llvm_mode/README.llvm b/llvm_mode/README.llvm
index a0c4021..f324b8c 100644
--- a/llvm_mode/README.llvm
+++ b/llvm_mode/README.llvm
@@ -8,8 +8,7 @@
1) Introduction
---------------
-! llvm_mode works with llvm version 3.8.1 up to 8.x !
-! llvm version 9 does not work yet !
+! llvm_mode works with llvm versions 3.8.1 up to 9 !
The code in this directory allows you to instrument programs for AFL using
true compiler-level instrumentation, instead of the more crude
diff --git a/qemu_mode/README.qemu b/qemu_mode/README.qemu
index 124fce1..754c025 100644
--- a/qemu_mode/README.qemu
+++ b/qemu_mode/README.qemu
@@ -46,7 +46,19 @@
users, you need to build it before issuing 'make install' in the parent
directory.
-3) Notes on linking
+3) Options
+----------
+
+There is ./libcompcov/ which implements laf-intel (splitting memcmp,
+strncmp, etc. to make these conditions easier solvable by afl-fuzz).
+Highly recommended.
+
+Another option is the environment variable AFL_ENTRYPOINT which allows
+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) Notes on linking
-------------------
The feature is supported only on Linux. Supporting BSD may amount to porting
@@ -68,7 +80,7 @@
Setting AFL_INST_LIBS=1 can be used to circumvent the .text detection logic
and instrument every basic block encountered.
-4) Benchmarking
+5) Benchmarking
---------------
If you want to compare the performance of the QEMU instrumentation with that of
@@ -84,7 +96,7 @@
fairly meaningless if the optimization levels or instrumentation scopes don't
match.
-5) Gotchas, feedback, bugs
+6) Gotchas, feedback, bugs
--------------------------
If you need to fix up checksums or do other cleanup on mutated test cases, see
@@ -106,7 +118,7 @@
Beyond that, this is an early-stage mechanism, so fields reports are welcome.
You can send them to <afl-users@googlegroups.com>.
-6) Alternatives: static rewriting
+7) Alternatives: static rewriting
---------------------------------
Statically rewriting binaries just once, instead of attempting to translate
@@ -114,12 +126,11 @@
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.
-If you want to experiment with this mode of operation, there is a module
-contributed by Aleksandar Nikolich:
+The best implementation is this one:
https://github.com/vanhauser-thc/afl-dyninst
- https://groups.google.com/forum/#!topic/afl-users/HlSQdbOTlpg
-At this point, the author reports the possibility of hiccups with stripped
-binaries. That said, if we can get it to be comparably reliable to QEMU, we may
-decide to switch to this mode, but I had no time to play with it yet.
+The issue however is Dyninst which is not rewriting the binaries so that
+they run stable. a lot of crashes happen, especially in C++ programs that
+use throw/catch. Try it first, and if it works for you be happy as it is
+2-3x as fast as qemu_mode.
