update with changes from master

1 files changed, 11 insertions, 18 deletions

diff --git a/README.md b/README.md
index dff6463b..14e1ae59 100644
--- a/README.md
+++ b/README.md
@@ -12,6 +12,10 @@
   afl++ is maintained by Marc Heuse <mh@mh-sec.de>, Heiko Eißfeldt
   <heiko.eissfeldt@hexco.de> and Andrea Fioraldi <andreafioraldi@gmail.com>.
 
+  Note that although afl now has a Google afl repository [https://github.com/Google/afl](https://github.com/Google/afl),
+  it is unlikely to receive any noteable enhancements: [https://twitter.com/Dor3s/status/1154737061787660288](https://twitter.com/Dor3s/status/1154737061787660288)
+
+
 ## The enhancements compared to the original stock afl
 
   Many improvements were made over the official afl release - which did not
@@ -19,7 +23,8 @@
 
   Among others afl++ has, e.g. more performant llvm_mode, supporting
   llvm up to version 9, Qemu 3.1, more speed and crashfixes for Qemu,
-  laf-intel feature for Qemu (with libcompcov) and more.
+  laf-intel feature for Qemu (with libcompcov), better *BSD and Android
+  support and more.
 
   Additionally the following patches have been integrated:
 
@@ -50,7 +55,6 @@
 
 
 ## 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
@@ -173,7 +177,6 @@ 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
@@ -201,7 +204,6 @@ A more comprehensive description of these and other options can be found in
 
 
 ## 5) Power schedules
-------------------
 
 The power schedules were copied from Marcel Böhme's excellent AFLfast
 implementation and expands on the ability to discover new paths and
@@ -233,7 +235,6 @@ Computer and Communications Security (CCS'16):
 
 
 ## 6) 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
@@ -255,7 +256,6 @@ exercise different code paths in the target binary.
 
 
 ## 7) 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
@@ -294,7 +294,6 @@ fuzzers - add the -d option to the command line.
 
 
 ## 8) Interpreting output
-----------------------
 
 See the [docs/status_screen.txt](docs/status_screen.txt) file for information on
 how to interpret the displayed stats and monitor the health of the process. Be
@@ -356,7 +355,6 @@ see [http://lcamtuf.coredump.cx/afl/plot/](http://lcamtuf.coredump.cx/afl/plot/)
 
 
 ## 9) 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.
@@ -369,7 +367,6 @@ last section of [docs/parallel_fuzzing.txt](docs/parallel_fuzzing.txt) for tips.
 
 
 ## 10) Fuzzer dictionaries
-----------------------
 
 By default, afl-fuzz mutation engine is optimized for compact data formats -
 say, images, multimedia, compressed data, regular expression syntax, or shell
@@ -406,7 +403,6 @@ utility with AFL. For that, see [libtokencap/README.tokencap](libtokencap/README
 
 
 ## 11) 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.
@@ -455,7 +451,6 @@ near the end of [docs/technical_details.txt](docs/technical_details.txt).
 
 
 ## 12) 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
@@ -480,7 +475,6 @@ shared with libfuzzer) or `#ifdef __AFL_COMPILER` (this one is just for AFL).
 
 
 ## 13) 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:
@@ -511,7 +505,6 @@ tasks, fuzzing may put strain on your hardware and on the OS. In particular:
 
 
 ## 14) Known limitations & areas for improvement
----------------------------------------------
 
 Here are some of the most important caveats for AFL:
 
@@ -553,10 +546,9 @@ Beyond this, see INSTALL for platform-specific tips.
 
 
 ## 15) Special thanks
-------------------
 
-Many of the improvements to the original afl wouldn't be possible without
-feedback, bug reports, or patches from:
+Many of the improvements to the original afl and afl++ wouldn't be possible
+without feedback, bug reports, or patches from:
 
 ```
   Jann Horn                             Hanno Boeck
@@ -598,14 +590,15 @@ feedback, bug reports, or patches from:
   Rene Freingruber                      Sergey Davidoff
   Sami Liedes                           Craig Young
   Andrzej Jackowski                     Daniel Hodson
-  Nathan Voss				Dominik Maier
+  Nathan Voss                           Dominik Maier
+  Andrea Biondo                         Vincent Le Garrec
+  Khaled Yakdan                         Kuang-che Wu
 ```
 
 Thank you!
 
 
 ## 16) Contact
------------
 
 Questions? Concerns? Bug reports? The contributors can be reached via
 [https://github.com/vanhauser-thc/AFLplusplus](https://github.com/vanhauser-thc/AFLplusplus)