...

• results/uniquelog.txt – a log file that tracks the unique crashers found during the run

The "results/crashers" directory will contain the uniquely-crashing
test cases. The variants that have crashed the target application
will application will be stored here with the zzuf seed number appended to the
seed the seed file name. For each uniquely-crashing case, there will also
be also be a .stderr, .gdb, .callgrind and .valgrind file that contains
the contains the stderr, gdb, callgrind and valgrind output for that case,
respectively respectively.

The CERT BFF minimizes crashers. In other words, each crashing
test crashing test case will have a number of bytes that have been modified
from modified from the seed file. When a crasher is minimized, a test case is
generated is generated with a minimal number of bytes that have changed from
the from the seed file. The minimized test case will have "-minimized"
inserted  inserted into the filename before the extension. Also, a
minimizera minimizer_log.txt file is created containing a log of the
minimization the minimization process. This is used by tools/minimizer_plot.py
py to produce a chart showing the minimizer progress. 

Aside from minimizing to the seed file, BFF also includes the
ability the ability to minimize a crashing testcase to a string pattern.
This  This will show which bytes of a file may be altered without
affecting without affecting the crash. Due to performance issues, the
minimizethe minimize-to-string option is disabled by default. However, the
minimizer the minimizer can be run in a standalone mode.

Say you have a crashing test case, but you really need to get it to a
proofa proof-of-concept exploit. The problem is when you load the crash into your
debugger your debugger you can't easily tell which registers, stack values, or memory
locations memory locations are under your control. But what if you could change the crashing
test case so that it had only the bytes required to cause that crash, and the
rest the rest were all masked out with a fixed value, say "x" (0x78)? Then you'd know
that if you saw EIP=0x78787878, you may already be a winner. The
minimizeThe minimize-to-string option does just that.

To get command-line usage of the minimizer, run: 

tools\minimize.py --help

To minimize a crashing testcase to the Metasploit string pattern, run:

tools\minimize.py --stringmode <crashing_testcase>

When minimizing to the Metasploit pattern, FOE will use the resulting byte map
to map to create an additional minimized file that uses a string of 'x' characters. 

...

Metasploit pattern enumeration

...

Especially with larger files, you may notice that the Metasploit pattern
repeats pattern repeats several times over the length of a Metasploit-minimized crasher.
Given  Given any particular dword, it may not be obvious which instance is the one
that one that you are dealing with. This is where the tools\mtsp_enum.py script comes
in comes in handy. For example, let's say that you have a crasher.doc were EIP = "Aa0A"
If  If you run:  

Code Block
tools\mtsp_enum.py Aa0A crasher.doc

You will end up with a file called crasher-enum.doc. With this file, every
instance every instance of the byte pattern "Aa0A" will be replaced with a unique,
incrementing  incrementing replacement. For example, "0a0A", "1a0A", "2a0A", etc. Now when
you when you open crasher-enum.doc, you could for example get EIP = "5a0A". If you
search you search for that pattern in the file, there should be only once instance of it.
Note  Note that you can use a search pattern of any length and you can also search
for search for hex values. For example: "\x01\x02\x03\x04" 

Analysis tools

The analysis directory contains a few tools for analyzing the
results the results of a fuzz run. 

Try 'python <script> --help' for  for detailed usage options.

• tools/bff_stats.py generates a concise summary of the fuzz

...

• run results so far, including how many times each unique crash

...

• was seen, the first seed number it was seen at, the most recent

...

• seed number it was seen, and the bitwise and bytewise Hamming

...

• Distance from the original seedfile for the minimized testcase.
• tools/callsim.py can display crashes clustered by

...

• the similarity of their called functions. This analysis is based

...

• on the idea that crashes with similar call history are likely to

...

• be related even if they result in unique crash hashes. The

...

• resulting clusters of crashes can be useful in deciding which crashes

...

• to investigate first given a large number of crashes. The

...

• source data for this analysis is callgrind output generated for

...

• each crash.
• tools/create_crasher_script.py will generate a shell

...

• script that in turn can be used to regenerate all the test cases for

...

• a given crash id. The use of the '--destination' option

...

• is highly recommended.
• tools/minimizer_plot.py plots the minimizer data for a

...

• given crash, showing how the minimizer tunes its parameters as

...

• it progresses in order to find the optimal minimized test case.
• tools/drillresults.py will search for crashing test cases

...

• that are more easily exploitable than the others. It searches

...

• based on the type of crash as well as whether the faulting

...

• address matches patterns in the fuzzed file.
• tools/repro.py will launch the specified application using the

...

• same command-line parameters as configure for the fuzzing

...

• campaign. This can be used to test crashing testcases

...

• interactively.

...

Fuzzing on your own

...

When the UbuFuzz VM is powered on, it will automatically
execute automatically execute the batch.sh script in the VMWare shared folder. In order
to order to power on the virtual machine without it beginning a fuzzing
campaignfuzzing campaign, you should rename batch.sh. This will allow you to
power to power on the virtual machine to install the target software. Once
BFF Once BFF has started a fuzzing run, it will copy bff.cfg to the
the /home/fuzz directory in the virtual machine. This configuration
file will be used for subsequent fuzzing runs, rather than the
copy in the shared folder. This is why it is important to make
a snapshot of the VM in its clean state. If you wish to reset
a fuzzing machine to a clean state, e.g. to start a new fuzzing
campaign or if you've change fuzzing parameters or seed files,
you should run the ~/bff/reset_bff.sh script.

The first step to beginning a fuzzing run is to obtain and
install and install the target software. Usually this process will involve
downloading involve downloading the application source code and compiling a debug
version debug version of it. Rather than using Ubuntu's package repository,
this  this will ensure that you will be fuzzing the latest version of
the of the target application. It will also give you the ability to have
debug have debug symbols, as well as the ability to use a non-optimized
build optimized build if you like.

Create a new snapshot of the VM after the target software has
been has been installed.

The bff.cfg file contains all of the parameters for the fuzzing
runfuzzing run. This file must be edited to suit the software that you will
be will be fuzzing. The bff.cfg file is annotated and should be
relatively be relatively self-explanatory.

The default bff.cfg file will start a fuzzing run that invokes:

Code Block
convert $SEEDFILE /dev/null

This will use ImageMagick's "convert" program to process the seed
fileseed file, outputting to /dev/null. Because BFF will mangle the seed
fileseed file, this fuzzing run will exercise ImageMagick's decoding
capabilitiesdecoding capabilities.

You should choose a command line that efficiently exercies the
capabilities of the exercises the capabilities of the application that you wish to test. Ideally,
this  this will involve a command-line application that terminates
immediately terminates immediately upon completion. In such cases, the fuzzing run will
be will be CPU-bound, as BFF will invoke the application as fast as it
canit can. Applications that have a GUI can still be fuzzed using this
frameworkthis framework. However, in most cases, each invocation of the target
application target application will need to wait for the specified timeout to elapse
before elapse before the process is terminated.

BFF analyzes gdb (or CrashWrangler on OS X) backtraces to
determine to determine uniquely-crashing testcases. The default setting is to
hash to hash the last five code locations in the backtrace to determine a
hash a hash for the crash. We have found this value to be effective for
most for most applications, however you can adjust the value to fit your
needsyour needs.

Another important bff.cfg option is the "copymode" setting. By
default setting. By default, zzuf will use LD_PRELOAD to hook into an application to
perform to perform input mangling and intercept signals. In some cases, the
target application will not behave properly in this mode. The
file The file may fail to be mangled, or the target application may fail
to fail to run properly at all. If this is the case, set "copymode" to 1
and 1 and zzuf will create a temporary file and then open that file
with file with the target application. Most OS X applications require copy
modecopy mode, so the default bff.cfg provided on OS X will default to this
modethis mode.

There are several options within bff.cfg related to application
timeoutsapplication timeouts. "progtimeout" is the maximum time that BFF will allow
a allow a single invocation of the target application to run before
terminating before terminating it. In the case of the "convert" component of
ImageMagick convert component of ImageMagick, it is reasonable to expect the program to finish
within finish within a few seconds. Depending on the application you are
fuzzingare fuzzing, this value will need to be adjusted. Especially with GUI
applicationsGUI applications, the goal is to allow the application to run long
enough long enough to process the input file, but not so long that the
application the application is sitting idle for an amount of time for each
invocationeach invocation. The "killprocname" and "killproctimeout" options are
used  and killproctimeout options are used for the external process killer. When running some analyzers,
the  the application that you are fuzzing may be left running after
the after the analyzer is terminated. The external process killer
killer (killproc.sh) is a script that polls running processes and makes
sure makes sure that no single instance of the specified application is
allowed is allowed to run for longer than the specified time.

Once you have configured the options in bff.cfg, power on the
UbuFuzz the UbuFuzz VM. It should begin fuzzing automatically. If the
target the target is a GUI application, you should see the application
launch application launch repeatedly as it is being fuzzed. If it is a command-line
applicationline application, you should notice increased CPU usage in the top
windowtop window. The first seed_interval that BFF executes will also
display also display stderr to the terminal window to let you see if something
is something is obviously wrong. If you need to tweak your settings, such as
by as by using a smaller progtimeout value to improve throughput, you
can you can edit the bff.cfg file and restore the VM to its previous
snapshotprevious snapshot. Alternatively, you can run ~/bff/reset_bff.sh and
restart and restart X to cause the VM to re-read the shared bff.cfg file and
start and start fuzzing again.