Metasploit Framework

after some debugging:

the seh frame seems to be well built. vulnerable code jumps to hard-coded pop/pop/ret but the encoded payload crashes in a xor [esi], esi because esi = ffffffff.

if I debug apache, let the seh frame do its thing, let the pop/pop/ret do its thing, and then I manually replace in memory the alphanum encoded payload with the raw/not encoded version of the payload, everything works as expected.

I did all testing with payloads windows/shell/bind_tcp and windows/shell_bind_tcp.

it seems to be a problem of the alpahum encoder.

I modified apache_modjk_overflow.rb to use my custom shellcode (not alphanum but without 00s etc) instead of the shelcode generated my metasploit and the exploit works great.

So, although I'm not familiar with the inner workings of the alphanum encoder, I think the problem is in the alphanum encoder.

Hernano reports that this exploit contains the shellcode he used:

http://downloads.securityfocus.com/vulnerabilities/exploits/22791-unohope.py

I reproduced the lack of working, but its not clear why. It does look like it may be the alpha encoder. Also, this exploit says to use the encoder "AlphanumUpper" but it actually ends up being mixed case... odd.

In my test (Apache 1.3.37 with mod_jk/1.2.20 for 1.3.37), the set of bad characters was different from what the module had.

I removed \x2b and \x3a. I added \x3b. Works for me now.. Not sure how it will work against various other versions.. Perhaps 2b and 3a are bad, but only in some installs.. Hernan?