"Vircing" the InVircible

                       "Vircing" the InVircible

                Vesselin Bontchev, research associate
               Virus Test Center, University of Hamburg
             Vogt-Koelln-Str. 30, 22527 Hamburg, Germany
               bontchev@fbihh.informatik.uni-hamburg.de


     "I made this letter longer than usual because I lack the time
      to make it shorter."  ---Blaise Pascal


0. Annotated Table of Contents.

Yes, we know. This is a very long paper. But it is not our fault
that InVircible contains so many bugs and security holes which need
to be described. Reading the whole document is strongly advisable,
but if the reader nevertheless does not feel like doing it, here is
an annotated table of contents. Users who are in a hurry can use it
to locate the parts of particular interest and read them first.

0. Annotated Table of Contents. You are reading it.

1. Introduction. Describes what InVircible is and why we felt
       compelled to write this paper.

2. The Self-Checking Capabilities. Explains what self-checking is,
       why is it used, and how (un)reliable it is.

2.1. Bypassing the Self-Check. Five trivial ways to bypass
       InVircible's self-checking capabilities.

2.2. Damage to the User's Data. How the different programs from
       InVircible are damaging the user's data.

2.3. The Self-Checking Algorithms Outlined. Detailed description
     of the self-checking algorithms used by inVircible's programs.

2.3.1. Algorithm HeaderCheck.
2.3.2. Algorithm CheckSum.
2.3.3. Algorithm DecoyLaunch.
2.3.4. Algorithm AdvancedDecoyLaunch.

2.4.  Usage  of the Self-Checking Algorithms by InVircible's Programs.
       Lists which of the above algorithms are used by each
       particular program and in what order.

2.5. Summary. A summary of the "effectiveness" of InVircible's
       self-checking capabilities.

2.6. Testing the Self-Checking Algorithms with Real Viruses.
       Descriptions of some tests using existing viruses to
       demonstrate how InVircible's self-checking techniques fail.

3. The Scanner (IVSCAN). Test results showing the weak performance of
       the known-virus scanner provided with the package.

4. The Decoy Launcher (IVTEST). Describes what the decoy launcher
       does in addition to the other programs and why it is just as
       ineffective.

5. The Disk Editor (RESQDISK). Explains what the so-called "SeeThru"
       technique consists of, how ResQdisk uses it, and how it can
       destroy the user's data.

6. The Automatic Scan String Extractor (IVX). Lists some tests of
       the so-called "hyper-correlator", demonstrating how it can
       cause both false positives and false negatives and just
       confuses the user.

7. The File Integrity Checker (IVB). Mentions briefly what an
       integrity checker is, what the proper way to test it is,
       and how far such programs can be relied upon.

7.1. Stealth. Explains what the anti-stealth techniques are and how
       stealth viruses defeat IVB's anti-stealth techniques.

7.2. Fast Infection. Describes what fast infection is, how IVB tries
       to avoid it, and how it fails to do so.

7.3. Companions. Explains what companion viruses are.

7.3.1. Extension-Priority Companions. Describes this typical kind of
       companion viruses and shows that IVB is unable to detect them.

7.3.2. PATH Companions. Describes a more sophisticated kind of
       companion viruses - viruses which IVB does not detect either.

7.3.3. Alias Companions. Describes yet another kind of companion
       viruses that IVB is unable to detect.

7.4. Infection of Unusual Executable Objects. Lists which file
       extensions are protected by IVB. The next sections describe
       several kinds of infectable files, the infection of which IVB
       does not detect.

7.4.1. Macros.
7.4.2. Libraries.
7.4.3. OBJ Files.
7.4.4. PIF Files.
7.4.5. GRP Files.
7.4.6. DLL Files.
7.4.7. AVR Files.
7.4.8. BAT Files.
7.4.9. Device Drivers.

7.5. Kernel Infectors. Describes yet another kind of viruses which IVB
       is totally unable to detect.

7.6. Deleting the Database(s) of Checksums. Explains why the checksum
       databases used by IVB are poorly designed, what their format is,
       and how easy it is to fool the program by deleting the actual
       checksum databases.

7.7. Diskette-Only Infectors. Demonstrates that InVircible is unable
       to detect even such an old and well-known virus like Brain.

7.8. Slow Viruses. Lists some tests with yet other kind of viruses
       which completely bypass IVB's detection algorithms.

7.9. Unusual File Infection Techniques. Lists some ways used by some
       viruses to infect files - ways that are not detectable by IVB.

7.10. Windows Viruses. Explains why InVircible is unsuitable for
       protection of Windows applications.

7.11. Direct Attacks. Explains how viruses can be easily written to
       attack this particular anti-virus program and what flaws in
       its design let it happen.

8. The Bootstrap Integrity Checker (IVINIT). Describes how IVINIT
       works, how it can be bypassed easily by some viruses, and
       how it can make the user's disk non-bootable.

9. The User Interface. Describes some frustrating quirks in
       InVircible's user interface.

9.1 No Flexibility to Select on Which Drives to Install. Explains why
       InVircible cannot be installed on some machines.

9.2. Disk Space Wasting. Points out how wasteful of the user's disk
       space InVircible is.

9.3. Critical Error Handling. Lists situations in which InVircible
       just hangs.

9.4. Inflexible Report and Data Files. Describes how InVircible uses
       files with fixed names in particular directories and why this
       is a bad idea.

9.5. Clumsy AUTOEXEC.BAT Manipulation. Describes how the installation
       program can install the product improperly, disabling some of
       its detection capabilities and hindering its performance.

9.6. Peculiar Line Editing, Menus and Beeps. Lists many other small
       but annoying problems of InVircible's user interface.

9.7. The Rescue Diskette. Describes how sloppily InVircible handles
       the important task of creating a rescue diskette.

9.8. Corruption of the Database of Checksums. Points out a bug in IVB
       which makes it corrupt the databases of checksums if there are
       too many files in the directory.

9.9. Documentation. Lists a huge number of real gems of stupidity and
       incompetentness from inVircible's documentation.

9.10. Unstable Distribution and Prices. Shows that in just a couple
       of years four different companies in the USA alone have tried
       to distribute the product at several different prices.

10. Conclusion. Contains our final conclusion about InVircible after
       its careful examination and testing.

11. Acknowledgments. Expresses our gratitude to the few people who
       helped us to do those tests.

12. References. Contains bibliographic references to the papers
       quoted in this material.


1. Introduction.

Recently there has been a lot of hype about the anti-virus product
called "InVircible", produced by Zvi Netiv from NetZ Computing Ltd.,
Israel and distributed as shareware by several companies - mostly
in the USA.

The author of the product is trying hard to push it, using methods
that, according to some, are at least questionable from the business
ethics point of view. He regularly posts to many virus-oriented
public forums, advertising his product as "the ultimate defense
against computer viruses" and often engages in rather low bashing
of the products of his competitors and the competitors themselves.
Even independent anti-virus researchers who do not agree with his
opinion on his product have not escaped his personal attacks and
character assassination tactics.

Another method that he regularly resorts to, is the extensive use
of pseudo-scientific buzzwords instead of the established and
well-known terms in the anti-virus field: "piggybacking virus"
instead of "fast infector", "hyper-correlator and expert system"
instead of "automatic scan string extraction", "anti-piggybacking
SeeThru technology" instead of "tunnelling" or "anti-stealth
techniques", "virus capturing" instead of "decoy launching",
"advanced signature techniques" instead of "heuristics", "generic
methods" instead of "integrity checking", and so on, and so on. The
obvious intent is to confuse the user and to suggest that the
product that uses all those scientifically-sounding
incomprehensible techniques is somehow more advanced than any other
product of the competition. In fact, all those methods have been in
use in many different anti-virus products for years - without the
hype, of course. Sadly, this tactic often succeeds in fooling the
user - not surprisingly, because most users know next to nothing
about the advanced methods used in the contemporary anti-virus
products. They buy the product and rely on it to protect them from
viruses. Since, on a general scale, virus infections are a
relatively rare phenomenon, most users fail to experience the flaws
of the protection that the product provides and therefore fail to
notice the security holes that the product is full of.

Another method often used by the people promoting this product is
to get some satisfied user, whom the product has happened to help,
or to get some person who is completely incompetent in virus
matters to test the product, and then publicize widely the
favorable opinions obtained this way.

Simultaneously, the author of the product himself is not reluctant
to hire known virus distributors to sell his product. For instance,
he is known to have hired Michael Paris to sell his product - and
Michael Paris is well known to have run a BBS with viruses available
on it for download. According to some unconfirmed reports, Tripp
Lewis, the virus writer known under the handle "Firecracker" and a
former member of the virus writing group NuKE, has been selling the
product too.

For any other producer with a conscience this would be an obvious
conflict of interests. Clearly, the author of InVircible does not
fall in this category. Other questionable practices that he engages
into include distributing widely a product that can generate
automatically real viruses with just a few bits changed to disable
their replication capability - "emasculated viruses", as the author
calls them; another meaningless buzzword of his. Obviously the fact
that they can be easily turned into real, spreading and damaging
viruses (sometimes just changing one bit from 0 to 1 would do so)
does not prevent him from supplying them to his unsuspecting users.
This general attitude is confirmed by the reports that some of the
marketing representatives of the product (e.g., in New Zealand) are
freely passing diskettes with real viruses on them to the potential
customers, so that the latter can "evaluate" the product.

In this paper we are trying to take a careful and experienced look
at the security problems that InVircible is full of. We would like
to emphasize that this paper is not a review of the product. It
does not make any attempt to list the good qualities of the product
- the readers can obtain such information from other sources, which
are abundant; not the least from the marketing claims that the
author of the product makes. Here we will try to concentrate only
on the negative sides of the product - on those marketing claims
that are false, and on those security holes that are never
mentioned by the author or by the "reviewers". Our intent is to
warn the potential customers of the product about the possible
dangers that the product presents, to provide them an informed
opinion about the negative sides of the product, and to help them
to make to decide whether to buy or not to buy the product and
whether to rely on it or not to protect them from viruses.

In our tests we used version 6.01D of InVircible. The previous
versions have some additional security holes, but we will not dwell
into that - it is reasonable to assume that the users will try hard
enough to obtain the latest available version of the product.

Each time when we discovered a security hole, we tried to confirm
it by using an existing virus that exploits it. This was not always
possible - the product contains some security holes which no virus
known to us exploits. In those cases we used non-viral programs to
simulate the virus behavior. The alternative would be to write a
virus ourselves - something that contradicts our ethical principles.
However, in all cases we have tried to describe the security holes
with enough details, so that it becomes clear to the users how a
virus could exploit them.

2. The Self-Checking Capabilities.

Whenever a virus is suspected, the first thing the user should do
is to boot from an uninfected write-protected system diskette - to
make sure that no virus is present in memory when doing any virus
hunting. Unfortunately, many users forget to do so and immediately
resort to their anti-virus programs, thus letting the virus to
infect those programs. For this reason, most anti-virus products
have the capability to verify their own integrity - to checksum
themselves in order to to determine whether they have been modified,
possibly by a virus, and to warn the user about it.

However, for most anti-virus programs self-checking is some kind
of last-resort fail-safe - just in case the user has accidentally
infected them. Not so with InVircible. It is designed to rely on
its self-checking capabilities and even to use them actively for
virus detection. While the documentation does advise the user to
boot from a clean environment, the author of the product often
brags about how well his product is able to cope with viruses which
are active in memory and how it can even use them for disinfection
purposes. All of this leaves the users of InVircible with the
impression that booting from a clean environment when suspecting a
virus is unimportant and that the product will automatically handle
the problem for them. Let's see whether the product lives up to its
promises.

2.1. Bypassing the Self-Check.

First of all, a virus that is resident and active in memory
presents the danger of hiding itself (using stealth techniques)
from the anti-virus program. Secondly, such a virus can intercept
the file accesses that the anti-virus program makes to inspect the
system. The virus can then use those accesses for spreading itself
on all infectable objects on this system (fast infection).

The programs from the InVircible package claim to be immune to
stealth techniques and fast infection. However, as we shall see in
section 7.1. and 7.2., this is not always the case.

Finally, at least one program from the package does not perform
any self-checking at all. This is the program IVHELP.EXE. This
presents a particularly dangerous security hole, since whenever the
user suspects an infection and attempts to use the product, s/he is
quite likely to invoke the help system, thus allowing the virus to
infect it and to use it to spread itself further.

Why the help system does not perform a self-check is quite clear
to us. It is not developed by the author of the product. It is, in
fact, a popular hypertext browser, known by the name Tech Help! by
Flambeaux Software, Inc. - the same hypertext browser that is used
by Patricia Hoffman's VSUM. Since the folks at Flambeaux Software
specialize in hypertext engines and not in anti-virus software, it
is quite natural that their program does not perform any kind of
self-checking. Obviously, the author of InVircible has decided that
it is much easier to license someone else's hypertext browser,
instead of creating his own. However, the programmer's laziness
cannot be an excuse for the security hole introduced this way,
which exposes the users' data by creating additional risks of a
virus infection.

Next, we found out that it is particularly easy to fool all of the
programs included in InVircible by infecting them with a companion
virus. They are all EXE files and obviously none of them bothers
checking whether or not a COM file with the same name exists in the
current directory. As a matter of comparison, even F-PROT - a
known-virus scanner - is able to detect when it gets infected this
way by a virus - even if this is a virus unknown to the scanner. In
general, InVircible's ineptness to deal with companion infections
is proverbial, as we shall see in section 7.3.

Then, we tried a method that has been discovered by the virus
writers as effective against the self-checking performed by the
popular scanner TbScan and that has been widely publicized in the
underground virus writing magazines. The method consists of
damaging the pointer that points to the full path of the currently
executed program (argv[0] for C programmers or ParamStr(0) for
Turbo Pascal ones). This way, the program is unable to find itself
on the disk. If this happens, some anti-virus programs silently
fail to checksum themselves, without reporting anything to the user.

Sadly, all programs from the InVircible package fall into this
category. We simulated the attack by appending a piece of code to
them (much like a virus) which, at runtime, destroyed the pointer
mentioned above and transferred control to the original entry
point. All programs that were tested this way failed to detect
that they had been modified. As a consequence, this means that the
self-checking capabilities of InVircible will not work by
definition under any DOS version lower than 3.0 - because those DOS
versions do not support the pointer mentioned above. A good
implementation of the self-check is expected to notice that it
cannot find its image on the disk and to notify the user about this.
Obviously, the self-check of InVircible does not belong to this
category.

In fact, the above security hole can be exploited in a much
simpler way by the virus writers. As it turns out, InVircible's
self-checking mechanism does not report anything if any kind of
critical error occurs. It does not even report that the file has
been modified. Remember that when a modification is discovered, the
self-checker attempts to repair the file. Now, if the file has the
ReadOnly attribute set, this "repair" of course fails. As it
happens, this is sufficient to shut up the self-checker. So, a
virus can easily circumvent InVircible's self-checking modules by
simply setting the ReadOnly attribute to the files it infects.
Obviously, the capabilities of a programmer who has written an
anti-virus program that has such a blatant security hole should be
at least questioned.

The next test that we did was to determine what exactly happens
when the program succeeds to determine that it has been modified.
Any good and reasonably modest anti-virus program would display an
alert and would refuse to run. However, the InVircible's opinion
about its capabilities is far from being that modest! Regardless
that a discovered modification of the program probably means that a
virus has infected it and this virus is now active in memory,
InVircible's programs boldly try to repair themselves. Our
experience with self-repairing methods and the advanced techniques
used by the contemporary viruses suggest that often such an attempt
is doomed to fail. However, it wouldn't hurt if, whenever it fails,
it simply informs the user about this and refuses to work further.
But even this is considered as too modest by InVircible. Instead,
the program performs some magic on its image on the disk and
announces that it has successfully restored itself and everything
is fine and dandy.

In order to test this claim, we did the following. The programs in
InVircible are distributed as EXE files compressed with the popular
program LZEXE 0.91 - with some strings that are usually used to
identify this kind of compression mangled with some additional data.
Such mangling did not fool the author of this paper, who is also
the author of an improvement of a program for decompression of
LZEXE-compressed files - UNLZEXE 0.8. The particular improvements
introduced by him were designed exactly to deal with
LZEXE-compressed files whose identification strings have been
damaged somehow. So, it was not a problem to decompress the
compressed executables.

The decompressed files were, of course, different from the
originals. Since no attempts were taken to fool the self-checking
algorithm in this case, the difference was detected immediately by
the program's self-checking module. However, if any self-repairing
module is able to reverse such a modification and to restore the
original (compressed) state of the file, we swore to eat our hat.

Imagine our surprise when InVircible boldly declared that the
program has been restored to its original state and proceeded with
its execution. We were already reaching for our hat, when we
decided to take a look at the "restored" program. Not very
surprisingly, it turned out not to be restored at all - it remained
in its decompressed state. We executed it several times and each
time it declared that it had successfully restored itself (then why
did it keep finding that it has been modified?), and even created a
data file, claiming to contain the "captured" virus that had
"infected" the program. We pity the users who will rely on such a
"reliable" and "honest" self-repairing algorithm.

Another problem of the self-checking mechanism of the product is
that it involves renaming the program that is checking itself to a
file with the same name and with an empty extension (e.g., IVB.EXE
gets renamed to IVB.) and back. If a file with the same name and no
extension already exists - even if it is zero bytes long - the
renaming operation fails. This has the outcome that the
self-checking mechanism simply transfers control to the main
program, without reporting anything to the user, even if the
program has been modified. Clearly, this is yet another way a virus
can use to disable InVircible's self-checking mechanism.

2.2. Damage of the User's Data.

While we were doing those tests, a minor disaster happened. The
author of this paper is a Bulgarian, who is closely affiliated with
the Laboratory of Computer Virology, at the Bulgarian Academy of
Sciences in Sofia. He often sends there software obtained from
different shareware sources, information about viruses, and so on.
To keep track of this information, a record is kept in a text file
named SOFIA in one of the directories on the disk. While we were
examining the programs from InVircible and running them, we
discovered that this file had suddenly disappeared. The DOS command
UNDELETE seemed unable to recover it. While this was annoying, we
always keep good backups and were able to recover the file. At that
time, we decided that we had accidentally deleted it by mistake -
although it didn't seem very likely.

To our surprise, the next time we executed one of InVircible's
programs while the file SOFIA was in the current directory, that
file disappeared again - and again it was not possible to undelete
it. This time we became very suspicious and used a monitoring
program to watch what exactly the programs from InVircible do when
executed. We discovered some very troubling things.

First of all, every single program from the package that performs
a self-check, when started, deletes a file named SOFIA in the
current directory. Second, some of the programs (IVINIT and IVB)
also destroy a file named WRITEST in the root directory of the
current drive. This happens every time those programs are run -
regardless of whether those files exist or not. Since the
self-checking mechanism also involves the creation of some files
(decoy launching), the disk is written to before the program has
terminated. This usually results in UNDELETE being unable to
recover the destroyed files.

We do not know what the author of InVircible has against a file
named after the capital of our native country. Nowhere in the
documentation does he explain why those two files are deleted - and
even does not mention that such a deletion takes place. The
destruction of those files is undoubtedly intentional and the user
is never offered a chance to save them - or even informed about the
intention of the product to destroy them. We were lucky to have
backups, but for some other users this behavior of the product can
easily result in the irreparable lost of precious data. This makes
us classify InVircible as a Trojan Horse destroying data and we
strongly discourage the users from ever using any programs released
by the same author. Indeed, we discovered the very same damaging
code in two other products of his - his infamous AVPL (the product
that creates "emasculated viruses") and the set of utilities
FIXBOOT, SWAPBOOT, and XMONKEY.

When faced with the above facts, the author of InVircible
initially refused to admit them. Then he began to claim that those
are "just temporary files" used by his programs. First of all,
using fixed names for the temporary files - especially so naturally
sounding ones like SOFIA and WRITEST - shows an extremely poor
programming practice. There exists a DOS function call to create a
file with a unique name - it is provided exactly for the purpose to
create temporary files without endangering the user's data. Second,
destroying a file without warning the user or providing him/her
with the option to avoid the destructive action - even for the
purpose to write some temporary data to this file - is another
extremely poor programming practice. Finally, the way that the file
SOFIA is "handled" is a bit suspicious for a "temporary" file.

Indeed, one would expect the program to create a temporary file,
write some data to it, read it back later, close the file and
delete it. This is definitely not what the programs from InVircible
(as well as the other ones released by the same author) do. When
used in a normal, documented way, they simply delete the file SOFIA
in the current directory - without making any other use of it. They
do not open it, do not create it, do not write to or read from it,
they even do not check whether the files exists and whether the
deletion has been successful! They simply delete it.

As we have discovered later, there are some cases when InVircible
creates this file and writes some data to it. If any of the programs
is executed with the string "!@#" as a command line, that program does
not perform its usual task, but instead creates the file SOFIA in the
current directory and writes the following data to it:

        procedure NETZ;
        begin
        Blztc[1] := 23117;
        Blztc[2] := 126;
        Blztc[3] := 100;
        Blztc[4] := 0;
        Blztc[5] := 2;
        Blztc[6] := 10197;
        Blztc[7] := 10197;
        Blztc[8] := 6042;
        Blztc[9] := 128;
        Blztc[10] := 0;
        Blztc[11] := 14;
        Blztc[12] := 3022;
        Blztc[13] := 28;
        Blztc[14] := 0;
        Blztc[15] := 9215;
        end;

The above data is created by IVScan; the other programs create a
similarly looking file - only the numbers are different. Note that
in this mode the file is not deleted after the program exits. This
is definitely an interpretation of the word "temporary" that we were
not aware of.

The meaning of the numbers above is the following. The numbers 1
to 14 are the contents (in decimal) of the EXE header of the
respective program that has generated the file. The part of the
header is from offset 0 to 0x1A and is taken as unsigned two-byte
words. The 15th number is the contents of the EXE header between
offsets 0x21 to 0x22, again taken as a one unsigned two-byte word.
This information might be important to the author of the programs,
but it can easily be generated by an external program and is
definitely not worth sacrificing the user's data.

The cases described above are not the only ones which expose the
user's data to risk. When the decoys are created, the InVircible
does not check whether files with those names already exist. The
probability for this happening is relatively low but is
nevertheless higher than zero. If this happens, the decoy will
destroy the file with the same name in the root directory of drive
C:.

Finally, IVSCAN automatically cuts off some data from the end of
the executable files (see the section describing this program), and
IVINIT performs some aggressive actions on the user's command
interpreter (again, the reader should refer to the section
describing IVINIT).

2.3. The Self-Checking Algorithms Outlined.

Here we shall describe the algorithms that the programs from the
package use to check themselves for infection. In all cases, plain DOS
functions are used, so the operations performed during the self-check
can be easily intercepted even by the simplest memory resident virus.

The programs from InVircible use the following algorithms to detect
whether they have been modified or whether a (possibly stealth) virus
is active in memory.

2.3.1. Algorithm HeaderCheck:

Part A:

1) Open the file containing the program, read 0x1C bytes from it
(the EXE header), check whether the contents of the header is as it
should be, close the file.

2) Open the file again, move to offset 0x21, read the next 2
bytes, check their contents, close the file.

3) Delete a file named SOFIA in the current directory.

Part B:

1) Rename the file containing the program to one with no extension.

2) Open the renamed file, move to the end of the file and check
whether the offset to which we have moved is the same as the
expected original length of the file, close the file.

3) Open the file, read 0x1C bytes from it (the EXE header), check
whether the contents of the header is as it should be (and whether
it is the same as the contents read when executing Part A), close
the file.

4) Rename the file back to its original extension.

The above algorithm will be bypassed by any full-stealth virus
which removes itself from the infected files when those files are
renamed to empty extensions and which re-infects them when they are
renamed back to executable extensions. The algorithm will also be
bypassed by a virus which does not modify the size of the file and
which overwrites the programs after offset 0x21 from the beginning
of the file. Finally, the algorithm will be bypassed by any virus
that conceals its presence in the infected files regardless of
their extension.

2.3.2. Algorithm CheckSum:

1) Open the file containing the program, move to offset 0x1C, read
the checksum of the whole file stored in the next 4 bytes (for
LZEXE-compressed files - as the ones in the InVircible package are
- those 4 bytes normally contain the identifier "LZ91"), close the
file.

2) Open the file again, read the whole file in 4 Kb bites, compute
its checksum and compare it with the one stored in the four bytes
at offset 0x1C.

The above algorithm will be bypassed by any read-stealth virus.

2.3.3. Algorithm DecoyLaunch:

1) Create a file with a random 8-character name and no extension,
write 3 bytes to it, close the file. This is the decoy. The name is
randomly generated from the alphabet 0-9@A-Z.

2) Rename the decoy to a COM extension, execute the decoy.

3) Open the decoy, move to the end of the file, check that the
offset we have moved to corresponds to the expected length of the
file (3 bytes), move back to the beginning of the file, try to read
0x80 bytes from it (of course, only 3 are read), check the contents
of those bytes, write 3 additional bytes to the file, close the
file.

4) Rename the decoy to an empty extension.

5) Open the renamed decoy, move to the end of the file, check that
the offset to which it has moved corresponds to the expected
length of the file (6 bytes), close the file, delete the decoy.

All file opens are in Read-Write mode, so this is likely to
trigger most popular monitoring and access control programs and to
cause false alarms.

It is clear that the above algorithm will be bypassed by a
full-stealth virus which disinfects the files when they are renamed
to empty extensions and infects them back when they are renamed to
have executable extensions. Similarly, a virus which avoids
infecting files with names consisting of exactly 8 characters will
be able to bypass the above algorithm. Also, a virus which does not
infect 3- or 6-byte COM files will not be detected by the above
algorithm. Additionally, a virus which does not infect files with
particular contents (all COM decoys consist of the bytes 0x90,
0xCD, 0x20, 0xCD, 0x19, 0x20) will escape detection by this
algorithm. At last, the above algorithm will not detect a virus
which infects only EXE files. Finally, the algorithm will be
bypassed by any virus that conceals its presence in the infected
files regardless of their extension.

2.3.4. Algorithm AdvancedDecoyLaunch:

1) Create a file with a random name and no extension (the same
name is used as in the algorithm DecoyLaunch), write 8 Kb to it,
close the file. This is the decoy.

2) Rename the decoy to a file with a COM extension, execute it,
and rename it back to an empty extension.

3) Open the decoy, move to the end of the file, check that the
offset we have moved to corresponds to the expected length of the
file (8192 bytes), close the file, delete the decoy.

4) Create another file with the same random name and an EXE
extension, write 516 bytes to it, close the file. This is the new
(EXE) decoy.

5) Execute the decoy.

6) Check whether a file with the same name as the decoy, but with
a COM extension exists. Probably this is a check for a memory
resident fast infecting companion virus.

7) Rename the decoy to a file with no extension.

8) Open the renamed file, move to the end of the file, check
whether the offset we have moved to corresponds to the expected
length of the file (516 bytes), close the file.

9) Open the file again, read 516 bytes from it and check whether
they are those 516 bytes that were originally written.

The above algorithm will be easily bypassed by:

1) A full-stealth virus that disinfects the infected files when
they are renamed to empty extensions and that reinfects them when
they are renamed to have executable extensions.

2) A full-stealth virus that does not change the size of the
infected files. In fact, the virus has to conceal its presence only
in the EXE files, since the COM decoys are never checksummed.

3) A virus which avoids to infect files with names that consist of
exactly 8 characters.

4) A virus that avoids infecting files with the contents of the
decoys This contents is always one and the same - for instance, the
8 Kb COM decoy consists of the bytes 0xE9, 0x01, 0x00, 0x90, 0xC3
and then the byte 0x90, repeated 8187 times.

5) A virus which does not infect 8 Kb COM and 516-byte EXE files.

6) A virus that conceals its presence in the infected files
regardless of their extension.

2.4. Usage of the Self-Checking Algorithms by InVircible's Programs.

The different programs from InVircible use the above algorithms in
the following way:

IVB: HeaderCheck, destroy the file WRITEST, CheckSum, DecoyLaunch.

IVSCAN: HeaderCheck, DecoyLaunch, CheckSum.

IVTEST: HeaderCheck, DecoyLaunch, AdvancedDecoyLaunch.

IVX, IVLOGIN, INSTALL: HeaderCheck.

IVMENU, RESQDISK, FIXBOOT, SWAPBOOT, XMONKEY, AVPL: HeaderCheck,
CheckSum, DecoyLaunch.

IVINIT: HeaderCheck (Part A), InterpreterCheck, CheckSum, check
the MBR and compare it with the contents of the file PART.NTZ,
destroy the file WRITEST, DecoyLaunch, AdvancedDecoyLaunch,
HeaderCheck (Part B), check the boot sector and compare it with the
contents of the file BOOT.NTZ, check the CMOS and compare it with
the contents of the file CMOS.NTZ.

Note that some programs (INSTALL, IVTEST, IVX, IVLOGIN) do not
checksum themselves, some programs (IVX, IVLOGIN) perform only a
header check, and one program (IVHELP) does not perform any
self-checking whatsoever. The algorithm InterpreterCheck is used
only by IVINIT and will be described later.

2.5. Summary.

All in all, the means that InVircible uses to detect whether some
of its programs have been modified or whether there is an active
virus in memory are patchy, inconsistent, and trivial to bypass
once the virus writers know how they work. The latter is especially
trivial to achieve, since the programs use no anti-debugging
techniques. They use nothing that attempts to make their analysis
and disassembly (or even decompilation back to Turbo Pascal)
difficult. Also, they use plain DOS functions (instead of advanced
tunnelling like, for instance, TbScan or VDS) which are trivial to
intercept and analyze. Additionally, none of the programs checks
whether a companion virus has infected it - something that, for
instance, F-PROT does. Finally, a well-designed advanced
full-stealth virus like Dir_II will be able to both infect the
programs unnoticeably and hide its presence - as our tests have
demonstrated (see section 2.6). Furthermore, those self-checking
techniques are extremely aggressive, are likely to cause conflicts
with any other anti-virus software of the behavior blocker type,
and, as we have demonstrated, sometimes intentionally destroy the
user's data (see section 2.2).

2.6. Testing the Self-Checking Algorithms with Real Viruses.

We used the following known viruses to demonstrate that the
self-checking techniques that InVircible uses should not be relied
upon. Each particular virus illustrates a different method to
bypass those techniques. Many other viruses exist that bypass the
product in the same way and a practically unlimited number of
viruses could be written that would bypass it using those
techniques.

First, we infected several of InVircible's programs with a simple
companion virus - merely AIDS_II. The infection went undetected by
any of the programs of the package, even after booting from the
rescue diskette.

Second, we used a full-stealth virus - Tremor.A - which removes
itself from the infected files if it senses that an attempt is made
to locate the virus body in them. The infection went undetected by
any programs of the package. Furthermore, while we were testing IVB
and IVSCAN, the virus infected some of the files opened by those
programs, without InVircible detecting that a virus was using it to
spread further. It is not particularly clear to us why this was not
detected by the programs in question. When we booted the machine
from the infected disk, the integrity checker (IVB) crashed, thus
making the disk non-bootable (because the program is invoked during
the booting process from AUTOEXEC.BAT). Only after booting from a
clean floppy and running a clean copy of the integrity checker, did
it succeed to detect that some files on the hard disk had been
modified.

We would like to emphasize that this (booting from a
write-protected, uninfected system diskette and running a known
clean copy of the anti-virus program) is the only secure way to
look for viruses. The users must not rely on any self-checking
techniques used by the anti-virus program, regardless how loudly
those techniques are boasted about by the program's author. They
are simply too unreliable.

Next, we used a very advanced stealth virus - Dir_II.T. The level
of stealth used by this virus completely bypasses all checks
performed by any of the InVircible's programs and the virus was not
detected by any of them. Obviously, the author of the package is
aware of the serious problem that such a level of stealth poses to
his package, because almost all programs from the package are
designed to perform a known-virus scan of the memory for this virus
(Dir_II) and another one (Necropolis). However, there are many
variants of the virus that are not detected by this scan, so it was
easy for us to pick one that went undetected and used the disk
access performed by InVircible's programs to spread itself like a
wildfire on the whole hard disk. While the known-virus memory scan
performed by the programs from the package could be improved to
detect other variants of this virus, our tests clearly show that
the generic anti-virus techniques employed by the package are
completely unable to handle stealth viruses of this type.

Finally, we infected one of InVircible's programs with a simple
overwriting virus - Trivial.30.A. When the infected program was
executed, it not only failed to detect that it was infected, but
also let the virus infect all other files in the same directory.

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
lack thereof - of IVSCAN to detect known viruses. After all, this
is the main function of a known-virus scanner.

Testing a virus-specific on-demand (i.e. not memory-resident)
scanner, while difficult enough, is the relatively easiest task when
testing an anti-virus product. It is therefore not surprising that
such tests abound. In the Virus Test Center at the University of
Hamburg we have developed a stable methodology of measuring the
detection rate of on-demand scanners. The only problems that arise
are those caused by scanners which are so poorly designed, that they
are either buggy or "untestable" - for instance, crash during the
test, or are unable to produce a proper report file and so on.
IVSCAN does fall in the latter category, but nevertheless, for the
purposes of this paper, we made an exclusive effort to test it - an
effort that we normally wouldn't make for a regularly tested
product.

The problems that make IVSCAN "untestable" are mostly caused by
its awkward user interface. Those are covered in Section 9. Here
we shall concentrate only on the results of the tests. We will
mention here that among the most annoying problems was the
inability of the scanner to run unattended from batch files. If it
detects a virus, it stops at the end of the scanning and asks the
user whether the report file has to be displayed. There is no way
to force the program to exit immediately after the scan has been
completed.

Also, we were unable to test the scanner for boot sector virus
detection. The reason is that first, the product refuses to create a
report file when scanning floppies and, second, that it requires the
user to press a key each time it has found an infected floppy (but not
when the floppy is not infected). The floppy disk simulator we are
currently using is unable to handle the situation when different kinds
of user input are needed between each two scanned floppies. We can only
express our condolences to the users of the scanner who would have to
scan hundreds, if not thousands of floppies after an outbreak of a
boot sector virus.

The tests were performed on our well organized virus collection
([VirLib]), containing 21,986 samples of 5,789 different file
viruses. The testing protocol is clearly explained in [Tests]. Of
those viruses in our collection, IVSCAN detected 343 or 6% of the
viruses and 2425 or 11% of the samples. Just as a means for
comparison, one of the top performers, AVP 2.2, detected 21,977 or
99.96% of the samples and 5,777 or 99.86% of the viruses. We are
forced to admit that IVSCAN is the worst known-virus scanner we
have ever seen. Even MSAV is better than it.

The quality of the detection of IVSCAN wasn't great either.
Ideally, a scanner that performs exact identification, should have
reported 5,789 different file virus names. Alas, IVSCAN reported
only 66 different file virus names - clearly an unsatisfactory
result. Again, as a matter of comparison, FindVirus 7.08.11
reported 5,156 different file virus names.

Of those viruses from which IVSCAN detected at least some of the
samples, 57 file viruses were detected unreliably (i.e., at least
one sample was detected and at least one sample was not detected).
Unreliable virus detection is a very dangerous bug in known-virus
scanners - because it means that some infected objects will remain
undiscovered and will later cause a re-infection. According to many
security analysts, each re-infection is just as costly to the
victim companies as the original infection. As a comparison,
FindVirus 7.08.11 had only 7 unreliable detections of file viruses.

Finally, IVSCAN had 2 cases of unreliable identification (i.e.,
different samples of one and the same virus being reported under
different names) of file viruses.

All those numbers clearly indicate that the exact identification (or
even nearly exact identification) in IVSCAN is miserable to
non-existent. Obviously, this is yet another scanner that uses the
archaic and obsolete nowadays technology of looking for simple scan
strings. The users should not rely on it to tell them which
particular virus has infected their machine.

We would like also to mention that the scanner sometimes causes
false positives. We have a program that demonstrates the video
effect of one of the Murphy viruses. IVSCAN reported it as being
infected by "Murphy 2" during the installation. Interestingly, this
did not prevent the installation program from invoking the
integrity checker to compute a checksum of the suspected file - as
if it were clean. Had it indeed been a real virus, and had the user
failed to notice the report from the scanner (something that
happens easily, because at scan time the report flashes quickly and
then the report is presented to the user only on specific request),
the checksummer would have "conserved" a real virus as a clean file
in its database.

Interestingly enough, the scanner also reported some Central Point
Software anti-virus programs as "immunized by CPAV" and later the
report said "6 infected or immunized files found". Obviously, the
author of the scanner treats one of the products of his competitors
in the same way as a virus - something that this competitor might
not like too much. Even more curious - once the installation had
created the databases of checksums, later runs of the integrity
checker stopped reporting the Murphy "infection", but continued to
report the CPAV "immunization". Clearly, the author of the product
considers the presence of a competing product as something more
dangerous than the supposed presence of a virus and as something
that is more important to be reported to the user.

The fact that IVSCAN does not use the CARO standard scheme for
naming the viruses it detects does not make the matter easier and
additionally confuses the user. Clearly, this scanner is of a
rather low quality, does not perform adequately the function it is
designed to perform, and shouldn't be relied upon. In fact, it is
our conclusion that IVSCAN is the worst part of the (bad in
general) product. There are scanners with a much better detection
rate (and a much lower rate of unreliable detection and
identification too) - AVP, FindVirus, F-PROT, TbScan, to just name
a few. Even if the users decide to use InVircible as the anti-virus
package of their preference (something that is clearly not
advisable, having in mind the security holes in the other parts of
the package that are explained elsewhere in this paper and the fact
that all programs from the package intentionally destroy data), we
strongly urge them to at least replace the scanner part of the
package (IVSCAN) with one of the better and more reliable ones.

For those who would like to check the above results themselves, we
have made the full report produced from this test available via
anonymous ftp. The full URL reference is

ftp://ftp.informatik.uni-hamburg.de/pub/virus/texts/tests/vtc/invb601d.zip

The archive contains both the rough reports from the scanner when
run on our virus collection and the preprocessed reports, which make
computing the detection rates an easier task. The preprocessed
reports contain three columns - the full path of the file
containing the virus samples, the standard CARO name of the virus
in that file, and the name reported by the scanner (or blank if the
scanner has not detected any virus in the file).

Finally, we have to point out that in some cases, even when run in
scan-only (no repair) mode, IVSCAN can cause damage. As it turns
out, the program automatically cuts out the string "MsDos", if it
finds it at the end of the executable files. It did so with two of
the files on our machine. Unfortunately, those files contained
self-checking programs, and the self-checking included the area
containing the "MsDos" string. As a result of running IVSCAN on the
directory containing those programs, the latter were modified and
refused to run. It is always dangerous to modify the user's data
without permission. It is much more so, if the user is even not
notified about what is happening. This behavior, again, forces us
to classify InVircible as a Trojan Horse.

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
section 2.3.4). The documentation suggests the user to include
invocations of this program in the often used batch files.

The "improvements" in IVTEST's algorithm consist in additionally
creating 8 Kb long COM decoys and also in creating EXE decoys with
the length of 516 bytes. Unfortunately, avoiding to infect those is
just as trivial as the "simple" decoys, and therefore does not
provide any significant increase in the protection offered to the
user.

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
tunnelling technique (named "SeeThru") works, it can be used to
disinfect an active stealth virus very easily. Even if the virus is
not stealth, ResQdisk can be used to locate the original boot
sector, if it is stored elsewhere by the virus, read it from there,
and write it to its original place.

According to the documentation, ResQdisk can be also used to
repair a damaged MBR or DOS boot sector. Unfortunately, we were
unable to test this, because this feature is available only in the
registered version of the product. However, we discovered that
ResQdisk (as well as IVScan) carries within itself a copy of the
code part of a standard MBR and a copy of the DOS boot sector
program used by MS-DOS versions 5.0 and above (it is one and the
same in all versions above 5.0).

Supposedly, the MBR code is used in a manner equivalent to the
FDISK/MBR method, while the DOS boot sector can be used in
situations when the DOS program SYS would be needed. It is worth
mentioning that having a program to install a copy of the DOS boot
sector is much more convenient than using SYS - because in many
cases SYS refuses to work properly and always tries to transfer
also the DOS files - a completely unnecessary operation, if all we
want is to recover the DOS boot sector.

However, having a third-party program carry a copy of the DOS boot
sector poses several other problems. The first question to come in
our mind is - has the author of InVircible obtained a license from
Microsoft for using their code in his programs? We didn't have the
means to check this, and weren't particularly concerned by the
answer, but users who are worried to use a potentially infringing
piece of software should probably contact Microsoft and ask for
more information.

Using a particular DOS boot sector code poses another, technical,
and much more serious problem. Unlike the program in the MBR, the
DOS boot sector program is DOS version-dependent. While one and the
same program can be used to boot DOS versions 5.0 to 6.22, the same
is not true for all the earlier DOS versions or for other brands of
DOS - like DR-DOS, Novell DOS, Compaq DOS, Zenith DOS, and so on.
We strongly suspect that "recovering" the DOS boot sector with
ResQdisk will make a disk formatted with one of those DOSes
non-bootable. Unfortunately, we could not directly verify our
suspicion, because this function of ResQdisk is available only in
the registered version of the product.

However, we tested our conjecture by replacing the boot sector of
a 3.5" 1.44 Mb DR-DOS 6.0 system diskette with the boot sector of a
MS-DOS 6.20 system diskette of the same size, also taking care to
change the names of the two DOS files. According to our
expectations, the diskette became non-bootable.

Next, we used another program from the same author - FixBoot -
which is supposed to rebuild the boot sectors of the diskettes if
they become corrupted or infected. We instructed the program to
rebuild the boot sector of a bootable DR-DOS 6.0 diskette. Again,
as a result of this operation, the diskette became non-bootable. We
are pretty sure that the same will happen to a DR-DOS formatted
hard disk whose DOS boot sector is "recovered" by ResQdisk or
IVScan.

This is, however, not the only way that "rebuilding" the boot
sectors with ResQdisk would cause damage. As we have already
mentioned, the "SeeThru" technique works only on IDE and EIDE
drives. However, it does not work properly on all kinds of such
drives.

For instance, one of the newer Western Digital Caviar 850 EIDE
drives has 1654 cylinders. The INT 13h handler of the older BIOSes
that do not have the LBA translation capability cannot address the
whole drive, because it has a limitation that allows it to handle
only drives with no more than 1024 cylinders. In order to circumvent
this problem, Western Digital ships a product from Ontrack which is
an "AT Register Set Compatible BIOS Extension V3.08". It works by
booting its own code from sectors 0,0,2 - 0,0,30 on the drive, and
then replacing INT 13h in the BIOS (or whatever INT 13h code you
are at that time running) with its own INT 13h code. It redirects
attempts to read the 0,0,1 partition table so that the partition
table looks like a normal one starting the bootable partition at
1,0,1 - i.e., it is acting much like a stealth virus.

When ResQdisk is run on it, it comes up in "SeeThru" mode ON. It
beeps, and alerts the user:

"Caution ! Boot spoofing detected !"

which is actually pretty much accurate, but is not caused by a
virus. The "SeeThru" code does indeed allow the original odd MBR to
be seen, and under "special functions" Ctrl-F1 announces that it
will "rebuild master partition sector". Since we do not have the
registered version, we were unable to test whether this rebuild
would indeed overwrite the Ontrack/Western Digital "Dynamic Drive
Overlay V6.03" bootable partition. If it actually does restore the
partition table to bring up the partition on 1,0,1 without the
Dynamic Drive Overlay code and replacment of INT 13h being
installed, this will definitely corrupt the drive when the user
starts to write to it after the next boot, assuming it could
complete the boot process with the now-incorrect drive geometry at
all.

We also noticed another odd thing. Under the F5 key display of the
drive's geometry, if the user boots from a floppy without loading
the BIOS Extension code, ResQdisk will report that the CMOS
settings for the drive only have 1024 cylinders and that it is a
500 Mb drive. The CMOS, of course, actually has it listed as a 1654
cylinder drive, but it appears that Invircible is either ignoring
the CMOS when reporting its contents, or it is misinterpreting the
CMOS, due to a bug.

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
to the virus-specific detector (IVSCAN).

First of all, this idea is definitely not new. One of the first
anti-virus products to use it was Victor Charlie. Similar
capabilities are available in the registered version of TBAV. The
anti-virus researchers at IBM's High Integrity Lab at the T. J.
Watson research center use a similar idea but on a much more
scientific basis to speed up their work in picking good scan
strings for the new viruses that their scanner has to handle
([Autoextract]). However, they are sensible enough to understand
that, even scientifically much more developed than the approach in
InVircible, their method is too unreliable to be given in the hands
of the general user and have it used it only internally by their
anti-virus experts who know what they are doing. Finally, within
CARO we are often using a similar method of computing the ratio of
common substrings to determine whether two viruses belong to the
same virus family.

Secondly, this idea is seriously flawed. It assumes that the virus
that has infected the file always receives control at its entry
point. In many cases (e.g., Omud, Lucretia, and so on), this is not
the case.

Finally, this method fails miserably when it encounters a
polymorphic virus. To prove this, we took a file infected by a the
One_Half.3544 virus (a polymorphic virus known to be in the wild)
and instructed IVX to look for other infected files in a directory
containing a couple of dozens of them. Using the default
correlation factor of 20%, not even a single infected file was
detected.

While we did expect a bad performance (One_Half is polymorphic),
we were surprised that it was so bad. For instance, using MtE- or
TPE-based polymorphic viruses (which are much more polymorphic than
One_Half), the program succeeded to detect some (but not all) of the
infected files with a correlation factor of 30-40%. However, it
also gave one false positive when run on a directory containing some
perfectly innocent files.

Other viruses whose polymorphic mechanism seemed to defeat IVX
even better than MtE or TPE were Neuroquila and Tremor - again to
our surprise, because, while polymorphic, they are not as much
polymorphic as the MtE- or TPE-based viruses.

Anyway, it is obvious that IVX can be easily defeated and should
not be relied upon.

However, besides being useless in detecting polymorphic viruses,
IVX can often cause dangerous false positives. To demonstrate this,
we performed the following tests.

First, we used a prepending parasitic virus written in a
high-level language and spreading in LZEXE-compressed form -
HLLP.3680. We instructed IVX to use one infected file as a sample
and to look for other infections in the directory where
InVircible's programs were installed. The program reported that
almost all programs in that directory (except IVHELP.EXE) seemed to
contain the same virus - with a confidence of 76%! Needless to say,
neither of them was actually infected. They were just compressed
with the same executable file compressor (LZEXE 0.91), as the virus.

Next, we used a companion virus written in a high-level language -
HLLC.Globe.7705; a virus which spreads in PKLited form. We gave a
sample of this virus to IVX to examine and instructed it to search
the DOS directory for other infections. We are using DR-DOS 6.0,
and most files in the DOS directory are compressed with PKLite;
just like the virus. According to our expectations, IVX reported
most of them as "infected" again - but this time the "confidence
factor" often reached 100%!

We definitely do not think that in a real-life situation the
average user will be able to figure out that some of the files are
infected, while others are perfectly clean and just compressed with
the same file compression utility. The level of both false
positives and false negatives is simply unacceptably high and makes
IVX too unreliable and unsuitable for virus detection purposes.

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
whether those modifications have been caused by a virus or not, is
often left to the user. In order to make this task easier, many
integrity checkers save some additional information - e.g., a full
copy of the boot sectors, the date and time of last modification
and the attributes of the file, some parts of the file near the
entry point and so on. Then, when a modification has been detected,
the integrity checker applies a set of heuristics, in order to
decide whether the modification is of the kind that is likely to be
caused by a virus. Often the integrity checker is able even to
restore the modified object to its original contents (even if it is
infected with a virus unknown to the program) by using the saved
information about the object when it was in its virus-free form.

The integrity checker in InVircible - IVB - is exactly of this
latter kind - with the exception that the heuristic disinfection
program is not available in the version of the product that is
distributed as shareware (i.e., it is available only after
registration). Since we didn't intend to buy the product just for
the purpose of this test (and it is rather expensive), and since no
evaluation copy has been provided to us by the producers, the
heuristic disinfection part of the product was not tested. We would
like only to note that, according to our information, the full
product is copy protected - and we always discourage the users from
using copy protected products, especially anti-virus ones. The best
protection against the data destruction caused by computer viruses
is the existence of good backups - and copy protected products by
definition prevent the users from making as many backup copies of
the product as they want.

Additionally, there are about three dozen ways a virus can infect
a file. Some of them are just impossible to restore using the
heuristic approach - for instance, consider a virus that encrypts
the whole file it infects, or an overwriting virus - unless the
information saved about the file consists of a full copy of the
original, uninfected file. The sort of full copy referred to here
is commonly known as a "backup".

Finally, we would like to mention that, as usual, the product uses
pseudo-scientific buzzwords to indicate a rather simple thing. The
integrity checker with its heuristics that decide whether a
modification has been caused by a virus or not and the heuristic
disinfector are called "integrity analyzer and expert system" - a
completely meaningless phrase in this context.

Since an integrity checker is not a virus-specific anti-virus
program, it makes no sense to test it with particular viruses and
measure what percentage of them it is able to detect. Instead, such
products should be tested with generic virus attacks - which even
do not have to be implemented as viruses - and it should be noted
which of those attacks the product is able to stop and which of
them are able to bypass it ([Quality]). It is important to note
that each such attack which successfully penetrates the line of
defense provided by the anti-virus product can be implemented in a
practically unlimited number of particular viruses. All of those
viruses will be able to successfully attack the machines protected
by this particular (and faulty) anti-virus product.

An almost exhaustive list of such attacks against integrity
checkers is given in details in [Attacks]. Again there, there are
detailed descriptions of how those attacks can be prevented - the
authors of integrity checkers need only to bother to read that
paper and implement almost ready recipes. As the following lines
will show, the author of InVircible has obviously failed to do
that.

In our tests, we implemented the attacks described in the paper
mentioned above almost "by the book" - with a few improvements, in
the sense that some additional attacks have been tried. Almost
always, we first used a simulation of the attack - to check whether
IVB is able to stop it. Only when we knew of an existing virus that
implemented this particular attack, did we use a real, existing
virus, in order to confirm that the attack works as implemented by
the virus writers.

7.1. Stealth.

Most programs from the InVircible package employ anti-stealth
techniques in one way or another. Clearly, the author thinks that
this is a vital function, because it often boasts about his
"anti-piggybacking techniques" (another meaningless buzzword) and
how they make his package superior to the others and how they
prevent the viruses from fooling and "piggybacking" his product -
unlike all products of the competition.

The truth is that while useful, those techniques are nothing in
particular and, worse, are often impossible to implement in a way
that is both secure and portable. The truth also is that many other
anti-virus products have been employing them for years. Probably the
most well-known one is TbScan, which accesses the file system at
INT 25h/26h level. This is the most portable way to do it, that's
why TbScan usually has the least problems working on different
hard- and software configurations. Nevertheless, its author clearly
understands that those techniques ought to cause problems in some
environments and has provided an emergency option to disable them
and use the portable and time-tried way via standard, documented
DOS functions. Another scanner - PC Vaccine Professional - uses a
similar approach.

While the most portable, this approach is also the easiest one to
spoof by advanced stealth viruses - ones that are stealth at INT
25h/26h or even INT 13h level, or at block device driver request
level. Examples of such viruses include Int13 and Dir_II.

A more secure - but less portable - approach is to use INT 13h
calls to access the files on the hard disk, or even to call
directly the original INT 13h handler in the BIOS. The former
approach is used by the product VDS, while the latter one is
employed by the Russian integrity checker ADInf. Not surprisingly,
those products have problems in some environments - VDS has less,
while ADInf has more such problems.

Finally, it is important to note that there are environments in
which the anti-stealth techniques that access the files at a sector
level simply do not work. Such environments include networks -
because they usually do not provide means to access the contents of
the networked drive at a sector level. Therefore, while certainly
useful, the anti-stealth techniques definitely must not be relied
upon to provide absolute protection if a virus is active in memory.
The only method that provides such a protection is to boot from a
write-protected uninfected system diskette and use a known clean
copy of the anti-virus program. The anti-stealth techniques should
be considered only as an auxiliary fail-safe in those cases when
the user forgets to apply the secure approach - because they will
help to detect some (but not all) additional classes of viruses.

It must be noted that InVircible uses far less sophisticated
methods than the products mentioned above. For instance, it always
uses plain DOS functions to access the files on the disk. The only
really sophisticated technique it employs is applied only to access
the boot sectors. It consists of accessing the hard disk directly
via the ports. Of course, this technique (called with the usual
buzzword "SeeThru") works only for IDE and EIDE hard disks. On one
of our machines we are using only SCSI and on another one - MFM
disks. There InVircible turned this technique off and accessed the
boot sectors of the disk with normal INT 13h calls. Furthermore,
the only programs that use the "SeeThru" technique are ResQdisk,
IVInit, IVTest, and IVScan - the others use plain DOS functions
only.

The only other anti-stealth technique used by InVircible is the
cute trick consisting of renaming the programs to empty extensions
when performing a self-check. This technique, as we saw in the
section about the self-checking capabilities, can be trivially
bypassed using a variety of methods - from disinfecting the file
that has been renamed to simply setting the ReadOnly attribute of
it.

We did several experiments to check IVB's capabilities to deal
with stealth viruses active in memory. To some extent, some of them
overlap the tests of the self-checking capabilities of the product.

The first test was to used a file infecting virus that is stealth
at INT 13h level - Int13 is the only such virus that we know. The
virus was perfectly able to spoof the integrity checker and the
latter found no changes in the infected files while the virus was
active.

The second test involved using a virus that is stealth at INT
25h/26h level - such as Dir_II.T. This virus again completely
succeeded to hide is presence. Even worse - after we booted from a
clean environment (the rescue diskette), all that IVB was able to
tell us was that the infected files were "modified, probably not by
a virus".

In the next test, we used a virus that is full-stealth at file
level only - the Number_of_the_Beast virus. The presence of the
virus was not detected - neither in memory, nor in the infected
files; i.e., the virus succeeded to hide itself. Again, booting
from a clean diskette and running the integrity checker resulted in
the not very helpful message that a bunch of files had been
"modified, probably not by a virus".

Then we tried a stealth companion virus - a virus that spoofs the
result of the FindFirst/FindNext function calls, in order to hide
the presence of its companion body. InVircible was unable to detect
it, although we are not certain whether this is due to the fact
that the virus had successfully hidden itself via stealth
techniques, or due to the general incapability of the program to
cope with companion viruses (see section 7.3).

To finish with the file stealth virus tests, we tested the product
with a full-stealth file virus, which does not infect files smaller
than 10 Kb - thus avoiding the decoy launching check. The virus was
Tremor.A. Again, the integrity checker was unable to determine
that a stealth virus was present in memory and couldn't see the
fact that the files whose integrity it was checking were in fact
modified.

Using a normal boot sector stealth virus like Parity_Boot.B did
not succeed in fooling the program on an IDE hard disk. However,
when we infected the SCSI disk's MBR with Tequila.A (it conceals
its presence in the MBR), the infection was not detected - much to
our expectations. IVB succeeded in detecting the infection in the
files - and even the fact that a file infecting virus was active.
However, this was due to the fact that Tequila.A does not attempt
to conceal its presence in the infected files - the MBR infection
was successfully concealed by the virus and the only complain from
InVircible was about the missing 3 Kb of memory. The latter is a
rather unreliable indication, as it is often reported in different
circumstances - e.g., when running InVircible's programs under
DesqView.

To confirm our conjecture, we infected a SCSI and an MFM disk with
stealth boot sector viruses which allocate memory in a less obvious
way - such as Russian_Flag and StarShip. In both cases, the
infection went completely undetected while the respective virus was
active in memory.

In our next test we used a hardware-level stealth virus, which
employs the methods first used by the Russian virus Strange
([Strange]). The particular virus we used was Megastealth - an
Australian virus published in the underground virus writing magazine
Vlad and which has been posted to the Internet and is therefore
supposed to be in wide circulation.

When we booted from the infected IDE hard disk, we got uncertain
results. For instance, running ResQdisk with the virus active in
memory sometimes results in a warning that a boot sector virus is
active and the program displays the real (i.e., infected) MBR. This
seems to mean that InVircible does take some measures against the
hardware-level stealth technique. However, when instructing the
program to read the MBR several times in a sequence, the results
were random and unpredictable. Sometimes the original MBR was
displayed (i.e., the virus succeeded in using stealth techniques to
hide itself from the anti-virus product), sometimes the "SeeThru"
technique was indicated to be turned off, and sometimes the program
displayed a message that the requested operation (what operation;
the reading of the MBR?!) requires an authorization key. Currently
we are unable to explain the reason for the observed effects.

Our conclusion is that accessing the hard disk via the ports is
a powerful anti-stealth technique and it should be widely used
whenever possible - but the security of an anti-virus product
shouldn't depend solely on it, because it simply does not work for
all kinds of hard disks.

7.2. Fast Infection.

The fast infectors are viruses which intercept a large set of disk
access operations and infect files whenever the latter are accessed
for whatever reason. In the case this whatever reason is running an
anti-virus program that has to read those files, the virus can
quickly spread like a wildfire on all infectable objects on the
system under attack. True to his principles to use obscure and
meaningless buzzwords instead of the established and well-known
terms, the author of InVircible calls this "piggybacking".

Protection from fast infectors is achieved in much the same way as
protection from stealth viruses. The only difference is that while
the purpose of the anti-stealth protection is to prevent the virus
from intercepting the disk access and modifying its results, the
purpose of the "anti-piggybacking" protection is to prevent the
virus from intercepting the disk access and infecting the object
being accessed. In both cases the virus has to be prevented from
intercepting the access to the object under examination by the
anti-virus program. Therefore, the same anti-virus techniques work
in both cases. The difference is seen mostly by the tester of the
product - because many viruses go to great lengths to hide their
presence, while few of them use similarly aggressive means to
unnoticeably infect everything infectable.

Besides its self-checking mechanisms which were explained in
section 2, InVircible uses only one additional technique against
fast infection. While it is scanning the disk, it constantly
monitors the available free disk space on that disk. (More exactly,
it checks the available free disk space after each 5th checked file
and at the end of each directory.) If this disk space suddenly
begins to decrease, InVircible decides that a fast infector is
infecting the files as they are being scanned (or as their
integrity is being checked).

Of course, there is one problem. InVircible's programs always
create their report files in the root directory of the disk being
examined. This, naturally, causes a reduction of the free disk
space on this disk. In order to avoid "outsmarting itself", the
programs from the package use the following technique. Each time
when they find something worth reporting, they open the report
file, append the new report to it, close the report file, and get
the resulting (decreased) free disk space as the new value that is
monitored for sudden decreases. This allows a virus to intercept
the operation "close the report file" - something that can be done
quite easily, since all report files have constant names and are
created in known places - and to postpone all infections till that
moment.

Needless to say, the free disk space monitoring technique has
several other drawbacks as well. First of all, it allows the virus
to infect one to four files before the problem is noticed.
Secondly, it will cause false alerts in multi-user and/or
multi-tasking environments. For instance, if another task or
another user copies a file on the disk being scanned, this will
cause the available free disk space there suddenly to diminish.
Thirdly, this technique is helpless against viruses that do not
decrease the available free disk space when they are infecting -
for instance, overwriting viruses (e.g., SillyOR.*), cavity
viruses, viruses using the slack space at the end of the last
cluster (e.g., Number_of_the_Beast) and so on. Finally, on
compressed volumes the increase of the files due to their infection
often does not result in decrease of the available free disk space
- due to the fact that the compressed infected file occupies the
same number of compressed units. Therefore, on compressed volumes
InVircible is unlikely to be able to detect the fact that it is
being ridden by a fast infecting computer virus - especially if the
size of the virus is relatively small.

To prove our point, we used a cavity virus - BootEXE.451. This
virus installs itself in the empty space of the headers of the EXE
files. We disabled IVB's self-checking capabilities - we had
already tested those and knew how they can be bypassed; now we
wanted to test only the ability of the program to detect fast
infecting viruses. Just as we expected, the virus successfully
"piggybacked" the integrity checker and was spread by the latter on
all infectable files on the disk while they were checked. A similar
test with a variant of the Number_of_the_Beast and Dir_II viruses
proved to demonstrate similar results - the fast infection went
undetected and running the integrity checker succeeded to spread
the virus like wildfire on the whole disk that was checked.

To prove our suspicions of InVircible's anti-fast infection
technique being incompatible in multi-tasking/multi-user
environments, we did one last test. We started the integrity
checker in one DOS task under DesqView and instructed it to check
the integrity of the whole disk. While it was working, we opened
another DOS task and made a copy of a file. This caused IVB that
was running in the other task to immediately stop and announce that
a "piggybacking virus" is active in memory - thus causing a false
positive. Similar results can be obtained under Windows, under
Novell DOS 7, in a network environment, and so on.

7.3. Companions.

Companion viruses do not modify the files they infect and as such
they represent an attack against the modification-detection
programs. Instead, those viruses change the execution path, so that
whenever the user attempts to start the infected program, the virus
is executed instead. After doing its work (e.g., infecting some
other files, installing itself in memory, and so on), the virus
transfers control to the original program, so that the user does
not notice anything unusual.

To our amazement, IVB turned out to be completely unable to deal
with this kind of attack. Good integrity checkers (e.g.,
Untouchable) would notice the presence of the companion virus and
would raise an alarm. IVB simply assumes that this is a new file,
computes its checksum, and stores it in the databases, thus
preserving the state of infection.

7.3.1. Extension-Priority Companions.

This is the simplest kind of companion viruses. They look for EXE
files and create in the same directory a file with the same name
but with a COM extension, containing the virus body. The
extension-priority companion that was used in our tests was
AIDS_II.

As mentioned above, IVB totally failed to notice this kind of
infection - regardless that this kind of companion viruses have been
well-known for ages, that it is trivial to detect this attack, and
that all good integrity checkers do detect it. Also, as it can be
seen from [WildList], some companion viruses have been found in the
wild (i.e., in real-life infections) and therefore InVircible fails
to provide protection from a very real threat.

After some experimentation, we found out that InVircible can
detect extension-priority companions in one particular case. This
is when the virus marks its spoofing body with the Hidden attribute
set. Obviously, the author of InVircible is not aware of the fact
that many companion viruses exist which do not set the Hidden
attribute. Or, maybe he has just wanted to spare himself lots of
technical support calls caused by false positives - because some
popular programs (e.g., DV from DesqView) come with companion
bodies.

It is less well known that besides the COM->EXE spoofing, other
kinds of extension-priority companion spoofing are possible - for
instance, COM->BAT and EXE->BAT spoofing. In 4DOS, COM->BTM,
EXE->BTM, and BTM->BAT spoofings are also possible. Since IVB
provides no means for the user to specify which are the executable
extensions and in what order they are searched by the command
interpreter, it proved to be totally incapable to handle this kind
of attack too. The fact that no viruses are known which employ these
attacks is by no means an excuse - the attack is known to the virus
writers and it will be only a matter of time before they implement
it, especially if they learn that a popular anti-virus product does
not protect from it. Good integrity checkers (e.g., Untouchable)
already come equipped with means to thwart this particular attack.

7.3.2. PATH Companions.

The PATH companion viruses examine the contents of the PATH
variable from the environment. This variable containes an ordered
semicolon-separated list of directories, which are searched for
executable files by the command interpreter. The virus would put
its companion body (regardless of its extension) in a directory
that is listed earlier in this list than the directory where the
file being infected resides.

Only one existing virus - TP_Worm - is known to do something
similar. This attack is more difficult to detect and prevent than
the previous one; however good integrity checkers (like
Untouchable) are nevertheless able to detect it by analyzing the
PATH variable and even the contents of the AUTOEXEC.BAT file that
sets it.

Needless to say, IVB turned out to be totally incapable to even
detect this attack, let alone prevent it or remove the infections
caused by it.

7.3.3. Alias Companions.

This companion attack is the most difficult one to detect. It
involves using the alias capabilities of some command-line shells
and utilities (e.g., 4DOS or DOSKEY) and defines an alias of the
infected file. This alias is executed while the command line is
being processed - i.e., before any other file from the disk - and
transfers control to the virus body, stored elsewhere on the disk,
which later transfers control to the original file (the one that
is being infected by the alias companion).

No such viruses are known to exist, but also no integrity checkers
are known that are able to cope with this attack. Unsurprisingly,
our tests demonstrated that IVB wasn't able to cope with it either.

7.4. Infection of Unusual Executable Objects.

IVB checksums only the files that match the specifications *.EXE,
*.COM, *.SYS, *.OV?, *.BIN, *.386, *.VLM, and *.NLM. It does not
provide the user the capabilities to define additional extensions
to be checked. However, as the real life has demonstrated, the
above are by far not all files which can be infected by a virus.

7.4.1. Macros.

The macro language of several products (e.g., Microsoft Word for
Windows - MWfW) is powerful enough to write a virus entirely in that
language. This attack has been first mentioned by [Highland], who
illustrated how a virus can be written in the macro language of the
product Lotus 1-2-3.

In our tests we modified a trojan horse for MWfW macros contained
in MWfW documents, which is known to be floating around the virus
exchange BBSes. Needless to say, IVB failed to notice the attack.

7.4.2. Libraries.

The LIB files contain collections of perfectly executable (and
therefore infectable) OBJ files (more about them see below). No
LIB-infecting viruses are known to exist, but they can be easily
simulated by replacing one of the objects in the library with its
equivalent with some code appended to it.

Since IVB provides no means to checksum LIB files, it is not
surprising that this attack went undetected.

7.4.3. OBJ Files.

Another kind of infectable objects are the OBJ files. They have a
well-documented format and contain executable code. Worse, a virus
is known to exist - Shift_OBJ - which successfully infects them.

Since IVB does not provide the capability to checksum OBJ files,
it is not surprising that this virus went undetected. All good
integrity checkers allow the user to specify which file extensions
are assumed to indicate executable code and should be checksummed.
However, IVB is not one of them.

7.4.4. PIF Files.

It is less well known that the PIF files used by Microsoft Windows
and DesqView are data files, containing pointers to the actual file
that has to be executed. This pointer can be easily modified by a
virus to execute the virus body instead, which would then transfer
control to the original file. No such viruses are known to exist,
but this nevertheless does not make the attack less real.

IVB does not checksum PIF files and was therefore unable to detect
this attack. It is worthwhile to notice that some integrity checkers
(e.g., ADInf) offer to protect PIF files by default.

7.4.5. GRP Files.

The GRP files used in Windows contain different kinds of
information - like the place of the group window on the screen, its
size, pointers to the applications that are members of the group,
and so on. These pointers can be easily spoofed by a virus - much
in the same way as it is done with the PIF files. However, the GRP
files pose a much bigger problem to the integrity checkers, because
their contents constantly changes - each time when the user moves
the group window around or iconizes it. No GRP-infecting viruses
are known to exist, but they are perfectly possible, just like the
PIF infectors. The task of a generic anti-virus program - such as
an integrity checker - is to protect against generic virus attacks;
even against viruses that do not exist yet. After all, the ability
to detect new viruses without the need for updates is the main
quality of the integrity checker - one that is so much boasted about
by their authors.

Needless to say, IVB was unable to detect a simulated GRP
infector. A known-virus scanner wouldn't have a problem detecting
it, once the virus has been included in its database of known
viruses.

7.4.6. DLL Files.

Many files contain executable code and have executable file
structure (e.g., an EXE header) - even if they have other
extensions. A typical example are the DLL files in Windows, but
there are other examples as well - FOT files, VXD files, and so on.
Some viruses infect them by mistake - because they notice the EXE
header. Usually, after such infection, those files refuse to work
properly and can be considered as damaged. Nevertheless, it is
perfectly possible to write a virus that would infect those files
correctly. In any case, an integrity checker ought to be able to
detect the modification of those files. Unfortunately, this is not
the case with IVB.

7.4.7. AVR Files.

There are two anti-virus products (admittedly, both are now
obsolete) which store executable code in special files with an AVR
extension. Usually this is code that contains the scanning engine
needed to detect a particular polymorphic virus. The contents of
those files are perfectly infectable and indeed, at least one virus
is known to exist - Horns - which is able to infect them.

Needless to say, IVB proved to be unable to detect this virus and
such infections in general.

7.4.8. BAT Files.

Currently there are about a dozen viruses which can infect BAT
files. While it is relatively easy to discover the infection by
visual examination of the infected files, many anti-virus programs
do not bother to protect BAT files. Therefore, if the user is
relying on the protection provided by the anti-virus software, a
BAT infecting virus can easily remain undetected.

IVB does not provide the user with the option to monitor the
integrity of the BAT files. Furthermore, no other part of InVircible
is able to detect any BAT file infectors. Our tests with a few BAT
file viruses have demonstrated this beyond any doubt.

7.4.9. Device Drivers.

There are many known viruses that are able to infect device
drivers. Those device drivers are usually in files with the
extension SYS, but can be in a file with any extension - e.g., DRV,
BIN, and so on.

The version of IVB that we tested was able to detect modifications
in SYS files. The documentation suggests that this is a relatively
new addition (obviously, till recently the author of the product
failed to realize that such viruses exist) and that infections of
only SYS files with EXE file structure are detected. However, in
our tests it was discovered that infections of SYS files with a COM
file structure are detected as well.

Unfortunately, IVB does not allow the user to define the
extensions of the files that are being protected, so infections of
anything that does not have the default extensions (e.g., of DRV
files) are not detected by the program.

7.5. Kernel Infectors.

The two files containing MS-DOS are not regular files. In versions
of DOS before 5.0 the boot sector program loads the first of them
as a sequence of sectors, not as a file, since no file system
interpreter is available at boot time. This allows a virus to
fragment the DOS file and place its body on the freed sectors - the
contents of which will be loaded at boot time. This is known as
"the DOS file fragmentation attack" and is a powerful weapon
against integrity checkers ([DOSFrag]), well-known to the virus
writers. (In fact, it was first described to the author of this
paper by a virus writer.) Viruses which infect the DOS areas in a
special way are known as kernel infectors.

The proper way to thwart this attack is to compute not only the
checksum of the DOS files as files, but also to remember the
addresses of the sectors on which they reside. Currently we are
aware of two scanners which are able to cope with this attack -
Untouchable and VDS. IVB is not among them.

We are not aware of a virus which employs the DOS file
fragmentation attack, but when such an attack was simulated, IVB
failed to detect it, just as expected.

However, kernel infection can be implemented in a more elegant and
portable way - one which would work on all DOS versions. This way is
being used by the Russian virus 3APA3A, which is known to be in the
wild in Russia. For a detailed description of the method it uses,
see [3APA3A]. In short, this virus shifts the entries of the root
directory one step forward, in order to free space for one more
entry, then makes a copy of the first DOS file under exactly the
same name, overwrites the beginning of the original file with the
virus body and sets its VolumeLabel attribute. Any attempt to
access the file via the DOS functions will access the second copy
of it (which is unmodified) - because DOS does not allow opening of
files with the VolumeLabel attribute set. Under DR-DOS, the
FindFirst/FindNext functions will not even notice the existence of
a file marked as a VolumeLabel.

When we infected an IVB-protected computer with the 3APA3A virus,
IVB failed to detect the infection. The only thing that was
detected was the reduction of the total amount of memory available
to DOS - 3APA3A reduces this by 4 Kb. However, this cannot be
called a reliable detection - InVircible displays similar alerts
when run under DesqView, or when we boot our notebook computer from
a floppy containing only DR-DOS. Furthermore, many viruses (e.g.,
StarShip) use memory allocation techniques that are undetectable by
the methods currently employed by InVircible, as our tests have
demonstrated.

7.6. Deleting the Database(s) of Checksums.

This is probably the easiest, silliest, and the most often used
attack against integrity checkers. It consists of simply locating
and deleting the database(s) where the anti-virus program stores the
checksums of the protected objects. Many integrity checkers that
suffer from a bad design will fail to notice anything unusual and
will simply re-create the database(s) of checksums - this time of
the already infected files.

Several viruses exist that target the databases created by some
popular integrity checkers - CPAV/MSAV seems to be the most often
targeted one. At least one virus - Groove:MtE - targets more than
one product at once (NAV, CPAV, NoVi, Dr. Solomon's AVTK, and
Untouchable). As the author of InVircible himself admits in the
documentation of the product, at least one such virus exists that
targets the databases of checksums created by this product (this is
the One_Thirteenth:VICE.0_3 virus, although this is not mentioned).

The proper way to deal with this threat is to have the
installation program create the database(s) of checksums once for
all, and then have the integrity checker raise an alert each time
when the database is found to be missing. Furthermore, in order to
make it difficult for the viruses to locate the database, the
latter has to be contained in a single file. At installation time,
the user should be asked to specify a name for this file and a
directory where to keep it - no standard and easily guessable names
should be used.

IVB takes quite the opposite approach. It stores its checksums in
hundreds of files named IVB.NTZ - one in each directory containing
executable files. The files are even not marked as hidden and are
trivial for a virus to find and delete. Once they are deleted, the
next time IVB performs its integrity checking, it silently
recreates them, thus "conserving" the probably already infected
state of the files in the directory. While easier from the
programmer's point of view, such an approach presents significant
security holes to the user and most good integrity checkers (e.g.,
F-CHECK, Untouchable, ADInf) avoid it. In our opinion, programmer's
laziness at the price of exposing the user at risks to get a virus
is inexcusable.

The author of InVircible makes a feeble attempt to close this
major security hole by placing, deeply buried in the documentation,
a remark that the users should use a name for the databases of
checksums that is different from the default one and providing a
special menu item in the shell (IVMENU) to do the renaming.
However, the installation program presents no such warning and not
even the ability to do so, so this remark is likely to be ignored
by most users, who rarely read documentations anyway.

Furthermore, the documentation claims that the renamed databases
are impossible to locate and are "tamper-resistant". This is
ultimately false. We were easily able to write a program that
locates the databases, regardless of their name, decrypts, and even
deletes or modifies them. Therefore, we must conclude that a virus
would be able to do it too and that the claims of the documentation
to the contrary are completely bogus.

The databases consist of collections of 66-byte records - thus
their file size is always a multiple of 66. Each such record has
the following format:

Offset: Contents:
------- ---------
00 - 01 Record identifier. Can be 'MZ', 'PK', or 0xEA60.
02      Length of the name of the file.
03 - 0E File name, format "NAME.EXT", right-padded with zeroes.
0F - 3D File data.
3E - 3F Partial file checksum.
3F - 41 Record checksum.

The file name field is "encrypted" using the following algorithm:

        for (i = 0; i < record [2]; i++)
                record [i + 3] ^= 0xFF;

The contents of the file data field depends on the type of the
file and is different for COM and for EXE files. (The file type is
determined by the first two bytes of the file's contents; not by
its extension.) Its format for both file types is as follows (the
offsets are for convenience given from the beginning of the record;
not from the beginning of the data field):

COM-type files:
===============

Offset: Contents:
------- ---------
0F - 2A Stores the 0x1C (28 decimal) bytes from the file between
        offsets 0x00-0x1B.
2B - 30 Stores the last 6 bytes of the file.
31 - 34 Stores the length of the file. Clearly, two bytes are wasted.
35 - 36 Stores the time of last modification of the file.
37 - 38 Stores the data of last modification of the file.
39 - 3B If the file begins with a JMP Near, the 3 bytes of the file
        where this JMP points to are stored in this area. The field
        is unused if the file does not begin with a JMP Near.
        Instructions like JMP Short or CALL Near are not handled.
3C - 3D Unknown.

EXE-type files:
===============

Offset: Contents:
------- ---------
0F - 28 Stores the 0x1A (26 decimal) bytes from the file between
        offsets 0x02-0x1B.
29 - 2A Stores the 2 bytes after the EXE header (i.e., the two bytes
        at [file [8] * 0x10].
2B - 2E Stores the length of the file.
2F - 30 Stores the time of last modification of the file.
31 - 32 Stores the date of last modification of the file.
33 - 3D Unknown. The contents of those bytes does not seem to depend
        on the contents of the file.

The whole file data field is "encrypted" using the following
algorithm:

        for (sum = 0, i = 2; i < 14; i++)
                sum += record [i] + 1;
        key = ((sum + 16) & 0xFF) % 7;
        for (i = 0xF; i < 0x3E; i++) {
                record [i] ^= key++;
                key %= 7;
        }

The partial file checksum is computed using the following algorithm:

        for <i = 0x20; i < 0x1020; i += 2)
                file_chksum += * (unsigned *) (file + i);

That is, the words from offset 0x20 to 0x1020 of the file are
simply added together. First of all, this checksum algorithm is
astonishingly insecure from the cryptographic point of view. It
would be trivial for a virus to infect the file without modifying
its checksum - all it has to do is to overwrite the file, compute
the checksum of the overwritten part, subtract from it the checksum
of the virus body, and use the complement of this number in the
last word of its body.

Second, an "add-them-together" checksum is much less likely to
detect random corruptions than, say, a CRC. Furthermore, one and
the same area of the file is checksummed, independent of the file
type. For EXE files this often means that only the relocation items
area of the header is checksummed and no part of the actual code is
covered by the checksum.

Finally, the record checksum is computed using the following
algorithm:

        for (rec_chksum = sum, i = 0x12; i < 0x40; i += 2)
                rec_chksum += sum ^ (* (unsigned *) (record + i));

Here 'sum' is the same number computed from the encrypted file
name field that was used to compute the initial value of the key
used to encrypt the file data field. This checksum algorithm is
slightly (only very slightly!) more elaborated, but does not cover
the first 4 bytes of the file data field. It also has to be noted
that this checksum is computed after the file data field has been
encrypted.

Note that the original attributes of the file are not saved in the
database. Also, it is very important to note that the database does
not contain a checksum of the whole file. This means that the file
restoration capabilities of the registered version of the program
cannot be reliable - because the program has no information that
would allow it to verify whether the file has been entirely
restored to its original contents.

7.7. Diskette-Only Infectors.

One type of viruses that cause a lot of problems to the integrity
checkers are the viruses which infect only floppy disks. The
information on the floppies is often subject to frequent changes
and few integrity checkers bother to create checksum database(s)
for it. IVB can create a database of checksums for the files on the
diskette, but does not checksum the diskette's boot sector. As a
result of this, IVB is unable to detect even such old and
well-known virus as Brain. (IVScan detects most variants of Brain,
but we were able to find a variant it couldn't detect -
Brain.Standard.No_Text - in order to illustrate our idea.)

One may argue that if the infection is confined only to the
floppies, then the machine is not infected (although it might be
used as a vector for infection of more carriers). However, it is
very easy to imagine a diskette-only infector like Brain which,
unlike Brain, has a data damaging payload. Even worse, this payload
may consist of slow corruption of only the data files on the hard
disk. A good general-purpose integrity checker that allows the user
to checksum even the data files, if necessary, would catch the
problem. However, IVB does not fall in this category - it claims to
be a virus detection tool only, not a general-purpose integrity
checker, and, as such, does not allow the user to checksum other
files than the ones with the default executable extensions.

7.8. Slow Viruses.

One of the most powerful kinds of attacks against the integrity
checking programs are the so-called slow viruses. Those are viruses
which infect only objects that are being modified. For instance,
they can infect the boot sector of a floppy only when it is being
written to by commands like FORMAT or SYS; or when the user copies
a file they would infect only the copy but not the original; or
when the compiler creates a new file they would infect the latter.
An integrity checker would notice the newly appeared file and would,
in most cases, report this fact to the user (because no checksum
for that file is available). However, the user wouldn't suspect a
problem - because the new file has been created by the user's
instructions - and would tell the integrity checker to compute a
checksum for the new (now infected) file and to store it in its
database(s).

Fighting this attack is extremely difficult. The most successful
methods include integrity shells - intelligent memory-resident
integrity checkers, which constantly monitor the creation path of
every new file and attempt to validate all steps involved in its
creation as virus-free. InVircible uses decoy launching - it
creates a few COM and EXE files with known (to it) contents,
expects the virus to infect them, and then checks their integrity.

Unfortunately, as explained in the section about the decoy
launching, the implementation of this approach is not good enough
and it is relatively easy for a memory-resident slow virus to avoid
infecting the decoys and thus remain undetected. To prove this, we
used the Darth_Vader - a slow infecting cavity virus, which infects
only COM files that contain areas of zeroes when those files are
being written to. Since InVircible's decoys do not contain zeroes
(they contain NOPs - 0x90 - instead), the virus did not infect them
and thus went undetected.

Additionally, the decoy launching approach has the serious
drawback of requiring the virus to be active in the memory of the
computer at the time when the check is being performed. Leaving an
active virus lurking in memory is dangerous per se. Also, as the
section examining the anti-stealth techniques demonstrated, it
could also mean that the anti-virus program can be fooled by a
particularly smart stealth virus.

7.9. Unusual File Infection Techniques.

IVB is not a simple integrity checker that checksums the whole
files. Its author has figured out that this is a relatively slow
operation. Since his intended use of the product is to be started
once daily from the user's AUTOEXEC.BAT file, he probably
understands quite well that a slow anti-virus program will not be
accepted by the user. His main mistake has been not to allow
checksumming of the whole files as an option - for those cases when
the user feels that it is really needed.

In order to speed up the checksumming process, IVB checksums only
some small parts near the file beginning (see the description of the
format of the database of checksums in section 7.6), combining them
with information about the file length. The reasoning behind this
approach is that a virus would always try to get control first and,
even if doesn't, it will change the length of the file.
Unfortunately, there are viruses which fail to comply with this
simplistic assumption.

For instance, the Russian virus Omud ([Omud]) sometimes overwrites
a random sector of the file with its body. The virus is designed in
such a way, that if this body happens to receive control by chance
during the execution of the file, the virus will succeed in
installing itself in memory correctly and begin to infect. When
tested, IVB failed to detect such infections, therefore leaving the
possibility for those files to cause a re-infection.

Another method is used by the Lucretia virus. This virus searches
the files for an instruction that looks like a call to a system
library in a compiled high-level language program and places there
the instruction that would transfer control to the virus. If,
whenever the infected file is executed, the original system library
function happens to be called, the virus will receive control. IVB
is able to detect this particular virus only because the latter
increases the size of the infected files. However, it is easy to
combine this infection strategy with one which searches the victim
file for an area of constants (e.g., zeroes) and overwrites it with
the virus body without increasing the size of the file. (Such
viruses are called cavity viruses.) When we simulated such an
attack, IVB cheerfully failed to detect it.

7.10. Windows Viruses.

As it becomes clear from the format of the database of checksums
described in section 7.6, InVircible doesn't seem to know about the
NewEXE headers used by the Windows applications. This means that
almost always it saves information only about the standard EXE
header of such files and of the small DOS program that this EXE
header describes (the program which prints an error message if the
file happens to be executed under plain DOS). If a virus infects
the Windows application properly (several such viruses are known to
exist), in many cases it will not be detected and the infected file
will almost never be restored successfully. From the point of view
of the virus the most difficult part would be not to modify the
length of the file - but the Windows applications often contain
large areas of zeroes and/or easily compressible areas in which
such a virus could hide.

7.11. Direct Attacks.

IVB does not use a simple CRC or not even a well-known
cryptographic hash function to compute the checksums of the files
it is supposed to protect. Furthermore, the databases of checksums
themselves are encoded ("encrypted" would be a too strong word in
this case). The checksum algorithm and the encoding method are not
published. However, it wouldn't be too difficult to the determined
attacker to determine them by fishing them from the program or by
analyzing the database files. Fact is that we succeeded to do it
(see section 7.6), so there is no reason why a virus writer
wouldn't be able to do it just as well. The security of an
anti-virus program - especially if it is one of the generic, as
opposed to the virus-specific kind - must not rely on whether the
potential attacker knows how this particular program works. This is
called "security by obscurity" and is a principle that is
well-known by the security experts to be unreliable.

IVB has no protections against debugging and decompilation - it is
a straightforward Turbo Pascal program, compressed with LZEXE 0.91,
with the strings "LZ91" and "*FAB*" replaced by some numbers needed
for the self-checking purposes. Decompiling it would be relatively
easy. We didn't bother to do it, but we are aware of cases when the
virus writers (e.g., Dark Avenger) have decompiled whole popular
anti-virus programs (e.g., McAfee's SCAN), in order to determine
their checksum algorithm or scan strings used and to subvert them.
We do not doubt that the same task is perfectly feasible for IVB.

The important thing to note is that IVB always computes one and
the same checksum for one and the same file - even if installed
many times on different machines. Therefore, a virus which knows
the format of the checksum databases and the checksum algorithm
could easily manipulate them. (We doubt that it would bother
however - as noted elsewhere in this paper, it would be much easier
and effective to simply delete them - IVB won't notice anything
anyway.)

This is a serious security hole. As demonstrated in [Radai],
cryptographically insecure checksum algorithms can be securely used
for virus detection purposes (as opposed to authentication
purposes), if the virus has no way to determine the particular
checksum algorithm used. For this purpose, at each installation
the integrity checker must pick a random checksum algorithm -
usually this is achieved by selecting a random generator polynomial
for the CRC. Most good integrity checkers (e.g., Untouchable,
Integrity Master, etc.) do exactly this. This is not,
unfortunately, the case with InVircible.

Another easy direct attack is to modify the executable in such a
way as to disable the routine that raises an alert each time when a
virus-like problem is detected. A virus can easily achieve this by
decompressing IVB.EXE (the LZEXE decompression algorithm is widely
known and is in the public domain) and patching its code. In order
to prevent the modification from being spotted, the virus will have
also to patch the self-checking routines and to disable them - or
to use one of the other methods to circumvent the program's
self-checking, or to use stealth techniques, as described elsewhere
in this paper.

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
boot sectors at fixed and easily locatable (and modifiable) places
was also already mentioned as a serious security hole elsewhere in
this paper. Here we shall describe the algorithm InterpreterCheck.
It consists of the following:

Algorithm InterpreterCheck:

1) Locate the file pointed to by the variable COMSPEC from the
environment and remember its extension.

2) Rename this file to a file with no extension.

3) Check that the renaming is successful by trying to locate
(using the function FindFirst) the newly renamed file.

4) Open the renamed file, read the first 3 bytes of the renamed
file and compare them with the bytes stored in the file C:IV.INI,
then close the file.

5) Rename the file back to its original extension. Done.

It is important to note that if any of the data files that IVINIT
uses (C:PART.NTZ, C:BOOT.NTZ, CMOS.NTZ, C:IV.INI) is missing,
the program simply re-creates it and saves in it the current
contents of the respective object. That is, if the virus has
modified one of those objects and has simply deleted the respective
data file that contains information about the object, IVINIT will
simply re-create the data file with the new information (about the
already infected object), thus "conserving" the infection. The user
is never informed that such an action (re-creation of the data
files) has taken place.

Another serious problem is the aggressive way the program uses to
treat the user's command interpreter. Messing with the user's files
without requesting a permission - or even without informing the
user what is happening - is in general a very bad idea. But what
else can be expected from a program which intentionally destroys
some of the user's data files?! Anyway, imagine that a power
failure happens after step 2 of the algorithm InterpreterCheck. The
user's hard disk will become non-bootable, since the bootstrapping
process will be unable to find the command interpreter. We had at
least one report from a user of InVircible that exactly this has
happened to his computer. A similar problem can - and does - occur
with some anti-virus programs of the behavior blocking kind (e.g.,
TbFile). InVircible is incompatible with them and using it on a
system protected with them can lead to unpredictable, and often
damaging results.

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
InVircible does contain some particularly awkward traits which are
worth mentioning.

9.1 No Flexibility to Select on Which Drives to Install.

The installation program automatically scans all available logical
disk drives for viruses (using the rather poor known-virus scanner;
see section 3) and creates the database of checksums in all
directories that contain executable files on all those drives -
without offering the user any option to make a decision or a
selection. Indeed, the scanning and checksum creation of a
particular drive can be aborted by pressing Esc, but the user needs
to have rather good reflexes in order to do it in time - i.e., at
the beginning of the operation for that particular drive, when no
checksum databases are created yet. A well-designed integrity
checker would provide the user with the flexibility to choose which
particular drives and directories have to be protected, and which
ones should be excluded from the protection.

9.2. Disk Space Wasting.

All those hundreds of databases (one in each directory) are
extremely wasteful regarding disk space. On our notebook containing
about 1,500 executable files in about 200 directories, the created
databases were totally about a hundred of kilobytes, but occupied
about half a megabyte of disk space. This is because those
databases are relatively small files - but DOS always allocates disk
space in clusters, so even the smallest file can easily occupy a
few kilobytes of disk space, depending on the cluster size. The
more such files there are, the more disk space will be wasted.

We did not dare to install InVircible on our normal working
machine, which contains our virus collection, consisting of tens of
thousands of files in a couple of thousands of directories. That
machine has a 1.9 gigabyte disk, but we were afraid that the free
space on some logical disk drives would be insufficient to cope
with InVircible's disk wasteful databases of checksums - and the
installation did not provide us a clean way to exclude some of the
logical disk drives, let alone some of the directories.

The better designed integrity checkers (e.g., Untouchable, ADInf,
F-CHECK) keep all checksums in a single file.

9.3. Critical Error Handling.

On our notebook we are using a popular freeware disk encryption
software - SFS. This software reserves some logical disk drive
letters as mount points for encrypted volumes. When no such volume
is mounted to them, those drive letters are visible to DOS, but an
attempt to access those "drives" returns a critical error. Some
types of disk compression software (e.g., JAM) have a similar
behavior.

At installation time, InVircible attempted to access those
non-existent drives and appeared to hang. We had to terminate the
scanning of those drives with Esc. While annoying, this would be
acceptable, if it were to happen only at installation time.
However, each time the installed product tried to check the
integrity of the machine (after being started from AUTOEXEC.BAT;
see below) it hung again when trying to access the non-existent
drives. Integrity checking when started from AUTOEXEC.BAT is
supposed to be automatic and should be interrupted only if
virus-related problems are found. Obviously, the critical error
handling in InVircible leaves a lot to be desired.

9.4. Inflexible Report and Data Files.

There is a set of files which InVircible always creates in the
root directory of the drive. The product does not provide the user
with the flexibility of indicating where those files have to be
placed or even how to name them.

Probably the most annoying example is the report file generated
after scanning or integrity checking. It is always named IVSCAN.RPT
(or IVB.RPT, or IVX.RPT) and is created in the root directory of
the drive being scanned. In practice, this means that it is
impossible to obtain a report of the scanning of write-protected
media. Imagine a situation when your organization has been infected
by a virus and you have to scan hundreds, if not thousands of
floppies, and want to determine which ones are infected and which
are not - for instance, in order to attempt to trace the origins of
the infection. Well, InVircible would not allow you to create a
report from the scan - unless you remove the write-protection from
all the floppies (a very unwise move when a virus is suspected of
lurking around) - and even then you'll have to collate the report
from the hundreds of sub-reports created on each floppy. InVircible
"solves" this problem in a very lazy way by simply refusing to
create a report file if a floppy is being scanned.

However, the root directory is exclusively used for many other
files that InVircible creates. For instance, all decoys created
during the self-check (described in details in section 2) are
created in the root directory of drive C:. Besides being annoying,
it also introduces a security hole - a slow virus which avoids
infecting files in this directory will not be "captured" by the
decoy launching method.

Another example are the files created by IVINIT which contain
copies of the Master Boot Record of the hard disk and the DOS boot
sector of the active partition. Both those files have fixed names
(PART.NTZ and BOOT.NTZ respectively) and are again created in the
root directory of drive C:. It is trivial for a virus to find and
delete or modify them. The 48 bytes from the CMOS that IVINIT saves
and checks are saved again in a file with a fixed name (CMOS.NTZ),
which is created again in the root directory, but this time not
necessarily the root directory of drive C:. Instead, it is created
in the root directory of the drive from which IVINIT has been
started.

Some other files - for instance a saved copy of the infected decoy
if the decoy launching method has succeeded to "capture" a virus,
or the first few bytes of one of the self-checking programs in
InVircible if their self-checking algorithm has succeeded to detect
that they have been modified - are also saved in the root directory
with fixed names (VIRUSAM.PLE, VIR-CODE).

An anti-virus package that is well-designed from the security
point of view should be flexible enough to allow the user to
specify how exactly those files should be named and where exactly
they have to be put. Furthermore, it would allow the encryption of
the vital data file(s) with a user-selectable password (e.g., like
F-CHECK does).

9.5. Clumsy AUTOEXEC.BAT Manipulation.

The installation program blindly edited the file AUTOEXEC.BAT and
inserted two lines at the very beginning:

        IVINIT/NoCMOS
        IVB C: DAILY/NOMEM

According to the documentation, the program also REMs out any
existing calls to a competing product - TbFile from the package
TBAV. Just stating that InVircible is incompatible with TbFile
would be enough - in our opinion, actively turning off a
competitor's anti-virus software goes a bit too far, is unethical,
and exposes the user to risks, if they are relying on the presence
of that other anti-virus product and on the protection that it
provides - especially having in mind that InVircible itself does
not contain a behavior blocker and therefore does not provide this
kind of protection.

But let's return to the two lines mentioned above. The first of
them starts the program that checks the integrity of the boot
sectors and does advanced decoy launching to detect an eventually
present in the memory virus. It also checks the integrity of the
command interpreter. Why the CMOS check was turned off by the
installation is a mystery for us - maybe the author of the package
does not consider it to be reliable enough?

The second line starts the file integrity checker, instructing it
to always check at boot time the contents of the root directories of
all drives and to perform only once a day an integrity check of the
whole contents of all the drives. We were unable to find out what
the option /NOMEM does. It is explained neither in the
documentation, nor in the on-line hypertext help system. However,
the existence of this option is mentioned.

Regarding the integrity checking strategy, "check always C: and
once a day everything else" is by far not the most convenient
integrity checking strategy we have seen. For instance, Untouchable
always performs an integrity check of all programs started from
CONFIG.SYS and AUTOEXEC.BAT - for this purpose it contains a
built-in interpreter of the language used in those files and can
handle even a situation when external BAT files are called which
execute some additional programs. It also allows integrity checks
to be performed on different groups of objects (e.g., a group
containing all objects executed at startup time; a group of all
executable objects - allowing the user to specify what an
executable object is; a group of all files; etc.) and using
different algorithms (e.g., only size, time and data check; check
only of some areas near the entry point; check of the full contents
of the file).

Furthermore, many anti-virus programs that install something in
the user's startup files allow the user to select where exactly this
something will be placed - all this at installation time. As it
turned out, the fact that InVircible's installation blindly placed
those two lines at the very beginning, effectively turned off some
of the checking capabilities of the product and significantly
slowed down its performance.

The reason for the former is that we are using 4DOS as our command
interpreter. This program is distributed as a COM file, but it is of
EXE type. We have renamed it to have an EXE extension on our
machine, because files for which the extension conflicts with the
type cannot be moved around by our disk defragmenting software
(Norton's SpeedDisk) and often trigger warnings from some
anti-virus programs. At boot time, 4DOS sets the environment
variable COMSPEC to 4DOS.COM. That's why, we have a line in our
AUTOEXEC.BAT file, which sets COMSPEC to 4DOS.EXE. Unfortunately,
InVircible modified AUTOEXEC.BAT to invoke IVINIT before this line.
That's why, at boot time IVINIT complained that 4DOS.COM is missing
and refused to perform some of its checks. Clearly, this could be
easily avoided, had the installation software been a bit better
designed to be more intelligent and flexible.

The second problem was caused by the fact that we are using a disk
cache program (Norton's NCache). Since InVircible modified
AUTOEXEC.BAT to invoke the integrity checker before the disk cache
was started, the check itself was rather slow. Again, a little bit
of intelligence from the part of the designer of the anti-virus
product would have avoided the problem.

9.6. Peculiar Line Editing, Menus and Beeps.

The general user interface in InVircible is far from intuitive and
does not conform to any of the existing de facto standards in the
field of designing user interfaces. This drawback of the program is
not terribly important from the security point of view. However, it
is nevertheless worth mentioning, since awkward user interfaces can
easily repulse the user and make him/her reluctant to use the
software. And, even the most secure program (which InVircible isn't
by far) is useless if it is left unused.

The small, annoying problems in InVircible's user interface
include:

1) Annoying beeps and pitches while the program works.

2) The items on the pull-down menus are not "cyclic" - i.e., it is
not possible to move the cursor from the last menu item to the
first one by pressing the Down key, or from the first menu item to
the last one by pressing the Up key. Also, the PgUp and PgDown keys
do not move the cursor on the first and last items of the menus,
respectively; the Down key does not cause "pulling" of the current
menu item, and so on.

3) When the program asks the user to input a line (e.g., a file
name) the de facto standard features for line editing (Home, End,
Cursor keys, Insert toggle) are not available.

4) In many cases it is impossible to abort the current operation
and to return to a previous item in the menu - for instance, when
the program is requesting a line of input.

5) The F1 key does not provide context-sensitive help. Instead, it
invokes the hypertext help system with general help about the
particular program of the package that is being executed - not with
help about the particular place in that program where the user has
requested help.

6) The mouse control is non-standard and it is not possible to do
everything with the mouse. For instance, it is not possible to leave
the shell (IVMENU) without reaching to press the keyboard. Clicking
on the scroll bar's ends when the list with the directories is
displayed does not scroll this list but instead directly jumps to
the beginning or the end of the list - to achieve scrolling, the
user has to move the scroll bar indicator.

7) When the screen is in a mode that has more than 25 lines,
InVircible's programs display some garbage at the beginning of the
26th line - a clear indication that the direct video RAM access is
not programmed properly.

8) The installation program fails to copy the plaintext manual
(MANUAL.TXT) from the installation diskette to the destination
directory. In fact, it turns out that the installation copies to
the destination directory all EXE and H! from the package and just
the first of every *.ICO and *.PIF files that it finds in the source
directory - which might happen to be from a completely different
package.

9) At installation time, the integrity checker reported sometimes
to be "validating" a directory and sometimes to be "renewing the
signatures" in it. This makes no sense whatsoever, because at all
times it wasn't doing any of those - it was creating the databases
of checksums instead.

10) The built-in viewer for the report files messes up the display
when the lines in those report files are too long (e.g., longer than
80 characters).

11) The messages displayed by the different programs of the
package are often cryptic. The documentation neither lists them
all, nor explains what they mean.

12) On CGA video controllers the programs of the package display a
characteristic "snow" when changing the contents of the screen,
making it clear that the programmer either didn't know how to
prevent this annoying effect (it's trivial), or didn't bother to do
it.

13) The "thermometer" bars that are supposed to illustrate how far
the program has reached in the scanning process do not work
correctly. It seems that they are updated on a per directory basis
(instead of on a per file basis). When a directory containing a lot
of files is being scanned (or the integrity of those files is being
checked), the bar stays for a long time at some low value and then
suddenly jumps to a much higher value.

14) The package is not authenticated against tampering in any
serious way. Such an authentication is particularly important for
anti-virus programs distributed as shareware - because they are
very often subjected to such tampering by malicious attackers. For
instance, TBAV and F-PROT use public-key based authentication (PGP)
to ensure the integrity of the programs in the respective package.

There are several other similar problems in InVircible's user
interface which are probably not worth listing here. Undoubtedly,
the user can eventually get used to them, but at first they
certainly look frustrating.

9.7. The Rescue Diskette.

The installation procedure simply tells the user how to create a
rescue diskette (one containing copies of the operating system, the
boot sectors, and some other important areas) - in the better
designed products such a diskette is automatically created during
the installation. Furthermore, when this diskette was created, the
product failed to analyze the contents of CONFIG.SYS and
AUTOEXEC.BAT and to copy all programs started from there - as some
better products do. In practice, this means that if some device
drivers are needed to access some parts of the disk, those parts
might remain inaccessible after booting from the rescue diskette.

The rescue diskette contains only the operating system, most of
the different files from InVircible (but, for instance, IVTEST is
not present - why?!), copies of CONFIG.SYS, AUTOEXEC.BAT, the MBR,
the DOS boot sector of the active partition, a copy of track 0 of
the hard disk, and SYS.COM. However, we have DR-DOS installed on
our machine and the program SYS is in a PKLited EXE file.
InVircible was unable to find the program when it had an EXE
extension and forced us to abort the creation of the rescue
diskette and rename the file. Finally, creation of a rescue
diskette is impossible (the product refuses to do it), if the
current command interpreter is not C:COMMAND.COM. In our case it
was D:DOS4DOS4DOS.EXE and we had to temporary modify the COMSPEC
variable from the environment, in order to force InVircible to
create a rescue diskette.

Finally, InVircible's total incompatibility with other anti-virus
programs of the behavior blocking type reared its ugly head again.
We are using a small device driver, which guards against resetting
the ReadOnly attribute of the files. This was enough to prevent
InVircible from transfering the operating system to the rescue
diskette - because the files of the operating system have the
ReadOnly attribute set, InVircible always opens files in ReadWrite
mode (even when it only wants to copy them), and tries to reset the
ReadOnly attribute in order to succeed - something that our device
driver prevented. Surprisingly, InVircible issued no error messages
informing us about its failure - it simply did not put DOS on the
rescue diskette. Had we failed to notice this, and had we needed to
boot from the rescue diskette for disk recovery purposes, we would
have been unable to do so.

It is also worth noting that once InVircible transfers all the
files it needs to the rescue diskette, it creates a hidden file on
it with a random 8-character name and no extension - a file that
occupies the whole free disk space on the diskette. The purpose for
this is not clear - the rescue diskette must be always kept
write-protected (at least the documentation of InVircible says so),
therefore no virus would be able to infect it. Besides, even if it
were not write protected, the fact that there is no free disk space
on it wouldn't stop most boot sector viruses from infecting it.
Therefore, filling up the free disk space is wasteful and serves no
protection purposes. We would advise the users to delete the huge
hidden file and to copy there some useful utilities - like an
editor, a file manager, and a disk editor - which would come handy
if (when) InVircible's data recovery features fail to recover a
scrambled disk. Adding there a good anti-virus program might not be
a bad idea either.

By the way, InVircible calls this operation (filling the free disk
space with a huge hidden file) "armoring the diskette". It also
claims that InVircible's armor is "patent pending". We definitely
do not think that the process of filling the free disk space with
garbage is worth patenting.

9.8. Corruption of the Database of Checksums.

It must be noted that IVB - the file integrity checker from
InVircible suffers from one very serious bug when handling its
database of checksums. The program is written in Turbo Pascal and
Turbo Pascal programs have problems to handle data structures
larger than 64 Kb. We have discovered that IVB reads the whole
database of checksums for a particular directory in memory. This
prompted us to check what happens when the size of such a database
exceeds 64 Kb.

Since the record for each file occupies 66 bytes (the exact format
of each record is described in section 7.6 of this paper), this
means that if a directory contains more than 993 files with EXE,
COM, SYS, OV?, BIN, 386, VLM, or NLM extensions, the database of
checksums for this directory will exceed 64 Kb. In our tests, we
created 1,000 COM files in a single directory and ran IVB on it to
create the database of checksums. We did expect to find the program
unable to handle the situation, but we also expected it to detect
that this is the case and to complain that there are too many files
in the directory. However, the error checking in InVircible is
notoriously poor and again succeeded to surprise us. IVB issued no
error message and proceeded to create the database of checksums.
However, when we examined this database, we found out that it was
severely corrupted near the end. When afterwards IVB was run in
checking mode, it simply exited without performing any checks and
without reporting any errors. And, of course, it failed to detect
that meanwhile we had infected a few of the files in this directory
with a virus.

This again presents a serious security hole and is very likely to
occur in real-life situations. In our experience, we found it a
rather common situation for the users to have a single directory
named BIN on a LAN server, which often contained more than a
thousand (in fact, numbers like 1,200-2,000 were a norm) executable
files.

9.9. Documentation.

The documentation of the product is full of little gems - most of
them exposing an amazing incompetence in virus-related matters or
unfair attacks against competing anti-virus products. Let's take a
look at some quotes, with some comments added by us:

"InVircible avoids common problems of other anti-virus software."
- in fact, InVircible not only has those problems, but also
introduces several new ones on its own.

"InVircible programs recover themselves in case they become
infected, even from stealthy viruses." - not always true, as our
tests have discovered; see section 7.1.

"InVircible does not allow a 'fast infector' virus to 'piggyback'
its scanners and to infect an entire hard disk drive." - not true,
as our tests have demonstrated; see section 7.2.

"Computer viruses are sophisticated computer code written by
imaginative programmers" - in fact, most existing computer viruses
are horribly buggy programs, written by people without any serious
knowledge in programming.

"Computer viruses are passed the same ways we obtain software; by
copying from friends, from bulletin board systems, with newly
purchased PCs and even in vacuum wrapped new software." - in fact,
most often infections are caused by forgetting an infected data
diskette in the bootable drive of the computer.

"FAT manipulators are inherently stealth viruses because they hide
the increase in file length, although the virus code is actually
appended to the file. The way it is done is by inserting the extra
clusters in the file's clusters chain in the FAT. Two well known
such viruses are Dir-2 and 1963 (Necropolis)." - in fact, Dir-2
does not append any code to the files at all. Also, the other
virus (1963) is usually referred to as "Niemela" by the rest of the
documentation.

"The detection of encrypted viruses cause high false alarm rates
due to the ambiguity in the detection of the short common string." -
in fact, the modern scanners decrypt the encrypted viruses and
perform exact identification of the decrypted virus body, thus
avoiding any false positives. Unsurprisingly, InVircible's scanner
does not belong to this category.

"Polymorphic viruses are a higher order of encrypted viruses. In
addition to encryption, they use a 'mutations generator' that
scramble the encryption too. A polymorphic virus mutates itself, so
that each occurrence is totally different from the one before. This
creates huge difficulties for anti- virus scanners, because they
cannot look for a 'known' virus signature. Polymorphic viruses have
rendered scanners effectively useless since they cannot be removed
by an algorithmic approach." - in reality, the polymorphic viruses
scramble the decryptor; not themselves. Also, many modern scanners
(e.g., FindVirus, F-PROT, TbScan, AVP) can emulate the polymorphic
decryptor until it decrypts the virus body and then scanning
becomes trivial - but again, this is a technique that is obviously
unknown to and beyond the capabilities of InVircible.

"[InVircible] handles both known and unknown computer viruses" -
in fact it can't handle even some of the known viruses, let alone
the unknown ones.

"[Invircible] is extremely fast, professional and easy to
operate" - actually, it can be rather slow, is extremely
unprofessional, and its user interface can be frustrating.

"[InVircible] uses a unique unobtrusive file protection and
restoration scheme" - actually, several other products use a similar
or better restoration scheme and InVircible's self-checking
mechanisms are extremely aggressive and damaging; see section 2.

"[InVircible] uses a unique generic virus behavior probe and
sampler" - actually, some anti-virus products (e.g., Victor Charlie,
VDS) have a similar decoy launching mechanism.

"[InVircible] uses unique programs that automatically check
themselves for, and restore themselves from virus infection" - and
they do it rather unreliably.

"[InVircible] features an interactive installation utility" - which
fails to perform proper installation.

"[InVircible] has an indispensable toolbox for computer security
experts and advanced users" - but rendered our hard disk
non-bootable twice during the tests and we had to resort to a more
professional tool like Norton Disk Editor to fix the damage.

"[InVircible] utilizes sabotage-resistant protection designed to
avoid both human- and virus-based deception" - but is trivial to
circumvent by both viruses and humans.

"[InVircible] is piggybacking resistant to prevent InVircible from
be coming a virus carrier" - but fails to succeed for some viruses,
as our tests have demonstrated; see section 7.2.

"Since the reliability of memory-resident activity monitors is
limited only to known viruses..." - this is clearly false; the
memory-resident activity monitors are generic anti-virus programs,
which detect virus-like activity and therefore may detect both known
and unknown viruses. It is the memory resident scanners (not the
activity monitors) that are limited to known viruses.

"IVB takes a 66 byte 'snapshot' (signature) of critical
information from each executable file..." - it doesn't. The
"snapshot" consists of much fewer bytes, since the 66-byte record
that IVB uses contains also the file name (13 bytes) a record
identifier (2 bytes), the file length (4 bytes), the file date (2
bytes), time (2 bytes) and two checksums (4 bytes). In fact, we
have determined that the information stored from each executable
file is no more than 28 bytes for EXE files and 37 bytes for COM
files (see the description of the checksum database record format
in section 7.6 of this paper).

"Common viruses will usually increase the size of a file, while
Trojan-Horses typically decrease the size of a file by overwriting
it." - we have yet to see a trojan horse that decreases the size of
the files. However, we know of several viruses that overwrite the
files (e.g., Burger) or even compress them and reduce their size
(e.g., Cruncher). On the other hand, InVircible certainly decreases
the size of some files by deleting them altogether or by removing
portions of them during various operations.

"IVB is tamper-resistant and will replace the database file of a
particular file, if tampered with." - but we were able to modify a
file, then decrypt its record in the database and "fix" it to
reflect the new size, header, and partial checksum of the file -
and InVircible didn't detect anything.

"IVB secures executable files (COM, EXE, SYS) only" - wrong,
version 6.01D also secures OV?, BIN, 386, VLM, and NLM files.

"For example, incidentally booting a disk which is infected with
Stoned with a floppy infected by Michelangelo will not boot anymore
by itself, although it can be booted from a DOS floppy. Attempting
to restore the partition with the FDISK command may end up with the
complete loss of the whole disk content." - in fact, FDISK/MBR is
exactly the simplest method to recover from this particular
situation.

"Some infectors such as FLIP will cause only minor changes,
perceivable only to the expert observer, some as Stoned will show a
message such as 'Your PC is Stoned, Legalize Marijuana!'" - Flip
turns the display image upside-down on EGA/VGA displays; you hardly
need to be an "expert" to notice this. As opposed to that, Stoned
displays its message very rarely - only when booting from an
infected floppy and even then with a probability of only 1/8.

"There are now at least two widespread such viruses, DIR-2
(Creeping Death) and 1963 (Niemela). These viruses are inherently
stealthy and propagate extremely fast. Standard passive scanners
are useless and harmful against these viruses. Countless hard disks
were unnecessarily destroyed by the use of passive anti virus
scanners against these two viruses." - rubbish. The author of this
paper is himself the author of freeware programs of the standard
scanner type, which are perfectly able to disinfect those two
viruses.

"MSAV, the virus scanner distributed with Microsoft's MS-DOS 6, is
an example of a passive scanner. Although it detects the 1963
(Niemela) virus and claims to clean it from infected files, in
reality it ruins all the files it 'cleans' from this virus." - while
MSAV is certainly one of the worst scanners around, criticizing it
in the documentation of a competing product is not very appropriate,
from the business ethics point of view.

"The presence of DIR-2 or 1963 is detected by InVircible programs
and is indicated by a warning message." - rubbish. inVircible fails
to detect about the half of the existing Dir-2 variants.

"The CPAV Inoculation or self integrity check is the cause of many
unexplained malfunctions." - while inoculation is indeed a bad idea,
why not just say so, instead of attacking a competitor's product?

"IVSCAN will remove the CPAV inoculation from files when in the
virus 'remove' mode." - but doing so on the programs from the CPAV
package itself, might prevent the latter from running.
Unfortunately, we couldn't test this, since the removal mode
requires some kind of authorization key and is probably available
only in the registered version.

"Anti virus TSR look only for viruses included in their database.
There are today as many as 5000 known viruses and their number
increases at a constant rate of 50 to 100 per month. This number
takes a heavy toll on the size of the database attached to the TSR
and occupies precious memory space." - again, the author does not
seem to have heard about memory-resident behavior blocking
programs and seems to think that the only kind of memory-resident
anti-virus programs are those of the scanner type.

"Anti-virus TSR can be aggressive, affect the computer's
performance, interfere with other applications, cause conflicts in
memory and are potentially dangerous! For example, a typical and
common AV TSR slows the computer by a factor of 3 to 5 and is
notorious for having knocked out many hard disks that it was
supposed to protect, without the slightest trace of any virus." -
maybe the author speaks about his own unsuccessful attempts to
write a good memory-resident scanner? A typical good
memory-resident scanner (e.g., Guard from Dr. Solomon's Anti-Virus
Toolkit) occupies only about 9 Kb of memory, has no noticeable
impact on the computer's performance, and detects all common
viruses and most of the other ones, for a total of 6157 viruses in
version 7.11.

"TSRs need to be constantly updated. The assumption that the
producer of the TSR will be the first to examine any new virus,
proved to be false in most cases." - it has been proved to be
perfectly true for most leading anti-virus producers - e.g. Frisk
Software International or S&S International.

"The TSR is useless against new viruses, neither will it detect a
known, but modified virus." - a behavior blocker TSR will.

"Practically, a TSR older than six months is out-of-date" - not
true for the behavior blockers.

"VSAFE, the anti-virus TSR distributed with MS-DOS 6, is a grim
reminder of this fact." - again an attack against a competitor's
product. Later in the documentation, a method is given how to fool
SCAN (another competitor's product) and to make it give a false
positive for the Jerusalem virus and damage the files it is trying
to repair.

"Weighing the pros and cons for and against anti-virus TSR leads
to the conclusion that TSR are a constant nuisance and threat to
the health of your computer." - but the documentation does not
even list any of the "pros", let alone "weighting" them.

"At this date, there are no known viruses that affect the
operation of Novell's Netware software." - wrong, several
Netware-aware viruses are known, most of which steal login
passwords.

"A file server can even be started with its MBR infected by Stoned
or Michelangelo..." - such an experiment certainly should be
avoided on March 6.

9.10. Unstable Distribution and Prices.

We are carefully watching most popular anti-virus products and
have noticed that in the past one-two years the status of
InVircible has changed multiple times. Originally, it was a
commercial product, distributed in Israel. Later, its author
obviously decided to market it around the world and that a
shareware anti-virus program will have more chances to become
popular. In those one-two years the product appeared under several
rather different prices and has been distributed by several
different companies. Here are some quotes from earlier versions of
the product:

1) Invincible Software Incorporated, InVircible Anti-Virus
Division, P.O. Box 24846, Seattle, WA 98124-0846, tel.
+1-800-984-1158 used to distribute the product for a price of
$89.00 a copy. The e-mail address listed for contact is
murphware@aol.com or murphwar@connected.com.

2) New Castle International, PO Box 267, Rye Beach, NH 03671, tel.
+1-603-431-6170, fax: +1-603-431-6370, used to distribute the
product for a price of $99.00 a copy.

3) FuturSoft Corporation, InVircible Anti-Virus Division, 4033
N.E. Sunset Blvd, Renton, WA 98056, tel. +1-800-NO-VIRUS used to
distribute the product for $129.00 a copy. Surprisingly, the e-mail
address for contact mentioned for this company is again
murphware@aol.com or murphwar@pylon.com. Could it be the same
person who had the first company, has gone bankrupt, and then
created a new company?

4) The latest offer seems to be Vine Computer Industry, PO Box
50124, Cicero IL. 60650, tel. +1-800-422-5130, fax +1-708-863-1917,
e-mail antivir@netcom.com, provides the package for $99.00 each
copy (with discounts available).

We are not experts in economics, but such a frequent change of the
price and the distributor does not inspire to us a confidence in
the economic stability of the company that produces the product.

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.
Everybody would benefit if the author of InVircible, instead of
bashing his competition, would concentrate his energy onto
improving his product and fixing the security holes in it. Those
holes have been pointed out to him long time ago and multiple times
by the author of this paper and by several others - but he doesn't
seem inclined to listen. Hopefully, public pressure from the part
of his users and/or potential customers will make him to decide
otherwise.

The general idea behind InVircible is correct - integrity checking
is indeed inherently a stronger line of defense against computer
viruses than scanning or behavior blocking. However, several
attacks against this kind of protection exist, and they ought to be
taken into account. Also, integrity checking alone does not provide
adequate protection. A sound anti-virus protection scheme must be a
multi-level one - providing both scanning and integrity checking,
and probably even monitoring, with accent on integrity checking. And
all the three parts of the defense must be as good as possible -
providing an integrity checker, even if it is a good one (which, as
we saw above, the one provided with InVircible is not), is by no
means an excuse to provide a bad scanner or no scanner at all. In
case the author(s) of the anti-virus product are unable to create
and maintain a good scanner (this is by no means a trivial task),
they should license the scanner from one of the best performers in
the field, instead of making their users' security a victim of their
own (inadequate) anti-virus product.

The bottom line is - InVircible is a very bad, insecure, and plain
dangerous product. Avoid it at any price, and use something better -
something that is secure and works. InVircible isn't and doesn't.

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
replicate viruses like 3APA3A, StarShip, and Strange;

- Zvi Netiv for requesting to review a copy of this paper before
publication. After examining it for about a week, he failed to
find any technical mistakes in the paper (or at least did not
report any). However, he didn't like the paper and threatened to
sue us if we publish it. Since we strongly believe in the right of
freedom of expression, this threat made our determination to publish 
the paper even more strong, for which we thank him;

- Stephan Tode for helping us to determine the checksum algorithms
used by InVircible;

- "Fernando" for telling us about the "!@#" parameter;

- "GJ" for testing the "SeeThru" technique on EIDE disks.

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.
Conf., September 1994, pp. 179-194. See also
ftp://ftp.informatik.uni-hamburg.de/pub/virus/texts/viruses/immune.zip

[DOSFrag] M. E. Kabay, "Conference Report: the First International
Anti-Virus Product Developers' Conference", Virus News and Reviews,
January 1992, pp. 2-7.

[Highland] Harold Highland, "A Macro Virus", Computers & Security, 8
(1989), pp. 178-188.

[Omud] Eugene Kaspersky, "8888: The Poor Man's Commander Bomber",
Virus Bull., August 1993, pp. 12-13.

[Quality] Klaus Brunnstein, Vesselin Bontchev, Wolf-Dieter Jahn,
"Methods and Requirements for Quality Assessment of Anti-Virus
Products", Proc. 1st EICAR Conf., 1992, Munich, Germany.

[Radai] Yisrael Radai, "Checksumming Techniques for Anti-Viral
Purposes", Proc. 1st Int. Virus Bulletin Conf., September 1991, pp.
39-68.

[Strange] Eugene Kaspersky & Vadim Bogdanov, "A New Way to Hide,
Virus Bulletin", April 1993, pp. 12-13.

[Tests] Vesselin Bontchev, "Comparative Tests of On-Demand
Known-Virus Scanners", Available electronically from
ftp://ftp.informatik.uni-hamburg.de/pub/virus/texts/tests/vtc/tests-01.zip

[VirLib] Vesselin Bontchev, "Analysis and Maintenance of a Clean
Virus Library", Proc. 3rd Int. Virus Bull. Conf., September 1993,
pp. 77-89. Also available electronically from
ftp://ftp.informatik.uni-hamburg.de/pub/virus/texts/viruses/virlib.zip

[WildList] Joe Wells, "The Wildlist", Proc. 4th Int. Virus Bull.
Conf., September 1994, pp. 175-177. Also available electronically from
ftp://ftp.informatik.uni-hamburg.de/pub/virus/texts/viruses/wild9409.zip
0
No votes yet
Your rating: None
PreviewAttachmentSize
vircing_the_invircible.zip52.82 KB