__________________________________________________
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