|
A comparison of programs that detect changes to ot
NOTICE: TO ALL CONCERNED Certain text files and messages contained on this site deal with activities and devices which would be in violation of various Federal, State, and local laws if actually carried out or constructed. The webmasters of this site do not advocate the breaking of any law. Our text files and message bases are for informational purposes only. We recommend that you contact your local law enforcement officials before undertaking any project based upon any information obtained from this or any other web site. We do not guarantee that any of the information contained on this system is correct, workable, or factual. We are not responsible for, nor do we assume any liability for, damages resulting from the use of any information on this site.
Comparison: Products to Detect Changes to Programs
Prepared by David J. Stang, Ph.D.
and © 1990, 1991 by
the National Computer Security Association
Suite 309, 4401-A Connecticut Ave NW
Washington DC 20008
Voice: 202-364-8252
BBS: 202-364-1304
This document may be freely distributed, but may not be altered
in any way.
This is a review of some of those checksum or CRC comparison
programs. In it, I make an effort to concisely describe the
merits of this class of products, and then to help
you in selecting a product from their ranks.
There is a difference between checksum algorithms and CRC --
cyclic redundancy check -- algorithms. The latter usually uses a
table, and is usually a bit slower than the former. Despite the
differences, many authors seem to use the words
interchangeably, and we will continue the sloppy practice in this
chapter.
Each file has a unique fingerprint in the form of a checksum
or CRC. Changes in any character within the file likely change
the checksum or CRC. If a file's original CRC is known --
perhaps recorded in a file elsewhere -- and its current CRC is
known, the two values can be compared. Any difference indicates
that the file has been changed, and offers reason to investigate
further. For example, DELOUSE allows you to build a list of
critical system files that are normally subject to attack, and
check them periodically for changes.
If a program's size is changed, it must be concluded that some
modification has occured to the file. If the size has not changed,
some modification is still possible. A file that contains the simple
message Hi Mom! could be modified so that it contained the
message Hi Dad!, and it would not show any change in size.
A much tougher test of whether a file has been modified is to
compute the checksum or CRC cyclic redundancy check. At
this writing, there are no viruses able to modify a file without
modifying the file's CRC. Thus any checksum checker will work
just fine in catching viruses, providing that you use it to
establish checksums before a virus has modified your files.
How is the checksum computed? Simply adding the values of all
the characters in the file is not enough, as a file containing just
"AE" would produce the same result as a file with just "EA".
Rather, the first byte of a file is read, and an algorithm applied
to it. This algorithm does something to the value of the byte,
such as rotating the bits a certain number of times, and logically
ANDING or ORING the bits to something else. The result of
that algorithm is then applied to the next byte of the file. The
process is repeated until the final byte is reached, and the
remainder is recorded. During this process, different algorithms
might be used for different portions of the code being processed.
With most procedures, a small file produces a checksum value of
the same size as a large file.
Is there such as thing as "the" CRC value? No. The algorithm
used defines the result. There are two popular algorithms in use:
a standard CCITT CRC and a popular XMODEM CRC. Consider
COMMAND.COM for DOS 3.3 dated 2/2/88 and taking 25308
bytes. Here are some of the checksums produced for this file by
various programs. SSCRC and Validate (method 1) use the
CCITT standard. All others in the list use some other approach.
o BSearch, 16-bit CRC - 13369 (3439 h)
o BSearch, CRCTT - 10994 (2AC0 h)
o CHKSUM - 20011 (4E2B h)
o CRCDOS - 59676 (E91C h)
o Delouse, method 1 - 1073916 (1062FC h)
o Delouse, method 2 - 1067428 (1049A4 h)
o Delouse, method 3 - 1048666 (10005A h)
o The Detective, CRC 1 - 26939 (693B h)
o The Detective, CRC 2 - 54914 (D682 h)
o Module Integrity Check - 24922 (615A)
o SSCRC - 52167 (CBC7 h)
o Validate, method 1 - 52167 (CBC7 h)
o Validate, method 2 - 4024 (0FB8 h)
o VCheck - 2141344 (0020ACA0 h)
WHY DETECT CHANGES?
There are several good reasons.
o Viruses have great difficulty infecting your machine
without making some change in it. To detect a change
is to begin the process of detecting a virus. Although
some are concerned that a change-detecting program
cannot prove there isn't already a virus in your
computer, the fact is that you needn't worry about this.
If you infect your computer with a dozen viruses, then
measure its state, one of these viruses will change that
state in the next hour or so; a remeasurement
establishes that something is afoot.
o Occasionally things go wrong with computer hardware
and software. You run CHKDSK and discover a
number of lost clusters in a number of lost chains. You
scrap these clusters, but wonder what files you've lost.
A proper change-detection program will give you a list
of files deleted since your last run. You can then
restore them from your backups.
o In many organizations, we only want to permit the use
of "authorized software." Using a proper
change-detection program, you can establish what
software was added to the machine since your last run.
Any "extra" software will quickly come to your
attention.
CAN A VIRUS BEAT THE SYSTEM?
The answer may be yes. You need to know how, so it doesn't
happen to you. The defeat can come at the hands of a
CRC-aware virus (none exists yet) or at the hands of a stealth
virus (there are several now).
CRC-AWARE VIRUSES
In theory, a virus could be written that would compute a file's
CRC, add itself to the file, then replace additional characters
from the file until the new CRC was the same as the old one.
Such a virus would escape the attention of many checksum
checkers.
Programs could catch such a virus by using an incremental
cyclic redundancy check approach. In this approach, files are
dissected into randomly-sized blocks of data, using dynamic
block size allocations that allow files as small as one byte to be
accurately checked. CHECKUP uses this approach. It scans and
compares every byte of the target files on a block-by-block basis.
If the recorded file sizes, any of the block CRC comparisons, or
the CRC totals do not match, CHECKUP alerts users that the
target files have been altered.
Another approach to the problem is to compute the check in two
different ways. For example, if both a checksum and a file size
were to be calculated and recorded for later comparison, it is
unlikely that a virus could be modified without mismatching on
one of the comparisons. Or if checksums were to be calculated
using two different algorithms, the virus would again likely fail
to fool both techniques.
Thus if some future virus were to compute checksums prior to
infections, pad their viral code with characters that maintain
checksum integrity and then infect, CHECKUP could catch it.
STEALTH VIRUSES
A stealth virus is able to defeat a checksum program if it loads
into memory before the checksum program runs. The stealth
virus can then detect the checksum program as it attempts to
read each program on the disk, and before letting the checksum
program see the file it is trying to read, extracting the virus
from it. After the checksum program is satisfied that there is no
virus in the file, the virus in memory can re-insert it into the
file just checked.
Such a problem can be easily avoided: simply boot the system
from an uninfected floppy, then run your checksum program
from it.
In the tables presented here, space has been provided for you to
rate an additional product.
PRODUCT COMPARISONS
EASE OF USE
Conducting these evaluations was not easy. In the table below, I
record my joy or frustration in trying to master the program.
Alert
This program makes claims of ease of use, with a
pop-up, drop-down menus, mouse support, nifty sound
effects, and the like. But the blinking text on the
screen will certainly drive you crazy, if you are still
sane after waiting, Alert would like to run McAfee's
scan every time you add a file to the list it will check;
it doesn't accept wild cards, so if you thought you
would do a checksum on all of your files, assume that
you won't be able to install it in less than a week.
Installation and simple evaluation took 53 minutes.
The Antibody Test
Antibody's installation is extremely easy, if it works.
You cannot simply copy the files to your hard disk --
you must let Antibody do it for you. In the process,
Antibody wants to check the integrity of your
distribution disk. If you have any alien file on this
disk, Antibody will abort after 3 or 4 minutes of
self-examination. Beat the system by clearing the
read-only and hidden attributes of SIGNATURE.DAT,
then rename it. Antibody will create a new file for you
and proceed. The manual includes a comprehensive list
of error messages and their meanings.
BSearch
No installation required! Copy BSEARCH.EXE to
anywhere on your hard disk, and run it with the
obvious wildcards. For example, BSEARCH C:\*.* will
examine everything.
CHKSUM
Simply copy to anywhere on your hard disk and enter
"CHKSUM". You'll be prompted for what you should
have entered.
Checkup
The most difficult of all the packages reviewed here.
Documentation spans five files, and numbers almost
100 pages. With such a mass of instructions, you are
unlikely to have any success in installing the program.
The verbosity extends to the log file, which you can
create to record any file mismatches. The log file for a
single run on 183 files was 270K - nearly 2K per file.
Should you try to use the product on a large hard disk,
your log would be worthless.
CRCDOS
As with CHKSUM, simply copy to anywhere and go!
Instructions will appear on the screen if you simply
enter "CRCDOS."
Delouse
It took just four minutes to completely understand how
Delouse works and to begin building the file of CRC
values. Installation is nothing more than copying a few
files to anywhere on your hard disk. Delouse can also
be run from a floppy.
The Detective
Copy and go. When first run, the program pops up a
simple menu that works very well. You'll be asked
what drives to process and what file extensions to
check. Entering * will process everything. You'll be
asked if you also wish to scan for viruses (meaning to
compute CRCs) as you produce the file list for
subsequent checks. Also, The Detective keeps itself
up-to-date with each run. On every run, the most
recent signatures are copied to the "old" list, and new
signatures are computed for comparison.
F-Prot
Copy F-OSCHK to any location on your hard disk and
enter F-OSCHK. It will display five numbers which are
encrypted checksums of the partition table, boot record,
and three operating system files. AUTOEXEC.BAT can
then be given a line beginning with (path) F-OSCHK
and followed by these five values.
FICHECK
Seemingly easy to use. Can be run from a menu or as a
command line in a batch file. However documentation
for the command line operation is poor, and misleading.
Module Integrity Check
Copy the file MIC to anywhere on your hard disk and
enter MIC. There are no menus, nothing to select.
You'll create a list of CRCs, if none exists, in your root.
If one exists, it will be renamed "OLD", and another
will be created. The two will be automatically
compared. You'll be notified of any changes, any added
files, and any deleted files. You'll also be notified if
nothing has changed. All information is automatically
sent to reports in the root. Nothing could be simpler.
Novirus
Copy the program to anywhere on your hard disk, and
it makes a hidden file in the root containing what it
claims is encrypted CRC, file date, time, and size
information for each of the three system files.
Installation and use are very easy.
SSCRC
Very easy. Copy the file to your hard disk, and run the
program. Onscreen instructions tell you to enter /F to
create the File of CRCs or /C to Check files against
these CRCs. Requires ANSI.SYS
Validate
Very easy to use for finding the CRC of a single file.
Simply copy VALIDATE to your drive, and run it.
Impossible to use for checking the CRCs of all files, as
it does not work with a list, does not accept wildcards,
and will not compare current CRC with stored CRC.
VCheck
Fairly straightforward. You may need to follow the
example in the manual to guess the spacing required
for parameters in the command line. Results are
displayed on your screen, and you'll need to press a key
to continue scanning, after the screen fills. This
ensures you'll spot a surprise change in a file, but
doesn't deliver the kind of power that suits it for a
batch file. Not menu-driven.
VirusGuard
Simply type INSTALL. VirusGuard will install itself on
your hard disk and scan all COM and EXE files for
their signatures. It will also modify your
AUTOEXEC.BAT to automatically invoke RAMWATCH
on subsequent boots. Our copy of the program did not
come with documentation, however, so we are a bit
limited in our review here.
NUMBER OF TECHNIQUES
The program should compute checksums using two different
approaches, or compute both file size and checksum, to ensure
that a virus doesn't modify a file in such a way that the
checksum isn't changed. Gilmore Systems has a program called
PROVECRC that creates a modified version of a file that is
different, but that has the same CRC as the original. The
program proves that a single CRC is not fool-proof for virus
detection, for it is possible to write a virus -- much like they
wrote PROVECRC -- which can add code to your programs
without changing the CRC. When two algorithms are used,
PROVECRC creates changes undetected by one, but detected by
the other.
Alert
Alert uses different algorithms on different portions of
each file. A file records the results of these algorithms
in encrypted form in a file which covers all of a group
of files you wish to check. It is very unlikely that any
virus author would have the interest or patience to
break the scheme.
The Antibody Test
Antibody lists all files added or deleted since the last
comparison, as well as showing any changes in size,
date, time, or attributes.
BSearch
Stores filenames (with paths), file sizes, 16-bit and
32-bit checksums in an indexed databases. Uses a
binary tree indexed database structure to store the files
quickly and allow even quicker searches and updates.
CHKSUM
Uses a single 16-bit checksum approach.
Checkup
Offers three different options for calculation:
table-driven incremental CRC, cumulative CRC, and
cumulative checksum.
CRCDOS
Uses a single 16-bit checksum approach.
Delouse
Uses three different checksum algorithms. All are
simple, but slightly different in the way they calculate
the checksum. One of these algorithms is chosen at
random when Delouse starts, and the method number
is recorded in a data file. You can force Delouse to
choose one of the three methods if you wish.
The Detective
Uses two different 16-bit CRC algorithms.
F-Prot
F-OSCHK uses just one algorithm.
FICHECK
FICHECK uses one 16-bit algorithm, MFICHECK uses
another. Both are bundled in the same package.
Module Integrity Check
Uses one 16-bit algorithm.
Novirus
Appears from testing that Novirus uses no checksum or
CRC algorithm, despite the claims of its
documentation. Using a sector editor, for instance, the
word "Microsoft" was changed to "Machosoft" in
COMMAND.COM. Novirus was unable to recognize
this. I changed the attributes of the hidden system
files, and again Novirus failed to detect the change. I
renamed COMMAND.COM, infected it with Jerusalem,
and renamed it to COMMAND.COM. Novirus
recognized the change, but only because of the
increased file size. When I used NU to reduce the size
of the infected file to its original size, as listed in the
root directory, Novirus did not recognize it as a
problem. It appears that no checksumming is done,
although this is claimed in the documentation. Checks
on file existence, date, size, and time do appear to be
done. For instance, I booted, deleted COMMAND.COM,
and ran Novirus. Novirus halted the system. It also
halted the system when I used NU to increase the size
of COMMAND.COM to 999999999.
SSCRC
Uses one 16-bit CCITT CRC algorithm.
Validate
Uses two 16-bit algorithms, one of which is CCITT
CRC.
VCheck
Uses one 32-bit algorithm.
VirusGuard
Appears to use one algorithm. CRCs are encrypted.
SCANNING OF CRITICAL SYSTEM FILES
On an MS-DOS hard disk, there are five critical system files
that are read during the boot process: the partition table, the
boot record, two hidden system files, and COMMAND.COM.
Because many viruses take up residence in the partition table,
boot record, or COMMAND.COM, it may be desirable to check
these files on each boot. Not all CRC programs, however, can
check all of these files. Two points are awarded for each file it
can check. Note that viruses rarely touch the two hidden system
files, and many do not touch COMMAND.COM Quite a few,
however, get into the partition table of the hard disk or boot
record of floppies.
Alert
Alert cannot examine the partition table or boot record.
It can check the other three files.
The Antibody Test
Antibody does not check the partition table. It does
check the other four files automatically, however.
BSearch
Does not scan partition table or boot record.
CHKSUM
Does not scan partition table or boot record.
Checkup
Does not scan partition table or boot record.
CRCDOS
Does not scan partition table or boot record.
Delouse
Does not scan partition table or boot record.
The Detective
Does not scan partition table or boot record. Further,
the evaluation version (reviewed here) will not examine
anything in the root, which is certainly the two hidden
system files and likely COMMAND.COM.
F-Prot
F-OSCHK scans all five files.
FICHECK
Automatically checks the CRC of the partition table
and the boot record, and logs this along with available
disk space and FAT ID byte. For all files checked, logs
date, time, size, attributes, and CRC, and reports any
discrepancies. Checking of hidden system files,
COMMAND.COM, etc. is at user discretion.
Module Integrity Check
Does not scan partition table or boot record.
Novirus
Does not scan partition table or boot record.
SSCRC
Does not scan partition table or boot record.
Validate
Does not scan partition table or boot record.
VCheck
Does not scan partition table or boot record.
VirusGuard
Does not scan partition table or boot record.
COMPLEXITY OF CHECKING ALGORITHM
A 32-bit CRC is potentially harder for a virus to beat than a
32-bit CRC; a pair of calculations is harder than a single
calculation. In this table, 10 points are awarded for the use of a
32-bit CRC or two 16-bit CRCs; 5 points for a single 16-bit CRC;
0 for no CRC.
Alert
Algorithm is not discussed in the documentation.
However, the encrypted CRC for just one file is 748
bytes - about 5% of the checked file's length. This
suggests that the algorithm is essentially unbreakable.
The Antibody Test
Algorithm is not discussed in the documentation.
However, the encrypted CRC for just each file is 128
bytes. This suggests that the algorithm is essentially
unbreakable.
BSearch
Performs both 16-bit and 32-bit checksums.
CHKSUM
Performs CRC-16 -- 16 bit cyclic redundancy check.
Checkup
Performs CRC-16 -- 16 bit cyclic redundancy check.
Results are encrypted.
CRCDOS
Performs CRC-16 -- 16 bit cyclic redundancy check.
Delouse
Performs CRC-16 -- 16 bit cyclic redundancy check.
The Detective
Performs both 16-bit and 32-bit cyclic redundancy
checks.
F-Prot
Not described in documentation. Encrypts recorded
checksums. Uses only one algorithm.
FICHECK
Computes CRC with FICHECK, modified CRC with
MFICHECK. You can run both, if you wish, to defeat
any imaginary virus that is able to defeat one of these
approaches.
Module Integrity Check
Computes a checksum on part of the file. Uses only one
algorithm.
Novirus
Does not appear to do any CRC/checksum computation.
SSCRC
Uses only one algorithm -- a 16-bit CCITT standard
CRC.
Validate
Uses two 16-bit algorithms, one of which is CCITT
CRC.
VCheck
Uses one 32-bit algorithm.
VirusGuard
Unknown.
SPEED WHEN CHECKING ALL FILES
From time to time, it may be desirable to check all files on the
hard disk for changes. However, if this process takes a long
time, users will not do it as often as they should. What is the
speed of checking files?
For our tests, we did CRC calculations on a 20Mb hard disk in a
12Mhz XT. The XT had a Norton SI of 1.8 for its computing
index, and 1.4 for its disk index, an overall performance index of
1.6 that of an IBM XT. It had a total of 2.3 Mb in 134 files in 19
directories. In each case, the checksum program was run from a
floppy. Timing was done with a shareware program called
TIMER. Numbers reported here are per file. Since it is not the
number of files, but the number of bytes, that determines the
overall speed of operation, your times will vary if your files are
larger or smaller, on average, than those in the test suite. Our
average file was 18,651 bytes. So to say that scanning files took
about 2 seconds a piece is to say that the program could scan
9,325 bytes per second. A 20 Mb hard disk, full to the brim,
would take such a program 37 minutes to scan fully. If you
restricted the program to COM, EXE, OVL, BIN, SYS, and other
executable files (an intelligent restriction), you might cut this
time in half or more.
Alert
I could not imagine waiting while Alert checked all
files on the hard disk. Scanning just one file took 13.5
seconds. Checking the 2.3 Mb on the test hard disk
would have taken about 17.5 minutes. This is
unacceptable.
The Antibody Test
Antibody is slow, but not as slow as some of the others
tested here. It took 6 minutes, 14 seconds to scan all
programs on the hard disk -- 71 files, about 5 seconds a
piece.
BSearch
Building the initial database of all files -- including
manuals and other files -- took BSearch 10 minutes, 35
seconds -- about 4.7 seconds each. Then scanning
against this file took 10 minutes, 20 seconds -- about
4.6 seconds each.
CHKSUM
To compare the three DOS files with CRCs previously
computed took 5.6 seconds, about 1.9 seconds each.
Testing everything in the root took 13 seconds for 8
files, about 1.6 seconds each.
Checkup
To build a list of CRCs for 183 files took 9 minutes, 16
seconds, about 3 seconds each. It took 8 minutes, 35
seconds to use the author's proprietary "enhanced"
CRCs, about 2.8 seconds each. Using the checksum
approach took about 2.8 seconds each.
CRCDOS
To build a list of CRCs for 146 files, CRCDOS took 6
minutes 27 seconds, about 2.6 seconds each. Testing
everything on this list took 6 minutes, 24 seconds,
again about 2.6 seconds each.
Delouse
To build a list of CRCs for 146 files, Delouse took 2
minutes 38 seconds, about 1.1 seconds each. Testing
everything on this list took 2 minutes, 35 seconds,
again about 1.1 seconds each.
The Detective
To build a list of CRCs for 146 files, The Detective took
3 minutes 57 seconds, about 1.6 seconds each. Testing
everything on this list took exactly the same length of
time.
F-Prot
Scans five system files in 10.0 seconds, 2 seconds per
file. However, F-OSCHK cannot be made to calculate
checksums on any files but these.
FICHECK
To build a list of CRCs for 146 files, FICHECK took 5
minutes 27 seconds, about 2.2 seconds each. Testing
everything on this list took 5 minutes, 24 seconds,
again about 2.2 seconds each.
Module Integrity Check
To build a list of CRCs for 146 files, MIC took only 1
minute 30 seconds, about .6 seconds each! Testing
everything on this list took the same length of time.
The program achieves this blazing speed by performing
a checksum only on the parts of the file that a virus is
likely to infect: the top and the bottom.
Novirus
Scans three system files in 1.54 seconds, .5 seconds per
file. However, cannot be made to check any files but
these, and does not appear to calculate checksums.
SSCRC
To build a list of CRCs for 146 files, SSCRC took 6
minutes 27 seconds, about 2.6 seconds each. Testing
everything on this list took 6 minutes, 10 seconds,
about 2.5 seconds each.
Validate
To validate a selected file requires issuing the validate
command for that file, then looking the result up
on-line, from a BBS in California. Minimum time
required: perhaps 3 minutes per file.
VCheck
To build a list of CRCs for 87 COM and EXE files,
VCheck took 1 minute 55 seconds, about 1.3 seconds
each. Testing everything on this list took 1 minutes, 25
seconds, about 1 second each.
VirusGuard
To build a list of CRCs for 87 COM and EXE files,
VirusGuard took 1 minute 39 seconds, about 1.2
seconds each. Testing everything on this list took 1
minute, 42 seconds, again about 1.2 seconds each.
EFFICIENCY IN CHECKING ALL FILES
Does the program permit checking of all files with some option
such as "/ALL", or is it necessary to feed the program a list of
all the files you wish checked? The latter approach can be
grueling for any user with a large hard disk! Is there an upper
limit to the number of files that can be checked? Is the program
smart enough to check other logical drives, such as D:?
Alert
No. There does not seem to be any such efficiency
possible. The programwants to scan one file at a time,
and add one at a time to its list. Alert can only manage
a list of about 200 files. Alert does not know that
viruses do not inhabit documentation, and is likely to
begin by scanning its own manual! Creating a list to be
checked is very labor-intensive.
The Antibody Test
Antibody automatically scans the entire hard disk upon
installation. It can manage about 3900 file signatures.
Antibody ignores drives D:, E:, etc., however.
BSearch
There is no upper limit to the number of files that can
be checked. Ignores D:, E:. As with Antibody, BSearch
can be called from a batch file that scans specified
drives, directories. Output showing changes can be
routed to the printer, if this is desired.
CHKSUM
Power is about equivalent to BSearch. You can do
almost anything with batch files, but you will need to
be a bit handy with an ASCII editor to do so. You'll
need to specify if you want CHKSUM to look at D: for
you. There is no limit on the number of files that can
be checked. Unlike BSearch, CHKSUM will not look at
subdirectories of the specified target, unless you tell it
to.
Checkup
Checkup simply processes everything on your hard
disk, and does not work from any input list. There is
no upper limit on the number of files that can be
scanned, other than your patience. Checkup is happy to
point out that files have been changed, when they
haven't been. This occurs because Checkup creates one
X.XUP for every file beginning with X. Thus the
signature for X.BAT is stored in X.XUPand the
signatures for X.COM, X.SYS, X.BAK, etc. are
compared with the contents of this file. With perhaps
10% of such "claims" wrong, you will lose patience with
it quickly. Checkup gets a 10 for efficiency, a 0 for
accuracy.
CRCDOS
CRCDOS will process an ASCII list of files you give it,
a list you can create by entering CHKDSK *.* /v >>
filelist You can then feed CRCDOS this list with a
command such as CRCDOS -m crclist filelist. There is
no upper limit on the number of files that can be
scanned. D: and other drives are ignored unless
CRCDOS is told to work them over. Like CHKSUM,
CRCDOS will not automatically look at subdirectories
of the specified target, unless you tell it to.
Delouse
Much like CRCDOS. Delouse will process an ASCII list
of files you give it, a list you can create by
entering CHKDSK *.* /v >> delouse.dat You can then
feed Delouse this list with a command such as
DELOUSE MAKE. This creates a file DELOUSE.CHK
file, used during checking. To check, you enter
DELOUSE CHECK. There is no upper limit on the
number of files that can be scanned. D: and other
drives are ignored unless Delouse is told to work them
over. Like CHKSUM and CRCDOS, Delouse will not
automatically look at subdirectories of the specified
target, unless you tell it to.
The Detective
Intelligent menu-driven design. Prompts for drives, file
extensions. It is easier (and more sensible) to make it
simply check everything than to be selective.
F-Prot
Very efficient, but scans only the five system files.
FICHECK
Intelligent menu-driven design. Prompts for drives, file
extensions. It is easier (and more sensible) to make it
simply check everything than to be selective. Some
selectivity (with *.COM, *.EXE, etc.) is easy; other
selectivity (specific files) is harder to do.
Module Integrity Check
Checks all files automatically. Processes only the
current logical drive. Cannot be made to scan
selectively. Creates all reports, as disk files,
automatically. Because it is so fast, we award nearly
full points here.
Novirus
Cannot be made to check multiple drives. Cannot be
made to check files other than the three system files.
SSCRC
There is no upper limit to the number of files that can
be checked. Ignores D:, E:. As with Antibody and
BSearch, can be called from a batch file that scans
specified drives, directories. Output showing changes
can be routed to the printer, if this is desired.
Validate
No. There does not seem to be any efficiency possible.
The programwants to scan one file at a time, and is
unable to compare its results with anything in a list of
recorded checksums.
VCheck
Checks all COM and EXE files automatically. Processes
whatever logical drive you specify on the command line.
Cannot be made to scan selectively. Cannot be made to
scan SYS, BIN, OVL, or other files that might become
infected. Creates all reports, as disk files,
automatically.
VirusGuard
Checks all COM and EXE files automatically. Processes
whatever logical drive you specify on the command line.
Cannot be made to scan selectively. Cannot be made to
scan SYS, BIN, OVL, or other files that might become
infected. If a file is changed, the machine pauses
during signature checking, with the message "X.X has
been modified. Press F1 to acknowledge."
USER CONTROL OF FILES TO BE CHECKED
Because checking all files can take some time, users may wish to
provide the program with a list of files to be checked. Can this
be done? Can the user use their text editor or other convenient
tool to build the file list?
Alert
Yes. Users select those files they wish to check, via
menu. The menu system can be used to build a file list
for subsequent use. The file list is encrypted and not
editable with any program other than Alert, however.
The Antibody Test
No. Antibody cannot be given a short list. You may add
to its understanding of what should be checked, but
cannot subtract.
BSearch
You can only list by file type and directory. Thus you
can specify all COM files within each of 4 directories,
all EXEs within another 2 directories, etc. Each
instruction is offered on a separate command line, and
can be run from a batch file. The database cannot be
edited with most word processing programs, however.
CHKSUM
Building the list of files to check can be done easily by
redirecting the program's output (">>") to a file, then
editing this file into a batch file.
Checkup
No control.
CRCDOS
Extremely easy to use here. Hand CRCDOS a list of
files, and it builds a list of CRCs for those files. Hand
it this list, and it compares current and stored CRCs
for changes.
Delouse
A bit easier than CRCDOS, even, in that file names to
scan and to compare are hard-coded, so the command
line is simpler: you only need to enter "Delouse Make"
or "Delouse Check"
The Detective
The user controls the drive(s) to check, and the file
extensions to check, but cannot control the directories
to check or provide a list of specific files.
F-Prot
The user can choose to not check any of the five system
files. But the user cannot get F-OSCHK to scan any
other files than these.
FICHECK
The user controls the drive(s) to check, and the file
extensions to check, but cannot control the directories
to check or provide a list of specific files.
Module Integrity Check
MIC is so fast that it doesn't make any sense to
attempt to force it to scan selectively. Let it scan
everything. You're done. MIC is certainly the easiest to
use, most efficient of all the programs described in this
chapter.
Novirus
Offers no control over the checking process. Takes only
one command line - /I makes it start over with a new
database of information on the three files.
SSCRC
Offers no control over the checking process other than
permitting scan of a directory, rather than the entire
drive.
Validate
You can make it scan any file in any directory. But
scanning two files requires two commands. Not
practical for real-life.
VCheck
Offers no control over the checking process other than
permitting scan of a directory, rather than the entire
drive.
VirusGuard
VirusGuard is so fast that it doesn't make any sense to
attempt to force it to scan selectively. Let it scan
everything. You're done. MIC is certainly the easiest to
use, most efficient of all the programs described in this
chapter.
ADDING SELF-CHECKING TO FILES
The most efficient approach to checking files is not to check only
critical files, or all files, but rather to check files as they are
run. This checking can be done with either code which is added
to each file, or with a memory-resident driver, that monitors file
access.
Adding code to a file is the idea of "vaccination." The file is
modified so that when it is run, control is first passed to the
appended code, which then calculates the checksum of the file
with the checksum that was stored in that file at the time of
vaccination. A failed comparison can result in an alert to the
user.
There are a few drawbacks to the approach. It slows processing
a small amount, it enlarges each file a small amount, it may not
work on COM files that are nearly 64K in size, since 64K is the
largest size supported by the COM format; it cannot work with
BIN, SYS, and OVL files; it cannot work with archived,
self-extracting EXE files, and so on. While some authorities,
such as Rich Levin, view such approaches as substantially
flawed, we are unconvinced.
Alert
This feature is not offered.
The Antibody Test
This feature is not offered.
BSearch
This feature is not offered.
CHKSUM
This feature is not offered.
Checkup
This feature is not offered.
CRCDOS
This feature is not offered.
Delouse
This feature is not offered.
The Detective
This feature is not offered.
F-Prot
The F-Prot package includes F-XLOCK, a program that
can make any other COM or EXE self-checking.
Entering F-XLOCK *.* will protect all COM and EXE
files in the current directory. When infected, the
program will hang the system and report "THIS
PROGRAM HAS BEEN INFECTED!" and the system
hangs.
FICHECK
This feature is not offered.
Module Integrity Check
This feature is not offered.
Novirus
This feature is not offered.
SSCRC
This feature is not offered.
Validate
This feature is not offered.
VCheck
This feature is not offered.
VirusGuard
This feature is not offered.
OPTIONAL SYSTEM LOCKUP ON DETECTION OF
MODIFICATION
Many things can modify a program: a virus, a hacker, an error
in using a sector editor. If a program has been modified, do you
want to try to run it? The smart money says no, let's stop right
now and see what has happened here. Running any program
that contains a virus is certain to spread the virus. It might be
desirable if the system is able to prevent any modified program
from running.
Alert
You are given ample warning about what files have
been modified. The warning is both auditory and
visual, and the screen requires you to press a key after
reading what has happened. The warning may not be
accurate, however. I swapped the names of two test
files, and Alert was unable to find one, told me the
other was the wrong size. Both, in fact, were where
they had been, but were completely modified. Further,
the warning on the screen tells the user to consult the
manual, rather than telling the user what to do next.
The Antibody Test
The log shows what has changed, and how. Optionally,
you may ask the program to display any text in any
file which has been changed since the last check.
However, there is no system lockup if a modification is
detected, nor are there any audible warnings.
BSearch
The log shows what has changed, and how. There is no
system lockup if a modification is detected. A faint beep
can be heard when any change is detected.
CHKSUM
Upon detecting a changed file, CHKSUM beeps and
displays a message. But it doesn't pause in its labors,
and the result of a massive infection is likely to go
scrolling off the screen. No lockup takes place on
mismatches.
Checkup
The documentation indicates that the system can be set
to lockup upon detection of a mismatch. We were not
able to create this effect on our test machine, however.
Further, although the documentation claims to permit
production of a log file, we were not able to do this.
Our copy was downloaded from the author's BBS.
CRCDOS
There is an extensive screen message whenever a
change is detected, but the system does not beep. No
lockup takes place on mismatches, either.
Delouse
There is a modest screen message whenever a change
is detected, but the system does not beep. No lockup
takes place on mismatches, either.
The Detective
You won't get a beep or message on the screen. A
report, sent to disk or your printer, lists the files that
have been added, deleted, or changed since the last run
of The Detective. Far too subtle for most users.
F-Prot
If any of the programs in the F-Prot package becomes
infected with any virus, or changed in any way, it
reports "THIS PROGRAM HAS BEEN INFECTED!". If
any program is protected with F-XLOCK, it will then
hang the system.
FICHECK
You won't get a beep or message on the screen. A
report, sent to disk or your printer, lists the files that
have been added, deleted, or changed since the last run
of FICHECK. Changes noted can include size, date,
time, crc. If the report is not requested, or not
requested correctly, or sent to disk, users may not
become aware of virus-induced changes.
Module Integrity Check
You get several very nice reports, automatically placed
in your root, showing files removed, added, and
changed since the last run. If a file has been changed
for any reason, MIC will tell you, and will tell you to
read the change report.
Novirus
If Novirus does manage to find a problem with a
change in the time, date, size or presence of one of your
three system files, it will halt the system and display a
full-screen warning message.
SSCRC
You won't hear a beep. You might see a notice go past
on the screen when a changed file is found. At the end
of the scan, you'll see a summary table, including a row
showing number of files failing CRC. Their names are
listed at the top of REPORT.CRC, placed in the root.
Your batch file that invokes SSCRC could send this
report to the printer, if you wished. There is no system
lockup. We might want this less subtle.
Validate
Because Validate makes no comparison with
pre-recorded CRCs, it cannot know if there is a
problem with a file. It is happy to scan infected files
and report their CRCs.
VCheck
You won't hear a beep. You will see a list, on screen, of
exactly which COM and EXE files have different CRCs
or sizes. Their names can be listed in a report you
create, which can be sent to the printer. There is no
system lockup.
VirusGuard
No beeps. But you'll see the changed program listed on
the screen, with the message that it has been modified.
You'll need to tap a key to remove the message from
the screen. There is no system lockup, and no hard
copy report or file of changes is created.
SELF-PROTECTION OF CHECKSUM PROGRAM
If a checksum program becomes infected, it then puts the virus
into memory before it begins to run. A stealth virus in memory
is able to remove itself from any file as the file is checksummed,
preventing the checker from finding the virus. Thus we need
some notification that the checksum program has been infected.
Ideally, the checker reports that it has been infected and quits
running.
To test this, we infected each checker with Jerusalem-B, and
tried running it.
Alert
Alert runs no worse with an infection than without one,
and never seems to notice that it has become a carrier
of Jerusalem.
The Antibody Test
As with Alert, Antibody runs just fine after infection.
BSearch
As with Alert and Antibody, BSearch runs just fine
with a Jerusalem infection.
CHKSUM
Runs well when infected.
Checkup
Runs as well when infected as when not infected --
poorly.
CRCDOS
Runs well when infected.
Delouse
Runs well when infected.
The Detective
Runs well when infected.
F-Prot
F-OSCHK reports that it has been infected. F-XLOCK
reports that it has been infected, and hangs the
system.
FICHECK
Runs well when infected. Includes an option to
self-check for virus infection. The self-check works.
After a few moments, it will report "Error - This
program has been altered or tampered with!" However,
the user must invoke this option deliberately and
manually.
Module Integrity Check
Runs well when infected.
Novirus
Runs well when infected.
SSCRC
Runs well when infected.
Validate
Runs well when infected.
VCheck
Runs well when infected.
VirusGuard
Runs well when infected.
VENDOR INFORMATION
o Alert. Version 2.20, available from the NCSA BBS as
ALERT220.ZIP. Also available from Robert W. Reed,
3858 Waterview Loop, Winter Park, FL 32792. Price:
$25 each for 1-10 licensees.
o The Antibody Test, version 1.03B. Available from
the NCSA BBS as ANTIBODY.ZIP. Also available at
no charge from Commander, TRADOC, ATTN: ATIS-S
(Major Richard W. Adams), Ft. Monroe, VA
23651-5000.
o BSearch. "If you find BSearch of value, a contribution
of $10 would be helpful." Available from the NCSA
BBS as BSEARCH.ZIP, or from David Harris, POB
2058, El Paso, TX 79951.
o CHKSUM is available from the NCSA BBS in a file
called CHKSUM.ZIP. It is also available from its
author, Bob Taylor, 8602 Woodlake Drive, Richmond,
VA 23229. The author does not request a contribution.
The package includes C source code.
o Checkup v. 3.9 (Levin) "This is not free software.
You are granted a limited license to evaluate this
program for ten days in your home or office. If you
continue to use this program, you must register with
the author. Registration fees are $24.95 per copy for
home users and $49.95 per copy for office users."
Available from the NCSA BBS as CHKUP39.ZIP or
from Richard B. Levin, POB 14546, Philadelphia, PA
19115.
o CRCDOS version 1.0. Available from the NCSA BBS
as CRCDOS.ZIP. This ZIP file includes C source
code. Written by R.E. Faith, January 11, 1988.
Released to the public domain, on condition that no fee
be charged for distribution, that authorship information
concerning source and any modifications will be
retained, and that the code is not included as part of a
commercial package.
o Delouse version 0.9 Available from the NCSA BBS as
DELOUSE.ZIP. Written by Phillip M. Nickell, February
28, 1988. Includes Pascal source code. No fee is
requested. No copyright is taken. Appears to be public
domain. Thanks, Mr. Nickell!
o The Detective version 1.2 Available from the NCSA
BBS as DETECT.ZIP. "The free version of The
Detective is expressly prohibited for use in commercial,
educational, and governmental institutions except for
the purpose of evaluation." The price per computer, if
you choose to register, is $25 for 1-50 computers, and
less with more. You may order the current version from
PC Solutions, POB 742, Mequon, WI 53092. (414)
241-9119. The shareware version, distributed via
bulletin boards, is unable to process files in the root
directory.
o F-Prot, version 1.12, is available from the NCSA's BBS
as FPROT112.ZIP. Version 1.12 of this package
contains a large number of extremely useful anti-virus
tools. From the standpoint of the present review, only
two are relevant, however: F-XLOCK (which permits all
programs to check for CRC changes as they are
executed) and F-OSCHK (which checks the partition
table, boot record, two hidden system files, and
COMMAND.COM) F-Prot is available from Fridrik
Skulason, Box 7180, IS-127 Reykjavik, Iceland. Pricing:
Skulason suggests $15 for 1-7 computers, and lower
payments on larger volumes.
o FICHECK, version 5.0, comes bundled with
MFICHECK 5.0 and PROVECRC ver 1.0. It may be
downloaded from the NCSA BBS as FICHECK5.ZIP. It
is available from the author, Chuck Gilmore, Gilmore
Systems, POB 3831, Beverly Hills, CA 90212-0831.
Pricing: "A 30 day trial period is granted. Afterward,
you may either order one of the commercial versions or
destroy the evaluation copies." Two commerical
versions are available: XFICHECK (eXtended
FICHECK) for $15 and PFICHECK (Professional
FICHECK) for $20.
o Module Integrity Check, version 1.0, is available
from the NCSA BBS in a file called MIC10.ZIP.
Pricing: "This program may be used by anyone free of
charge... Anyone who finds this program of value is
encouraged to make a voluntary donation to the
author... Even if you do not make a donation you are
still free to use this program as you see fit." Author:
Steve Leonard, 260 Dunbar Road, Hilton, NY 14468.
o Novirus version 3.0, accompanied by documentation
for version 2.0, is available in a file called
NOVIRUS3.ZIP on the NCSA BBS. It is also available
from the Interconnect BBS, 703-827-5762. Author:
Jeffrey Morley. Price: free.
o SSCRC, version 1.4, is available in a file called
SSCRC.ZIP from the NCSA BBS. Pricing: "If you use
this utility to protect your system, do the right thing
and send us $10", says the author. It is available from
OSR, 561 Blaxland Road, Eastwood, 2122, NSW,
Australia.
o Validate, version 0.3, is available in a file called
VALIDAT3.ZIP from the NCSA BBS. It is also
available at no charge from Computer Virus Industry
Association, 4423 Cheeney St., Santa Clara, CA 95054.
(408)-727-4559. Price: free.
o VCheck, version 1.1E, is available in a file called
VCHECK.ZIP on the NCSA BBS. Pricing: "If you use
VCHECK, send a registration of $25 to
Systemberatung Axel Dunkel, Robert-Schuman-Ring
37, D 6239 Kriftel, West Germany."
o VirusGuard.
SOME OBSERVATIONS
Once again, the correlation between price and value is upset.
Many of our highest scoring packages were the cheapest.
We note also the contradiction betwen our ratings and those
published elsewhere. The documentation accompanying Checkout
notes that the product is Compute!'s PC Magazine Editors choice
for virus protection, is the featured virus detection system in
Dvorak and Anis' "Dvorak's Guide to PC Telecommunications",
etc. We found it at the bottom of our scoring system. You may
wish to review our ratings of this product.
OTHER EVALUATION CONSIDERATIONS
We did not compare products on the following items, but you
may wish to:
o Can the program work on files with hidden, system,
read-only attributes.
o Can the program work from floppy disk? This is
valuable if you wish to use the program to monitor
another user's machine, for instance, to see if they are
clandestinely running a golf game that is not on the
approved corporate software list. It is also valuable for
guarding against stealth viruses.
o Can the program produces separate lists of deleted
files, added files, and changed files? Separate lists may
have benefits over a massive list of changes.
o Do you have control over whether the program updates
its baseline database? If the program updates this
everytime it is run, you will lose your history file.
+++++
|
|
