FW: SDK Questions

[bazarova at anz.com (Bazarov, Alexey)]

Hello,
 
Could you help me guys ? The last week I spent playing with Metasploit. It is a great tool and I found a SDK example 
very interesting , but some moments are difficult to me to understand. My working environment is RedHat 9.0 Linux 
installed on VMware Workstation 4.0. 
 
The main problem arises in the second stage when we try to exploit vuln and bind shell. As I understood the buggy buf 
[64] rewrites the return point of function main () , right ? Following your steps I found that in my system the offset 
is 76 as you wrote  , sure it must be 76 because buf[] is the first variable we pushed in stack after function prelude 
and gives us 64 plus stored ret, ebp, etc.
 
Well, gdb showed me that esp was 0xBFFF EA70. I changed the corresponded field and executed exploit. Nothing. Again. 
Nothing. I am not a linux guru and actually it is a first time when I meet with assembler stuff , but I was very 
currios to understand how it worked so I done some additional checks to see entire picture.  Below I placed the diagram 
of my research.
 
Stack at the initial moment 
____
|___| <==== RET ADDRESS FOR FUNCTION MAIN ()
____
|___| <==== EBP POINTS AT  0xBFFF F758
____           |
|___|            68 bytes [ 64 bytes of buf + 4 bytes of prelude(saved ESP) ? ]
____           |     
|___|           |
____           | 
|___|  <=== ESP POINTS AT  0xBFFF F6E0 , OUR BUFFER STARTS HERE
 
 
Stack after exploit
____
|___| <=== SPLOIT CODE STARTS HERE
____
|___| <=== SOME NOPs HERE
____
|___|
____
|___| <=== WE PLACED VALUE 0xBFFF EA70 HERE REPLACING RET 
____
|___| <=== 0xBFFF F758 
____          |
|___|          68 bytes filled with 'A'
____          |     
|___|          |
____          | 
|___|  <=== OUR BUFFER STARTS HERE AT  0xBFFF F6E0
____
|___|
____
|___| <=== EIP POINTS HERE 0xBFFF EA70 AFTER READING RET FROM STACK
 
 
As you can see exploit wont work untill the address provided by us falls in the range where NOPs pad is located. Anyway 
we have to guess this address that makes very hard to exploit this vuln because we have only one shoot.
 
Where am I wrong ? 
 
Thank you
 
Alex
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.metasploit.com/pipermail/framework/attachments/20040811/e09978cf/attachment.htm>