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.

 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.

Bookmark/Search this post with:

delicious | digg | reddit | newsvine | furl | google | yahoo | technorati