2

I am trying to understand the following C program and the layout of the stack. The ultimate goal is to understand the buffer overflow exploit.

#include <unistd.h>

void Test()
{
   char buff[4];
   printf("Some input: ");
   gets(buff);
   puts(buff);
}

int main(int argc, char *argv[ ])
{
   Test();
   return 0;
}

I used -g -fno-stack-protector -O0 to compile the program.

In gdb when I see the assembly of the Test function it looks like this

(gdb) disass Test
Dump of assembler code for function Test:
   0x0804847d <+0>: push   %ebp
   0x0804847e <+1>: mov    %esp,%ebp
   **0x08048480 <+3>:   sub    $0x28,%esp**
=> 0x08048483 <+6>: movl   $0x8048550,(%esp)
   0x0804848a <+13>:    call   0x8048330 <printf@plt>
   0x0804848f <+18>:    lea    -0xc(%ebp),%eax
   0x08048492 <+21>:    mov    %eax,(%esp)
   0x08048495 <+24>:    call   0x8048340 <gets@plt>
   0x0804849a <+29>:    lea    -0xc(%ebp),%eax
   0x0804849d <+32>:    mov    %eax,(%esp)
   0x080484a0 <+35>:    call   0x8048350 <puts@plt>
   0x080484a5 <+40>:    leave  
   0x080484a6 <+41>:    ret    
End of assembler dump.

I noticed that in assembly the compiler has reserved around 40 bytes of data. This is based on the **0x08048480 <+3>: sub $0x28,%esp** statement above.

Question: Since the buffer allocated is only 4 byte why is the compiler reserving 40 bytes? What are the other bytes for?

PS:

Please notice that I am disabling all optimizations in compiler and using -fno-stack-protector as an argument. Also the Test function above has no arguments.

gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04)

CIsForCookies
  • 12,097
  • 11
  • 59
  • 124
David
  • 4,634
  • 7
  • 35
  • 42
  • 2
    Note that it doesn't reserve 28 bytes, but 0x28 (40) bytes. – Some programmer dude Jun 05 '17 at 07:29
  • @Someprogrammerdude updated the quesiton – David Jun 05 '17 at 07:31
  • @IvanIvanov Do you mean in this case it reserve 40 byte just to align 4 byte of data? In that case 8 byte is enough... – David Jun 05 '17 at 07:32
  • 2
    Compile with `gcc -fverbose-asm -S -g -fno-stack-protector -O1 yoursource.c` and look (with an editor) into the generated `yoursource.s` assembler file – Basile Starynkevitch Jun 05 '17 at 07:33
  • 1
    Because why not? In debug it does reserve stack space for almost everything what has been emerging in any compilation phase, then in the final code some of the reservations turn out to be premature, and they are not used by the code. But it doesn't hurt any thing, and optimizing it would slow down debug builds, so it is done only with more aggressive optimizations enabled. Asking why compiler does something in debug code is quite pointless, unless you are ready to dive into the compiler inner mechanics, it's simply following fastest/simplest path to churn out working code. – Ped7g Jun 05 '17 at 07:42
  • 4
    [Stack allocation, padding, and alignment](https://stackoverflow.com/a/1061942/2498790) – Alex Jun 05 '17 at 08:09
  • 1
    Learning to "exploit" debug (unoptimized) code is a pointless waste of time. Real applications are not compiled this way. – Cody Gray - on strike Jun 05 '17 at 11:15
  • 1
    Possible duplicate of [Stack allocation, padding, and alignment](https://stackoverflow.com/questions/1061818/stack-allocation-padding-and-alignment) – Cody Gray - on strike Jun 05 '17 at 11:15

0 Answers0