An patch for shellphish's Driller. Add support for strip static linked binaries, for which uses IDrillerA's result to hook libc functions.
In some cases, we need to fuzz static linked binaries. Driller is not good at solving static binaires, for it depands on angr platform, and it is a waste of doing symbolic execution in lib.
So we use IDA_Wrapper(https://github.com/cxm95/IDA_Wrapper) to do lib function identification, and automatic add hook functions from angr(procedures).
It works well after testing with some simple binaries, such as pwn20, which cannot be solved after 12 hours of fuzzing using AFL, but several minute using sDriller.
pwn20: (https://github.com/cxm95/IDA_Wrapper/blob/master/test/pwn20)
git clone this repo
install requirements
python setup.py build
pip install -v -e .
Driller is an implementation of the driller paper. This implementation was built on top of AFL with angr being used as a symbolic tracer. Driller selectively traces inputs generated by AFL when AFL stops reporting any paths as 'favorites'. Driller will take all untraced paths which exist in AFL's queue and look for basic block transitions AFL failed to find satisfying inputs for. Driller will then use angr to synthesize inputs for these basic block transitions and present it to AFL for syncing. From here, AFL can determine if any paths generated by Driller are interesting, it will then go ahead and mutate these as normal in an attempt to find more paths.
Driller's symbolic execution component is invoked when AFL is 'stuck'. In this implementation, AFL's progress is determined by its 'pending_favs' attribute which can found in the fuzzer_stats file. When this attribute reaches 0, Driller is invoked. Other heuristics could also be used, and it's infact likely that better heuristics exist.
This same implementation of Driller was used team Shellphish in DARPA's Cyber Grand Challenge (CGC) to aid in the discovery of exploitable bugs. To see how Driller's invokation was scheduled for the CGC you can look at the Mechanical Phish's scheduler component 'meister'.
The code currently supports three modes of operation:
- A script that facilitates AFL and driller on one machine (over many cores if needed): https://github.com/shellphish/fuzzer/blob/master/shellphuzz
- A monitor process watches over the fuzzer_stats file to determine when Driller should be invoked. When Driller looks like it could be useful, the monitor process schedules 'jobs' to work over all the inputs AFL has discovered / deemed interesting.
- Celery tasks are assigned over a fleet of machines, some number of these tasks are assigned to fuzzing, some are assigned to drilling. Fuzzer tasks monitors the stats file, and invokes driller tasks when Driller looks like it could be useful. Redis is used to sync testcases to the filesystem of the fuzzer.
Driller was built and developed for DECREE binaries.
While some support for other formats should work out-of-the-box, expect TracerMisfollowError
s to occur when unsupported or incorrectly implemented simprocedures are hit.
Here is an example of using driller to find new testcases based off the trace of a single testcase.
import driller
d = driller.Driller("./CADET_00001", # path to the target binary
"racecar", # initial testcase
"\xff" * 65535, # AFL bitmap with no discovered transitions
)
new_inputs = d.drill()
- Mechaphish Fuzzer component
- Mechaphish Tracer component