about summary refs log tree commit diff
path: root/docs/fuzzing_in_depth.md
diff options
context:
space:
mode:
Diffstat (limited to 'docs/fuzzing_in_depth.md')
-rw-r--r--docs/fuzzing_in_depth.md20
1 files changed, 8 insertions, 12 deletions
diff --git a/docs/fuzzing_in_depth.md b/docs/fuzzing_in_depth.md
index 19d8e783..2365c6fd 100644
--- a/docs/fuzzing_in_depth.md
+++ b/docs/fuzzing_in_depth.md
@@ -336,22 +336,19 @@ target as possible improves the efficiency a lot.
 
 To operate correctly, the fuzzer requires one or more starting files that
 contain a good example of the input data normally expected by the targeted
-application. There are two basic rules:
+application.
 
-- Keep the files small. Under 1 kB is ideal, although not strictly necessary.
-  For a discussion of why size matters, see [perf_tips.md](perf_tips.md).
+Try to gather valid inputs for the target from wherever you can. E.g., if it is
+the PNG picture format, try to find as many PNG files as possible, e.g., from
+reported bugs, test suites, random downloads from the internet, unit test case
+data - from all kind of PNG software.
 
-- Use multiple test cases only if they are functionally different from each
-  other. There is no point in using fifty different vacation photos to fuzz an
-  image library.
+If the input format is not known, you can also modify a target program to write
+normal data it receives and processes to a file and use these.
 
 You can find many good examples of starting files in the
 [testcases/](../testcases) subdirectory that comes with this tool.
 
-PS. If a large corpus of data is available for screening, you may want to use
-the afl-cmin utility to identify a subset of functionally distinct files that
-exercise different code paths in the target binary.
-
 #### b) Making the input corpus unique
 
 Use the AFL++ tool `afl-cmin` to remove inputs from the corpus that do not
@@ -787,8 +784,7 @@ Another tool in AFL++ is the afl-analyze tool. It takes an input 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
-[technical_details.md](technical_details.md).
+complex file formats.
 
 ### The End