Find file Copy path
e2af893 Feb 3, 2016
2 contributors

Users who have contributed to this file

@joxeankoret @v-p-b
193 lines (152 sloc) 7.12 KB
Blind Code Coverage Fuzzer (BCCF)
This is a new addition to the Nightmare fuzzing suite. This tool tries
to do one of the following 3 tasks:
* Maximize code coverage of one sample.
* Create new generations that can be used as templates for fuzzing
covering more features that then original template from one file
or a directory with multiple files.
* Discover bugs by executing code not typically covered.
It can be considered an evolutionary fuzzer.
How it works
This fuzzer takes as input some template file and tries to make changes
here and there, randomly, in order to increase code coverage. The target
application will run under instrumentation
in order to be able to determine the total number of different basic
blocks that were executed in each run.
Initially, before making mutations, it will meassure after a number of
executions (10 by default) that maximum, minimum and average number of
different basic blocks executed per each execution (as it may vary
depending on the target application) and then start making many random
modifications any where in the sample in order to maximize execution. By
default, a maximum number of 10 generations (i.e., modifications that
caused the application to execute more new basic blocks) will be saved
in memory.
A generic is dropped after a number of "failures". I mean, if a single
modification makes it execute more basic blocks but after a number of
added modifications the number of basic blocks is always the same or it
drops to a bad number, the generation will be eventually dropped. If, on
the other hand, a new change discover more new basic blocks, the current
generation and statistics will be stored (in memory) and the last new
generation will be considered the current generation.
While this approach is not bullet proof, it certainly can:
* Discover new bugs.
* Maximize code coverage of a sample or set of samples in order to use
them as new templates for another mutator (like radamsa).
This is an experimental tool and, as such, there are so many little
configuration directives and options. However, using the supplied .cfg
file (bcf.cfg) starting with this fuzzer is easy.
For example, let's say that you want to fuzz the tool "readelf". We need
to configure in bcf.cfg:
* The BCF tool section.
* The DynamoRIO section.
* The specific target section.
For BCF and DynamoRIO the following options lines are all we need:
# Configuration for the BCF fuzzer
# Current options are: DynamoRIO, Pin
# Use *ONLY* iterative algorithm instead of all algorithms?
# Use *ONLY* radamsa instead of all the implemented algorithms?
# Configuration for DynamoRIO (requied for code coverage)
The options "iterative" and "radamsa" are completely uninteresting yet,
so let's forget them for now. After those lines we will need to add the
directive for the target application we want to fuzz, in our example
case, "readelf". The following lines are what we need:
# Configuration for "readelf" tool
# Command line to launch it
command=/usr/bin/readelf -a
# Base tube name
# The tube the fuzzer will use to pull of samples
# The tube the fuzzer will use to record crashes
# Extension for the files to be fuzzed
# Timeout for this fuzzer
# Environment
The options are either self-explanatory or already commented so I think
there is no need to go through all of them with the only exception of
the following ones:
* iterative: Use the iterative algorithm? The iterative algorithm will
make modifications byte-per-byte starting from the value "skip-bytes"
* radamsa: Use only radamsa to make new generations?
Both configuration directives can be set at either BCF level (global) or
specific fuzzer level (the recommended setting).
Once we have the BCF tool, DynamoRIO section and our specific target
configuration section(s) already configured in our bcf.cfg file we need
to simply run the following command:
$ cd $NIGHTMARE_DIR/fuzzers
$ 32 bcf.cfg readelf inputtemplate output_dir
The first argument given to is the architecture: 32 for 32bits
architectures (Intel x86) and 64 for 64bits (x86_64).
As for the input template(s): this tool is can be considered "smart". We
can feed to it an (almost) empty file and it will discover the relevant
modifications required to execute more code and, hopefully, discover new
bugs. For example, given a 1024 bytes file filled with 0x00 characters
and only with the typical "\x1FELF" header, the tool will manage to
create files that will make to crash "readelf" or, at the very least,
that will execute more code (new different basic blocks) in the target
Other binary instrumentation backends
The tool was originally developed with DynamoRIO but Pin was also added
as an experimental instrumentation backend. The example of Pin shows
how other backends can be added.
First of all, you should download Pin:
To use Pin for BCF you should grab the RunTracer pintool that is
included in the dependencies/ directory as a Git submodule. You can issue
the following command to grab it:
$ git submodule init
$ git submodule update
After downloading you should copy the RunTracer directory under your
%PINROOT%/source/tools/ and compile with the included Makefile. Pin
requires the following kernel option to be set:
# echo 0 > /proc/sys/kernel/yama/ptrace_scope
After everything works as expected you should configure your fuzzer to
work with Pin in bcf.cnf:
# Current options are: DynamoRIO, Pin
As you can see you should set the bininst-tool parameter in the BCF
section to 'Pin' (case sensitive, no quotes) and also have to define a new
section called 'Pin' and a 'path' parameter pointing to your Pin
Pin backend is handled by the CPinCoverage class declared in the
runtime/ file. It is registered with the name 'Pin' in
the BININST_AVAILABLE_TOOLS dictionary - this is not the best solution
but probably good enough for now.
Copyright (c) 2013, 2014 Joxean Koret