Fuzzing for Crashes

Fuzzing is sending malformed or oversized input to a program to trigger unexpected behavior, especially crashes. A crash often signals a memory corruption bug.

For buffer overflows, the first goal is to make the target crash so we know an overflow exists.

The classic exploitation workflow is:

• Fuzz to crash the program.
• Find the exact offset to the return address.
• Control EIP.
• Redirect to shellcode.

This lesson covers the first two steps.

To observe crashes, attach a debugger (such as Immunity Debugger or x64dbg on Windows, or GDB on Linux) to the target.

When the program crashes, the debugger shows the state of the registers, especially EIP, which reveals whether we overwrote the return address.

A simple fuzzer sends increasingly large strings until the program crashes. A common starting point is sending many 'A' characters (0x41).

If EIP shows 41414141 after the crash, you have confirmed control over the return address.

When the application crashes and EIP equals 41414141, the overflow reached the saved return address.

But you do not yet know exactly how many bytes precede EIP. Sending all the same byte tells you that EIP is controllable, not where it sits.

To find the precise offset, send a unique non-repeating pattern instead of all 'A's. Each 4-byte window is distinct, so the value that lands in EIP identifies the offset.

Metasploit ships pattern_create.rb for this.

After crashing with the pattern, note the value in EIP. Feed it to pattern_offset.rb and it returns the exact number of bytes before EIP.

This offset is the size of your padding before the return-address bytes.

Always verify. Build an input of offset bytes of 'A' followed by four 'B' bytes (0x42). If EIP becomes 42424242, the offset is exact.

This confirmation prevents wasted hours debugging an off-by-a-few error later.

After controlling EIP, you also note where ESP points at the moment of the crash. ESP usually points just after the overwritten return address, into your remaining buffer.

That space is where you will later place shellcode.

Useful fuzzing and pattern tools include:

• Spike and boofuzz: network protocol fuzzers.
• pattern_create / pattern_offset: locate the EIP offset.
• mona.py in Immunity: automates pattern, offset, and bad-char tasks.

A useful crash must be reproducible. Save the exact input that triggers it and re-run from a clean state to confirm the offset is stable.

Inconsistent crashes often mean the bug is not a clean stack overflow, or that some condition (timing, length, content) varies between runs.

Recall why a cyclic pattern beats a string of identical bytes.

You now know how to find the crash offset:

• Fuzz with growing input to trigger a crash; confirm with 41414141 in EIP.
• Use a cyclic pattern with pattern_create / pattern_offset to find the exact offset.
• Verify with padding + four 'B' bytes (42424242).
• Note where ESP points for later shellcode placement.

Next you will fully control EIP and redirect execution.