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

[HD Moore <hdm () metasploit com>]

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

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