Skip to main content
? Erik 'ES of TEX' Simon, 1989

                             PART I
                 THE ULTIMATE VIRUS KILLER BOOK

                    2 - VIRUS CLASSIFICATION


virus,  n.  venom:  contagious or poisonous matter (as of ulcers,
etc.):  the transmitted cause of infection: a pathogenic agent, a
combination  of  chemicals,  but capable  of  increasing  rapidly
inside a living cell: any corrupting influence.
                            Chambers Twentieth Century Dictionary

 Viruses  (or virii,  or whatever you want to call them -  though
'viruses'  seems to be the word that is most commonly  used)  and
all  things  even  remotely connected with them  are  as  old  as
computers  are.  The  term 'computer virus' seems to  indicate  a
connection  with  biological viruses which is,  as  we  will  see
later, highly appropriate due to the striking similarities.
 In the early days of computing,  viruses and associated programs
predominantly  appeared on networks and large mainframe  systems,
but as time proceeded and home computers became more  affordable,
viruses also became known to lesser mortals like us.  More  about
that later.

 2.1      WHAT ARE VIRUSES?

 Indeed,  the word 'virus' in the term 'computer virus' has quite
some affinity with its biological counterpart. The latter infects
living cells,  in which they then manipulate the gene information
so  as  to cause those living cells to  start  reproducing  other
virus  cells  instead of their former,  healthy  selves.  A  very
clever  piece  of work of mother nature,  and all of us  have  no
doubt been confronted with it more than once - any common case of
cold,  for  example,  is a virus disease.  Other 'popular'  virus
diseases  are flu and,  indeed,  AIDS and the recently  re-arisen
Ebola.
 Computer viruses function very much like biological viruses, the
only  difference  being that they don't infect living  cells  but
'prey' on programs and floppy disks instead.

 Well...er...we  already knew that viruses can turn out  to  have
rather negative consequences for computer users, and we also know
that  they tend to copy themselves - or don't they actually  have
to  copy  themselves  to be called a  virus?  What  is  a  virus,
actually?
 A definition might be in order here.

 In his "Computer Viruses:  Theory and Experiments", published in
1984, Fred Cohen defines a computer virus as follows...

 "We  define  a computer 'virus' as a program that  can  'infect'
other  programs by modifying them to include a  possibly  evolved
copy of itself.  With the infection property,  a virus can spread
throughout  a computer system or network using the  authorisation
of  every user using it to infect their programs.  Every  program
that gets infected may also act as a virus and thus the infection
grows."


 Of  course,  this  description is  somewhat  outdated  now.  For
example,  bootsector viruses,  like we will see shortly, will not
infect other programs but other disks instead.  And the bit about
'user  authorisation'  is  also somewhat  vague  to  mere  humble
mortals like you and me.
 It is not the intention of this book to come up instead with  an
up-to-date description of what a virus might then be.  Apart from
the fact that many authors have already tried it - and that other
authors  later  always  changed  and  updated  them  -  this   is
completely  beyond  the scope of this  book.  Remember,  it  aims
primarily  to  tackle  the practical side  of  things.  There  is
limited use for theories and definitions,  so let's happily throw
them  in the bin and temporarily retrieve them only  when  really
necessary.
 All  you need to know is that viruses can infect other disks  or
programs quite autonomously by copying or appending themselves to
them  respectively,  and that most viruses contain a  destruction
routine
  that  can later be triggered by something.  It  is  also
important  to know that the destruction routine is likely  to  do
something  bad.   These  events  described  as  'something'  vary
independently from the virus you're dealing with and are  limited
only by the somewhat warped mind of the virus programmer.

 The  destruction  routines  are the main  reasons  why  computer
viruses  should  be got rid of.  They can principally  vary  from
harmless  operations such as changing the colours of your  screen
or  making  the  sound chip produce a bit of noise  right  up  to
rather  more  evil  proceedings such as  entirely  clearing  your
floppy  disk  or even formatting a partition of your  hard  disk,
with  just about anything conceivable in between. You  will  find
mention  of  more  specific  examples  of  destruction   routines
incorporated  in  the  descriptions  of  various   Atari-specific
viruses in appendix A.
 The destruction routine is usually not invoked immediately after
a virus is executed or once it has multiplies itself. As a matter
of fact,  the "success" of a virus can be measured by the time it
can  remain alive to produce copies of itself,  the time  it  can
continue to infect other disks or programs.  The longer it lives,
the longer it can multiply. The more copies it succeeds in making
of itself (with each copy creating yet more copies, and so on and
so forth in a distinctly exponential way),  the larger the damage
will  be when eventually it comes out of its  hiding.  And  until
that time a computer virus is invisible,  copying itself  without
the  user ever finding out anything about what's  happening.  The
moment the destruction routine is invoked, often the virus itself
ceases to be and can no longer multiply itself.
 That is why, usually, a trigger routine is built into a virus to
control  the moment when the destruction routine will be  called.
It generally assures the destruction routine is not invoked until
after  a  specified time or after a specified number  of  events,
such  as a specific date in your computer's  internal  clock,  or
having  reached  a  specific generation  number,  or  by  finding
certain  file  names on your storage  media.  Other  examples  of
trigger routine specifications can be found,  again,  in appendix
A.

 2.2      BOOTSECTOR VIRUSES

 The  kind of virus that is most widely spread on the  Atari  TOS
computer platform is the bootsector virus.  To understand what  a
bootsector virus is and how it works,  however,  one should first
know something about the way a disk is built up:  The disk format
of  Atari  TOS computers  (which,  incidentally,  happens  to  be
identical  to  that of MS-DOS machines).  We also  need  to  know
something  about  the machine's booting process and the  way  the
Operating System works.
 Please  have a look at figure 1 in the "pictures" folder  for  a
glance at what a disk format looks like,  in this case that of  a
standard Double Density disk.

 Figure 1 shows that a disk is divided in a number of  concentric
rings that are called tracks.  These tracks are again divided  in
parts that are called sectors. The number of tracks on a disk can
vary, though it is usually 80. The number of sectors per track on
Double  Density (DD) disks is usually 9,  but can vary up to  11.
High Density (HD) disks usually have 18 sectors per track, though
this can be increased to up to 22.  Extra High Density (ED) disks
in general have 36 sectors per track,  though this can run up  to
40.  There  is space for 512 bytes of data inside each  of  those
sectors.
 Double-sided  disks are built up identical on the  second  side;
thus,  double-sided  disks have each track  twice,  resulting  in
twice  as many sectors and,  correspondingly,  twice the  storage
capacity.

 Because the format of individual disks can vary (various  number
of  tracks,  sectors  and sides can  be  specified,  among  other
things),  a disk needs to have some way to 'tell' the disk  drive
and your computer what its specific amount of tracks, sectors and
sides  are.  That is why,  when a disk is being  formatted,  your
computer's Operating System writes that information on the disk's
bootsector,  the  first  sector on the first track on side  A  of
every  disk.  This  bootsector  is always at  the  same  location
irrespective  of what disk you are using,  so your  computer  can
always determine how the disk has been formatted.
 In  the  bootsector  there  is a  specific  area  that  is  used
exclusively to store these values in.  This segment is called the
BIOS Parameter Block (or BPB for short),  which takes up about 20
of the 512 bytes available in that sector.  The BPB is loaded and
analysed by the Operating System each time you insert a disk  and
the  Operating  System has to access it  (such  as  happens,  for
example,  when  it reads the the list of the files present  on  a
disk,  the  directory).  All  of this happens  automatically  and
rather quickly, without the user really noticing.

 When  resetting an Atari TOS computer or switching  it  on,  the
Operating System (TOS) immediately takes over control and  starts
installing all kinds of necessary things in memory - like  system
variables
,  a reserved space where the screen memory will be, and
lots more. Don't be confused by these names just yet as they will
be  explained later - and in case you haven't got  the  patience,
you may care to refer to appendix J, the glossary.
 This process,  anyway, is called booting, and it takes care of a
whole  lot of things before the GEM desktop actually appears  and
you can start using the machine (see appendix I for everything it
actually   does).    Again,   this   happens   quite   fast   and
inconspicuously.
 One of the many things booting takes care of is reading into the
computer's memory whatever is on the bootsector of the disk  that
is currently in the disk drive.  Once that's done successfully, a
checksum  of  the  512 bytes that have just  been  read  will  be
calculated.  Should  that checksum equal a hexadecimal  value  of
$1234, the Operating System will execute whatever program happens
to be loaded from the bootsector at that moment.
 Yes,  apart  from  the aforementioned BIOS  Parameter  Block,  a
bootsector may also contain a small program that will be executed
during booting, i.e. on boot-up. This possibility was included so
that  alternative  Operating Systems could be  loaded  this  way,
before  enormous  chunks  of  memory  would  already  have   been
allocated for use by GEM and the like.  Apart from the old  Atari
TOS 'on- disk' versions and alternative Operating  Systems,  many
commercial games and demos use this feature to load (hundreds  of
them,  actually).  Apart from the fact that this usually  assures
faster  loading,  the software companies or demo  crews  involved
often implement this as part of their software protection.
 Unfortunately,  the  flexibility  offered by  this  method  also
allows  for  less savoury little programs to  be  installed  into
memory such as, indeed, bootsector viruses. Instead of being used
to  load an Operating System,  game or demo,  the program in  the
bootsector  now  installs  itself  into  a  safe  spot  in   your
computer's memory,  makes itself resident and active by  patching
onto  a few Operating System vectors,  and gives control back  to
the computer as if nothing has happened,  the virus installed and
ready to strike.
 Safe spots?!  Patching!? Operating System vectors!? Strike?! All
will be explained forthwith. Just bear with me for a little while
longer.

 There are various safe spots in memory where a virus can  locate
itself  without there being much danger of being  overwritten  by
other  programs  that  may be loaded into memory  at  some  later
instance.  Only  a  part of your computer's RAM -  the  so-called
Transient  Program  Area - is used to actually load  and  execute
regular programs,  and basically viruses just make sure that they
locate themselves somewhere else.  There are plenty of small bits
of  memory  unused  by anything else in which a  virus  can  hide
itself.  After all,  especially bootsector viruses are usually no
bigger than 512 bytes, so that's all they'll need. An amount like
512 bytes is peanuts to the 524,288 bytes that even the most low-
spec 520 ST computer has,  let alone something like the 4,193,304
bytes that a 4 Mb system has.

 The next step we need to look at is the thing that was just  now
referred to as patching. To understand how this works, we have to
take  a  somewhat deeper look at how  your  computer's  Operating
System works exactly.
 A  large  part of the Operating System consists  of  small  sub-
programs that do very specific things.  There are,  for  example,
special sub-programs that set the colours, display a line of text
or even play a sequence of sounds.  There are also, however, sub-
programs that function to read a sector from or write a sector to
floppy disk.
 Because one such sub-program can be located at various different
addresses in your Operating System's ROM memory, depending on the
Operating System version you're using, some kind of method had to
be  developed to make sure that programmers would be able to  use
those  routines,  too,  without first having to find out the  ROM
memory  addresses  on which to find the sub-programs  they  would
want to use.
 What  Atari came up with,  basically,  was agreeing  on  certain
specially  documented  and  reserved memory  addresses  -  safely
outside  the Transient Program Area - that would  always  contain
the  ROM  memory  address for a  particular  sub-program  in  the
current  version of the Operating System.  The  Operating  System
itself,  upon boot-up,  would make sure the proper ROM  addresses
were stored there.
 These  specially  documented and reserved addresses  are  called
system variables or system vectors.  If the Operating System or a
regular  program wants to read a sector from disk,  for  example,
whether it is part of a bigger file or just on its own,  it  will
jump through the address contained on the specifically documented
system vector that will get access to the desired sub-program  to
read a disk sector.
 Besides     maintaining    inter-version    Operating     System
compatibility,  however, the whole setup involving system vectors
has another reason,  even more important.  You see, the Operating
System's  sub-program  to change the colours of  your  screen  is
quite  adequate for your machine's standard  graphic  resolutions
but  will  be  quite  improper if you  have  installed  a  better
graphics card that will yield a higher resolution,  for  example,
with more colours.  Similarly,  the sub-program to read a  sector
from  floppy  disk  functions  properly  but  it  is  not   quite
sufficient to handle other, larger media such as hard disks or CD
ROMs.
 To  allow  for the installation of extended  screen  drivers  or
similar  drivers for larger storage media,  system vectors are  a
necessity.  Suppose an extended screen driver is installed and  a
programmer 'tells' the Operating System, for example, to change a
colour.  It  will  jump  through the  address  contained  on  the
specified  system vector that would normally get to  the  desired
Operating System sub-program.  However,  when an extended  screen
driver is installed this causes the system vector not to  'point'
to  the  Operating  System's sub-program but to  one  within  the
driver software that,  unlike the original one,  will be able  to
handle a bigger screen resolution with more colours. Only when it
determines  the  screen is of regular dimensions with  a  regular
amount  of  colours  will it give back control  to  the  original
Operating  System's sub-program.  For this purpose it has  stored
the  original  address  it  found on that  system  vector  in  an
internal buffer somewhere.
 In a way much the same as described in the above example, a hard
disk  driver
  will  cause the system  vector  through  which  the
Operating  System jumps when it wants to access a disk sector  to
be  pointed  to the extended routines that,  unlike that  of  the
Operating  System,  can handle hard disks the way they ought  to.
And  only when the extended driver software notices it's  dealing
with  a regular floppy disk (this is easily done by  checking  if
the drive identifier is "A" or "B",  which are never hard  disks)
will  it  pass control on to the original  sub-program  contained
within the Operating System.
 The  people at Atari weren't lazy by not  implementing  extended
screen drivers themselves,  nor by not implementing right  within
the  Operating System the sub-programs that are needed to  use  a
hard   disk  and  a  CD  ROM.   They  were  merely  taking   into
consideration  the development of new storage media that  weren't
even  known at the time the Operating System  was  written.  They
tried to keep things as flexible as possible, and decided to keep
the Operating System down to the bare necessities.  Producers  of
extended hardware (whether graphic cards or larger storage  media
or whatever) were,  via the system vectors,  given the ability to
write their own specific routines.
 I hope you're still with me.  Maybe it will console you if I say
that you have now behind you probably the most difficult part  of
the entire "Ultimate Virus Killer Book".  It  was,  incidentally,
also the most difficult to write.

 Bootsector viruses would, logically, benefit from 'knowing' when
your  computer  is accessing the  disk  drive;  they  could,  for
example,  copy themselves to the disk currently in the drive when
they  notice that the Operating System is writing to  or  reading
from  that disk anyway.  So what a bootsector  virus  does,  when
installing  itself,  is  make  sure the system  vectors  for  the
various disk-associated sub-programs point to a small part within
itself  instead  of to the addresses originally  present  on  the
system  vectors  (which would point to  sub-programs  within  the
Operating System or an extended storage media  driver,  usually).
The  virus would now,  whenever a disk-associated sub-program  is
called either by a program or the Operating System,  get executed
before  anything else and check if it wants to copy to  the  disk
currently in the drive and, if needed, do so. And, of course, the
virus will have stored elsewhere within itself the old  addresses
so   the  originally  intended  sub-programs  will   be   invoked
immediately once the virus has finished whatever it needed to do.
The  delay will only be minimal and will,  certainly when  you're
not paying special attention, go by unnoticed.

 You  will have noticed that bootsector viruses can only work  if
they're  in  memory  all the time,  in  other  words  if  they're
resident.  You can load other programs and quit them  again,  but
bootsector viruses will remain in memory once they have installed
themselves.  They won't disappear until someone resets the system
or  turns it off.  Principally,  that means we're supposed to  be
talking  about  resident bootsector viruses.  As  all  bootsector
viruses  on  TOS computers are resident in some way  or  another,
this  full name is usually not specified (and therefore will  not
be here, either).

 Bootsector  viruses also exist on a variety of other  computers.
The only things that usually differ from the principles mentioned
above (apart, of course, from the actual program code that has to
be  suitable  for the machine's actual main  processor)  are  the
checksum   values,   bootsector  sizes  and  the  system   vector
addresses.  On MS-DOS,  by the way,  all bootsectors are executed
regardless their checksum. Most MS-DOS bootsectors contain a very
small  program  that  displays "This is not  a  system  disk"  or
something along similar lines.
 More  about  viruses on other computer systems can  be  read  in
chapter 3.

 2.2.1    RESET-RESISTANT BOOTSECTOR VIRUSES

 There are two specific kinds of bootsector viruses, of which the
first  is  the reset-resistant variety (reset-resistant  is  also
often called reset-proof).  To fully understand what this  means,
it must first be explained what 'reset-resistant' actually  means
and what programs have to do to be classified as such.
 Reset-resistant   means  that  the  program  in  question   will
'survive' a soft reset.  A soft reset is performed when you press
the  'reset' button on the back of your  computer,  an  operation
that  can  also be performed by pressing  [CTRL-ALT-DEL]  on  TOS
versions 1.04 and up.  During this reset, most of your computer's
memory will be cleared and the system will again appear as if  it
has just booted. Its counterpart, the hard reset, by the way, has
one  difference:  It clears all your computer's  memory.  A  Hard
reset  is performed whenever you turn on your  system,  or  press
[CTRL-ALT-DEL-RIGHT  SHIFT]  on  newer  TOS   versions.   Nothing
survives a hard reset, not even a virus that is reset-resistant.

 There  are  two ways to make a program survive a soft  reset  on
your computer:  The legal and the illegal one.  Both of them have
been built into the Operating System by Atari  themselves.  After
all,  they reckoned,  there may be perfectly valid reasons for  a
program to have to survive a soft reset, so that's why provisions
were  built in to assure that such can be achieved.  One  of  the
methods  is  referred  to as 'legal'  because  it  is  officially
documented and will not change in possible future versions of the
Operating  System.  This  on the contrary to the  'illegal'  way,
which  has  never really been officially documented  even  though
many  people  know  about it.  Although the  illegal  method  has
continued to be supported in all TOS versions up to and including
Falcon  TOS 4.04,  it is still not official and might  vanish  if
Atari ever decide to make a new Operating System version.
 A  valid  program  that might want to make sure  it  -  and  its
contents - would remain intact after a soft reset,  for  example,
is  a reset-proof RAM disk.  This RAM disk,  basically a  virtual
disk drive in your computer's memory,  could then survive a  soft
reset  with  all files stored in it left intact.  If  it  weren't
reset-proof,  all  those  files would be lost upon a  soft  reset
being performed.

-----------------------------------------------------------------
             Hexadecimal address:           Name:
-----------------------------------------------------------------

             $426.L                         Resvalid
             $42A.L                         Resvector

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

          System variables for 'legal' reset resistance

 When  your system is reset (in other words during  booting,  see
appendix I),  at a certain stage the Operating System will  check
the  resvalid system variable (four bytes at hexadecimal  address
$426),  and look if there is a so-called 'magic' longword  stored
there.   When   this  'magic'  longword  happens  to  contain   a
hexadecimal value of $31415926 (the first eight numbers of  "pi")
it  will  not continue the rest of the regular  Operating  System
reset  sub-program but instead first jump to the  memory  address
contained on the resvector system vector.
 A  reset-resistant application,  now,  would cause  resvalid  to
contain  that  specially documented  magic  longword,  and  cause
resvalid  to point to a segment within itself that makes sure  it
is safeguarded before the old reset sub-program is called.
 During a soft reset,  by the way, not all memory is cleared. So,
basically,  a  virus  only  needs to make sure  that  it  is  re-
installed in a previously cleared patch of memory and the  system
vectors  correspondingly  patched  again.  All  of  this  happens
quickly and smoothly,  so it will appear once again as if nothing
out of the ordinary has happened.

 The illegal way, the non-officially documented method, is rather
more complex. Somewhere in its reset routine, after having booted
from floppy or DMA (hard disk),  the Operating System will  check
all  RAM memory locations at 512-byte intervals starting  at  the
physical top of RAM memory and going down to hexadecimal  address
$600  inclusive  to see if it finds there another  one  of  those
'magic'  longword  values,  in this case a  hexadecimal  longword
value  of  $12123456.  If this is  found,  the  Operating  System
performs another check to see if the next longword value contains
the address on which the $12123456 value was found.  When this is
found,  too,  it performs a third check by calculating a checksum
for  the 512-byte part of memory starting at the memory  location
where the magic longword was found.  If the checksum is equal  to
$5678 hexadecimal,  it will invoke whatever program code it finds
at the magic longword's address + 8.

-----------------------------------------------------------------
  Address (hex):           Contents:
-----------------------------------------------------------------

  $600                     $12123456        ----+
  $604                     $00000600            |
  $608                     Start of program     \
                                                Checksum of $5678
  ....                                          /
                                                |
  $800                     End of program   ----+

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

             Non-documented reset-resistant: Example

 You see that these three special checks are very much similar to
the function of resvalid, explained earlier. Instead of something
similar to resvector, though, the Operating System just expects a
program at a specific memory address and calls that.  Again, this
program  would re-install the virus on the place in memory  where
it   wants  to  be  and  patch  the  necessary   system   vectors
accordingly.
 The bottom line is that, no matter which of these two methods is
used, viruses can be made to survive a soft reset.

 2.2.2    NON-EXECUTABLE BOOTSECTOR VIRUSES

 Earlier,  we  already learned that a bootsector needs to have  a
special checksum of $1234 in order to be executable and to  cause
a program contained within that bootsector and loaded into memory
to run.  We also learned that this was the way bootsector viruses
got  loaded and installed into memory.  However,  there are  also
bootsector  viruses  that don't even require a bootsector  to  be
executable: Non-executable bootsector viruses.
 To  many of you this will sound like some kind of  contradiction
in terms - as indeed it did to me when I first heard of it. If we
have  a closer look at the booting process  once  more,  however,
things will suddenly become much clearer.
 On  start-up,  as was already mentioned before,  the  Atari  TOS
loads in the bootsector of the boot device (floppy-or hard  disk)
and then looks if the checksum of that equals $1234.  If it does,
the bootsector is executable and a JSR (Jump to SubRoutine)  will
be  performed on it.  This results in the program present in  the
bootsector being executed (and thus,  should a virus be contained
there,  for  it to be installed).  Nothing new  there.  But  what
happens exactly when the bootsector is not executable?
 The system now has a copy of the bootsector's contents still  in
memory,  starting  at the memory address contained in the  system
variable called _Dskbufp, an address at which is located the disk
buffer
.  Even  though  the  program in this  bootsector  has  not
actually been executed, it is still there. And because all memory
was  already  cleared  at a much earlier  stage  of  the  booting
process, it is in no danger of being erased.
 Next,  the Operating System starts to do its check for  programs
that  are reset-resistant in the undocumented way,  such  as  was
explained in 2.2.1.  This check also includes the part of  memory
where  the  disk buffer is located - the part of memory  where  a
copy  of  the  bootsector's  contents  now  resides.   Because  a
bootsector  is 512 bytes in size and the Operating System  checks
for programs that are reset-resistant in the undocumented way  at
512-byte intervals,  it will always check for that special  magic
$12123456 value somewhere within the disk buffer.
 If  a virus makes sure a $12123456 magic longword is located  on
the exact 512-byte interval that the Operating System happens  to
check  while it's within the disk buffer area,  it's well on  its
way to being executed.  And if it also makes sure the two further
criteria listed in 2.2.1 are met, it will be executed.

-----------------------------------------------------------------
TOS version:            _Dskbufp: Offset off $200 page boundary:
-----------------------------------------------------------------

 TOS 0.00 (Das Boot TOS)   $12BC           Not applicable
 TOS 1.00 (Old or ROM TOS) $167A          -$186 off $1800
 TOS 1.02 (Blitter TOS)    $16DA          -$126 off $1800
 TOS 1.04 (Rainbow TOS)*   $181C          -$1E4 off $1A00
 TOS 1.06 (STE TOS Rev 1)  $181C          -$1E4 off $1A00
 TOS 1.62 (STE TOS Rev 2)  $181C          -$1E4 off $1A00
 TOS 2.02 (MEGA STE TOS)     ?
 TOS 2.05 (MEGA STE TOS)   $1410          -$1F0 off $1600
 TOS 2.06 (ST Book TOS)    $16E8          -$118 off $1800
 TOS 3.01 (TT TOS 030)     $1630          -$1D0 off $1800
 TOS 3.05                  $1630          -$1D0 off $1800
 TOS 3.06                    ?
 TOS 4.01 (Falcon)         $1CC6          -$13A off $1E00
 TOS 4.02 (Falcon)         $1CC6          -$13A off $1E00
 TOS 4.04 (Falcon)         $1CC6          -$13A off $1E00

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

         _Dskbufp addresses with different TOS versions
                   * = Also goes for KAOSdesk

 Suppose  a virus will want to work on the Falcon,  which  always
has its disk buffer located at memory address $1CC6.  As you  see
in  the  above  column,   that  means  that  the  next   512-byte
(hexadecimal $200) interval that falls within the disk buffer  is
located  at  $1E00,  meaning  that  the  actual  $12123456  magic
longword  will  need to be present at offset  $13A  ($1E00  minus
$1CC6)  within  the bootsector for it to be  encountered  by  the
Operating  System at the exact 512-byte interval within the  disk
buffer where it needs to be to work.
 Using this technique,  viruses can get themselves installed into
your  computer's  memory  even when a disk's  bootsector  is  not
executable.  This  is  especially dangerous  because  many  virus
killers and other pieces of virus detection software only  notice
anything in a bootsector after it's found to be executable in the
first place. It is easy to imagine such non-executable bootsector
viruses  going around and spreading prolifically  without  anyone
noticing them for quite a long time.
 Due to lack of contiguous space in a bootsector infected by such
a non-executable bootsector virus,  they often use whatever space
there is left just to load in some more sectors which contain the
rest of the actual virus program.  To see where these  additional
sectors may be stored, please refer to 2.4, "Call Viruses".

 2.3      LINK VIRUSES

 The second virus type is the link virus,  not to be mistaken for
what  some other publications about viruses call a  'link  virus'
and which refers to a virus included in the linker of a  compiler
program,  that  automatically  infects programs that  are  linked
using  that  compiler (see 2.8,  "Source-and  Compiler  Viruses",
below).

 The  link virus type is harder to find than a bootsector  virus,
difficult  to  recognise  and  virtually  impossible  to  destroy
without damaging the program it is attached to,  because the link
virus does not write itself to a bootsector but merges itself  to
an actual program file on disk
.  It is then executed (and it  may
multiply itself) each time such an infected program is loaded and
run.
 Since  the  link virus is not restricted to the mere  512  bytes
usually available to a bootsector virus,  it can be as big as the
programmer needs it to be.  It can potentially do things that are
quite repulsive. It can do virtually anything, actually.

 Using the "file layout" table,  below, we can have a look at the
structure  of  a program file (program files generally  have  the
extensions ACC,  PRG,  TTP, APP, TOS or GTP). This will help when
trying to see how link viruses work.

-----------------------------------------------------------------
              File header (offset $0-$1C exclusive)
-----------------------------------------------------------------
                          TEXT segment
                    (the actual program code)
-----------------------------------------------------------------
                          DATA segment
-----------------------------------------------------------------
                   BSS (Block Storage Segment)
-----------------------------------------------------------------
                          Symbol table
-----------------------------------------------------------------

               File layout (top is start of file)

-----------------------------------------------------------------
       Offset:         Contains:
-----------------------------------------------------------------

 $00             BRA.S ($601A; BRanch Always instruction,
                  jumps to $1C)
 $02             Bytes in text segment
 $06             Bytes in data segment
 $0A             Bytes in BSS (Block Storage Segment)
 $0E             Bytes in symbol table
 $12             Zero (reserved)
 $16             ph_flag (longword)
                 ST/STE/TT/Falcon:
                 Bit 0     = Fastload on/off
                 TT only:
                 Bit 1     = Load program into TT RAM
                 Bit 2     = Use TT RAM only
                 ST/STE/TT/Falcon, sensible with "MultiTOS":
                 Bit 3     = Reserved, always 0
                 Bit 4-7   = Default memory protection mode
                             None set = Private
                             Bit 4    = Global
                             Bit 5    = Super
                             Bit 6    = Readable
                 Bit 8-11  = Reserved, always 0
                 Bit 12    = Share text segment on/off
                 Bit 13-27 = Reserved, always 0
                 Bit 28-31 = Minimum amount of TT RAM needed
                             (value * 128) in Kb
 $1A             Zero if no relocation bits
 $1C             Start of program text segment
                 (The BRanch Always makes sure it is started)

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

                      File header contents

 When a link virus appends itself to a program (links itself to a
program,  hence the name),  it usually stores itself between  the
TEXT and the DATA segment of a file, as well as at the very start
of  a  file.  This principally means that the TEXT  segment  and,
thus, the total program file itself, become longer (exceptions to
this rule are substitute link viruses, see 2.3.6).
 The  link  virus changes the program's file header so  that  the
Operating  System recognises the new length of the  TEXT  segment
for  when  the file is being loaded and executed  at  some  later
instance.
 As  soon as an infected program has been loaded and executed  by
GEMDOS,  the  little  bit of the virus at the start of  the  TEXT
segment  will  be  executed.  This will then cause  to  virus  to
multiply and,  if necessary,  install itself elsewhere in memory.
After that it will change back the original file header,  restore
the beginning of the TEXT segment where it had stored itself and,
last, execute the original program as if nothing has happened.
 Especially on floppy disk,  running a file that is infected by a
link virus will take noticeably longer.  After all, the virus has
to  find another file,  then search for the  DATA  segment,  copy
itself  to it (increasing the file length),  buffer the start  of
the  original program code and patch itself to the program  start
routine before the original program even gets as much as a chance
at  getting  executed.  In this case,  it is relatively  easy  to
recognise link virus infection.
 On top of that,  most link viruses use regular Operating  System
calls to open another file,  read from it and write to it. Should
your disk be write-protected,  for example,  their use of regular
Operating  System  calls will cause a display of a  "Disk  Write-
protected;  please remove write-protect" alert box. Programs that
suddenly  attempt  disk  accesses whereas  they  never  did  this
before,  especially at start-up,  are surely worth checking  with
the "Ultimate Virus Killer"!

 There  are  two  ways of classifying  link  viruses:  The  first
classifies  them according to their behaviour in  the  computer's
memory (2.3.1 - 2.3.3), the other according to their behaviour in
infected  files  (2.3.4  -  2.3.5).   In  the   following,   both
9[...................................................]0110
classifications are used independently.

 2.3.1    NON-RESIDENT LINK VIRUSES

 There  are two possible ways for a virus to manifest  itself  in
memory.  The first type,  the non-resident link virus, is the one
that is least complex and that spreads slowest.
 Upon  starting a program infected by a non-resident link  virus,
the virus executes itself and infects one (or,  indeed,  several)
files  on  the  disk.  After checking if the  condition  for  the
destruction routine to be executed is true, it calls it or simply
leaves  again,  jumping  back  to the original code  of  the  old
program (i.e.  the program it was located in, which it has in the
mean  time restored in memory),  at which time the  virus  itself
will have disappeared from RAM completely.
 This  is  called  non-resident  as the  virus  does  not  remain
(reside) in memory at all after it has fulfilled its purpose.

 2.3.2    RESIDENT LINK VIRUSES

 The  other  type  of  link virus is  the  resident  link  virus,
sometimes also called interrupt virus. This differs from the non-
resident
  link  virus  by  the fact that  it  remains  in  memory
starting at the moment it does its job for the first time.
 As with bootsector viruses, the resident link viruses patch some
Operating  System  vectors  to point to  their  own  sub-programs
before executing the ones the Operating System actually wanted to
access in the first place. Whereas the bootsector virus varieties
need to 'know' when a disk sector is being accessed, the resident
link virus varieties have more benefit from 'knowing' whenever  a
file  is opened or loaded into memory so that they  can  promptly
infect  whatever  file is currently  being  accessed.  The  basic
difference  between resident bootsector viruses and link  viruses
is that they patch different system vectors;  link viruses  patch
system vectors that point at the Operating System's  file-related
sub-programs such as those needed to open a file, change a file's
status, or create/load a file.

 Resident  link viruses can spread a lot faster than  their  non-
resident counterparts:  Each time when another program is  loaded
after  your  system  has been  infected,  this  program  will  be
infected automatically,  too.  Even when the originally  infected
program has been removed from memory (usually by exiting it), the
resident link virus program parts are still in memory  somewhere.
This  means that resident link viruses can also  infect  programs
that  are  in  a different (sub-)directory of  a  disk  or  drive
partition,  or even on a totally different disk.  Especially  the
latter is usually impossible with non-resistant link viruses.

 2.3.3    RESET-RESISTANT LINK VIRUSES

 The  more persistent variety of the resident link virus  is  the
reset-resistant link virus.  This is not only resident,  but also
survives  a  reset using one of the methods described  in  2.2.1.
Therefore, it is even more dangerous than the 'ordinary' resident
link virus, and will be even more prolific at spreading itself.

 2.3.4    OVERWRITING LINK VIRUSES

 Now that we have gone through a link virus classification  based
on  the  way  they behave themselves  in  memory  after  infected
programs having been loaded and run,  let us now have a look at a
classification  based on the ways they behave  themselves  within
the  infected  file,   before  they  get  executed  by  the  user
unwittingly loading the contaminated program.

 A division can be made into two kinds, of which by far the least
complex would be the overwriting link virus. This link virus does
not  bother  about placing itself somewhere between some  of  the
program  segments,  buffering the program part  it  replaces,  or
changing any of the values contained in the program  header.  No,
this type of link virus just writes itself right across a part of
the original program file, hence its name.
 Overwriting link viruses are quite rare because they are quickly
noticed - a program file infected with one will no longer work at
all - and can,  consequently, be battled quite effectively. It is
far  simpler  to design and program such  an  overwriting  virus,
however,  because  the  programmer would not need  to  take  into
consideration all the things that were mentioned before.

 Files  that are infected with this type of link virus can  never
be repaired;  not by the "Ultimate Virus Killer" nor by any other
virus killer anywhere on any system (not even if they claim  to).
This  can  be  explained by the fact that part  of  the  original
program,  which  would be needed to restore the file to its  full
(non-infected) working order,  has disappeared altogether and can
thus impossibly be restored.

 2.3.5    NON-OVERWRITING LINK VIRUSES

 All  link viruses that don't overwrite part of the program  they
infect  are called non-overwriting link viruses,  which form  the
majority of the link viruses existing on any computer system.
 The  trick of the non-overwriting link virus is that it  buffers
all  parts  of the program it infects that would  otherwise  have
been overwritten.  That way it can restore all these parts  after
it  has  done  its job,  allowing the  original  software  to  be
executed properly so that the user does not notice  anything,  at
least  not until it is too late and the virus has already  spread
itself.
 Below you will see a diagram of a non-infected file, followed by
one  of  the same file infected by a non-overwriting  link  virus
(file start at the left).

 The  original program in this case consists of a program  header
(H),  a  TEXT segment (here divided in two  hypothetical  blocks,
TEXT 1 & 2), a DATA segment (DATA) and a BSS (BSS). When the link
virus  infects the file,  it buffers a part of the  TEXT  segment
(TEXT 1),  writes a piece of its own code which replaces it (V1),
and  then  writes its second part with the buffered part  of  the
TEXT  segment (V2 & TEXT 1) between the TEXT and  DATA  segments.
The  contents of the program header are changed to match the  new
length of the TEXT segment.

          ---------------------------------------------
          |H| TEXT 1 & 2 | DATA        | BSS          |
          ---------------------------------------------

  ------------------------------------------------------------
  |H| V1 | TEXT 2 | V2 & TEXT 1 | DATA        | BSS          |
  ------------------------------------------------------------

              Non-overwriting link virus infection

 When  the  infected file is loaded and run,  first  V1  will  be
executed.  This will execute V2, which will do whatever the virus
does (copy itself,  make itself resident, do something nasty...),
then restore TEXT 1 to its original position,  copy the  DATA-and
BSS segment back to their original offsets in memory and  execute
TEXT  1.  The actual program will then be started as  if  nothing
happened.

 Non-overwriting link viruses,  I think you'll readily agree with
me  on the grounds of the evidence presented so far,  are  a  lot
more   difficult  to  write  than  their   overwriting   cousins.
Unfortunately,  however,  type-in listings and construction  kits
for these non-overwriting link viruses have appeared from various
sources. With the aid of these it has been made easy for even the
most utter laymen to successfully create link viruses.
 The one 'good' thing about non-overwriting link viruses is  that
they can be spotted by suddenly increasing program file  lengths,
unless...

 2.3.6    SUBSTITUTE LINK VIRUSES

 There  is  in  fact  another link  virus  type  that  should  be
mentioned:  The substitute link virus,  which is basically a non-
overwriting  link  virus that does not change the length  of  the
programs it infects,  as opposed to regular non-overwriting  link
viruses which, as we know, make a file longer.
 Substitute link viruses use compression techniques (also  called
compacking,  packing,  crunching or compacting,  among many other
names)  to make sure that the original file length a program  had
before  infection is reached again.  This  way,  substitute  link
viruses significantly decrease their chance of discovery  because
they  cannot  get detected by suddenly  increasing  program  file
lengths.
 Substitute  viruses  seem  quite,   well,  'popular'  on  MS-DOS
systems.  On Atari TOS computers, however, they seem not to exist
outside the realms of rumour.

 2.4      CALL VIRUSES

 In 2.4 to 2.10,  a couple of virus types will be mentioned  that
have  arisen from various different virus  classifications.  They
are  included  here for the sake  of  completeness.  Principally,
however,  they can be classified as specific types of bootsector-
or link-viruses mentioned so far.

 The principle of the call virus is simple:  It stores a  segment
of itself elsewhere,  to be called and used later.  In case of  a
bootsector  virus  this usually means it has  additional  sectors
apart  from the bootsector elsewhere on a disk in which  more  of
its program code is stored;  in the case of a link virus it means
that there are parts of the virus not within the infected program
file  itself but instead located either in additional sectors  or
in a hidden file.
 The  advantage  for a bootsector virus is that it can  now  have
access  to more space for its program code (and potentially  more
elaborate destruction routines) to be located in.  Especially  in
the  case of non-executable bootsector viruses  (see  2.2.2),  in
which  there  is  preciously  little space  left  in  the  actual
bootsector,  this  is the required way out.  The advantage for  a
link  virus  is that part of it does not need to be  appended  to
each infected file,  causing a diminished file size growth and  a
shorter infection time.

 A  call virus will need to find some way to make sure  that  its
external segment is not overwritten by other files on the disk. A
call  virus  with its external program code  destroyed  would  be
quite harmless or would simply crash.
 The  most  straightforward way would be the use of  an  external
file. It would be just like any other file on your disk, only its
"hidden"  attribute (similar to the "read only" one that you  may
be  more  familiar with) would be switched on.  Both  MS-DOS  and
Atari  TOS  computers have this facility built  into  their  file
management system.  A "hidden" file is present on the disk,  like
any other file, but will not be displayed when double-clicking on
a drive icon to display its list of files, its directory.
 A rather less straightforward way,  primarily used by bootsector
call viruses,  is the principle of hidden disk sectors. This is a
bit  more complicated than the hidden file,  as it requires  that
the  virus  find  some  extra sectors  on  a  disk,  besides  the
bootsector,  that are in some way safe from later write access to
that disk.
 When a disk is formatted,  certain of its areas will be reserved
and cannot be used to store files on.  The bootsector is such  an
area,  for example, but there are also the FAT and the directory,
generally taking up the first two tracks on a disk. The directory
is  needed  to  keep track of which files are in  a  disk's  root
directory,  when they were created,  how long they are, what file
attribute they have and at which disk sector they start.  The FAT
(the File Allocation Table, of which two copies are maintained on
each  disk)  keeps track of the order in which disk  sectors  are
allocated  to files,  as disk files need not necessarily take  up
contiguous sectors only.
 An  entire track is set aside for the  FAT  and,  similarly,  an
entire track is allocated for the disk's directory. But there are
a few sectors that are not used just after each of the two copies
of the FAT,  and if you don't have too many files and/or  folders
in your root directory there are quite a few sectors available at
the end of the track that is allocated for that, too.
 Call viruses are known to use,  for example,  the last directory
sector  to store extra information or program code  in.  And  the
'spare'  sectors of the 'backup' copy of the FAT are  also  quite
popular.  In case of a long directory,  infection by a call virus
may  cause  part  of  your disk's file  list  to  be  demolished,
rendering those files inaccessible and unsalvageable.  The  other
way  around,  however,  writing more files to a disk so that  the
entire  directory list is filled up would also destroy  the  call
virus' external segment, rendering the virus quite harmless.

 The  FAT does more,  though,  than just keeping track  of  which
sectors belong to which files and in which order.  When a disk is
formatted, the Operating System also checks to see whether any of
the formatted tracks and sectors are damaged or faulty, i.e. bad.
After  all the tracks have been formatted,  the Operating  System
installs the default FAT and an empty directory, and it will mark
any  bad sectors in the FAT as 'used' bad sectors so  they  won't
ever be used again to attempt to write files onto.
 Call  viruses can 'simulate' these bad sectors;  their  external
segments would be written to specific disk sectors,  after  which
the  virus would mark these as 'bad' in the disk's FAT.  The  end
result would be the same as the methods described above, but even
safer insofar that not even an extra long directory, for example,
could damage the call virus' external program code.
 In a way similar to the simulation of bad sectors,  call viruses
can also just allocate the extra disk sectors they use to a  non-
existing  file,  this  way generating what is known  as  a  'lost
cluster'.

 2.5      BOOT VIRUSES

 A boot virus, is, quite simply, a link virus (either overwriting
or non-overwriting,  resident or non-resident) that only  infects
the  boot  file  of  MS-DOS  machines,   usually  a  file  called
"COMMAND.EXE". Not to be mistaken for a bootsector virus.
 This virus type is only useful on MS-DOS computers, as Atari TOS
computers use no boot file as such.

 2.6      BUFFERED VIRUSES

 Principally,  any  known virus type can be a  buffered  virus. A
buffered  virus is a virus that is not only  resident,  but  that
also  finds  a way of making sure that it survives  even  if  the
computer which it has infected is turned off.
 Luckily, this is only possible with computers that have battery-
backed  RAM or battery-backed clock cards with some RAM of  their
own.  When the system is turned off,  the batteries will  prevent
the RAM from being erased (hence the term battery backed).  Also,
many  portable  computers  using CMOS  RAM  chips  actually  only
disable  the display when you switch them off.  This  makes  sure
that everything in memory, viruses included, remains intact.
 Atari  TOS  computers have no battery backed RAM  except  for  a
'massive'  128  bytes  somewhere  in  the  intelligent   keyboard
processor (the HD 6310 chip or something like that) in MEGA  STs,
MEGA  STEs,  TTs  and Falcons only.  This hardly suffices  for  a
virus, so we need never worry (see 5.3).
 Should  you  worry anyway,  you can simply  remove  the  battery
during power-off and you will be perfectly safe.  Insert it again
after thirty seconds.

 2.7      BATCH VIRUSES

 MS-DOS  computers without "Windoze" or a similar graphical  user
interface  have a so-called CLI (Command Line  Interface),  which
allows  the user to type in a certain command which will then  be
executed. Whereas we, fortunate TOS computer users, use the mouse
and  the  desktop to format a disk,  copy files or  generally  do
anything in a very user-friendly way, MS-DOS CLI-based life forms
have  to  enter  long  lines of  extensive  syntax  with  a  load
parameters  instead.  Have  a  look at the  full  syntax  of  the
"format" command, for example...

 dc:padc\FORMAT d: /S /1 /8 /V /B /4 /N /N:ss /T:ttt

 If  you add a couple of such instructions together (there are  a
lot more different ones than just the FORMAT command,  of course)
and  write them into an ASCII text file with the extension  .BAT,
you have created a so-called batch file.  Typing the name of that
batch file at the CLI prompt suffices to execute all the commands
that  you have entered in that text file.  Some of you  may  know
this principle from the various shell programs that are available
for your computer ("COMMAND.PRG",  "NeoDesk CLI", "Gemini" built-
in  CLI,  Michtron's "Shell" utility and "Gulam",  to name but  a
few).
 Viruses that manipulate these batch files are,  quite logically,
called  batch  viruses.   As  MS-DOS-type  CLI  commands  include
commands like FORMAT and DELETE, a batch virus by no means has to
be harmless. It can even multiply itself.
 The good thing about batch viruses is that they are quite easily
recognised,  as  a  batch file's contents can  be  displayed  and
examined on the screen with the MS-DOS TYPE command.
 As  Atari TOS computers normally do not use a CLI (though  these
so-called shells are available in quite an abundance both in  the
Public Domain and commercially),  batch viruses do not have  much
of  a  chance.  On MS-DOS  computers,  however,  they  are  quite
notorious.

 2.8      SOURCE CODE-AND COMPILER VIRUSES

 It  is quite difficult to get to grasps with how  these  viruses
are supposed to be able to spread, how they are built up, and how
it is possible that they exist.
 Compiler  viruses,   also  sometimes  confusingly  called   link
viruses
,  are  pieces of source code that will  automatically  be
included  in  any  given program  when  compiled.  Sounds  rather
complicated,  whereas  it sounds rather impossible that they  can
live  on  as actual pieces of source code after  actually  having
infected  another  program.  This would mean  that  the  infected
program  would  get considerably longer (as source  code  is  not
quite compact). Such a virus would be easily noticeable.
 Probably,  these viruses can only be built in by people actually
making  compilers,  or maybe people that know how a  compiler  is
built up,  disassemble it,  patch it, and assemble it again. This
means  that  there  seems to be a fair way  of  evading  them  by
avoiding   pirated  copies  of  these   programs,   as   official
manufacturers  would rather not have their name  dragged  through
the  dirt by spreading viruses on their own accord in  their  own
commercial programs!
 Lucky for us,  they have not been sighted on TOS systems and  it
is  to be doubted sincerely whether they ever will,  although  it
would  be conceivable that they could spread  via,  for  example,
Public Domain C library extensions of some sort.
 Source  code  viruses  are  easier  to  write,   and  are  often
variations  on  the  call  virus  theme.  High-level  programming
languages  can  be  used  to write  them  (even  Basic,  Lisp  or
Prolog!),  and  they  are only difficult to  recognise  when  the
original  (non-infected) source code is quite  big.  Source  code
viruses, however, have never been seen on TOS computers, either.

 2.9      XP VIRUSES

 XP  Viruses,  sometimes also called line viruses,  are a  really
tough  cookie.  They  are possible only within  so-called  Expert
Systems
. There is not much to tell about these viruses that would
be  of any practical use to you,  and truly explaining  how  they
work would take up too many pages.
 Also, let's be honest, I don't know anything about them.
 To  whet  your appetite,  it can be mentioned that they  can  be
dangerous  in Hospital's disease analysing systems and that  they
multiply inside a program, generally manipulating all lines of an
Expert System, quite inconspicuously causing it to malfunction.

 2.10     ENCRYPTING VIRUSES

 Suppose you would get infected by a virus.  You could get rid of
it using a virus killer, right? Right.
 Suppose you would get infected by an encrypting virus.  Upon  it
infecting  your  system it would encrypt your  hard  disk's  FAT,
causing  you to be able to work with your hard disk only as  long
as you're still infected
.  You could get rid of it using a  virus
killer,  right?  Indeed  you  could,  but your  hard  disk  would
instantly  become  inaccessible because of your  drive's  FAT  no
longer  being decoded by the resident virus whenever your  system
accesses it.  The only way you could come out on top again  would
be if you had a mirrored copy of your boot record and FAT  tables
(such as is made by "Diamond Mirror" on Atari TOS computers).
 These  encrypting  viruses  really  only  get  destructive  when
they're no longer there,  almost calling for a rather drastic re-
evaluation  of most concepts involving  trigger-and  destruction-
routines.
 Although these viruses are unheard of on the Atari TOS  platform
so far, it might really only a be matter of time.

 2.11     ACQUAINTED TUMOURS

 Whenever  people mention computer viruses,  they  often  mention
various other tumours of computer science. The most well-known of
these will be mentioned here.

 2.11.1   TROJAN HORSES

 "A long time ago,  some kind of Lord wanted to conquer some kind
of  city in ancient Greece called Troy.  Since the master of  the
city  did  not particularly like the fact that  this  weird  Lord
wanted  to take the city away from him,  he defended it with  all
power he could (of course).  The fact that it had all started off
with a woman with a face that launched a thousand ships made  the
idea no less bearable to him.
 The  Lord  thought  deep for a long while and  came  up  with  a
brilliant idea that was to be echoed through the halls of history
during  long times yet to come:  He built a large  wooden  horse,
filled it with soldiers and left it standing before the gates  of
Troy one night - a token of 'goodbye'.
 The next morning,  whoever ruled the city looked over the sturdy
walls and saw the plains totally empty.  The army had disappeared
and they had left behind a present - a large wooden horse.
 They rejoiced,  flipped out and generally had a ball:  The enemy
had not been victorious and had even left behind a present!
 The  city  gates  were opened and the  large  wooden  horse  was
brought to the city centre.  People celebrated, food was devoured
and drinks were drunk in excessive amounts.

 But that night,  after even the last bozos had gone home and the
city  streets were empty again,  a hatch somewhere in the  wooden
horse was opened and the soldiers came out.
 They opened the city's gates and whistled three times.  Over the
plains came the legions of the Lord that conquered the city,  ate
its men,  slaughtered its women and raped its pigs (or  something
like that).
 A smile wrought itself upon the wooden lips of the  Horse,  that
was to be known throughout history as the Trojan Horse."

 So far a bit of (rather freely interpreted) history.

 In  the world of computing,  the term Trojan Horse has become  a
synonym for something that looks like something but really isn't.
An  illustrative  example  would be a  game  that  simultaneously
formats your hard disk:  It's not quite what you had expected  it
would be.
 Trojan  Horses are not viruses.  Although we have  shunned  away
from precise definitions  as to what viruses are exactly, I think
we'd  all  at  least  have  to  agree  on  the  fact  that   they
autonomously copy themselves. Trojan Horses don't copy themselves
at  all;  it's a thing that all computer science boffins seem  to
agree upon, remarkable though this may seem.
 Dozens of Trojan Horses seem to exist on MS-DOS  machines.   One
of  the  varied programs like this,  for  example,  is  something
called "SEX.EXE" that shows some rather naughty things  happening
on the screen during which the hard disk is formatted.
 Perhaps   barring   funny  accessories  such   as   "CRABS.ACC",
"FUNNY.ACC"  or "WOWBAGGR.ACC" (that,  strictly taken,  are  what
they  seem to be and can therefore not actually be called  Trojan
Horses at all),  Trojan Horses have never been seen on Atari  TOS
systems.

 2.11.2   WORMS

 Worms  are  programs  that  have so far  only  been  sighted  on
networks.  They  can also transfer themselves through data  lines
between  several  computers,  and can eventually  knock  down  an
entire network.
 There are endless variations on this theme, too. There are worms
that  trap  all passwords entered in a  network,  thus  gradually
working  up  to  the system operator.  Other  types  can  destroy
database files. And the list is, actually, virtually endless.
 This may all sounds terribly exciting and,  in a Robert  Redford
"Sneakers" kind of way,  romantic, but the heart of the matter is
that  a worm would not be of much use on a machine like an  Atari
TOS-based system.

 2.12     ANTI-VIRUSES

 In the battle against viruses, anti-viruses have done quite some
excellent  work ever since they first arrived on the ST scene  in
early  1988.  Even so,  they have also been the reason  for  much
concern.
 It  is quite difficult to define exactly what an anti-virus  is,
for some of them multiply and some of them do not;  some of  them
are resident and some of them are not.
 They really only have a couple of things in common:  They reside
in  the  bootsector,  they  do not aim to  do  anything  negative
against  the user or his system,  they are generally  not  reset-
resistant and they try to warn the user for (bootsector)  viruses
when  there is a reason to believe that these are  present.  This
warning generally consists of flashing the screen and/or making a
beeping  sound,  sometimes  also  allowing the user  to  press  a
certain key that will cause memory to be cleaned (i.e.  that will
cause the virus to be removed).
 For  first  aid and quick  virus  infection  recognition,  anti-
viruses  are  quite  helpful.  But,  once the  suspicion  of  the
presence of a virus exists, the "Ultimate Virus Killer" should be
used.  Anti-viruses are too small to be able to determine whether
the  bootsector includes a virus or a harmless program:  Many  of
them  do not even recognise the advanced "Ultimate Virus  Killer"
advanced disk bootsector immunization method, either.

 2.12.1   CLONING ANTI-VIRUSES

 These  have been the reason for quite a stir because,  as  their
name implies,  they clone - which basically means that they  copy
themselves to other disks. As a matter of fact they are virtually
exactly  the  same as viruses,  whereas most typical  virus  code
characteristics  are also present.  Some virus killers  therefore
classify these cloning anti-viruses as viruses,  too.  There  are
two  distinctive differences between these  cloning  anti-viruses
and regular viruses, though.
 First of all, these cloning viruses first check whether or not a
bootsector is executable before they clone themselves across  it.
This  means that they will never copy themselves  on  bootsectors
needed  by  games and such. Modern anti-viruses even  leave  IBM-
compatible disks untouched (which would lose IBM compatibility if
they didn't).  The second difference is that they should not harm
your system or your data in any way.
 All  cloning anti-viruses are resident,  too,  and thus need  to
patch onto system vectors to work properly.

 2.12.2   NON-CLONING ANTI-VIRUSES

 Non-cloning anti-viruses are probably the best.  They are  still
resident in your system and will warn you when virus infection is
likely,  but  they never copy themselves onto other  disks.  Non-
cloning anti-viruses are no longer viruses by definition, and are
commonly regarded as being very safe and a pretty good help.
 Most  of the latest anti-viruses exist in a non-cloning as  well
as  a  cloning  version.  For non-cloning  anti-viruses  to  work
properly, they need to patch onto the usual system vectors, too.

 2.12.3   NON-RESIDENT ANTI-VIRUSES

 If a definition of these non-resident anti-viruses would have to
be given, it would be something like "all non-resident bootsector
programs  that  check certain system vectors on  start-up  and/or
that call themselves 'anti-viruses'". They do not and cannot copy
themselves to other disks, as they vanish from memory right after
they have served their purpose.  They also do not patch onto  any
system vectors.
 Usually, they get loaded and executed immediately after a reset,
during  the  booting process,  and then  start  checking  whether
certain system vectors point to RAM addresses. When this is found
to be the case,  they print warning messages on the screen and/or
bleep and/or invert colours.
 Strictly taken they are not viruses nor even anti-viruses,  even
though  they sometimes do call themselves 'anti-virus'  and  have
been  classified as such by various virus  killers.  Non-resident
anti-viruses  generally  only recognise  reset-resistant  viruses
(and possibly other reset-resistant applications), since all non-
reset-resistant  viruses  will already have  vanished  from  your
computer's  memory by the time the non-resident  anti-virus  gets
loaded off the bootsector and executed, after a reset.

 2.12.4   VIRUS FREE DISKS

 These  have nothing to do with anti-viruses or viruses as  such,
actually,  but  are considered worthwhile mentioning since  there
are such an awful lot of them.  Also, the line between virus free
disks
 and non-resident anti-viruses is an awfully thin one.
 A  virus free disk is none other than a disk containing a  small
program  in its bootsector that tells the user,  in some  way  or
other, that there is no virus on the disk. A 'virus free disk' is
never  resident  in any way.  Most virus killers  and  even  most
computer  crews have their own ones.  There must be more  than  a
hundred of them,  which is actually far too many and not making a
virus  killer  programmer's  life any easier.  On  top  of  that,
various  viruses  are known to be travelling in the  guise  of  a
'virus free disk'.

 A  'virus  free  disk' works with a  simple  concept:  When  its
message appears,  there is no virus on the disk. When the message
does not appear,  something has overwritten it,  which may  jolly
well be a virus! The method of negative proof used by 'virus free
disks' is not a very reliable one, though.
 Some 'virus free disks' work more extensively; for example, they
may  also  check for reset-resistant applications or  viruses  in
memory.  In  this particular case it's basically  a  non-resident
anti-virus that calls itself a 'virus free disk'.  Yes,  it's all
quite  complicated,  especially  when the  programmers  of  these
particular little bootsector programs don't even know what to let
it call itself.

 2.13     'GOOD' VIRUSES

 Many publications on the subject also mention good viruses,  and
therefore it will be done here,  too.  The example that is always
quoted  from  Cohen's virus research is the  virus  that  spreads
itself and compresses all programs it 'infects',  making sure the
files take up less space on disk.  In the case of program  files,
it even makes sure that they de-compress themselves when  they're
being loaded and run.
 A  'good'  virus  indeed,   though  compression  can  also  have
disadvantages (increased loading + decompression time when  using
a fast storage medium, or the compressed program simply no longer
working  properly or not at all).  In a non-viral form -  without
the  multiplication  characteristic - these  programs  are  quite
popular  on  Atari and other computer systems,  and are  used  to
compress  program-and  data-files.  Need I mention  "DC  Squish",
"Squish  II",  "BA Pack",  "PA Pack",  "Happy  Computer  Packer",
"Sentry  Packer",  "Ice  Packer",  "Atomic" and  "Pompey  Pirates
Packer" on our Atari platform?

 2.14     KILLER DISKS

 Now, since we are talking about destruction of data and computer
systems, why not mention the so-called killer disks? Killer disks
are  disks  that  can actually inflict physical  damage  on  your
computer system - quite specifically on your floppy disk drive.
 The difference between viruses and killer disks is very  simple:
A  killer  disk  contains  no program  that  assists  it  in  the
'killing' and is created purely on a hardware basis.  The  German
Bayrische Hacker Post wrote quite an extensive article on  killer
disks  quite  a  few  years ago  (August  1987)  which  was  very
unsettling.  It explained in detail which chemical compounds  had
to be put on disks to allow the read/write head of the disk drive
to  be  irreversably  damaged,  and how  to  replace  the  actual
magnetic data carrier by fine sandpaper.  However,  killer  disks
have actually never been sighted (or,  at least,  these sightings
have  not  been documented) and I think we can  be  thankful  for
that.

 This mentioning of killer disks,  however, was only included for
the  sake  of completeness.  As stated before,  they  have  never
occurred and hopefully never will.