No room for shellcode

[allendb760 at googlemail.com (DB Allen)]

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.

I even went back to the old WarFTP1.65 server and ran the shellcode through
the PASS and USER bof's to see if the badchar was specific to my FTP server
or to the FTP protocol in general- had exactly the same issues with that, as
in that didn't like 0x0D opcode either and using alphanum shellcode results
in the bof not occurring in the first place, which was pretty weird.

Will keep plugging away at it but reckon I'll switch trades to being a
bloody florist or something at this rate - too damn stressful!

Cheers for the replies everyone.

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

> On Sun, 03 May 2009 13:19:44 -0500, DB Allen <allendb760 at googlemail.com>
> wrote:
>
> > Out of interest, has anyone ever seen an overflow fail when changing
> > shellcode. As in the buffer overflow doesn't even occur..
> > I thought there may be a bad character in the shellcode, which was why it
> > was not landing up in the stack properly, so generated new shellcode set
> > to exclude the byte I thought could be causing problems, and the overflow
> > didn't even occur, was sending exactly the same data for the initial
> >  buffer, just different shellcode... It's irritated the hell outta me!
>
> This happens pretty often, its a pain to work through, but its usually
> caused by either a badchar being missed, or the combination of two
> characters triggering some processing issue in the application. With FTP
> servers, the 0xFF byte is often treated as an escape, so you have to double
> each 0xFF so that it decodes properly. What protocol is this exploit using?
>
> -HD
>
>
>
> _______________________________________________
> https://mail.metasploit.com/mailman/listinfo/framework
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.metasploit.com/pipermail/framework/attachments/20090503/ac74acb9/attachment.htm>