Virus Classification
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.
