Change Log

See BFF Release Notes

Requirements

• UbuFuzz requires VMWare Workstation 7 or later, or compatible virtualization software.
• The OS X installer requires Snow Leopard or later. 
  • Xcode Tools is recommended, which provides libgmalloc (Guard Malloc).

Demo Quick Start

UbuFuzz

1. Unzip BFF-2.7.zip to c:\fuzz or another folder to be shared as "fuzz"
2. Unzip UbuFuzz-2.7.zip
3. Open UbuFuzz.vmx
4. Create a snapshot in VMWare
5. Power on the VM

If you do not wish to use a shared folder, simply remove ~/bff
and unzip BFF-2.7.zip to the ~/bff directory.

OS X

1. Install BFF
2. Run BFF
3. Run ./batch.sh

...

Look in ~/results to investigate the fuzzing results.

To use BFF without UbuFuzz

See BFF Installation Notes

Additional information

The configuration for VMWare may prevent virtual machines from utilizing shared folders by default. You may need to manually enable shared folders for the VM after opening the VMX. If you chose to unzip scripts.zip to a folder other than c:\fuzz, then you will need to modify the properties of the shared folder in VMWare to point to the new location of the files. Alternatively, if you may unzip the BFF scripts into ~/bff if you do not wish to use a shared folder.

...

CFLAGS="-g -O0" ./configure --without-x

Analyzing results

When the fuzzing run encounters a crash, BFF will analyze the details of the crash. This involves capturing stderr, gdb, valgrind, and callgrind output. The gdb output contains several pieces of information, including the memory map, signal information, backtrace, registers, disassembly, as well as output from the CERT Triage Tools, which indicates possible exploitability of the crash. On the OS X platform, CrashWrangler is used instead of gdb. By looking at the backtrace, BFF will keep track of which test cases cause unique crashes. Each unique crash will be placed in the configured output directory.

...

• crashers: Contains a subdir for each uniquely-crashing test case and its analyzed results
• seeds: Contains the original seedfiles as well as logs specific to that seedfile

Other files of note:

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

...

Metasploit pattern enumeration

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

...

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

Analysis tools

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

...

• 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 the batch.sh script in the VMWare shared folder. In order to power on the virtual machine without it beginning a fuzzing campaign, you should rename batch.sh. This will allow you to power on the virtual machine to install the target software. Once BFF has started a fuzzing run, it will copy bff.cfg to 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.

...