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
‹ "Vircing" the InVircible: 6. The Automatic Scan String Extractor (IVX).up"Vircing" the InVircible: 8. The Bootstrap Integrity Checker (IVINIT). ›
Bookmark/Search this post with: 
 delicious |  digg |  reddit |  newsvine |  furl |  google |  yahoo |  technorati