Framework SDK 2.5 doubts

[grutz at jingojango.net (Kurt Grutzmacher)]

Check for the following sysctl setting, it was added to the linux  
kernel in 2.6.12:

$ sysctl kernel.randomize_va_space
kernel.randomize_va_space = 1

Set it to 0 and recalculate your offsets. It may or may not be your  
particular problem but when starting out it's nice have easily  
guessable addresses.

On Apr 7, 2006, at 2:32 AM, curious one wrote:

> EIP is being over written completely. The reason exploit is borking  
> is because it is returning to a string of 'A' because I could not  
> locate the nop sled. If we  look at the exploit providede in  
> vuln1_2.pm we can see that a ries of 'A's shall prceed the return  
> addtress i.e.
>
> # You call GetLocal for Advanced options, unlike calling GetVar above
>   my $evil = 'A' x $self->GetLocal('PreRetLength');
>   $evil .= pack('V', $ret) x int($self->GetLocal('RetLength') / 4);
>   $evil .= $shellcode;
>
> Though we are specifying a minimum of 16 nops i.e.
>  'MinNops'   => 16, # This keeps brute forcing sane
>
> I can not locate this sled anywhere near the return address string.  
> Lookimg at the gdb dump I can locate
> 0xbf87ea30:     0x41414141      0x41414141      0x41414141       
> 0x41414141
> 0xbf87ea40:     0x41414141      0x41414141      0x41414141       
> 0x41414141
> 0xbf87ea50:     0x41414141      0x41414141      0x41414141       
> 0x41414141
> 0xbf87ea60:     0x41414141      0x41414141      0x41414141       
> 0x41414141
> 0xbf87ea70:     0x41414141      0xbfb17b30      0xbfb17b30       
> 0xbfb17b30 <----------------------return address
> 0xbf87ea80:     0xbfb17b30      0xbfb17b30      0xbfb17b30       
> 0xbfb17b30
> 0xbf87ea90:     0xbfb17b30      0x42414246      0x90924191       
> 0x49464ef8
>
>
> So, thats the part of the problem.I can not see my shellcode.there  
> is a a sled of 'A's then the return address.. where did the  
> sheccoded and minnops 16 go?
>
> I apologize for sounding like a n00b, but I am one :-)
>
> Cheers
>
>
> On 4/7/06, Sahir Hidayatullah < sahirh at mielesecurity.com> wrote:
> First check whether you're overwriting the saved EIP with the right  
> number of bytes. You can figure out the exact length of your buffer  
> using PatternCreate() in conjunction with patternoffset.pl from the  
> SDK directory. If you're sure you're overwriting EIP completely,  
> look at the address that you're returning to and ensure that your  
> nops lie there. From what I understood, you picked an address among  
> a series of 'A's, if you return into a string of 'A's, they will  
> not be valid instructions and your exploit will bork.
>
>
> --S.
>
>
>
> From: curious one [mailto:0x0804 at gmail.com]
> Sent: Thursday, April 06, 2006 5:37 PM
> To: framework at metasploit.com
> Subject: [framework] Framework SDK 2.5 doubts
>
>
> Hi,
>
> I am a n00b here. I was trying to learn remote exploitation using  
> metasploit's documentation. I used the sdk and the prog vuln1.c as  
> target. I followed the first part where we find the offsets and  
> locate the return address accordingly. My problem is when I am  
> trying it with vuln1_2.pm exploit module my return addres is never  
> right
>
> Everytime I try a return address i get this :
>
> Program received signal SIGSEGV, Segmentation fault.
> 0xbfb247cf in ?? ()
>
> I do a x/200x $esp-256 in gdb and I can see a 'A' sled. i choose an  
> address in that address and run teh exploit again still I end up  
> with just a dos and my payload is not getting through at all. Any  
> help on that???
>
> I am using Slax (backtrack if you please), gcc 3.3.5, kernel  
> 2.6.12.2 .
>
> All help will be appriciated.
>
> Cheers

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.metasploit.com/pipermail/framework/attachments/20060407/661561dc/attachment.htm>