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.