| Roadmap 2.53d: |
| ============== |
| |
| all: |
| - indent all the code: .clang-format? |
| (vh: tried, the variable definion look very ugly then, what to do?) |
| |
| afl-fuzz: |
| - modularize: forkserver is in a module |
| others: |
| mutator - is deeply integrated and would loose performance if split |
| scheduler - is within this and as the values it operates on are afl |
| specific it does not make sense to seperate this |
| input - if we get different input vectors then this would make sense, |
| e.g. network (which we have seen is super non-performant and using |
| desock is much faster) |
| so for the moment we are done? (vh) |
| |
| docs/: |
| - update docs/sister_projects.txt |
| - doc + example for AFL_CUSTOM_MUTATOR_LIBRARY |
| |
| gcc_plugin: |
| - needs to be rewritten |
| - fix crashes when compiling :( |
| - whitelist support |
| - skip over uninteresting blocks |
| - laf-intel |
| - neverZero |
| |
| qemu_mode: |
| - update to 4.x |
| - deferred mode with AFL_DEFERRED_QEMU=0xaddress |
| (vh: @andrea - dont we have that already with AFL_ENTRYPOINT?) |
| |
| unit testing / or large testcase campaign |
| |
| |
| Roadmap 2.54d: |
| ============== |
| 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 at collisions at this # of edges: |
| 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 |
| Its 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 |
| 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 |
| |
| qemu_mode: |
| - persistent mode patching the return address (WinAFL style) |
| - instrument only comparison with immediate values by default when using compcov (done) |
| |
