M.V.I. (Mudular Virus Interface)
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  by Bumblebee/29a


  Overview
  ~~~~~~~~
 This is a 'do nothing' article. Only an exposition of ideas about a  new
way of infection. Think just for a moment you can infect all binary files
in your HDD. This is posible? i can answer yes. Users will experiment new
sesations when a MID or MP3 or ... infected file shows its payload.
 Have fun with this '10-minutes' article.


  The sub-system approach
  ~~~~~~~~~~~~~~~~~~~~~~~
 The idea is to code a  'plug-in' that complements  win32 to  support our
modules. What hapens when user execs a program? If we sum up we get:

        1. system verifies it's an executable
        2. gets executable header and:
                - put it into memory
                - put imports
                - ...
        3. gives the control to

 So the Mudular Virus Interface (aka MVI) i s a group of modules plus the
plug-in  called  Mother.  The  Mother  patches  kernel32  and  hooks  all
CreateFileA calls. Then reads last dword searching the sign of a  Modular
Virus (aka MV). If found, this sign has  information to allow  the Mother
to put the MV in memory,  give to it the  APIs that  needs and installing
the hooks the MV wants.

 Take this a example:

        1. Mother arrives to the system
        2. Infects kernel32
        3. Monitors CreateFileA
        4. if VM found goto 5 else goto 3
        5. install VM into memory
        6. create a thread for VM and goto 3

 It's ovious that mother needs its own way  for spread.  But we are  olny
with theory. We'll look this topic later.


  VM format
  ~~~~~~~~~
offs   Size    Description

 00     dw      'VM' this is the VM sign
 02     dw      size of the module (65536 is enough for a module!)
 04     dd      identifier
 08     dw      offset of entry point from begin of module (BOM)
 0a     db      number of imports (n)

  Xn   /dd      CRC of API name to import
       \dw      offset to store its addr (dd) from BOM

        db      number of hooks (m)

  Xm   /dd      CRC of API name to hook
       \dw      offset of hooker function from BOM

        [ here goes the code of the VM ]

        dw      size of the module (65536 is enough for a module!)
        dw      'VM' this is the VM sign


 The mother opens a S3M file.  Then reads the last dword and checks  it's
'VM' the  last word.  Then gets the first word and moves the file pointer
this amount  from end of file.  Then reads the entire module.  Checks the
'VM' is there too and if the identifier is new (not into memory yet) then
allocs  some  writable/readable/executable memory and  copies  the module
there.  Now gets the  number of imports  and does a  loop to store in the
module body the  addresses of  the imported API.  With the hooks gets the
addrs of each hook in the new position into memory and patches the kernel
with this information. Notice that if the VM wants to hook CreateProcessA
it needs  to import  this API  and hook it.  This is  'cause  Mother puts
the address of the hooker  into the kernel32.  The VM  needs  the address
of the  API  before the  hook (this is provided  by the  Mother  with the
imports) to return the control there when it ends its work.
 Another  detail is  all the  VM needs  to import  ExitThread because the
Mother creates a thread to allow the VM to work as run-time too.

 Let me show some ways of work:

             type      imports     hooks

            run-time      X
            resident      X          X

 A dummy VM needs at least one import: ExitThread.

 The following can be an exaple of VM:

;--------------------------------------------------------------------------
label   byte    begin

header  dw      'VM'
        dw      end-begin
id      dd      'VMT1'
ep      dw      offset entry
        db      2

        dw      CRC_EXITTHREAD
        dw      offset _ExitThread

        dw      CRC_CreateProcessA
        dw      offset _CreateProcessA

        db      1

        dw      CRC_CREATEPROCESSA
        dw      offset MyCreateProcessA

entry:
        call    delta
delta:
        pop     ebp
        sub     ebp,offset delta

        call    dword ptr [_ExitThread+ebp]


MyCreateProcessA:
        call    delta2
delta2:
        pop     ebp
        sub     ebp,offset delta2

        jmp     dword ptr [_CreateProcessA+ebp]

_ExitThread     dw      0
_CreateProcessA dw      0

        dw      end-begin
        dw      'VM'
labe    byte    end
;--------------------------------------------------------------------------

 I'm  not going  to explain  how to compile  this pieze of code,  but the
reader  can see the  VM can be small,  very small.  This is due to Mother
provides some functions that a normal virus must to in win32:  get kernel
addr, scan APIs, ...

 This VM hooks  CreateProcessA, but does  anything. Only give  control to
the next hooker in chain.

 All the Mother implements  it's not  needed in the VM. Mom can implement
SEH before giving control to the hooker of the MV.This will make all more
stable. And this is only an example.


  Real implementation of Mother
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 The MVI can be a reality.  Only is needed  the implementation of Mother.
This can be as complex as stable we want the interface.

 But all this theory is as good  as spreaded is the mother.  The only one
point  for is that if MVI works,  may be  the avers  need to update their
damn scanners.


                                                        The way of the bee