<<< NEWS FROM THE LAB - Monday, December 5, 2005 >>> ARCHIVES | SEARCH Old skool virus fighting Posted by Mikko @ 23:13 GMT 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:







COMcomEXEexeOV?ov?

Crepate (c)1992/93-Italy-(Pisa)



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.



Originally published 12 years ago in F-PROT Professional 2.10 Update Bulletin, May 1993.



PS. Jeremy, if you're reading this...get in touch!









