Learning to Fuzz

Fuzzing is an automated way to find vulnerabilities in software. Fuzzing has grown in popularity as personal computers have become more accessible and powerful. In this post I will briefly detail my first experience using WinAFL.

The first step was to write some vulnerable code to fuzz. Here’s the function that has the two unique crashes.

void FuzzMe(byte* bytes, unsigned int fileSize)
{
	if (fileSize >= 2)
	{
		if (bytes[0] == 0xBE)
		{
			if (bytes[1] == 0xEF)
			{
				// CRASH
				*(DWORD*)0 = 1;
			}
		}
	}

	if (fileSize >= 4)
	{
		if (bytes[0] == 0xDE)
		{
			if (bytes[1] == 0xAD)
			{
				if (bytes[3] == 0xBE)
				{
					if (bytes[4] == 0xEF)
					{
						// CRASH
						*(DWORD*)0 = 1;
					}
				}
			}
		}
	}
}

This code will crash if given the input of 0xDEADBEEF or 0xBEEF.

Next I used RAMDisk to create a virtual RAM drive for my out folder. Then I ran WinAFL with the following arguments.

afl-fuzz.exe -i in -o r:/out -t 10000 -D D:\DynamoRIO\bin32 -- -covtype edge -fuzz_iterations 100000 -coverage_module vulnerablex32.exe -target_module vulnerablex32.exe -nargs 0 -target_method main -- vulnerablex32.exe @@

It didn’t long for it to find some unique crashes.

Opening each unique crash in 010 Editor looks like this.

At first I was confused as to how that 14 got in the middle of my 0xDEADBEEF. Reviewing my code in the Visual Studio debugger showed my silly mistake.

I accidentally went from bytes[0] and bytes[1] to bytes[3], skipping bytes[2] in the array. Since bytes[2] is never checked it could be anything and still be valid.

I’m excited to learn more about this powerful tool. I’ve only scratched the surface of what WinAFL is capable of. Next I want to point WinAFL at some closed source software and see what I can find.