Question

I copy this code from a book. In every comment I put a number and then ask you question(1,2,3,4) related to lines of code commented by that number. Hope its ok.

1) ESP points to these buffer values. WHY dont we see a 0x41 for ´A´ over here ????

2) ESP points to flag variable memory that must contain 31337 which is 0x7a69 in hex. WHY DOES IT INSTEAD CONTAIN THIS NUMBER 0xbffff89c ???

3) Points to previous stack frame pointer, which is this case contains a correct address.

4) Return address. Also correct.

5) Arguments. Also correct values.

So what happens in 1) and 2)? Is it padding?

Thank u very much.

void test_function(int a, int b, int c, int d) {
  int flag;
  char buffer[10];
  flag = 31337;
  buffer[0] = 'A';
}

int main() {
  test_function(1, 2, 3, 4);
}


GDB debug session
Breakpoint 2, test_function (a=1, b=2, c=3, d=4) at stack_example.c:5
5 flag = 31337;
(gdb) i r esp ebp eip
esp 0xbffff7c0 0xbffff7c0
ebp 0xbffff7e8 0xbffff7e8
eip 0x804834a 0x804834a <test_function+6>
(gdb) disass test_function
Dump of assembler code for function test_function:
0x08048344 <test_function+0>: push ebp
0x08048345 <test_function+1>: mov ebp,esp
0x08048347 <test_function+3>: sub esp,0x28
0x0804834a <test_function+6>: mov DWORD PTR [ebp-12],0x7a69
0x08048351 <test_function+13>: mov BYTE PTR [ebp-40],0x41
0x08048355 <test_function+17>: leave
0x08048356 <test_function+18>: ret
End of assembler dump.
(gdb) print $ebp-12
$1 = (void *) 0xbffff7dc
(gdb) print $ebp-40
$2 = (void *) 0xbffff7c0
  (gdb) x/16xw $esp  
    0xbffff7c0: 0x00000000 0x08049548 0xbffff7d8 0x08048249  // 1
    0xbffff7d0: 0xb7f9f729 0xb7fd6ff4 0xbffff808 0x080483b9  // 1 
    0xbffff7e0: 0xb7fd6ff4                                   // 1
    0xbffff89c                                               // 2
    0xbffff808                                               // 3
    0x0804838b                                               // 4
    0xbffff7f0:                                              // 4
    0x00000001 0x00000002 0x00000003 0x00000004              // 5




reader@hacking:~/booksrc $ gcc -g stack_example.c
reader@hacking:~/booksrc $ gdb -q ./a.out
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) disass main
Dump of assembler code for function main():
0x08048357 <main+0>: push ebp
0x08048358 <main+1>: mov ebp,esp
0x0804835a <main+3>: sub esp,0x18
0x0804835d <main+6>: and esp,0xfffffff0
0x08048360 <main+9>: mov eax,0x0
0x08048365 <main+14>: sub esp,eax
0x08048367 <main+16>: mov DWORD PTR [esp+12],0x4
0x0804836f <main+24>: mov DWORD PTR [esp+8],0x3
0x08048377 <main+32>: mov DWORD PTR [esp+4],0x2
0x0804837f <main+40>: mov DWORD PTR [esp],0x1
0x08048386 <main+47>: call 0x8048344 <test_function>
0x0804838b <main+52>: leave
0x0804838c <main+53>: ret
End of assembler dump
(gdb) disass test_function()
Dump of assembler code for function test_function:
0x08048344 <test_function+0>: push ebp
0x08048345 <test_function+1>: mov ebp,esp
0x08048347 <test_function+3>: sub esp,0x28
0x0804834a <test_function+6>: mov DWORD PTR [ebp-12],0x7a69
0x08048351 <test_function+13>: mov BYTE PTR [ebp-40],0x41
0x08048355 <test_function+17>: leave
0x08048356 <test_function+18>: ret
End of assembler dump
(gdb)

Answer 1

'A' and 31337 are literals. They have no reason to be placed on the stack.

It would be more interesting for you if you printed out a disassembly of that code block to see exactly what the compiler is emitting. Then you can cross-check with what your stack contains at runtime.

Given that your function has no side-effects, it could be optimized to a no-op.

Here’s what I get with your code in an environment I’m more familiar with:

Breakpoint 1, test_function (a=1, b=2, c=3, d=4) at t.c:4
4     flag = 31337;
(gdb) disass test_function
Dump of assembler code for function test_function:
   0x080483a4 <+0>: push   %ebp
   0x080483a5 <+1>: mov    %esp,%ebp
   0x080483a7 <+3>: sub    $0x10,%esp
=> 0x080483aa <+6>: movl   $0x7a69,-0x4(%ebp)
   0x080483b1 <+13>:    movb   $0x41,-0xe(%ebp)
   0x080483b5 <+17>:    leave  
   0x080483b6 <+18>:    ret    
End of assembler dump.
(gdb) display $ebp
2: $ebp = (void *) 0xffffcd70
(gdb) display $esp
3: $esp = (void *) 0xffffcd60
(gdb) x/16xw $esp
0xffffcd60: 0xf7e7dcdd  0xf7fa7324  0xf7fa6ff4  0x00000000
0xffffcd70: 0xffffcd88  0x080483e1  0x00000001  0x00000002
0xffffcd80: 0x00000003  0x00000004  0xffffcdf8  0xf7e66cc6
0xffffcd90: 0x00000001  0xffffce24  0xffffce2c  0x00000001

Difference with your case, except for the ASM syntax, is that my compiler reserved less slack on the stack, but that’s about it.

So, as in your case, the literals end up in the instruction stream, not on the stack. The stack address and contents (interpreted as 32bit ints, careful with endianness) of the locals:

(gdb)  x/1xw $ebp-4
0xffffcd6c: 0x00000000
(gdb)  x/1xw $ebp-0xe
0xffffcd62: 0x7324f7e7

Now lets assign to flag:

(gdb) n
5     buffer[0] = 'A';
(gdb) x/8xw $esp
0xffffcd60: 0xf7e7dcdd  0xf7fa7324  0xf7fa6ff4  0x00007a69
0xffffcd70: 0xffffcd88  0x080483e1  0x00000001  0x00000002
(gdb)  x/1xw $ebp-4
0xffffcd6c: 0x00007a69
(gdb)  x/1xw $ebp-0xe
0xffffcd62: 0x7324f7e7

All good, the right stack slot was updated ($ebp-4 last 32bit slot in line 1 of the x/8xw).

And lets set the first item of buffer:

(gdb) n
6   }
(gdb)  x/4x $ebp-0xe
0xffffcd62: 0x41    0xf7    0x24    0x73
(gdb) x/8xw $esp
0xffffcd60: 0xf741dcdd  0xf7fa7324  0xf7fa6ff4  0x00007a69
0xffffcd70: 0xffffcd88  0x080483e1  0x00000001  0x00000002
(gdb)  x/1xw $ebp-4
0xffffcd6c: 0x00007a69
(gdb)  x/1xw $ebp-0xe
0xffffcd62: 0x7324f741

All good again. The endianness makes things look a bit strange when viewed as 32bit ints, but it looks fine if you look at it byte by byte.