💾 Archived View for spam.works › mirrors › textfiles › virus › implemen.mca captured on 2023-11-04 at 16:01:46.
⬅️ Previous capture (2023-06-16)
-=-=-=-=-=-=-
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.