Metasploit vs ANI

[nicolas.ruff at gmail.com (Nicolas RUFF)]

To HDM and Rhys: thanks for your explanations on the style sheet trick -
I missed this one. There *is* a second connection to get the ANI file.

However, I still feel like there is a bug somewhere. My victim is Vista
32-bit English. I attached Olly to IEXPLORE and an access violation is
triggered in the following block (which is clearly a GetEIP):

02C80EF3   EB 0F                 JMP SHORT 02C80F04
02C80EF5   68 BC040000           PUSH 4BC
02C80EFA   59                    POP ECX
02C80EFB   5E                    POP ESI
02C80EFC   29CC                  SUB ESP,ECX
02C80EFE   89E7                  MOV EDI,ESP
02C80F00   F3:A4                 REP MOVS BYTE PTR ES:[EDI],BYTE PTR
DS:[ESI]
02C80F02   FFE4                  JMP ESP
02C80F04                         CALL 02C80EF5

This memory block belongs to:
\Device\HarddiskVolume1\Users\[...]\Temporary Internet
Files\Low\Content.IE5\BUURI5IQ\hMNjttkPdyba3xhJwbZa9FrbHegyoRkUeMVg74rfMvIceIwheWHyaB7zWJNzWKe5VoXHAAU47[1].zip

*However*, EIP value is 02C80EF4, so the sequence of bytes is
interpreted as PUNPCKHBW instruction (nice one :). If I manually set EIP
to 02C80EF3, exploit works fine.

There is some kind of "one-by-one" in the jump address - looks like you
0xCC'ed something :)


> Wireshark automatically decompresses any standard Content-Encoding or
> Transport-Encoding on HTTP traffic, so you are viewing the page as the
> browser rendering engine would later see it.

Indeed, but:
1/ Wireshark is expected to display both compressed and uncompressed
streams in different tabs, if I remember well.
2/ Automatic decoding will occur only if appropriate header is found,
which is not the case.

But this is not the point, since nothing is gzip'ed here ;)

Regards,
- Nicolas RUFF