The program reserves 32 bytes for buffer, then calls gets() to read input. The problem: gets() does not check the buffer size. It keeps reading characters until it encounters a newline. If the user types 40 or 50 characters, the extra characters overflow past the 32-byte buffer.

How memory is laid out on the stack

When a C function runs, the stack (a region of memory) stores:

1. Local variables (like buffer)
2. The saved EBP (base pointer from the calling function)
3. The saved return address (where the CPU should jump when the function returns)

Picture it like this:

When gets() overflows buffer with too much input, the extra bytes overwrite the saved EBP and then the return address.

If we carefully craft the overflow to place a specific address in the return address field, the CPU will jump to that address when the function tries to return.

How the exploit works: Step by step

1. The program starts and allocates buffer[32] on the stack.
2. It calls gets(buffer) to read a line of user input.
3. We send a string that is longer than 32 bytes (say, 50 bytes).
4. gets() has no size check, so it writes all 50 bytes into the buffer.
5. The extra 18 bytes overflow past buffer and overwrite the saved EBP and return address.
6. We carefully construct the overflow so the return address points to shellcode on the stack.
7. When the function returns, the CPU reads the overwritten return address.
8. The CPU jumps to the shellcode.
9. The shellcode runs under the program's permissions.

This is the simplest form of code execution through a buffer overflow.

What happens in the shellcode: The payload

messageBox.asm is a small piece of code designed to run after the overflow.

It does the following:

1. Load USER32.DLL: Calls LoadLibraryA with the string "USER32.DLL" to ensure the library is in memory.
2. Prepare arguments for MessageBoxA: Pushes four arguments onto the stack (window handle, message text, caption, button type).
3. Call MessageBoxA: Calls the Windows API function to display a message box with the text "CAN I HACK THE PC?".
4. Exit cleanly: Calls ExitProcess to safely terminate the program.

The key point: this is executable code that runs after the overflow redirects execution to it. When the message box appears on screen, it proves three things:

1. The buffer overflow worked and rewrote the return address.
2. Execution jumped to the shellcode on the stack.
3. The shellcode ran successfully and made Windows API calls.

In a real attack, this payload could do anything: steal data, create a user, download malware, etc. The message box is just a visible, safe way to demonstrate that arbitrary code execution happened.

This specific payload uses hardcoded memory addresses for MessageBoxA (0x751D8830) and ExitProcess (0x7437ADB0). These addresses are specific to one system. The payload would need to be adjusted for a different Windows version or system.

How to build and run the demo

Step 1: Disable protections

Modern Windows has multiple security features that prevent this exploit:

• Stack Canaries (GS flag): detects stack overwrites.
• ASLR (DYNAMICBASE): randomizes memory addresses so hardcoded addresses don't work.
• DEP/NX (NXCOMPAT): marks the stack as non-executable to prevent code execution there.

For this learning exercise, we disable all of them.

Step 2: Compile on Windows

Use MSVC (Microsoft Visual C++) with specific flags:

Flag meanings:

• /GS- disables stack buffer overrun protection.
• /DYNAMICBASE:NO disables Address Space Layout Randomization (ASLR).
• /NXCOMPAT:NO disables DEP, allowing code on the stack to execute.

If you already have the executable, you can disable protections with editbin:

Step 3: Run it

1. Start vulnerable.exe.
2. When prompted, enter a long string (more than 32 characters).
3. If the overflow works, the saved return address is overwritten.
4. The program may crash, jump to random memory, or (in a real exploit with proper shellcode) execute the payload.

Why the README is complete

This README explains:

1. What gets() is and why it is unsafe (no size limit).
2. How the stack stores local variables, saved registers, and return addresses.
3. How an overflow can overwrite the return address.
4. How the CPU uses the return address when a function returns.
5. How shellcode can execute when the return address points to it.
6. What protections exist and why we disable them.
7. How to build and run the example.

You now understand the entire buffer overflow exploit flow. Read the code files and compare them to this explanation to solidify your understanding.

Important safety notice

This example is for learning only. Do not use this technique against systems you do not own or have explicit permission to test. Unauthorized access to computer systems is illegal.