![]() |
![]() ![]() |
![]() |
I am often asked if virus writers are good programmers. This is a little like asking if Jack the Ripper was a good surgeon -- for the most part, such a question is not only irrelevant, but offensive. Any skill displayed in executing a malicious act can only make that act more abominable.
Here, the question of skill or expertise serves only to apportion the degree of guilt to be assigned to the perpetrators. If a schoolboy creates a virus without really understanding what he is doing, he is merely being irresponsible. If a skilled programmer creates a virus, he is a criminal.
I have disassembled well over one thousand viruses: many have been extremely complex, but only two or three have shown evidence of real programming skill. Hopefully, this indicates that genuinely talented programmers have too much appreciation of computing to write viruses.
The virus under examination this month, Pathogen, displays above-average programming skill, and some in-depth knowledge of anti-virus techniques. These facts, coupled with a very nasty trigger routine, make the writer one of the most destructive individuals whose work I have encountered.
Pathogen is a resident, parasitic virus which infects COM and EXE files by intercepting two DOS file access functions. The code is encrypted, and the decryptor randomised on each infection, so all appended code is changed. This method of avoiding identification has become known as polymorphism. The virus will not trigger until it has achieved a certain degree of penetration, but when it does, most of the data stored on the fixed disk will be destroyed, and the floppy drives will be disabled until the CMOS can be reset.
When an infected file is executed, the virus gains control and decrypts its code. A call is issued to determine if the virus is already resident. This 'Are you there?' technique is almost standard for resident viruses. Here it is achieved by placing a value of 18FFh into the AX register and issuing an Int 21h request. If the value returned in AX is 0E71h, the virus is deemed resident, and processing passes to the host program.
If the virus is not resident, processing passes to a memory allocation routine which searches the machine memory structure and locates a suitable block of memory. The virus grabs 7872 bytes from this block, which is then allocated to DOS ownership and used to store the active resident virus code. If necessary, the available memory pointer is also modified, to ensure that the virus code remains undisturbed.
The process of hooking the virus into the system begins by collecting the required system addresses from low memory, and inserting them into the virus code. Next comes a routine which traces the interrupt processing until an address within the DOS area is recognised. This address is inserted into the virus code. Tracing interrupts in this way is known as 'tunnelling', and done to try and bypass monitoring software which has itself hooked into system services. It is easy to write software which can detect and prevent this tracing process so that a good quality anti-virus monitor will not be affected by it.
This virus tunnels both the DOS Interrupt, Int 21h, and the Disk Service Interrupt, Int 13h, although only the DOS Interrupt is actually used by the virus. Once the tunnelling process is complete and the appropriate addresses collected, a counter is incremented for later testing. Next, the virus code is relocated into the prepared memory space, and the address of the virus routines are inserted into the interrupt vector table. Processing finally returns to the host program and the virus remains resident to intercept the system and disk requests.
While resident and awaiting system requests, Pathogen actively intercepts only Int 21h functions 4Bh and 6Ch (Load_and_Execute and Extended_Open/Create). Although a hook is inserted into the Disk Service Interrupt 13h, it is used in a passive manner, to reroute system requests to the tunnelled vector when they emanate from the virus code. The idea, presumably, is to avoid any monitoring activity on either interrupt when the virus code is accessing the system. The manner in which this is done suggests that the writer knows how some of the less efficient monitoring systems work and has designed this method of circumventing them.
The Int 21h handler follows a more usual pattern. The first check made on intercepted functions is whether the 'Are you there?' call has been made. This is followed by a detection routine which reroutes any exit program requests (via function 4Ch or Int 20h) to the tunnelled Int 21h vector.
The main intercepts 4Bh and 6Ch are then detected and intercepted; all others are allowed to continue into normal system services. The intercept routine is identical for both function requests, and begins by setting a flag which will indicate to other routines that the virus is in control. The virus then collects and stores the existing addresses for three other interrupts -- Int 03h, Int 23h and Int 24h -- and installs a default handling routine for Int 23h and Int 24h to avoid interference by DOS in the event of system errors.
The Int 03h routine is then hooked into the tunnelled Int 21h routine, to be used by the virus to access the DOS services. This is unusual, and seems to have been chosen to make single stepping analysis of the code more difficult. It is no secret that most debugging and analysis programs use this single byte interrupt to place break point markers in code under active analysis. This is easily circumvented, but quickly becomes rather tedious for the researcher.
Once these hooks have been set, the virus checks the counter mentioned in the installation section. If the counter value is zero, processing passes to the trigger checking routine (see below). Otherwise, the infection section is entered, and the virus begins checking the target file for suitability for infection. The target file in this case is that being processed by the original system call -- Pathogen does not instigate its own search for suitable files.
The first stage of checking ensures that the target file has either a COM or an EXE extension. Then the beginning of the filename is tested to see if it begins with a pair of characters from the following list contained within the code: CO, F-, SC, TB, VI, FS, VP, VS, CL, SM and FL. If the target filename begins with any of these, it is not infected.
Processing continues by collecting the attributes of the target file and storing them before resetting them to allow Read/Write access. The file is then opened, and the date and time stamps collected and stored. The date stamp of the file is checked to see if the year value is greater than 100 -- if so, it is assumed to be already infected, and rejected by the virus.
If the file is acceptable thus far, its first 32 bytes are read into memory and checked for the presence of the 'MZ' or 'ZM' header bytes which identify EXE files. Processing branches depending upon the result of the test. Non-EXE files are checked to ensure that they are not greater than 56000 bytes in length -- otherwise, they are rejected. A number of garbage bytes are then appended to suitable files, to increase their size to an exact multiple of 16.
EXE files are checked to ensure that they are parent programs, with no overlay number in the header field. Processing then tests the memory allocation fields within the header, and also true file size, to ensure that the file has no additional code. Next, as non-EXE files, random garbage bytes are written to make the size a multiple of 16. Extra processing is then completed to modify the EXE header segment and offset fields to ensure that the virus is processed first. A childish trick is employed to make the virus code 'appear' to be in the stack segment of the host program. This might confuse some simple debuggers and disassemblers, but is merely an empty gesture to an experienced researcher.
After the encrypted code has been appended to the host file, the attributes, date and time are returned to their original condition (with 100 added to the year value) and the file is closed. Processing then returns to the host program.
The primary check for the trigger routine has already been mentioned in the installation section. The generation counter is set such that it only increments each time the virus code is installed into memory. Thus, if the counter value is five, after installation it will become six. This will be the value in every infected copy generated during that session. There is little likelihood of the number increasing by more than two or three during the life of the virus on a specific machine.
Copies taken to other machines might also show an increase of two or three, and so on from machine to machine. The number is set to cycle from 0 to 31, and the check is looking for a value of zero, so it will only be successful after the virus has passed through several machine generations. If, for other reasons, the check fails and the virus survives, there will be a trigger-free period before the next trigger time.
However, if the primary check is successful, the system day and time is then checked. If this indicates that it is not Monday between 17:00 and 17:59 (inclusive), processing branches to a routine which attempts to de-install the floppy drives. Otherwise the keyboard is disabled, the screen is cleared, and a message is displayed:
Your hard-disk is being corrupted, courtesy of PATHOGEN! Programmed in the U.K. (Yes, NOT Bulgaria!) [C] The Black Baron 1993-4. Featuring SMEG v0.1: Simulated Metamorphic Encryption Generator! 'Smoke me a kipper, I`ll be back for breakfast.....' Unfortunately some of your data won't!!!!!
The virus then proceeds to write garbage at random all over the first fixed disk of the system. This process uses the low-level access routine, and will therefore corrupt any logical drives on that disk (not necessarily drive C). It is likely that the first trigger condition will occur before the second one, so it is possible that the virus will leave a system corrupted and disabled, and no external software will be able to be loaded without resetting the internal configuration.
In viruses which use both encryption and decryption randomisation, the infection process has to be in at least two distinct stages. First, a decryption algorithm must be chosen; then a pseudo-random routine generated to achieve that algorithm. This done, the virus code can be encrypted (according to the chosen algorithm), and appended to the decryptor. In this way it is possible to produce infections of the same virus code which differ in every byte when considered in their passive state (attached to host code).
A further complication is introduced in some viruses by prepending executable garbage code. This code will execute without corrupting the programming environment, but fulfils no function other than to take up a random amount of space. Some early viruses which used this technique contained extremely complex routines to generate truly random garbage code while ensuring that memory modification was kept strictly under control.
At first sight, this virus appears to do much the same thing; closer analysis, however, reveals that there are only six different decryption algorithms, each of which has two coding methods to achieve them. Thus, identification of this virus will be considerably easier than many others, although the apparent complexity is time consuming.
For someone to hate computing so much that they produce a virus like Pathogen is almost beyond belief. With the added suspicion that some genuine anti-virus research was involved, the possibility of market manipulation becomes more real. Pathogen will cause problems for some anti-virus vendors due to the complex nature of the polymorphic code, and the tactic of releasing the virus straight into the wild makes the destructive trigger even more malicious.
In Singapore, I believe a person can be flogged for vandalising a car -- on that scale, this virus writer would qualify for a punishment well off the Richter Scale of human endurance. The infantile ramblings in the trigger message are normal in viruses now, and the 'Black Baron' obviously fancies himself as one of the UK's top programmers. However, he doesn't even qualify for the heats, let alone for the final.
![]() |
![]() ![]() |
![]() |
![]() |
Virus Bulletin: SMEG:Pathogen / webmaster@virusbtn.com | © 1998 Virus Bulletin Ltd. |