Roll AFL 2.31b:2.38b and switch coverage to use trace-pc-guard.

third_party/afl/src/docs/technical_details.txt

 ===================================
 Technical "whitepaper" for afl-fuzz
 ===================================
 
   This document provides a quick overview of the guts of American Fuzzy Lop.
   See README for the general instruction manual; and for a discussion of
   motivations and design goals behind AFL, see historical_notes.txt.
 
 0) Design statement
 -------------------
@@ skipping 261 matching lines @@
 impact on the execution path.
 
 The built-in trimmer in afl-fuzz attempts to sequentially remove blocks of data
 with variable length and stepover; any deletion that doesn't affect the checksum
 of the trace map is committed to disk. The trimmer is not designed to be
 particularly thorough; instead, it tries to strike a balance between precision
 and the number of execve() calls spent on the process, selecting the block size
 and stepover to match. The average per-file gains are around 5-20%.
 
 The standalone afl-tmin tool uses a more exhaustive, iterative algorithm, and
-also attempts to perform alphabet normalization on the trimmed files. 
+also attempts to perform alphabet normalization on the trimmed files. The
+operation of afl-tmin is as follows.
+
+First, the tool automatically selects the operating mode. If the initial input
+crashes the target binary, afl-tmin will run in non-instrumented mode, simply
+keeping any tweaks that produce a simpler file but still crash the target. If
+the target is non-crashing, the tool uses an instrumented mode and keeps only
+the tweaks that produce exactly the same execution path.
+
+The actual minimization algorithm is:
+
+  1) Attempt to zero large blocks of data with large stepovers. Empirically,
+     this is shown to reduce the number of execs by preempting finer-grained
+     efforts later on.
+
+  2) Perform a block deletion pass with decreasing block sizes and stepovers,
+     binary-search-style. 
+
+  3) Perform alphabet normalization by counting unique characters and trying
+     to bulk-replace each with a zero value.
+
+  4) As a last result, perform byte-by-byte normalization on non-zero bytes.
+
+Instead of zeroing with a 0x00 byte, afl-tmin uses the ASCII digit '0'. This
+is done because such a modification is much less likely to interfere with
+text parsing, so it is more likely to result in successful minimization of
+text files.
+
+The algorithm used here is less involved than some other test case
+minimization approaches proposed in academic work, but requires far fewer
+executions and tends to produce comparable results in most real-world
+applications.
 
 6) Fuzzing strategies
 ---------------------
 
 The feedback provided by the instrumentation makes it easy to understand the
 value of various fuzzing strategies and optimize their parameters so that they
 work equally well across a wide range of file types. The strategies used by
 afl-fuzz are generally format-agnostic and are discussed in more detail here:
 
   http://lcamtuf.blogspot.com/2014/08/binary-fuzzing-strategies-what-works.html
@@ skipping 230 matching lines @@
     unlikely. This is suggestive of a checksum or other "magic" integer.
 
   - "Suspected checksummed block" - a long block of data where any change 
     always triggers the same new execution path. Likely caused by failing
     a checksum or a similar integrity check before any subsequent parsing
     takes place.
 
   - "Magic value section" - a generic token where changes cause the type
     of binary behavior outlined earlier, but that doesn't meet any of the
     other criteria. May be an atomically compared keyword or so.