Change Log

See BFF 2.7 Release Notes

...

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

The fuzzing virtual machine is preconfigured to automatically
begin a fuzzing run on several image format decoders provided
by ImageMagick's "convert" program. An old (5.2.0) version of
ImageMagick is preloaded onto the VM. ImageMagick was built
with debug symbols as well as non-optimized. This makes gdb
provide more useful crash reports. ImageMagick was configured
using the following command:
CFLAGS="-g -O0" ./configure --without-x

...

BFF will copy its configuration to results/bff.cfg, and will
log will log messages of level INFO or higher into results/bff.log. The
config The config file copied here is just for recording purposes, another
copy another copy is made in /home/fuzz and it is this copy of the file that
actually gets used by BFF.

Additionally the following subdirectories are created in the
results the results dir:*

• 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

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

...

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: tools\mtsp_enum.py Aa0A crasher.doc
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.
Try 'python <script> --help' for detailed usage options.

...

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.

...