Re: [Semi OT] Auto return address / padding discovery - is it possible?

[wullie millen <wullie21 () googlemail com>]

On Sat, Nov 21, 2009 at 9:41 PM, HD Moore <hdm () metasploit com> wrote:

> On Sat, 2009-11-21 at 15:48 +0200, Konrads Smelkovs wrote:
> > Once in a while I stumble across a vulnerable system for which I don't
> > have ret address. The official solution is then to obtain the same
> > version of OS and software, load debugger and discover the new
> > address. I wonder how difficult would it be to use some brute-forcing
> > and try to discover the return address. Taking a step further, if
> > during testing of a, say, appliance one would discover a likely
> > stack/heap overflow, to try to guess the padding?
>
> Unless its in a narrow class of bugs or you can leak addresses, this
> isn't an effective way to go. Theoretically you can try to exploit a
> windows SEH using a system like:
>
>
> [PAD][EB 06 XX XX][RET][CODE]
>
> Pick a ret that is within an OS/APP DLL without /SafeSEH, then increase
> padding until you get a shell. Even this simplified example doesn't work
> well in the wild though - there are often bad characters that transform
> or truncate the input or otherwise break this method. The only well
> documented "blind" method I have seen is:
>
> http://www.securityfocus.com/infocus/1819
>
>
> Keep in mind that getting the system DLLs/EXEs for any language of
> Windows is simple - just download the SP installer for that language,
> decompress the file with cabextract (or another cab archiver), then
> decompress the individual compressed files the same way.
>
> -HD

Thanks for the info HD this will come in very handy.

-will

> _______________________________________________
> https://mail.metasploit.com/mailman/listinfo/framework
_______________________________________________
https://mail.metasploit.com/mailman/listinfo/framework