thank you for answering me.
Sorry for the inaccuracy using when talking about overwriting registry, i know they ‘re not on the stack but talk as they where
Here is a sketch of the stack after the function get called:
The string should overwrite both the return address and the EBP. The return address cause the EIP (enhanced Instruction Pointer) to jump to the address stored in it that is in our case 0x41414141.
But I noticed it does not rewrite the return address or something similar.
I don’t know if it is because of the OS or the gcc but noticed this on FC4 and today I tested it o FC3 and saw the same.
The bad thing is that examples from “The art of Exploitation” & “Shellcoders’ Handbook” want work.
The good thing is that if true FC would probably be much harder to run shellcode on and so much secure
(But I would still like to have those examples work on FC4)
Later on I installed slackware 10.0 on VMware and notice that both the return address were overwritten, as it should be. So both eip and ebp contained the value 0x4141414141.
root@localhost:~# ./vulnerable "perl -e "print "A"x300';"
Segmentation fault (core dunped)
root@localhost:~# gdb vulnerable c:ore GNU gdb 6.1.1
Copyright 2004 Free Softuare Foundation, Inc.
GDB is free...
This GDB was configured as "i4B6-slackware-linujt"... Using host libthreaddb library "/lib/libthreaddb .so.l".
Core was generated by ./vulnerable AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Progran teminated with signal 11 r Segnentation fault.
Reading synbols fron /lib/libc.so.6...done.
Loaded synbols for /lib/libc.so.6
Reading synbols fron /lib/ld-linux.so.2...done.
Loaded syibols for /lib/ld-linux.so.2
#0 0x41414141 in ?? ()
(gdb) info registers eip
eip 0x41414141 0x41414141
(gdb) info registers ebp
ebp 0x41414141 0x41414141