File Fuzzing Using Minifuzz

What is Fuzzing?

Fuzz testing is a testing technique that provides malicious input to the application. Fuzz testing is crashes, assertion failures, and memory leaks when program fails to handle the malicious input. Fuzz testing identifies vulnerabilities which are severe in nature. The typical fuzzing checks the application for buffer overflow, format string vulnerability which can be highly automated.

Fuzz testing can also be used to find out XSS, Sql injection like vulnerabilities. Google is developing a tool called Lemon which can be used to find out XSS, Sql Injection, HTTP response splitting, Cookie poisoning, Stack trace leaks, Encoding issues and Charset bugs.

For more info:

Fuzzing can have a great impact on the quality of source code.


Below method need to fuzz tested as it accepts the data in the form of given file name.

public static byte[] ReadFile(String FilePath)
FileStream fs = new FileStream(FilePath, FileMode.Open, FileAccess.Read,
	int length = (int)fs.Length;
	byte[] data = new byte[length];
	// Perform some action with the data read
	catch (Exception)

Types of Fuzz Testing

Dumb fuzzing:  Randomly changing data and then supplied into an application.
Smart fuzzing : Changing specific data with the knowledge of underlying format the application accepts.

How it works?

The process of fuzz testing is quite simple as described in the below steps.

  1. Program accepts the file.
  2. Create malformed data.
  3. Program accepts the malformed data.
  4. If program breaks or unhandled exception occurs, the vulnerability has been found.

Note: Not every unhandled exception/crash is vulnerability. It is a bug. Further analysis can determine if it’s a security bug.

To analyze crashes use !exploitable Crash Analyzer which is the used to automate crash and risk assessment.


Minifuzz File Fuzzer

Minifuzz tool helps in detecting security flaws that may expose application vulnerabilities in file handling code. The Minifuzz tool accepts the file content and creates a multiple variations of the same file to identify the application behavior for handling different file formats. You should first need to define the file content the application accepts and based on that you should run Minifuzz for the applicable file formats.

It is simple fuzzer designed to ease adoption of fuzz testing by non-security professionals who are not familiar with file fuzzing.

Minifuzz testing must be performed during Microsoft security development lifecycle (SDL) Verification Phase.

file fuzz

Using Minifuzz:

Below is the sample demonstration of MiniFuzz File Fuzzer.
Here we will be fuzzing Agent.exe application. Below is the parameter we need to set in order to perform fuzzing.

Field Description
Process to fuzz This is the full path and the name of the executable under test.
Command line args Place holder and optional switches to pass to the process under test. %1 is a placeholder for the name of the corrupted file, and because the name is random, you won’t know the filename ahead of time but the fuzzer does. If your tool requires a command line switch to set the name of the file, then you should include that also. For example, if your application requires you set the filename using the /F: option, then you can use this: /F:%1
Allow process to run for This is the maximum time in seconds to allow the process to run before killing the process. Whatever time you set, it should be long enough to allow the process to render or parse the file. If the application does not die in the allotted time, MiniFuzz will terminate the process.
Important: Do not be overly aggressive with this value by making the value very small because the application under test might not have time to start up, configure itself, load the file and then render the file before MiniFuzz tears the process down. Start out at 2.0 seconds, and then after a couple of tests, throttle back to 1.5, then if needed 1.0 or, the lowest possible value, 0.5 seconds.
Also, for very large files, over 1Mb, you should increase this setting substantially because it will take time for the process under test to load the file off the disk.
Shutdown method MiniFuzz can close an application down by using one of three methods:
Thread Injection injects a new thread into the target process and then calls ExitProcess on that threat. This works for all Windows applications and is a graceful shutdown. This is the default setting.
WM_CLOSE is the most graceful shutdown method as it instructs the application to shut down cleanly. This only works for graphical applications, not for console applications.
TerminateProcess is a Windows API that tears the application down. It’s brutal, and it can lead to some resources left un-freed. Any application type can be shut down this way, but it should be used as a last resort.
Do not be alarmed if you see dozen of your target processes running at once, this is quite normal because shutting processes down can take time for some kinds of processes. If you see hundreds of instances of you application, then the fuzzer is not shutting the process down correctly, or your application is preventing shutdown.
Template Files This is where you have stored your set of template files; you can override this setting if you need to.
Temporary files This is the location of all the corrupted files. MiniFuzz deletes these files in the background, so it’s not unusual to see about ten files in this folder at any given time. MiniFuzz will also attempt to delete any files remaining in this folder when MiniFuzz exits. This location is configurable through the XML configuration file described in “Step 2: Configure MiniFuzz” on page 3.
Log files This is the location of the log file that tracks all crashes. More on this file in a moment.
Crash files In the application under test crashes, the offending file is removed from the temporary folder and written to this folder. This location is configurable through the XML configuration file described in “Step 2: Configure MiniFuzz” on page 3.
Aggressiveness This setting determines how much of the incoming file to fuzz. There is no value that is better than any other number because sometimes a very subtle single bit change might trigger an application to fail. Large changes may render a file so badly malformed that your parsing code rejects the file very early in the parsing process. In short, you need to work out what the most appropriate level or aggressiveness is for your parsing code.
Always on Top This means MiniFuzz always runs as the top-most window.
Start Fuzzing As the name suggests, this starts the fuzzing process once you have set all the appropriate settings.
Stop Fuzzing Stops the fuzzing process, but does not reset the progress data.
View Log Dir Opens the folder that contains all the log files.
TFS Settings Opens a dialog box that allows you to view and configure Visual Studio Team Foundation Server settings.
About Brings up the About dialog box.
Progress section This section lists ongoing tally information such as the number of files read and the number of crashes.


Once the fuzzing is started, leave the application to run for at least an hour or two. Minifuzz then creates different variations of the file which is then passed to the application. Security Development Lifecycle (SDL) recommends to test 100,000 patterns for each file format. Below figure shows the different variations of file created by Minifuzz.

Figure below show the file for which the application got crashed.

Same can be seen in log file.




1 comment

I have a question on template files. If i want to fuzz email client application like outlook then how do i generate templates for it.

Any example or sample file will be helpful.


Leave a Reply

Your email address will not be published. Required fields are marked *

For security, use of Google's reCAPTCHA service is required which is subject to the Google Privacy Policy and Terms of Use.

I agree to these terms.