fix MDs

Makefile

@@ -410,17 +410,3 @@ endif
 	cp -r testcases/ $${DESTDIR}$(MISC_PATH)
 	cp -r dictionaries/ $${DESTDIR}$(MISC_PATH)
 
-#publish: clean
-#	test "`basename $$PWD`" = "afl" || exit 1
-#	test -f ~/www/afl/releases/$(PROGNAME)-$(VERSION).tgz; if [ "$$?" = "0" ]; then echo; echo "Change program version in config.h, mmkay?"; echo; exit 1; fi
-#	cd ..; rm -rf $(PROGNAME)-$(VERSION); cp -pr $(PROGNAME) $(PROGNAME)-$(VERSION); \
-#	  tar -cvz -f ~/www/afl/releases/$(PROGNAME)-$(VERSION).tgz $(PROGNAME)-$(VERSION)
-#	chmod 644 ~/www/afl/releases/$(PROGNAME)-$(VERSION).tgz
-#	( cd ~/www/afl/releases/; ln -s -f $(PROGNAME)-$(VERSION).tgz $(PROGNAME)-latest.tgz )
-#	cat docs/README.md >~/www/afl/README.txt
-#	cat docs/status_screen.txt >~/www/afl/status_screen.txt
-#	cat docs/historical_notes.txt >~/www/afl/historical_notes.txt
-#	cat docs/technical_details.txt >~/www/afl/technical_details.txt
-#	cat docs/ChangeLog >~/www/afl/ChangeLog.txt
-#	cat docs/QuickStartGuide.txt >~/www/afl/QuickStartGuide.txt
-#	echo -n "$(VERSION)" >~/www/afl/version.txt

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

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/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.

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

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.
 

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.
 

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

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?
 

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/)

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

examples/asan_cgroups/limit_memory.sh

@@ -20,7 +20,7 @@
 # This tool allows the amount of actual memory allocated to a program
 # to be limited on Linux systems using cgroups, instead of the traditional
 # setrlimit() API. This helps avoid the address space problems discussed in
-# docs/notes_for_asan.txt.
+# docs/notes_for_asan.md.
 #
 # Important: the limit covers *both* afl-fuzz and the fuzzed binary. In some
 # hopefully rare circumstances, afl-fuzz could be killed before the fuzzed

examples/custom_mutators/README

@@ -1,2 +1,2 @@
 This is a simple example for the AFL_CUSTOM_MUTATOR_LIBRARY feature.
-For more information see docs/custom_mutator.txt
+For more information see [docs/custom_mutator.md](../docs/custom_mutator.md)

examples/python_mutators/README

@@ -1,5 +1,5 @@
 These are example and helper files for the AFL_PYTHON_MODULE feature.
-See docs/python_mutators.txt for more information
+See [docs/python_mutators.md](../docs/python_mutators.md) for more information
 
 Note that if you compile with python3.7 you must use python3 scripts, and if
 you use pyton2.7 to compile python2 scripts!

gcc_plugin/README.md

@@ -56,7 +56,7 @@ standard operating mode of AFL, e.g.:
 Be sure to also include CXX set to afl-g++-fast for C++ code.
 
 The tool honors roughly the same environmental variables as afl-gcc (see
-../docs/env_variables.txt). This includes AFL_INST_RATIO, AFL_USE_ASAN,
+[env_variables.md](../docs/env_variables.md). This includes AFL_INST_RATIO, AFL_USE_ASAN,
 AFL_HARDEN, and AFL_DONT_OPTIMIZE.
 
 Note: if you want the GCC plugin to be installed on your system for all

llvm_mode/README.md

@@ -73,7 +73,7 @@ operating mode of AFL, e.g.:
 Be sure to also include CXX set to afl-clang-fast++ for C++ code.
 
 The tool honors roughly the same environmental variables as afl-gcc (see
-../docs/env_variables.txt). This includes AFL_USE_ASAN,
+[docs/env_variables.md](../docs/env_variables.md)). This includes AFL_USE_ASAN,
 AFL_HARDEN, and AFL_DONT_OPTIMIZE. However AFL_INST_RATIO is not honored
 as it does not serve a good purpose with the more effective instrim CFG
 analysis.

src/afl-forkserver.c

@@ -332,7 +332,7 @@ void init_forkserver(char **argv) {
            "have a\n"
            "    restrictive memory limit configured, this is expected; please "
            "read\n"
-           "    %s/notes_for_asan.txt for help.\n",
+           "    %s/notes_for_asan.md for help.\n",
            doc_path);
 
     } else if (!mem_limit) {
@@ -408,7 +408,7 @@ void init_forkserver(char **argv) {
          "with ASAN and\n"
          "    you have a restrictive memory limit configured, this is "
          "expected; please\n"
-         "    read %s/notes_for_asan.txt for help.\n",
+         "    read %s/notes_for_asan.md for help.\n",
          doc_path);
 
   } else if (!mem_limit) {

src/afl-fuzz-cmplog.c

@@ -217,7 +217,7 @@ void init_cmplog_forkserver(char** argv) {
            "have a\n"
            "    restrictive memory limit configured, this is expected; please "
            "read\n"
-           "    %s/notes_for_asan.txt for help.\n",
+           "    %s/notes_for_asan.md for help.\n",
            doc_path);
 
     } else if (!mem_limit) {
@@ -293,7 +293,7 @@ void init_cmplog_forkserver(char** argv) {
          "with ASAN and\n"
          "    you have a restrictive memory limit configured, this is "
          "expected; please\n"
-         "    read %s/notes_for_asan.txt for help.\n",
+         "    read %s/notes_for_asan.md for help.\n",
          doc_path);
 
   } else if (!mem_limit) {

src/afl-fuzz-init.c

@@ -601,7 +601,7 @@ void perform_dry_run(char** argv) {
                "quickly\n"
                "      estimate the required amount of virtual memory for the "
                "binary. Also,\n"
-               "      if you are using ASAN, see %s/notes_for_asan.txt.\n\n"
+               "      if you are using ASAN, see %s/notes_for_asan.md.\n\n"
 
                MSG_FORK_ON_APPLE
 

src/afl-fuzz-stats.c

@@ -747,7 +747,7 @@ void show_init_stats(void) {
   SAYF("\n");
 
   if (avg_us > ((qemu_mode || unicorn_mode) ? 50000 : 10000))
-    WARNF(cLRD "The target binary is pretty slow! See %s/perf_tips.txt.",
+    WARNF(cLRD "The target binary is pretty slow! See %s/perf_tips.md.",
           doc_path);
 
   /* Let's keep things moving with slow binaries. */
@@ -762,10 +762,10 @@ void show_init_stats(void) {
   if (!resuming_fuzz) {
 
     if (max_len > 50 * 1024)
-      WARNF(cLRD "Some test cases are huge (%s) - see %s/perf_tips.txt!",
+      WARNF(cLRD "Some test cases are huge (%s) - see %s/perf_tips.md!",
             DMS(max_len), doc_path);
     else if (max_len > 10 * 1024)
-      WARNF("Some test cases are big (%s) - see %s/perf_tips.txt.",
+      WARNF("Some test cases are big (%s) - see %s/perf_tips.md.",
             DMS(max_len), doc_path);
 
     if (useless_at_start && !in_bitmap)

src/afl-fuzz.c

@@ -96,7 +96,7 @@ static void usage(u8* argv0) {
       "score.\n"
       "                  <explore (default), fast, coe, lin, quad, or "
       "exploit>\n"
-      "                  see docs/power_schedules.txt\n"
+      "                  see docs/power_schedules.md\n"
       "  -f file       - location read by the fuzzed program (stdin)\n"
       "  -t msec       - timeout for each run (auto-scaled, 50-%d ms)\n"
       "  -m megs       - memory limit for child process (%d MB)\n"
@@ -145,7 +145,7 @@ static void usage(u8* argv0) {
       argv0, EXEC_TIMEOUT, MEM_LIMIT);
 
 #ifdef USE_PYTHON
-  SAYF("Compiled with %s module support, see docs/python_mutators.txt\n",
+  SAYF("Compiled with %s module support, see docs/python_mutators.md\n",
        (char*)PYTHON_VERSION);
 #endif