American fuzzy lop - a security-oriented fuzzer

Related tags

Miscellaneous AFL
Overview

american fuzzy lop

Build Status

Originally developed by Michal Zalewski [email protected].

See QuickStartGuide.txt if you don't have time to read this file.

1) Challenges of guided fuzzing

Fuzzing is one of the most powerful and proven strategies for identifying security issues in real-world software; it is responsible for the vast majority of remote code execution and privilege escalation bugs found to date in security-critical software.

Unfortunately, fuzzing is also relatively shallow; blind, random mutations make it very unlikely to reach certain code paths in the tested code, leaving some vulnerabilities firmly outside the reach of this technique.

There have been numerous attempts to solve this problem. One of the early approaches - pioneered by Tavis Ormandy - is corpus distillation. The method relies on coverage signals to select a subset of interesting seeds from a massive, high-quality corpus of candidate files, and then fuzz them by traditional means. The approach works exceptionally well, but requires such a corpus to be readily available. In addition, block coverage measurements provide only a very simplistic understanding of program state, and are less useful for guiding the fuzzing effort in the long haul.

Other, more sophisticated research has focused on techniques such as program flow analysis ("concolic execution"), symbolic execution, or static analysis. All these methods are extremely promising in experimental settings, but tend to suffer from reliability and performance problems in practical uses - and currently do not offer a viable alternative to "dumb" fuzzing techniques.

2) The afl-fuzz approach

American Fuzzy Lop is a brute-force fuzzer coupled with an exceedingly simple but rock-solid instrumentation-guided genetic algorithm. It uses a modified form of edge coverage to effortlessly pick up subtle, local-scale changes to program control flow.

Simplifying a bit, the overall algorithm can be summed up as:

  1. Load user-supplied initial test cases into the queue,

  2. Take next input file from the queue,

  3. Attempt to trim the test case to the smallest size that doesn't alter the measured behavior of the program,

  4. Repeatedly mutate the file using a balanced and well-researched variety of traditional fuzzing strategies,

  5. If any of the generated mutations resulted in a new state transition recorded by the instrumentation, add mutated output as a new entry in the queue.

  6. Go to 2.

The discovered test cases are also periodically culled to eliminate ones that have been obsoleted by newer, higher-coverage finds; and undergo several other instrumentation-driven effort minimization steps.

As a side result of the fuzzing process, the tool creates a small, self-contained corpus of interesting test cases. These are extremely useful for seeding other, labor- or resource-intensive testing regimes - for example, for stress-testing browsers, office applications, graphics suites, or closed-source tools.

The fuzzer is thoroughly tested to deliver out-of-the-box performance far superior to blind fuzzing or coverage-only tools.

3) Instrumenting programs for use with AFL

When source code is available, instrumentation can be injected by a companion tool that works as a drop-in replacement for gcc or clang in any standard build process for third-party code.

The instrumentation has a fairly modest performance impact; in conjunction with other optimizations implemented by afl-fuzz, most programs can be fuzzed as fast or even faster than possible with traditional tools.

The correct way to recompile the target program may vary depending on the specifics of the build process, but a nearly-universal approach would be:

$ CC=/path/to/afl/afl-gcc ./configure
$ make clean all

For C++ programs, you'd would also want to set CXX=/path/to/afl/afl-g++.

The clang wrappers (afl-clang and afl-clang++) can be used in the same way; clang users may also opt to leverage a higher-performance instrumentation mode, as described in llvm_mode/README.llvm.

When testing libraries, you need to find or write a simple program that reads data from stdin or from a file and passes it to the tested library. In such a case, it is essential to link this executable against a static version of the instrumented library, or to make sure that the correct .so file is loaded at runtime (usually by setting LD_LIBRARY_PATH). The simplest option is a static build, usually possible via:

$ CC=/path/to/afl/afl-gcc ./configure --disable-shared

Setting AFL_HARDEN=1 when calling 'make' will cause the CC wrapper to automatically enable code hardening options that make it easier to detect simple memory bugs. Libdislocator, a helper library included with AFL (see libdislocator/README.dislocator) can help uncover heap corruption issues, too.

PS. ASAN users are advised to review notes_for_asan.txt file for important caveats.

4) Instrumenting binary-only apps

When source code is NOT available, the fuzzer offers experimental support for fast, on-the-fly instrumentation of black-box binaries. This is accomplished with a version of QEMU running in the lesser-known "user space emulation" mode.

QEMU is a project separate from AFL, but you can conveniently build the feature by doing:

$ cd qemu_mode
$ ./build_qemu_support.sh

For additional instructions and caveats, see qemu_mode/README.qemu.

The mode is approximately 2-5x slower than compile-time instrumentation, is less conducive to parallelization, and may have some other quirks.

5) Choosing initial test cases

To operate correctly, the fuzzer requires one or more starting file that 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.

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

You can find many good examples of starting files in the 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.

6) Fuzzing binaries

The fuzzing process itself is carried out by the afl-fuzz utility. This program requires a read-only directory with initial test cases, a separate place to store its findings, plus a path to the binary to test.

For target binaries that accept input directly from stdin, the usual syntax is:

$ ./afl-fuzz -i testcase_dir -o findings_dir /path/to/program [...params...]

For programs that take input from a file, use '@@' to mark the location in the target's command line where the input file name should be placed. The fuzzer will substitute this for you:

$ ./afl-fuzz -i testcase_dir -o findings_dir /path/to/program @@

You can also use the -f option to have the mutated data written to a specific file. This is useful if the program expects a particular file extension or so.

Non-instrumented binaries can be fuzzed in the QEMU mode (add -Q in the command line) or in a traditional, blind-fuzzer mode (specify -n).

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.

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 want quick & dirty results right away - akin to zzuf and other traditional fuzzers - add the -d option to the command line.

7) Interpreting output

See the status_screen.txt 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.

The fuzzing process will continue until you press Ctrl-C. At minimum, you want to allow the fuzzer to complete one queue cycle, which may take anywhere from a couple of hours to a week or so.

There are three subdirectories created within the output directory and updated in real time:

  • queue/ - test cases for every distinctive execution path, plus all the starting files given by the user. This is the synthesized corpus mentioned in section 2. Before using this corpus for any other purposes, you can shrink it to a smaller size using the afl-cmin tool. The tool will find a smaller subset of files offering equivalent edge coverage.

  • crashes/ - unique test cases that cause the tested program to receive a fatal signal (e.g., SIGSEGV, SIGILL, SIGABRT). The entries are grouped by the received signal.

  • hangs/ - unique test cases that cause the tested program to time out. The default time limit before something is classified as a hang is the larger of 1 second and the value of the -t parameter. The value can be fine-tuned by setting AFL_HANG_TMOUT, but this is rarely necessary.

Crashes and hangs are considered "unique" if the associated execution paths involve any state transitions not seen in previously-recorded faults. If a single bug can be reached in multiple ways, there will be some count inflation early in the process, but this should quickly taper off.

The file names for crashes and hangs are correlated with parent, non-faulting queue entries. This should help with debugging.

When you can't reproduce a crash found by afl-fuzz, the most likely cause is that you are not setting the same memory limit as used by the tool. Try:

$ LIMIT_MB=50
$ ( ulimit -Sv $[LIMIT_MB << 10]; /path/to/tested_binary ... )

Change LIMIT_MB to match the -m parameter passed to afl-fuzz. On OpenBSD, also change -Sv to -Sd.

Any existing output directory can be also used to resume aborted jobs; try:

$ ./afl-fuzz -i- -o existing_output_dir [...etc...]

If you have gnuplot installed, you can also generate some pretty graphs for any active fuzzing task using afl-plot. For an example of how this looks like, see http://lcamtuf.coredump.cx/afl/plot/.

8) Parallelized fuzzing

Every instance of afl-fuzz takes up roughly one core. This means that on multi-core systems, parallelization is necessary to fully utilize the hardware. For tips on how to fuzz a common target on multiple cores or multiple networked machines, please refer to parallel_fuzzing.txt.

The parallel fuzzing mode also offers a simple way for interfacing AFL to other fuzzers, to symbolic or concolic execution engines, and so forth; again, see the last section of parallel_fuzzing.txt for tips.

9) Fuzzer dictionaries

By default, afl-fuzz mutation engine is optimized for compact data formats - say, images, multimedia, compressed data, regular expression syntax, or shell scripts. It is somewhat less suited for languages with particularly verbose and redundant verbiage - notably including HTML, SQL, or JavaScript.

To avoid the hassle of building syntax-aware tools, afl-fuzz provides a way to seed the fuzzing process with an optional dictionary of language keywords, magic headers, or other special tokens associated with the targeted data type -- and use that to reconstruct the underlying grammar on the go:

http://lcamtuf.blogspot.com/2015/01/afl-fuzz-making-up-grammar-with.html

To use this feature, you first need to create a dictionary in one of the two formats discussed in dictionaries/README.dictionaries; and then point the fuzzer to it via the -x option in the command line.

(Several common dictionaries are already provided in that subdirectory, too.)

There is no way to provide more structured descriptions of the underlying syntax, but the fuzzer will likely figure out some of this based on the instrumentation feedback alone. This actually works in practice, say:

http://lcamtuf.blogspot.com/2015/04/finding-bugs-in-sqlite-easy-way.html

PS. Even when no explicit dictionary is given, afl-fuzz will try to extract existing syntax tokens in the input corpus by watching the instrumentation very closely during deterministic byte flips. This works for some types of parsers and grammars, but isn't nearly as good as the -x mode.

If a dictionary is really hard to come by, another option is to let AFL run for a while, and then use the token capture library that comes as a companion utility with AFL. For that, see libtokencap/README.tokencap.

10) Crash triage

The coverage-based grouping of crashes usually produces a small data set that can be quickly triaged manually or with a very simple GDB or Valgrind script. Every crash is also traceable to its parent non-crashing test case in the queue, making it easier to diagnose faults.

Having said that, it's important to acknowledge that some fuzzing crashes can be difficult to quickly evaluate for exploitability without a lot of debugging and code analysis work. To assist with this task, afl-fuzz supports a very unique "crash exploration" mode enabled with the -C flag.

In this mode, the fuzzer takes one or more crashing test cases as the input, and uses its feedback-driven fuzzing strategies to very quickly enumerate all code paths that can be reached in the program while keeping it in the crashing state.

Mutations that do not result in a crash are rejected; so are any changes that do not affect the execution path.

The output is a small corpus of files that can be very rapidly examined to see what degree of control the attacker has over the faulting address, or whether it is possible to get past an initial out-of-bounds read - and see what lies beneath.

Oh, one more thing: for test case minimization, give afl-tmin a try. The tool can be operated in a very simple way:

$ ./afl-tmin -i test_case -o minimized_result -- /path/to/program [...]

The tool works with crashing and non-crashing test cases alike. In the crash mode, it will happily accept instrumented and non-instrumented binaries. In the non-crashing mode, the minimizer relies on standard AFL instrumentation to make the file simpler without altering the execution path.

The minimizer accepts the -m, -t, -f and @@ syntax in a manner compatible with afl-fuzz.

Another recent addition to 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.txt.

11) Going beyond crashes

Fuzzing is a wonderful and underutilized technique for discovering non-crashing design and implementation errors, too. Quite a few interesting bugs have been found by modifying the target programs to call abort() when, say:

  • Two bignum libraries produce different outputs when given the same fuzzer-generated input,

  • An image library produces different outputs when asked to decode the same input image several times in a row,

  • A serialization / deserialization library fails to produce stable outputs when iteratively serializing and deserializing fuzzer-supplied data,

  • A compression library produces an output inconsistent with the input file when asked to compress and then decompress a particular blob.

Implementing these or similar sanity checks usually takes very little time; if you are the maintainer of a particular package, you can make this code conditional with #ifdef FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION (a flag also shared with libfuzzer) or #ifdef __AFL_COMPILER (this one is just for AFL).

12) Common-sense risks

Please keep in mind that, similarly to many other computationally-intensive tasks, fuzzing may put 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:

    $ iostat -d 3 -x -k [...optional disk ID...]

13) Known limitations & areas for improvement

Here are some of the most important caveats for AFL:

  • AFL detects faults by checking for the first spawned process dying due to a signal (SIGSEGV, SIGABRT, etc). Programs that install custom handlers for these signals may need to have the relevant code commented out. In the same vein, faults in child processed spawned by the fuzzed target may evade detection unless you manually add some code to catch that.

  • As with any other brute-force tool, the fuzzer offers limited coverage if encryption, checksums, cryptographic signatures, or compression are used to wholly wrap the actual data format to be tested.

    To work around this, you can comment out the relevant checks (see experimental/libpng_no_checksum/ for inspiration); if this is not possible, you can also write a postprocessor, as explained in experimental/post_library/.

  • There are some unfortunate trade-offs with ASAN and 64-bit binaries. This isn't due to any specific fault of afl-fuzz; see notes_for_asan.txt for tips.

  • There is no direct support for fuzzing network services, background daemons, or interactive apps that require UI interaction to work. You may need to make simple code changes to make them behave in a more traditional way. Preeny may offer a relatively simple option, too - see: https://github.com/zardus/preeny

    Some useful tips for modifying network-based services can be also found at: https://www.fastly.com/blog/how-to-fuzz-server-american-fuzzy-lop

  • AFL doesn't output human-readable coverage data. If you want to monitor coverage, use afl-cov from Michael Rash: https://github.com/mrash/afl-cov

  • Occasionally, sentient machines rise against their creators. If this happens to you, please consult http://lcamtuf.coredump.cx/prep/.

Beyond this, see INSTALL for platform-specific tips.

14) Special thanks

Many of the improvements to afl-fuzz wouldn't be possible without feedback, bug reports, or patches from:

  Jann Horn                             Hanno Boeck
  Felix Groebert                        Jakub Wilk
  Richard W. M. Jones                   Alexander Cherepanov
  Tom Ritter                            Hovik Manucharyan
  Sebastian Roschke                     Eberhard Mattes
  Padraig Brady                         Ben Laurie
  @dronesec                             Luca Barbato
  Tobias Ospelt                         Thomas Jarosch
  Martin Carpenter                      Mudge Zatko
  Joe Zbiciak                           Ryan Govostes
  Michael Rash                          William Robinet
  Jonathan Gray                         Filipe Cabecinhas
  Nico Weber                            Jodie Cunningham
  Andrew Griffiths                      Parker Thompson
  Jonathan Neuschfer                    Tyler Nighswander
  Ben Nagy                              Samir Aguiar
  Aidan Thornton                        Aleksandar Nikolich
  Sam Hakim                             Laszlo Szekeres
  David A. Wheeler                      Turo Lamminen
  Andreas Stieger                       Richard Godbee
  Louis Dassy                           teor2345
  Alex Moneger                          Dmitry Vyukov
  Keegan McAllister                     Kostya Serebryany
  Richo Healey                          Martijn Bogaard
  rc0r                                  Jonathan Foote
  Christian Holler                      Dominique Pelle
  Jacek Wielemborek                     Leo Barnes
  Jeremy Barnes                         Jeff Trull
  Guillaume Endignoux                   ilovezfs
  Daniel Godas-Lopez                    Franjo Ivancic
  Austin Seipp                          Daniel Komaromy
  Daniel Binderman                      Jonathan Metzman
  Vegard Nossum                         Jan Kneschke
  Kurt Roeckx                           Marcel Bohme
  Van-Thuan Pham                        Abhik Roychoudhury
  Joshua J. Drake                       Toby Hutton
  Rene Freingruber                      Sergey Davidoff
  Sami Liedes                           Craig Young
  Andrzej Jackowski                     Daniel Hodson

Thank you!

15) Contact

Questions? Concerns? Bug reports? Please use GitHub.

There is also a mailing list for the project; to join, send a mail to [email protected]. Or, if you prefer to browse archives first, try: https://groups.google.com/group/afl-users.

Comments
  • afl: Fix afl-qemu build by applying new patches

    afl: Fix afl-qemu build by applying new patches

    These patches are gathered from different sources, see also below. The other patch is required because some implicitly included files are not included anymore, requiring an explicit include of <linux/sockios.h>. This solves issue #41.

    Build errors include: SIOCGSTAMP not declared, SIOCGSTAMPNS not declared and static declaration of ‘gettid’ follows non-static declaration

    See also:

    • https://github.com/qemu/qemu/commit/71ba74f67eaca21b0cc9d96f534ad3b9a7161400
    • https://github.com/qemu/qemu/commit/6d5d5dde9adb5acb32e6b8e3dfbf47fff0f308d2
    • https://lkml.org/lkml/2019/6/3/988
    • https://patchwork.kernel.org/patch/10862231/

    It would be great if someone could verify this (or help me verify it), I'm not using the qemu build. Main goal is to make sure afl keeps building in the NixOS repositories for anyone that wants to be able to use the QEMU mode.

    opened by Mindavi 11
  • Fix 'has_new_bits' function

    Fix 'has_new_bits' function

    In function 'has_new_bits' were fixed following points:

    • new hit counts bucket detection;
    • virgin bits update.

    Let's consider the following case. Before another program start we have: virgin_map[100] = 0xff // '100' is chosen just for example Let's say after run we have: trace_bits[100] = 0xff // > 128, i.e. we got into 7th hit counts bucket (128+) After 'has_new_bits' was called: virgin_map[100] = 0x00 and we will not ever detect any bucket, despite we hit in only one bucket during all program runs.

    In fact, we must update virgin_map so as: virgin_map[100] = 0x8f It is somewhat extreme example, but current 'has_new_bits' realization causes loss of some new testcases (following new path criterion from white paper) and in some cases it causes save extra entries in queue (such cases were not considered here).

    And that is a fix.

    opened by wakolzin 10
  • `./build_qemu_support.sh` broken on debian buster

    `./build_qemu_support.sh` broken on debian buster

    When I compile on debian buster (I used dockerhub), qemu fails to build due a conflict with memfd_create (perhaps due to newer libc's including this name). I've not been following qemu dev, so it could just be the version used by AFL needs to be updated.

    Here is the build error:

     CC      util/memfd.o
    util/memfd.c:40:12: error: static declaration of 'memfd_create' follows non-static declaration
     static int memfd_create(const char *name, unsigned int flags)
                ^~~~~~~~~~~~
    In file included from /usr/include/x86_64-linux-gnu/bits/mman-linux.h:117,
                     from /usr/include/x86_64-linux-gnu/bits/mman.h:49,
                     from /usr/include/x86_64-linux-gnu/sys/mman.h:41,
                     from /workdir/AFL-2.53b/qemu_mode/qemu-2.10.0/include/sysemu/os-posix.h:29,
                     from /workdir/AFL-2.53b/qemu_mode/qemu-2.10.0/include/qemu/osdep.h:104,
                     from util/memfd.c:28:
    /usr/include/x86_64-linux-gnu/bits/mman-shared.h:46:5: note: previous declaration of 'memfd_create' was here
     int memfd_create (const char *__name, unsigned int __flags) __THROW;
         ^~~~~~~~~~~~
    make: *** [/workdir/AFL-2.53b/qemu_mode/qemu-2.10.0/rules.mak:66: util/memfd.o] Error 1
    

    (Sorry for no patch; limit time :( )

    opened by dbrumley 10
  • LLVM trace-pc mode build failed using Clang 10.0.0-svn371489

    LLVM trace-pc mode build failed using Clang 10.0.0-svn371489

    I was trying AFL-2.54b with the LLVM trace_pc_guard feature, however it failed to build with LLVM 10.0.0-svn371489 (of course, I commented out -sanitizer-coverage-block-threshold=0 related lines in afl-clang-fast.c).

    The error message is like: 2019-09-11-215509_958x610_scrot

    So it turns out that the execution traces are unexpectedly the same when the inputs are 0 and 1, which can be confirmed by observing the following results: 2019-09-11-225007_355x150_scrot

    I got LLVM/Clang from https://apt.llvm.org (Ubuntu 18.04.2 LTS).

    I also tried building AFL-2.54b with LLVM-4.0, where there are no issues for builds, and the trace_pc_mode seems working on projects such as exiv2.

    Meanwhile, I tried AFLplusplus with the same LLVM/Clang build tools (v10.0), it builds and tests without errors, despite that compared to AFL-2.54b I can see no big changes for the trace_pc_guard feature.

    opened by hongxuchen 9
  • qemu_mode: redesign for increased performance

    qemu_mode: redesign for increased performance

    Instead of requiring qemu to return to its outer emulation loop for every TranslationBlock's execution and deciding whether to record each execution at runtime, decide whether to instrument each TB with a call to a TCG "helper function" at IR generation time.

    This means we can remove the qemu nochain option, re-enabling block chaining, one of TCG's most important performance features. Without block chaining, qemu has to spill all its registers, look up the next TB and then re-pack registers for every basic block it comes across, both in uninteresting/library code and in interesting/executable code.

    This results in a 3-4x speedup for my use case. I'd love for people to have a go and see how it works for them.

    (I suspect there is probably also room for a more aggressive mode which forwards last_tb information down the "translation request" pipeline, allowing the already-chained blocks to be pre-generated by the forkserver too, though I think this is not guaranteed safe for all cases which e.g. modify executable areas or use dlopen to load code at runtime)

    opened by risicle 8
  • Fix counting stage execs for user inserts

    Fix counting stage execs for user inserts

    Pretty obvious, because of the number of iterations of the outer loop few lines later:

    for (i = 0; i <= len; i++) {

    Without the fix the progress can (and does for me) go over 100% otherwise.

    opened by baryluk 7
  • afl-clang-fast: remove useless codes related to maybe_linking

    afl-clang-fast: remove useless codes related to maybe_linking

    Now that the maybe_linking check is removed in afl-clang-fast.c, maybe it is better to remove useless codes caused by it since maybe_linking is now defined but not used.

    I think in the old code, "maybe_linking" should not be set to zero on seeing the "-shared" argument because dynamic libraries should also statically link the AFL runtime into themselves. But now that the maybe_linking variable is removed, it is no more a problem.

    Besides, the code 'if (argc == 1 && !strcmp(argv[1], "-v")) maybe_linking = 0;' in line 146 itself is useless regardless of the maybe_linking variable because in main() we have check "if argc < 2, then exit".

    opened by QinlinChen 6
  • afl-clang*-fast toolchains built with clang from source fails `test_build`

    afl-clang*-fast toolchains built with clang from source fails `test_build`

    Hi, I was trying to build afl-clang*-fast toolchains using clang built from source.The compiler wrappers do build successfully, however they fail at the test_build with the following error:

    clang (LLVM option parsing): Unknown command line argument '-sanitizer-coverage-block-threshold=0'.  Try: 'clang (LLVM option parsing) --help'
    clang (LLVM option parsing): Did you mean '  --sanitizer-coverage-pc-table=0'?
    

    The error does indeed stop occuring if I make the mentioned fix in afl-clang-fast.c. However, from what I understand these are two completely different flags. The original flags is associated with inlining instrumentation callbacks and the pc-table flag refers to a feature where PC's corresponding to function/non-function entry blocks is made as a pre-processing step.

    My clang version which I built from source is:

    clang version 10.0.0 ([email protected]:llvm-mirror/clang.git 65acf43270ea2894dffa0d0b292b92402f80c8cb) ([email protected]:llvm-mirror/llvm.git 2c4ca6832fa6b306ee6a7010bfb80a3f2596f824)
    Target: x86_64-unknown-linux-gnu
    

    The command I am using to build llvm_mode is: AFL_TRACE_PC=1 CC=/path/to/built/clang CXX=/path/to/built/clang++ make -C llvm_mode clean all

    opened by prashast 6
  • fix a little mistake, maybe...

    fix a little mistake, maybe...

    Thanks for reading this pr . When I learn AFL source code, I found a little mistake. In afl-fuzz.c, If shmat fail, it will return -1. Soif (!trace_bits) PFATAL("shmat() failed"); will not run.

    http://man7.org/linux/man-pages/man2/shmget.2.html

       On success, a valid shared memory identifier is returned.  On error, -1 is returned, and errno is set to indicate the error.
    
    opened by ssdemajia 6
  • Fix compilation errors for QEMU mode for recent glibc

    Fix compilation errors for QEMU mode for recent glibc

    As explained in QEMU git commit 75e5b70e6b5dcc4f2219992d7cffa462aa406af0 (https://git.qemu.org/?p=qemu.git;a=commitdiff;h=75e5b70e6b5dcc4f2219992d7cffa462aa406af0), recent versions of the glibc add memfd_create, which creates conflicts at compile time for QEMU 2.10.

    This can be fixed by adding a pair of patches when building QEMU with AFL support.

    opened by pietroferretti 6
  • Revamp documentation

    Revamp documentation

    You can preview the newly built docs here: https://afl-1.readthedocs.io/en/latest/

    Let's have some more modern documentation rather than just dozens of .txt files. I've kept Michael's original philosophy though and made sure the plaintext files are easy to read as well.

    I've chosen Sphinx because it's a popular choice (used by other Google projects as well: kmsan, python-fire) and lets us use readthedocs to keep our docs automatically updated and publicly available.

    This also greatly reduces the cruft in the README, we should add some more stuff there separately.

    opened by ammaraskar 6
  • Is it necessary to put the

    Is it necessary to put the "-fsanitize-undefined-trap-on-error" flag when using AFL with UBSan?

    I am building a C project in this way:

    make CC=afl-gcc CFLAGS="-g -fsanitize=undefined" The goal is to detect undefined behavior bugs with AFL. Do I also have to put "-fsanitize-undefined-trap-on-error" in CFLAGS?

    %afl-gcc version
    afl-cc++2.68c by Michal Zalewski
    
    opened by zhoulaifu 0
  • Communication issues with parent-child processes

    Communication issues with parent-child processes

    The following error occurs during the execution of AFL:

    [-] PROGRAM ABORT: read: Unable to request new process from fork Server (OOM?)
    Location: run_target (), the afl - fuzz. C: 2530
    

    So I print the return value of read() res = 0, which means nothing is read. When I check the write(), it does write the child id of the new fork correctly. What would cause afl-fuzz to return a value of 0?

    opened by kimiwanano 1
  • How to let AFL ignore certain expected abort() situations?

    How to let AFL ignore certain expected abort() situations?

    I am testing GNU Scientific Library (GSL) with AFL. Mathematical functions in GSL usually expect inputs to be within certain ranges. For example, a square root function expects nonnegative inputs. If the input goes out of the expected range, GSL invokes an error handler which prints out error messages and then invokes the abort() function.

    How can I ask AFL to ignore crashes that are due to these kinds of crashes triggered by expected invalid inputs? With GSL, one can write a customized error handler. So I am trying to come up with an error handler that looks like this:

    <some_type> gsl_error_handler(){
        // ask afl to not consider the following abort() as a unique crash
        abort();
    }
    

    The question is how to fill the part with "//" above. Note that if I simply create an error handler that does nothing would be problematic too due to other issues, so the abort() above has to be there in the error handler.

    opened by zhoulaifu 0
  • llvm_mode doesn't seem to support Clang 13

    llvm_mode doesn't seem to support Clang 13

    When running make -C llvm_mode, it generates some deprecation warnings and fails the test:

    $ clang --version
    Debian clang version 13.0.1-3
    Target: x86_64-pc-linux-gnu
    Thread model: posix
    InstalledDir: /usr/bin
    
    $ make -C llvm_mode
    
    [*] Checking for working 'llvm-config'...
    [*] Checking for working 'clang'...
    [*] Checking for '../afl-showmap'...
    [+] All set and ready to build.
    clang -O3 -funroll-loops -Wall -D_FORTIFY_SOURCE=2 -g -Wno-pointer-sign -DAFL_PATH=\"/usr/local/lib/afl\" -DBIN_PATH=\"/usr/local/bin\" -DVERSION=\"2.54b\"  afl-clang-fast.c -o ../afl-clang-fast
    ln -sf afl-clang-fast ../afl-clang-fast++
    clang++ `llvm-config --cxxflags` -Wl,-znodelete -fno-rtti -fpic -O3 -funroll-loops -Wall -D_FORTIFY_SOURCE=2 -g -Wno-pointer-sign -DVERSION=\"2.54b\" -Wno-variadic-macros -shared afl-llvm-pass.so.cc -o ../afl-llvm-pass.so `llvm-config --ldflags`
    afl-llvm-pass.so.cc:134:31: warning: 'CreateLoad' is deprecated: Use the version that explicitly specifies the loaded type instead [-Wdeprecated-declarations]
          LoadInst *PrevLoc = IRB.CreateLoad(AFLPrevLoc);
                                  ^
    /usr/lib/llvm-13/include/llvm/IR/IRBuilder.h:1678:3: note: 'CreateLoad' has been explicitly marked deprecated here
      LLVM_ATTRIBUTE_DEPRECATED(LoadInst *CreateLoad(Value *Ptr,
      ^
    /usr/lib/llvm-13/include/llvm/Support/Compiler.h:320:52: note: expanded from macro 'LLVM_ATTRIBUTE_DEPRECATED'
    #define LLVM_ATTRIBUTE_DEPRECATED(decl, message) [[deprecated(message)]] decl
                                                       ^
    afl-llvm-pass.so.cc:140:30: warning: 'CreateLoad' is deprecated: Use the version that explicitly specifies the loaded type instead [-Wdeprecated-declarations]
          LoadInst *MapPtr = IRB.CreateLoad(AFLMapPtr);
                                 ^
    /usr/lib/llvm-13/include/llvm/IR/IRBuilder.h:1678:3: note: 'CreateLoad' has been explicitly marked deprecated here
      LLVM_ATTRIBUTE_DEPRECATED(LoadInst *CreateLoad(Value *Ptr,
      ^
    /usr/lib/llvm-13/include/llvm/Support/Compiler.h:320:52: note: expanded from macro 'LLVM_ATTRIBUTE_DEPRECATED'
    #define LLVM_ATTRIBUTE_DEPRECATED(decl, message) [[deprecated(message)]] decl
                                                       ^
    afl-llvm-pass.so.cc:143:15: warning: 'CreateGEP' is deprecated: Use the version with explicit element type instead [-Wdeprecated-declarations]
              IRB.CreateGEP(MapPtr, IRB.CreateXor(PrevLocCasted, CurLoc));
                  ^
    /usr/lib/llvm-13/include/llvm/IR/IRBuilder.h:1787:3: note: 'CreateGEP' has been explicitly marked deprecated here
      LLVM_ATTRIBUTE_DEPRECATED(
      ^
    /usr/lib/llvm-13/include/llvm/Support/Compiler.h:320:52: note: expanded from macro 'LLVM_ATTRIBUTE_DEPRECATED'
    #define LLVM_ATTRIBUTE_DEPRECATED(decl, message) [[deprecated(message)]] decl
                                                       ^
    afl-llvm-pass.so.cc:147:31: warning: 'CreateLoad' is deprecated: Use the version that explicitly specifies the loaded type instead [-Wdeprecated-declarations]
          LoadInst *Counter = IRB.CreateLoad(MapPtrIdx);
                                  ^
    /usr/lib/llvm-13/include/llvm/IR/IRBuilder.h:1678:3: note: 'CreateLoad' has been explicitly marked deprecated here
      LLVM_ATTRIBUTE_DEPRECATED(LoadInst *CreateLoad(Value *Ptr,
      ^
    /usr/lib/llvm-13/include/llvm/Support/Compiler.h:320:52: note: expanded from macro 'LLVM_ATTRIBUTE_DEPRECATED'
    #define LLVM_ATTRIBUTE_DEPRECATED(decl, message) [[deprecated(message)]] decl
                                                       ^
    4 warnings generated.
    clang -O3 -funroll-loops -Wall -D_FORTIFY_SOURCE=2 -g -Wno-pointer-sign -DAFL_PATH=\"/usr/local/lib/afl\" -DBIN_PATH=\"/usr/local/bin\" -DVERSION=\"2.54b\"  -fPIC -c afl-llvm-rt.o.c -o ../afl-llvm-rt.o
    [*] Building 32-bit variant of the runtime (-m32)... success!
    [*] Building 64-bit variant of the runtime (-m64)... success!
    [*] Testing the CC wrapper and instrumentation output...
    unset AFL_USE_ASAN AFL_USE_MSAN AFL_INST_RATIO; AFL_QUIET=1 AFL_PATH=. AFL_CC=clang ../afl-clang-fast -O3 -funroll-loops -Wall -D_FORTIFY_SOURCE=2 -g -Wno-pointer-sign -DAFL_PATH=\"/usr/local/lib/afl\" -DBIN_PATH=\"/usr/local/bin\" -DVERSION=\"2.54b\"  ../test-instr.c -o test-instr
    ../afl-showmap -m none -q -o .test-instr0 ./test-instr < /dev/null
    echo 1 | ../afl-showmap -m none -q -o .test-instr1 ./test-instr
    
    Oops, the instrumentation does not seem to be behaving correctly!
    
    Please ping <[email protected]> to troubleshoot the issue.
    
    make: *** [Makefile:103: test_build] Error 1
    
    opened by yonic2 1
  • Security Policy violation Binary Artifacts

    Security Policy violation Binary Artifacts

    This issue was automatically created by Allstar.

    Security Policy Violation Project is out of compliance with Binary Artifacts policy: binaries present in source code

    Rule Description Binary Artifacts are an increased security risk in your repository. Binary artifacts cannot be reviewed, allowing the introduction of possibly obsolete or maliciously subverted executables. For more information see the Security Scorecards Documentation for Binary Artifacts.

    Remediation Steps To remediate, remove the generated executable artifacts from the repository.

    Artifacts Found

    • docs/vuln_samples/file-fpu-exception.elf
    • docs/vuln_samples/strings-bfd-badptr.elf
    • docs/vuln_samples/strings-bfd-badptr2.elf
    • docs/vuln_samples/strings-unchecked-ctr.elf
    • testcases/others/elf/small_exec.elf

    Additional Information This policy is drawn from Security Scorecards, which is a tool that scores a project's adherence to security best practices. You may wish to run a Scorecards scan directly on this repository for more details.


    Allstar has been installed on all Google managed GitHub orgs. Policies are gradually being rolled out and enforced by the GOSST and OSPO teams. Learn more at http://go/allstar

    This issue will auto resolve when the policy is in compliance.

    Issue created by Allstar. See https://github.com/ossf/allstar/ for more information. For questions specific to the repository, please contact the owner or maintainer.

    allstar 
    opened by allstar-app[bot] 54
Releases(v2.57b)
  • v2.57b(Jul 4, 2020)

  • v2.56b(Sep 26, 2019)

  • v2.55b(Sep 19, 2019)

  • v2.53b(Jul 25, 2019)

    • No functional changes. Updated some comments and license headers to comply with the open sourcing guidelines and publish the source code on GitHub.

    Please download this release by checking out the release tag in a git checkout:

    git checkout tags/v2.53b
    
    Source code(tar.gz)
    Source code(zip)
Owner
Google
Google ❤️ Open Source
Google
BLEND: A Fast, Memory-Efficient, and Accurate Mechanism to Find Fuzzy Seed Matches

BLEND is a mechanism that can efficiently find fuzzy seed matches between sequences to significantly improve the performance and accuracy while reducing the memory space usage of two important applications: 1) finding overlapping reads and 2) read mapping.

SAFARI Research Group at ETH Zurich and Carnegie Mellon University 13 Sep 27, 2022
Special Apps Remover (U.S.A Android Phones) (ADB ONLY) Supports deleting the applications of some American companies

Special Apps Remover (U.S.A Android Phones) (ADB ONLY) Supports deleting the applications of some American companies

muhammad almuhmmah 3 Apr 28, 2022
Coverage-guided grammar aware fuzzer that uses grammar automatons

Gramatron Gramatron is a coverage-guided fuzzer that uses grammar automatons to perform grammar-aware fuzzing. Technical details about our framework a

HexHive 38 Aug 18, 2022
funky fun fuzzer

FunkyFunFuzzer / fffz FunkyFunFuzzer / fffz is an attempt at a file fuzzer prioritising usability while striving for real-world performance. It is a m

Rory M 11 Oct 8, 2021
Next-gen Rowhammer fuzzer that uses non-uniform, frequency-based patterns.

Blacksmith Rowhammer Fuzzer This repository provides the code accompanying the paper Blacksmith: Scalable Rowhammering in the Frequency Domain that is

Computer Security Group @ ETH Zurich 171 Sep 23, 2022
A fast driver IOCTL fuzzer that I wrote.

IOCTL Explosion A fast driver IOCTL fuzzer that I wrote. Disclaimer There is still a lot of work to be made for this fuzzer. Currently, multi-threadin

null 3 May 9, 2022
Loop is an object oriented programming language

Loop Loop is an object oriented programming language. How do I build and run loop? Make sure, you installed the requirements for clang and make: Debia

Loop 24 Aug 9, 2021
A hobby and performance-oriented Linux® distribution that provides aesthetics and practical functionality.

Heiwa/Linux A hobby and performance-oriented Linux® distribution that provides aesthetics and practical functionality.

Heiwa/Linux 26 Apr 29, 2022
Garry's Mod privacy-oriented anticheat module for Simple-Roleplay.

Simple-Anticheat Garry's Mod privacy-oriented anticheat module for Simple-Roleplay. About privacy We will never: Transmit the content of your files to

Simple Roleplay 2 Sep 19, 2021
Computer room reservation system(Object oriented programming)

Computer-room-reservation-system Computer room reservation system(Object oriented programming) 首先进入登录界面,可选登录身份有: 学生代表 老师 管理员 退出 每个身份都需要进行验证后,进入子菜单 学生需

life_geometry 2 Jan 1, 2022
Cross-platform GPU-oriented C++ application/game framework

Introduction neoGFX is a C++ app/game engine and development platform targeted at app and game developers that wish to leverage modern GPUs for perfor

i42 Software 466 Sep 15, 2022
ToPS is an objected-oriented framework implemented using C++ that facilitates the integration of probabilistic models for sequences over a user defined alphabet

ToPS is an objected-oriented framework implemented using C++ that facilitates the integration of probabilistic models for sequences over a user defined alphabet

Andre Yoshiaki Kashiwabara 34 Aug 2, 2022
Real-time oriented physics engine and library that's currently best suited for 2D games.

PlayRho A way to play with physical behaviors like the conservation of momentum. PlayRho is a real-time oriented physics engine and library that's cur

Louis Langholtz 90 Sep 22, 2022
Gunyah is a Type-1 hypervisor designed for strong security, performance and modularity.

Gunyah is a Type-1 hypervisor, meaning that it is independent of any high-level OS kernel, and runs in a higher CPU privilege level. It does not depend on any lower-privileged OS kernel/code for its core functionality. This increases its security and can support a much smaller trusted computing base than a Type-2 hypervisor.

Qualcomm Innovation Center 73 Oct 2, 2022
The purpose of these streams is to be educational and entertaining for viewers to learn about systems architecture, reverse engineering, software security, etc., and NOT to encourage nor endorse malicious game hacking.

Memestream This repository holds the code that I develop during my live game "modding" ?? sessions. When I stream, I like to speedrun making a success

Stephen Tong 28 Jul 6, 2022
Proof-of-concept implementation for the paper "Osiris: Automated Discovery of Microarchitectural Side Channels" (USENIX Security'21)

Osiris This repository contains the implementation of the Osiris framework discussed in the research paper "Osiris: Automated Discovery of Microarchit

CISPA 38 Aug 8, 2022
mimikatz is a tool I've made to learn C and make somes experiments with Windows security

mimikatz is a tool I've made to learn C and make somes experiments with Windows security

Benjamin DELPY 16k Sep 28, 2022
anthemtotheego 366 Sep 29, 2022
weggli is a fast and robust semantic search tool for C and C++ codebases. It is designed to help security researchers identify interesting functionality in large codebases.

weggli is a fast and robust semantic search tool for C and C++ codebases. It is designed to help security researchers identify interesting functionality in large codebases.

Google Project Zero 1.9k Sep 27, 2022