Re: Is the memory map of a process different when executed in GDB?



I'm beggining studying deeply exploits. Now I have a problem. I'm
trying a return-to-libc exploit but I get a segmentation fault when
executed in the terminal and I get the code correctly executed when I
run it inside GDB. Does GDB alter the memory map of a process when
executed inside it? In which way? Where I can read info about this?

It's hard to say exactly what's going on without seeing the example code you're trying to exploit. But let me give you some basic thoughts..

I assume you are putting the address of the string "/bin/sh" somewhere in the environment and then attempting a basic ret-to-libc with a call to system(). So your buffer probably looks something like this:

[ x bytes of junk to overflow buffer ][ address of system() ][ address of exit() ][ address of "/bin/sh" ]

The environment a program receives when being invoked by gdb is a bit different than that which it receives when being invoked from the shell. As an example, try compiling and running this simple program which shows the address of an environment variable:

#include <stdlib.h>
main(int argc, char **argv){ printf("%s :: 0x%08x\n", argv[1], getenv(argv[1])) ; }

Run that both from a shell and from gdb and you will see the addresses are different. Don't hold me to this, but I believe on Linux you will find that your target environment variable address will be 0x20 bytes lower when called from gdb than from a shell. But you should do your own experimenting to see how it works.

Remember also that the length of your program name (argv[0]) also affects the memory layout. So if you compile the above code as './ getenv' and your program name is './vulnerableproggy' then the address will be different. For every character longer the vulnerable program is, the memory address you are examining will be two bytes *lower* (on Linux IA-32, at least). This is because the name of the program, as part of argv, is passed to the program. This difference also differs across platforms.

Also try manually looking through the process memory space in gdb so you can see what kind of items are in there. If the address returned by the above call to getenv() is 0xbffffd10, for example, try looking at memory as strings starting at 0xbffff900 in gdb using

x/20s 0xbffff900

Hope this helps.
-c