NEWS FROM THE LAB - Monday, December 5, 2005

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.

F-PROT Professional 2.10 Update Bulletin

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

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

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:


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

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

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!