Difference between gdb addresses and “real” addresses?

Question

If I run a C/C++ program in gdb (after compiling with the -g flag) and I examine the addresses of certain variables, arguments...etc, and then I run it outside of gdb (using ./) will these addresses be the same as the ones I saw in gdb? If they're different are they usually similar or will they be drastically different?

I ask this because I have a buffer overflow program that works perfectly in gdb (with and without breakpoints), however when I try to run it outside of gdb it doesn't work.

Answer 1

I examine the addresses of certain variables, arguments...etc, and then I run it outside of gdb (using ./) will these addresses be the same as the ones I saw in gdb

It depends.

1. Global variables defined in the main executable will stay at the same address (unless the executable is built with -fpie and linked with -pie flags.
2. Global variables defined in other shared libraries may have drastically different addresses due to ASLR.
3. Local variables and parameters may move around by several K-bytes due to ASLR.
4. Heap-allocated variables may also drastically move due to ASLR, or if your program is multi-threaded.

Note that GDB on Linux by default disables ASLR, to make debugging easier. You can re-enable ASLR under GDB with set disable-randomization off. That may allow you to reproduce the problem under GDB.

I have a buffer overflow

Also note, that tools like Valgrind and Address Sanitizer are often significantly more effective for finding buffer overflows than running under GDB. Address Sanitizer in particular is great in that it finds buffer overflows in globals and on stack (Valgrind doesn't).

Answer 2

You should never ever assume that a certain code or vars will be located at a fixed place.

This was true in the past in the most OS but it is a security hole. malicious software uses this to inflect programs. OS will tend to scramble addresses to increase security.

Answer 3

Compiling with the -g flag increases the code size as it bungs into the executable extra information.

As to your buffer problem it would help to publish a snippet of code where things are going awry.