Update README to reflect AFL runner

[blt]

This commit updates the README to reflect the changes made to use
model-based fuzzing, as opposed to straight QuickCheck. This resolves

Signed-off-by: Brian L. Troutwine brian@troutwine.us

[blt]

@ReinierMaas relevant to your interests. Does this help?

[ReinierMaas]

Yes this is more relevant still some changes need to be made.

cargo build should be cargo afl build to make an instrumented binary.

in order to run afl i needed the following two incantations
sudo bash -c 'echo core > /proc/sys/kernel/core_pattern'
sudo bash -c 'echo performance | tee /sys/devices/system/cpu*/cpufreq/scaling_governor'

having created the tmp dir in the project folder (keeping it together):

mkdir -p tmp/repeat/in
mkdir -p tmp/repeat/out
date >> tmp/repeat/in/0000
date >> tmp/repeat/in/0001
date >> tmp/repeat/in/0002
date >> tmp/repeat/in/0003

When I run the following:
cargo afl fuzz -i tmp/repeat/in -o tmp/repeat/out target/debug/str_repeat

I get the following output:
$: afl-fuzz 2.52b by lcamtuf@google.com
$: [+] You have 8 CPU cores and 1 runnable tasks (utilization: 12%).
$: [+] Try parallel jobs - see docs/parallel_fuzzing.txt.
$: [] Checking CPU core loadout...
$: [+] Found a free CPU core, binding to #0.
$: [] Checking core_pattern...
$: [] Checking CPU scaling governor...
$: [] Setting up output directories...
$: [+] Output directory exists but deemed OK to reuse.
$: [] Deleting old session data...
$: [+] Output dir cleanup successful.
$: [] Scanning 'tmp/repeat/in'...
$: [+] No auto-generated dictionary tokens to reuse.
$: [] Creating hard links for all input files...
$: [] Validating target binary...
$: [+] Persistent mode binary detected.
$: [+] Deferred forkserver binary detected.
$: [] Attempting dry run with 'id:000000,orig:0000'...
$: [] Spinning up the fork server...
$:
$: [-] Whoops, the target binary crashed suddenly, before receiving any input
$: from the fuzzer! There are several probable explanations:
$:
$: - The current memory limit (50.0 MB) is too restrictive, causing the
$: target to hit an OOM condition in the dynamic linker. Try bumping up
$: the limit with the -m setting in the command line. A simple way confirm
$: this diagnosis would be:
$:
$: ( ulimit -Sv $[49 << 10]; /path/to/fuzzed_app )
$:
$: Tip: you can use http://jwilk.net/software/recidivm to quickly
$: estimate the required amount of virtual memory for the binary.
$:
$: - The binary is just buggy and explodes entirely on its own. If so, you
$: need to fix the underlying problem or find a better replacement.
$:
$: - Less likely, there is a horrible bug in the fuzzer. If other options
$: fail, poke lcamtuf@coredump.cx for troubleshooting tips.
$:
$: [-] PROGRAM ABORT : Fork server crashed with signal 11
$: Location : init_forkserver(), afl-fuzz.c:2201

Thank you for the support!

[blt]

@ReinierMaas what's the content of the file the target is crashing on? I can't find a crashing input.

[blt]

I'm going to go ahead and merge this up. It's already an improvement over the current state of things. We can refine for platform specific compile issues going forward.