Gdb shows a different address than in the code

Question

I am trying to implement a buffer overflow attack, and I need to know the address of my buffer, which I am trying to overflow.

The address displayed using GDB is different from the fact that I just did this in code:

Exact code:

#include<stdio.h> int main() { char buffer[20]; printf("%p\n", buffer); // 0xbffff320 return 0; } 

However, in gdb, if I do this:

 p &buffer 

I get: 0xbffff330

Why is there a difference and this will ruin my buffer overflow attack?

I have ALSR and stack protection is disabled.

Thanks.

EDIT 1: Even when I go through gdb and encounter a print line, I get 0xbffff320 as the address

EDIT 2:

Environment: The Ubuntu Linux 9 image runs in a virtual box on windows 7.

Gdb version: 6.8-debian

Compiled using GCC, for example: gcc -g -fno-stack-protector filename.c immediately execute: ./a.out address printed: 0xbffff320

Then open the following in the debugger: gdb ./a.out then type b main then run then p &buffer

Then the address is 0xbffff330

Edit 3:

This is gdb log for reproducing behavior:

$ gdb. / a.out

b main

run

p & buffer / * the address here is different from what is displayed if I run the executable * /

go through the program to the printf statement / * address here just like p & buffer, but differs from what is printed when the program starts * /

Answer 1

The question, as I understand it, is why the address of the local variable in main is different when the program starts from the shell or when it is started from gdb.

Here is an example program to show the difference:

 mp@ubuntu :~$ cat sc #include<stdio.h> int main(int argc, char **argv) { char buffer[20]; system("env"); printf("%s %p\n", argv[0], buffer); return 0; } 

We will run it in a clean environment. (I also disabled ASLR).

 mp@ubuntu :~$ env -i sh $ ./s PWD=/home/mp ./s 0xbffffe48 

 $ gdb ./s (gdb) run Starting program: /home/mp/s COLUMNS=80 PWD=/home/mp LINES=42 /home/mp/s 0xbffffe08 

Exiting the gdb print &buffer command matches the programmatic idea of ​​the address, but they are both different from when the program was run in the shell.

 (gdb) b 6 Breakpoint 1 at 0x804849c: file sc, line 6. (gdb) run Starting program: /home/mp/s COLUMNS=80 PWD=/home/mp LINES=42 Breakpoint 1, main (argc=1, argv=0xbffffed4) at sc:6 6 printf("%s %p\n", argv[0], buffer); (gdb) p &buffer $1 = (char (*)[20]) 0xbffffe08 (gdb) n /home/mp/s 0xbffffe08 8 return 0; 

There are several things that make a difference:

• gdb calls a program with an absolute path name, so the argv array is larger.
• gdb sets (or in this case adds) two environment variables. This is done in readline/shell.c:sh_set_lines_and_columns() . Thus, the environment array is larger.

To remove these two variables from the environment, you can use to disable the environment or set exec-wrapper to run env -u ... Thus, the program addresses under gdb are the same as when running in the shell (if we use the absolute path).

 $ `pwd`/s PWD=/home/mp /home/mp/s 0xbffffe28 $ gdb `pwd`/s (gdb) set exec-wrapper env -u LINES -u COLUMNS (gdb) run Starting program: /home/mp/s PWD=/home/mp /home/mp/s 0xbffffe28 

Answer 2

The object of your array on your system is stored on the stack. At the top of the stack is, among other things, a medium. When you run your program using gdb , gdb will provide a different environment (env var and their meaning) that explains the difference in addresses.

You can check the difference by running show environment in gdb and comparing the output with the set command in your shell.

Answer 3

It turned out that this is the expected behavior in older versions of GDB (mine is 6.8-debian), and if you properly construct the buffer overflow attack, you can bypass this behavior and this will not be a problem.

Answer 4

At the moment, the only reasons I can imagine are:

• You tried print &buffer after completing your program. Solution: try setting a breakpoint on main , run , next to execute printf and print &buffer .
• first you ran your program outside of gdb, and then you ran it inside gdb, but you forgot to execute the printf line with next .
• error in your gdb version
• an error in your version of gcc (gcc may lead to incorrect debugging information: see 1 and 2 )