Dec 172017
Check Up V3.5 by Levin. Virus detection system.
File CHKUP35.ZIP from The Programmer’s Corner in
Category System Diagnostics
Check Up V3.5 by Levin. Virus detection system.
File Name File Size Zip Size Zip Type
CHECKUP.BAT 2335 746 deflated
CHECKUP.DOC 108635 26480 deflated
CHECKUP.EXE 73739 48125 deflated
LICENSE.DOC 7952 2647 deflated
MIS.BAT 1938 972 deflated
REGISTER.DOC 3333 898 deflated
UPDATE.DOC 2487 1039 deflated

Download File CHKUP35.ZIP Here

Contents of the CHECKUP.DOC file

Rich Levin's CHECKUP (tm) Virus Detection System

Documentation for Version 3.5
(See UPDATE.DOC for updates to this document)
Released June 14, 1989

For the IBM PC, XT, AT, PS/2 and IBM-compatible computers

Copyright (c) 1988 Richard B. Levin
All Rights Reserved

Give your files a CHECKUP! (tm)

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 $20.00 per copy for home users and
$40.00 per copy for non-home users. A deluxe edition is
available to all users for $60.00.

If you purchased CHECKUP through a retail outlet, send a copy of
your dated sales receipt in lieu of a registration fee.

Registered users receive a special program, REGISTER.EXE, that
enables advanced features and disables CHECKUP's time-delayed
opening screen. Remit registration fees and sales receipts to
Richard B. Levin, P.O. Box 14546, Phila., PA 19115 using the
REGISTER.DOC form included in the CHECKUP distribution archive.

CHECKUP is published by

Richard B. Levin
9405 Bustleton Ave.
P.O. Box 14546
Phila., PA 19115

Lab: (215) 333-8274
BBS: (215) 333-8275

Corporate support: Inquire for details

Site licenses and quantity discounts available. Dealers and
consultants protected. Call or write for details.

Thank you for using CHECKUP.

Table of Contents

CONSUMER ALERT.............................................2
IMPORTANT NOTE.............................................2
CHECKUP'S MASTER DISK CONTENTS.............................2
COPYRIGHT NOTICE...........................................2
SOFTWARE LICENSE...........................................3
DISTRIBUTION POLICY........................................4
UPGRADE POLICY.............................................5
REGISTRATION FORM..........................................6
NOTE TO USERS OF MS-DOS....................................8
THE PROBLEM DEFINED........................................8
FILE COMPARISON UTILITIES.............................12
ANTI-VIRUS TSRs.......................................14
HOW CHECKUP WORKS.........................................15
RUNNING CHECKUP...........................................16
CHECKUP'S COMMAND-LINE OPTIONS........................17
CHECKUP'S ERRORLEVELS.................................24
CHECKUP'S .XUP FILES..................................25
THE CHECKUP.LOG FILE..................................26
ERROR CODES AND EXPLANATIONS..........................28
FATAL ERRORS..........................................31
ADVANTAGES OF USING CHECKUP...............................31
DIAGNOSING AN INFECTED COMPUTER...........................38
WHAT TO DO IF YOUR SYSTEM IS INFECTED.....................39
CHECKUP'S RELEASE HISTORY.................................43


"The only truly secure system is one that is powered off, cast in
a block of concrete and sealed in a lead-lined room with armed
guards--and even then I have my doubts."

Eugene H. Spafford



This Is The Original CHECKUP (tm) Program
Not To Be Confused With Other Programs Of The Same Name
If It's Not Software By Rich Levin
It's Not The Original CHECKUP (tm) Virus Detection System

CHECKUP has become one of the world's leading virus
detection systems for IBM PC-class microcomputers. It is used by
government agencies of the USA, Canada, Europe and Australia;
hospitals and research laboratories, colleges and universities,
member companies of the Forbes and Fortune 500s, BBS SysOps and
individual users everywhere. It is likely that CHECKUP runs on
more systems world-wide than all other anti-virus systems


Please read this document before running CHECKUP. If you
are upgrading from a previous release of CHECKUP, please note:
the CHECKUP program, invocation syntax, file formats and
documentation have been substantially revised.


Your CHECKUP disk/archive contains the following files:

CHECKUP.BAT - sample CHECKUP batch file (ASCII)
CHECKUP.DOC - this file (ASCII)
CHECKUP.EXE - CHECKUP program (Binary)
CHECKUP.REG - registered user data file (Binary)*
INSTALL.BAT - installation program (ASCII)*+
README.DOC - last-minute errata (ASCII)+
REGISTER.DOC - owner registration form (ASCII)
REGISTER.EXE - registration program (Binary)*
SETUP.BAT - setup program (ASCII)*+

* Provided to registered users only. Registered users
are provided most of the above files in a
self-extracting archive file named CHKUP.EXE.

+ May or may not be present


The name "CHECKUP" and the CHECKUP program, documentation,
CHECKUP-created input and output files, visual displays,
interface, look and feel ("the CHECKUP system") are copyright (c)
and trademark (tm) 1988 Richard B. Levin ("the author"), all
rights reserved.


The CHECKUP system is protected by United States Copyright
Law (Title 17 United States Code). Unauthorized modification,
reproduction, duplication, transfer or sales may result in
imprisonment of up to one year and fines of up to $25,000.00 (17
USC 506). Copyright infringers may also be subject to civil
liability. The Federal Bureau of Investigation investigates
allegations of criminal copyright infringement.


Please read the terms and conditions of this software
license before using the CHECKUP system. This license is
effective from the day you first run the CHECKUP system and
remains in effect for as long as you possess, in whole or in
part, a copy the CHECKUP system. By using the CHECKUP system,
you agree to honor the terms and conditions of this license.

The CHECKUP system is the sole and exclusive property of
Richard B. Levin ("the author") and is provided to you without
warranty of any kind, either express or implied. The entire risk
as to the results and performance of the CHECKUP system is
assumed by you. Should the CHECKUP system prove defective,
ineffective or unsatisfactory, you (and not the author) assume
the entire cost of repair or replacement to damaged or unusable
hardware or software. The author is not liable for any damages
incurred by you or any other party through the use or misuse of
the CHECKUP system.

You are granted a limited license to use and evaluate
unregistered copies of the CHECKUP system on a single computer
for a period of ten days, beginning with the date you first
acquired the CHECKUP system. If you continue to use the CHECKUP
system after the expiration of the ten day evaluation period, you
must register with the author by following the instructions
contained in the accompanying REGISTER.DOC file. Upon credit of
your paid registration or receipt of your dated sales voucher,
the author will provide you with both a program and data file
("REGISTER.EXE" and "CHECKUP.REG") that enable the CHECKUP
system's advanced features and disable its time-delayed opening

Registered users of the CHECKUP system are granted the
non-exclusive right to use the CHECKUP system in accordance with
this license. Each registered copy of the CHECKUP system is
licensed for use on a single computer. Registered users may
transfer the CHECKUP system from one computer to another provided
the CHECKUP system is in use on only one computer at a time. You
must separately register every copy of the CHECKUP system used on
non-registered computers. Failure to register copies of the
CHECKUP system used on non-registered computers is a violation of
this license and United States Copyright Law.


You are permitted to copy and distribute UNREGISTERED copies
of the CHECKUP system to other users through any legal means
available to you, provided such copies conform to the terms,
conditions and spirit of the author's "Distribution Policy,"
presented below. You are NOT permitted to copy and distribute,
in whole or in part, REGISTERED copies of the CHECKUP system, the
REGISTER.EXE file or the CHECKUP.REG file. Registered users are
permitted to make archival back-up copies of the CHECKUP system.

You are not permitted to de-compile, disassemble, make
changes to or reverse engineer the CHECKUP system in any way
whatsoever, nor are you permitted to attempt to de-compile,
disassemble, make changes to or reverse engineer the CHECKUP

This license is non-transferable. Any violation of this
license or attempt to assign, sub-license or transfer same,
except as provided for herein, renders this license null and
void. The author reserves the right to make changes to this
license and to the CHECKUP system at any time without prior
notice. This license is governed by the laws of the Commonwealth
of Pennsylvania and the United States of America. Terms or
conditions of this license found to be unenforceable or illegal
will not effect the remaining license terms and conditions.


You are permitted to distribute UNREGISTERED copies of the
CHECKUP system to other users when the following conditions are

1. The CHECKUP system must be distributed in its
entirety, as originally produced by the author.

2. No part of the CHECKUP system may be altered,
added to, removed, re-archived or modified in any
way whatsoever.

3. The CHECKUP system must not be sold by anyone
other than the author or authorized
representatives of the author.

4. The REGISTER.EXE program and the CHECKUP.REG data
file (both provided to registered users) must NOT
be distributed.



The latest edition of the shareware version of CHECKUP is
stored on the Mother Board BBS (215-333-8275) in the "Software by
Rich Levin" area and may be downloaded, free of charge, at any
time. Upgrades are also regularly posted to the IBMNET\IBMSYS
Forum on the CompuServe Information Service (GO IBMSYS) and the
IBM and BBS RoundTables (RTs) on the General Electric Network for
Information Exchange (GEnie). Registered users can enable
advanced features of CHECKUP system upgrades and disable their
time-delayed opening screen.

Upgrades are also available by mail to registered users.
Send a blank, formatted, IBM-compatible 360k diskette; a
postage-paid, pre-addressed disk mailer and your check or money
order (drawn on a U.S. bank or financial institution and made
payable to "Richard B. Levin") in the amount of $10.00 per copy
for home users and $20.00 per copy for non-home users to:

P.O. Box 14546
Phila., PA 19115

Please remember to note your registered user serial number on
your order.



Please print, complete and mail this form within ten days to:

Richard B. Levin
CHECKUP Registration
P.O. Box 14546
Phila., PA 19115

Home users: Enclose payment in the amount of $20.00 per copy
Non-home users: Enclose payment in the amount of $40.00 per copy

All users: Enclose payment in the amount of $60.00 per copy
if you would like to receive the "deluxe"
(typeset and bound) edition of the CHECKUP

Please have checks and money orders drawn on a U.S bank or
financial institution and made payable to "Richard B. Levin."

Purchase orders are accepted on a net terms basis, with approved
credit and a minimum initial purchase of $500.00. Orders are
shipped insured, freight collect. Quantity pricing, site
licenses and other information available on request. Prices
subject to change without notice.

Registered owner's name:


Title: _________________________________________________________

Department: ____________________________________________________







City, State and Zip:


Home telephone number: ( ) -
Work telephone number: ( ) -

Comments: ______________________________________________________




Total number of unregistered computers running CHECKUP: ________

Amount enclosed (check all that apply):

[ ] Home user @ $20.00 per copy: $_____________
[ ] Non-home user @ $40.00 per copy: $_____________
[ ] Deluxe edition @ $60.00 per copy: $_____________
[ ] Sales receipt enclosed @ $0.00 per copy: $_____________

Sign here: _____________________________________________________



Many people have selflessly contributed to the creation of
the CHECKUP system; you know who you are. This program is
dedicated to you.


The files IO.SYS and MSDOS.SYS are the MS-DOS equivalents to


Ours is not to reason why there exists, in this wonderful
but crazy computing world of ours, programs that intentionally
destroy your hard-earned data while pretending to be just another
run-of-the-mill application. These programs are popularly called
"bombs" or "Trojan horses" and they "explode" on users who do not
properly evaluate software before they run it (safe-computing
procedures outlined later in this document). The consequences of
running a bomb can be disastrous: erased files, scrambled disk
directories and re-formatted disks are but some of the documented
results. Because bombs willingly self-destruct--they run on the
systems they destroy--they have limited run-time lives and pose,
therefore, a finite threat.

Like bombs, computer viruses are typically delivered hidden
inside harmless-looking "Trojan" carriers (usually stored on
illegal, pirated copies of commercial program disks). Unlike
bombs, which detonate immediately when run, viruses pursue a more
sinister and long-range plan: the conversion of ordinary
programs into infected Trojan carriers. Once infected, the new
carriers also reproduce in secret, penetrating other computers
and infecting files exponentially--one program infects two, two
infects four, four infects eight and so on. This reproductive
cycle continues until the number of affected systems and diseased
files reaches epidemic proportions; the viruses have effectively
extended their run-time lives.

To manage their activities and to avoid re-infecting the
same files over again, viruses store coded bytes called
"v-markers" (virus markers) into files during their initial
infection. When unmarked, uninfected files cannot be found,
viruses assume their hosts have been thoroughly poisoned(1) with
viral code; tampering with system operations and user data
usually begins at this time when all-out contamination has been
achieved. Viruses may begin by simply toying with users,
printing taunting messages on screens or causing abnormal system
behavior. Eventually, however, most viruses detonate and damage
disk-based data.


[(1) One clever way to prevent the spread of a virus is to put
copies of its v-markers into all executable files. To implement
such a plan would, of course, require careful study of the
dissected viral code--not a task for the meek.]

It is extremely difficult--sometimes nearly impossible--to
accomplish total eradication of a virus allowed to obtain total
system saturation (especially in a networked environment). When
infections are discovered too late, countless viral offspring
have probably been spawned; generations of back-up data and
multiple computers have also been infected. Eradication can be a
nerve-wracking, time-consuming and complicated process, best
performed by highly skilled (and highly paid) anti-virus experts,
with relapses occurring long after systems appear to have been

Well-written computer viruses are difficult to detect using
modern file management and anti-Trojan techniques. They are
ingenious yet simple programs, polluting systems by inserting
copies of themselves into, appending viral clones onto or
creating shells around ordinary executable files. Expertly
engineered viruses will not change file date or time stamps, nor
will they alter attributes, sizes or checksums. Converting the
attributes of potential viral targets (such as COMMAND.COM,
IBMBIO.COM and IBMDOS.COM) to "read-only" may prevent
inadequately designed viruses from infecting them. Most viruses,
however, can check file attributes, reset them if necessary,
infect, then return the attributes to their original state. As
you will learn in the following sections, there are no sure-fire
ways to prevent viruses from infecting your systems. The only
practical solution is to isolate and eradicate infections
immediately after they occur using virus detection software
stored off-line.


Many public domain, shareware and commercial utilities
designed to combat viruses have appeared since the first virus
panic swept the nation in early 1988. Of the anti-virus products
examined during our ongoing testing, all were over-hyped,
underpowered or engineering overkill, providing no real benefits
to consumers. Virtually all of the offerings are marketed using
"the fear factor"--the exploitation of under-educated users. It
is of the utmost importance that users understand the failings
inherent in most anti-virus programming; thus, our observations
on the state of virus protection programs follows.



Many anti-virus programs claim to provide a software
"antigen" or "vaccine" that, when "injected" into executable
files, "inoculates" them to prevent viral infections.
Unfortunately, the implicit comparisons between anti-virus
software and true biological vaccines is misleading--just so much
marketing rhetoric.

What software vaccines actually do is append small
anti-virus programs and data (usually file checksums or CRCs) to
target executable files. The target files are modified so that,
when run, control is passed first to the appended anti-virus
programs. As the target files run, the anti-virus programs
compare the file checksums to their appended data. When
comparisons are successful, control is returned to the target
files, which (if all goes well) begin normal operations. When
comparisons fail, users are alerted and (hopefully) appropriate
actions taken.

Users should be aware of the following shortcomings and
complications associated with software vaccines before they put
them into service:

1. "Vaccinated" programs take longer to load because
appended anti-virus code and data increases

2. Large amounts of disk space can be consumed as
appended anti-virus code and data enlarge program

3. Data and overlay files cannot be protected;
vaccines must be used with executable files.

4. Some vaccines cannot protect .COM files because
they (the vaccines) try to modify .EXE headers.
.COM files do not have .EXE headers.

5. Many vaccines cannot protect packed .EXE files.
(Packed .EXE files have been compressed during
programming's LINK process to conserve disk space;
they expand in-memory when run. CHECKUP.EXE is an
example of a packed file.)

6. False alarms are generated when self-modifying
programs (like Borland's SideKick) update internal
data areas. To prevent false alarms, users are
forced to remove and re-install vaccines before
and after self-modifying programs are used.


7. For programmers, source code modifications are
often misinterpreted as viral alterations.

8. There are no guarantees that modifications to
executable files (like the appending of anti-virus
code and data) will not adversely affect their

9. The virus-like behavior of vaccines may cause
conflicts with other viral defense systems.

10. A virus can detect the modification of target
files and simply delete the anti-virus code and

11. Non-destructive file-checking utilities (like
CHECKUP) provide a safer, easier way of conducting
pre-run file checksums and CRCs.

Vaccines operate in a manner fundamentally similar to
viruses, although they do not reproduce without authorization or
purposely damage files. Most users are uncomfortable with the
concept of injecting a virus--antigen or otherwise--into their
executable files, especially when safer, less drastic
alternatives are available.


Some anti-virus vendors claim their products can remove
viruses or repair files damaged by a virus. Perhaps so; a far
more reliable method, however, is to restore infected files from
certified back-up or master copies. Other vendors con the
computing public by boldly demonstrating their programs'
"amazing" ability to restore "virus-deleted" data from
re-formatted, repartitioned hard disks. The truth is they are
merely restoring back-up copies of critical disk information:
the boot sectors, File Allocation Tables, disk directories and
partition data.

Most users are blissfully unaware that re-formatting disks
and repartitioning hard disks does not delete user data; instead,
it just marks allocated disk space as "unused." By replacing
disk "road maps" with accurate back-ups, user data appears to be
miraculously resurrected. Like their cousins, the software
vaccines, antidotes and format-recovery programs are not without
their drawbacks:

1. If the back-up data is not current, the
information it replaces will be out of date--an
inaccuracy that leads to further data loss.


2. Format recovery programs cannot reconstruct data
erased by low-level or destructive high-level
re-formatting. (Low-level formatting is employed
by most hard disk controller manufacturers;
destructive formatting is a feature of AT&T's and
Compaq Computer's DOS' and perhaps other OEM DOS

3. If new data has been written to a disk after it
has been re-formatted, deleted data cannot be
reliably recovered.

4. Many users already own data recovery programs
(like the Mace Utilities, the Norton Utilities and
PC-Tools) that are capable of restoring even the
most badly damaged disk to a usable condition.

Once again, it is safer (and more reliable) to restore files
from certified back-up copies or through the use of proven data
recovery programs. There are no substitutes for regularly
scheduled back-ups.


File comparison utilities compare, byte for byte, two
mirror-image copies of a target file specification. There are
several problems with this simple technique:

1. The same level of protection is achieved using any
file-comparison utility, including those provided
with DOS.

2. A duplicate copy of every compared file must be
stored on another disk or directory, a waste of
valuable disk space.

3. File comparison utilities generally do not support
features essential for the management of virus
detection; options like activity logs, alarms,
data encryption, system locks and wildcard (? and
*) input filespecs are sorely missed.

4. Viruses can check disk directories for duplicate
files and infect both copies of a target filespec.
Future file comparison checks would not detect any
differences between the two infected files.


5. Most file comparison utilities designed
specifically for virus detection prevent users
from comparing more than system start-up files
other files, including user data, remain


Disk-mappers (also known as "picture takers,"
"finger-printers" and "signature checkers") maintain centralized
data files consisting of coded disk images. These programs
notify users when changes are discovered between target disks and
their coded images. Here again, the solution fails to provide an
adequate defense against viral infections:

1. Disk-mappers' output files can occupy vast amounts
of disk space; they increase in direct proportion
to the number of files being tracked.

2. Time consuming maintenance of disk-mapper data
files is generally required. As the state of the
target disk evolves, entries must be sorted,
updated, deleted or purged.

3. Disk-mappers can be complex to operate because
they must support many data-file maintenance

4. Disk-mappers customarily update data files at
system start-up, increasing boot time.

5. Viruses can detect, modify and delete disk-mapper
data files.

6. Some disk-mapping programs convert files
(including raw data) to read-only status, thereby
assuring conflicts with other applications.

7. Several disk mapping schemes rely on
memory-resident modules to intercept DOS commands
in order to provide last-minute checks of programs
about to run. The problems with memory-resident
anti-virus programs are discussed in the next

8. File-checking utilities (like CHECKUP) provide a
safer, easier way of performing last-minute checks
of programs about to run.



Programs that load and stay RAM-resident (like Borland's
SideKick) are commonly referred to as "TSRs" (an anacronym for
"terminate and stay resident"). Anti-virus programs employing
this technology typically monitor disk writes directed to
specific files or provide last-minute checks of files about to
run. Unfortunately, the complications presented through the use
of anti-virus TSRs are numerous and severe:

1. Many computer configurations respond poorly to
particular groupings of TSR programs--they crash,

lock-up or simply behave abnormally.

2. Anti-virus TSRs often consume considerable
portions of limited available RAM space.

3. False alarms occur frequently, triggered by normal
disk activity that's misinterpreted.

4. Unattended computer operations, such as e-mail
transfers, uploads and downloads, are subject to
unanticipated--and usually fatal--interruptions
when anti-virus TSRs accidentally activate.

5. Most anti-virus TSRs allow a limited number of
files to be monitored, leaving other files--user
data included--unprotected.

6. System performance decreases as each BIOS- or
DOS-driven disk write is intercepted for
processing by anti-virus TSRs.

7. Viruses can directly manipulate disk controller
hardware to bypass interception by anti-virus

8. Anti-virus TSRs can be easily detected by viruses,
which is not surprising, since TSRs are always
evident in RAM. Viruses can disable or remove
TSRs and for this reason alone, anti-virus TSRs
provide users with a false sense of security.


A final point, relevant to all anti-virus systems: viruses
have complete control of PC system resources at the moment of
infection. Anti-virus programs renamed and stored in hidden
subdirectories, write-protected hard disks; hidden, read-only and
vaccinated files, file comparison utilities, disk maps, TSR
programs, device drivers, you name it--all are subject to the
scrutiny of viruses as they examine their hosts. Obviously,
then, anti-virus systems stored on non-removable media, relying
on support files stored on non-removable media or residing in
memory are themselves subject to infection.


CHECKUP detects viral infections by comparing target file
sizes, incremental cyclic redundancy checks (CRCs) and total file
CRCs to previously stored baseline values. CHECKUP examines
files by dissecting them into randomly sized blocks of data,
using a dynamic block size allocation that allows files as small
as one byte to be accurately checked. CHECKUP then scans and
compares each and every byte of the target files on a
block-by-block basis. If the recorded file sizes or any of the
block CRC comparisons or CRC totals do not match, CHECKUP alerts
users that the target files have been altered.

CHECKUP's incremental block CRC technique is superior to
simply calculating a sum-of-the-bytes and comparing past and
present checksum totals. Future viruses may be able to compute
checksums prior to infections, pad their viral code with
characters that maintain checksum integrity and then infect.
Even more alarming is the knowledge that viruses can effortlessly
exchange bytes within data files--a potent form of data
destruction ordinary checksum programs cannot detect. (For
example, the checksum of both 1 + 2 and 2 + 1 is 3, yet the order
of operators [the numbers 1 and 2] are different.) This kind of
viral activity would defeat other checksum calculation programs,
but not CHECKUP.

We believe it is impossible for a virus to maintain an
accurate intra-file (inter-block) CRC. This is especially true
when the checked block size varies from one byte to near total
file size, when the method for calculating the CRC is unknown and
the results encrypted. To survive CHECKUP's scrutiny, a virus
would need to know the block size, the exact calculation entry
point, the CRC algorithm and the encryption key used at
initialization. The virus would then have the difficult--if not
impossible--task of padding its code with dummy characters, since
adjustments would have to occur every hundred few bytes. Even if
a virus were able to achieve this high degree of adaptability, it
would nevertheless be unable to operate in such an internally
scrambled condition.



Launch syntax is:

[d:][path]CHECKUP [d:][path]filename[.ext] [/options]


* [d:] specifies the letter of the drive that
contains the CHECKUP program file.

* [path] specifies the path name that contains the
CHECKUP program file.

* CHECKUP is the run-time name of the CHECKUP.EXE
program file.

* [d:][path]filename[.ext] specifies the drive, path
and target file name(s) you want CHECKUP to

* [/options] are one or more of CHECKUP's
command-line actions (explained below).


1. If a drive letter is not specified, the default
drive is assumed.

2. If a path name is not specified, the default
directory is assumed.

3. The global file name characters * and ? may be
used to specify target files.

4. The target file specification must be the first
parameter on the CHECKUP command-line.

5. If CHECKUP is stored in the current directory or
in a directory specified by the PATH environment
variable, the drive letter and path name preceding
the CHECKUP file name become optional.


* To check COMMAND.COM on the logged default drive
in the logged default directory, the launch syntax
would be:



* To check all of the .COM files on the logged
default drive in the logged default directory, the
launch syntax would be:


* To check FOO.EXE (a very popular program) on the
C: drive in the \PLOP\PLOP\FIZZ\FIZZ directory,
the launch syntax would be:


* To check all of the .EXE files on the C: drive in
the \PLOP\PLOP\FIZZ\FIZZ directory, the launch
syntax would be:


CHECKUP accepts all legal DOS path and file names. Running
CHECKUP without command-line parameters causes the correct
invocation syntax and other helpful information to be displayed.


CHECKUP supports a variety of command-line options that
allow you to tailor the program's actions to address specific
application requirements. These command-line options are
provided as tools to aid in the control of CHECKUP'S execution;
CHECKUP does not require any of these options to run.

The switch character ("/") and first letter of the option(s)
selected must appear after the target file specification on the
CHECKUP command-line (note that future releases may implement
changes to these options):

/B[LOCK]:#### Override auto-block sizes and use
#### byte blocks

CHECKUP automatically selects
random data block sizes. Use this
option to specify fixed data block

In general, the larger the selected
block size, the faster CHECKUP
processes the file. Our testing
shows ideal block sizes range from
1024 to 2048 bytes; your testing
may yield different results.


Note that the colon character (":")
must appear before the block size
value. For example, the commands


both specify a block size of 1024

/C[OLOR] Override auto-attributes and use

CHECKUP automatically detects the
type of video adapter card
(monochrome or color) installed and
sets on-screen colors accordingly.
Use this option if CHECKUP does not
detect your color video adapter

/D[EBUG] Print verbose error messages

Causes CHECKUP to report error code
and line numbers in addition to
standard error messages.

/E[CRC] Override CRCs and use enhanced CRCs

CHECKUP automatically uses
table-driven CRCs (cyclic
redundancy checks) to detect
changes in target files. ECRCs are
a proprietary superset of CRCs that
provide better error checking but
may take longer to run.

/F[AST] Override CRCs and use checksums

CHECKUP automatically uses
table-driven CRCs (cyclic
redundancy checks) to detect
changes in target files. Checksums
provide faster error checking but
cannot detect adaptive-checksum
viruses and one type of data
tampering (see the section titled
"HOW CHECKUP WORKS," above, for
more information on checksums and
data tampering).


/I[NFO] Display program information

Causes CHECKUP to display an
informational message when no other
options are entered.

/L[OCK] Lock-up system when file
modifications are detected

Causes CHECKUP to secure the host
system and sound a continuous alarm
when file modifications are
detected. The host system must be
re-booted in order to un-lock it.

/M[ONO] Override auto-attributes and use

CHECKUP automatically detects the
type of video adapter card
(monochrome or color) installed and
sets on-screen colors accordingly.
Use this option if CHECKUP does not
detect your monochrome or Hercules
video adapter card.

/N[OLOG] Suppress output of CHECKUP.LOG file

CHECKUP normally maintains an
output file named CHECKUP.LOG.
This option prevents CHECKUP from
updating the CHECKUP.LOG file and
thus speeds CHECKUP's operations.
See the section titled "THE
CHECKUP.LOG FILE," below, for more
information on the CHECKUP.LOG

/P[AUSE] Pause when file modifications are

Causes CHECKUP to secure the host
system when file modifications are
detected. Pressing any key
un-pauses the host.

/R[EPLACE] Use replacement extension (.COM
becomes .XOM)


See the section titled "CHECKUP'S
below, for more information on this

/S[HIFT] Use shifted extension (.COM becomes

See the section titled "CHECKUP'S
below, for more information on this


We suggest that CHECKUP be run by an AUTOEXEC.BAT file
residing on a "clean" floppy disk. This ensures that files are
checked by a pure copy of CHECKUP loaded by uninfected system
files. It also guarantees that the .XUP files CHECKUP generates
will not be illegitimately altered.

If the "clean floppy disk/batch file method" is not
appropriate for your installation, other virus detection
strategies utilizing CHECKUP may be devised and used. We
recommend, however, that users read this section to gain an
understanding of the security benefits provided by implementation
of the clean floppy disk/batch file method.

The following steps explain how to create a clean CHECKUP
floppy disk using an IBM PC-compatible with 2 floppy disk drives
and a hard disk. Experienced users can adapt these steps to
accommodate different configurations:

1. Turn off your computer. Remove all floppy disks.
Wait 60 seconds.

2. Insert a factory master copy of DOS into drive A.
Close the disk drive door, then turn your computer

3. After your computer has completed the start-up
process, insert a NEW, never used, unformatted
floppy disk into drive B. Close the disk drive


4. Enter the command:


(The /S switch causes the FORMAT command to
transfer DOS' system files to the disk in drive B,
making it "boot-able.")

5. After the floppy disk in drive B has been
formatted and the system files transferred, copy
CHECKUP.BAT and CHECKUP.EXE to the floppy disk in
the B drive.

6. After CHECKUP.BAT and CHECKUP.EXE have been copied
to the floppy disk in the B drive, enter the
following commands:


7. Press F6, then press ENTER.

8. Remove the factory master DOS disk from drive A.
Replace it with the factory master of your
favorite ASCII editor. (An ASCII editor is any
word processor capable of generating unformatted
text output. If you're uncertain of your word
processor's ability to create pure ASCII text, use
EDLIN.COM [provided on your factory master DOS
diskettes] instead.)

9. Run your ASCII editor and edit the AUTOEXEC.BAT
file on drive B to reflect the disks, paths and
files you want CHECKUP to process. Confirm that
the disk and path names of the target files and
.XUP files match exactly.

10. After you have finished editing the AUTOEXEC.BAT
file on drive B, remove the factory master of your
ASCII editor from drive A. Replace it with the
clean CHECKUP floppy disk you just created on
drive B (leaving CHECKUP in drive A and drive B

11. Press and hold the Ctrl+Alt+Del keys to re-boot
your computer. CHECKUP will process the files
specified in the AUTOEXEC.BAT file, copy the .XUP
files back to the A drive and delete duplicate
.XUP files from the target disk.


12. After CHECKUP's AUTOEXEC.BAT file has completed
its run, remove the clean CHECKUP floppy disk from
drive A and store it in a cool, dry place.

13. Press and hold the Ctrl+Alt+Del keys to re-boot
your computer.

Use the clean CHECKUP floppy disk to boot your computer
whenever you check files again.

Remember that all viruses, no matter how sophisticated,
share the same, simple weakness: they cannot affect programs or
data unless they have access to them. By storing CHECKUP, the
CHECKUP AUTOEXEC.BAT file and the .XUP files on a clean,
boot-able floppy disk, and by using that disk *ONLY* to boot and
run CHECKUP (and for *NO* other operations), you are isolating
your CHECKUP system files and ensuring their reliable operation.


An example of the suggested CHECKUP AUTOEXEC.BAT file for a
hard disk drive system follows; users should edit this file to
support their specific needs. This sample batch file will
automatically run CHECKUP, check one of four ERRORLEVELs returned
by CHECKUP and back-up .XUP files as they are created. It is
included in the CHECKUP archive file (under the name of
CHECKUP.BAT) and may be edited as necessary:


REM Rich Levin's CHECKUP.BAT (tm)
REM Copyright (c) 1988 Richard B. Levin
REM All Rights Reserved
REM This batch file maintains clean copies of CHECKUP and .XUP
REM files. Rename to AUTOEXEC.BAT and store on a clean floppy
REM disk. See CHECKUP.DOC for information on how to create a
REM clean floppy disk.
REM Set the system date and time:
REM Make sure we're on the root directory of the target disk
REM (substitute the disk drive letter of your choice):
CD \
REM Copy CHECKUP and .XUP files from the A: drive to the target
REM disk:
REM Check files and resulting ERRORLEVEL. An ERRORLEVEL of 1 or
REM higher indicates CHECKUP terminated abnormally. (CHECKUP
REM supports four ERRORLEVELs; see CHECKUP.DOC for details.) In
REM this example, system execution is halted by PAUSE-ing after
REM a non-zero ERRORLEVEL is encountered. You may want take
REM different action(s) based on specific ERRORLEVELs.
REM (Substitute your list of input files here):
REM Copy .XUP files from the target disk back to the clean floppy
REM disk:
REM Reclaim disk space by deleting CHECKUP-related files from the
REM target disk:



COMMAND.COM, IBMBIO.COM and IBMDOS.COM should be checked on
a daily basis, as they are the most likely targets of a spreading
virus. Other executable files should be checked prior to being
run or before they are exported to another system. Static data
(like initialization files) should also be periodically checked;
checking dynamic data (like data base files) will usually result
in CHECKUP detecting file modifications.

Note that CHECKUP does not require the attributes of hidden
and system files be changed prior to checking. CHECKUP will
successfully process all files, regardless of type, provided the
files are specified correctly on command-line.


Upon exiting to DOS, CHECKUP returns the following
ERRORLEVELs to the operating system. These ERRORLEVELs can be
tested for and acted upon in any DOS batch file:

ERRORLEVEL = Condition

0 = Process terminated normally
1 = Input file(s) modified since last check
2 = Fatal error occurred
3 = Cancelled on demand (user aborted)

The ERRORLEVEL condition will test positive if CHECKUP
generates an exit code equal to or greater than the ERRORLEVEL
being tested for; this means that ERRORLEVELs must be checked in
descending order to insure accuracy. For example, the following
batch file command executes if the ERRORLEVEL is equal to or
greater than 1:

[ ...
IF ERRORLEVEL 1 [command]
... ]

This code demonstrates how one command can be executed for
ERRORLEVELs equal to or greater than 2 while a separate action is
reserved for an ERRORLEVEL of 1:


[ ...
IF ERRORLEVEL 2 [command]
IF ERRORLEVEL 1 [command]
... ]

Finally, this code excerpt shows how different commands can
be executed for different ERRORLEVELs:

[ ...
IF ERRORLEVEL 3 [command]
IF ERRORLEVEL 2 [command]
IF ERRORLEVEL 1 [command]
... ]

ERRORLEVEL reporting is provided as a tool to aid in the
control of batch file execution; CHECKUP does not require users
to test ERRORLEVEL conditions.


The first time a file is checked, CHECKUP creates an .XUP
file in the same directory as the target file. CHECKUP creates
one .XUP for every checked file; access to the .XUP files are
required during future checks. If CHECKUP or any .XUP files are
mysteriously deleted or altered, a CHECKUP-aware virus may have
infiltrated your system. To prevent viruses from gaining control
of CHECKUP's files, use the clean floppy disk/batch file method
described in the section titled "CREATING A CLEAN CHECKUP FLOPPY
DISK," above.


".XUP" is CHECKUP's default output file extension. There
are times, however, when use of the .XUP extension presents
complications (when checking numbered overlay files, for example,
or files with the same name). CHECKUP provides two command-line
alternatives designed to resolve target filename conflicts: the
/R[EPLACE] and /S[HIFT] commands.

1. The /R[EPLACE] command creates output files with
"replacement" extensions when a /R appears on
CHECKUP's command-line. CHECKUP replaces the
first character of the input file extension with
the letter X:

OVERLAY.001 Input file
OVERLAY.X01 Optional replacement extension
OVERLAY.XUP Default CHECKUP output file


OVERLAY.002 Input file
OVERLAY.X02 Optional replacement extension
OVERLAY.XUP Default CHECKUP output file

When checking OVERLAY.002, CHECKUP will attempt to
use OVERLAY.XUP--an incorrect data file since it
contains output information gathered from checking
OVERLAY.001. In this example, a non-fatal
"Input/output file mismatch" error would occur if
the /R switch was not used.

2. The /S[HIFT] command creates output files with
"shifted" extensions when a /S appears on
CHECKUP's command-line. CHECKUP replaces the
first character of the input file extension with
the letter X and replaces the second two
characters of the input file extension with the
first two characters (in effect shifting the
extension one character to the right):

COMMAND.COM Input file
COMMAND.XCO Optional shifted extension
COMMAND.XUP Default CHECKUP output file

Use CHECKUP's alternate output file extension options
whenever Input/output file mismatch errors are encountered, when
checking overlay files with numeric extensions or input files
with the same name.


CHECKUP maintains a file named CHECKUP.LOG on the root
directory of the logged disk. CHECKUP.LOG contains a detailed
record of CHECKUP's activities and may be invaluable in the event
a virus is detected; it will be your only recorded history of
viral exercises.

You can view the CHECKUP.LOG file with any ASCII editor and
delete it at any time (although we recommend back-up copies be
maintained). The CHECKUP.LOG file is provided as an
informational tool only; CHECKUP does not require it to run.

You can optionally SET a log file directory. CHECKUP will
store the CHECKUP.LOG file in the directory specified by the LOG
or TMP environment variables. The following command (ideally
added to AUTOEXEC.BAT) causes CHECKUP to store the CHECKUP.LOG
file in the C:\CANYA\DIGIT directory:



CHECKUP looks first for the LOG, then the TMP, environment
variables. If LOG is not found or null, CHECKUP attempts to use
the TMP variable. If TMP is not found or null, CHECKUP will use
the root directory of the default drive. Note that output of the
CHECKUP.LOG file can be suppressed if the /N[OLOG] switch appears
on CHECKUP's command-line.


The following messages are encountered when using CHECKUP:

1. This is the unregistered commercial version ....

An unregistered commercial version of CHECKUP was
launched. See the section titled "REGISTRATION
FORM," above, for information on how to register
your copy of CHECKUP.

2. This is not free software.

An unregistered, user-supported shareware version
of CHECKUP was launched. See the section titled
"REGISTRATION FORM," above, for information on how
to register your copy of CHECKUP.

3. Syntax is ....

CHECKUP was launched without command-line
parameters and the help screen was displayed.

4. Cancelled on demand

Either the ESC or C keys were pressed; CHECKUP
discontinued file processing and returned to DOS.
An ERRORLEVEL of 3 was returned to DOS by CHECKUP.

5. Press any key to continue

Either the SPACE, P, CR or I keys were pressed, or
CHECKUP detected file size or CRC changes while
the /P[AUSE] option was specified on the
command-line. CHECKUP paused processing and
displayed this message.

6. Checksums|CRCs|ECRCs calculated and logged

CHECKUP processed the input file for the first
time or updated an existing .XUP file to a new


7. File sizes are different

The input file size changed since CHECKUP first
processed it. An ERRORLEVEL of 1 was returned to

8. Checksum|CRC|ECRC error on block # ....

CHECKUP detected changes to the input file
beginning at the specified block number. An
ERRORLEVEL of 1 was returned to DOS by CHECKUP.

9. Checksums|CRCs|ECRCs match

The input file has not changed since CHECKUP last
processed it.


CHECKUP detected file size or checksum|CRC|ECRC
changes. An ERRORLEVEL of 1 was returned to DOS

11. ... file(s) checked

CHECKUP completed processing of one or more files.

12. System locked

CHECKUP detected changes to an input file while
the /L[OCK] command was specified on the
command-line. An ERRORLEVEL of 1 was returned to


The following error messages may be encountered when using

1. Endless loop error

See the explanation of "Loop error," below.

2. Bad file name
Bad file name or number

See the explanation of "Path/File access error,"


3. Device fault
Device timeout
Device unavailable
Disk media error
Disk not ready

Indicates a hardware error (like an open disk
drive door or a bad, non-existent or incorrectly
specified device) or a hardware failure (such as a
damaged disk).

Retry the operation after checking disks, disk
drive doors, printer switches, cables, connections
and related hardware.

4. Device I/O error

An unrecoverable input/output error occurred.

Retry the operation.

5. Disk full

The disk is full.

Retry the operation using another disk or delete
some non-CHECKUP related files from the current

6. Error in EXE file

A portion of the CHECKUP.EXE file is missing or
the file is corrupt.

Replace CHECKUP.EXE with a certified clean copy
downloaded direct from one of CHECKUP's principal
distribution points. See the section titled
"UPGRADE POLICY," above, for a list of authorized
distribution points or call 215-333-8274 to
arrange the purchase of a new CHECKUP master disk.

7. File not found

An input filespec does not exist.

Retry the operation using the correct filespec.


8. Input file contains 0 bytes

The input file did not contain data.

Retry the operation using a file that contains

9. Input/output file mismatch

The input file was not the same as the one used to
create the output .XUP file.

Retry the operation using the correct input and
output files. Use either the /R[EPLACE] or
/S[HIFT] options on CHECKUP's command-line to
prevent most input/output file mismatches from

10. Out of memory
Out of string space

CHECKUP needs more RAM than is available.

Retry the operation after unloading TSRs (memory
resident utilities like "SideKick") or buy an
expansion card to increase the amount of RAM.

11. Path/File access error
Path not found

An input file or path does not exist.

Retry the operation using the correct path and
file name.

12. Permission denied

An attempt was made to write to a write-protected
disk or to a locked file in a multi-user or
networked environment.

Retry the operation.

13. Too many files

CHECKUP was unable to open the input file.

Try adding the following statement to the

FILES = 25


14. Loop error

See the explanation of "Endless loop error,"


The following error messages should never be encountered.
If they are, they indicate an internal problem with CHECKUP.
Contact us if any of these error messages are displayed more than

Out of DATA
Illegal function call
Subscript out of range
Division by zero
String formula too complex
CASE ELSE expected
Variable required
FIELD overflow
Internal error
File not found
Bad file mode
File already open
FIELD statement active
File already exists
Bad record length
Input past end of file
Bad record number
Communication-buffer overflow
Advanced feature unavailable
Rename across disks
Registration error
Filename initialization error
Unassigned error
Compression unsuccessful
No-new-taxes error


CHECKUP provides many advantages over other anti-virus

* CHECKUP is fast, taking only seconds to check most


* CHECKUP is easy to use. There are no commands or
switches to learn (they're optional), no
maintenance modes, no extraordinary hardware
requirements and no unusual installation
procedures or other cumbersome features.

* CHECKUP is easily customized, allowing users to
override all automated features and implement the
options of their choice.

* CHECKUP is 100% compatible with IBM PC-compatible
computers and software.

* CHECKUP is 100% accurate, capable of detecting
changes to any file, regardless of type, size,
attributes or storage location.

* CHECKUP is capable of detecting all viruses--past,
present and future--with absolute accuracy,
without requiring hardware or software upgrades.

* CHECKUP, when used as directed, is 100% secure
from viral infection and alteration.

* CHECKUP never writes to or modifies input files.

* CHECKUP never writes to or modifies sensitive disk
boot sectors, nor does it tamper with File
Allocation Tables or disk directories.

* CHECKUP does not reduce the amount of available

* CHECKUP, when used as directed, does not reduce
available disk space.

* CHECKUP provides a relocatable usage log that
tracks file checkups, verifications and changes.

* CHECKUP is available as user-supported software,
allowing shareware users a full and fair
evaluation prior to purchase.

* Unregistered copies of CHECKUP can be legally
shared among users without fear of promoting
software piracy.

* CHECKUP is easy to register, requiring only one
command to enable advanced features and to disable
the time-delayed opening screen.


* CHECKUP is reasonably priced for home and non-home
users alike.

* CHECKUP can be easily upgraded by mail or
electronic BBS.

* Support for CHECKUP is free and available by mail,
telephone or electronic BBS.

* CHECKUP is the virus detection system preferred by
educated users.


Flu_Shot Plus, an anti-virus TSR program, incorrectly flags
CHECKUP as attempting to write to the input file being checked.
CHK4BOMB, an anti-bomb program, incorrectly identifies CHECKUP as
capable of formatting a hard disk.

CHECKUP's output is restricted to the .XUP files and the
CHECKUP.LOG file. CHECKUP cannot overwrite an input file, format
a disk or perform other destructive actions. If you are
concerned about the integrity of your copy of CHECKUP, however,
visit one of CHECKUP's principal distribution points and download
the latest version. See the section titled "UPGRADE POLICY,"
above, for a list of authorized distribution points.


By employing the techniques described below, you will
severely limit the ability of computer viruses and other
destructive software to affect your system. We welcome your
enhancements and additions to this list:

* Run CHECKUP daily, using the clean floppy
disk/batch file method described above. (See the
DISK," above, for more information on creating a
clean floppy disk.)

* Run major applications via DOS batch files and
have CHECKUP perform pre-run, last-minute checks
of programs about to run. Use the /L[OCK]

command-line option to prevent execution of the
target file when file modifications are
encountered or use the DOS "GOTO" batch file
command to skip execution of the checked file if
the ERRORLEVEL reported by CHECKUP is not 0.


For example, instead of typing the "WORD" command
to run Microsoft Word, create a batch file named
"WRD.BAT" that reads as follows:










Then, in the future, use the WRD command to invoke
Microsoft Word. CHECKUP will examine all of
Microsoft Word's executable files and will allow
them to run if (and only if) they pass CHECKUP's
scrutiny. Of course, unlike Microsoft Word, many
applications have only one principal executable
file to check, greatly simplifying implementation
of pre-run checking through DOS batch files.

You can also store pre-run .XUP files on a clean
floppy disk or have pre-run batch files rename the
.XUP files for an extra measure of protection.
See the section titled "CREATING A CLEAN CHECKUP
FLOPPY DISK," above, for information on creating
clean floppy disks.

* Use CHECKUP to examine files after they are first
installed and before exporting them to another system.
Do not export files that fail to pass CHECKUP's


* Regularly check and log available disk space.
Aggressive viruses decrease storage space as they
spread throughout a system. This activity can be
identified through rigorous monitoring.

The following commands, added to AUTOEXEC.BAT,
will track disk usage:

CD \

* Observe the time it takes for programs to
load--infected files take longer. Programs
exhibiting longer than normal load times may be
infected (see next tip for related information).

* Scrutinize disk accesses whenever possible.
Viruses can spend large amounts of time scanning
directories and executable files as they search
for new, uninfected host files. Programs
conducting longer than normal disk I/O, especially
during load-time, may be infected.

* Periodically re-install applications from their
master disks. This overwrites application files
in use and any viruses incubating within them.

* Once a week, use the SYS command to re-install the
system files onto your boot disk(s). This
eliminates viruses lurking in the boot sectors.

* Use the DOS "SHELL" command to rename and relocate
COMMAND.COM to a directory other than the root of
your boot disk. Then place a different copy of
COMMAND.COM in the root directory. This may
divert viruses into infecting the decoy copy
instead of your actual command processor. Refer
to your DOS reference manuals for information on
the SHELL command.

* Boot from a certified clean floppy disk copy of
your DOS master disks whenever possible. This
insures your system is running under an
uncorrupted operating system at all times.


* Change executable file attributes to read-only.
Poorly engineered viruses may not be able to alter
read-only files. (Executable files are those
ending in a .BAT, .COM or .EXE extension or those
loaded in CONFIG.SYS. Some application programs
use non-standard extensions on their executable
files [numbered overlays, for instance]. Check
with your software vendors for detailed
information about specific application programs.)

Many programs write to their master executable
file when saving configuration information. If
such a file has been converted to read-only, the
read-only attribute must be removed before
re-configuring and reset afterward.

There are many utilities that can reset file
attributes, including ATTR.COM, available for
downloading from the PC-Magazine Network on
CompuServe. CompuServe users can "GO PCMAGNET" to
download ATTR.COM. If you own the Norton
Utilities, use Norton's FA.EXE to change file
attributes. To change COMMAND.COM to read-only
using Norton's FA, enter:


Some versions of DOS provide an ATTRIB (or
similar) command. Check your DOS reference
manuals for more information on modifying file

* Use extreme caution when working with directory
and FAT editors, directory sorters, disk
optimizers, disk "snoopers," DOS shells, file
movers, format-recovery systems, partition-related
tools, un-erasers and other low-level DOS
utilities. These programs manipulate critical
data and one bug or errant keystroke can
annihilate a disk.

Safe bets for low-level disk management are the
Norton Utilities, Advanced Edition, from Peter
Norton Computing, Inc.; PC-Tools from Central
Point Software and the Mace Utilities from Paul
Mace Software. Among DOS shells, we recommend the
Norton Commander, also from Peter Norton
Computing, Inc. These programs are available at
most computer retailers.


* Install a hard disk utility like BOMBSQAD,
Tab). As TSRs, these programs may suffer from the
drawbacks discussed earlier, however, they provide
adequate protection against poorly engineered
bombs and viruses.

* Do not run files downloaded from public access
BBSes (bulletin board systems) that do not
validate users who upload. If the SysOp of a
bulletin board did not contact you directly (by
phone, mail or automatic callback), you can be
certain that other users have not been validated.
(SysOps: If validating users is a burden, a
practical alternative is to validate them after
they upload their first file.)

* Do not run files downloaded from public access
BBSes where the SysOps do not test and approve all

* Do not run files provided by shareware/public
domain disk distributors, including your local
users group, where the disk librarians do not test
and approve all files.

* Do not run self-extracting archives unless they
have been tested. Self-extracting archives are a
classic delivery method used by bomb developers.

* Beware of suspicious-looking files. A 128 byte
.COM file that un-archives without documentation
and whose description reads "Great Word Processor"
is certainly suspect.

* Use a binary file-viewing utility (like the one
included in the Norton Commander) to examine

executable code. Look for suspicious comments and
messages embedded in the code.

* Do not run programs unaccompanied by well-written
documentation prepared by the program's author.

* Do not run programs that do not include the name,
address and telephone number(s) of the author
within the documentation or executable(s).


* Call program authors and verify the version
number, time and date stamps, file sizes and
archive contents of files you have received. Ask
authors where you can get certified clean copies
of their programs, then discard the copies you
have and get the certified copies.

* Download shareware direct from the author's BBS.
Most professional shareware authors provide
support BBSes for their products. You are
guaranteed uncorrupted programs when you download
them directly from their authors.

* Do not use hacked or pirated software. Software
pirates have the skill and the tools needed to
create bombs and viruses. Many reported incidents
of viral infections have been associated with
software piracy. In fact, some of the deadliest
Trojans have been modified copies of well-known

* Back-up your system regularly! No system exists
in a vacuum, nor is any anti-virus or anti-Trojan
technique foolproof. Back-up on a daily, weekly
and monthly basis. When disaster strikes, users
who have regularly backed-up their systems will
have the last laugh (and their data)!


Systems exhibiting any of the following traits should be
checked by an experienced viral diagnostician. If you are unable
to locate a good consultant, call us for advice (don't be shy;
we've helped hundreds of users resolve their virus-related

1. Computer operations seem sluggish.

2. Programs take longer to load.

3. Programs access multiple disk drives where they
didn't before.

4. Programs conduct disk accesses at unusual times or
with increased frequency.

5. Available disk space decreases rapidly.

6. The number of bad disk sectors steadily increases.


7. Memory maps reveal new TSR programs of unknown

8. Normally well-behaved programs function abnormally
or crash without reason.

9. Programs encounter errors where they didn't

10. Programs generate undocumented messages.

11. Files mysteriously disappear.

12. Files are replaced with objects of unknown origin
or replaced with garbled data.

13. Names, extensions, dates, attributes or data
changes on files or directories that have not been
modified by users.

14. Data files or directories of unknown origin

15. CHECKUP detects changes to static objects (files).
Changes detected to dynamic objects are not
necessarily an indication of viral alterations.


Swift action is called for when a viral infection has been
diagnosed and confirmed. The longer eradication is delayed, the
larger the scope of the infection will become; virus removal
without loss of data could become impossible. The following
steps, performed immediately upon detection of a virus, will
usually cure a system from a viral infection:

1. Wash your hands and face. Wear rubber gloves if

2. Delete all executable files (those ending in a
.COM, .EXE or .SYS extension and any other files
you know to be executable [such as MW.PGM and
overlay files]) from the infected disk.

3. Turn off your computer. Wait sixty seconds.

4. Write-protect all storage media (disks, tapes,

5. Remove all non-fixed storage media (floppy disks,
streaming tapes, etc.).


6. Disconnect all external port-connected peripherals
(printers, modems, etc.) except for the video
monitor and keyboard.

7. Insert a write-protected, factory master copy of
DOS into drive A. Close the disk drive door, then
turn your computer on.

8. After your computer has completed the start-up
process, enter the following commands:

SYS [d:]

where [d:] is the letter of the drive being

9. After the system files have been re-installed via
the SYS command, manually re-install all of your
favorite application programs, one by one, from
their write-protected, factory master disks onto
the disk being eradicated.

10. Re-format all external storage media (disks,
tapes, etc.). (CAUTION: During the eradication
process, do NOT insert disks containing
drive unless they are the write-protected, factory
master copies of DOS. Destroy all storage media
containing non-factory master copies of DOS.)

11. After your application programs have been
re-installed onto the disk being eradicated,
remove the write-protected, factory master copy of
DOS from drive A. Turn your computer off. Wait
sixty seconds, then turn your computer on.

12. Back-up your system onto NEW, NEVER USED storage
media (floppy disks, streaming tapes, etc.) using
whatever method of back-up you prefer. Do NOT
overwrite or append back-up data to old back-up
disks or tapes.

13. If, after a few hours or days, the virus
reappears, you will have no choice but to
re-format your floppy disks or low-level re-format
your hard disk(s). Contact your computer dealer,
consultant or hardware manufacturer for
instructions on how to low-level re-format or call
us for technical support.



The buzz words relating to the many faces of rogue software
are often misused by both users and the popular computer press.
Worms are confused with viruses, the three types of software
bombs are usually addressed as one all-encompassing
classification, and so on. We hope to clear up some of this
misinformation and confusion by presenting this guide to popular
virus-related terms:

Anti-virus A program designed to prevent or
detect viral infections.

Back Door Undocumented, secret program
features or commands known only
(and perhaps available only) to the
program's designer.

Bomb A program that unconditionally
executes destructive instructions
(actions) without user

Bug A hardware or software error that
causes a system or program to
function incorrectly.

Drill Sergeant A bomb, logic bomb or time bomb
program that continuously executes
other programs or operating system

Host See the definition of "Target,"

Hostess A yummy cupcake.

Input file See the definition of "Target,"


Logic bomb A program that conditionally
executes destructive instructions
(actions) without user
authorization, depending upon the
status of specific environmental
variables. For instance, a logic
bomb could monitor payroll records,
looking for the designer's social
security number. The logic bomb
could be programmed to detonate
(erase the payroll records or
re-format the hard disk) if the
social security number failed to
appear in the records for three
consecutive weeks.

Rabbit See the definition of "Replicator,"

Replicator A bomb, logic bomb or time bomb
program that creates--continuously
and without end, either on-disk or
in-memory--independent, executable
copies of itself.

Rogue Any program specifically designed
with the capability to destroy
hardware or software without user

Target Any computer or file that is
subject to at least one category of
rogue software.

Time bomb A program that conditionally
executes destructive instructions
(actions) without user
authorization, depending upon the
status of counter- or time-related
environmental variables. For
example, a time bomb could be
programmed to detonate after three
consecutive runs, to detonate on a
given date (such as April first or
Friday the thirteenth) or to
detonate at a certain time (like


Trojan Horse A bomb, logic bomb, time bomb,
virus, worm or other rogue
(destructive) program that pretends
to be an ordinary (non-destructive)

Virus A program that modifies other
programs to include an executable
(and possibly altered) copy of

Virus detector A program designed to detect viral

Worm (core) A program that consumes memory by
traveling through it, much like a
worm burrows through dirt.

Worm (network) A program that travels through a
network from computer to computer,
sometimes creating executable
copies of itself in the process.


Version Release Date

1.0 April 1, 1988
2.0 December 18, 1988
3.0 April 12, 1989
3.5 June 14, 1989


Give your files a CHECKUP! (tm)


This document was created using Microsoft WORD Version 4.0

- End of CHECKUP.DOC -

 December 17, 2017  Add comments

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>