12. References.

[3APA3A] Igor Muttik, "3APA3A Virus - the First Kernel Infector",
Proc. 2nd EICAR Conf., 1994. Also available electronically from
ftp://ftp.informatik.uni-hamburg.de/pub/virus/texts/viruses/papers.zip

[Attacks] Vesselin Bontchev, "Possible Virus Attacks Against
Integrity Programs and How to Prevent Them", Proc. 2nd Int. Virus
Bull. Conf., September 1992, pp. 131-141. Also available
electronically from
ftp://ftp.informatik.uni-hamburg.de/pub/virus/texts/viruses/attacks.zip

[Autoextract] Jeffrey O. Kephart, William S. Arnold, "Automatic
Extraction of Computer Virus Signatures", Proc. 4th Int. Virus Bull.

11. Acknowledgments.

We would like to express our gratitude to the several people who
helped us with the analysis of InVircible and the writing of this
paper. These people we wish to thank publicly for their help; they
are not responsbile for the content of this paper. Some of them
have requested anonymity, so we have used pseudonyms instead of
their real names. We thank to

- Sarah Gordon for her suggestions regarding the English language
used in this paper;

- Bill Lambdin for the idea to use the Tremor.A and Trivial.30.A
viruses in our tests;

- Igor Muttik for helping us with the tests of some difficult to

10. Conclusion.

As we have seen from the above, InVircible has an awful lot of
problems and security holes - holes that make it too vulnerable
both to generic virus attacks against non-virus-specific anti-virus
programs and to direct attacks targeted against this particular
product. As we have also noted, there are anti-virus products which
do not have those problems and are, therefore, much more secure and
reliable than InVircible. Most of the security problems mentioned
above have been described in specialized literature a long time
ago. Additionally, in most cases they are relatively easy to fix.

9. The User Interface.

When reviewing anti-virus products, we usually do not pay
attention to their user interface and concentrate our attention on
their anti-virus capabilities. After all, it is the anti-virus
capabilities that can be measured objectively and that require an
anti-virus expert. The quality of the user interface is to a large
degree a subjective matter and can be evaluated by the users
themselves. However, firstly, as we mentioned in the introduction,
this paper is not a review but an exposure of only the problems in
a particular anti-virus product, and second, the user interface of

8. The Bootstrap Integrity Checker (IVINIT).

Most integrity checkers use one and the same program to check the
integrity of the files and of the boot sectors. InVircible has those
two functions separated. While IVB takes care (inadequately, as we
saw) of the file integrity check, another program - IVINIT - is
designed to perform a somewhat more thorough check of the system
startup process.

The exact sequence of the checks performed by IVINIT has been
already described in the section about the self-checking techniques
used by InVircible. The problem that IVINIT saves copies of the

7. The File Integrity Checker (IVB).

An integrity checker is not a virus-specific anti-virus product;
it is a generic one. It computes some kind of checksums of the
executable objects and stores those checksums in some kind of
database(s). Periodically, those checksums are re-computed and
compared with the originals. If a mismatch is found, the
corresponding object (file or boot sector) is considered to have
been modified - possibly by a virus. The main problem of the
integrity checkers is that they do not detect viruses - they detect
modifications in the executable objects. The burden of deciding

6. The Automatic Scan String Extractor (IVX).

As a sorry excuse for its horribly bad known-virus scanner,
InVircible provides an automatic scan string extractor, called with
the usual buzzword term "hyper-correlator". The idea behind it is
that it is supposed to be given an infected file and a set of
suspected files in a particular subdirectory tree. It examines the
bytes near the entry point of the infected file and attempts to
determine which other of the suspected files look like it and are
therefore infected by the same virus. In this way it is supposed to
scan for new viruses - or for known viruses that are simply unknown

5. The Disk Editor (RESQDISK).

Probably the most useful (or, shall we say, the least useless)
part of InVircible is its disk editor - RESQDISK. The program works
only on hard disks - a rather unfortunate limitation. It uses a
rather advanced tunnelling technique - direct access of the hard
disk via the ports - to read and write the sectors of the hard
disk. Unfortunately, this technique works only on IDE and EIDE
hard disks. On SCSI and MFM hard disks ResQdisk is just as helpless
against stealth boot sector viruses as any other disk editor.

Nevertheless, ResQdisk does contain some useful features. When the

4. The Decoy Launcher (IVTEST).

As was explained in the section about InVircible's self-checking
algorithms, most programs from the package use simple decoy
launching (of 6-byte long COM files) to detect whether a virus
might be resident and active in memory. As noted there, this
algorithm will fail to detect slow viruses that do not infect COM
files or that infect only COM files larger than 6 bytes.

In attempt to improve this situation, InVircible provides a
separate program - IVTEST - which performs a somehow advanced decoy
launching (using the AdvancedDecoyLaunch algorithm, explained in

3. The Scanner (IVSCAN).

Regardless that the author of InVircible often claims that
"scanners are dead and should be replaced by generic anti-virus
methods", his product does include a virus-specific scanner -
IVSCAN. Like most other programs from the package, IVSCAN performs
some other anti-virus functions - like self-checking, anti-stealth
techniques, and so on. However, these (and the problems in them)
are covered elsewhere in this paper, because they and their
problems are common for all programs in the package that employ
such techniques. Here we shall concentrate on the ability - or the