1.72b

Makefile

@@ -14,7 +14,7 @@
 #
 
 PROGNAME    = afl
-VERSION     = 1.71b
+VERSION     = 1.72b
 
 PREFIX     ?= /usr/local
 BIN_PATH    = $(PREFIX)/bin
@@ -108,11 +108,7 @@ clean:
 	rm -rf out_dir qemu_mode/qemu-2.2.0
 	$(MAKE) -C llvm_mode clean
 
-ifndef AFL_NOX86
 install: all
-else
-install: nox86
-endif
 	mkdir -p -m 755 $${DESTDIR}$(BIN_PATH) $${DESTDIR}$(HELPER_PATH) $${DESTDIR}$(DOC_PATH) $${DESTDIR}$(MISC_PATH)
 	rm -f $${DESTDIR}$(BIN_PATH)/afl-plot.sh
 	install -m 755 afl-gcc afl-fuzz afl-showmap afl-plot afl-tmin afl-cmin afl-gotcpu afl-whatsup $${DESTDIR}$(BIN_PATH)

docs/ChangeLog

@@ -16,6 +16,15 @@ Not sure if you should upgrade? The lowest currently recommended version
 is 1.48b. If you're stuck on an earlier release, it's strongly advisable
 to get on with the times.
 
+--------------
+Version 1.72b:
+--------------
+
+  - Fixed a glitch in non-x86 install, spotted by Tobias Ospelt.
+
+  - Added a minor safeguard to llvm_mode Makefile following a report from
+    Kai Zhao.
+
 --------------
 Version 1.71b:
 --------------

docs/historical_notes.txt

@@ -52,18 +52,18 @@ non-public, solver-based SAGE framework.
 
 In the past six years or so, I've also seen a fair number of academic papers
 that dealt with smart fuzzing (focusing chiefly on symbolic execution) and a
-couple papers that discussed proof-of-concept application of genetic
-algorithms. I'm unconvinced how practical most of these experiments were;
-I suspect that many of them suffer from the bunny-the-fuzzer's curse of being
-cool on paper and in carefully designed experiments, but failing the ultimate
-test of being able to find new, worthwhile security bugs in otherwise
-well-fuzzed, real-world software.
-
-In some ways, the baseline that such solutions had to compete against was a lot
-more impressive than usually acknowledged, making it difficult to truly stand
-out; for a singular example, check out the work by Gynvael and Mateusz Jurczyk,
-applying "dumb" fuzzing to ffmpeg, a prominent and security-critical component
-of modern browsers and media players:
+couple papers that discussed proof-of-concept applications of genetic
+algorithms with the same goals in mind. I'm unconvinced how practical most of
+these experiments were; I suspect that many of them suffer from the
+bunny-the-fuzzer's curse of being cool on paper and in carefully designed
+experiments, but failing the ultimate test of being able to find new,
+worthwhile security bugs in otherwise well-fuzzed, real-world software.
+
+In some ways, the baseline that the "cool" solutions have to compete against is
+a lot more impressive than it may seem, making it difficult for competitors to
+stand out. For a singular example, check out the work by Gynvael and Mateusz
+Jurczyk, applying "dumb" fuzzing to ffmpeg, a prominent and security-critical
+component of modern browsers and media players:
 
   http://googleonlinesecurity.blogspot.com/2014/01/ffmpeg-and-thousand-fixes.html
 
@@ -83,7 +83,8 @@ several itches that seemed impossible to scratch with other tools:
 
 1) Speed. It's genuinely hard to compete with brute force when your "smart"
    approach is resource-intensive. If your instrumentation makes it 10x more
-   likely to find a bug, but runs 100x slower, your users getting a bad deal.
+   likely to find a bug, but runs 100x slower, your users are getting a bad
+   deal.
 
    To avoid starting with a handicap, afl-fuzz is meant to let you fuzz most of
    the intended targets at roughly their native speed - so even if it doesn't
@@ -103,9 +104,8 @@ several itches that seemed impossible to scratch with other tools:
    Most of the approaches based on symbolic execution, taint tracking, or
    complex syntax-aware instrumentation are currently fairly unreliable with
    real-world targets. Perhaps more importantly, their failure modes can render
-   them strictly worse than "dumb" tools, and can be difficult for less
-   experienced users to notice and correct - giving them a false sense of
-   security.
+   them strictly worse than "dumb" tools, and such degradation can be difficult
+   for less experienced users to notice and correct.
 
    In contrast, afl-fuzz is designed to be rock solid, chiefly by keeping it
    simple. In fact, at its core, it's designed to be just a very good
@@ -130,7 +130,7 @@ several itches that seemed impossible to scratch with other tools:
    against resource-hungry or interaction-heavy tools, necessitating the
    creation of custom in-process fuzzers or the investment of massive CPU
    power (most of which is wasted on tasks not directly related to the code
-   we want to test).
+   we actually want to test).
 
    AFL tries to scratch this itch by allowing users to use more lightweight
    targets (e.g., standalone image parsing libraries) to create small

docs/sister_projects.txt

@@ -24,6 +24,13 @@ afl-fuzzing-scripts (Tobias Ospelt)
 
   https://github.com/floyd-fuh/afl-fuzzing-scripts/
 
+afl-crash-analyzer (Tobias Ospelt)
+----------------------------------
+
+  Makes it easier to navigate and annotate crashing test cases.
+
+  https://github.com/floyd-fuh/afl-crash-analyzer/
+
 Crashwalk (Ben Nagy)
 --------------------
 
@@ -98,6 +105,13 @@ Python AFL (Jakub Wilk)
 
   https://bitbucket.org/jwilk/python-afl
 
+Go-fuzz (Dmitry Vyukov)
+-----------------------
+
+  AFL-style guided fuzzing approach for Go targets:
+
+  https://github.com/dvyukov/go-fuzz
+
 -------------------------------
 Narrow-purpose or experimental:
 -------------------------------
@@ -129,3 +143,4 @@ Fuzzer shell for SQLite (Richard Hipp)
   A simple SQL shell designed specifically for fuzzing the underlying library.
 
   http://www.sqlite.org/src/artifact/9e7e273da2030371
+

docs/technical_details.txt

@@ -73,7 +73,7 @@ of tight loops (otherwise, A ^ A would be obviously equal to B ^ B).
 
 The absence of simple saturating arithmetic opcodes on Intel CPUs means that
 the hit counters can sometimes wrap around to zero. Since this is a fairly
-unlikely and localized event, it's an acceptable performance trade-off.
+unlikely and localized event, it's seen as an acceptable performance trade-off.
 
 2) Detecting new behaviors
 --------------------------
@@ -93,8 +93,9 @@ program state while not having to perform any computationally intensive and
 fragile global comparisons of complex execution traces, and while avoiding the
 scourge of path explosion.
 
-To illustrate, consider that the second trace shown below would be considered
-substantially new because of the presence of new tuples (CA, AE):
+To illustrate the properties of the algorithm, consider that the second trace
+shown below would be considered substantially new because of the presence of
+new tuples (CA, AE):
 
   #1: A -> B -> C -> D -> E
   #2: A -> B -> C -> A -> E

docs/vuln_samples/sqlite-bad-ptr2.sql

@@ -0,0 +1 @@
+PRAGMA foreign_keys=1;CREATE TABLE t1("""0"PRIMARY KEy REFERENCES t1 ON DELETE SET NULL);REPLACE INTO t1 SELECT(0);

docs/vuln_samples/sqlite-heap-overflow.sql

@@ -0,0 +1,2 @@
+DROP TABLE IF EXISTS t;CREATE VIRTUAL TABLE t0 USING fts4();insert into t0 select zeroblob(0);SAVEPOINT O;insert into t0
+select(0);SAVEPOINT E;insert into t0 SELECT 0 UNION SELECT 0'x'ORDER BY x;

docs/vuln_samples/sqlite-null-ptr14.sql

@@ -0,0 +1 @@
+CREATE VIRTUAL TABLE x USING fts4();VALUES(0,0),(0,0),(0,0),(0,0);PRAGMA writable_schema=ON;UPDATE sqlite_master SET sql=''WHERE name='';UPDATE sqlite_master SET sql='CREATE table t(d CHECK(T(#0)';SAVEPOINT K;SAVEPOINT T;SAVEPOINT T;ANALYZE;ROLLBACK;SAVEPOINT E;DROP TABLE IF EXISTS t;

docs/vuln_samples/sqlite-null-ptr15.sql

@@ -0,0 +1 @@
+CREATE VIRTUAL TABLE t4 USING fts4(0,b,c,notindexed=0);INSERT INTO t4 VALUES('','','0');BEGIN;INSERT INTO t4 VALUES('','','0');INSERT INTO t4(t4)VALUES('integrity-check');

llvm_mode/Makefile

@@ -72,7 +72,7 @@ test_deps:
 
 test_build: $(PROGS)
 	@echo "[*] Testing the CC wrapper and instrumentation output..."
-	unset AFL_USE_ASAN AFL_USE_MSAN; AFL_QUIET=1 AFL_INST_RATIO=100 AFL_PATH=. AFL_CC=$(CC) ../afl-clang-fast $(CFLAGS) ../test-instr.c -o test-instr $(LDFLAGS)
+	unset AFL_USE_ASAN AFL_USE_MSAN AFL_DEFER_FORKSRV; AFL_QUIET=1 AFL_INST_RATIO=100 AFL_PATH=. AFL_CC=$(CC) ../afl-clang-fast $(CFLAGS) ../test-instr.c -o test-instr $(LDFLAGS)
 	echo 0 | ../afl-showmap -m none -q -o .test-instr0 ./test-instr
 	echo 1 | ../afl-showmap -m none -q -o .test-instr1 ./test-instr
 	@rm -f test-instr