aflplusplus / aflplusplus

The fuzzer afl++ is afl with community patches, qemu 5.1 upgrade, collision-free coverage, enhanced laf-intel & redqueen, AFLfast++ power schedules, MOpt mutators, unicorn_mode, and a lot more!

American Fuzzy Lop plus plus (AFL++)

Release version: 4.21c

GitHub version: 4.22a

Repository: https://github.com/AFLplusplus/AFLplusplus

AFL++ is maintained by:

• Marc "van Hauser" Heuse [email protected]
• Dominik Maier [email protected]
• Andrea Fioraldi [email protected]
• Heiko "hexcoder-" Eissfeldt [email protected]
• frida_mode is maintained by @Worksbutnottested
• Documentation: Jana Aydinbas [email protected]

Originally developed by Michal "lcamtuf" Zalewski.

AFL++ is a superior fork to Google's AFL - more speed, more and better mutations, more and better instrumentation, custom module support, etc.

You are free to copy, modify, and distribute AFL++ with attribution under the terms of the Apache-2.0 License. See the LICENSE for details.

Getting started

Here is some information to get you started:

• For an overview of the AFL++ documentation and a very helpful graphical guide, please visit docs/README.md.
• To get you started with tutorials, go to docs/tutorials.md.
• For releases, see the Releases tab and branches. The best branches to use are, however, stable or dev - depending on your risk appetite. Also take a look at the list of important changes in AFL++ and the list of features.
• If you want to use AFL++ for your academic work, check the papers page on the website.
• To cite our work, look at the Cite section.
• For comparisons, use the fuzzbench aflplusplus setup, or use afl-clang-fast with AFL_LLVM_CMPLOG=1. You can find the aflplusplus default configuration on Google's fuzzbench.

Building and installing AFL++

To have AFL++ easily available with everything compiled, pull the image directly from the Docker Hub (available for both x86_64 and arm64):

docker pull aflplusplus/aflplusplus
docker run -ti -v /location/of/your/target:/src aflplusplus/aflplusplus

This image is automatically published when a push to the stable branch happens (see branches). If you use the command above, you will find your target source code in /src in the container.

Note: you can also pull aflplusplus/aflplusplus:dev which is the most current development state of AFL++.

To build AFL++ yourself - which we recommend - continue at docs/INSTALL.md.

Quick start: Fuzzing with AFL++

NOTE: Before you start, please read about the common sense risks of fuzzing.

This is a quick start for fuzzing targets with the source code available. To read about the process in detail, see docs/fuzzing_in_depth.md.

To learn about fuzzing other targets, see:

• Binary-only targets: docs/fuzzing_binary-only_targets.md
• Network services: docs/best_practices.md#fuzzing-a-network-service
• GUI programs: docs/best_practices.md#fuzzing-a-gui-program

Step-by-step quick start:

1. Compile the program or library to be fuzzed using afl-cc. A common way to do this would be:

   CC=/path/to/afl-cc CXX=/path/to/afl-c++ ./configure --disable-shared
   make clean all
   

2. Get a small but valid input file that makes sense to the program. When fuzzing verbose syntax (SQL, HTTP, etc.), create a dictionary as described in dictionaries/README.md, too.

3. If the program reads from stdin, run afl-fuzz like so:

   ./afl-fuzz -i seeds_dir -o output_dir -- \
   /path/to/tested/program [...program's cmdline...]
   

   To add a dictionary, add -x /path/to/dictionary.txt to afl-fuzz.

   If the program takes input from a file, you can put @@ in the program's command line; AFL++ will put an auto-generated file name in there for you.

4. Investigate anything shown in red in the fuzzer UI by promptly consulting docs/afl-fuzz_approach.md#understanding-the-status-screen.

5. You will find found crashes and hangs in the subdirectories crashes/ and hangs/ in the -o output_dir directory. You can replay the crashes by feeding them to the target, e.g. if your target is using stdin:

   cat output_dir/crashes/id:000000,* | /path/to/tested/program [...program's cmdline...]
   

   You can generate cores or use gdb directly to follow up the crashes.

6. We cannot stress this enough - if you want to fuzz effectively, read the docs/fuzzing_in_depth.md document!

Contact

Questions? Concerns? Bug reports?

• The contributors can be reached via (e.g., by creating an issue): https://github.com/AFLplusplus/AFLplusplus.
• Take a look at our FAQ. If you find an interesting or important question missing, submit it via https://github.com/AFLplusplus/AFLplusplus/discussions.
• Best: join the Awesome Fuzzing Discord server.
• There is a (not really used) mailing list for the AFL/AFL++ project (browse archive). To compare notes with other users or to get notified about major new features, send an email to [email protected], but note that this is not managed by us.

Branches

The following branches exist:

• release: the latest release
• stable/trunk: stable state of AFL++ - it is synced from dev from time to time when we are satisfied with its stability
• dev: development state of AFL++ - bleeding edge and you might catch a checkout which does not compile or has a bug. We only accept PRs (pull requests) for the 'dev' branch!
• (any other): experimental branches to work on specific features or testing new functionality or changes.

Help wanted

We have several ideas we would like to see in AFL++ to make it even better. However, we already work on so many things that we do not have the time for all the big ideas.

This can be your way to support and contribute to AFL++ - extend it to do something cool.

For everyone who wants to contribute (and send pull requests), please read our contributing guidelines before you submit.

Special thanks

Many of the improvements to the original AFL and AFL++ wouldn't be possible without feedback, bug reports, or patches from our contributors.

Thank you! (For people sending pull requests - please add yourself to this list :-)

List of contributors

  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 Neuschaefer                  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 Boehme
  Van-Thuan Pham                        Abhik Roychoudhury
  Joshua J. Drake                       Toby Hutton
  Rene Freingruber                      Sergey Davidoff
  Sami Liedes                           Craig Young
  Andrzej Jackowski                     Daniel Hodson
  Nathan Voss                           Dominik Maier
  Andrea Biondo                         Vincent Le Garrec
  Khaled Yakdan                         Kuang-che Wu
  Josephine Calliotte                   Konrad Welc
  Thomas Rooijakkers                    David Carlier
  Ruben ten Hove                        Joey Jiao
  fuzzah                                @intrigus-lgtm
  Yaakov Saxon                          Sergej Schumilo

Cite

If you use AFL++ in scientific work, consider citing our paper presented at WOOT'20:

Andrea Fioraldi, Dominik Maier, Heiko Eißfeldt, and Marc Heuse. “AFL++: Combining incremental steps of fuzzing research”. In 14th USENIX Workshop on Offensive Technologies (WOOT 20). USENIX Association, Aug. 2020.

BibTeX

@inproceedings {AFLplusplus-Woot20,
author = {Andrea Fioraldi and Dominik Maier and Heiko Ei{\ss}feldt and Marc Heuse},
title = {{AFL++}: Combining Incremental Steps of Fuzzing Research},
booktitle = {14th {USENIX} Workshop on Offensive Technologies ({WOOT} 20)},
year = {2020},
publisher = {{USENIX} Association},
month = aug,
}

aflplusplus's Issues

python mutator module issue

Hi,

I want to use python mutator module, I have installed python2.7-dev, and use make source-only to build afl. But when I invoke afl with AFL_PYTHON_MODULE="python_mutators.example" PYTHONPATH=. ./afl-fuzz ..., it reported that Your AFL binary was built without Python support. It seems the Makefile cannot detect python2.7.

Then I installed python3.7-dev, and build afl with make source-only. Then run the afl-fuzz with python module, But it reported that:

[!] WARNING: Could not check CPU scaling governor
[*] Setting up output directories...
[+] Output directory exists but deemed OK to reuse.
[*] Deleting old session data...
[+] Output dir cleanup successful.
AttributeError: module 'python_mutators.example' has no attribute 'trim'
Error in sys.excepthook:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/apport_python_hook.py", line 63, in apport_excepthook
    from apport.fileutils import likely_packaged, get_recent_crashes
  File "/usr/lib/python3/dist-packages/apport/__init__.py", line 5, in <module>
    from apport.report import Report
  File "/usr/lib/python3/dist-packages/apport/report.py", line 30, in <module>
    import apport.fileutils
  File "/usr/lib/python3/dist-packages/apport/fileutils.py", line 23, in <module>
    from apport.packaging_impl import impl as packaging
  File "/usr/lib/python3/dist-packages/apport/packaging_impl.py", line 24, in <module>
    import apt
  File "/usr/lib/python3/dist-packages/apt/__init__.py", line 23, in <module>
    import apt_pkg
ModuleNotFoundError: No module named 'apt_pkg'

Original exception was:
AttributeError: module 'python_mutators.example' has no attribute 'trim'
[!] WARNING: Python module does not implement trim API, standard trimming will be used.

python3.7 doesn't have apt_pkg module.

Any idea to use python mutator module in afl++?

QEMU build breaks on new glibc

When using ubuntu 19.10 and AFL++ commit c124576 everything worked perfectly fine before, but I think with the new glibc in ubuntu 19.10 it fails (see link below why I think that). I tried upgrading my Docker image to the new a67d86c commit (so I don't think it is the new AFL++ but a glibc/QEMU problem):

$ apt-get update && apt-get -y install build-essential clang git python2.7-dev python2.7 && git clone https://github.com/vanhauser-thc/AFLplusplus.git /afl && cd /afl/ && git reset --hard a67d86c6e2ca58db81f2ddf6d0a4c837be88271d && make
[...]
$ cd /afl/libdislocator/ && make
[...]
$ cd /afl/llvm_mode && ln -s /usr/bin/llvm-config-? /usr/bin/llvm-config && make
[...]
$ cd /afl/ && make install
$ unset AFL_CC AFL_CXX AFL_AS && apt-get update && apt-get -y install libtool-bin wget bison libglib2.0-dev libpixman-1-dev python && cd /afl/qemu_mode && ./build_qemu_support.sh && cd /afl/ && make install
[...]
  CC      x86_64-linux-user/accel/tcg/user-exec-stub.o
  CC      x86_64-linux-user/linux-user/main.o
  CC      x86_64-linux-user/linux-user/syscall.o
/afl/qemu_mode/qemu-3.1.0/linux-user/syscall.c:256:16: error: static declaration of 'gettid' follows non-static declaration
  256 | _syscall0(int, gettid)
      |                ^~~~~~
/afl/qemu_mode/qemu-3.1.0/linux-user/syscall.c:187:13: note: in definition of macro '_syscall0'
  187 | static type name (void)   \
      |             ^~~~
In file included from /usr/include/unistd.h:1170,
                 from /afl/qemu_mode/qemu-3.1.0/include/qemu/osdep.h:90,
                 from /afl/qemu_mode/qemu-3.1.0/linux-user/syscall.c:20:
/usr/include/x86_64-linux-gnu/bits/unistd_ext.h:34:16: note: previous declaration of 'gettid' was here
   34 | extern __pid_t gettid (void) __THROW;
      |                ^~~~~~
make[1]: *** [/afl/qemu_mode/qemu-3.1.0/rules.mak:69: linux-user/syscall.o] Error 1
make[1]: *** Waiting for unfinished jobs....
  LINK    ivshmem-server
  LINK    qemu-nbd
  LINK    qemu-img
make: *** [Makefile:483: subdir-x86_64-linux-user] Error 2

This seems to be this one:
https://lists.gnu.org/archive/html/qemu-devel/2019-04/msg01314.html

If I understand it correctly this is more of a QEMU problem than an AFL++ problem, however, AFL++ still uses QEMU 3.1.0 instead of 3.1.1. So squeezing the following in:

sed -i "s/3.1.0/3.1.1/g" build_qemu_support.sh && sed -i "s/0318f2b5a36eafbf17bca0f914567dfa5e8a3cd6ff83bb46fe49a0079cd71ddd3ec4267c6c62a03f9e26e05cc80e6d4b/28ff22ec4b8c957309460aa55d0b3188e971be1ea7dfebfb2ecc7903cd20cfebc2a7c97eedfcc7595f708357f1623f8b/g" build_qemu_support.sh

It didn't compile either :( So either QEMU support will be broken in newer glibc or we patch AFL++ or QEMU 4 support is ready soon. Unfortunately I can also not use an older version of 9.10, because in Docker images the version specification "9.10" is as granular as it gets.

Patching AFL++ shouldn't be too hard, as there is already a syscall.diff patch...

Off-topic: I'm currently writing a Docker image for AFL++. I think AFL++ would really profit from a stable build environment, where tests could be run as well to make sure AFL++ still works correctly. With Docker multi-stage images I was able to build different images, with various features and different compile times if the Docker image would need updating. It was also only one command (rebuild the docker) to find the above issue. Moreover, I think it would really benefit the community, as installing AFL++, libdislocator, llvm_mode, recidivm, QEMU mode, afl-dyninst is probably already a problem for beginners. Having the same build environment would be the first step to simplify performance comparisons (together with -E -V options). With the Docker image it would as well be very easy to do some sort of continuous integration and building the newest release overnight and run additional tests... I'll let you know some more about the Docker soon

Limiting command line options (-V -E) do not work properly

I was trying to fuzz a target only for a minute or until a certain amount of executions were done. However, afl-fuzz just went on fuzzing. For example:

afl-fuzz -Q -i afl_in -o afl_out -M main -s 1 -E 100000 -V 60 /examples/binutils-2.24/build-clang/binutils/readelf -a @@

Any idea why -E and -V are so unreliable?

Showmap fix may break cmin

@vanhauser-thc I've just seen your change to showmap and it is useful to see the raw
tuples but this IMO will break afl-cmin that uses showmap with manipulated tuples.
Your patch skips the count_class_binary filter used by cmin without -e.
I will add ASAP an option to showmap for not manipulated tuples and left the old behaviour by default to not break cmin and other tools built on top of showmap.

Delivery Method for patches

For the current iteration of unicornafl, I've patched quite a bit:

❯ git diff --shortstat master unicornafl
65 files changed, 1801 insertions(+), 70 deletions(-)

I wonder if creating .diff files is still the best way to go. Creating a proper fork for this/these projects might be easier to understand and maintain?
What's everybody's opinion? pro/contra?

Floating point laf-intel

Currently, the laf-intel LLVM pass seems to not support the split
of floating point comparisons (CmpInst::FCMP_*). RIght?

I will implement also a QEMU CompareCoverage extension for x86 floating point comparisons (https://docs.oracle.com/cd/E19120-01/open.solaris/817-5477/epmnp/index.html).

The command to get the clang version in the llvm_mode Makefile is not correct

#44

AFL for android hidl

Hi,
Android now uses hidl (client/server mode) stated here https://source.android.com/devices/architecture/hidl-cpp.

If I enable afl for client and server and when I run fuzz for client, it will only show paths of client. I know there is a called llvm persist mode, but I can hardly find anywhere in the hidl mode to put the persist code in hidl server.

Any idea or experience?

AFL server and client model

There is a AFL project for linux kernel named syzkaller (github.com/google/syzkaller) which uses client/server model, that is:

• A manager running on host machine to 1. init connection to target device; 2. receive coverage data from target device; 3. display status on web
• A fuzzer running on target device to 1. run exectutor; 2. to send coverage data back to manager

So I want to know if AFL can change to this kind of model

• AFL-manager (receive corpus and show status on web)
• Multiple AFL-fuzzer and executors ( do what afl-fuzz do but also send the coverage back to manager)

Why:
We are running afl-fuzz on target device which will easily crash, and then we have to restart the device and rerun the afl-fuzz from beginning. But syzkaller like model can bear the device crash and resume where it crashes or hangs.
And we don't know what paths are covered on target machine too.

Suspicious crash of QEMU with FFmpeg on old Debian

I'm trying to fuzz FFmpeg on a server with Linux 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64 GNU/Linux.

I have a suspicious segfault of QEMU in afl-fuzz, running the binary with afl-qemu-trace works fine.
Output with debug child out:

ffmpeg version N-95006-g76f861bbb7 Copyright (c) 2000-2019 the FFmpeg developers
  built with gcc 6.3.0 (Debian 6.3.0-18+deb9u1) 20170516
  configuration: 
  libavutil      56. 35.100 / 56. 35.100
  libavcodec     58. 58.101 / 58. 58.101
  libavformat    58. 33.100 / 58. 33.100
  libavdevice    58.  9.100 / 58.  9.100
  libavfilter     7. 58.102 /  7. 58.102
  libswscale      5.  6.100 /  5.  6.100
  libswresample   3.  6.100 /  3.  6.100
Trailing options were found on the commandline.
[avi @ 0x40049f6380] Could not find codec parameters for stream 0 (Video: mpeg4 (FMP4 / 0x34504D46), none, 1x1): unspecified pixel format
Consider increasing the value for the 'analyzeduration' and 'probesize' options
qemu: uncaught target signal 11 (Segmentation fault) - core dumped

On my Ubuntu 18 laptop it works fine without crashes, can you reproduce the issue?
attachments.tar.gz

llvm_mode make "Prerequisites are not met" with llvm10

I'm using llvm10 from Ubuntu Bionic PPA: http://apt.llvm.org/bionic/

I used to change the llvm_mode Makefile to use c++14 when using llvm10, but recently a patch came out to support llvm10. \o/

The patch seems to have some problem, or there is some incompatibility I'm not aware of.

`
:/AFLplusplus/llvm_mode$ make
Makefile:51: llvm_mode only supports llvm versions 3.8.0 up to 10
llvm_mode detected llvm 10+, enabling neverZero implementation and c++14
Prerequisites are not met, skipping build

:/AFLplusplus/llvm_mode$ llvm-config --version
10.0.0

:/AFLplusplus/llvm_mode$ clang --version
clang version 10.0.0-[phone]+f99297176cd-1exp120191211082036.1372
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
`

From the make output it looks like Makefile detected that I have llvm10, set configuration for it and then exited as unsupported.

If I set the LLVM_UNSUPPORTED test from Makefile:39 to always pass, the build seems to work without any problems.

Is the Makefile check incorrect, or is there some issues with llvm10, even though the build passes?

Move to Python3 (mostly)?

Currently build_unicorn_support.sh installs in python2 by default on linux.
I don't know what the python mutators expect or need.
However, as py2 is no longer supported starting in 40 days or so, I suggest dropping py2 support completely.

llvm_mode and OpenBSD

When trying to build llvm_mode in OpenBSD, it does not work right out of the box.

clang-local does not search for llvm libs in their installed directories by default (for security purposes).

So when trying to build some test program with afl-clang-fast it fails:

[*] 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.52b" ../test-instr.c -o test-instr
clang:../afl-llvm-pass.so: undefined symbol '_ZN4llvm10ModulePass17assignPassManagerERNS_7PMStackENS_15PassManagerTypeE'
clang:../afl-llvm-pass.so: undefined symbol '_ZN4llvm10ModulePassD2Ev'
clang:../afl-llvm-pass.so: undefined symbol '_ZN4llvm24DisableABIBreakingChecksE'
clang:../afl-llvm-pass.so: undefined symbol '_ZN4llvm4Pass13releaseMemoryEv'
clang:../afl-llvm-pass.so: undefined symbol '_ZN4llvm4Pass17dumpPassStructureEj'
clang:../afl-llvm-pass.so: undefined symbol '_ZN4llvm4Pass18getAsImmutablePassEv'
clang:../afl-llvm-pass.so: undefined symbol '_ZN4llvm4Pass18getAsPMDataManagerEv'
clang:../afl-llvm-pass.so: undefined symbol '_ZN4llvm4Pass18preparePassManagerERNS_7PMStackE'
clang:../afl-llvm-pass.so: undefined symbol '_ZN4llvm4Pass26getAdjustedAnalysisPointerEPKv'
clang:../afl-llvm-pass.so: undefined symbol '_ZNK4llvm10ModulePass17createPrinterPassERNS_11raw_ostreamERKNSt3__112basic_stringIcNS3_11char_traitsIcEENS3_9allocatorIcEEEE'
clang:../afl-llvm-pass.so: undefined symbol '_ZNK4llvm10ModulePass27getPotentialPassManagerTypeEv'
clang:../afl-llvm-pass.so: undefined symbol '_ZNK4llvm4Pass11getPassNameEv'
clang:../afl-llvm-pass.so: undefined symbol '_ZNK4llvm4Pass14verifyAnalysisEv'
clang:../afl-llvm-pass.so: undefined symbol '_ZNK4llvm4Pass16getAnalysisUsageERNS_13AnalysisUsageE'
clang:../afl-llvm-pass.so: undefined symbol '_ZNK4llvm4Pass5printERNS_11raw_ostreamEPKNS_6ModuleE'
error: unable to load plugin '../afl-llvm-pass.so': 'Cannot load specified object'
gmake: *** [Makefile:98: test_build] Error 1

This is from the old afl-2.52b package, but applies to our version as well.
So, for OpenBSD we have to set the llvm lib path explicitly.

I will investigate later and report back.

gcc_plugin crash

this happens in a lot of larger projects when compiling with the gcc_plugin - afl-gcc-fast/afl-g++-fast :

[+] Instrumented 11 locations in TIFFInitJPEG
during GIMPLE pass: evrp
tif_jpeg.c: In function ‘JPEGFixupTagsSubsamplingSec’:
tif_jpeg.c:2388:1: internal compiler error: Segmentation fault
 }
 ^
0x7ffff758e83f ???
	/build/glibc-vjB4T1/glibc-2.28/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x7ffff757b09a __libc_start_main
	../csu/libc-start.c:308
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <file:///usr/share/doc/gcc-8/README.Bugs> for instructions.
make[2]: *** [Makefile:696: tif_jpeg.lo] Error 1

to reproduce:

wget http://download.osgeo.org/libtiff/tiff-4.0.4.tar.gz
tar xzf tiff-4.0.4.tar.gz
cd tiff-4.0.4
CC=afl-gcc-fast CXX=afl-g++-fast ./configure --disable-shared
make

llvm_mode/README.instrim missing

The file llvm_mode/README.instrim is mentioned here but it appears it's not committed.

libdislocator breaking change: getrandom not available on older Linux kernels

I have commented on the commit, but the latest update to libdislocator creates a dependency on the getrandom system call which does not exist in older kernels, such as 3.16 which ships with Debian 9 (which is EOL next June).

93a9e2d#r36207264

LLVM compile errors

Currently only llvm 3.9, 4.0 and 8 compile successfully, 5.0 and 6.0 with a workaround.

Versions 3.7 and 7 fail, workaround is being investigates
And for 5.0 and 6.0 it is to be seen if the g++ workaround can be getting rid of.

To clarify: this is also in the original afl 2.52b. This is not because of any code additions.

QEMU 5

I had some trouble porting to QEMU 4. It works but the exec/sec decrease drammatically.
For example, on tcpdump exec/sec are dropped from ~1650 to ~60.
I can't figure out why this happens and if someone will find why please tag me.

As a note for the future, I didn' use the QEMU helpers cause a patched version of tcg_gen_callN (tcg_gen_afl_maybe_log_call) that only generates calls to afl_maybe_log is faster. It avoids an hashtable lookup for flags and sizemask (I hardcoded them) and many operations related to arguments preparation will be simplified by the compiler.

MOpt havoc doesn't appears in UI

I'm trying QEMU CompCov in combination with MOpt and I notoced that the results of MOpt havoc are not shown in the UI

As you can see only the information about trim are present.

Linker issue: local symbol __afl_area_ptr in afl-llvm-rt.o is referenced by DSO

Hi guys,

I'm trying to compile OpenJDK with AFL++. In essence I'm compiling like this with jdk10: https://hg.openjdk.java.net/jdk-updates/jdk9u/raw-file/tip/common/doc/building.html#tldr-instructions-for-the-impatient . Yes I know that's probably not the easiest task, until I got this far I had to include several bug fixes for the code already. E.g. it doesn't accept CFLAGS, not even via the configure argument --with-extra-cflags and --with-extra-cxxflags that was made for it: https://bugs.openjdk.java.net/browse/JDK-8156967 . I "fixed" it by search/replacing CFLAGS/CXXFLAGS in the make scripts after the configure instruction. It feels like I'm the only person on the planet compiling

I've got through the compiling stage but I'm not getting linker error. I guess I need to fix LDFLAGS as well. Any ideas how I could resolve the following error? I guess I need to

ERROR: Build failed for target 'images' in configuration 'linux-x86_64-normal-server-release' (exit code 2) 

=== Output from failing command(s) repeated here ===
* For target support_native_java.corba_idlj_objs_BUILD_LAUNCHER_idlj_link:
/usr/bin/ld: /jdk10/build/linux-x86_64-normal-server-release/support/modules_cmds/java.corba/idlj: local symbol `__afl_area_ptr' in /afl//afl-llvm-rt.o is referenced by DSO
/usr/bin/ld: final link failed: bad value
clang: error: linker command failed with exit code 1 (use -v to see invocation)
* For target support_native_java.desktop_appletviewer_objs_BUILD_LAUNCHER_appletviewer_link:
/usr/bin/ld: /jdk10/build/linux-x86_64-normal-server-release/support/modules_cmds/java.desktop/appletviewer: local symbol `__afl_area_ptr' in /afl//afl-llvm-rt.o is referenced by DSO
/usr/bin/ld: final link failed: bad value
clang: error: linker command failed with exit code 1 (use -v to see invocation)

* All command lines available in /jdk10/build/linux-x86_64-normal-server-release/make-support/failure-logs.
=== End of repeated output ===

Here's the exact command that fails:

# /usr/local/bin/afl-clang -Wl,--allow-shlib-undefined -Wl,-rpath,\$ORIGIN/../lib/jli -Wl,-rpath,\$ORIGIN/../lib -L/jdk10/build/linux-x86_64-normal-server-release/support/modules_libs/java.base/jli -Wl,-version-script=/jdk10/jdk/make/mapfiles/launchers/mapfile-x86_64 -o /jdk10/build/linux-x86_64-normal-server-release/support/modules_cmds/java.corba/idlj /jdk10/build/linux-x86_64-normal-server-release/support/native/java.corba/idlj_objs/main.o -lz -lpthread -ljli -ldl -lc -v
afl-clang-fast++2.54d by <[email protected]>
clang version 9.0.0-2 (tags/RELEASE_900/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/8
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/9
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/9
Candidate multilib: .;@m64
Selected multilib: .;@m64
 "/usr/bin/ld" -z relro --hash-style=gnu --build-id --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o /jdk10/build/linux-x86_64-normal-server-release/support/modules_cmds/java.corba/idlj /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/crt1.o /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/crti.o /usr/bin/../lib/gcc/x86_64-linux-gnu/9/crtbegin.o -L/jdk10/build/linux-x86_64-normal-server-release/support/modules_libs/java.base/jli -L/usr/bin/../lib/gcc/x86_64-linux-gnu/9 -L/usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu -L/usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../lib64 -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib64 -L/usr/lib/x86_64-linux-gnu/../../lib64 -L/usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../.. -L/usr/lib/llvm-9/bin/../lib -L/lib -L/usr/lib --allow-shlib-undefined -rpath "\$ORIGIN/../lib/jli" -rpath "\$ORIGIN/../lib" -version-script=/jdk10/jdk/make/mapfiles/launchers/mapfile-x86_64 /jdk10/build/linux-x86_64-normal-server-release/support/native/java.corba/idlj_objs/main.o -lz -lpthread -ljli -ldl -lc /afl//afl-llvm-rt.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/bin/../lib/gcc/x86_64-linux-gnu/9/crtend.o /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/crtn.o
/usr/bin/ld: /jdk10/build/linux-x86_64-normal-server-release/support/modules_cmds/java.corba/idlj: local symbol `__afl_area_ptr' in /afl//afl-llvm-rt.o is referenced by DSO
/usr/bin/ld: final link failed: bad value
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Time-to-generate of fuzzed inputs

Hi,

Do you think we should add the time-to-generate of fuzzed inputs to their names? It is quite useful when we need to compute the Time-to-Exposure (the length of the fuzzing
campaign until the first crashing input is generated) values to compare with other fuzzers. So the patch is very simple like this one: strongcourage/aflgo@d73133e

Thanks,
Manh Dung

CPU scaling check/set

This seems to be changing on new kernels, we need to update afl-fuzz and afl-system-config once I have confirmed data

AFL_PRELOAD in qemu_mode

Issue to track the fact that AFL_PRELOAD is mapped to LD_PRELOAD and the specified library is preloaded in both afl-qemu-trace and the target program.
With QEMU_SET_ENV we can avoid this and preload the lib only into the target but we cannot let the user to specify a value of AFL_PRELOAD with a comma inside (or otherwise QEMU_SET_ENV will be broken).

My proposal is to:

• get the value of AFL_PRELOAD, check if there is a comma. If yes, report error to the user.
• if QEMU_SET_ENV is not defined, set it as QEMU_SET_ENV=LD_PRELOAD=$AFL_PRELOAD
• check if LD_PRELOAD is already specified in QEMU_SET_ENV, if yes report the error saying that the user have to use only one of the methods.
• otherwise, append LD_PRELOAD=$AFL_PRELOAD to QEMU_SET_ENV adding a comma-separated field (QEMU_SET_ENV=LD_PRELOAD=$AFL_PRELOAD,$QEMU_SET_ENV)

iOS support and mmap

I found the work of Proteas for ios support and expanded a bit on it in this branch.

iOS needs a different API for using shared memory (mmap-based).
I adapted it, refactored some common shared memory handling code into one place, made it the default and tested it for Linux (which has mmap and shmat).

I also extended afl-as.h to support non-llvm-mode (but I am not an assembly programmer).

It would be nice if the adapted programs (afl-as, afl-fuzz, afl-analyze, afl-showmap, afl-tmin, afl-gcc, afl-g++, afl-clang, afl-clang++) could be tested for other platforms (maybe even for iOS).

My hope is that the mmap API is generally more available thus making afl more portable.

TODO: we need to auto detect whether the mmap API is available else fallback to shmat().

Unsigaction does not compile with -m32

hi there,

I'm trying to build qemu-mode and the unsigaction in it (actually just running make binary-only). However, I get:

[+] Building unsigaction ...
make[1]: Entering directory '/afl/qemu_mode/unsigaction'
cc -m32 -fPIC -shared unsigaction.c -o unsigaction32.so || echo "Cannot build unsigation32"
/usr/bin/ld: cannot find crti.o: No such file or directory
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/9/libgcc.a when searching for -lgcc
/usr/bin/ld: cannot find -lgcc
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/9/libgcc.a when searching for -lgcc
/usr/bin/ld: cannot find -lgcc
collect2: error: ld returned 1 exit status

in Ubuntu 19.10. This seems to assume that -m32 just works. Is this working as intended? At other places AFL++ checks if -m32 works and if not just goes with -m64... https://github.com/vanhauser-thc/AFLplusplus/blob/624f0da6c0f7034cc56784d4b971b2c12ad5aa98/llvm_mode/Makefile#L222

Feature request: expose CompCov API in unicornafl

For the next release (the one after the today release) I'd like to have some thing like afl_compcov(bytes_a, bytes_b, size) in unicornafl. In QEMU an user can preload libcompcov to track the progress into *cmp functions but in unicorn ATM we can track the progress only of cmp and sub instructions in TCG.
Exposing such API let the user to hook comparison routines and add them to compcov by hand (we should also provide example scripts).
cc @domenukk

@vanhauser-thc in the unicorn fork there isn't the issue section, can you create it?

llvm_mode floating point split failure

It's better to open an issue from the float related bug that I found while trying to compile ffmpeg for the issue #85 .

I attach the command line, the preprocessed C file and the generated bitcode.
Note that if I use this command line to generate the bitcode is fine (change -emit-obj to -S -emit-llvm).
tmp.tar.gz

LLVM version 7.0.0, Ubuntu 18.04.3.

Fails to build with LLVM 9.0.0rc1

LLVM 9.0.0 is scheduled to be released on 2019-08-28. afl++ currently fails to build against it:

clang++90 `llvm-config90 --cxxflags` -Wl,-znodelete -fno-rtti -fpic -O2 -pipe -fstack-protector-strong -fno-strict-aliasing   -Wall -D_FORTIFY_SOURCE=2 -g -Wno-pointer-sign -DVERSION=\"++2.53c\" -Wno-variadic-macros -shared compare-transform-pass.so.cc -o ../compare-transform-pass.so `llvm-config90 --ldflags`  -fstack-protector-strong
--
compare-transform-pass.so.cc:85:13: error: no viable conversion from 'llvm::Function' to 'llvm::Function *'
Function* tolowerFn = cast<Function>(c);
^           ~~~~~~~~~~~~~~~~~
In file included from compare-transform-pass.so.cc:22:
In file included from /usr/local/llvm90/include/llvm/IR/IRBuilder.h:22:
In file included from /usr/local/llvm90/include/llvm/IR/BasicBlock.h:22:
In file included from /usr/local/llvm90/include/llvm/IR/Instruction.h:21:
In file included from /usr/local/llvm90/include/llvm/IR/DebugLoc.h:17:
In file included from /usr/local/llvm90/include/llvm/IR/TrackingMDRef.h:16:
In file included from /usr/local/llvm90/include/llvm/IR/Metadata.h:28:
In file included from /usr/local/llvm90/include/llvm/IR/Constant.h:16:
In file included from /usr/local/llvm90/include/llvm/IR/User.h:23:
In file included from /usr/local/llvm90/include/llvm/IR/Use.h:29:
In file included from /usr/local/llvm90/include/llvm/Support/CBindingWrapping.h:17:
/usr/local/llvm90/include/llvm/Support/Casting.h:58:24: error: cannot initialize a parameter of type 'const llvm::Value *' with an rvalue of type 'const llvm::FunctionCallee *'
return To::classof(&Val);
^~~~
/usr/local/llvm90/include/llvm/Support/Casting.h:77:32: note: in instantiation of member function 'llvm::isa_impl<llvm::Function, llvm::FunctionCallee, void>::doit' requested here
return isa_impl<To, From>::doit(Val);
^
/usr/local/llvm90/include/llvm/Support/Casting.h:132:36: note: in instantiation of member function 'llvm::isa_impl_cl<llvm::Function, const llvm::FunctionCallee>::doit' requested here
return isa_impl_cl<To,FromTy>::doit(Val);
^
/usr/local/llvm90/include/llvm/Support/Casting.h:143:70: note: in instantiation of member function 'llvm::isa_impl_wrap<llvm::Function, const llvm::FunctionCallee, const llvm::FunctionCallee>::doit' requested here
typename simplify_type<const Y>::SimpleType>::doit(Val);
^
/usr/local/llvm90/include/llvm/Support/Casting.h:257:10: note: in instantiation of function template specialization 'llvm::isa<llvm::Function, llvm::FunctionCallee>' requested here
assert(isa<X>(Val) && "cast<Ty>() argument of incompatible type!");
^
compare-transform-pass.so.cc:85:25: note: in instantiation of function template specialization 'llvm::cast<llvm::Function, llvm::FunctionCallee>' requested here
Function* tolowerFn = cast<Function>(c);
^
/usr/local/llvm90/include/llvm/IR/Function.h:774:36: note: passing argument to parameter 'V' here
static bool classof(const Value *V) {
^
2 errors generated.

See https://reviews.freebsd.org/P287 for the full log.

havoc/custom is not a good choice to have in the same line in stats

This is what I was saying sometine ago when it was instroduced. We should find a solution cause is very ugly.

MOpt-AFL mutations selection optimization

MOpt-AFL is a AFL-based fuzzer that utilizes a customized Particle Swarm Optimization (PSO) algorithm to find the optimal selection probability distribution of operators with respect to fuzzing effectiveness.

https://github.com/puppet-meteor/MOpt-AFL

This seems very interesting and the results showed in the paper confirm the validity of this technique. It does not change the way about how AFL works and maybe can be integrated here with a bit of source code refactoring.

NtH: Update docs to Markdown

Currently the documentation of AFLplusplus is writing in plain text.

I suggest to reformat the docs/*.txt files to markdown.

What are your thoughts?

CompareCoverage in QEMU mode?

We support laf-intel in LLVM mode, why not support an equivalent instrumentation in QEMU mode?
I'm experimenting a bit with the x86 target and I will create a branch for this.
The idea is to not touch the fuzzer but work only in QEMU.
The implementation will be different from honggfuzz that uses a different map for CompareCoverage, my idea is to put all in the AFL map.
This can create problems with large targets and the user may need to enlarge MAP_SIZE but this is also true for laf-intel.
Obviously this mode is off by default and can be enabled setting an env variable (I called it AFL_QEMU_COMPCOV in my experiment of this evening).
Let me know your opinion.

Python mode mutators

Implement this:
https://github.com/choller/afl/blob/master/docs/mozilla/python_modules.txt

Pull "changes" from upstream afl (?)

Google just released AFL on github officially, apparently.
The code lives here:
https://github.com/google/AFL
The version has been bumped to 2.53b.
Should afl++ merge the one line of readme changes and adapt to the upstream versioning?

how to calculate total paths

hello,I use the afl-fuzz to fuzz my code.I find something about the total paths.
My code:
int main(int argc, char *argv[])
{
int a = 0;
int b = 0;
int c = 0;
std::ifstream fin;
std::string file_name(argv[1]);
fin.open(file_name);
std::string str;
getline(fin, str, ' ');
a = stoi(str);
getline(fin, str, ' ');
b = stoi(str);
getline(fin, str, ' ');
c = stoi(str);

std::cout<<a << b << c<<std::endl;

 if(a>b)
{
    printf("a>b::a%d\n", a);
}
else 
{
    printf("a>b::b%d\n", b);
}

if(a>c)
{
    printf("a>c::a%d\n", a);
}
else 
{
    printf("a>c::c%d\n", c);
}

return 0;

}

Then, I get the total paths is 5,but I think the total paths is 4.Can you have some suggestion to me? Thanks.

Proposition: add radamsa to list of mutators

Since radamsa now exists as a (shared library), we might want to add it.

It could be called like this:
n = radamsa((uint8_t *) input, len, (uint8_t *) output, BUFSIZE, seed);

libdislocator stalls in OpenBSD

While porting our new test script test/test.sh to OpenBSD, I saw that the test for libdislocator (detecting a memory corruption) simply stalls and needs to be Ctrl-C'ed.
The lib is used with LD_PRELOAD=...

The reason is unknown yet.

AFL_BENCH_JUST_ONE=1 has no effect

If I understand correctly (and skimming through the code), this:

❯ AFL_BENCH_JUST_ONE=1 ../afl-fuzz -U -i in -o out -d -- python ../unicorn_mode/samples/simple/simple_test_harness.py @@

Should run only one testcase, however it just spawns AFL++ normally
Or am I holding it wrong?

Test Cases

Hi,

How do you know which test case is favored?
How can you create a favored test case?

Thanks

FairFuzz (afl-rb) integration

Has there been any discussion on incorporation of the FairFuzz project by Caroline Lemieux into afl++? In my tests, its approach was very effective, certainly comparable in value to the aflfast schedules.

That said, the code was slightly messy in a few places the last time I looked so perhaps it wouldn't be trivially mergeable and would require some manual porting.

What do you think?

ffmpeg not compiling with llvm_mode (v. 9.0.0)

when i instruments ffmpeg, it occured som error like:

./libavutil/libm.h:54:32: error: static declaration of ‘cbrt’ follows non-static declaration
   54 | static av_always_inline double cbrt(double x)
      |                                ^~~~
In file included from /usr/include/features.h:424,
                 from /usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33,
                 from /usr/include/stdint.h:26,
                 from /usr/lib/gcc/x86_64-linux-gnu/9/include/stdint.h:9,
                 from /home/fuzz/temp/include/types.h:20,
                 from /home/fuzz/temp/include/config.h:20,
                 from libavdevice/alldevices.c:21:
/usr/include/x86_64-linux-gnu/bits/mathcalls.h:152:1: note: previous declaration of ‘cbrt’ was here
  152 | __MATHCALL (cbrt,, (_Mdouble_ __x));
      | ^~~~~~~~~~
In file included from ./libavutil/internal.h:176,
                 from ./libavutil/common.h:491,
                 from ./libavutil/avutil.h:296,
                 from ./libavutil/samplefmt.h:24,
                 from ./libavcodec/avcodec.h:31,
                 from ./libavformat/avformat.h:317,
                 from ./libavformat/internal.h:27,
                 from libavdevice/alldevices.c:23:
./libavutil/libm.h:61:31: error: static declaration of ‘cbrtf’ follows non-static declaration
   61 | static av_always_inline float cbrtf(float x)
      |                               ^~~~~
In file included from ./libavutil/common.h:36,
                 from ./libavutil/avutil.h:296,
                 from ./libavutil/samplefmt.h:24,
                 from ./libavcodec/avcodec.h:31,
                 from ./libavformat/avformat.h:317,
                 from ./libavformat/internal.h:27,
                 from libavdevice/alldevices.c:23:
/usr/include/x86_64-linux-gnu/bits/mathcalls.h:152:1: note: previous declaration of ‘cbrtf’ was here
  152 | __MATHCALL (cbrt,, (_Mdouble_ __x));
      | ^~~~~~~~~~
In file included from ./libavutil/internal.h:176,
                 from ./libavutil/common.h:491,
                 from ./libavutil/avutil.h:296,
                 from ./libavutil/samplefmt.h:24,
                 from ./libavcodec/avcodec.h:31,
                 from ./libavformat/avformat.h:317,
                 from ./libavformat/internal.h:27,
                 from libavdevice/alldevices.c:23:
./libavutil/libm.h:68:32: error: static declaration of ‘copysign’ follows non-static declaration
   68 | static av_always_inline double copysign(double x, double y)
...

so i revert some git commit, and found the trouble cause by commit id: 4adca18, because 0e59a59 is fine.

what's it problem, and how to fix it?

by the way, it not always make failed, if you instruments a simple program, it should be ok.

Inefficient llvm_mode generated code for neverZero_counters branch

the shared memory map between afl-fuzz and the target contains 65536 one-byte buckets.

In the current afl implementation these can wrap and in rare occasions result in a 0 byte value which afl-fuzz ignores.

in tests an implementation that saturates (leaves at max 255 value) is bad for performance and bad for path discovery.

An implementation that skips the 0 when wrapping (and goes directly to 1) improves path discovery instead, so this is the road to go.

Problem: the code in llvm_mode for this is inefficient.

This is what is generated :

mov     al, [r8+r11]
mov     ebx, eax
add     bl, 1
adc     al, 1
mov     [r8+r11], al

instead of what would be efficient:

mov     al, [r8+r11]
add     al, 1
adc     al, 0
mov     [r8+r11], al

Code can be found in https://github.com/vanhauser-thc/AFLplusplus/tree/neverZero_counters (and then in llvm_mode/afl-llvm-pass.so.cc

qemu_mode broken with new libdislocator

QEMU fails to start when libdislocator is preloaded via AFL_PRELOAD.
GLib complains about alignment (we added posix_memalign recently).
The workaround (and perharbs the correct way to preload libraries in the QEMU guest without affecting QEMU itself) is using QEMU_SET_ENV.

So QEMU_SET_ENV=LD_PRELOAD=./libdislocator.so ./afl-fuzz -Q ... is the right way to have QEMU works with the last libdislocator changes.

What should we do? Pivot AFL_PRELOAD to QEMU_SET_ENV? Define AFL_QEMU_PRELOAD? Simply write in the readme to use QEMU_SET_ENV?
IMO the last is better so that the user can also set other env vars for the guest only.

integrate aflgo?

@strongcourage had the idea of integrating https://github.com/aflgo/aflgo into afl++

My opinion - just putting down my thoughts:

its an interesting feature for sure.

we partially can achieve something like that with the whitelist feature in llvm_mode, and @hexcoder- has thought about rewriting the whitelist feature code to allow to match on function names.
But it does not reach the fine-grained targeting that aflgo has.

usually if you fix something you have a crashing test case, only if you dont have one, you would need aflgo.

the overall steps to finally run aflgo are quite some and its complicated to get there (compared to normal llvm_mode compiling)

looking at the specific changes: mirrorer/afl@master...aflgo:master
I can see that the shm mapsize is different to normal, and the llvm_mode has been rewritten a lot.
So: I don't think the two projects are actually compatible to have in one tool - or only with complex code changes

TLDR: interesting feature, however very special case, and I doubt it can be easily integrated. However I only had a quick look

libdislocator does not trigger a segfault on Darwin/MacOSX

First issue was using the environment variable DYLD_INSERT_LIBRARIES instead of LD_PRELOAD.

To be sure the lib was really loaded, I temporarily added a puts("init\n") in the init function. That worked. I got my expected output.

But none the less the test did not trigger the segfault. It should do so because the page following the allocation is protected.

$ DYLD_INSERT_LIBRARIES=../libdislocator.so ./test-compcov BUFFEROVERFLOW
This will only crash with libdislocator: TESTBUFFEROVERFLOW

qemu_mode crash

this crash in qemu only seem to happen with specific input files. weird.

afl-fuzz -Q -i in -o out -- ./xmllint @@

always after exactly 5 seconds of running:

[-] PROGRAM ABORT : Unable to communicate with fork server (OOM?)
         Location : run_target(), afl-fuzz.c:2718

to reproduce:

wget ftp://xmlsoft.org/libxml2/libxml2-2.9.2.tar.gz
tar xzf ibxml2-2.9.2.tar.gz
cd ibxml2-2.9.2
./configure --disable-shared
make
mkdir in
cp ./test/schemas/complex-type-extension_0.xml in/

I tried a few other test xml files but they did not produce a crash

@andreafioraldi - thats more your competence, can you have a look?

Performance problem, caused by commit id: df379dfcf4694

i found after update to df379df, parallel mode had a performance trouble, it was slower than single fuzzer and each cpu alse can't reach 100%(only about 50%). also, if more fuzzers, the slower each speed.

that is output of 4721617(commit id):

and df379df output:

in single fuzzer, the speed is about 3600/sec.

llvm_mode does not compile on Ubuntu 18.04 with LLVM 6.0

During compilation of llvm_mode the testbuild target fails when the compiler pass is loaded and used:

...
[*] Testing the CC wrapper and instrumentation output...
unset AFL_USE_ASAN AFL_USE_MSAN AFL_INST_RATIO; AFL_QUIET=1 AFL_PATH=. AFL_CC=/usr/lib/llvm-6.0/bin/clang AFL_LLVM_LAF_SPLIT_SWITCHES=1 AFL_LLVM_LAF_TRANSFORM_COMPARES=1 AFL_LLVM_LAF_SPLIT_COMPARES=1 ../afl-clang-fast -O3 -funroll-loops -Wall -D_FORTIFY_SOURCE=2 -g -Wno-pointer-sign -I ../include/ -DAFL_PATH=\"/usr/local/lib/afl\" -DBIN_PATH=\"/usr/local/bin\" -DVERSION=\"++2.54d\" ../test-instr.c -o test-instr 
Rewriting 1 switch statements 
switch: 2 cases 8 bit
Split-floatingpoint-compare-pass: 0 FP comparisons splitted
Split-integer-compare-pass 64bit: 0 splitted
Split-integer-compare-pass 32bit: 0 splitted
Split-integer-compare-pass 16bit: 0 splitted
/usr/lib/llvm-6.0/bin/clang: symbol lookup error: ../afl-llvm-pass.so: undefined symbol: _ZNK4llvm11Instruction16getNumSuccessorsEv
clang: error: unable to execute command: No such file or directory
clang: error: clang frontend command failed due to signal (use -v to see invocation)
clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/lib/llvm-6.0/bin
clang: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script.
clang: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/test-instr-a66778.c
clang: note: diagnostic msg: /tmp/test-instr-a66778.sh
clang: note: diagnostic msg: 

********************
Makefile:196: recipe for target 'test_build' failed

check_binary error for Mach-O universal binary with 2 architectures

$ file /usr/local/bin/python3 /usr/local/bin/python3: Mach-O universal binary with 2 architectures: [i386:Mach-O executable i386] [x86_64:Mach-O 64-bit executable x86_64] /usr/local/bin/python3 (for architecture i386): Mach-O executable i386 /usr/local/bin/python3 (for architecture x86_64): Mach-O 64-bit executable x86_64

$ afl-fuzz -U -i in -o out -m none -- python3 frida_driver.py
afl-fuzz++2.58d based on afl by Michal Zalewski and a big online community
[+] afl++ is maintained by Marc "van Hauser" Heuse, Heiko "hexcoder" Eissfeldt and Andrea Fioraldi
[+] afl++ is open source, get it at https://github.com/vanhauser-thc/AFLplusplus
[+] Power schedules from github.com/mboehme/aflfast
[+] Python Mutator and llvm_mode whitelisting from github.com/choller/afl
[+] afl-tmin fork server patch from github.com/nccgroup/TriforceAFL
[+] MOpt Mutator from github.com/puppet-meteor/MOpt-AFL
[] Getting to work...
[+] Using exploration-based constant power schedule (EXPLORE)
[+] You have 4 CPU cores and 2 runnable tasks (utilization: 50%).
[+] Try parallel jobs - see /usr/local/share/doc/afl/parallel_fuzzing.txt.
[] Checking CPU scaling governor...
[] Setting up output directories...
[+] Output directory exists but deemed OK to reuse.
[] Deleting old session data...
[+] Output dir cleanup successful.
[] Scanning 'in'...
[+] No auto-generated dictionary tokens to reuse.
[] Creating hard links for all input files...
[*] Validating target binary...

[-] PROGRAM ABORT : Program '/usr/local/bin/python3' is not a 64-bit Mach-O binary
Location : check_binary(), src/afl-fuzz-init.c:1901

Compilation artifacts not listed in .gitignore

There appears to be a number of compilation artifacts which are not listed in .gitignore, and as a result appear as untracked files in the AFLplusplus git repo after compilation.

These files are as follows:

• afl-analyze.8
• afl-clang-fast++.8
• afl-clang-fast.8
• afl-cmin.8
• afl-fuzz.8
• afl-gcc.8
• afl-gotcpu.8
• afl-plot.8
• afl-showmap.8
• afl-system-config.8
• afl-tmin.8
• afl-whatsup.8
• qemu_mode/libcompcov/compcovtest

These appeared on my system after compiling AFLplusplus by running make distrib and then sudo make install

I have created #65 which adds these files to the .gitignore file, if for some reason these only appeared on my system and not for other people feel free to close this issue and reject the PR.