home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
norge.freeshell.org (192.94.73.8)
/
192.94.73.8.tar
/
192.94.73.8
/
pub
/
computers
/
pcjr
/
utility
/
SERV300.LZH
/
CHECKSUM.DOC
next >
Wrap
Text File
|
1989-11-27
|
13KB
|
255 lines
+====================================================+
: CHECKSUM.EXE version 1.0 |
| Copyright (C) 1989, Lawrence Stone Reasearch Group |
| Written and developed by Lawrence Stone |
+----------------------------------------------------+
+=======================================================+
| Purpose: |
| Check one or more files for corruption and/or viruses |
+-------------------------------------------------------+
Licenese:
CHECKSUM is "shareware" or user supported software. CHECKSUM was developed
as a supplemental utility for LSRGroup's disk, file, and archive controller
program called SERVICES. You are granted the right to use CHECKSUM for a
limited period in order to evaluate its usefulness. After a reasonable
period, you must either register your copy or discontinue using this program.
Government agencies and commercial agencies of any kind must register this
program. Registration is $10 U.S. per copy. If you register CHECKSUM, then
your fee will be deductable from the registration cost of SERVICES, when you
register SERVICES. If you have a registered copy of SERVICES, then you do
not need to register CHECKSUM.
To register, send a check, money order, or warrent to:
LSRGroup
P.O. Box 5715
Charleston, Oregon 97420
Atten: SDN Distribution
Disclaimer:
Use of this program acknowledges this disclaimer of warranty: "This program
is supplied as-is. LSRGroup disclaims all warranties, expressed or implied,
including, without limitation, the warranties of merchantability and of
fitness of this program for any purpose. LSRGroup assumes no liability for
damages direct or consequential, which may result from the use of this
program."
Introduction:
CHECKSUM will discover most virus if the virus wasn't present in a file
when you first checked that file. And, CHECKSUM will discover all files
that have become corrupted if the files were not corrupted the first time
they were checked by CHECKSUM.
For a very thorough check for viruses, LSRGroup recommends you use FLUSHOT,
by Software Concepts Design, and SCAN, by McAfee Associates, in conjunction
with CHECKSUM. This recommendation is made because all three of these pro-
gram use different techniques to hunt out viruses, thereby, increasing the
likelihood of finding one, if one is present. CHECKSUM also looks for cor-
rupted files whether corrupted due to a virus or not.
If you have CHECKSUM write a report file then, by analyzing the report, you
can determine whether the failed CRC check is due to a virus (and if it is,
the extent of the infection) or if a file failed the CRC due to another
reason, such as weakened formatting, etc.
If you use FLUSHOT in conjunction with CHECKSUM, be advised that if FLUSHOT
has calculated a file's checksum value before CHECKSUM.EXE has been run on
that file then you need to instruct FLUSHOT to re-figure the checksum of that
file. This is necessary because CHECKSUM hides its calculated CRC value
inside of each file it tests. If FLUSHOT performed its test prior to when
CHECKSUM did, the next time FLUSHOT checks this file, it will inform you that
it failed the CRC check. This file is ok, it just contains hidden informa-
tion for CHECKSUM that wasn't present the first time FLUSHOT checked it and,
therefore, when tested by FLUSHOT, produced a different checksum value from
its original.
Just instruct FLUSHOT to re-calculate the checksum and you should have no
further error messages from FLUSHOT unless there is a virus present. Also,
when CHECKSUM hides this information within a file, the size of the file will
be increased by four bytes.
One question often asked is, "What files need to be checked for viruses?"
Obviously, checking every file is time consuming and often impractical. Most
files do not need to be checked. Viruses need to do a handshake with your
files before they can get infected. This handshake will occur via other
files that can make the "touch". Your COMMAND.COM, BIOS, DOS, CHECKSUM.EXE,
any memory resident program or, any file that is loaded automatically via
your AUTOEXEC.BAT are good candidates for virus checks.
You can run CHECKSUM from your AUTOEXEC.BAT and do a CRC/checksum test auto-
matically, every time you boot your computer. CHECKSUM will return an error-
level to you batch file. Have your batch file use this errorlevel so that it
can take appropriate action, if needed.
Before you use CHECKSUM, make sure you have a good backup of the file(s) to
be tested. If the file should ever become corrupted, you will need to over-
copy it with a clean copy (backup). Also, if CHECKSUM should, for any reason
interfere with the file tested, then you will want to over-copy it with your
backup copy.
I. Call syntax:
CHECKSUM [?] [file] [@list] [-report]
Where CHECKSUM is the name of the program and where one or more of the items
within square brackets (above) must be included.
Calling CHECKSUM with "?" will display a help screen.
"file" is the name of a file to test. If you tell CHECKSUM to test a single
file, then do not give it the "@list" parameter. The file can contain the
complete path with the file's name.
"@list" is the name of a control file. It can include the complete path. If
you use this parameter, do not give CHECKSUM a "file" parameter. The control
file name must be immediately preceded with an at symbol, hence, the term for
this parameter is "@list".
"-report" is the name of the report file. It can include the complete path.
This parameter can be used with the "file" parameter or the "@list" parameter.
The name of the report file must be immediately preceded with a minus sign,
hence, the term for this is "-report".
Sample calls to CHECKSUM:
CHECKSUM ?
CHECKSUM C:\COMMAND.COM
CHECKSUM C:\EMM.SYS-C:\UTIL\CHECKSUM.RPT
CHECKSUM @CONTROL.LST-C:\UTIL\CHECKSUM.RPT
CHECKSUM @C:\UTIL\CONTROL.LST-C:\UTIL\CHECKSUM.RPT
II. The Control File
When the CHECKSUM utility is controlled by this file, it will test all the
files listed within. The control file must be an ASCII file, and should
have the complete path and filename for every file listed. The control file
can have any name. LSRGroup suggests you use the name, "CONTROL.LST" or use
"CONTROL.FIL". Below is a sample control file:
C:\IO.SYS
C:\MSDOS.SYS
C:\COMMAND.COM
C:\RAMDRIVE.SYS
C:\EMM.SYS
C:\DOS\COMMAND.COM
C:\UTIL\SCREEN\FAST.COM
C:\UTIL\ANSI.COM
C:\UTIL\CHECKSUM.EXE
C:\SERVICES\SERVICES.EXE
Note that the control file is a sequential, ASCII list of those files to be
checked by CHECKSUM.
III. CHECKSUM's Report File
The report file is a written report stating the date and time of each test,
the file name of each file tested, result of each file tested, errorlevels
produced for each file tested, and any errors produced while reading or writ-
ing to files. The report is written in ASCII and saved as a disk file and
can have any name. LSRGroup recommends you name it, "CHECKSUM.RPT".
LSRGroup further recommends that you have CHECKSUM output to a report when-
ever you test a file.
Whenever CHECKSUM creates a report, it will append it to any previous report.
In this way, you can maintain a complete history of the status of each file
tested. After a while, this report will become quite large. It is your
responsibility to archive it, or delete it, as your needs dictate.
The checksum report is an ASCII file and has the following format:
(Sample Report)
+=======================================+
| Checksum Report 10-01-1989 08:11:40 |
+---------------------------------------+
File Result Exit Error
--------------------------------------------------------- ------ ---- -----
C:\IO.SYS PASSED 0 0
C:\MSDOS.SYS PASSED 0 0
C:\COMMAND.COM PASSED 0 0
C:\RAMDRIVE.SYS PASSED 0 0
C:\EMM.SYS PASSED 0 0
C:\DOS\COMMAND.COM PASSED 0 0
C:\UTIL\ANSI.COM PASSED 0 0
C:\UTIL\SCREEN\FAST.COM PASSED 0 0
C:\SERVICES\CHECKSUM.EXE PASSED 0 0
C:\SERVICES\MAKEFAT.EXE PASSED 0 0
C:\SERVICES\PROTECT.EXE ADDED 1 0
---------------------------------------------------------------------------
<--------------- 62 character spaces -------------------><---7--><-5-><-5->
Each time CHECKSUM appends to the report, it begins the report with a box
informing you that this report is a "Checksum Report" and the date and time
the report was created. Below that is a listing of each file tested, their
result, errorlevel (Exit), and any errors produced while reading or writing
the file (Error). The actual errorlevel established, once CHECKSUM is
finished, is the highest errorlevel encountered.
Files tested will have one of the following results:
Result Definition
------ ------------------------------------
PASSED File tested successfully.
FAILED File failed checksum test.
NULL Attempted to test a null file.
COMMND Improper command line argument.
DISK Disk error encountered.
OPEN Error while attempting to open file.
READ Error while attempting to read file.
WRITE Error while attempting to write file.
CHECKSUM will set an errorlevel so that those who use it in their system's
AUTOEXEC.BAT files can take appropriate action based upon the returned
errorlevel. The report lists each exit level (errorlevel) established and,
the highest exit level established is the actual errorlevel returned when
CHECKSUM is done. The following list the errorlevels and their meanings:
Exit Description
---- ---------------------------------------
0 File passed checksum test.
1 File had signature/checksum added - OK?
2 Floppy drive had drive door open.
3 Disk has bad sector in FAT.
4 Disk not DOS formatted.
5 Disk was write protected.
6 Path was not found.
7 Invalid command line argument.
8 Read error.
9 Other errors.
10 File failed checksum test!
Note: If you are testing files on floppy drives then you must remove any
write protect tabs.
If, for any reason, CHECKSUM fails to handle any file, then this information
is presented in the report under the heading "Error". The only exception to
this is if CHECKSUM was given a bad path name for its report - in this case,
the program is aborted with an errorlevel 9 and, obviously, no report is
written. Errors that CHECKSUM lists are the same error codes that DOS would
produce unless the error is greater than or equal to 255. In this case,
subtract 255 to get the DOS error.
Example errors:
0 No error
2 Bad crc in FAT
12 Not DOS formatted
255 Disk write protected
259 Path not found.