diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/QuickStartGuide.md | 14 | ||||
| -rw-r--r-- | docs/README.md | 8 | ||||
| -rw-r--r-- | docs/binaryonly_fuzzing.md | 2 | ||||
| -rw-r--r-- | docs/env_variables.md | 6 | ||||
| -rw-r--r-- | docs/historical_notes.md | 4 | ||||
| -rw-r--r-- | docs/life_pro_tips.md | 6 | ||||
| -rw-r--r-- | docs/parallel_fuzzing.md | 2 | ||||
| -rw-r--r-- | docs/status_screen.md | 2 |
8 files changed, 22 insertions, 22 deletions
diff --git a/docs/QuickStartGuide.md b/docs/QuickStartGuide.md index d5ad303e..f9e3b256 100644 --- a/docs/QuickStartGuide.md +++ b/docs/QuickStartGuide.md @@ -1,9 +1,9 @@ # AFL quick start guide -You should read docs/README.md - it's pretty short. If you really can't, here's +You should read [README.md](README.md) - it's pretty short. If you really can't, here's how to hit the ground running: -1) Compile AFL with 'make'. If build fails, see docs/INSTALL for tips. +1) Compile AFL with 'make'. If build fails, see [INSTALL.md](INSTALL.md) for tips. 2) Find or write a reasonably fast and simple program that takes data from a file or stdin, processes it in a test-worthy way, then exits cleanly. @@ -15,7 +15,7 @@ how to hit the ground running: The program must crash properly when a fault is encountered. Watch out for custom SIGSEGV or SIGABRT handlers and background processes. For tips on - detecting non-crashing flaws, see section 11 in docs/README.md . + detecting non-crashing flaws, see section 11 in [README.md](README.md) . 3) Compile the program / library to be fuzzed using afl-gcc. A common way to do this would be: @@ -38,7 +38,7 @@ how to hit the ground running: command line; AFL will put an auto-generated file name in there for you. 6) Investigate anything shown in red in the fuzzer UI by promptly consulting - docs/status_screen.txt. + [status_screen.md](status_screen.md). 7) compile and use llvm_mode (afl-clang-fast/afl-clang-fast++) as it is way faster and has a few cool features @@ -49,6 +49,6 @@ That's it. Sit back, relax, and - time permitting - try to skim through the following files: - README.md - A general introduction to AFL, - - docs/perf_tips.txt - Simple tips on how to fuzz more quickly, - - docs/status_screen.txt - An explanation of the tidbits shown in the UI, - - docs/parallel_fuzzing.md - Advice on running AFL on multiple cores. + - docs/perf_tips.md - Simple tips on how to fuzz more quickly, + - docs/status_screen.md - An explanation of the tidbits shown in the UI, + - docs/parallel_fuzzing.md - Advice on running AFL on multiple cores. diff --git a/docs/README.md b/docs/README.md index e926c956..3b572d42 100644 --- a/docs/README.md +++ b/docs/README.md @@ -315,7 +315,7 @@ contains a good example of the input data normally expected by the targeted application. There are two basic rules: - Keep the files small. Under 1 kB is ideal, although not strictly necessary. - For a discussion of why size matters, see [perf_tips.txt](docs/perf_tips.txt). + For a discussion of why size matters, see [perf_tips.md](docs/perf_tips.md). - Use multiple test cases only if they are functionally different from each other. There is no point in using fifty different vacation photos @@ -359,7 +359,7 @@ You can use -t and -m to override the default timeout and memory limit for the executed process; rare examples of targets that may need these settings touched include compilers and video decoders. -Tips for optimizing fuzzing performance are discussed in [perf_tips.txt](docs/perf_tips.txt). +Tips for optimizing fuzzing performance are discussed in [perf_tips.md](docs/perf_tips.md). Note that afl-fuzz starts by performing an array of deterministic fuzzing steps, which can take several days, but tend to produce neat test cases. If you @@ -369,7 +369,7 @@ fuzzers - add the -d option to the command line. ## 8) Interpreting output -See the [docs/status_screen.txt](docs/status_screen.txt) file for information on +See the [docs/status_screen.md](docs/status_screen.md) file for information on how to interpret the displayed stats and monitor the health of the process. Be sure to consult this file especially if any UI elements are highlighted in red. @@ -521,7 +521,7 @@ file, attempts to sequentially flip bytes, and observes the behavior of the tested program. It then color-codes the input based on which sections appear to be critical, and which are not; while not bulletproof, it can often offer quick insights into complex file formats. More info about its operation can be found -near the end of [docs/technical_details.txt](docs/technical_details.txt). +near the end of [docs/technical_details.md](docs/technical_details.md). ## 12) Going beyond crashes diff --git a/docs/binaryonly_fuzzing.md b/docs/binaryonly_fuzzing.md index 6eff30d7..ff98ed00 100644 --- a/docs/binaryonly_fuzzing.md +++ b/docs/binaryonly_fuzzing.md @@ -43,7 +43,7 @@ emulation. Runtime environment and/or loaders have to be written from scratch, if needed. On top, block chaining has been removed. This means the speed boost introduced in the patched QEMU Mode of afl++ cannot simply be ported over to - Unicorn. For further information, check out ./unicorn_mode.txt. + Unicorn. For further information, check out [unicorn_mode/README.md](../unicorn_mode/README.md). As it is included in afl++ this needs no URL. diff --git a/docs/env_variables.md b/docs/env_variables.md index 677a7b5f..ebfe12c2 100644 --- a/docs/env_variables.md +++ b/docs/env_variables.md @@ -22,7 +22,7 @@ tools make fairly broad use of environmental variables: - Setting AFL_USE_ASAN automatically enables ASAN, provided that your compiler supports that. Note that fuzzing with ASAN is mildly challenging - - see notes_for_asan.txt. + - see [notes_for_asan.md](notes_for_asan.md). (You can also enable MSAN via AFL_USE_MSAN; ASAN and MSAN come with the same gotchas; the modes are mutually exclusive. UBSAN and other exotic @@ -221,10 +221,10 @@ checks or alter some of the more exotic semantics of the tool: - Setting AFL_CUSTOM_MUTATOR_LIBRARY to a shared library with afl_custom_mutator() export run additional mutations though this library. If AFL_CUSTOM_MUTATOR_ONLY is also set, all mutations will solely be - performed with/from the libary. see docs/custom_mutator.txt + performed with/from the libary. see [custom_mutator.md](custom_mutator.md) - For AFL_PYTHON_MODULE and AFL_PYTHON_ONLY - they require to be compiled - with -DUSE_PYTHON. Please see docs/python_mutators.txt + with -DUSE_PYTHON. Please see [python_mutators.md](python_mutators.md) This feature allows to configure custom mutators which can be very helpful in e.g. fuzzing XML or other highly flexible structured input. diff --git a/docs/historical_notes.md b/docs/historical_notes.md index 2079698b..b5d3d157 100644 --- a/docs/historical_notes.md +++ b/docs/historical_notes.md @@ -40,7 +40,7 @@ coverage-driven fuzzer that relied on coverage as a fitness function. Jared's approach was by no means identical to what afl-fuzz does, but it was in the same ballpark. His fuzzer tried to explicitly solve for the maximum coverage with a single input file; in comparison, afl simply selects for cases that do -something new (which yields better results - see technical_details.txt). +something new (which yields better results - see [technical_details.md](technical_details.md)). A few years later, Gabriel Campana released fuzzgrind, a tool that relied purely on Valgrind and a constraint solver to maximize coverage without any brute-force @@ -133,7 +133,7 @@ several itches that seemed impossible to scratch with other tools: corpora of interesting test cases that can be fed into a manual testing process or a UI harness later on. -As mentioned in technical_details.txt, AFL does all this not by systematically +As mentioned in [technical_details.md](technical_details.md), AFL does all this not by systematically applying a single overarching CS concept, but by experimenting with a variety of small, complementary methods that were shown to reliably yields results better than chance. The use of instrumentation is a part of that toolkit, but is diff --git a/docs/life_pro_tips.md b/docs/life_pro_tips.md index 379ef70d..a0d90659 100644 --- a/docs/life_pro_tips.md +++ b/docs/life_pro_tips.md @@ -5,15 +5,15 @@ to read or memorize every other piece of documentation for AFL. ## Get more bang for your buck by using fuzzing dictionaries. -See dictionaries/README.md to learn how. +See [dictionaries/README.md](../dictionaries/README.md) to learn how. ## You can get the most out of your hardware by parallelizing AFL jobs. -See docs/parallel_fuzzing.md for step-by-step tips. +See [parallel_fuzzing.md](parallel_fuzzing.md) for step-by-step tips. ## Improve the odds of spotting memory corruption bugs with libdislocator.so! -It's easy. Consult libdislocator/README.md for usage tips. +It's easy. Consult [libdislocator/README.md](../libdislocator/README.md) for usage tips. ## Want to understand how your target parses a particular input file? diff --git a/docs/parallel_fuzzing.md b/docs/parallel_fuzzing.md index e6780125..0a2863fe 100644 --- a/docs/parallel_fuzzing.md +++ b/docs/parallel_fuzzing.md @@ -25,7 +25,7 @@ cases on the fly. Note that afl++ has AFLfast's power schedules implemented. It is therefore a good idea to use different power schedules if you run -several instances in parallel. See docs/power_schedules.txt +several instances in parallel. See [power_schedules.md](power_schedules.md) Alternatively running other AFL spinoffs in parallel can be of value, e.g. Angora (https://github.com/AngoraFuzzer/Angora/) diff --git a/docs/status_screen.md b/docs/status_screen.md index dd726c1d..1ea98415 100644 --- a/docs/status_screen.md +++ b/docs/status_screen.md @@ -218,7 +218,7 @@ most of the time - and if it stays below 100, the job will probably take very long. The fuzzer will explicitly warn you about slow targets, too. If this happens, -see the perf_tips.txt file included with the fuzzer for ideas on how to speed +see the [perf_tips.md](perf_tips.md) file included with the fuzzer for ideas on how to speed things up. ### Findings in depth |