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