Explain esp-ebp in this program

Question

I have this C function:

void hello(char * src) { char buffer[64]; strcpy(buffer, src); printf("Hello %s !\n", buffer); } 

(which contains the security issue that I know of)

X86 node for it

 push ebp mov ebp,esp sub esp,0x58 

Why is it 0x58 (t. 88)? I would expect 64 + 4 + 4 + 4 (local variable buffer + argument + old ebp + return address) or something that I am missing?

Answer 1

Well, this is a crazy guess, but let him run the pole flag and see what happens.

Perhaps the compiler does not optimize the space, and this is the adjustment of word alignment to preserve shifting words for loading registers along the borders of four slots.

Look at the values, 0x58 and 8bytes -> the next border of the quadruple dictionary is 96 0x60. It is much easier to stroke ebp from the smallest (or most of all - endian ?;)) a significant part of the quad-core string in memory; advanced thinking and all that.

Edit: for sure! (What did he say...)

Answer 2

It depends a lot on your architecture and compiler flags, so it’s impossible to point out one thing and say “it should be this” here. However, I can give you some pointers that may help you.

First, consider the border of the stack. You may have heard of the -mpreferred-stack-border = X flag for GCC. If not, this basically tells your compiler to have your stack values ​​be 2 ^ X bytes each. Then your compiler will try to optimize your program so that these values ​​match the stack as closely as possible. On the other hand, a GCC modifier, such as __packed__, will cause the compiler to try to set the data on the stack as accurately as possible.

There is also a stack protector. Basically, GCC pushes dummy values ​​onto the stack, which ensures that buffer overflows can do no harm except segfaulting your program (which is not fun, but better than an attacker that controls the instruction pointer). You can easily try this: grab any latest version of GCC and let the user overflow the buffer. You will notice that the program exits with a message in the line "stack detection, termination". Try compiling your program with -fno-stack-protector, and the allocated local memory on the stack is likely to be less.

Finally, there is some insignificant information about how the cdecl calling convention works, which you are mistaken. Arguments are pushed onto the stack before the function is called, which means they are higher in memory on the stack (remember that the stack grows in memory). Here's an extremely simplified example of a function that requires 3 arguments and allocates 2 local integer variables:

 # First we push three arguments on the stack in reverse order as they # appear in C. The values don't matter here. pushl $0xc pushl $0xb pushl $0xa # A CALL instruction comes in here to get in the function. The return # address is placed on the stack. # Assume we are in the function now. This function first saves the base # pointer, then sets the base pointer to the address in the stack pointer. pushl %ebp movl %esp, %ebp # Now we can allocate our local variables. We need 8 bytes of space for # those 2 integer variables (note that this is an extremely simplified # example that doesn't consider what I just told you above). subl $0x8, %esp # Let just put 1 and 2 in those variables. movl $0x1, -4(%ebp) movl $0x2, -8(%ebp) # We're done. Put a return value in EAX, then restore the stack- and # base pointers. movl $0x0, %eax movl %ebp, %esp popl %ebp ret 

So, our stack looks something like this:

 16(%ebp) -> Argument 3 12(%ebp) -> Argument 2 8(%ebp) -> Argument 1 4(%ebp) -> Return address %ebp -> Old %ebp pushed on the stack by function -4(%ebp) -> Local variable 1 -8(%ebp) -> Local variable 2 

In other words, only local variables are in lower memory than the base pointer. Honestly, maybe there are a few more things that can affect the size of local variables on the stack, which I forgot to include, but I hope this helps you a bit. Keep hacking your program and you'll find out. :)

Answer 3

There are many reasons why the compiler reserves more space. Besides what others have said, if you are on MSVC, it is possible that you edit and continue . Without a compiler name and compilation options, I can no longer tell you