29a-7.013

从29A上收集的病毒源码

exploiting winrar 3.10

last friday(24/1), while looking in bugtraq, i found the enclosed advisorie
(/doc/bugtraq.txt). quickly, my mind started to see the possibilities of a
exploit over this vulnerability. if it worked as i would expect, sending a
email with a attached .rar was almost like a autorun: winrar its popular, and
the vulnerable version is widely used(i was using); and, as its one of the
first vulnerabilities in archivers to pop in last times, users where not
attent to the dangers to double-click these files, to inspect their contents.

i first started by hand-constructing a bugged .rar. altought the format was
very know, this job taked a time: i had to build a setup program to insert
the right crc32 values in the right places.

as was in advisorie, i just had to put 260 chars after the dot, in filename,
to trigger the exploit. at crash time, 256 after the dot, its the place to put
your new EIP, and, in the dword before it, a value that goes inside EBX(who
care, anyway). at crash time, several places in stack contained addresses
for our code. there was pointers to the content after the dot, and other to
the start of filename. perfect.

better yet, several registers where usable to reach these addresses: EBP, EDI
and, of course, ESP. it dont take too much time: in a couple of minutes, i
found a JMP [EDI-8], at 0x0047b936, that looked perfect! but not... winrar
translate high chars(>128), to other ones, and the address was crippled. note
that i could use 0 as highest byte of my address: it was the last char of my
buffer, anyway :)

well, so, i did more search. soon a JMP [EBP+18h], in a valid address,
appeared, as in a dream: 0x0048671a. jusr recompiled, and it work perfect. my
"A", that i used to fill the buffer, where running as a row of INC ECX. so,
now to the shellcode...

api usage, in w32 exploits, always cause troubles. but not for winrar: it
imported almost all apis we need, and some more. with a tool i coded for such
occasions(/ut/list_iat), i dumped the import list. the only api we need,
MessageBoxA(), was there.

soon, the high char problem appeared again. high chars where translated to
something else. but i notice a thing: we had a great variation. thus, by
using 0xde, instead of oxcc(int 3), after translation, i had a breakpoint in
the exact place.

faced with this problem, i did the following table(/doc/opcode.bin):

       00 01 02 03   04 05 06 07   08 09 0A 0B   0C 0D 0E 0F

00000  00 00 00 00