2.20b

config.h

@@ -21,7 +21,7 @@
 
 /* Version string: */
 
-#define VERSION             "2.19b"
+#define VERSION             "2.20b"
 
 /******************************************************
  *                                                    *
@@ -61,13 +61,9 @@
 /* Number of calibration cycles per every new test case (and for test
    cases that show variable behavior): */
 
-#define CAL_CYCLES          10
+#define CAL_CYCLES          8
 #define CAL_CYCLES_LONG     40
 
-/* The same, but when AFL_NO_VAR_CHECK is set in the environment: */
-
-#define CAL_CYCLES_NO_VAR   4
-
 /* Number of subsequent hangs before abandoning an input file: */
 
 #define HANG_LIMIT          250

docs/ChangeLog

@@ -16,6 +16,22 @@ Not sure if you should upgrade? The lowest currently recommended version
 is 2.18b. If you're stuck on an earlier release, it's strongly advisable
 to get on with the times.
 
+--------------
+Version 2.20b:
+--------------
+
+  - Revamped the handling of variable paths, replacing path count with a
+    "stability" score to give users a much better signal. Based on the
+    feedback from Vegard Nossum.
+
+  - Made a stability improvement to the syncing behavior with resuming
+    fuzzers. Based on the feedback from Vegard.
+
+  - Changed the UI to include current input bitmap density along with
+    total density. Ditto.
+
+  - Added experimental support for parallelizing -M.
+
 --------------
 Version 2.19b:
 --------------

docs/README

@@ -464,6 +464,7 @@ bug reports, or patches from:
   Daniel Godas-Lopez                    Franjo Ivancic
   Austin Seipp                          Daniel Komaromy
   Daniel Binderman                      Jonathan Metzman
+  Vegard Nossum
 
 Thank you!
 

docs/env_variables.txt

@@ -99,11 +99,6 @@ checks or alter some of the more exotic semantics of the tool:
     normally done when starting up the forkserver and causes a pretty
     significant performance drop.
 
-  - Setting AFL_NO_VAR_CHECK skips the detection of variable test cases,
-    greatly speeding up session resumption and path discovery for complex
-    multi-threaded apps (but depriving you of a potentially useful signal
-    in more orderly programs).
-
   - AFL_EXIT_WHEN_DONE causes afl-fuzz to terminate when all existing paths
     have been fuzzed and there were no new finds for a while. This would be
     normally indicated by the cycle counter in the UI turning green. May be

docs/parallel_fuzzing.txt

@@ -51,13 +51,25 @@ 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.
 
-The only difference between the -M and -S modes is that the master instance
-will still perform deterministic checks; while the secondary instances will
+The difference between the -M and -S modes is that the master instance will
+still perform deterministic checks; while the secondary instances will
 proceed straight to random tweaks. If you don't want to do deterministic
 fuzzing at all, it's OK to run all instances with -S. With very slow or complex
 targets, or when running heavily parallelized jobs, this is usually a good plan.
 
-You can monitor the progress of your jobs from the command line with the
+Note that running multiple -M instances is wasteful, although there is an
+experimental support for parallelizing the deterministic checks. To leverage
+that, you need to create -M instances like so:
+
+$ ./afl-fuzz -i testcase_dir -o sync_dir -M masterA:1/3 [...]
+$ ./afl-fuzz -i testcase_dir -o sync_dir -M masterB:2/3 [...]
+$ ./afl-fuzz -i testcase_dir -o sync_dir -M masterC:3/3 [...]
+
+...where the first value after ':' is the sequential ID of a particular master
+instance (starting at 1), and the second value is the total number of fuzzers to
+distribute the deterministic fuzzing across.
+
+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,
 it's probably time to stop.
 

docs/sister_projects.txt

@@ -78,6 +78,13 @@ TriforceAFL (Tim Newsham and Jesse Hertz)
 
   https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2016/june/project-triforce-run-afl-on-everything/
 
+WinAFL (Ivan Fratric)
+---------------------
+
+  As the name implies, allows you to fuzz Windows binaries (using DynamoRio).
+
+  https://github.com/ivanfratric/winafl
+
 ----------------
 Network fuzzing:
 ----------------

docs/status_screen.txt

@@ -119,15 +119,19 @@ If you feel that the fuzzer is progressing too slowly, see the note about the
 ---------------
 
   +--------------------------------------+
-  |    map density : 4763 (29.07%)       |
+  |    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. Be wary of extremes:
+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.,
@@ -271,7 +275,7 @@ some of the more expensive deterministic fuzzing steps.
   |  pend fav : 583     |
   | own finds : 0       |
   |  imported : 0       |
-  |  variable : 0       |
+  | stability : 100.00% |
   +---------------------+
 
 The first field in this section tracks the path depth reached through the
@@ -291,27 +295,33 @@ 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
 number of inputs that produce seemingly variable behavior in the tested binary.
 
-That last bit is actually fairly interesting. There are four quasi-common
-explanations for variable behavior of the tested program:
+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 over 90%, the fuzzing process
+is still unlikely to be negatively affected. If it gets much lower, you may
+be in trouble, since AFL will have difficulty discerning between meaningful
+and "phantom" effects of tweaking the input file.
 
-  - Use of uninitialized memory in conjunction with some intrinsic sources of
-    entropy in the tested binary. This can be indicative of a security bug.
+Now, most targets will just get a 100% score, but when you see lower figures,
+there are several things to look at:
 
-  - Attempts to create files that were already created during previous runs, or
-    otherwise interact with some form of persistent state. This is harmless,
-    but you may want to instruct the targeted program to write to stdout or to
-    /dev/null to avoid surprises (and disable the creation of temporary files
-    and similar artifacts, if applicable).
+  - 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.
 
-  - Hitting functionality that is actually designed to behave randomly. For
-    example, when fuzzing sqlite, the fuzzer will dutifully detect variable
-    behavior once the mutation engine generates something like:
+  - 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.
 
-    select random();
+  - 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 usually
-    just a nuisance, but if the number of variable paths is very high, try the
-    following options:
+  - 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 llvm_mode/ - it uses a thread-local tracking
       model that is less prone to concurrency issues,
@@ -323,17 +333,10 @@ explanations for variable behavior of the tested program:
     - Replace pthreads with GNU Pth (https://www.gnu.org/software/pth/), which
       allows you to use a deterministic scheduler.
 
-Less likely causes may include running out of disk space, SHM handles, or other
-globally limited resources.
-
 The paths where variable behavior is detected are marked with a matching entry
 in the <out_dir>/queue/.state/variable_behavior/ directory, so you can look
 them up easily.
 
-If you can't suppress variable behavior and don't want to see these warnings,
-simply set AFL_NO_VAR_CHECK=1 in the environment before running afl-fuzz. This
-will also dramatically speed up session resumption.
-
 9) CPU load
 -----------
 
@@ -378,6 +381,7 @@ directory. This includes:
   - 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
+  - stability      - percentage of bitmap bytes that behave consistently
   - variable_paths - number of test cases showing variable behavior
   - unique_crashes - number of unique crashes recorded
   - unique_hangs   - number of unique hangs encountered

llvm_mode/README.llvm

@@ -163,8 +163,8 @@ wary of memory leaks and of the state of file descriptors.
 
 When running in this mode, the execution paths will inherently vary a bit
 depending on whether the input loop is being entered for the first time or
-executed again. To avoid spurious warnings, the feature implies 
-AFL_NO_VAR_CHECK and hides the "variable path" warnings in the UI.
+executed again. This can cause the "stability" metric in the UI to dip
+slightly under 100%.
 
 PS. Because there are task switches still involved, the mode isn't as fast as
 "pure" in-process fuzzing offered, say, by LLVM's LibFuzzer; but it is a lot