ExternalVendorCode/AFLplusplus
1
0
Fork 0
mirror of https://github.com/AFLplusplus/AFLplusplus.git synced 2025-06-10 09:11:34 +00:00
Code Issues Packages Projects Releases Wiki Activity

Edit FAQ

Browse Source
This commit is contained in:
llzmb 2021-12-11 18:25:28 +01:00
parent 5ec91ad529
commit 4544a90b6e
1 changed files with 25 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
docs/FAQ.md
View File

@ -33,6 +33,19 @@ If you find an interesting or important question missing, submit it via
Report](https://www.fuzzbench.com/reports/2020-08-03/index.html).
</p></details>
<details>
<summary id="is-afl-a-whitebox-graybox-or-blackbox-fuzzer">Is AFL++ a whitebox, graybox, or blackbox fuzzer?</summary><p>
The definition of the terms whitebox, graybox, and blackbox fuzzing varies
from one source to another. For example, "graybox fuzzing" could mean
binary-only or source code fuzzing, or something completely different.
Therefore, we try to avoid them.
[The Fuzzing Book](https://www.fuzzingbook.org/html/GreyboxFuzzer.html#AFL:-An-Effective-Greybox-Fuzzer)
describes the original AFL to be a graybox fuzzer. In that sense, AFL++ is
also a graybox fuzzer.
</p></details>
<details>
<summary id="where-can-i-find-tutorials">Where can I find tutorials?</summary><p>
@ -126,6 +139,16 @@ If you find an interesting or important question missing, submit it via
## Performance
<details>
<summary id="what-makes-a-good-performance">What makes a good performance?</summary><p>
Good performance generally means "making the fuzzing results better". This can
be influenced by various factors, for example, speed (finding lots of paths
quickly) or thoroughness (working with decreased speed, but finding better
mutations).
</p></details>
<details>
<summary id="how-can-i-improve-the-fuzzing-speed">How can I improve the fuzzing speed?</summary><p>
@ -146,8 +169,8 @@ If you find an interesting or important question missing, submit it via
the edge coverage result will be different across runs. Those edges that
change are then flagged "unstable".
The more "unstable" edges, the more difficult for AFL++ to identify valid new
paths.
The more "unstable" edges there are, the harder it is for AFL++ to identify
valid new paths.
A value above 90% is usually fine and a value above 80% is also still ok, and
even a value above 20% can still result in successful finds of bugs. However,