updated binary_fuzzing document

This commit is contained in:
van Hauser
2020-01-27 13:06:00 +01:00
parent 3374ada561
commit 17f0aad0f0

View File

@ -1,6 +1,4 @@
#Fuzzing binary-only programs with afl++
Fuzzing binary-only programs with afl++
=======================================
afl++, libfuzzer and others are great if you have the source code, and afl++, libfuzzer and others are great if you have the source code, and
it allows for very fast and coverage guided fuzzing. it allows for very fast and coverage guided fuzzing.
@ -16,36 +14,42 @@ TL;DR: try DYNINST with afl-dyninst. If it produces too many crashes then
!!!!! !!!!!
QEMU ##QEMU
----
Qemu is the "native" solution to the program. Qemu is the "native" solution to the program.
It is available in the ./qemu_mode/ directory and once compiled it can It is available in the ./qemu_mode/ directory and once compiled it can
be accessed by the afl-fuzz -Q command line option. be accessed by the afl-fuzz -Q command line option.
The speed decrease is at about 50% The speed decrease is at about 50%
It is the easiest to use alternative and even works for cross-platform binaries. It is the easiest to use alternative and even works for cross-platform binaries.
Note that there is also honggfuzz: [https://github.com/google/honggfuzz](https://github.com/google/honggfuzz)
which now has a qemu_mode, but its performance is just 1.5%!
As it is included in afl++ this needs no URL. As it is included in afl++ this needs no URL.
WINE+QEMU
--------- ##WINE+QEMU
Wine mode can run Win32 PE binaries with the QEMU instrumentation. Wine mode can run Win32 PE binaries with the QEMU instrumentation.
It needs Wine, python3 and the pefile python package installed. It needs Wine, python3 and the pefile python package installed.
UNICORN As it is included in afl++ this needs no URL.
-------
##UNICORN
Unicorn is a fork of QEMU. The instrumentation is, therefore, very similar. Unicorn is a fork of QEMU. The instrumentation is, therefore, very similar.
In contrast to QEMU, Unicorn does not offer a full system or even userland emulation. In contrast to QEMU, Unicorn does not offer a full system or even userland
Runtime environment and/or loaders have to be written from scratch, if needed. emulation. Runtime environment and/or loaders have to be written from scratch,
On top, block chaining has been removed. This means the speed boost introduced in if needed. On top, block chaining has been removed. This means the speed boost
the patched QEMU Mode of afl++ cannot simply be ported over to Unicorn. introduced in the patched QEMU Mode of afl++ cannot simply be ported over to
For further information, check out ./unicorn_mode.txt. Unicorn. For further information, check out ./unicorn_mode.txt.
As it is included in afl++ this needs no URL.
DYNINST ##DYNINST
-------
Dyninst is a binary instrumentation framework similar to Pintool and Dynamorio Dyninst is a binary instrumentation framework similar to Pintool and Dynamorio
(see far below). However whereas Pintool and Dynamorio work at runtime, dyninst (see far below). However whereas Pintool and Dynamorio work at runtime, dyninst
instruments the target at load time, and then let it run. instruments the target at load time, and then let it run - or save the
binary with the changes.
This is great for some things, e.g. fuzzing, and not so effective for others, This is great for some things, e.g. fuzzing, and not so effective for others,
e.g. malware analysis. e.g. malware analysis.
@ -53,9 +57,9 @@ So what we can do with dyninst is taking every basic block, and put afl's
instrumention code in there - and then save the binary. instrumention code in there - and then save the binary.
Afterwards we can just fuzz the newly saved target binary with afl-fuzz. Afterwards we can just fuzz the newly saved target binary with afl-fuzz.
Sounds great? It is. The issue though - it is a non-trivial problem to Sounds great? It is. The issue though - it is a non-trivial problem to
insert instructions, which change addresses in the process space, so insert instructions, which change addresses in the process space, so that
everything is still working afterwards. Hence more often than not binaries everything is still working afterwards. Hence more often than not binaries
crash when they are run (because of instrumentation). crash when they are run.
The speed decrease is about 15-35%, depending on the optimization options The speed decrease is about 15-35%, depending on the optimization options
used with afl-dyninst. used with afl-dyninst.
@ -63,11 +67,10 @@ used with afl-dyninst.
So if dyninst works, it is the best option available. Otherwise it just doesn't So if dyninst works, it is the best option available. Otherwise it just doesn't
work well. work well.
https://github.com/vanhauser-thc/afl-dyninst [https://github.com/vanhauser-thc/afl-dyninst](https://github.com/vanhauser-thc/afl-dyninst)
INTEL-PT ##INTEL-PT
--------
If you have a newer Intel CPU, you can make use of Intels processor trace. If you have a newer Intel CPU, you can make use of Intels processor trace.
The big issue with Intel's PT is the small buffer size and the complex The big issue with Intel's PT is the small buffer size and the complex
encoding of the debug information collected through PT. encoding of the debug information collected through PT.
@ -77,30 +80,39 @@ the implementation and other factors).
There are two afl intel-pt implementations: There are two afl intel-pt implementations:
1. https://github.com/junxzm1990/afl-pt 1. [https://github.com/junxzm1990/afl-pt](https://github.com/junxzm1990/afl-pt)
=> this needs Ubuntu 14.04.05 without any updates and the 4.4 kernel. => this needs Ubuntu 14.04.05 without any updates and the 4.4 kernel.
2. https://github.com/hunter-ht-2018/ptfuzzer 2. [https://github.com/hunter-ht-2018/ptfuzzer](https://github.com/hunter-ht-2018/ptfuzzer)
=> this needs a 4.14 or 4.15 kernel. the "nopti" kernel boot option must => this needs a 4.14 or 4.15 kernel. the "nopti" kernel boot option must
be used. This one is faster than the other. be used. This one is faster than the other.
Note that there is also honggfuzz: https://github.com/google/honggfuzz
But its IPT performance is just 6%!
CORESIGHT
---------
##CORESIGHT
Coresight is ARM's answer to Intel's PT. Coresight is ARM's answer to Intel's PT.
There is no implementation so far which handle coresight and getting There is no implementation so far which handle coresight and getting
it working on an ARM Linux is very difficult due to custom kernel building it working on an ARM Linux is very difficult due to custom kernel building
on embedded systems is difficult. And finding one that has coresight in on embedded systems is difficult. And finding one that has coresight in
the ARM chip is difficult too. the ARM chip is difficult too.
My guess is that it is slower than Qemu, but faster than Intel PT. My guess is that it is slower than Qemu, but faster than Intel PT.
If anyone finds any coresight implementation for afl please ping me: If anyone finds any coresight implementation for afl please ping me:
vh@thc.org vh@thc.org
PIN & DYNAMORIO ##FRIDA
--------------- Frida is a dynamic instrumentation engine like Pintool, Dyninst and Dynamorio.
What is special is that it is written Python, and scripted with Javascript.
It is mostly used to reverse binaries on mobile phones however can be used
everywhere.
There is a WIP fuzzer available at [https://github.com/andreafioraldi/frida-fuzzer](https://github.com/andreafioraldi/frida-fuzzer)
##PIN & DYNAMORIO
Pintool and Dynamorio are dynamic instrumentation engines, and they can be Pintool and Dynamorio are dynamic instrumentation engines, and they can be
used for getting basic block information at runtime. used for getting basic block information at runtime.
Pintool is only available for Intel x32/x64 on Linux, Mac OS and Windows Pintool is only available for Intel x32/x64 on Linux, Mac OS and Windows
@ -115,30 +127,27 @@ Hence Dynamorio is the option to go for if everything fails, and Pintool
only if Dynamorio fails too. only if Dynamorio fails too.
Dynamorio solutions: Dynamorio solutions:
https://github.com/vanhauser-thc/afl-dynamorio * [https://github.com/vanhauser-thc/afl-dynamorio](https://github.com/vanhauser-thc/afl-dynamorio)
https://github.com/mxmssh/drAFL * [https://github.com/mxmssh/drAFL](https://github.com/mxmssh/drAFL)
https://github.com/googleprojectzero/winafl/ <= very good but windows only * [https://github.com/googleprojectzero/winafl/](https://github.com/googleprojectzero/winafl/) <= very good but windows only
Pintool solutions: Pintool solutions:
https://github.com/vanhauser-thc/afl-pin * [https://github.com/vanhauser-thc/afl-pin](https://github.com/vanhauser-thc/afl-pin)
https://github.com/mothran/aflpin * [https://github.com/mothran/aflpin](https://github.com/mothran/aflpin)
https://github.com/spinpx/afl_pin_mode <= only old Pintool version supported * [https://github.com/spinpx/afl_pin_mode](https://github.com/spinpx/afl_pin_mode) <= only old Pintool version supported
Non-AFL solutions ##Non-AFL solutions
----------------- There are many binary-only fuzzing frameworks.
Some are great for CTFs but don't work with large binaries, others are very
slow but have good path discovery, some are very hard to set-up ...
There are many binary-only fuzzing frameworks. Some are great for CTFs but don't * QSYM: [https://github.com/sslab-gatech/qsym](https://github.com/sslab-gatech/qsym)
work with large binaries, others are very slow but have good path discovery, * Manticore: [https://github.com/trailofbits/manticore](https://github.com/trailofbits/manticore)
some are very hard to set-up ... * S2E: [https://github.com/S2E](https://github.com/S2E)
* <please send me any missing that are good>
QSYM: https://github.com/sslab-gatech/qsym
Manticore: https://github.com/trailofbits/manticore
S2E: https://github.com/S2E
<please send me any missing that are good>
## Closing words
That's it! That's it! News, corrections, updates? Send an email to vh@thc.org
News, corrections, updates?
Email vh@thc.org