aboutsummaryrefslogtreecommitdiff
path: root/docs
diff options
context:
space:
mode:
authorllzmb <46303940+llzmb@users.noreply.github.com>2021-11-24 10:52:29 +0100
committerllzmb <46303940+llzmb@users.noreply.github.com>2021-11-24 10:52:29 +0100
commitf11cf068dca784831d1c70e95258e85f5b1e64eb (patch)
tree70900adee16a5b2b25a2bc328f45a1eb6d28ff73 /docs
parentc866e9c3ccef57d935cb296c8243cf8b40ffb564 (diff)
downloadafl++-f11cf068dca784831d1c70e95258e85f5b1e64eb.tar.gz
Merge "common_sense_risks.md" into "fuzzing_in_depth.md"
Diffstat (limited to 'docs')
-rw-r--r--docs/common_sense_risks.md36
-rw-r--r--docs/fuzzing_in_depth.md37
2 files changed, 37 insertions, 36 deletions
diff --git a/docs/common_sense_risks.md b/docs/common_sense_risks.md
deleted file mode 100644
index a8d68d7a..00000000
--- a/docs/common_sense_risks.md
+++ /dev/null
@@ -1,36 +0,0 @@
-# Common sense risks
-
-Please keep in mind that, similarly to many other computationally-intensive
-tasks, fuzzing may put a strain on your hardware and on the OS. In particular:
-
- - Your CPU will run hot and will need adequate cooling. In most cases, if
- cooling is insufficient or stops working properly, CPU speeds will be
- automatically throttled. That said, especially when fuzzing on less
- suitable hardware (laptops, smartphones, etc), it's not entirely impossible
- for something to blow up.
-
- - Targeted programs may end up erratically grabbing gigabytes of memory or
- filling up disk space with junk files. AFL++ tries to enforce basic memory
- limits, but can't prevent each and every possible mishap. The bottom line
- is that you shouldn't be fuzzing on systems where the prospect of data loss
- is not an acceptable risk.
-
- - Fuzzing involves billions of reads and writes to the filesystem. On modern
- systems, this will be usually heavily cached, resulting in fairly modest
- "physical" I/O - but there are many factors that may alter this equation.
- It is your responsibility to monitor for potential trouble; with very heavy
- I/O, the lifespan of many HDDs and SSDs may be reduced.
-
- A good way to monitor disk I/O on Linux is the 'iostat' command:
-
-```shell
- $ iostat -d 3 -x -k [...optional disk ID...]
-```
-
- Using the `AFL_TMPDIR` environment variable and a RAM-disk you can have the
- heavy writing done in RAM to prevent the aforementioned wear and tear. For
- example the following line will run a Docker container with all this preset:
-
- ```shell
- # docker run -ti --mount type=tmpfs,destination=/ramdisk -e AFL_TMPDIR=/ramdisk aflplusplus/aflplusplus
- ``` \ No newline at end of file
diff --git a/docs/fuzzing_in_depth.md b/docs/fuzzing_in_depth.md
index 4481bce6..19d8e783 100644
--- a/docs/fuzzing_in_depth.md
+++ b/docs/fuzzing_in_depth.md
@@ -13,6 +13,43 @@ Fuzzing source code is a three-step process:
3. Perform the fuzzing of the target by randomly mutating input and assessing if
a generated input was processed in a new path in the target binary.
+### 0. Common sense risks
+
+Please keep in mind that, similarly to many other computationally-intensive
+tasks, fuzzing may put a strain on your hardware and on the OS. In particular:
+
+- Your CPU will run hot and will need adequate cooling. In most cases, if
+ cooling is insufficient or stops working properly, CPU speeds will be
+ automatically throttled. That said, especially when fuzzing on less suitable
+ hardware (laptops, smartphones, etc.), it's not entirely impossible for
+ something to blow up.
+
+- Targeted programs may end up erratically grabbing gigabytes of memory or
+ filling up disk space with junk files. AFL++ tries to enforce basic memory
+ limits, but can't prevent each and every possible mishap. The bottom line is
+ that you shouldn't be fuzzing on systems where the prospect of data loss is
+ not an acceptable risk.
+
+- Fuzzing involves billions of reads and writes to the filesystem. On modern
+ systems, this will be usually heavily cached, resulting in fairly modest
+ "physical" I/O - but there are many factors that may alter this equation. It
+ is your responsibility to monitor for potential trouble; with very heavy I/O,
+ the lifespan of many HDDs and SSDs may be reduced.
+
+ A good way to monitor disk I/O on Linux is the `iostat` command:
+
+ ```shell
+ $ iostat -d 3 -x -k [...optional disk ID...]
+ ```
+
+ Using the `AFL_TMPDIR` environment variable and a RAM-disk, you can have the
+ heavy writing done in RAM to prevent the aforementioned wear and tear. For
+ example, the following line will run a Docker container with all this preset:
+
+ ```shell
+ # docker run -ti --mount type=tmpfs,destination=/ramdisk -e AFL_TMPDIR=/ramdisk aflplusplus/aflplusplus
+ ```
+
### 1. Instrumenting the target
#### a) Selecting the best AFL++ compiler for instrumenting the target