           __________________________________________________

            P R O T E C T I N G   Y O U R   I N F E C T I O N

                                   by

                    Sepultura [Immortal Riot/Genesis]
                              <sep@ikx.org>
                            <sep@nether.net>
           __________________________________________________

                       % I N T R O D U C T I O N %
                     ____________________________

    In  IR  magazine issue #7 I presented an article named `Post Discovery
    Stratagies'. This article discussed measures that could  be  taken  to
    protect  your virus from analysis by AV researches, once it  had  been
    discovered. i.e. firstly, Pre-Discovery Stratagies (stealth) are  used
    to  reduce chances of the virus being discovered. Secondly,  once  the
    virus  _IS_  discovered,  |Post-Discovery Stratagies  (slow-polymorphy,
    anti-bait code, etc) are used to make it more difficult for the AV  to
    write  a  program that can detect the virus. This article is the  next
    stage  -  Now the virus can be detected, how can we stop them  getting
    rid of it?

    This  document  will  be divided into two sections  -  one  discussing
    preserving  file  infections,  and  one  discussing  preserving   boot
    infections.

       % P R E S E R V I N G   F I L E   I N F E C T I O N S %
      ________________________________________________________

    The  methods  of  cleaning  infected  files  generally  fit  into  two
    catagories   -   specific  and  generic.  Specific   methods   involve
    identifying the exact virus the file is infected with, and then  using
    the  information the AV program has on the virus, to  clean  it.  This
    information  is usually the length of the virus (to truncate  it  from
    the  file),  and  the offset in the virus body of the data  needed  to
    clean  the file (such as the first three bytes of a .COM file  or  the
    clean EXE header of a .EXE file). There are two methods of generically
    cleaning  a  file.  The first is storing a database of  the  important
    characteristics of a file, and restoring them if the file is  believed
    to  be  infected  (see the article `MODERN METHODS  OF  DETECTING  AND
    ERADICATING KNOWN AND UNKNOWN VIRUSES' by Dr. Dmitry Mostovoy  in  the
    AV  rip-off  section  of  IR#8'). The second involves  emmulating  the
    virus,  until  the  cleaner can find the point  where  the  virus  has
    cleaned  the host in memory, and using this to clean the file on  disk
    (see the article `HEURISTIC ANTI-VIRUS TECHNOLOGY' by Frans Veldman in
    the AV rip-off section of IR#8').

    This section will discuss methods of defeating all three methods.

                    ENCRYPT YOUR RESTORATION DATA
                  _____________________________

    As  was  stated, conventional methods use the restoration data in  the
    virus body to clean the host, so obviously we can't let them have  it.
    The  easiest  thing that you can do, is encrypt the data  (either  the
    clean  EXE header, or the first 3 bytes of the com file), and  decrypt
    it when you need to return to the host, or stealth the file. Ofcourse,
    encrypting the data with a simple 8 bit XOR and a constant key, is not
    going  to  pose much of a challenge. You might want to use the  entire
    virus  body as a key (by modifying the restoration data with the bytes
    from  the virus) or using some thing similar to a polymorphic  engine,
    to vary the encryption algorithm each infection.

                        ENCRYPT THE HOST FILE
                      _____________________

    The  next step-up, from encrypting the restoration data, is to encrypt
    the  ENTIRE  host file. As with encrypting the restoration  data,  you
    should  make  the  encryption quite complex or variable.  This  method
    could  become  quite complex with EXE files, or a full stealth  virus.
    The  virus `Midnight' by Antigen in Vlad-#5, is an example of a  virus
    that  encrypts  the entire host, using the virus body itself,  as  the
    key.

                      RANDOM DECODING ALGORITHM
                     _________________________

    The  Random  Decoding Algorithm is a trick used by the RDA  family  of
    viruses,  and is effective against both conventional cleaning  methods
    and   heuristic  cleaning  via  emmulation.  The  virus  encrypts  the
    restoration  data using a series of 16 transformations chosen  from  a
    list  of  16  operations (ADD,SUB,XOR, etc.) - i.e.  65,536  different
    encryption algorithms in total. The list of encryption operations also
    doubles  as the list of decryption operations (i.e. ADD decrypts  SUB,
    ROL  decrypts ROR, etc). After encrypting the restoration data with  1
    of the 65,536 possible encryption routines, the virus DOESN'T save the
    appropriate  decryption routine. Instead it only saves a  CRC  of  the
    original, decrypted restoration data. When it becomes time to  restore
    the  host  file,  the virus attempts to decrypt the  restoration  data
    using  the  first of the 65,536 possible encryption routines.  If  the
    decrypted code does not have the same CRC as the original, saved  CRC,
    it  tries  again with the second CRC, then the thrid, etc,  until  the
    data is succesfully decrypted. This can take a great amount of time  -
    enough  time  to  make it unviable to incorporate into a  conventional
    cleaner,  and also enough time to cause most emmulators  to  bail  out
    thinking they have entered an infinite loop or traced the program  too
    far.

                       USE ANTI-DEBUGGER CODE
                     ______________________

    Some  heuristic  cleaners - TBCLEAN for example - use INT  01h  single
    stepping to trace the infected code until the image of the program  in
    memory  appears clean. The simple thing to do is execute  a  piece  of
    code  that will take advantage of this, by causing the cleaner to bail
    out  when it traces the virus. TBCLEAN doesn't allow writing to memory
    outside  the  virus code segment, so we cant meddle with the  INT  01h
    vector  or  handler,  but  we  can take advantage  of  the  fact  that
    everytime an INT 01h is generated, 3 words are PUSH'ed onto the stack.
    The  easiest ways to thwart this is to execute code such as a  program
    terminate  if an INT 01h tracer is detected, by checking if the  stack
    below  SP has been over written, or by setting SP to 1,3, or 5,  which
    will  cause a stack overflow when the interrupt causes the 3 words  to
    be PUSH'ed.

                       STRONG POLYMORPHIC CODE
                     _______________________

    As  we  all  should  know, if the code produced  by  your  polymorphic
    generator  is strong enough to hamper encryption via X-Ray  techniques
    (as  used in Suspicious) and emmulators (as used in Dr Web) the  virus
    has to be detected via algorithmic methods. This means the AV have  to
    devise an algorithm, or set of rules, that will determine if any given
    sequence  of bytes is a decryptor produced by your engine (usually  by
    eliminating all `innocent' sequences). What you might not realise,  is
    that  if  they are detecting it algorithmically, the actual  virus  is
    never  decrypted by the scanner. By hiding the restoration data behind
    a  strong  decryptor, you make it both harder to detect and clean  the
    virus.

                      VARIABLE LENGTHED VIRUSES
                    _________________________

    Once  the  cleaner has the restoration data, and restored the affected
    areas  of  the  file, all that is left is to truncate  or  remove  the
    actual  virus body from the file. If your virus is X bytes  long,  all
    they  have  to do is seek -X bytes from the end of the infected  file,
    and  write 0 bytes (to truncate the file). If you make your  virus  if
    variable  length, such as by using polymorphism or size padding,  then
    they  will  have to figure out how many bytes to remove each infection
    if they want a precise clean.

                  % UNUSUAL INFECTION TECHNIQUES %
                ________________________________

    Another  step  that can be taken to hamper removing the  actual  virus
    body from the file is using unusual infection techniques. Most viruses
    are  appenders,  so the virus body is placed after the original  clean
    file.  This makes the virus very easy to remove. There are many  other
    forms  of infection, including overwriting appenders (where the  virus
    overwrites  the start of the file and prepends the original  start  of
    the  file  such as in H8URNMES), midfile infection (several  different
    techniques),  and  app-pre-penders (where code is added  to  both  the
    start and end of the file such as in Neither).

    The  virus  Commander Bomber places itself somewhere in the middle  of
    the file to be infected, then creates several `junk islands' in random
    spots  of  the  file. Each island ends by jumping to the next  island,
    until the virus entry point is reached. This means that the virus  can
    not  simply be truncated from the end of the file, which makes removal
    somewhat  more complex. It also means that several spots  through  out
    the  file  must be restored, not just the first few bytes of the  file
    like  most  viruses. This method is also used by One-Half  which  uses
    several methods to very effectively hamper cleaning of the virus.

       % P R E S E R V I N G   B O O T   I N F E C T I O N S %
       _______________________________________________________

    Many  of  the  most commonly reported viruses in the wild infect  boot
    sectors  or  MBR's.  Due  to  the  ease  with  which  traditional  MBR
    infections  can  be  removed.  Whats  the  used  of  a  Full  Stealth,
    Polymorphic virus, if it can simply be removed by typing `FDISK /MBR'?
    This  section  will  deal with protecting Hard drive  infections,  not
    floppies which are expendable.

                        WRITE PROTECT THE MBR
                      _____________________

    When  the virus is resident, it should abort any attempts to write  to
    the  MBR. This can be done in two ways. Firstly, you can take the more
    proffesional stealth approach, where any write attempt to the  MBR  is
    redirected to the sector containing the original clean MBR instead (if
    reads  are redirected in the same manner too, the virus will  be  full
    stealth).  The simpler approach is simply to set the Carry  Flag,  and
    return with an error code in AX, if a program attempts to write to the
    MBR.

                   ERASE THE PARTITION INFORMATION
                  _______________________________

    A  simple  MBR infector places its code at the start of the  MBR,  but
    does  not alter the Partition Information (starting at offset 1BEh  of
    the  MBR)  itself.  This means that if the MBR's code  is  simply  re-
    written with clean code (such as the DOS MBR code placed down by FDISK
    /MBR)  the  virus is removed. If howeverthe Partition  Information  is
    completely overwritten, things become more complex. While the  machine
    is  infected and the virus is TSR, everything seems normal, since  any
    attempt  to read the Partition Information will be redirected  to  the
    clean   MBR.  But  if  the  code  is  cleaned,  wthout  the  Partition
    Information  being  restored, or the machine is booted  from  a  clean
    floppy  disk,  no  partitions will exist, so no drives  on  the  first
    physical  hard  drive  will be accessible. This would  appear  to  the
    novice  user  that the hard disk had crashed and all  data  was  lost.
    Ofcourse, if the machine was booted from a virus infected disk  again,
    everything  would be fine. When overwriting the Partition  Information
    make  sure you dont overwrite the AA55h identifier at the end  of  the
    sector, so it remains bootable!

                    RECURSIVE EXTENDED PARTITION
                   ____________________________

    Like the above method, this method will cause a system crash, but in a
    much more peculiar fashion. As with erasing the Partition Information,
    it  is nescessary to stealth the MBR in order for the machine to  work
    correctly  while the virus is resident. Since an MBR can only  hold  4
    partition entries, DOS offers the capability to create a partition  of
    type  05h  -  Extended  Partition. The first sector  of  the  extended
    partition then contains more Partition Information, so it is  possible
    to  create  more  then four partitions. The virus's  Ginger.Orsam  and
    Rainbow  write  the  following  bytes  at  offset  1BEh  of  the  MBR:
    0,0,1,0,5,0,0b8h,0bh,1,0,0,0,0bch,1,0,0. All we need to know  is  this
    indicates an Extended Partition starting at Cylinder 0, Head 0, Sector
    1.  When the virus is active and stealthing it does not matter because
    the original MBR is read instead, but if there is an attempt to access
    a  logical  partition  of  the first hard drive  with  out  the  virus
    resident,  the system will go into an infinite loop - i.e. hang.  This
    is  becuase  DOS  sees there is an Extended Partition at  [0,0,1]  and
    attempts to load it and setup the partitions it contains, but  ofcours
    [0,0,1]  is  the MBR so it just keeps loading the MBR  over  and  over
    again.

                   CHANGING THE ACTIVE BOOT SECTOR
                 _______________________________

    While the previously discussed methods `retaliate' or punish the  user
    if  an attempt is made to remove the virus by re-writing the MBR code,
    this  method  actually lets the virus survive and stay  active.  Doing
    this  is slightly more compex. First, instead of writing the virus  to
    the  MBR,  you write the virus to another unused sector on  the  disk,
    such  as  Cylinder 0, Head 0, Sector 2. Then you alter  the  Partition
    Information  of the Active Bootable Partition (the one  which  has  an
    identity of 80h) so that its starting Cylinder, Head, Sector, is  that
    of  the sector which you wrote the virus to. This way 3 (possible even
    1)  bytes  of  the MBR are changed. When the MBR boots, it  loads  the
    `Boot  Sector' containing the virus, which then executes the  original
    MBR so the Partitions in DOS appear as they did before the infection.

                   ENCRYPTING THE BOOT SECTOR/MBR
                 ______________________________

    Encrypting the original Boot Sector or MBR does not need discussion  -
    this  is  pretty much the same as what was discussed in  the  `ENCRYPT
    YOUR  RESTORATION  DATA' part of the File Infection  section  of  this
    article.  What is more interesting, is a tricked used by Havoc.  While
    infecting  the  MBR,  Havoc checks if the bootable partition  (ID=80h)
    belongs  to DOS (type=Dos 12 bit FAT, 16 bit, or BIGDOS).  If  it  is,
    Havoc  encrypts the first sector of this partition (the Boot  Sector).
    As part of its stealth routines, whenever the encrypted Boot Sector is
    read  Havoc decrypts it in memory, so this is not visible. If however,
    the MBR is cleaned and the virus is no longer resident in memory it is
    ofcourse encrypted.  This means two things - firstly, the user can  no
    longer  boot  from  their Hard Drive since the  Boot  Sector  code  is
    garbled.  Secondly, the user can no longer access  the  logical  drive
    belonging  to that partition, since the drives BPB in the Boot  Sector
    is garbled.

                           ENCRYPTING DATA
                         _______________

    The  virus OneHalf is very difficult to remove, and has been known  to
    cause many problems for AV user-support persons. The virus uses a very
    complex method to hamper its removal. On first infecting the MBR,  the
    virus  searches through the last Partition Entry that could belong  to
    DOS  (12  bit  FAT,16  bit  FAT, BIGDOS, or  an  Extended  Partition),
    calculates the starting and ending Cylinder/Head of the partition  and
    saves  this  information in the infected MBR. The virus then  encrypts
    the LAST 2 Cylinders of the Partition. Each time after this, the virus
    encrypts 2 more Cylinders each Boot-Up. i.e. The first boot-up and the
    last  2  cylinders are encrypted, the second boot-up and  the  last  4
    cylinders  are  infected, etc until eventual the entire  partition  is
    encrypted. When resident in memory the virus intercepts any reads from
    encrypted  cylinders and decrypts them in memory. Likewise,  any  data
    written  to the encrypted cylinders is encrypted first accoringly.  It
    is  a  good  idea to decrypt the encrypted buffer after the write  has
    been  done,  so  as to avoid arousing suspsicion. Using  this  method,
    everything  seems fine while the virus is active on the  machine,  but
    when the system is cleaned, all data is lost.

                      ANOTHER INTERESTING TRICK
                    _________________________

    The  Volga  family  of boot viruses uses a very interesting  trick  to
    produce a similar result to the encryption used by OneHalf. First,  we
    must  acknowledge  the fact that for the INT 13h functions  AH=02  and
    AH=03 (Sector Read and Sector Write) there are corresponding functions
    AH=0Ah  and AH=0Bh (Long Sector Read and Long Sector Write). The  Long
    functions read or write the usaul 512 bytes per sector as well as some
    additional (usually 3 or 4) bytes containing an error correction code.
    If you attempt to read normally (AH=02) a sector that has been written
    in  long format, the read will fail. If however you attempt to read  a
    normal  sector  using AH=0Ah the read will be done succesfully  as  if
    AH=02 had been used. The virus takes advantage of this fact. When ever
    an  attempt is made to write (AH=03h) a sector the virus changes it to
    AH=0Bh  so  the  sector is written one at a time. If multiple  sectors
    were requested to be written, the virus must write them one at a time.
    This  is  because more then 512 bytes are written per sector.  Let  us
    call  this amount X. The virus  writes the X bytes at offset 0 of  the
    buffer  to  the first second, then the X bytes at offset  512  of  the
    buffer  to the second sector, then the X bytes at offset 1024  of  the
    buffer to the third sector, until all sectors are written. So the user
    does  not  notice  this, the virus also converts  all  standard  reads
    (AH=02h) to long reads (AH=0Ah). Once again, the reads must take place
    one  sector at a time. The virus reads the first sector into  its  own
    memory  area and then copies the first 512 bytes read to offset  0  of
    the  read buffer, then repeats this for the second sector copying  the
    first  512  bytes  read to offset 512 of the read  buffer,  etc.  Like
    OneHalf,  everything seems fine while the virus is resident in  memory
    but once the system is cleaned, all data is lost.

                               THE END