No room for shellcode

[allendb760 at googlemail.com (DB Allen)]

Cheers Pal - used the badchar list you posted - had to add 0x40 (the @ sign)
to it and strangely 0x42 didn't seem to go down to well with if sent after
0x18 (caused a DoS). Good call about the 0xFF too - when it wasn't doubled
up it seemed to cut off the shellcode 102 bytes after where the 0xff was
located, doubled it up and it suddenly liked the shellcode - thanks for
that, doubt I would have figured that one out on my own :-/

It was a right pain in the arse to work out the badchars - I ended up using
a slightly modified Sulley to set up PyDbg on the remote host, listening on
a port - then send the shellcode one byte at a time, querying PyDBG on the
remote host to see if an exception of any kind occurred after each byte had
been sent.

Is there a less involved method commonly used to check for badchars? Or just
a case of a trail and error for each byte?

Thanks again,

DB



On Sun, May 3, 2009 at 9:35 PM, H D Moore <hdm at metasploit.com> wrote:

> On Sun, 03 May 2009 14:46:30 -0500, DB Allen <allendb760 at googlemail.com>
> wrote:
>
> It's FTP - I didn't know about 0xFF being treated as an escape , this
> > server doesn't seem to like 0x0D either for whatever reasons - I tried
> > generating new shellcode without 0xFF and 0x0D but this seemed to not cause
> > an overflow - so then tried it with PexAlphaNum encoded shellcode - all the
> > shellcode
> > seems to get copied across this time but I don't get control of EIP,
> > although an access violation still occurs further up in the stack.
>
> Try using the BadChars from an existing FTP exploit:
>
> 'BadChars' => "\x00\x7e\x2b\x26\x3d\x25\x3a\x22\x0a\x0d\x20\x2f\x5c\x2e",
>
> 0xFF may need to be doubled (in your exploit code, just use gsub to double
> it up), but more than likely not.
>
>
> 0x0a and 0x0d are the CRLF line terminators, so no surprise its an issue.
>
>
> -HD
> _______________________________________________
> https://mail.metasploit.com/mailman/listinfo/framework
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.metasploit.com/pipermail/framework/attachments/20090504/4a2082cc/attachment-0001.htm>