From: woodside@ttidca.TTI.COM (George Woodside)
Newsgroups: comp.sys.atari.st,comp.sys.apple,comp.sys.mac,comp.sys.ibm.pc
Subject: Virus 101 - Chapter 1
Date: 1 Mar 89 14:39:58 GMT

Preface: The program VKILLER is specific to the ATARI ST. My apologies
for not making this clear in the previous posting, which went to
several newsgroups. I have recieved far too many requests for the
program from users of other systems to reply to each one individually,
and the mailer has bounced some of the replies I tried to send. If you
have an Atari, VKILLER was posted here a few weeks ago, and is
available in the archives, on GEnie, Compuserve, and from most public
domain disk distributors and User Group libraries. The current version
is 2.01. 

Initial postings will cover virus fundamentals, as they apply to the
area of the Atari ST and, similarly, to MS-DOS systems. The file
systems of the two machines are nearly identical. These general
information articles will be cross-posted to the newsgroups in which
this topic is now active. Future postings will be made only to the
Atari newsgroup, since they will deal with viruses (the plural,
according to Webster's, is viruses) known to exist in the ST world.
They would automatically be different than an IBM virus, since they
are in the 68000 instruction set, or from a Mac or Amiga virus, since
the file systems differ. Since all the viruses I have located are the
"BOOT SECTOR" type (far and away the most common), that's what I will
dwell upon. If and when the proposed newsgroup comp.virus becomes
active, it will be added to the list for all postings.

Your generic disclaimer: I just an old-school computer hacker, with 20
years in the software business. I built my first IMSAI many years ago,
and have had several different computers. That qualifies me to have
spent a lot of time on computers, but nothing further. I may be wrong
about some things, may have a different opinion than you or anybody
else, or most anything else you'd care to have disclaimed. What I
think is my own opinion, and in no way represents the opinion or
position of my employer or anyone else. I've written several articles
for magazines as well as software related to virus detection and
killing, but I have been known to be wrong (so they tell me :^)).

While posting any kind of information about viruses may trigger
someone to attempt creating one, I believe that the benefit of the
knowledge to potential victims outweighs that risk. I don't believe
that you can stop someone (who wishes to) from creating a virus by
withholding information - it is already available from many sources.
Since not all viruses act the same, or attempt to attack in the same
manner, it may help potential (or current) victims to learn about the
symptoms of the viruses known to exist, and how to protect themselves.

While the concept of viruses can be complex, I'll try to keep things
at a level that should be understandable by most anyone past the
casual user genre. However, since I've been at this sort of thing for
some time, what I consider basic knowledge may not be familiar to
everyone. Advance apologies are offered here for any invalid
assumptions, typos, smart alec remarks, grammatic errors, or whatever
offends you. 

Some basic terms, as they have come to be used in this area: 

A VIRUS is any program which spreads itself secretly. It may be
destructive, a prank, or even intended to be helpful, but it spreads. 

A TROJAN HORSE is a program which executes one function secretly while
appearing to be accomplishing some other task, or appearing to be some
other program entirely. One task a Trojan Horse may accomplish is to
install a virus, which would then spread itself.

A WORM is a program or function which imbeds itself inside another
program, be it an application, part of a system, a library or
whatever. It may or may not spread itself by some means, and may or
may not have destructive intents. 

Now, to the basics of a disk (specifically floppies, but true of most
hard disks as well): 

A DIRECTORY is a list of files and sub-directories. There is one
primary directory (called the root directory) on a disk. It contains
the entries for files, and other directories (called sub-directories,
or folders on the Atari). Sub-directories (folders) may contain
entries of other sub-directories, files, or both. Every file has one
entry in the disk directory (or in some sub-directory). That entry
contains, among other things, the file name, date and time of
creation, length, and the address of the first entry in the File
Allocation Table (FAT) for the file. 

A FAT is a File Allocation Table. It is a road map of how the
operating system will locate data on a disk. Essentially, it is a
series of pointers. The directory entry of a file points to the first
FAT entry of that file. That entry points to the next, and so on,
until the last entry, which contains a special value indicating end of
file. There are two copies of the FAT on the disk, since it is
absolutely critical. Lose the FAT, and the data on the disk becomes
un-accessable. 

A BOOT SECTOR is the first sector on a floppy disk. With the Atari
(and MS-DOS) system, it contains configuration information about the
disk. That information includes how many tracks are on the disk, how
many sectors per track, how many sides on the disk, how big the FATs
and directories are, where the data begins, etc. On the MS-DOS
systems, the boot sector contains the ID of the operating system under
which it was formatted. On the Atari, that value is not used, but
replaced (in part) by a number. That number should be different on
every disk, and is used as part of the mechanism by which disk changes
are detected. The boot sector may or may not contain executable code.
If it does contain executable code, it is normally executed only at system
powerup or system reset time. 

On all such disks, the boot sector is number 0, the first sector on the
first side of the first track. On a standard format Atari disk, the
next five sectors are the first copy of the FAT, the next five sectors
are the second copy of the FAT, the next seven sectors are the root
directory, and the remainder of the disk is available for data.

Now, on with the show: 

Floppy disks are changed on a regular basis while the computer is
being used. More so on systems with no hard disks, but periodically on
most all systems. This event, referred to as a "Media Change", is
detected by the computer's disk drive. The disk door is opened, the
status of the write protection changes as one disk is removed and
another is inserted, etc. When that happens, the operating system must
recognize that the disk has been changed before attempting to read or
write to the new disk. The operating system reads the disk's boot
sector to learn about the newly inserted disk. That instant, when the
operating system checks the new disk, is when nearly all the boot
sector viruses spread. We'll get to that in the next chapter, but first,
a more primary question: 

How did the virus get in there? 

When a computer is booted up from a power off state, or reset (in most
cases), it starts executing code from internal ROMs. Those ROMs set up
primary vectors, minimal configuration information, and perform some
fundamental tests. Then they start moving into uncharted waters. They
have to find out what devices are attached, and get them into
operating status. They also have to provide a means of expanding their
own capabilities to support new devices, functions, and whatever else
which may not have existed when the ROMs were created. One of the
means by which this is accomplished is by checking various addresses
for special codes, magic numbers, or any kind of response to a read
or write. Another function which may be enabled is checking the boot
sector on an inserted floppy disk for executable status. If that boot
sector has executable status, the code contained in the boot sector is
executed. That code may cause other portions of the disk to be loaded
and executed, set variables or vectors, or nearly anything imaginable.
That includes infecting the system with a virus, if that's what the
boot sector code contains. Executable status may be via a special flag
value in a reserved address, but it is normally determined by adding
up the value of all the data bytes in the boot sector. If the total
derived (called a checksum) is a specific value (a "magic" number),
then the boot sector is deemed executable. The code is usually executed
at that time. The code is not normally garanteed to be loaded at any
specific address in memory, so it must be "position independant",
or capable of executing no matter where it exists in memory.

The boot sector is of limited size, normally 512 bytes. While that is
enough for a small program, it may not be enough for whatever task it
is designed to accomplish. So, part of what the code in the boot sector
accomplishes must be to load the rest of the code it needs to get the job done.
This may be a normal data file, or hard coded to some other part of the
disk.

If the code from the boot sector is designed only to accomplish some task,
it will normally take the steps to do so, then return to the operating
system. This may be setting the screen resolution or colors, issuing
an initialization command to some device, or setting up some option
or feature. If the code is designed to remain available after the initial
execution (such as part of a device driver), it must inform the operating
system that it wishes to remain resident. The operating system then
alters the amount of RAM available to protect the space occupied by the
loaded code, so that subsequent programs do not tamper with the loaded
routine. Such a routine is referred to as a "Terminate and Stay Resident"
routine, or a TSR. Viruses must be TSR type programs. They have to remain
in the system, and active, to be able to accomplish their spread, and
eventually, their true goal. If the boot sector program was designed
to attack immediately, it may accomplish its destruction, but it would
never get the opportunity to spread, and the disk which caused the
attack would be easily identifiable.

Most viruses accomplish system infection by taking over a "vector". A
vector is a specific address in system memory which contains the
address of a routine or function. When an interrupt (such as pressing
a key, the clock ticking, or so on) occurs, processing is suspended,
and the system loads the address in some vector associated with that
event. It executes the routine at the address which was stored in the
vector, then resumes whatever it was up to when the interrupt
occurred. Other vectors are not associated with interrupts, but with
specific functions, such as display a character on the screen, read a
sector from the disk, write to the printer, and so on. 

To take over a vector, the steps are fairly simple. A RAMdisk, for
example, will usually take over a disk read/write vector. When it
installs itself, it removes the current address from the vector
assigned to the disk read/write function. It saves that address in
it's own code, and places the address of it's own code in the vector.
When a disk read/write call is made by the operating system, the
operating system loads the address found in the proper vector, and
starts executing the code found at that address. That address now
points to the executable code of the RAMdisk. The first thing the
RAMdisk does is check the function call's parameters to see if the
read/write is for the RAMdisk. If it is, the RAMdisk accomplishes the
read or write, and returns to the operating system. If the read/write
is for some other disk drive, the RAMdisk code passes the call on to
the address it removed from the vector, allowing the assigned device
to accomplish the task. 

There may be more than one alteratiion of the vector. Each new routine
which is installed will save the old vector, and insert itself. That
means that the routine installed last will get the first access to any
call which uses that vector. If it does not want the call, it passes
the call on to the address it found in the vector, and so on. The
significance of this sequencing is that a boot sector virus, if
present, will be one of the first "vector snatchers" to get installed.
Conversely, it will be one of the last routines in the sequence to get
executed when a vector is accessed. 

If the vector in question happens to be for floppy disk I/O, the virus
will be one of the last vectors before the real physical read/write
routine. So, if a program designed to detect a virus's floppy disk I/O
calls is executed as part of a startup procedure, it can easily be
fooled. The detect program will see only normal system I/O calls
passing through the vector. The virus resides in the vector list after
the anti-virus program, so the anti-virus will never see any activity
generated by the virus. The anti-virus thinks that things are
progressing well, while, in reality, the virus is either spreading or
doing damage behind the anti-virus's back. 

If the anti-virus gets installed first (say, by being in a boot sector
itself), it has a better chance of offering protection, but not an
absolute one. Some viruses check things like ROM version numbers, and
know the absolute addresses in the ROMs of the functions they want. By
using those addresses, they can bypass subsequent links in the vector
list, and still do their dirty work. They can also refuse to install
themselves if the addresses or version numbers do not correspond to
the environment they want. 

End of Chapter 1. 
-- 
*George R. Woodside - Citicorp/TTI - Santa Monica, CA 
*Path:       ..!{philabs|csun|psivax}!ttidca!woodside
From: woodside@ttidca.TTI.COM (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
From: woodside@ttidca.TTI.COM (George Woodside)
Newsgroups: comp.sys.atari.st,comp.sys.apple,comp.sys.mac,comp.sys.ibm.pc
Subject: Virus 101: Chapter 3
Date: 13 Mar 89 14:24:23 GMT

First, the mail: 

Addressing a controversial topic is sure to generate some strong responses,
and this one is no exception. Mail of the "Thank You" flavor outweighs the
"You Idiot" flavor by about 4-1, so I'll be pressing on. The majority of
the "You Idiot" mail is from senders who either admit, or display, limited
programming ability. For the benefit of those individuals: I appreciate
your concern. I am not attempting to aid in the spread of viruses, but in
your own understanding of them, and ability to defend yourself. People with
the ability to create a working virus will have found little or nothing
they didn't already know in the preceeding postings. There is certainly
nothing in them that isn't already available in the most fundamental books
about personal computers. The preceeding postings are also written at a
superficial level, and are missing quite a few specific things necessary to
make a real working virus. Those missing items would add nothing to the
layman's understanding of how a virus spreads or works, so are not
included. You need not take my word for this; contact anyone you know who
is knowledgeable in the system software field, and they will confirm it. 

Sin of omission: 

Part of a message received from Forrest Gehrke (feg@clyde.att.com): 

...One method for a virus finding enough space to hide itself, that I have
seen, you have not mentioned. I have noticed that the so-called Pakastani
virus uses non-standard sectoring at tracks 37 and 38 for IBM PC
diskettes... 

Mr. Gehrke is quite right. I did forget to mention this technique. While I
had heard rumors of it being in use, I hadn't seen it in any of the virus
code I've captured (again, I'm in the Atari ST world). 

I have responded to all mail I have recieved (if it requested a response)
including mailing out copies of missed chapters. Several responses have
been returned by various mailers. If you requested something, and haven't
heard from me, either your request or my response failed.

Now, Chapter 3: 

Once a virus has installed itself, and replicated as frequently as it has
found the opportunity, it will eventually launch whatever form of attack it
was originally designed to do. That attack is the real purpose of the
existance of the virus. Everything up to this point has been for the sake
of getting to this stage. 

What will it do? Almost anything. The limits are imagination and code
space. The most benign virus I've seen claims to be an anti-virus. It
blinks the screen on boot-up. The idea is that if you see the screen blink,
you know that the benign virus is on the disk, rather than a more malicious
one. It does, however, spread itself just like any other virus. From there, 
things proceed through the prank levels, time-triggered, messages, ones 
which try to simulate hardware failures, to ones which destroy files and 
disks. The actions vary from virus to virus. And, of course, there is a 
whole different library of viruses for each machine type. Attempting to detect
a virus by describing or recognizing the symptoms is not only a task of 
limitless proportions, it is too little too late. When the symptoms appear, 
the damage has already been done. 

Several viruses attempt to simulate hardware problems. (Conversly, I've had
several pleas for help with a virus that proved to be other types of
failures.) Frequently these viruses use timers to delay their actions until
the system has been running for some time, and to spread out their
activities to make the problem appear intermittent. Such virus induced
glitches include occasionally faking succesful disk I/O, while actually not
performing the read or write, altering the data being read or written, and
(more commonly) screen display glitches. It is very difficult for anyone to
determine whether such incidents are the results of a virus, or a real
hardware problem. When such incidents start to occur on your system, start
executing whatever virus detection software you have available, before
lugging your system off to a service firm. 

Previously, I mentioned the use of write protected disks as a step in the
right direction to protect yourself. A large percentage of personal
computer systems now use hard disk systems. Floppy disks are more often a
backup media, or offline storage of files not needed on the hard disk for
day to day use. Backing up requires the disks to be writeable, as does
archiving off the infrequently used files. It is good practice to write
protect the archived disks as soon as the files are copied to them. Run
whatever virus checking software you have on the archive disks, write
protect them, and then file them away. 

(When reading the following suggestions about protecting your system from
attacks, keep in mind that not all techniques can be applied to all systems
or all software. Read the documentation accompanying the software before
your first attempt to use it. Be familiar with what it is expected to do 
before you run it, and you'll be more able to recognize unexpected activity.)

The next step is to apply write protection to whatever disks you recieve
software distributed on, before ever inserting them into a computer. Be
they Public Domain, User Group Libraries, Commercial Software, or whatever,
write protect them before you first read them. Then, make a backup copy if
possible. Finally, when first executing the new software, have only write
protected disks in your system. You should be well aware of any legitimate
attempt to write to a disk by the software before it happens, and have
adequate opportunity to insert a writeable disk when the proper time comes. 
This will not only give you a clue to the presence of a virus in the new
software, but also protect the new software from a virus already resident
in your system.

If your system supports the use of a RAM disk, copy new software into the
RAMdisk before executing it the first time. Put write protected disks in
the drives, then execute the software from the RAMdisk. If the software has
no reason to access other disks, especially when starting itself up, be
very suspicious of any disk activity. The most common time for a virus or
trojan horse program to do it's dirty work is at startup, when it is
impossible to tell whether disk access is part of program loading, or some
clandestine operation. By having the software loaded into and executing
from memory, you will be able to detect any disk I/O which occurs. 

Finally, backup everything. Hard disks, floppy disks, tapes, whatever. Make
backup copies, write protect them, and store them in a safe place off-line.
If you are attacked by a dstructive virus, your first problem is to rid
your system of the virus. Do not go to your off-line backups until you have
determined if your problem came from a virus, and if so, that you have
removed it from the system. A backup is useless if you give a virus a
chance to attack it as well as your working copy. 

A significant portion of these three chapters have been related to boot
sector viruses. While the most common type in the Atari and MS-DOS world,
they are certainly not the only type. 

What follows is next is mostly a re-phrasing of an article from "Los
Angeles Computer Currents", June, 1988. There are a few direct quotes from
the copyrighted article. While I do not agree with all that this article
states, I can not disprove the items from a position of experience. Since
my efforts here are to inform, you may judge for yourself. A significant
portion of my remarks are oriented to the Atari ST, but the concept is true
to most all personal computers. 

An article in that issue, by Lewis Perdue, outlined the problems he faced
when the IBM PC running Ventura Publisher he was using to create the first
issue of PC Management Letter became infected. I won't begin to copy all
that, but the most interesting part of the recovery task was when they used
a normal (high-level) format program to clear the hard drive. It didn't
kill the virus. They had to resort to a low level format, and rebuild from
all original distribution disks. Their backups had been infected as well as
their working copies of the software. They relied on a PC specific tool
called Data Physician, by Digital Dispatch, to aid in the detection of the
virus. It implements techniques to diagnose infections, but it has to be
installed before the virus strikes. 

Another, more interesting aspect of the article, was categorizing viruses
into four groups: Shell, Intrusive, Operating System, and Source. 

Shell - these "wrap themselves around a host program and do not modify the
original program." In laymen's terms, such a virus would tack itself onto a
program file, so it would get loaded with the program. It would have to do
this in a manner that would cause itself to be executed before the host,
since the host certainly would not pass control to the virus. 

This would be quite a complex task on an Atari ST (and on systems with a 
similar structure for executable program files). The virus program would
have to be quite large in order to deal with the structure of an executable
file on the ST. In simple terms, an executable file (a program) is a series
of unique sections: a header, the code, data, a relocation map, and
possibly a symbol table. The header specifies the size of each of the
following segments. The code is the program, but in a form which will not
run until it has been relocated. The data is constants, literals, messages,
graphic data, etc. The relocation map tells the ST what changes to make to
the code before it can be run. The symbol table is not usually present,
except during program development. The reason behind this structure is that
when a program is created, it does not know where in memory it will reside
when it is executed. Things like RAMdisks, device drivers, accessories,
printer buffers, spelling checkers, and so on, may or may not be present in
the computer when the program is run. Since each of those things require
memory, the place where the program will wind up being loaded is unknown.
So, when it does get loaded, it has to be told where it is. And, since the
program will almost always contain references to itself (subroutines,
variables, etc.) it has to be modified so that those references point to
the right place. That's what the relocation map is for. It details how the
program has to be modified. Once the program is loaded into memory, and
fixed up, the relocation map and symbol table are discarded. So, to hook
into a program file, a virus would have to split the program file, attach
itself to the beginning of the code segment, (that's where execution
begins), re-attach the data, relocation, and (possibly) symbol table
segments, update the relocation map (all the original references would now
have moved), update the header, then re-write itself to the original disk,
assuming there was room on the disk for the (now bigger) file and that the
disk was not write-protected. That's a large amount of work to develop, and 
a large amount of code to sneak into a system for the original infection. 

I should mention here that it is not difficult to write "position
independant" code on most micro-processors. You have to set out to do that,
though, and take the necessary steps along the way to keep everything
position independant.  Boot sector code is a well known example. The
address where the boot sector will be loaded into memory is unknown, and
there is no relocation done on the code. It has to be position independant.
It also has to fit in the boot sector. If it needs more than the amount of
space in the boot sector, it has to determine its own location, and load
the additional code itself. Of course, that means that it had to have a
place to store the additional code, and it had to know where to find it. 
Those items were covered previously.

Detecting a "Shell" type virus is not difficult. When it attaches itself to
the target program, it must increase the size of the file. While it would
be a real nusiance to check file sizes on a regular basis, there are
programs available to do this for you. An "alteration detection" program
will typically accept a list of programs to recognize. It will write a data
file of its own, noting characteristics of each file in the list, such as
length and date, and then run a numeric algorithm across the file. The
numeric algorithm (typically a Cyclic Redundancy Check, or CRC) will yield
a value which is stored in the alteration detection program's own data
file. Then, on each subsequent execution of the alteration detection
program, it checks the recorded characteristics of each file in its list,
and re-executes the algorithm on the files. It reports back any file which
has been changed since it last executed. Needless to mention, such a
program must be run on the files to be monitored before any virus has an
opportunity to attach itself to those files. Then, it must be run frequently
to have a chance to detect altered files.

(Back to the types of viruses defined in the article)... 

Intrusive - Intrusive viruses work by patching themselves into an existing
program. This type of virus has two possibilities - either it is willing to
render the host program useless, or it will attempt to co-exist with the
host. If it is willing to corrupt the host, this is not too difficult a
task. It would replace a part of the host program, modify the relocation
map, and wait to get run. When it did, it would abandon the original task
of the host program, and launch its attack. An example of this would be the
virus bearing version of a word processor which struck the IBM compatible
market some years ago. It signed on, looking just like a popular shareware
program, but it was busy re-formatting the hard disk while the user waited
for it to load and get ready to accept input. 

The other flavor of intrusive virus, which attempts to co-exist with the
host program, is terribly difficult to create. It has to modify the host in
a manner that either accomplishes the host's task while also doing it's
own, or find a part of the host that is infrequently or no longer used, and
hide there. It would then have to modify some other part of the host in
order to get itself executed. In either case, a virus of this type has to
be aimed at one specific host program. There's no way it could perform the
analysis necessary to locate such portions of a randomly selected program.
For that reason, an intrusive virus has to target some program that resides
on a large portion of the target computer's installations, and that it is
certain will be available to tamper with when the virus introduction
occurs. That normally means either the Operating System, or some utility
program so common that it is found virtually every where. 

Operating System viruses work by replacing a portion of the Operating
System with their own code. This is similar to the intrusive type, except
that it can use a new trick (and there are ones that do this on the
IBM/MS-DOS computers). As a part of the operating system, it can sneak out
to a hard disk, find an unused part, mark it as defective, and hide there.
That would mean only a very small part of the code would have to be hooked
into the operating system (possibly as an entry in a list of device
initializing routines). That small segment could then allocate adequate
memory for the real routine, and load it from wherever. 

Source Code viruses - I found this type of virus to be a bit unbelievable.
The article reads (I quote): 

Source code viruses are intrusive programs that are inserted into a source
program such as those written in Pascal prior to the program being
compiled. These are the least-common viruses because they are not only hard
to write, but also have a limited number of hosts compared to other types.
(end quote) 

Sounds to me like this would be nearly impossible to accomplish in
after-market software. If, on the other hand, they mean a part of the
program added by a devious member of a development team, then, it is
credible. It brings to mind the story (which I can't verify, but I've heard
it from enough different sources to believe it is true) about what may well
have been the first virus. In case you're not familiar with "C" compilers,
they are usually several different programs, which must be run in proper
sequence, passing files and options from one to the next. Usually, this is
all done by a another program, a "compiler driver", which is almost always
called "cc". You execute "cc", passing it the necessary flags, and the
name(s) of the program(s) you want compiled, and it drives all the
necessary tasks to do it. 

This was reported to have been done by one of the originators of the UNIX
operating system, (name deleted), back in the development days at Bell
Labs. Well, the story goes, he wrote the first versions of UNIX, "C", and
"cc". He had a "back door" to get into a system running UNIX. He built the
back door code into "cc". The code in "cc" checked to see what it was
compiling. If it was the module "login", it incorporated the back door into
the module, so that he could get into the system. If, on the other hand, it
was compiling "cc", it included the code both to re-create itself, and the
code to build the back door into "login". So, every "cc" had the code, and
consequently every UNIX system included the back door. Eventually, it was
discovered, and removed. There followed a frantic rebuilding of every UNIX
system in existance, so the story goes. 

This is the final chapter which will be distributed via cross-posting.
Chapter 4 will relate specifically to viruses captured in the Atari ST
environment, and will be posted only to comp.sys.atari.st. It will come out
about 1 week after this one. This article was posted on March 13, 1989, so you
can determine the approximate delay to your receipt, in case you don't read
that newsgroup, but wish to locate the fourth chapter in comp.sys.atari.st. 

End of Chapter 3. 
-- 
*George R. Woodside - Citicorp/TTI - Santa Monica, CA 
*Path:       ..!{philabs|csun|psivax}!ttidca!woodside
From: woodside@ttidca.TTI.COM (George Woodside)
Newsgroups: comp.sys.atari.st
Subject: Virus 101: Chapter 4
Date: 21 Mar 89 13:40:56 GMT

Having discussed the way viruses work, spread, and can be deterred, the
only remaining topic is how to recognize when an attack occurrs. It is not
always as simple, or as straightforward, as it may seem. What may appear to
be a hardware problem may be a virus, and vice-versa.

There is no absolute way to determine if a given symptom is being caused by
a program error, a hardware error, a virus, or something else. Not all
viruses cause destructive attacks, but those that do are usually devastating.

When files start vanishing or becoming unreadable, it may be due to any of
several reasons. Poor media, or abuse of media is not uncommon. A dirty disk
drive head, or one drifting out of alignment can cause previously reliable 
disks to start producing errors. In the ST, there is the age old problem of
chip sockets and poor contact, and early versions of the ST had some component
reliability problems which could contribute to disk errors. Another source
becoming more frequent is the use of extended capacity disk formats, some of
which are not entirely reliable. There is also the potential of a real hardware
failure in the ST, or the drive. Finally there is the potential of a virus
attack. How do you tell? It's very difficult. 

Actually, the virus is the easiest to detect. Use your favorite virus detect
program, and start searching. If you can't locate one, then you problem could
be any from the list above. If you find one, you must be certain you have taken
every step available to you to insure it has been eradicated before accessing
your backups.

When the virus does not destroy files, what does it do? It's rather like
the age old "Where does a 600 pound gorilla sit?". Most anyhere he wants,
obviously. A virus can do most anything that any other piece of software can
do. The bigger the code segment of the virus, the more capable it can become.
There are some rather surprising things accomplished by the viruses already
found in boot sectors, when you consider that it has to accomplish its own
loading, spreading, and eventual attack in about 120 instructions. 

Some of the viruses currently spreading do nothing more than mess up the screen
display. When such an event occurs, it is not obvious that it is a virus
attack. It could be a momentary power fluctuation, a software bug of some
kind in the executing application, an intermittent hardware error, or any
of several other causes. The only hope of identifying the source as a virus
is, again, a methodic check of your disk library. 

Familiarity with the appearance of the attacks of known viruses would be 
helpful in recognizing when one is present. For that purpose, I have provided
the program "FLU". It is a demonstration program. It does not contain any of
the code present in any virus for the installation of the virus, or the
spreading of the virus. What it does contain is the non-destructive attack 
code of several viruses. These attacks are either audio or visual, so that
there is evidence of the attack occurring. There is no simulation of any of
the virus attacks which cause damage to disk data, since there is no way
to recognize when such an attack is occurring (and, of course, the purpose
of the program is to aid in recognizing the symptoms, not to destroy disks!).

"FLU" is absolutely safe. The program can be viewed as a simple novelty,
which does some strange display alterations. But by running it, and becoming
familiar with the symptoms it displays, you will be capable of recognizing
the characteristics of the attack of several current ST viruses. 

Two of the simulations, the "BLOT" virus and the "SCREEN" virus, attack in
a nearly identical manner. They step on a small portion of the screen. When
speeded up to display the symptoms, they have the appearance of drawing lines
from the top and bottom of the screen. However, when the attack occurs at the
speed at which the virus really operates, the attack would appear more like
a small blot appearing on the screen, since the screen would have most likely
been altered or redrawn by the application program between virus attacks.

The "FREEZE" virus is probably the most difficult of the non-destructive
viruses to recognize, since it is the most subtle. It takes over the
ST for an ever increasing period of time, causing a gradual slowing the 
machine. Again, the demonstration runs at a significantly higher speed than
the real virus.

This concludes the virus discussions. It has been the goal of these postings
to inform the general public of the way viruses spread, attack, and can be
dealt with. It is clear to me that, as a defense, ignorance has been 
unsuccessful.

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