Since we want to skip the statement at 0x0804842d and get to 0x08048434, we can calculate the difference to by 7 bytes easily enough. Hence, that's why I know it's correct to increment the ret pointer by 7.

What I can't figure out for the life of me is how many bytes have been allocated on the stack.

But, compiling and executing the program does not result in skipping the x=1 command.

So, I'm not asking anyone to tell me what the answer is (believe it or not). in terms of what the right number is. Rather, I'm hoping that someone can point me in the right direction so I can understand the stack layout on the machine.

What exactly are you doing to change the return address? How are you actually changing the stack? The function doesn't return to the address in your ret variable, it returns to the return value that's placed on the stack.

Also, did you keep in mind that the function arguments are also placed on the stack? The return address is placed between the saved frame pointer (or local variables) and function arguments.

Hope this helps.

ZF

Last edited by zeroflaw on Wed Feb 24, 2010 10:59 am, edited 1 time in total.

The only thing I can think of at this point is I need to add another 4 bytes to get it past eip. Is that what you mean? Because I think the 7 is correct, because that's how many bytes I need to get past the 'x=1' statement.

I've been messing around with this for a while, and I'm guessing it also has something to do with alignment. I'm not 100% sure of this, and I will look into it. 7 seems correct, but maybe the layout of your stack is different. I compiled it with Visual C++ and I need to add 10 for it to work. I feel stupid for providing you with the wrong information. I assumed the memory layout would be the same.

Edit: Apparently it is about the compiler and alignment. I also found this article which explains it.

I found the solution, when I decided to debug the whole thing on Ubuntu. If you inspect the stack layout, you will see the compiler put some extra space. The article describes this as "slack".

Run GDB, set a breakpoint at buffer1. And Inspect the stack memory for buffer1 with the command "x/8 buffer1", you will actually see the return address and some slack space. I disassembled main to be sure that it's the right address.

You can see buffer1 starts at address 0xbffff7e0 and the return address is at 0xbffff7fc. 0xbffff7fc - bffff7e0 = 28. The correct value in this case is 28!

I guess it's important to keep in mind what the compiler does. Also not every stack uses a saved frame pointer! So it's important to always dive into the assembly instructions and inspect memory carefully.