I was searching my hard drive for something else and I happened to run into this: a story I wrote over 12 years ago. It's about analysing a virus called Crepate. I hope you enjoy it.
An ordinary day at work; testing F-PROT's OS/2 version, answering support calls and writing the upcoming Update Bulletin. It's over five o'clock, time to get home - the fall is far advanced and I'll have to get my lawn sown before winter sets on.
The phone rings and shatters these thoughts. The call comes from Symbolic, our distributor in Italy. Jeremy Gumbley, who works in Symbolic's technical support, is on the line.
Jeremy gives it to me in a nutshell: A person had just dropped by and told him that a new, unknown virus had been found in one Italian university. There are probably tens of infected computers - the exact number is not known, because none of the antivirus programs that have been tried has been able to identify the new virus. The situation is serious and all the computers will remain on hold until the virus is under control. The visitor brought along a disketteful of files suspected to be infected.
Jeremy has already taken a look at the files and is quite certain that they contain a new virus. I tell Jeremy that the I'll start working on the subject immediately. Via modem, Jeremy transfers a sample packet to the F-Secure BBS system, and the examination begins. I extract the samples and put them through an automated examination system, which checks the files with thirteen different antivirus programs and stores the reports in an easily readable form. The system reports no alarms, although some programs report that certain sample files have counterfeit time stamps: in their creation date, the clock's seconds field shows an impossible value, 62. Some viruses use this trick to mark files they have already infected.
I give the files a quick once-over with a hex editor, enough to conclude that if they contain a virus, it is a brand-new one. Certain files have the text "(c)Crepa" at their end. Via Internet, I transfer the files to Frisk Software International's FTP server in Iceland. Just to be sure, I call Iceland and recount the incident to Fridrik Skulason. He says that the files will be taken under close inspection right away. We decide to divide our forces: I and Jeremy will concentrate on examining how the samples function, in other words find out what the virus really does. The people in FSI will focus on building detection- and disinfection routines for the new virus. We'll keep contact by phone and E-mail. I hang up and start the classification of samples. Seems like I won't get any time off for my lawn today.
I find out quickly that there are three different kinds of samples. Some of the files contain extraneous code at their end. This is not caused by a virus but the "Immunize" function of the Central Point Antivirus program. To be on the safe side, I remove the Immunization code and check the original programs. The files are clean. Some of the other programs contain code which seems to have been added to their beginning. The remaining files have the text "(c)Crepa" at their end. It seems that we need to divide the analysing task if we want to resolve the problem as quickly as possible. I call back to Iceland, and we agree that they will start working on incorporating the detection and disinfection of the virus while I and Jeremy start to disassemble and document the functioning of the little beast.
I give the Crepa files a closer look. There are four of them, all parts of the Italian MS-DOS 6. I choose to probe KEYB.COM, since it is a comfortably short program to examine and I know its structure of old. First I take a hex dump of the program by using Borland's TDUMP application. Then I proceed to run a debug listing of it with good old DEBUG.
It proves extremely difficult to follow the program's execution with a DEBUG listing: the virus completes only one or two instructions at a time before jumping to somewhere else in the code. Therefore I turn to Zanysoft Debugger, and use it to analyze the infected KEYB.COM. Along with Borlands Turbo Debugger, I have found ZD to be a handy tool to examine virus samples with.
The program's execution is easier to follow with ZD, and it soon becomes clear that the author of the virus has wanted to make the program difficult to examine by coding it full of jump instructions. However, a careful inspection of the code reveals that the commands executed between jumps form a complex routine that decrypts 3900 bytes at the end of the file. At this point it becomes obvious that this is a self-encrypting virus.
I execute the virus one command at a time until it has decrypted itself. Then I store the virus code back on the diskette. When I go over the decrypted virus code, I notice that two new lines of readable text have surfaced from beneath the encryption:
The first line appears to indicate that the virus is capable of infecting COM, EXE and Overlay files. The second line confirms the virus to be of Italian origin.
I discover that the task of separating the virus code and the original KEYB.COM code from each other is too arduous. Instead, I decide to see whether I can get the virus to infect a bait file. As bait, I use a collection of COM and EXE files which contain nothing more than a termination instruction and a lot of zeros to pad the files to a certain length. Such programs do nothing else than terminate their execution, and since the file lengths are even numbers, a change in size caused by a virus can be noticed at the first glance.
I transfer the virus to our much-abused test computer, and copy a sample of clean baits into the same directory with the virus. When I run the KEYB.COM, it gives an error message in Italian complaining about incorrect parameters. I use a memory mapping program to check for changes in memory allocation. No changes are evident, which means that the virus is either not resident in memory or capable of bypassing memory mapping applications. I check the bait files - no changes in those either. I run the infected KEYB.COM a couple of times to be certain, but the bait programs are simply ignored. Why? There are many possible explanations. Maybe the virus is picky about the files it infects. Maybe it won't infect anything on even days. Maybe it doesn't infect files in its current directory, but somewhere else on the disk. Maybe it is a stealth virus, in which case the changes cannot be seen anyway, at least not while the virus is active.
Jeremy calls while I'm thinking about all this. We get to a discussion on its peculiar jump structure. "I'm sure I have never seen so many jump instructions", "For a moment I thought it was a new version of the Commander Bomber virus, but no, at least not that", "I think that this jump-spaghetti has been added just to confuse heuristic analysis". Indeed - F-PROT's Heuristic Analysis failed to give warning of an infected file even when the /GURU option was enabled. Goes to show that any software-based protection can be overcome by software. Jeremy has managed to examine the virus a bit further. We agree to name the virus Crepate for the time being.
Jeremy says that, right after decrypting itself, the virus gets into the business of doing some absolute disk writes. Immediately, I get a brainstorm. - It is a multipartite virus we are talking about here, operating in the same way as, for instance, Tequila. When the virus is executed in a clean computer, it infects the hard disk's Master Boot Record but does nothing else. The next time the computer is turned on, the virus stays active in memory and starts infecting other program files. I test my theory - and yes! The F-CHECK checksum program reports an altered Master Boot Record.
I use Norton's DISKEDIT to take a copy of the Master Boot Record's code before restarting the computer. The boot-up seems to be completely normal. I run MEM and find the familiar sign indicating the presence of a boot sector virus: the amount of DOS memory has dropped from the 640 kilobytes normally available in this computer. There are only 636 kilobytes left, which means that the virus takes up four kilobytes. I go back to the virus directory and run the bait files again. Strangely enough, the baits are still not infected. The filesizes stay the same, whatever I do. Without giving the matter further thought, I run DOS's CHKDSK and attain instant enlightenment. CHKDSK reports "Allocation error" for every COM and EXE file I have executed during this session. The report includes all the files referred to in AUTOEXEC.BAT, all bait files, and CHKDSK.EXE itself. This is a clear sign of an active stealth virus that is operating in the computer and hiding the changes it has made to files. However, the virus is not sophisticated enough to hide the changes from the CHKDSK program, which is reporting errors caused by contradictions between directory information and File Allocation Table. The closer I look, the more advanced this virus is beginning to seem. When I compare the infected bait files, I notice that the decryption routine varies between different samples. In addition to everything else, the virus has polymorphic characteristics mixed in.
The phone rings - Fridrik is calling from Iceland. His staff has gone through the same sample files, concentrating first on the samples which I and Jeremy had decided to leave alone for the time being. Some of the samples had indeed been clean, though packed by using CPAV. Some other files had been found to contain a new virus, which was named March 25th. In other words, two different viruses are on the loose in the Italian university! Frisk hands me a short account on the characteristics of the March 25th virus: a memory-resident COM and EXE infector that structurally changes COM files into EXEs. The virus activates on the 25th of March and overwrites most data on the hard disk. The size of this virus is only 1024 bytes, and it is much simpler than Crepate.
Frisk has also gone over the Crepate files, and he is already well acquainted with the virus's functioning. For some reason, though, the virus does not function in his test computers. Although it manages to infect the hard disk's Master Boot Record, the computer won't boot afterwards. Curious. Fridrik is ready to build a disinfection routine for the virus, but he is hampered by the fact that he cannot get it to spread. I promise to send him a program packet containing both clean and infected versions of the same sample files.
After hanging up I take a closer look on the code the virus writes on the Master Boot Record. Aha, it tries to make inspection more difficult with commands that modify the commands next in line...I get another brainstorm. Immediately, I call back to Frisk and ask what kind of a computer he used to test the virus. Frisk tells me he has used his newest virus testing computer, a 33 MHz 386DX. "Does it have internal cache memory", I ask. "Yes, 8 kilos", Frisk answers. The mystery unravels. I had tested the virus in a 16 MHz 386SX computer with no cache memory.
The cache memory of Fridrik's computer buffers commands that are to be executed next, and makes it unnecessary to retrieve them all the way from the main memory. Because of that, though, the changes the virus tried to make in its own code never got through. The bytes it tried to change had already been read into the cache memory where they could not be altered. In other words, the Crepate virus cannot function in computers with internal cache memory - it will only crash them during boot-up.
I start to create a sample of demo files, beginning with a collection of programs that are different from each other both structurally and in file size. I pack the clean programs and transfer the packet into the infected computer. There I execute, open and copy programs. Any of these operations infects the program in question, but I notice that the virus won't infect the smallest files. I boot the computer from a clean diskette, pack the infected files and transfer them back to my own computer. Again, I open a telnet session and send the sample packet to Iceland via FTP.
I continue to examine the virus. It seems that Crepate uses a very peculiar method to hook the DOS interrupt 21h. The virus would gain nothing by jumping to hijack the interrupt for the first thing it does after it has been executed from the boot sector, because DOS takes the interrupt into use only later on. Instead, at the very beginning the virus hijacks BIOS's timer interrupt, activating 18.2 times in a second. The virus uses this interrupt to check 18 times in a second whether DOS has loaded itself. When that happens, the virus hooks the interrupt 21h to its own code. That way it gets to be the first program to clam onto the interrupt.
The phone rings again, this time it's Jeremy. We quickly exchange what we have learned from the virus. He tells me he has found a date check and destruction routine further along the code. The virus activates on the 16th day of any month, and executes a remarkably thorough destruction routine. It overwrites all the data on the first hard disk, going through the disk from beginning to end. Since that kind of a routine is quite difficult to code, most viruses use destruction routines that overwrite only a part of the hard disk. For example, even the notorious Michelangelo virus destroys only a certain amount of the hard disk's data. After such partial destruction, it is usually possible to salvage some data from the hard disk without turning to expensive data recovery services. Crepate is a different breed of cat and goes through the disk thoroughly, sector by sector.
The 16th day. That was a week ago -- maybe the virus was discovered a week ago, when the first hard disks were wiped? No matter. It must be stopped now, before it causes further damage.
I code a routine that checks files for Crepate infection. Using it, I scan the test computer's hard disk. Practically all the programs I have used during the evening have been infected. I wipe the hard disk and restore a basic combination of clean software on it. I run the routine also on diskettes I have used to carry files between the test computer and my own. I'm surprised when I notice that the boot sectors on the diskettes have also been infected. What on Earth - to the best of my knowledge, the virus code contained no routines for infecting diskettes. I go over the code more carefully, looking for something that hints at diskettes. After a time it becomes clear that the virus uses the same routine to infect both hard disks and diskettes. Crepate is a true multipartite virus -- capable of infecting three different file types and two kinds of boot sectors. Its maker must have spent a long time finishing his creation.
Fridrik sends a completed search routine via FTP. Using it as the base, I create F-PROT Professional 2.09e. After a quick check to make sure the program recognizes both March 15th and Crepate faultlessly, I transfer it to the file areas of F-Secure BBS. I call Jeremy to tell him he can pick it up with his modem. At the moment, he is putting together a summary of the virus to be delivered to the client. He says he will take F-PROT to the university in the morning.
Everything is just about finished for the evening. Frisk E-mails a message saying that he'll send a sample of the virus to other antivirus program developers so they can add the recognition of the new virus to their own products. After that, Frisk says, he will go home. Jeremy sounded tired too.
The time is 01.30 in Finland, 00.30 in Italy and 22.30 in Iceland. I'll go and get some sleep, too - the fall is far advanced and I'll have to get my lawn sown before winter sets on.
