|
6 | 6 | However, if there is only the binary program and no source code available,
|
7 | 7 | then standard `afl-fuzz -n` (non-instrumented mode) is not effective.
|
8 | 8 |
|
9 |
| - The following is a description of how these binaries can be fuzzed with afl++ |
| 9 | + The following is a description of how these binaries can be fuzzed with afl++. |
10 | 10 |
|
11 | 11 |
|
12 | 12 | ## TL;DR:
|
13 | 13 |
|
14 | 14 | qemu_mode in persistent mode is the fastest - if the stability is
|
15 | 15 | high enough. Otherwise try retrowrite, afl-dyninst and if these
|
16 |
| - fail too then standard qemu_mode with AFL_ENTRYPOINT to where you need it. |
| 16 | + fail too then try standard qemu_mode with AFL_ENTRYPOINT to where you need it. |
17 | 17 |
|
18 | 18 | If your target is a library use examples/afl_frida/.
|
19 | 19 |
|
|
29 | 29 |
|
30 | 30 | The speed decrease is at about 50%.
|
31 | 31 | However various options exist to increase the speed:
|
32 |
| - - using AFL_ENTRYPOINT to move the forkserver to a later basic block in |
| 32 | + - using AFL_ENTRYPOINT to move the forkserver entry to a later basic block in |
33 | 33 | the binary (+5-10% speed)
|
34 | 34 | - using persistent mode [qemu_mode/README.persistent.md](../qemu_mode/README.persistent.md)
|
35 |
| - this will result in 150-300% overall speed - so 3-8x the original |
| 35 | + this will result in 150-300% overall speed increase - so 3-8x the original |
36 | 36 | qemu_mode speed!
|
37 | 37 | - using AFL_CODE_START/AFL_CODE_END to only instrument specific parts
|
38 | 38 |
|
|
104 | 104 |
|
105 | 105 | ## RETROWRITE
|
106 | 106 |
|
107 |
| - If you have an x86/x86_64 binary that still has it's symbols, is compiled |
| 107 | + If you have an x86/x86_64 binary that still has its symbols, is compiled |
108 | 108 | with position independant code (PIC/PIE) and does not use most of the C++
|
109 | 109 | features then the retrowrite solution might be for you.
|
110 | 110 | It decompiles to ASM files which can then be instrumented with afl-gcc.
|
|
148 | 148 | ## CORESIGHT
|
149 | 149 |
|
150 | 150 | Coresight is ARM's answer to Intel's PT.
|
151 |
| - There is no implementation so far which handle coresight and getting |
| 151 | + There is no implementation so far which handles coresight and getting |
152 | 152 | it working on an ARM Linux is very difficult due to custom kernel building
|
153 | 153 | on embedded systems is difficult. And finding one that has coresight in
|
154 | 154 | the ARM chip is difficult too.
|
|
0 commit comments