Simtel MSDOS 1992 June/SIMTEL_0692.cdr/msdos/trojanpr/virus101.002

Internet Message Format | 1989-03-09 | 17.1 KB

From: [e-mail] (George Woodside)
Newsgroups: comp.sys.atari.st,comp.sys.apple,comp.sys.mac,comp.sys.ibm.pc
Subject: Virus 101 - Chapter 2
Date: 6 Mar 89 14:00:21 GMT

In response to a lot of the mail I've received:
1) You haven't missed the "rest of the chapters". I'm posting them as I
   get them written.

2) You may not agree with me. I tried to set down the definitions and
   terms as I would be using them, for the benefit of those who weren't
   familiar with them. This whole area is rather vague, and most of us
   in the trenches and making up the rules, as we learn the game.

When we left our virus at the end of Chapter 1, it had managed to get
itself installed in our system by being present on the boot sector of a
disk in the machine at cold start or reset.

Another way a virus may be installed is via a trojan horse program. Trojan
horses come in many flavors. Some disguise themselves as programs which
provide some useful function or service, while secretly doing something
else. The something else may be installing a virus, sabotaging some part of
a disk, setting up hooks to steal passwords on time sharing systems, or
whatever else you can imagine. In the event of the virus installer, the
trojan horse has a bit more flexibility than a typical boot sector virus,
simply because it doesn't have to fit itself into a relatively small space.
Since it is hiding in a larger program, it can be whatever size is
necessary to accomplish the task.

A typical boot sector contains information about the layout of the disk it
resides upon. This block of data requires 26 bytes. The first three bytes
of the boot sector are left available for an assembly language "jump"
command, to allow the execution of the code to skip over the boot sector's
data block. And, the boot sector must add up to the proper magic number to
have executable status. That will require another two bytes, since the
checksum is a 16 bit value. So, 31 bytes are allocated. Since (at least in
the 68000 family) machine instructions are always 16 bits and must begin on
an even address, 32 of the 512 bytes in the boot sector are not available
to any executable program. So, there are 480 bytes available for the
executable code. Machine instructions vary in length, depending upon what
they do, and how much additional information is required. In the 68000,
instruction lengths vary from one to five words, but a reasonable average
instruction length for a program is just over two words. That translates
the 480 bytes to 120 instructions.

The virus must contain the code to install itself, reserve the memory it
occupies to keep subsequent programs from over-writing it, spread itself to
other disks, and whatever it really intends to do once it decides it is
time to act. That's quite a bit of code to fit into 120 instructions,
unless it extends itself by loading some other part of the disk, or a file.

Files are pretty much out of the question. Most computer users would notice
if some file they didn't recognize started popping up on a lot of their
disks. There are attributes settable in a disk directory which can be used
to tell the operating system that certain files are "Hidden" or "System"
files. If the file had the proper status bits set, it could prevent itself
from appearing in normal disk directory displays. There are, however, more
flexible disk directory listing programs which will display the entries for
these files, as well as normal files. There is also the problem of the
space the hidden file occupies, as well as the directory entry. The space
available on the disk will be less than it should be, since the hidden file
is present. These symptoms would not escape detection for long.

A more effective method is the use of specific disk sectors. The standard
disk layout covered in the preceeding chapter mentioned such things as File
Allocation Tables, and disk directory space. In a standard format Atari
disk, for example, each FAT is 5 sectors long, and the directory is 7
sectors long. That is more than enough FAT space to accomodate the entire
disk. A virus in need of more space than 480 bytes might write the
remainder of itself in the last sector of the FAT (I have one that does
this). It might also write itself in the last sector of the directory,
taking advantage of a quirk in the operating system.

When a disk is formatted, all data sectors are normally filled with a
pre-defined value, E5 (hexadecimal). The directory and FAT space is usually
set to 00. When a directory entry is made active, the file name is written
in the directory, along with some other required information. When a file
is deleted, the first byte of the directory entry is set to E5. That makes
the entry available again. This is a carry over from the early days of
floppy disks, when where the directory would exist on a disk was not as
well defined. The directory entries had to appear as empty on a freshly
formatted disk, so E5 was used as a deleted entry mark. That way, no matter
where the directory was, a freshly formatted disk would always appear as
empty. Now, since disk formats are more flexible, the directory is located
by parameters, and normally the entire directory space is zeroed at
formatting time. Since an active entry will have some legitimate ASCII
character in the beginning of the file name, and a deleted entry will have
E5 in the first byte, it is generally assumed that encountering a directory
entry with a value of 00 in the first byte indicates that the entry has
never been used. Since directory entries are used (and deleted ones
re-used) on a first-found basis, finding one with 00 means that not only
has it not been used, but none of the ones following it will have been used
either. Consequently, most software stops looking at the directory entries
when a 00 entry pops up. If there are several more sectors available, there
may be something hiding out there, beyond the last used entry. While this
method of hiding is not foolproof, the typical virus is not concerned about
being bulletproof in all cases. It just has to survive long enough to
reproduce itself, and it has half the battle won. As long as it keeps
spreading, sooner or later it will survive long enough to do the task it is
designed to do, then it wins both halves of the battle.

There are other ways for the virus to get additional disk space. Typically,
floppy disks are not used up a sector at a time, but rather in groups of
sectors. Each group of sectors is referred to as a data "cluster". The
number of sectors in a cluster is variable, and is one of the parameters
stored in the boot sector. If the number of data sectors on the entire
disk, minus the boot sector, FATs, and directory, is not an exact multiple
of the number of sectors in a data cluster, the remaining sectors will
never be used by the opearting system. A clever virus can find them and
hide there. The inconvenience of this is that the unused sectors would
normally be at the end of the last track of the disk, causing long (and
noticeable) disk seeks to load or spread the virus.

There is a parameter in the boot sector designed to permit the disk to have
sectors reserved for any purpose, and not accessed as part of the normal
data area. A virus could also use this method to extend itself, but it,
too, has shortcomings. Using this feature requires the parameter to be set
when the disk has absolutely no data on it. Reserving sectors causes the
start of the data area to be moved further into the disk. While the data
area would be moved, the data already on the disk would not. Consequently,
altering the reserved sectors parameter would make all files on the disk
garbage. (They could be returned to proper status by restoring the original
value to the reserved sectors parameter, providing no disk write had
occurred.) There would also be the problem of the disk's free space being
less that it should.

Consequently, if a virus needs extra space, using prescribed system
features or hidden files is not a good choice, since it is too easily
detected. The approach used so far is to hide in sectors unlikely to be
used, and hope to spread before they get clobbered (and it works).

OK, so now the virus has managed to get onto a disk in your library, and
then get itself booted into your system at startup or reset. It may have
been on a disk you received from someone, and booted with, or it may even
have been installed by a trojan horse, but it is in your system. How does
it spread?

There are ways, and then there ways.....

The most common method is through the vector reserved for floppy disk read
and write functions. As we saw in Chapter 1, floppy disks get changed (some
surprise, eh?). One disk is removed, and another is inserted. When that
happens, the operating system is notified by the physical act of changing
the disk that the event has occurred. How that event is detected will vary
with different disk drives, but there are two common methods. One is the
disk drive latch. Some hardware reports the transition of the latch on the
floppy disk drive's door. When the locking lever is moved, a signal is sent
to the disk controller card, indicating that the disk door has been opened.
(Door is a carry over term from older drive mechanisms which had fully
closing doors over the disk drive slot.) The operating system makes note of
the fact that a disk change may have occurred.

The other method is the write protect notch. On both 5 1/4 and 3 1/2 inch
disks, the write protect notch tab is located in a position which makes it
impossible to fully remove and install a disk without having the write
protect detection mechanism be fully obstructed at some point, and fully
unobstructed at some point. The detection mechanism may be a physical sense
switch, or an optical sensor. Either way, as the body of the disk is
removed from the drive, it will be blocked. Then, when the disk is out, the
sense area is open. So, the drive will report transitions on the status
line. The operating system notes the change, and sets the necessary flags
to indicate that the disk may not be the same one that was there a little
while ago. It may also be, if the same disk was re-inserted, but that's not
important. The fact that it may have changed is very important. Attempting
to read or write to the disk, without first noting the characteristics of
it, could be very destructive.

When the next access of the (possibly) changed disk occurs, the operating
system will read the boot sector. In MS-DOS systems, I believe that the
operating system assumes that if there is a possiblity that the disk has
changed, it assumes that it has, dumps all information relative to the old
disk, and starts fresh. In the Atari, the operating attempts to be a bit
smarter. The boot sector contains a serial number which is supposed to be
unique across all disks. This serial number is 12 bits long, and is
assigned when the disk is formatted. If there is a possibility that the
disk has changed, the operating system reads the serial number. If the
serial number is different than before, the disk has changed, all old data
is wiped out, and the new serial number is noted. If the serial number is
the same, the disk has presumably not changed, and the data in the
operating system's internal buffers is assumed to be valid. This leads to
thoroughly trashed disks if two disks have identical serial numbers, and
are used consecutively.

In any event, when a possible disk change has occurred, the boot sector is
always read to determine the characteristics of the new disk. The operating
system uses the floppy disk read function to access the first sector on the
disk. As previously noted, this disk read function is pointed to by a
vector. If the vector has been altered to point to a virus, the plot
thickens...

We will assume a typical floppy disk boot sector virus for a while, and see
exactly what happens. The virus first checks the number of the drive being
accessed. If it is not a floppy disk, it passes the call on to the address
it found in the vector. No harm done.

If the call is to a floppy disk, most viruses check the side, track, and
sector of the call to see if it is the boot sector. If it isn't, it passes
the call on, and again, no harm done. Why? Performance. Not that the virus
cares about good disk performance, mind you. What it cares about is being
noticed. If it was busy snagging all the disk calls, and checking the boot
sector all the time, there would be an incredible increase in disk head
seeking, and a very noticeable drop in performance of the system. Anyone
with at least half a brain (witch inkluds sum smarter komputer pepel) would
notice that, and would become inquisitive about what was happenning. The
virus would have given itself away. No self-respecting virus would want to
be detected before it got a chance to spread, and possibly wreak a bit of
havoc, so it remains inactive until it can accomplish its task unnoticed.

When the read call is to the boot sector, the virus goes into action. The
data is read into a buffer, as designated by the host operating system's
call, exactly as expected. Normally, the disk read function would return to
the operating system at this point, but the virus doesn't. Depending upon
the sophistication of the virus, several things may happen. Some viruses
will first check the image of the boot sector in the buffer, to see if they
are already on the disk. If they find the disk already has the virus, the
go back to sleep (pleased, we assume!). Some even check revision levels in
the virus image, and replace themselves if the disk had a more recent
version of themselves!

If the image from the boot sector is not the virus, some will check to see
if the image was of an executable boot. If it was, the virus does not alter
it. Doing so would make a self-booting disk fail forever after, and would
probably lead to the detection of the virus. Other viruses, not as
sophisticated, will not execute this test, and may be spotted more readily.

Now, assuming that the boot sector is not executable, or that it is but
this virus is too dumb to leave it alone, it's time for the virus to
spread. There is a copy of the boot sector from the original virus disk in
a reserved memory area, from the original boot up process. The executing
copy of the virus knows where that is, since it reserved the memory for
itself and the image at the same time. The characteristics of the disk the
virus came from may not be the same as the disk in the machine now.
Depending upon the operating system's standards, the virus will either copy
the disk parameter information from the current disk into its own image
buffer, or copy its image into the current disk's buffer, leaving the
disk's parameters unchanged. Either way, the result is a copy of the
current disk's parameters, combined with the executable image of the virus.
Now, the executable status checksum must be computed, and added to the
buffer. This may be accomplished by a routine in the virus, or by an
operating system call. If the virus is on an Atari, it might be careful
enough to insure that the serial number on the new disk remains the same.
Failing to do so would lead to all disks with the virus having the same
serial number. That would lead to disks being accidently altered (due to
the serial number test), and the virus would probably be detected too soon.

When the new checksum is completed, the updated boot sector is re-written
to the disk. All this occurs in much less than the time required for the
floppy disk to make a single revolution, so the boot sector is re-written
on the next spin. Since the rotation speed of the disk is either 300 or 360
rpms, the total time lost is less than 1/5 of one second. Nearly impossible
for anyone to notice, when combined with the time required for the drive to
load the head, seek to track zero, read the sector, etc.

The only potential problem here is one of the virus' intended victim's
primary levels of defense: the write protect feature. Despite rumors to the
contrary, I have not seen a virus capable of writing to a write protected
disk. The hardware in the disk drive will not write if the write protect
status is set. It reports an error to the operating system. The virus can
not override this protection, but it must be wary of it. Older viruses were
sometimes spotted when a system error occurred, reporting that an attempt
was being made to write to a disk which was write protected. If the
function being performed (listing a directory, for example) should not be
writing to the disk, there was reason to become suspect. Most viruses now
are more sophisticated. They take over the error vector before attempting
the write, and restore it afterwards. That way, if the attempt to spread
themselves to the new disk fails, the error never gets reported. While the
user doesn't know that the attempt was ever made, the disk also doesn't get
infected.

Many viruses run counters. Some count the number of already infected disks
they have seen, while others count the number of disks they infect. Either
way, the counting viruses have some threshold they are attempting to reach.
When they reach that number, they (presumably) consider themselves
thoroughly spread, and it is now time to start their third act.

End of Chapter 2.
--
*George R. Woodside - Citicorp/TTI - Santa Monica, CA
*Path:       ..!{philabs|csun|psivax}!ttidca!woodside