Lines Matching +refs:is +refs:effective +refs:target
9 …<summary id="what-is-the-difference-between-afl-and-aflplusplus">What is the difference between AF…
11 AFL++ is a superior fork to Google's AFL - more speed, more and better
18 however, it is only accepting PRs from the community and is not developing
31 in independent fuzzing benchmarks it is one of the best fuzzers available,
37 …<summary id="is-afl-a-whitebox-graybox-or-blackbox-fuzzer">Is AFL++ a whitebox, graybox, or blackb…
45 describes the original AFL to be a graybox fuzzer. In that sense, AFL++ is
57 <summary id="what-is-an-edge">What is an "edge"?</summary><p>
61 blocks`. A `basic block` is the **largest possible number of subsequent machine
84 Every code block between two jump locations is a `basic block`.
86 An `edge` is then the unique relationship between two directly connected
102 Every line between two blocks is an `edge`. Note that a few basic block loop
113 $ afl-cmin -T nproc -i out/default/queue -o minimized_queue -- ./target
114 …FL_FAST_CAL=1 AFL_CMPLOG_ONLY_NEW=1 afl-fuzz -i minimized_queue -o out2 [other options] -- ./target
117 If this improves fuzzing or not is debated and no consensus has been reached
121 * The queue/corpus is reduced (up to 20%) by removing intermediate paths
125 * Fuzzing time is lost for the time the fuzzing is stopped, minimized and
135 For honggfuzz in comparison it is a good idea to restart it from time to
145 …<summary id="how-can-i-fuzz-a-binary-only-target">How can I fuzz a binary-only target?</summary><p>
147 AFL++ is a great fuzzer if you have the source code available.
149 However, if there is only the binary program and no source code available,
150 then the standard non-instrumented mode is not effective.
159 The short answer is - you cannot, at least not "out of the box".
195 <summary id="why-is-my-stability-below-100percent">Why is my stability below 100%?</summary><p>
197 Stability is measured by how many percent of the edges in the target are
199 path through the target every time. If that is the case, the stability is
207 The more "unstable" edges there are, the harder it is for AFL++ to identify
211 harnesses, a large number of unstable edges can mean that the target keeps
212 internal state and therefore it is possible that crashes cannot be replayed.
218 A value above 90% is usually fine and a value above 80% is also still ok, and
220 it is recommended that for values below 90% or 80% you should take
230 Not every item in our queue/corpus is the same, some are more interesting,
232 A power schedule measures how "interesting" a value is, and depending on
237 effective and several more modes added.
239 The most effective modes are `-p fast` (default) and `-p explore`.
241 If you fuzz with several parallel afl-fuzz instances, then it is beneficial
253 …<summary id="fatal-forkserver-is-already-up-but-an-instrumented-dlopen-library-loaded-afterwards">…
255 It can happen that you see this error on startup when fuzzing a target:
258 [-] FATAL: forkserver is already up, but an instrumented dlopen() library
264 As the error describes, a dlopen() call is happening in the target that is
265 loading an instrumented library after the forkserver is already in place. This
266 is a problem for afl-fuzz because when the forkserver is started, we must know
269 The best solution is to simply set `AFL_PRELOAD=foo.so` to the libraries that
273 If this is not a viable option, you can set `AFL_IGNORE_PROBLEMS=1` but then
276 degraded. Note that there is additionally `AFL_IGNORE_PROBLEMS_COVERAGE` to
283 If you see this kind of error when trying to instrument a target with
314 Depending how the target works it might also crash afterwards.