No room for shellcode

[patrick at aushack.com (Patrick Webster)]

It depends on how the badchar bytes are used. Some software will completely
reject them, some will modify them, some will change the behaviour of the
software or call an exception etc.

I'm sure many people have a better way, but I tend to use something like:

badchar = (0x01 .. 0xff).map { |b| [b].pack('C') }
sock.put(badchar)

.. set a breakpoint or trigger the exception and check the process memory to
see if anything has changed.

Pretty much everything rejects nulls as a character array terminator (\x00).
Any text-based protocols will reject carriage returns and line feeds
(\x0a\x0d).
Furthermore space charaters (\x20) for software which is expecting only one
argument to a command.

It is a good idea to look at the RFC of the protocol. Something like FTP is
likely to reject @, when the FTP server supports proxying of servers e.g.
user at ftp.microsoft.com.

Likewise HTTP will have issues with forward & backslash (\x2f\x5c), percent
(\x25 - used for spaces in URLs e.g. metasploit%20framework%203), equal
signs (\x3d), question marks (\x3f) and ampersand (\x26) for arguments in
requests e.g. login.php?username=bill&pass=gates.

Anyway you get the idea....

-Patrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.metasploit.com/pipermail/framework/attachments/20090505/2428c042/attachment.htm>