PART II
THE "ULTIMATE VIRUS KILLER" MANUAL
9 - THE SYSTEM STATUS SCREEN
To assist you in determining whether your computer system itself
is already infected by a virus or not, the "Ultimate Virus
Killer" always checks your computer's most important system
vectors/variables and memory contents on start-up. These specific
system variables are pointers to various sub-programs within the
computer's Operating System, for example pointing to a routine to
read or write a disk sector, a routine to 'open' a file and so on
and so forth. Generally, viruses cling to these system variables
in order to work. This way all known bootsector viruses can be
recognised in the system, as well as resident types of link virus
and a large number of harmless other programs that also cling to
these vectors (i.e. bend them) for valid purposes.
Of course unknown viruses cannot be recognised yet. That is the
reason why this screen has been included. On startup, or after
selecting the "System Status check" option from the main menu,
the "Ultimate Virus Killer" will check all these important system
vectors and try to establish which programs are hooked to them.
It will notify you of unknown programs that have bent these
vectors, signified by an inverted display of the memory address
to which the vector points, indicating that there is a chance
that you might be dealing with a new and unknown virus. This
chance is increased dramatically if the program additionally
displays "ALERT" behind a memory address displayed in inverted
text style. In this case it has calculated something not unlike
the regular 'Virus Probability Factor' for a small cluster of
memory located at that memory address, and the program code
present there was found to contain one or several characteristics
commonly found in viruses. Please see figure 9.
If you don't understand this business with vectors and such,
please refer to "The Book", 2.2).
Whenever something specific that bends a system vector is
recognised by the "Ultimate Virus Killer", it will display a
figure between brackets directly after the actual memory address.
This can have one of the following formats:
(x) The number of a recognised application
(Number corresponds with the APPLICAT.TXT file
list)
(?) An unknown application is recognised
(This MIGHT be a virus, or a harmless program)
(#x) Anti-virus recognised. Reboot without it!
(Number corresponds with appendix A)
(-x) Virus recognised. Turn off system and reboot!!
(Number corresponds with appendix A)
Often the "Ultimate Virus Killer" does not display a number but
instead displays a four-letter code (like "FrmD" of "CBHD", or
whatever). This is the so-called 'XBRA identification' (see
appendix G), which is a protocol devised in the early nineties to
allow for easier recognition of the multitude of files that can
hook themselves onto the various computer system vectors. These
XBRA identifiers are always displayed whenever they are
encountered; should you want to see numbers only (as these
correspond with the APPLICAT.TXT file list) you need to keep the
[ALTERNATE] key pressed while the addresses are put on the
screen. Pressing [CONTROL] will slow down the output so that you
can survey rather better all the programs that bend the specific
vectors.
An additional advantage of the XBRA protocol is that it is
possible to check if several programs have hooked themselves onto
the same vector, forming what is referred to as an 'XBRA chain' -
a sequence of programs that all use the XBRA protocol. This chain
will be examined by the "Ultimate Virus Killer" as deep as it can
go - which is until it finds an unknown program that uses the
XBRA protocol, a program (known or unknown) that does not use the
XBRA protocol, or until it hits on the actual standard and safe
Operating System values.
- Please note that, with but a few exceptions, installed RAM
disks are not recognised and will most likely result in "(?)
Unknown Application Found". To get rid of this, get rid of the
RAM disks in memory. Note that a lot of the modern RAM disks
are reset-proof, so you will have to turn off your system to
get rid of them.
- When the Physical Top of RAM is inverted, this is usually due
to some kind of (resident) RAM disk, too. Again, get rid of it
and run the "Ultimate Virus Killer" again.
- Alternative (and unofficial) versions of (beta STE) TOS 1.06
that go around (reference to the TOS '1.07' by TEX, TNT Crew
and Level 16 is meant here) are recognised as a standard TOS
1.06. This is because the people behind that adapted TOS wanted
to have maximum compatibility and could therefore not change
the date and version number. When specific TOS 1.07 versions
are recognised, they are thus stated in the status screen, and
their release date will be stated at 'TOS date' (which normally
displays the date contained is the TOS header, which represents
the date at which that particular TOS version has been
released).
- Something similar is the case for the alternative Operating
System "KaosTOS" (an adapted TOS 1.04). When this is
recognised, the TOS version displays 'KAOS' and the TOS date
specified is the release date of the "KAOSTOS" version
currently in use.
- The system screen will also check for reset-proof programs and
warns you when non-recognised resistant programs are found.
9.1 WHEN SUSPICIOUS
What to do when one or several of these variables happen to be
displayed in inverted text style, in other words when there is
something in your system that isn't yet recognised, something
potentially suspicious?
Step 1: If you're using an AUTO folder on your boot disk or boot
partition, disable all programs in there, as well as all
accessories. Disabling AUTO folder programs can be done by
changing the extensions from .PRG or .ACC into e.g. .PRX and .ACX
respectively. The Operating System will only load .PRG files from
the AUTO folder and will only recognise .ACC files as
accessories. If these aren't present the system will assume
they're not there and won't load any of them. Alternatively, on
more recent Operating Systems, you can keep [CONTROL] pressed
during booting until the desktop appears. This won't load any
accessories or AUTO folder programs, even if you haven't disabled
them. It should be noted that this does not load the
DESKTOP.INF/NEWDESK.INF file either, usually resulting in a
resolution that the "Ultimate Virus Killer" can't work in, as
well as all hard disk icons having to be installed on the desktop
again.
Turn off your system and turn it on again after about 30
seconds, with the "Ultimate Virus Killer" disk (or another disk
that is guaranteed to be free of viruses) in the drive. You will
now have a system that is as empty as can be.
Start the "Ultimate Virus Killer" and wait until the System
Status Screen has appeared. All values on display should be in
regular text. In case of an inverted display as a rule this does
not point to virus infection. It's probably a hard disk driver
software version that isn't yet recognised. Hard disk drivers
typically use memory slightly above the bottom of memory, whereas
your Operating System is typically located on addresses $Exxxxx
or $FCxxxx).
Now enable one AUTO folder program, reset your system and load
the "Ultimate Virus Killer". Check if the System Status Screen
shows something inverted. Continue like this until either all
files are enabled again or until a system variable is displayed
in inverted text style. The file to have been enabled last before
one (or several) system variable(s) is (are) 'suspicious' again
is the one that changes them. Do note that these AUTO folder
programs should be enabled in the same order as they are located
on the disk. With more recent Operating Systems versions (as well
as most alternative desktops, I would imagine), you can get this
order displayed by selecting "No Sort". If your Operating System
version does not have the "No Sort" option, please check each
AUTO folder program separately, disabling the one you checked
before each time.
Don't forget to go through this with the desk accessories, too,
as they are also known to bend system vectors occasionally. But
make sure you check the AUTO folder programs first, as
accessories will be loaded later, i.e. on top of AUTO folder
programs.
Do not delete a program that bends any system vectors, as it is
usually not at all likely to be of viral nature unless the word
"ALERT!" appears behind the inverted address displayed. Please
just send the appropriate program file, whether "ALERTed" or not,
to the feedback address, possibly with additional files belonging
to it and any documentation (on disk, or photocopied). Its
recognition will be catered for into the forthcoming version of
the "Ultimate Virus Killer" so that it will no longer cause any
memory addresses to be displayed in inverted text style. Do not
forget to supply enough International Reply Coupons (no stamps)
if you want your disks to be returned.
In case you are reluctant to send the program(s) in question to
the feedback address, or when it requires a very specific setup
that only you have, you can move the mouse cursor on top of the
inverted system variable contents and click on it with the left
mouse button. An additional dialog box will be displayed,
containing some vital information that we can work with to some
extent. Please write down the contents of the dialog box together
with the name, version number and origin of the file that caused
the vectors to be inverted, and send it to us so that inclusion
in future "Ultimate Virus Killer" versions may be possible after
all.
If you have a printer connected, you can keep [CONTROL] pressed
while you press the left mouse button; the program will then also
output the information on your printer. If you additionally keep
[ALTERNATE] pressed, a Form Feed will be sent after printing has
finished, causing the paper to be moved up to the start of the
next page (tractor feed) or to be ejected (sheet feed).
Press any key or mouse button anywhere to cause the information
lines to disappear from the screen again.
Pressing the "OK" button or pressing the associated keyboard
shortcut (in this case [ALTERNATE]-O or [RETURN]) will leave the
System Status Screen altogether, to the main menu.
- If system variables are suspicious even without any AUTO folder
programs and accessories having been installed, and you have no
hard disk, it could be a virus or RAM-based version of TOS
(i.e. TOS loaded off disk).
- If the above occurs if you have a hard disk, it is very likely
to be your hard disk driver. This is normal.
- If the program to bend the system vector uses the XBRA
protocol, the XBRA code may give you a clue as to which program
actually bent it.
9.2 THE PROBLEM
As you may have gathered from the above, it is no exception that
several programs hook onto the same system vector. It will not be
hard to imagine that a dozen or more resident programs can be
installed, all bending various system vectors to their heart's
content. This sort of thing tends to happen when you have a hard
disk cache program installed, a screen speeder ("Turbo ST",
"Quick ST", "NVDI", "Warp 9"), an alternative file selector
("FSelect", "UIS", "Selectric", "Freedom", "Little Green
Footballs File Selector"), a multi-tasking Operating System
("Magic", "Geneva", "MultiTOS"), a resident multi-tool program
("Update", "Mortimer", "Harlekin"), an alert box enhancement
program ("Let 'Em Fly", "FormDoIt") and an alternative desktop
("Gemini", "Teradesk", "NeoDesk", "Ease", "Thing") for example.
It's easy to have even more programs bending these vectors, none
of them necessarily viruses.
To check which application (i.e. which program) has bent a
particular system vector/variable, the "Ultimate Virus Killer"
examines the piece of memory where the vector now points to. It
will (or won't) recognise the program present there and display
the appropriate message in the system status screen for you to
look at.
Whenever multiple programs bend the same system vector it
becomes difficult (if not impossible) to check which programs
bent the system vectors before that last one did, unless they use
the XBRA protocol mentioned earlier. Usually, the memory address
that the last application found sitting on the vector is stored
somewhere in a buffer location within itself so that it can be
called after it has served its own purpose. There is no way to
tell precisely where.
You can compare a series of programs bending one system vector
with a chain. The program that was loaded last (let's call it
program "A") is most 'on top' and will be executed first whenever
the system variable is accessed by the Operating System. Once
program "A" is finished doing what it was intended for it will
pass on the address it found sitting on the vector before it
installed itself, i.e. the address at which the program is
located that installed itself prior to that last program. Let's
call that program "B". Once program "B" has finished what it
wanted to do it will pass on the address that it found on the
system variable before it installed itself there - that of
program "C". And so on and so forth, until eventually the last
program in the chain will execute the actual Operating System
routine that needed to be called originally.
The addresses that each of these programs found sitting on the
system vector are stored in themselves somewhere, internally. The
location where they are stored vary from program to program, even
between different versions of the same application.
The problem for a program such as the "Ultimate Virus Killer",
which tries to determine which resident applications are hooked
to any particular system variable, is that it is normally only
possible to tell which application bent that system vector last.
There is no way it can be determined what the other applications
before it are, as those programs' addresses are contained
somewhere in the program that later patched that vector (I hope
you're still with me).
Only when the last program ("A") used the XBRA protocol can it
be determined where the program before that application ("B") is
located in memory - and when that uses the XBRA protocol again it
is possible to go one step deeper (to "C") until one encounters
the first program that does not use XBRA.
I hope you see that it is normally only possible to check the
programs bending the vectors until a certain 'depth', i.e. up to
the first program that is foolish enough not to use the exalted
XBRA protocol. Anything that's any 'deeper' can only be guessed
at. So in case you're writing utilities that bend system vectors,
do abide by the XBRA rules! They are available in any recent
programmers guide or in the "Ultimate Virus Killer" book (see
appendix G).
So far mention has been made only of problems for the "Ultimate
Virus Killer". But what about a problem for you? Well,
unfortunately there is one.
Just suppose a virus installs itself in your system. It hooks
itself to a few system variables and would be plainly visible for
any extensive system check screen you'd care to throw at it.
However, now just suppose a bunch of AUTO folder programs and
desk accessories are loaded right afterwards. Unless all of these
are using the XBRA protocol, they will effectively hide the virus
from view (and, what's most important, they will also hide it
from the "Ultimate Virus Killer" check algorithms and all will
appear to be OK).
For you to be sure that all is safe you will have to do pretty
much the same as was described above, where the isolation of
unrecognised AUTO folder programs and desk accessories was
concerned. Disable all of these and boot your system anew. Enable
one AUTO folder program at a time, each time run the "Ultimate
Virus Killer", then do the same with the desk accessories. If no
memory addresses are displayed in inverted text style you can
consider yourself safe even if the program will not be able to
check to the most extreme depths each time.
Do note that you will have to check each newly acquired AUTO
folder program and desk accessory for link viruses if you want to
continue feeling safe!