about summary refs log tree commit diff
path: root/TODO
blob: 23bf688b0e727b15e81020d49225ca62dc2f438d (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
Roadmap 2.54d:
==============

afl-fuzz:
 - enable python mutator for MOpt
 - enable custom mutator for MOpt
 - make custom mutator to call other mutators as well unless
   AFL_CUSTOM_MUTATOR_ONLY=1 is set
 - add superion?

remote feature



Roadmap 2.55d:
==============

gcc_plugin:
 - needs to be rewritten
 - whitelist support
 - skip over uninteresting blocks
 - laf-intel
 - neverZero

qemu_mode:
 - update to 4.x (probably this will be skipped :( )
 - instrim for QEMU mode via static analysis (with r2pipe? or angr?)
   Idea: The static analyzer outputs a map in which each edge that must be
   skipped is marked with 1. QEMU loads it at startup in the parent process.

unit testing / or large testcase campaign


The far away future:
====================

Problem: Average targets (tiff, jpeg, unrar) go through 1500 edges.
         At afl's default map that means ~16 collisions and ~3 wrappings.
  Solution #1: increase map size.
    every +1 decreases fuzzing speed by ~10% and halfs the collisions
    birthday paradox predicts collisions at this # of edges:
     mapsize => collisions
	2^16 = 302
	2^17 = 427
	2^18 = 603
	2^19 = 853
	2^20 = 1207
	2^21 = 1706
	2^22 = 2412
	2^23 = 3411
	2^24 = 4823
    Increasing the map is an easy solution but also not a good one.
  Solution #2: use dynamic map size and collision free basic block IDs
    This only works in llvm_mode and llvm >= 9 though
    A potential good future solution. Heiko/hexcoder follows this up
  Solution #3: write instruction pointers to a big shared map
    512kb/1MB shared map and the instrumented code writes the instruction
    pointer into the map. Map must be big enough but could be command line
    controlled.
    Good: complete coverage information, nothing is lost. choice of analysis
          impacts speed, but this can be decided by user options
    Neutral: a little bit slower but no loss of coverage
    Bad: completely changes how afl uses the map and the scheduling.
    Overall another very good solution, Marc Heuse/vanHauser follows this up