2.31b

afl-fuzz.c

@@ -3906,7 +3906,7 @@ static void show_stats(void) {
 
   /* Honor AFL_EXIT_WHEN_DONE and AFL_BENCH_UNTIL_CRASH. */
 
-  if (!dumb_mode && cycles_wo_finds > 20 && !pending_not_fuzzed &&
+  if (!dumb_mode && cycles_wo_finds > 50 && !pending_not_fuzzed &&
       getenv("AFL_EXIT_WHEN_DONE")) stop_soon = 2;
 
   if (total_crashes && getenv("AFL_BENCH_UNTIL_CRASH")) stop_soon = 2;
@@ -3980,10 +3980,10 @@ static void show_stats(void) {
     if (queue_cycle == 1) strcpy(tmp, cMGN); else
 
     /* Subsequent cycles, but we're still making finds. */
-    if (cycles_wo_finds < 3) strcpy(tmp, cYEL); else
+    if (cycles_wo_finds < 5) strcpy(tmp, cYEL); else
 
     /* No finds for a long time and no test cases to try. */
-    if (cycles_wo_finds > 20 && !pending_not_fuzzed) strcpy(tmp, cLGN);
+    if (cycles_wo_finds > 50 && !pending_not_fuzzed) strcpy(tmp, cLGN);
 
     /* Default: cautiously OK to stop? */
     else strcpy(tmp, cLBL);
@@ -4881,7 +4881,7 @@ static u8 fuzz_one(char** argv) {
   u64 havoc_queued,  orig_hit_cnt, new_hit_cnt;
   u32 splice_cycle = 0, perf_score = 100, orig_perf, prev_cksum, eff_cnt = 1;
 
-  u8  ret_val = 1;
+  u8  ret_val = 1, doing_det = 0;
 
   u8  a_collect[MAX_AUTO_EXTRA];
   u32 a_len = 0;
@@ -5020,6 +5020,8 @@ static u8 fuzz_one(char** argv) {
   if (master_max && (queue_cur->exec_cksum % master_max) != master_id - 1)
     goto havoc_stage;
 
+  doing_det = 1;
+
   /*********************************************
    * SIMPLE BITFLIP (+dictionary construction) *
    *********************************************/
@@ -5126,8 +5128,6 @@ static u8 fuzz_one(char** argv) {
   stage_finds[STAGE_FLIP1]  += new_hit_cnt - orig_hit_cnt;
   stage_cycles[STAGE_FLIP1] += stage_max;
 
-  if (queue_cur->passed_det) goto havoc_stage;
-
   /* Two walking bits. */
 
   stage_name  = "bitflip 2/1";
@@ -5990,7 +5990,8 @@ static u8 fuzz_one(char** argv) {
 
     stage_name  = "havoc";
     stage_short = "havoc";
-    stage_max   = HAVOC_CYCLES * perf_score / havoc_div / 100;
+    stage_max   = (doing_det ? HAVOC_CYCLES_INIT : HAVOC_CYCLES) *
+                  perf_score / havoc_div / 100;
 
   } else {
 

config.h

@@ -21,7 +21,7 @@
 
 /* Version string: */
 
-#define VERSION             "2.30b"
+#define VERSION             "2.31b"
 
 /******************************************************
  *                                                    *
@@ -75,7 +75,8 @@
 
 /* Baseline number of random tweaks during a single 'havoc' stage: */
 
-#define HAVOC_CYCLES        5000
+#define HAVOC_CYCLES        256
+#define HAVOC_CYCLES_INIT   1024
 
 /* Maximum multiplier for the above (should be a power of two, beware
    of 32-bit int overflows): */
@@ -84,7 +85,7 @@
 
 /* Absolute minimum number of havoc cycles (after all adjustments): */
 
-#define HAVOC_MIN           10
+#define HAVOC_MIN           16
 
 /* Maximum stacking for havoc-stage tweaks. The actual value is calculated
    like this: 
@@ -114,11 +115,11 @@
 
 /* Splicing cycle count: */
 
-#define SPLICE_CYCLES       20
+#define SPLICE_CYCLES       16
 
 /* Nominal per-splice havoc cycle length: */
 
-#define SPLICE_HAVOC        500
+#define SPLICE_HAVOC        32
 
 /* Maximum offset for integer addition / subtraction stages: */
 

docs/ChangeLog

@@ -13,9 +13,23 @@ Want to stay in the loop on major new features? Join our mailing list by
 sending a mail to <[email protected]>.
 
 Not sure if you should upgrade? The lowest currently recommended version
-is 2.23b. If you're stuck on an earlier release, it's strongly advisable
+is 2.31b. If you're stuck on an earlier release, it's strongly advisable
 to get on with the times.
 
+--------------
+Version 2.31b:
+--------------
+
+  - Changed havoc cycle counts for a marked performance boost, especially
+    with -S / -d. See the discussion of FidgetyAFL in:
+
+    https://groups.google.com/forum/#!topic/afl-users/fOPeb62FZUg
+
+    While this does not implement the approach proposed by the authors of
+    the CCS paper, the solution is a result of digging into that research;
+    more improvements may follow as I do more experiments and get more
+    definitive data.
+
 --------------
 Version 2.30b:
 --------------

docs/README

@@ -190,8 +190,9 @@ include compilers and video decoders.
 Tips for optimizing fuzzing performance are discussed in perf_tips.txt.
 
 Note that afl-fuzz starts by performing an array of deterministic fuzzing
-steps, which can take several days. If you want quick & dirty results right
-away, akin to zzuf or honggfuzz, add the -d option to the command line.
+steps, which can take several days, but tend to produce neat test cases. If you
+want quick & dirty results right away - akin to zzuf and other traditional
+fuzzers - add the -d option to the command line.
 
 7) Interpreting output
 ----------------------
@@ -475,7 +476,8 @@ bug reports, or patches from:
   Austin Seipp                          Daniel Komaromy
   Daniel Binderman                      Jonathan Metzman
   Vegard Nossum                         Jan Kneschke
-  Kurt Roeckx
+  Kurt Roeckx                           Marcel Bohme
+  Van-Thuan Pham                        Abhik Roychoudhury
 
 Thank you!
 

docs/life_pro_tips.txt

@@ -121,3 +121,8 @@ Attacking a format that uses checksums? Remove the checksum-checking code or
 use a postprocessor! See experimental/post_library/ for more.
 
 %
+
+Dealing with a very slow target or hoping for instant results? Specify -d
+when calling afl-fuzz!
+
+%

docs/perf_tips.txt

@@ -186,5 +186,6 @@ using huge input files, or when you simply want to get quick and dirty results
 early on, you can always resort to the -d mode.
 
 The mode causes afl-fuzz to skip all the deterministic fuzzing steps, which
-makes output a lot less neat and makes the testing a bit less in-depth, but
-it will give you an experience more familiar from other fuzzing tools.
+makes output a lot less neat and can ultimately make the testing a bit less
+in-depth, but it will give you an experience more familiar from other fuzzing
+tools.