textfiles/virus/virus101.vir

Portal-Rmail-To: garyt@cup.portal.com
Message-Id: <8904260606.AB12617@Sun.COM>
Date:         Wed, 26 Apr 89 02:02:37 EDT
From: Revised List Processor (1.5o) <LISTSERV@IBM1.CC.Lehigh.Edu>
Subject:      File: "V101 1" being sent to you
To: "Gary F. Tom" <sun!portal!cup.portal.com!garyt>

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

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
Portal-Rmail-To: garyt@cup.portal.com
Received: by portal.com (3.2/Portal 8)
	id AA13156; Wed, 26 Apr 89 01:38:23 PDT
Received: from Sun.COM (arpa-dev) by sun.Sun.COM (4.0/SMI-4.0)
	id AA18522; Tue, 25 Apr 89 23:07:59 PDT
Received: from sun by Sun.COM (4.1/SMI-4.0)
	id AB12617; Tue, 25 Apr 89 23:07:12 PDT
Message-Id: <8904260607.AB12617@Sun.COM>
Received: from LEHIIBM1.BITNET by IBM1.CC.Lehigh.Edu (IBM VM SMTP R1.2) with BSMTP id 5945; Wed, 26 Apr 89 02:02:46 EDT
Received: by LEHIIBM1 (Mailer R2.03A) id 5720; Wed, 26 Apr 89 02:02:42 EDT
Date:         Wed, 26 Apr 89 02:02:41 EDT
From: Revised List Processor (1.5o) <LISTSERV@IBM1.CC.Lehigh.Edu>
Subject:      File: "V101 2" being sent to you
To: "Gary F. Tom" <sun!portal!cup.portal.com!garyt>

Subject: Virus 101 - Chapter 2
From: woodside@ttidca.TTI.COM (George Woodside)
Newsgroups: comp.sys.atari.st,comp.sys.apple,comp.sys.mac,comp.sys.ibm.pc
Date: 6 Mar 89 14:00:21 GMT
Reply-To: woodside@ttidcb.tti.com (George Woodside)
Organization: Citicorp/TTI, Santa Monica

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
Portal-Rmail-To: garyt@cup.portal.com
Received: by portal.com (3.2/Portal 8)
	id AA13166; Wed, 26 Apr 89 01:38:31 PDT
Received: from Sun.COM (arpa-dev) by sun.Sun.COM (4.0/SMI-4.0)
	id AA18573; Tue, 25 Apr 89 23:08:58 PDT
Received: from sun by Sun.COM (4.1/SMI-4.0)
	id AB12617; Tue, 25 Apr 89 23:08:11 PDT
Message-Id: <8904260608.AB12617@Sun.COM>
Received: from LEHIIBM1.BITNET by IBM1.CC.Lehigh.Edu (IBM VM SMTP R1.2) with BSMTP id 5946; Wed, 26 Apr 89 02:02:49 EDT
Received: by LEHIIBM1 (Mailer R2.03A) id 5722; Wed, 26 Apr 89 02:02:45 EDT
Date:         Wed, 26 Apr 89 02:02:44 EDT
From: Revised List Processor (1.5o) <LISTSERV@IBM1.CC.Lehigh.Edu>
Subject:      File: "V101 3" being sent to you
To: "Gary F. Tom" <sun!portal!cup.portal.com!garyt>

Subject: Virus 101: Chapter 3
From: woodside@ttidca.TTI.COM (George Woodside)
Newsgroups: comp.sys.atari.st,comp.sys.apple,comp.sys.mac,comp.sys.ibm.pc
Date: 13 Mar 89 14:24:23 GMT
Reply-To: woodside@ttidca.tti.com (George Woodside)
Organization: Citicorp/TTI, Santa Monica

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
Portal-Rmail-To: garyt@cup.portal.com
Received: by portal.com (3.2/Portal 8)
	id AA13204; Wed, 26 Apr 89 01:40:03 PDT
Received: from Sun.COM (arpa-dev) by sun.Sun.COM (4.0/SMI-4.0)
	id AA18592; Tue, 25 Apr 89 23:09:17 PDT
Received: from sun by Sun.COM (4.1/SMI-4.0)
	id AB12617; Tue, 25 Apr 89 23:09:07 PDT
Message-Id: <8904260609.AB12617@Sun.COM>
Received: from LEHIIBM1.BITNET by IBM1.CC.Lehigh.Edu (IBM VM SMTP R1.2) with BSMTP id 5947; Wed, 26 Apr 89 02:02:52 EDT
Received: by LEHIIBM1 (Mailer R2.03A) id 5724; Wed, 26 Apr 89 02:02:48 EDT
Date:         Wed, 26 Apr 89 02:02:48 EDT
From: Revised List Processor (1.5o) <LISTSERV@IBM1.CC.Lehigh.Edu>
Subject:      File: "V101 4" being sent to you
To: "Gary F. Tom" <sun!portal!cup.portal.com!garyt>

Date:    Thu, 30 Mar 89 22:03 CST
From:    Gordon Meyer                                     <TK0GRM1@NIU>
Subject: Virus 101 chapter four

Subject: Virus 101: Chapter 4
To: info-atari16@score.stanford.edu

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

------------------------------