Vesselin Bontchev
1995
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.
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.
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.
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.
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).
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.
Part A:
Part B:
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.
The above algorithm will be bypassed by any read-stealth virus.
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.
The above algorithm will be easily bypassed by:
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
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).
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.
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:
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.
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:\DOS\4DOS\4DOS.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.
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.
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.
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:
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.
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.
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