Maximize
Bookmark

VX Heaven

Library Collection Sources Engines Constructors Simulators Utilities Links Forum

Preserving Infections

Sepultura
Insane Reality Magazine [8]
December 1996

[Back to index] [Comments]

Introduction

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.

Preserving file infections

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 tachniques

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.

Preserving boot infections

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 rewritten 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.

[Back to index] [Comments]
By accessing, viewing, downloading or otherwise using this content you agree to be bound by the Terms of Use! vxheaven.org aka vx.netlux.org
deenesitfrplruua