IMPLEMENTING ANTI-VIRAL PROGRAMS Copyright (c) 1989 By John McAfee 4423 Cheeney Street Santa Clara, CA 95054 408 988 3832 In 1988 the Computer Virus Industry Association received over 25,000 requests for information about computer viruses from corporations, government agencies, special interest groups, and individual computer users. Questions ranged from - "How do I know if my system is infected?" to - "Where can I get a copy of a virus to play with?" A large number of organizations wanted to know if the CVIA recommended procedures or policies that would minimize infection risks (it does). A smaller number requested help in setting up in-house anti-virus training seminars. Some asked for help with removing an existing infection or with identifying the individual strain of virus that they had discovered. Others wanted to know why a particular virus infection kept recurring. A few wanted to know whether or not viruses really existed (is it all media hype?). One apparently legitimate caller wanted to know if any cases of human infections had been recorded - the winner in the imaginative question category. Within this body of requests, however, were two questions which have become the two most frequently asked (and most difficult to answer) questions concerning computer viruses. They are: "How can you tell whether or not a particular anti-viral program really works?" and "How do these products function?". At first glance, the answer to the first question seems obvious - test it and see. Just how, though, is not entirely clear to the average computer user. A person seriously trying to put together a test plan for validating anti-viral products will be faced with some staggering problems. Imagine yourself with such an assignment. The first problem that might come to mind is where to find a few dozen viruses that can be used as a test bed. Next (assuming that someone else will solve that problem or that it will otherwise go away), is how to go about running these viruses in a test environment without infecting your entire organization. If you overcome these first obstacles, you will then come face to face with the real issues: How do you measure the degree of the product's effectiveness, considering the fact that all viruses affect the computer system differently, and many show no measurable impact for months, or even years, after the initial infection? How do you test a product against "generic" viruses - that is - viruses that may not have been written yet but against which the product claims to be effective? (There are, by the way, effective generic anti-viral products). How do you even verify that a given virus has or has not infected the system during a test? Many viruses leave no externally visible trail - not even the size of the infected program will change. Additionally, many viruses have anti-detection mechanisms built in that make it extremely difficult to find the virus after an infection. These are just a few of the problems that will crop up during the development of an anti-viral product test plan. And the problems will not be helped by the slim likelihood of achieving points one and two above: You will likely find it difficult to acquire a test bed of live viruses and if you do, it is unlikely that you can carry out a successful extended test without endangering the rest of the organization. Experience has shown us that virus containment is a tricky task. They are extremely difficult to detect without special tools and they spread very quickly. Even if a completely isolated environment is used for testing, there will, from time to time, be a requirement to carry potentially infectious media into and out of the environment. The propensity for human error being what it is, a leak is virtually guaranteed given enough time or enough participants. There have been well meaning, but generally flawed attempts to solve some of the above problems through the development of virus simulators and specialized tools designed to validate anti-viral products. Most of the available utilities, however, were designed by the very people who manufacture and market the anti-virals, and their objectivity might be open to question. A second problem with these utilities is that not all virus activity can be simulated. Every new virus uses a different technique for trapping interrupts, bypassing the operating system or attaching to an application. Additionally, its technique for activating or causing damage will differ, and its basic replication mechanism will be unique. Because of these problems, the validation programs have limited utility. Does this mean the task is hopeless? Not at all. It simply means that some education is in order. The first thing needed is an understanding of just how anti-viral products work. By understanding what these products do, we can better address the question - "how effective are they?". Types of Products The virus problem has typically been addressed in one of three ways by individual antiviral programs: 1. By preventing generic viruses from initially infecting a system. These products are not keyed to any particular virus. They work by preventing any activity that could modify a program or executable segment of the system. 2. By detecting a generic infection after it has occurred. These products also are not keyed to any particular virus. They look for any modification that may have occurred to any executable component of the system. 3. By identifying specific viral strain infections and, usually, removing them. These products are effective only against known viruses. There has been much confusion about the relative utility of virus products due to a limited understanding of the above categories. Some critics, for instance, have stated that anti-viral products have limited utility because they only work against known viruses. This statement is valid, however, only for the third category of products. These products have been designed primarily to help remove existing infections and their benefit is apparent to anyone who has been infected and had used such products to clean their system. All of the more common virus strains are addressed by these products and a user's chances of acquiring a product that can fight a given infection are fairly good. Most such products list the specific viruses that they can remove. Another common misconception involves the "Vaccines". These products "inoculate" programs with a self test mechanism that can identify changes to the program. They are frequently thought of as prevention products because the word "vaccinate" connotes a preventive measure in general medicine. These products, however, are in reality infection detection products. They work only AFTER the program has become infected. Reviewers have frequently (and erroneously) pointed out that such products don't work because they didn't prevent a given infection. Likewise, infection prevention products have been panned because they were unable to "identify" a pre-existing infection. This confusion has reached a pinnacle in some of the organized efforts to formally evaluate anti-viral products. The test criteria for a product designed to remove an existing virus infection must be radically different from the test criteria for products designed to prevent the infection from occurring, and these criteria in turn will not be applicable to infection detection products. Yet numerous evaluations have been performed in which all three product types were judged by the same criteria. The results, to some minds at least, were completely meaningless. It must be understood that each product category is designed for different purposes, and is intended to be applied to different virus problem areas. A first prerequisite to testing product effectiveness, therefore, would be a solid understanding of what the product was intended to do, and how the product goes about doing it. How They Work Let's start with the infection prevention products. These products are all memory resident programs that re-direct system interrupts so that I/O and other selected system activities can be monitored. The programs then filter all activity that could indicate the presence of a virus and they notify the user of a potential infection. Attempts to modify the boot sector, write to an executable program or replace a hidden file are examples of activities that would be intercepted and flagged by such programs. Generally, any activity that appears to be an attempted modification of an executable segment of the system, such as a device driver, operating system module or application program, would be filtered. These programs are the first line of defense against viruses, and if properly designed and implemented, can prevent a virus from ever getting into a system. Since they can catch a virus before it can replicate, no removal or disinfection procedure is required and the virus usually has no time to do any damage to the system. These programs are also generic in their operation - that is, they can in theory catch viruses that have not yet been developed. This is because all viruses must replicate, and it is the generic replication process (i.e. attaching to an executable segment of the system) that is monitored by such products. These products, however, have three drawbacks which restrict the environments to which they can be applied and limit the effectiveness of their prevention abilities. The first drawback is that a fair amount of technical competence is required in order to use them effectively. Users must be able to discriminate between a legitimate program activity that is flagged by the product and a real virus threat. Numerous legitimate programs may at times perform functions that appear to be questionable. For example, some applications modify their own executable modules during their configuration phase. Compilers, assemblers and linkage editors legitimately modify or replace executable code. The DOS SYS command will legitimately modify the boot sector and operating system files. These and other programs may cause the anti-viral prevention product to flag the activity and notify the user. The user must then have a sufficient knowledge of the program or activity in process to determine whether to allow it to proceed or to terminate it. Many system users do not have the necessary technical depth to make a valid decision. A second drawback is the de-sensitization of the user caused by the false positives generated by these programs. If the prevention product flags too many legitimate activities, the user becomes conditioned to respond to the warning messages with a "continue" reply, without bothering to read the specific warning content. In many cases, real viruses have been detected by these products and the user ignores the warning message through course of habit. The third drawback to these products is that they rely on the virus being "well behaved" in its design structure. That is, they expect the virus to perform all I/O through normal system calls or software interrupts. Generally this is a reasonable assumption, since it is many times simpler to use the I/O facilities of the operating system than it is to develop your own basic I/O system. It also allows the program to operate on a wider variety of hardware without risk of program failure. Some virus designers, however, are beginning to take the extra effort, and run the increased risks, of interfacing directly to the hardware input/output devices. By doing so, they completely neutralize the infection prevention products' interrupt monitoring. No matter how cleverly software interrupts are trapped, or memory monitored, it is ineffectual if the virus never gives up processor control through an operating system call. In general then, we can say that infection prevention products provide the advantage of stopping a virus before it can infect your system and thereby prevent the virus from spreading. They also are effective against a large class of generic viruses. They should be used, however, only by competent system users, and - they contain a major loophole that can be used by sophisticated viruses to avoid the product's protection mechanism.. Infection Detection Products Infection detection products rely on the assumption that it is advantageous to discover an infection as soon as possible after it occurs. Viruses remain in systems for months or even years prior to activating and causing system damage. During this time their only activity is replication, and they take every precaution to remain undetected. Viruses require this "unobtrusive" phase in order to have the opportunity to duplicate themselves onto other systems - a necessary step in the process of spreading. Infection detection products, then, attempt to identify an infection as soon as possible after it has occurred, thereby limiting the spread of the virus within the organization and avoiding the virus destructive phase. Detection products operate in one of two ways: vaccination, or status logging. Vaccination products modify the system's executable code (programs, device drivers, etc.) to include a self test mechanism. This self test function will cause a warning whenever the code has been modified. The warning will occur at the time the code is executed. Status logging products, on the other hand, create a log file that contains all the information necessary to detect any questionable change in the system. The file usually contains a list of checksums of the executable code in the system, or it may contain other such information that can be used to identify change. A check function is then run periodically, usually at boot time, to evaluate the boot sector, operating system files, device drivers and all application programs. If a modification is discovered, a warning message occurs indicating the areas of the system that have become infected. It should be noted at this point that detection products will only work if the system is uninfected at the time the product is installed. If an infection has already occurred, the virus code will be logged as part of the program it has infected and the compare routines will never find the discrepancy. Detection products avoid the interrupt monitoring loophole of the prevention products. Because, irrespective of the sophistication of the virus infection mechanism, some segment of executable code will have changed after the infection has occurred, and detecting this change is usually a straightforward process. The disadvantage of such products, however, is that, unlike prevention products, the system must actually become infected before the flag is raised. Thus a disinfection process must be undertaken and there is also a slight risk that the virus will activate and cause damage before it can be detected. An additional drawback of the vaccination type of detection products is that many viruses cannot be detected using this method if they replace an entire section of code rather than modify it. Boot sector viruses are a prime example. They replace the boot sector with themselves. Thus, any vaccination code that had been applied to the boot sector would never have an opportunity to execute, and no warning would ever occur. This is a serious drawback of the vaccination approach. Infection Identification Identification products are designed to identify and, in some cases, counteract specific strains of existing viruses. They are not generic in function, that is - they cannot detect or remove viruses that are not commonly known. They work by scanning the system media, looking for characteristic code segments, identification flags or other signs left by a given virus strain. Since viruses are programs with specific functions and characteristics, each will have some unique discriminating attribute that can be used to distinguish it from the surrounding data and code indigenous to the system. Finding these unique attributes within the system is a certain sign of infection from the identified virus. Identification products perform two distinct functions: First, they can be used to scan a system and determine if it is infected with a given virus. Using multiple identification products (or a single product capable of identifying multiple viruses), a user can determine whether any of the more common viruses have already infected the system. This will provide a higher probability that the system is clean prior to implementing a prevention or generic detection product. Second, they are invaluable in helping to remove an existing infection from an organization. One of the major difficulties in removing a virus from an organization that has suffered a widespread infection is identifying all of the programs, files, removable media and other elements of the system that have been affected. Identification products can quickly and reliably size the scope of an infection and identify those elements of the system that must be disinfected. In many cases the products can, in addition, repair any damage that has been done and restore the system to its state prior to the infection. A great deal of manpower and other resources can thus be saved through the use of such products. Identification products are limited, however, in providing protection against newer viruses, or older viruses that may not have publicly surfaced. In order to develop an identification product, the virus must first be discovered and isolated. Then it must be disassembled and analyzed. Finally an effective countermeasure must be designed, implemented, and distributed to the public. The time lag for this process will stretch from a few months to a year or more. This "window of opportunity" for new virus developers will be a continuing barrier for such products. The three types of protection products that have been described above are not always clearly separable in the marketplace. Some products combine two or more programs, each addressing a single protection area, into a single package, much like a set of virus utilities. Other products may focus on a single type of protection but only provide a partial solution. For example, there exist infection detection products that will only detect changes to operating system files, ignoring all other executable code. All products to date, however, provide protection programs that can be grouped into one or more of the above categories. Important Features: Now that we have a fair understanding of what these products are doing, we can address the issue of "how well do they work?". Each type of product, it should be clear by now, should have a different set of criteria for judging performance. Let's take a look at these criteria: Infection prevention criteria: Infection prevention products should, at the minimum, be able to: - Differentiate between activities initiated by the user and activities carried out autonomously by programs. For example: Users may frequently delete or update program files or operating system segments, and this is a normal system activity. An application program, on the other hand, should not, under normal circumstances, modify another application program, an operating system program, or the system's boot sector. Such processes are indicative of virus activity. The infection prevention product should be able to discriminate between them. - Provide few false positives, or false alarms. Users become habituated to frequent false alarms and tend to overlook a valid virus warning when it does occur. - Run with other memory resident programs. Infection prevention programs are all memory resident and they modify a large number of software interrupts. This gives such programs a propensity for crashing or hanging the system when running concurrently with other memory resident programs. - Protect against modifications to all executable data, including the following: - The system's boot sector - All system device drivers - All operating system modules, including hidden file programs - All application programs - Provide an easily accessible enable/disable switch. Many instances will occur where the checking process will need to be temporarily suspended. A simple on/off switch is a necessity. - Provide the ability to selectively protect or ignore specific programs or specific areas of the system. This will reduce the number of false alarms when running programs which violate the "rules" imposed by the product. - Provide the ability to freeze virus activity when it is detected, and prevent the illegal access from continuing. This is mandatory to prevent the virus from infecting the system. - Run without noticeably degrading system performance. Memory resident programs have a tendency to increase system overhead and thus slow down the system. A well designed product should cause no more than a 5% degradation in system performance. - Monitor and protect all attached read/write devices. All attached devices that can be written to are potential virus targets. The prevention product should protect all such devices. - Selectively prevent all interrupt level I/O. An additional degree of protection is provided if the product disallows programs from performing non-standard calls for I/O service (interrupt level requests). However, doing so increases the false alarm rate. The user should have the choice of allowing or disallowing such calls. Infection detection criteria: Infection detection products should at a minimum be able to: - Detect characteristic viral modifications to all executable data, including the following: - The system's boot sector - All system device drivers - All operating system modules, including hidden file programs - All application programs - Allow the user to selectively exclude specific programs or specific areas of storage from the checking function. This will allow programs or directories that undergo frequent change to avoid causing error messages during the checking process. - Perform global check functions in a timely fashion. If the check function is executed at boot time, for example, it should add no more than 10 seconds to the boot sequence for each 50 programs on the disk that must be checked. - Provide automatic checking. The check function should execute at least each time the system is powered on or re-booted. Some systems provide a clock function so that the system can be checked automatically at user specified time intervals. - Stop the system, provide a visual and audible warning, and wait for user directions if a potential virus is detected. - Display the names of all infected programs, or clearly identify the areas of the system that have become infected. Infection Identification Infection Identification products should be able to: - Identify and remove multiple virus strains. The number of existing viruses continues to increase. So, when an infection occurs, it is not always possible to positively identify the infection strain. The more viruses that the product can distinguish, the better the chances of identification. - Provide information that will allow the user to determine how accurate the diagnosis may be. In some circumstances, identifying a given virus is not as precise as one might think. This is because many viruses have been slightly modified by unknown hackers and re-introduced into the public domain. These modified viruses can sometimes only be detected by cross referencing many different characteristics. The product should provide the degree of certainty, or other information that can be used to determine a course of action, for any questionable virus. - Identify and report on all areas of the system that are infected. It is important to know the extent of infection, and the product should provide that information. - Inform the user about the degree of success for the removal. Depending on the time that the virus has been in the system, removal may or may not be possible. The product should inform the user of possible options in a questionable situation. The options available should include automatic removal or erasure of the affected system element. - Scan and remove the infection from all attached devices. This should include floppies, fixed and removable hard disks and tape devices. - Automatically scan all subdirectories. The product should be capable of locating all areas of the system where the infection may have lodged, without user assistance. - Flag all areas of the system where removal was partially or completely ineffective. These areas must be manually dealt with after the program finishes. - Prevent itself from becoming infected during the identification and removal process. This is a real danger for many of the identification products. An infected identification product will run the risk of infected every system on which it is used. Testing Procedures Now that we have seen how these products work and we have been exposed to the central criteria for evaluating them, we are ready to begin the actual testing. The effectiveness of these products can usually be determined without having to use specialized tools. All that's required is a word processor or text editor, a good disk utility such as the Norton Utilities, a knowledge of common operating system commands and a sound understanding of the issues we've discussed so far. The test procedures that are recommended below will possibly not provide the degree of product assurance that could be ascertained by experienced virus specialists testing in a laboratory and using live viruses. They will, however, provide a great deal more information about the product's performance than could be gleaned from reading the product documentation or sales literature. They will also provide more information than quite a few of the published product reviews that have been performed, if only because you will gain hands on experience with the product in your operating environment. Any product that performs well in the following tests is guaranteed to provide some degree of real protection. Let's start with the infection prevention products: Infection Prevention Product Testing: These products, remember, are basically filter programs that monitor the system and try to prevent viruses from initially infecting programs or other executable components. The testing should determine how well the products protect these system elements from modification. The tests should also determine how sensitive these products are to valid system activities that might trigger a virus warning. The ideal product will catch all truly questionable activities while ignoring all normal system activities. The following procedures will provide a good indication of the product's effectiveness: (Be sure to install the antiviral product prior to running these tests). I. Program modification test To test the product's ability to protect general executable programs from being modified, create a temporary subdirectory and copy your word processor or text editor into the subdirectory. Create two output text file named TEST, one with a .EXE extension and the other with a .COM extension. Then attempt to update the file using the word processor or a text editor. If the antiviral program is working properly, it should flag both the creation and the update as a potential infection. Next create output files named IBMBIO.COM, IBMDOS.COM and COMMAND.COM. Attempt to modify them. Each attempt should be prevented. Finally, create output files with the same names as each of the installable device drivers in your system. (check your CONFIG.SYS file to determine the names of your device drivers if you do not already know them). Attempt to modify each of them. Each attempt should be prevented. Repeat each of the above steps using a floppy diskette as the output device, instead of the hard disk subdirectory. The same results should occur. II. Interrupt level I/O test Next, we need to test the product's ability to prevent interrupt level I/O. To do this, first copy the FORMAT routine to a file named TEST.COM. Run TEST and format a floppy diskette in the A or B drive. The antiviral program should prevent the format and flag the attempt. III. Operating system command test We next need to check the use of operating system commands. User commands are frequently, and erroneously, flagged by antiviral products when they instigate operations that mimic virus activities. It is important to select a product that can discriminate between activities instigated by the user and those that occur through program processes. To test this capability we use some standard DOS commands. Using standard COPY, DELETE and RENAME commands, copy an executable program into a different directory, rename it to another EXE or COM file name, and then delete it. None of the three operations should be flagged by the antiviral program. IV. Copy, rename and delete test Next we should verify that the above functions would be stopped if performed by a program, rather than by the system user. Using any application utility program that has copy, rename and delete functions (such as X-TREE, Norton Utilities, etc.), repeat the above series of steps. The antiviral program should prevent and flag all three attempts as potential viral activities. V. Self modification test Many programs modify their own executable modules at some point. This is not characteristic of viruses, and the process can in no way lead to the spread of the virus. The antiviral program should not flag or prevent any attempts of a program to modify itself. To test this, copy your word processor executable module to a backup file. Then run the word processor, create a dummy document, and then save it to the name of the executable word processor module (for example, using Word Perfect, you would save the file to the name - WP.EXE). The antiviral program should allow the modification. After this test, copy the saved version of the program back to its original name. VI. Boot sector test Attempt to modify the boot sector to check the product's ability to prevent the attempt. It is very important in this step that you be able to restore the boot sector in the event that the product's protection mechanism fails. Using any utility that allows reading and writing the boot sector (the Norton Utilities is an example), read the boot sector and write down the contents of the first byte. Change the first byte to 00 and attempt to write the sector back to disk. The product should prevent the attempt. If the product fails, replace the original contents of the first byte and re-write the boot sector. The re-write should be performed prior to shutting down or re-booting the system. VII. Memory resident check Many viruses modify the original structure of programs so that they remain memory resident after they terminate. The antiviral product should detect any attempt to remain resident. To test this feature, merely take any normally memory resident program, such as SIDEKICK or CACHE, and rename it to the file TEST.COM (or .EXE, depending on the program). Run TEST. The product should catch the program and display a warning message. In addition to the above tests, you should create a checklist of the product criteria discussed in the previous section and review such functions as the enable/disable switch, selective protection and other issues identified. Infection Detection Product Testing These products identify an infection after it has occurred. Testing should focus on detecting modifications to executable components of the system, such as the boot sector, the operating system or an application program. Before we describe the test procedures, however, a note of explanation about how viruses attach to programs is necessary. Viruses can attach to the beginning, to the end or to the middle of a program, or any combination of the three. They may fragment themselves and scatter virus segments throughout the program. Or they may even keep the main body of the virus unattached to the program, hidden in a bad sector for example. All viruses that have been discovered, however, have modified at least some small portion of the beginning instructions of the program. This is because a virus must be executed first, that is - before the host program to which it has attached. If the virus does not execute before its host program, then the environment in which the virus "wakes up" will be uncertain, and the possibility of program failure will be high. The exceptions to the this "positioning" rule are viruses that replace the entire program, such as boot sector infectors, and viruses that attack only specific programs, like known operating system files or other programs that would be commonly found in large numbers of systems. These viruses may gain control at any point, since the structure of the host program is well known and the environment can be predicted at any point in the host program's processing. The implications of this virus attachment profile are very important: Many detection products make use of this profile to speed the system checking function. If every byte of every program is processed in the checksum or other comparison technique, then global checking functions (scanning the entire system) may take substantial time to complete. Systems containing many hundreds of large programs (a common occurence), may require anywhere from 5 to 15 minutes to complete the audit. Since a global scan should be performed at least daily, this time requirement is a significant nuisance to the average user and a deterrent for the implementation of the product. Products that only look for the characteristic initial instruction modifications, on the other hand, would complete the same audit in a matter of seconds. All products, however, should perform a complete check of "universal" programs. These include the boot sector, the operating system files and the command interpreter. Armed with this information, we are now ready to begin the tests: I. Boot sector replacement Using a disk utility program, blank out the "Boot Failure" message within the boot sector (this is merely a safe way to create a unique boot sector). Then install the detection product you wish to test. Next, replace the entire boot sector using the SYS command (see the DOS user's guide for instructions on using this command). Then execute the check function of the product you are testing. The product should warn that the new boot sector is a replacement. II. Boot modification Next, re-install the detection product. Then modify the boot sector randomly using the disk utility. Run the check routine. The product should warn that the boot sector has been modified. (When finished with this step, perform the SYS command again, or use the disk utility to return the boot sector to its original state). III. Program deletion Copy a number of COM and EXE files to a temporary directory and then delete them from their original directories. Run the detection check function. The product should identify each of the missing programs. IV. Program modification Next, copy the programs back from the temporary directory to their original directories. Using your disk utility, modify the first byte of each of the COM programs. Modify the entire first 500 bytes of the EXE programs. Run the check program. Each modification should be detected. At this point you should replace each of the modified programs from the original programs stored in the temporary directory. V. Program replacement Replace one of the application programs with the origional program from the program distribution diskette. Then modify the program as above. The check function should still catch the modification. VI. System modification Using your disk utility, copy COMMAND.COM, IBMBIO.COM and IBMDOS.COM to backup files. Randomly modify each of the original files using your disk utility. Change only one byte in each. Run the check routine to determine that the modifications have been detected. Perform this step multiple times with different modifications. In addition to the above tests, you should create a checklist of the product criteria discussed in the previous section and review such functions as selective protection, automatic checking, visual warnings and other issues identified. Infection Identification products It is virtually impossible to test these products in the absence of a real infection, so I will assume that you would be evaluating such a product in order to rid yourself of an actual infection. I do not recommend that you obtain samples of real viruses in order to test these products. The ultimate test for these products is: Did it identify and remove the infection, and if so, how thouroughly? Performing the test is quite simple. The first steps are to isolate the infected system from all other systems, and to aquire clean, original copies of the infected programs. Make working copies of these uninfected programs onto separate floppy diskettes, one sample program per diskette. Insert each floppy in turn into the infected system and run each sample program. This, in most cases, will cause the diskette, or the program, to become infected. Using a disk utility, now do a binary compare of the infected diskette to the backup copy. If an infection has occurred, the diskettes will differ. Separate all working copy diskettes that have been modified by the virus and label them as infected. Now run the identification program against each of the infected floppies. Do this on a clean, uninfected system. The program should identify the infection on each diskette. Next cause the program to attempt removal. Run each floppy in turn through the removal cycle. The program should remove all of the infections. To test that the removal worked, take the infected (and now hopefully disinfected) diskettes and again do a binary compare against the original backup diskettes. There should be no discrepancy. If the program has passed the above tests, it is clearly able to identify and, at least in test disks, remove the infection. At this point you should test its operation on the infected system. To do this, first make a backup copy of the product. Then load the identification program into the infected system and begin the identification and disinfection process. On completion of the operation, perform a disk compare of the working disk against the original product disk. There should be no diferences. In addition to these tests, you should review the criteria for these products that we discussed in the previous section and determine such factors as usability and performance.