Let's load our program into GDB and see what's going on behind the curtain. We'll issue the run command with our initial test input and then examine the registers to see what the normal operation looks like, as follows:

# gdb demo
(gdb) break 6
(gdb) run test
(gdb) info registers

As we can see in the preceding screenshot, esp and ebp are right next to each other, so now we can figure out the stack frame. Working from esp, let's find the return address, remembering it'll be the first hexadecimal word after the base pointer. We know that we start at the esp, but how far do we look in memory? Let's review the math.

The stack pointer is at 0xbffff220 and the base pointer is at 0xbfff358. This means we can eliminate bfff, so we're counting hexadecimal words from 220 to 358. An easy way to think of this is by counting groups of 16: 220, 230, 240, 250, and so on, up to 360 , which is 20 groups. Therefore, we'll examine 80 hexadecimal words.

(gdb) x/80x $esp

If you find the base pointer address and then identify the hexadecimal word right after it, you will get the return address, as shown in the following screenshot:

Examine this until it makes sense. Then, use quit to exit so we can do the same procedure over again. This time, we will crash our program with a long string of the letter z:

# gdb demo
(gdb) break 6
(gdb) run $(python -c 'print "z"*400')

Ahh! What have we done? Take a look at the memory address the function is trying to jump to, shown in the following screenshot:

As you can see, if you run x/80x $esp as you did before, you'll see the stack again. Find the base pointer, then read the hexadecimal word after it. It now says 0x7a7a7a7a. 7a is the hexadecimal representation of the ASCII z. We overflowed the buffer and replaced the return address! Our computer is very angry with us about this because 0x7a7a7a7a either doesn't exist or we have no business jumping there. Before we move on to turning this into a working attack, we need to make sure we understand the order of bits in memory.