How to Recognise Virus Infection
PART I
THE ULTIMATE VIRUS KILLER BOOK
6 - HOW TO RECOGNISE VIRUS INFECTION
6.1 WHAT CAN GO WRONG
It is very difficult to summarise in short what can go wrong
once you've been infected by a virus. A virus in your system may
easily become corrupted (i.e. mutant) because another program
inadvertently accesses the same bit of memory that the virus uses
to store itself in. If the virus is not sufficiently corrupted to
disable it from multiplying afterwards, it may write corrupted
copies of itself. This is the way mutant viruses come into
existence. There is no telling what can go wrong when you
encounter these mutant viruses. In the multitude of cases,
however, it will get down to your computer crashing (with or
without the notorious little 'bombs' at the left-hand side of the
screen), or disk data suddenly becoming inaccessible due to a
mutant virus copying itself to the bootsector. This latter
problem can, with the aid of the "Ultimate Virus Killer", be
solved.
To try and determine whether something that went wrong actually
went wrong because you're dealing with a virus, it is important
to establish when viruses strike, when they are actually executed
by the Operating System. In most cases this happens immediately
before or after a read-or write-operation to a floppy-, hard-or
RAM-disk has been made. If you've just inserted a disk to read
its directory and something goes wrong around then, chances of
your dealing with a virus are significantly increased. Usually,
viruses will then check to see if the destruction criterion is
met, for example if it has been copied a specific amount of times
or if it is a specific date. The destruction routine will usually
be called within a split second afterwards. The destructive
effects of viruses vary widely (see appendix A for a complete
list of viruses and their effects), but they usually slow down
the system, do something to your storage media, print a message
on the screen or make a sound. A particularly common one, the
Ghost Virus, inverts the vertical movement of the mouse pointer,
for example.
Whenever something suspicious happens, you should turn off your
computer for thirty seconds. You should then boot with the
"Ultimate Virus Killer" disk in the drive. Because you should
have kept that disk write-protected at all times, there is really
not a chance that there will be a virus in your system then;
memory has been cleared entirely and no new virus has been
loaded.
After that you should use the "Ultimate Virus Killer" to check
all your disks and all files on them to see if they are infected
by viruses. Boot files of suspicious disks should be written on a
floppy disk and sent to the address mentioned in your "Ultimate
Virus Killer", as should programs and/or accessories that you
think may have caused a couple of system variables in the 'System
Status Screen' to be inverted (please refer to the manual part on
the System Status Screen for more information about that).
Once you have checked all your disk's bootsectors and files you
are virus-free. You should refrain from booting any of the disks
that you had to send boot files in of, and not execute any files
that were considered suspicious - at least not until you hear
that they are safe to work with.
6.2 HOW TO PREVENT VIRUS INFECTION
Although there is no 100% full-proof way of protection against
viruses, there are some points that you should always keep in
mind to drastically reduce your chances at infection.
6.2.1 KEEP YOUR DISKS WRITE PROTECTED
Although this same procedure on other computer systems might not
quite be as safe as you'd expect, write-protecting a disk on any
Atari TOS computer is a guaranteed protection against viruses. So
if you have disks that need never be accessed by write operations
(disks that never need to be written on, for example to store
save-games or hiscores or your own work of any kind), just write-
protect them!
Logically, write-protecting is no full-proof method for your
working disks, as these will have to be saved to at times (during
which moments they cannot remain write-protected and may be
infected).
6.2.2 ALWAYS BOOT WITH THE SAME, WRITE-PROTECTED DISK
Format a disk, then check it for viruses with the "Ultimate
Virus Killer" and immunize it. Next, write-protect it and leave
it in the boot drive WHENEVER YOU TURN ON YOUR SYSTEM or RESET
YOUR SYSTEM. Bootsector virus infection will now be impossible.
This may be a bit hard to remember if you don't always auto-boot
from a hard disk, as quite a few different disks will be likely
to be in your disk drive in that case. If you do not have a hard
disk and you want some accessories and AUTO folder programs to be
installed, just copy them all to this boot disk. After having
done that, however, you should re-check all those files and the
boot disk's bootsector with the "Ultimate Virus Killer"!
6.2.3 CHECK ALL DISKS YOU GET
Whenever you receive disks from a friend (or anyone else, for
that matter), or whenever you have bought a program (Public
Domain, but also commercial!) or a magazine with cover disk:
Check it with the "Ultimate Virus Killer"! Possible viruses can
then be killed at once, and you are advised to warn the person or
company who sent or sold you the disk in case of infection. Other
kinds of bootsectors will either be recognised directly (in case
of known harmless software) or analysed (in the case of
bootsectors not yet recognised).
Please do not forget to check commercial software, even when you
have just now bought it in a shop!
6.2.4 ANTI VIRUS TOS
A nice tip for the hardware-and machine code freaks among you.
Requirements are a reassembler program (such as "Detective"),
EPROMs and an EPROM programmer package. Also, you'll need a fair
bit of system knowledge and a hacker's attitude.
You can disassemble the Operating System, change the bootsector
read routine to make it ask whether or not to execute an
executable bootsector if one is found, assemble it again, and put
(burn) it on the EPROMs using the EPROM programmer. Make sure the
Operating System routines you altered will also check for the
magic longwords with non-executable bootsector viruses on the
proper offsets (see 2.2.2).
Creating a full-safe method to check for the executability of a
bootsector before it is executed it not possible by any other
means, as the Operating System's bootsector check (and possible
execution) is done even before the hard disk driver is installed
and before the first AUTO folder programs are executed. The next
available method would be to build such a virus check routine in
a hard disk driver or into an AUTO folder program, but by then a
virus can already have installed itself and will make sure these
programs find nothing suspicious, having hidden cleverly from
view.
Personally, I used to work with a MEGA ST that had TOS 1.07
(this is a patched version of STE TOS 1.06, which also includes
numerous other features and that is thoroughly debugged, done by
a couple of friends of mine). It is perfect, though this
particular effort was only useful in German machines, as it
involved a German TOS version that, among other things, supported
the different layout of a German ST's keyboard). It's the one
thing I've missed since I switched to the Falcon.
Although I have written to Atari with the suggestion that they
included this feature in their new Falcon TOS versions, they
haven't done so. I think this has something to do with Atari
still not officially wanting to admit that viruses exist,
probably the same reason why you won't find a big software
company like Hisoft or, indeed, Atari itself, marketing virus
killers. All in all this is a bit of a shame, for with such an
option built into the new TOS versions, at least bootsector
viruses could surely have died out rapidly, especially on the
Falcon.
6.2.5 A SPECIAL TIP FOR SOFTWARE AUTHORS
The problem with original game software in conjunction with
virus infection is that a virus writing itself across the
bootsector is more than likely to result in the game completely
failing to work due to loss of its own bootsector program - which
it would have needed to start in the first place. There is a way
to prevent this, though this can only be used if you have a bit
of free space left on your game's boot disk and the BPB is valid.
Also, you really need to be 'at home' in the world of creative
disk editing.
When a virus has infected the bootsector, the game will not
load. Instead, the Operating System will take over after the
virus has installed itself, and try to read the disk's directory
in search for an AUTO folder. Any programs in that AUTO folder
will then be executed as usual. That is the moment when something
can be done about the virus that infected your piece of software!
If the game's bootsector works, the AUTO folder will never be
executed and the game will load automatically. The track used up
by the AUTO folder and a possible program in it will never serve
their function. The game will work and everybody is happy. If the
game's bootsector does not work, however, such as would be the
case when virus infection has occurred, you simply make sure the
AUTO folder contains a neat little program that writes back the
proper bootsector to the disk and clears memory from A to Z,
followed by a reset. This little program should not use Operating
System calls for the writing of that bootsector, as the virus may
have patched these Operating System sub-programs and would then
write itself to that bootsector again as if nothing would have
happened.
This method will take up at least 1 cluster for the program, 1
cluster for the AUTO folder, 1 cluster for the directory and a
minimum of 1 cluster for a FAT. Some heavy BIOS Parameter Block
manipulating is in order here. Should you not want to do heavy
disk manipulation, it will cost you about three tracks.
Protection against link viruses is also possible, of course -
though the evil purpose of such a virus will probably already
have been fulfilled (at least partly) by the time something can
be done about it. At least you could include some checks in your
program code that check if the header and the program length are
unchanged (on the disk!). This way you can at least tell the user
whether a link viruses has contaminated the software.
The "Ultimate Virus Killer", for example, checks itself
completely for link virus infection each time it starts, and will
even give you the name of the virus in case of contamination.
6.2.6 ALTERNATIVE WAYS
There are a number of other methods that can be employed, with
varying effect, to battle the occurrence of viruses on your
system.
6.2.6.1 GUARD PROGRAMS
An alternative way to protect yourself from virus infection is
the use of a Guard program. This is a small program that is
resident in memory (although it might also be a desk accessory)
which monitors all use of the Operating System's read/write sub-
programs. Apart from the fact that these programs can tell you
when something is attempting to write to disk, they can also be
used to lock a hard disk partition from being written to.
Supposing partition "E" is your working partition and all the
other ones only contain programs that never write anything, you
can lock all partitions except partition "E".
Some clever partition guard programs are written by Henrik Alt
(on the disk of his German "Sagrotan" virus killer), Volker
Söhnitz (on the disk of his German "Virendetektor" virus killer)
and Omikron (built into their excellent resident "Mortimer"
multi-utility). I believe Delta Lab's "Poison!" virus killer also
has a possibility to check for viruses on the fly as it were.
6.2.6.2 THE DESKTOP.INF/NEWDESK.INF FILE
-----------------------------------------------------------------
#a000000
#b000000
#c7770007000600070055200505552220770557075055507703111103
#d
#E 1B 03
#W 00 00 04 03 43 10 00 @
#W 00 00 0D 08 2A 0B 00 @
#W 00 00 0E 09 2A 0B 00 @
#W 00 00 0F 0A 2A 0B 00 @
#M 00 00 00 FF A FLOPPY DISK@ @
#M 00 01 00 FF B FLOPPY DISK@ @
#T 00 06 02 FF TRASHCAN@ @
#F FF 04 @ *.*@
#D FF 01 @ *.*@
* #G 03 FF *.PRG@ @
* #G 03 FF *.APP@ @
* #Y 03 FF *.GTP@ @
* #F 03 04 *.TOS@ @
* #P 03 04 *.TTP@ @
-----------------------------------------------------------------
A typical DESKTOP.INF/NEWDESK.INF file
(Yours probably looks different, but never mind that)
You probably know that some of the common desktop parameters,
such as its colours, its printer definition, its currently opened
windows and their sizes and locations, as well as some other
values, can be stored, via the "Save Desktop" option, into a file
called DESKTOP.INF (or NEWDESK.INF on TOS versions 2.02 and
higher).
What rather less people know, however, is that this file can
also be used to change the extensions belonging to executable
files. Particularly some link viruses only multiply to files that
have either a PRG or TOS extension. If one were to change these
extensions, link viruses would not find any files to multiply
themselves to, and your program files would be protected.
Special attention needs to be given to the lines with an
asterisk (*) in front of them in the table above. These lines,
believe it or not, determine which file extensions invoke certain
types of program execution. They are slightly different in a
NEWDESK.INF file (including one or two extra values, probably,
and an additional "@" after the extension names).
PRG and APP files are started with full use of GEM, which can be
seen from the "#G" that their lines start off with. TOS programs
are executed like the above with the exception that GEM can not
be used - you will probably have noticed that TOS programs never
use pull-down menus, alert boxes and other GEM gizmos. TTP is a
special version of a TOS file that first requests the user to
enter certain parameters (TTP is an acronym for TOS Takes
Parameters). Added in more recent Operating System versions, GTP
files are very much like TTP files with the difference that they
can use GEM (GTP is an acronym for GEM Takes Parameters).
You are free to change these extensions to anything you want, as
long as the names consist only of alfa-numerals and you keep into
consideration that lines starting with "#G" apply to GEM
programs, "#Y" to "GEM Takes Parameters" programs, "#F" to TOS
programs and "#P" to "TOS Takes Parameters" programs. You can
change them to rather less popular extensions, which would make
sure that link viruses do not find the regular (PRG, APP, TOS,
etc.) extensions that programs usually need to have for them to
get infected.
Make sure you also change all the corresponding file names on
all your disks and hard disk partitions, and keep in the back of
your mind that you will have to re-configure the "Ultimate Virus
Killer" to actually recognise the new file extensions as
executable ones (see "The Manual", chapter 11).
Of course, link viruses that copy themselves to just any file
with just any extension cannot be protected against using this
method. These viruses, however, have the advantage of getting
discovered more quickly anyway because they potentially infect
(and, thus, corrupt) picture files, song files, text files and
generally all other data files, too.
It should to be noted that most alternative desktop programs
("NeoDesk", "KAOSDesk", "Gemini", "TeraDesk", "Thing" and "Ease",
among others) use their own specific versions of the
DESKTOP.INF/NEWDESK.INF file, almost always with another name.
They might also cater for even more different file types (like
"NeoDesk", that has the NPG extension for special programs that
make use of parts of "NeoDesk" itself). However, their own
equivalents of these information files can also be doctored with
so that new file extensions can be given.
Just make sure that you always keep a backup of all non-doctored
files in case you make a mistake while editing.
6.3 CALL TO ALL BULLETIN BOARD SYSTEM OPERATORS
A Bulletin Board System (or, for short, BBS) is easy to access
for a lot of people who have a modem; it allows files and
information to be exchanged between many users and between just
about any computer system.
It is easy to imagine a file infected by a link virus ending up
on such a BBS; especially link viruses cannot easily be noticed
when included in a program file, certainly not if it is
compressed and put into a package of files the likes of which all
modem people create with archive programs like "Arc", "Arj",
"Lzharc", "Zoo" or "ST Zip". It is likely that the person to
upload that specific file (i.e. the person who sent it to the
BBS) does not know that it was infected in the first place, but
intentional release of link viruses on a BBS would not require a
lot of work. So it is easy to imagine that a BBS could be a real
hearth of virus infection. Should one of those infected programs
get downloaded (taken from the BBS) very often, you could have
something like a computer link virus epidemic on your hands!
It is strongly advisable for all Bulletin Board System operators
(sysops, wizops, whatever) to check all the files that are
uploaded to them with the "Ultimate Virus Killer" (which means a
lot of work, but it should pay off in the end). Especially
Bulletin Board Systems that distribute vast quantities of Public
Domain software are already rumoured to be very risky, which is
often stated in books and articles about viruses.
The "Ultimate Virus Killer" is a powerful tool which enables
fast checking of whole directories of files. All you need to do
is de-archive the files. As the "Ultimate Virus Killer" can be
run from a CLI, it is possible to create a batch file that will
de-archive the files for them to be checked by the "Ultimate
Virus Killer" itself from that same batch file. So now it is
finally possible to get rid of that rumour - you can make your
BBS safe!
This paragraph also applies to operators of large Internet FTP
(File Transfer Protocol) sites, which are basically even larger
Bulletin Board Systems accessible through the enormous Internet.
6.4 CALL TO ALL SOFTWARE MANUFACTURERS
There are many commercial programs that use the bootsector to
load and start themselves. Especially games make extensive use of
this facility. Besides games that use the bootsector to load,
there are also many programs that check specific bytes in the
bootsector as part of their copy protection method (not just
games). This means that bootsector viruses would copy their image
across the part of the bootsector that contains the original sub-
program to load the (game) software, or the part that contains
the specific codes that the software needs to be able to check
for its copy protection. In both cases, this will most likely
cause the program in question to cease working properly, or cease
working at all.
Such bootsectors can, to large extent, be restored by the
"Ultimate Virus Killer". There is a library of commercial and
non-commercial bootsectors supplied with it, allowing for users
to restore the necessary boot code which should make the software
run properly again.
Since more and more bootsectors sub-programs on more and more
software titles become available every day, it is impossible for
the "Ultimate Virus Killer" to be able to restore them all
because a lot of them are not even recognised yet. Each update,
though, recognises more of these as users send in more new
bootsector dump files. None, however, can help more efficiently
than the software manufacturers themselves, by sending in their
unrecognised software so that it can be included in each
forthcoming "Ultimate Virus Killer" version. Of course, they
should also check all their master copies with a really good
virus killer before sending it off to be duplicated. Quite a few
of the major European software houses and distributors already
use the "Ultimate Virus Killer" to keep their software virus-free
now, and they are all quite satisfied.
This entire paragraph is also valid for demo programming crews
who supply their demo disks with auto-booting bootsectors, or who
have special virus free disk bootsectors.
6.5 CALL TO ALL ATARI TOS COMPUTER USERS
It is now finally possible to utterly obliterate the virus
problem on the Atari TOS computer platform. If everybody just
gets his hands on the "Ultimate Virus Killer" software and checks
all disks regularly, there will be no problem left. Tell your
friends and, of course, please feel free to get your very own
copy of the latest version of the "Ultimate Virus Killer".
Just check all disks you get, and always boot with the same,
non-infected and write-protected disk in your boot drive. Only in
that case will you be able to say, "Virus infection does not
happen to me."
6.6 CALL TO ALL VIRUS KILLER PROGRAMMERS
During the years that have been spent killing viruses, people
must have developed at least a hundred or so different anti-
viruses and virus free disk bootsectors. Of course, this
abundance of bootsector programs does not quite add to safety
where the prevention of virus infection is concerned; there are
viruses that 'mimic' anti-viruses or virus free disk bootsectors,
and the general abundance of such bootsectors that are not yet
recognised by the "Ultimate Virus Killer" often causes confusion.
Therefore I would like to call upon all virus killer
programmers: Do not create new 'virus free' bootsectors any more!
There are already more than enough, for at the moment just about
every virus killer and every hackin' group has one of those
bootsectors of its own. If you want to design one nonetheless,
please be as kind as to send it to the address mentioned in the
"Ultimate Virus Killer" so that it may be included in the
"Ultimate Virus Killer" recognition algorithms swiftly!
The reasons mentioned above are also the explanation why a
special "Ultimate Virus Killer" 'virus free' bootsector has never
been written, as it is believed that these bootsectors may be
handy but are not perfect at all. You see, generally, they always
rely on the fact that the user will notice it when a 'virus free'
message does not appear upon system boot-up, which would point at
the bootsector's destruction and possible virus infection. And,
should the attentive user notice, it is already too late: There
is already a virus on the disk and God knows where it has spread
to already.
That is why a method called disk immunization has been developed
which, by now, has been adopted by many virus killers as well as
some resident virus watch programs, good anti-viruses and even
the odd format program. This method of immunization is based upon
the habit of quite a few bootsector viruses (some 20%, including
most of the really wide-spread ones) to check if they are already
present on a bootsector before they multiply themselves. They
generally don't check the entire bootsector but just a small part
- one or two values, to be more precise. And by making sure these
few particular values are present on a disk's bootsector, you can
make sure that a specific virus will not copy itself onto it.
Unfortunately this method excludes immunization against viruses
that use a particular location in a bootsector to check for a
value that already needs to have another value stored there for
immunization against an earlier or more 'popular' bootsector
virus. This disk immunization method might not be perfect, but
it's the best protection against bootsector virus you can have on
disks that cannot be write-protected at all times.
The following table is a list of all possible immunizations
possible against all currently known bootsector viruses. The
leftmost column is the offset (in hexadecimal notation) that the
value (type "L" for longword, type "W" for word) needs to be on.
-----------------------------------------------------------------
Offset/type: Value: Protects against:
-----------------------------------------------------------------
*(1)$000.W $6038 Signum (all versions except D),
MAD, ACA, Freeze, BHP, Arnold/
Rambo, G-Data, DJA
$000.W $4E71 Joe
$000.W $601C Anti-ACA, Puke A, Upside Down
$000.W $6A38 Grim Reaper (first half of
immunization)
$000.W $EB34 Wolf
$000.L $5A4F4348 Zoch (ASCII: "ZOCH")
$000.L $60380666 Evil
* $002.W $001C Maulwurf
$002.W $07C4 Signum D
$01E.L $263C0000 Gotcha Xeno (2)
* $03A.W $4E75(3)
$03A.W $41FA Grim Reaper (second half of
immunization)
* $19E.L $70756B65 Puke #2 (ASCII: "puke")
* $1A2.L $27182818 Goblin
* $1B4.L $2A2A2A20 P.M.S. (ASCII: "*** ")
-----------------------------------------------------------------
(1) Entries with an "*" in front of them have been included in
the "Ultimate Virus Killer" advanced disk immunization
method.
(2) It would have been possible to immunize against the Gotcha
Xeno Virus, but the area that the immunization code is stored
in is an area in which, according to Atari, it is not
"officially allowed" to store boot programs ($06 to $3A
exclusive). To prevent possible problems, it was decided not
to include the immunization, the virus being fairly rare
anyway.
(3) The $4E75 on offset $3A is the opcode for the mnemonic RTS,
which is located at the right spot for the branch on offset 0
($6038) so that it immediately returns back and it is
impossible to execute a real program in an immunized
bootsector.
"Ultimate Virus Killer" immunization offsets and values
The "Ultimate Virus Killer" also makes an immunized disk
bootsector executable, thus rendering it immune for all proper
anti-viruses and the following true viruses: Screen, C'T, FAT,
5th Generation, Finland, Media Change and Macumba 5.2.
Should you decide to develop an anti-virus or a resident virus
watch program that checks for executable bootsectors, make sure
it does not suspect an executable disk that is immunized using
the advanced disk immunization method of the "Ultimate Virus
Killer", for in that case you will be dealing with a safe disk.
In most cases it will suffice to check only the word values on
offsets 0 and $3A.
Please also be sure to test the offsets where the magic longword
'$12123456' can be located (see 2.2.2), especially with non-
executable bootsectors.
A note on disk immunization and MS-DOS compatibility:
The desktop of TOS versions 1.04 and higher formats disks so
that they can be read in MS-DOS compatible systems (IBM PCs and
the like). This is actually very easy to do. The TOS desktop does
it by placing the hexadecimal word $E900 on the first location;
"FastCopy Pro" does it by placing the hex longword $EB349049424D
there. However, word values of $E918, $E983, $E96E, $E9E4, $E9EF,
$EB29, $EB2C, $EB36, $EB3C, $EB3E, $EB40, $EB45, $EB4A and $EB6E
can be found on MS-DOS disks, too, and seem to suffice.
Because MS-DOS compatibility needs a specific value on that
first location of the bootsector, this automatically renders
useless the advanced disk immunization method described above
because it needs another value ($6038) present there. Immunizing
a disk will cause a disk no longer to be MS-DOS- compatible.
Unfortunately there is no way around this without totally
sacrificing the power of immunization.
If you want to exchange files between a TOS computer and an MS-
DOS machine, you should maintain a small number of MS-DOS
compatible, non-immunized swap disks that you check regularly.
That is all that can be advised.
