Rich Levin's CHECKUP (tm) Virus Detection System Documentation for Version 3.9 (See UPDATE.DOC for updates to this document) Released April 29, 1990 For IBM PC, XT, AT, PS/2 and all IBM-compatible DOS-based personal computers COMPUTE!'s PC Magazine Editors Choice for Virus Protection The featured virus detection system in John Dvorak's and Nick Anis' book, "Dvorak's Guide to PC Telecommunications." ***************************************************************** LOOK FOR RICH LEVIN'S NEW BOOK, "THE COMPUTER VIRUS HANDBOOK," AN OSBORNE/MCGRAW-HILL PUBLICATION, COMING THIS SUMMER TO A BOOKSTORE NEAR YOU ***************************************************************** Entire contents copyright (c) 1988-1990 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 $24.95 (U.S.) per copy for home users and $49.95 (U.S.) per copy for office (non-home) users. Deluxe and premium editions are available to all users for $74.95 and $99.95 (U.S.), respectively. Registered users receive a special program, REGISTER.EXE, that enables CHECKUP's advanced features and disables CHECKUP's time-delayed opening screen. Remit registration fees to: Richard B. Levin, Levin & Associates, 9405 Bustleton Ave., 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 Levin & Associates 9405 Bustleton Ave. P.O. Box 14546 Phila., PA 19115 Lab: (215) 333-8274 BBS: (215) 333-8275 CompuServe: 72407,243 Delphi: RLEVIN GEnie: R.LEVIN MCI: Via CompuServe FAX: On request Information on site licenses available on request. Dealer, consultant and VAR programs available. Thank you for using CHECKUP. Table of Contents CONSUMER ALERT.............................................2 COPYRIGHT NOTICE...........................................2 SOFTWARE LICENSE...........................................2 Exclusion of Warranties................................3 Ten Day Evaluation Period..............................3 Program Usage..........................................3 Program Sharing........................................4 Other Terms and Conditions.............................4 DISTRIBUTION POLICY........................................5 UPGRADE POLICY.............................................6 REGISTRATION FORM..........................................7 ACKNOWLEDGEMENTS...........................................9 IMPORTANT NOTES............................................9 MINIMUM HARDWARE AND SOFTWARE REQUIREMENTS.................9 NOTE TO USERS.............................................10 A COMPUTER VIRUS OVERVIEW.................................10 THE TROUBLE WITH ANTI-VIRUS SOFTWARE......................11 Prevention Systems....................................11 Detection Systems.....................................12 Anti-bomb detectors...............................12 Anti-virus detectors..............................13 Program-specific detectors....................13 Generic detectors.............................13 Hit and Miss--Anti-Virus Software Failings............14 Vaccines..........................................14 Antidotes.........................................17 Disaster antidotes............................17 Infection antidotes...........................17 File Comparison Utilities.........................19 Virus Scanners....................................20 Disk Mappers......................................21 Memory-Resident Anti-Virus Programs...............22 HOW CHECKUP WORKS.........................................24 RUNNING CHECKUP...........................................25 CHECKUP's Command-Line Options........................26 CHECKUP's .XUP Files..................................34 CHECKUP's Alternate Output File Extensions............34 The /RE[PLACE] command............................35 The /SH[IFT] command..............................35 Examples of CHECKUP Command-Line Usage................36 CHECKUP's Errorlevels.................................37 The CHECKUP.LOG File..................................38 Creating Clean CHECKUP Floppy Disks...................38 CHECKUP's XUP.BAT/AUTOEXEC.BAT File...................41 Run-Time Messages and Explanations....................43 Error Codes, Error Messages and Explanations..........46 Conflicts with Other Anti-Rogue Programs..............51 ADVANTAGES OF USING CHECKUP...............................51 A COLLECTION OF ANTI-TROJAN/ANTI-VIRUS TECHNIQUES.........53 Boot From a Floppy Disk...............................53 Employ Virus Detection Software.......................55 Use Pre-Run File Checkups.............................56 Change File Attributes................................57 Use Command-Processor Decoys..........................58 Use Application File Decoys...........................59 Reinitialize the System...............................60 Reinstall Application Files...........................61 Reformat Hard Disks...................................61 Use Low-Level Disk Managers with Caution..............62 Observe Program Loading and Disk Access Times.........63 Log Available Disk Space..............................63 Log Bad Sectors.......................................64 Shareware with Care...................................65 Tip #1............................................66 Tip #2............................................66 Tip #3............................................66 Tip #4............................................67 Tip #5............................................67 Tip #6............................................67 Tip #7............................................68 Don't Use Pirated Software............................68 Beware of Salesmen Bearing Gifts......................69 Backup!...............................................69 DIAGNOSING INFECTED COMPUTERS.............................70 Computer Virus Warning Signs..........................71 What To Do When Your Systems Are Infected.............72 A GUIDE TO POPULAR VIRUS-RELATED TERMS....................76 CHECKUP'S RELEASE HISTORY.................................79 "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." Dr. Eugene H. Spafford Associate Professor Department of Computer Sciences Perdue University CONSUMER ALERT This Is The Original CHECKUP (tm) Virus Detection System Not To Be Confused With Programs Using Deceptively Similar Names If It's Not Software By Rich Levin It's Not Rich Levin's CHECKUP (tm) Virus Detection System Rich Levin's CHECKUP (tm), the original "clean disk" anti-virus software system, has become one of the world's leading virus detection programs for IBM PC-class microcomputers. It is used by government agencies of the USA, Canada, Central and South America, Europe, Asia 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 computers world-wide than all other anti-virus systems combined. The world's most experienced users entrust their computers to Rich Levin's CHECKUP (tm) Virus Detection System. COPYRIGHT NOTICE 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-1990 Richard B. Levin ("the author"), all rights reserved. The CHECKUP system is protected by United States Copyright Law (Title 17 United States Code). Unauthorized use may result in imprisonment of up to one year and fines of up to $10,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. SOFTWARE LICENSE Please read the terms and conditions of this software license before using the CHECKUP system. These terms constitute the entire agreement between you and the author with regard to the CHECKUP system. This license is effective from the date 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. Rich Levin's CHECKUP (tm) Version 3.9 Page 2 Exclusion of Warranties 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. All warranties, including the warranties of merchantability and fitness for a particular purpose, are hereby excluded. 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 of damaged or unusable hardware and software. In no event will the author be liable for any lost profits, lost savings or other consequential, special or indirect damages incurred by you or any other party through the use or misuse of the CHECKUP system, even if the author has been advised of the possibility of such losses or damages. Ten Day Evaluation Period You are granted a limited license to use and evaluate one unregistered copy of the CHECKUP system on a single computer for a period of ten days, commencing from 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 either the "REGISTRATION FORM" section of the CHECKUP system's accompanying documentation (the CHECKUP.DOC file) or the accompanying REGISTER.DOC file. Upon credit of your paid registration, the author will provide you with both a program and a data file (REGISTER.EXE and CHECKUP.REG) that enable the CHECKUP system's advanced features and disable its time-delayed opening screen. Program Usage Registered users of the CHECKUP system are granted the nonexclusive 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 unregistered computers. Failure to register copies of the CHECKUP system used on unregistered computers is a violation of this license and a violation of United States Copyright Law. Rich Levin's CHECKUP (tm) Version 3.9 Page 3 Program Sharing UNREGISTERED copies of the CHECKUP system display the message "Unregistered copy" on the title screen when the program is run. REGISTERED copies of the CHECKUP system display a registered user's serial number on the title screen when the program is run. 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 or distribute, in whole or in part, REGISTERED copies of the CHECKUP system, the REGISTER.EXE file or the CHECKUP.REG file. Copying or distributing, in whole or in part, REGISTERED copies of the CHECKUP system, the REGISTER.EXE file or the CHECKUP.REG file is a violation of this license and a violation of United States Copyright Law. Registered users are permitted to make archival backup copies of the CHECKUP system. Other Terms and Conditions You are not permitted to decompile, disassemble, make changes to, reverse engineer or create derivative works of the CHECKUP system, nor are you permitted to attempt to decompile, disassemble, make changes to, reverse engineer or create derivative works of the CHECKUP system. This license is nontransferable. Any violation of this license or attempt to assign, rent, lease, sell, sublicense, transfer or otherwise dispose of the CHECKUP system, except as provided for herein, renders this license null and void. This agreement may not be modified by anyone other than the author. The author reserves the right to make changes to this license and to the CHECKUP system at any time, without prior notification. This license is governed by the laws of the Commonwealth of Pennsylvania and by the laws of the United States of America. Terms or conditions of this license found to be invalid, unenforceable or illegal under applicable law shall be deemed omitted and the remaining provisions will continue in full force and effect. Rich Levin's CHECKUP (tm) Version 3.9 Page 4 DISTRIBUTION POLICY UNREGISTERED copies of the CHECKUP system display the message "Unregistered copy" on the title screen when the program is run. REGISTERED copies of the CHECKUP system display a registered user's serial number on the title screen when the program is run. You are permitted to copy and distribute UNREGISTERED copies of the CHECKUP system to other users when the following conditions are met: 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, rearchived 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. Rich Levin's CHECKUP (tm) Version 3.9 Page 5 UPGRADE POLICY The latest edition of the CHECKUP system 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 data libraries on the CompuServe Information Service (GO IBMSYS) and to the IBM and BBS RoundTables on the General Electric Network for Information Exchange (GEnie). Upgrades will soon be available on Delphi. Registered users can enable advanced features of CHECKUP system upgrades and disable their time-delayed opening screen. Upgrades are also available by mail. Send a blank, preformatted, IBM-compatible 360kb, 1.2mb, 720kb or 1.44mb diskette, a postage-paid, preaddressed disk mailer and payment in the amount of $12.95 (U.S.) for home users and $24.95 (U.S.) for office users to: Richard B. Levin Levin & Associates CHECKUP v.3.9 Upgrade 9405 Bustleton Ave. P.O. Box 14546 Phila., PA 19115 International cheques and money orders will NOT be honored unless they are payable in United States currency through a United States bank. Registered users should note their registered user serial number on their orders. Rich Levin's CHECKUP (tm) Version 3.9 Page 6 Rich Levin's CHECKUP (tm) Virus Detection System REGISTRATION FORM Please print, complete and mail this form within ten days to: Richard B. Levin Levin & Associates CHECKUP Version 3.9 Registration 9405 Bustleton Ave. P.O. Box 14546 Phila., PA 19115 Please make all checks and money orders payable in United States currency to "Richard B. Levin." International cheques and money orders will NOT be honored unless they are payable in United States currency through a United States bank. Purchase orders are accepted on a net terms basis with approved credit and a minimum initial purchase of $300.00. Orders are shipped FOB Philadelphia, via U.S. Mail or UPS. Site license and other information available on request. Prices, terms and conditions subject to change without notice. Please allow six weeks for delivery. For customer service inquiries, please call (215) 333-8274 or call our BBS at (215) 333-8275. PLEASE HAND PRINT CLEARLY USING PEN OR PENCIL. TO INSURE THE PROMPT PROCESSING OF YOUR ORDER, DO NOT USE COMPUTER PRINTERS TO COMPLETE THIS FORM. Date: _____/_____/_____ Your name and address: _________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ _________________________________________________________________ [ ] Corporate user. Business card attached. Home telephone number: ( ) - Work telephone number: ( ) - Data telephone number: ( ) - [ ] Check here if you would like information on site licenses [ ] Check here if you would like a representative to call Rich Levin's CHECKUP (tm) Version 3.9 Page 7 Available registration payment plans: 1. HOME editions are available ONLY to users running the CHECKUP system on their personal computers in their homes. All other use is prohibited. 2. OFFICE editions must be purchased by all non-home users of the CHECKUP system. HOME editions may NOT be used in a non-home environment. 3. DELUXE editions include a bound volume of the CHECKUP system documentation and are available to all users. 4. PREMIUM editions include one DELUXE edition and one copy of Rich Levin's Osborne/McGraw-Hill book, "The Computer Virus Handbook" (available summer 1990). PREMIUM editions are available to all users. HOME editions ordered: [# ] x $ 24.95 = $ .00 OFFICE editions ordered: [# ] x $ 49.95 = $ .00 DELUXE editions ordered: [# ] x $ 74.95 = $ .00 PREMIUM editions ordered: [# ] x $ 99.95 = $ .00 ----------------------------------------------------------------- Total copies ordered: [ ] Subtotal: $ .00 Shipping and handling (see table*, below): $ .00 Pennsylvania residents add 6% sales tax: $ .00 ----------------------------------------------------------------- Amount enclosed: $ .00 ================================================================= * Shipping charges: HOME and OFFICE editions: $2.00 per copy DELUXE editions: $4.00 per copy PREMIUM editions: $6.00 per copy International orders please add $2.00 to the above charges for foreign shipping charges Disk format: [ ] 360kb [ ] 1.2mb [ ] 720kb [ ] 1.44mb Payment method: [ ] Check or money order (DO NOT SEND CASH) [ ] Bill me. My purchase order is attached. Please sign here: ______________________________________________ Rich Levin's CHECKUP (tm) Version 3.9 Page 8 ACKNOWLEDGEMENTS Thanks to Kathy Ivens for helping prepare this documentation. Thanks also to Microsoft for their assemblers, compilers, linkers and other programming tools. A tip of the hat to Peter Norton Computing, Inc., for the Norton Editor, in which all of CHECKUP's code was written, and for the Norton Commander and Norton Utilities. Thanks to Quarterdeck for DESQview-386 and to Hammerly Labs for the ProBAS libraries. Special thanks to CompuServe and Don Watkins, Chief SysOp of IBMNET, and to Conrad Kageyama, IBMNET CoSysOp. Thanks to Nelson Ford and his Public (software) Library--still the best among the rest--and to Yoshi for LHarc. Thanks are due to Advanced Logic Research (ALR), AST, BTC (Behavior Tech Corporation), Casio, Hercules, IBM, Intel, Intellicom, Keytronics, Kodak, Microsoft, Mitsubishi, MultiTech, Panasonic, Practical Peripherals, Seagate, Sysgen, Thomson, Toshiba, Tripp-Lite, Verbatim and Western Digital for their compatible and dependable computer hardware. And finally, thanks to you, for using and supporting Rich Levin's CHECKUP (tm) Virus Detection System. IMPORTANT NOTES 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. For complete information on computer viruses, read Rich Levin's "Computer Virus Handbook," an Osborne/McGraw-Hill Publication, available this summer at quality bookstores everywhere. MINIMUM HARDWARE AND SOFTWARE REQUIREMENTS IBM PC, XT, AT, PS/2 or true compatible 128k RAM Video display adapter and monitor Floppy disk drive PC/MS-DOS v.2.1 or higher Rich Levin's CHECKUP (tm) Version 3.9 Page 9 NOTE TO USERS MS-DOS, the Microsoft Disk Operating System, is the most popular disk-based operating system among users of IBM PC-compatibles; it is a de facto standard with over fifty million users world-wide. MS-DOS is sold under a variety of manufacturer's names, including "IBM PC-DOS." When this document makes reference to "DOS," it should be treated as synonymous with the current version of MS-DOS (v.4.01, April, 1989 release). Note also that the files IBMBIO.COM and IBMDOS.COM are the IBM PC-DOS equivalents to MS-DOS' IO.SYS and MSDOS.SYS. A COMPUTER VIRUS OVERVIEW There exists, in this wonderful but crazy computing world of ours, programs designed to do nothing more than destroy your hard-earned data, all the while pretending to be run-of-the-mill applications. These programs are popularly called "bombs" or "Trojan horses." They "explode" on unsuspecting users who do not adequately protect their systems or properly evaluate software before running it for the first time. Erased files, scrambled disk directories and reformatted disks are but some of the prices paid by victims of "rogue" software. Like bombs, computer viruses are usually delivered hidden inside harmless looking "Trojan" carriers. Unlike bombs, which detonate immediately when run, destroying both themselves and the systems they're on, 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 as files are shared, 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. To manage their activities and to avoid reinfecting files, viruses place coded messages (called "v-markers" for "virus markers") inside files during their initial infections. When unmarked files cannot be found, viruses can assume their hosts have been thoroughly overrun with viral code. Tampering with system operations and user data often begins at this time. Viruses may begin their overt operations by simply toying with users, printing mysterious or taunting messages on screens or causing abnormal system behavior. Some viruses masquerade as "normal" system errors, prompting users to search to the point of exasperation for nonexistent hardware and software faults. Other viruses take a more direct approach, displaying bouncing balls, typing errors or "smiley faces" on screens. Eventually, most viruses detonate and damage disk-based data. Rich Levin's CHECKUP (tm) Version 3.9 Page 10 It is extremely difficult--sometimes nearly impossible--to eradicate viruses allowed to attain total system saturation. Countless viral offspring can inhabit generations of backup data and multiple computers. Eradication can be a nerve wracking, time consuming, complicated process, best performed by highly skilled (and highly paid) anti-virus experts. Even then, relapses occur frequently. Computer viruses are easy to create and difficult to detect. They are ingenious, 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. Some viruses are capable of completely replacing system kernels (like IO.SYS and MSDOS.SYS) and command shells (like COMMAND.COM), thus remaining memory resident throughout entire computing sessions. Such viruses handily defeat all but the most level-headed anti-virus counter measures. Converting the attributes of potential viral targets (such as COMMAND.COM, IO.SYS and MSDOS.SYS) to "read-only" may prevent inadequately designed viruses from infecting them. Most viruses, however, can check file attributes, reset them if necessary, infect, and then return attributes to their original states. Similarly, employing anti-virus software programs may prove equally ineffective. As you will learn in the following sections, there are *NO* sure-fire ways to prevent computer viruses from infecting your systems. The only practical solution is to isolate infections immediately after they occur, using virus detection software stored off line. THE TROUBLE WITH ANTI-VIRUS SOFTWARE (or "Hey--what a market!") Anti-virus software comes in as many flavors and varieties as do computer viruses. All anti-virus software systems can, however, be broken down into two broad categories: prevention systems and detection systems. Prevention Systems Prevention systems attempt to stop rogue software attacks on a real-time basis. Some also try to prevent unauthorized programs and unauthorized users from accessing system hardware. By identifying and blocking illegal disk accesses as they happen, by stopping rogue programs from loading into memory or by employing password protection schemes to keep unauthorized users from accessing hardware and software, prevention systems can and do enhance the level of system security. Rich Levin's CHECKUP (tm) Version 3.9 Page 11 All prevention systems are, by necessity, memory-resident programs (like those popular "hot-key" programs, they terminate and stay RAM-resident after loading). Always on line and operational, they rely on the constant monitoring of DOS interrupts to detect and intercept software-driven command requests, such as "load program," "read from disk," or "write to disk." When questionable activities are encountered, e.g. a program loads and secretly requests permission from DOS to overwrite the boot sectors, prevention systems jump into action. They intercept the "DOS calls," and advise users of the trapped events. Users may then be queried as to whether or not the intercepted actions should be permitted to proceed. Of course, in the case of disk boot sector write requests, the actions should be prevented at all costs, unless users are reinitializing the protected disks. Detection Systems While prevention systems monitor software goings-on as programs are active, detection systems check program code before it's run. Detection systems complement prevention systems; they allow intruders to breach systems and then rely on sophisticated examination algorithms to isolate invaders. Users, when advised of inspected code's illicit potential, can intelligently decide whether the checked programs should be used, evaluated further or discarded. Within the "detection systems" category, however, are program definition subsets: anti-bomb detectors and anti-virus detectors. Anti-bomb detectors scan programs looking for hidden messages and destructive program commands buried within programs' code. Anti-virus detection systems specialize in isolating viral infections immediately after they have occurred. Both strategies have their advantages and disadvantages; neither scheme is foolproof. Anti-bomb detectors Most anti-bomb detectors are capable of scanning individual or multiple file sets to search for destructive routines embedded in target files' executable code (commands such as file erasure or disk reformatting program calls). Some anti-bomb detectors extract text messages stored in programs, looking for overt indications of rogue activity--statements like "Arf! Arf! Gotcha'!" or profanity. Rich Levin's CHECKUP (tm) Version 3.9 Page 12 Anti-virus detectors Due to the very nature of viral activity--viruses cause detectable changes to otherwise static (nonchanging) executable files--anti-virus detection systems are considerably more effective at detecting viral activity. This level of effectiveness, the highest among anti-virus software types, can be further enhanced by the quality of the detection algorithm put into play. Anti-virus detection programs fall into two distinct classes: program-specific detectors (commonly called "virus scanners") and generic detectors. Program-specific detectors Program-specific detectors search for a limited number of known viruses. They probe their target files, looking for identifying features ("viral signatures") of the viruses they are programmed to detect. Program files containing known viral signatures will cause virus scanners to produce messages notifying users of their discoveries. Generic detectors Well designed generic detectors are the most dependable anti-virus software type. Instead of attempting to identify and keep up with every computer virus known to man, instead of trying to plug every DOS interrupt and software hole possible, generic detectors target the single weakness, the Achilles heel, that all computer viruses share: computer viruses must change normal executable files in order to survive. Executable program files should never change in either size or content unless users physically update them, perhaps with manufacturers' software upgrades. Generic computer virus detectors operate under the basic assumption that unauthorized changes occurring in static program files are, in themselves, indications of viral activity. In fact, when program files do change without users knowingly causing the alterations, computer viruses are often the cause. Rich Levin's CHECKUP (tm) Version 3.9 Page 13 Hit and Miss--Anti-Virus Software Failings Countless utilities for combating computer viruses emerged on the market when the first wave of viral paranoia struck in early 1988. Hot on the coattails of each new wave of virus hysteria are dozens of "new and improved" anti-virus software programs. Of the anti-virus software examined during ongoing testing, all were overhyped, somewhat ineffective offerings or classic examples of engineering overkill. Lots of features, no real benefits! Practically all of the anti-virus software programs on the market today are promoted using "the fear factor"--the exploitation of undereducated users. Trusting, unknowing users are duped by vendor promises of total system security through a variety of means: disk write-protection, viral signature scanning and metamorphosis monitoring, among others. As previously stated, less than perfect anti-virus schemes provide users with nothing more than a dangerously false sense of security. Because it is of the utmost importance that users understand the failings inherent in most anti-virus programming, some observations on the state of anti-virus software measures follow. Some anti-virus software vendors will cry "foul," and say it's unfair to point out the deficiencies in their favored anti-virus program types. The real injustice, however, has been the ceaseless misrepresentation of anti-virus software effectiveness by many of those same anti-virus software vendors. Starting today, let's place honesty and integrity first, hyperbole and profitability second. Vaccines So-called "software vaccines" were among the first anti-virus products to surface when the specter of computer viruses appeared. Initial end user response to these products was positive, but as users learned more about the underlying technology of these products (and the faults inherent in that technology), sales fell off. Few such products remain on the market today, their developers out of business, their users out in the cold. Rich Levin's CHECKUP (tm) Version 3.9 Page 14 Developers of software vaccines will tell you that their programs provide software "antigens" that, when "injected" into executable files, "inoculate" them from viral infections. These implicit comparisons between anti-virus programs and true biological vaccines is misleading--marketing rhetoric that exploits uniformed users. What software vaccines actually do is append small programs and checksum data to certain executable files. The targeted executables are then modified so that, when run, control is passed first to the appended anti-virus programs. The anti-virus programs compare the executable files' current checksums to their appended checksum data. When comparisons match, control is returned to the executable files, which (if all goes well) continue their normal operations. When comparisons fail, users are alerted and appropriate actions can be taken. It's important to be aware of the shortcomings and complications associated with software vaccines before putting them into service: 1. "Vaccinated" programs take longer to load because appended anti-virus code and data increases file sizes (the amount of data that must be loaded and positioned in computer memory) and because the pre-run checksum-comparison process takes time. 2. Large amounts of disk space can be consumed, as appended anti-virus code and data enlarge program files. 3. Most vaccines can be used only with .COM and .EXE files. Device drivers, executable data and overlay files cannot be protected. 4. Some vaccines cannot protect .COM files because the vaccines try to modify .EXE file headers or the vaccines increase file sizes beyond 64k. .COM files do not have .EXE headers and they cannot be larger than 64k. 5. Many vaccines cannot protect anything more than system start-up files (IO.SYS, MSDOS.SYS and COMMAND.COM). All other files, including user data, remain unprotected. 6. 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. Rich Levin's CHECKUP (tm) Version 3.9 Page 15 7. Vaccines may not be able to act on executable files that have been processed through real-time data decompression utilities, like System Enhancement Associate's AXE and PC Magazine's PCMANAGE programs. Such programs compress executable files and decompress them in memory when run. While not unlike packed .EXE files, the superior data compression algorithms used by real-time data decompression utilities result in much smaller .EXE files and are applied after programs have been compiled and LINKed. 8. False alarms are generated when self-modifying programs (like Borland's SideKick) update internal data areas or when programs are modified as part of an installation procedure. To prevent false alarms, users are forced to remove and reinstall vaccines when self-modifying programs are used or before installation procedures take place. 9. For programmers, source code modifications and recompiled executables are often misinterpreted as viral alterations. 10. There are no guarantees that modifications to executable files (like the appending of anti-virus code and data) will not adversely affect their operations. 11. The virus-like behavior of vaccines may cause conflicts with other viral defense systems. 12. Viruses can detect the presence of vaccine program code in target executable files. They can simply delete or modify the vaccine-related data or patch vaccinated executables to bypass their load-time checksum process. 13. Nondestructive file checking utilities (in other words, generic anti-virus detectors) provide a safer, easier way of conducting pre-run file checksums and CRCs. Vaccines operate in a manner fundamentally similar to computer viruses. They attach themselves to and run in place of executable files, although they do not reproduce without authorization nor do they purposely damage files. Most users are uncomfortable with the concept of inserting a virus--antigen or otherwise--into executable files, especially when safer, less drastic alternatives are readily available. Rich Levin's CHECKUP (tm) Version 3.9 Page 16 Antidotes Viral "antidotes" appeared on the market soon after the introduction of software vaccines. Even today, when a new viral strain emerges, a new viral antidote often follows close on its heels. Originally, some viral antidotes were integrated into software vaccine programs, but now most are sold as stand-alone, dedicated systems. Most anti-virus software systems offer sub-classifications within their respective genres; viral antidotes are no different. Disaster antidotes and infection antidotes are the categories used here to discuss anti-virus antidote programs. Disaster antidotes Disaster antidotes (sometimes referred to as "format recovery" programs) are designed to restore systems to working order after destructive events have occurred. Vendors of such systems have been known to con the computing public by boldly demonstrating their programs' "amazing" ability to restore "virus-deleted" data from reformatted, repartitioned hard disks. The truth is they are merely restoring backup copies of critical disk information: the boot sectors, command processors, file allocation tables, disk directories (as well as root directory program files) and partition data. The trouble is, most users are completely unaware that reformatting and repartitioning hard disks does not actually delete all user data. Instead, those actions just mark allocated disk space as "unused." By replacing disk "road maps" with accurate backups, user data appears to be miraculously resurrected--and, in a way, it has been. Infection antidotes Infection antidotes, on the other hand, seek and remove known viruses on a file-by-file basis. These programs work reasonably well within the confines of their limited usability. You see, infection antidotes can remove only a limited set of known viruses from a narrow group of known program types. In fact, most infection antidotes are dedicated to removing a single computer virus strain. Because new viruses are being introduced all the time and because old viruses are sometimes updated, infection antidotes quickly become outdated and ineffective. In contrast, the recommended method of removing computer viruses by overwriting infected files with certified backup or master copies is reliable, regardless of the virus' date of origin or the type of infected files. Rich Levin's CHECKUP (tm) Version 3.9 Page 17 Like software vaccines, antidotes and format recovery programs are effective to a point, but they are not without their drawbacks: 1. Format recovery systems cannot resurrect data on systems destroyed prior to their installation. A minimum of one up-to-date backup disk, created by an antidote program, is required. 2. If the antidotes' backed-up data is not current, the information it replaces will be out of date, an inaccuracy that leads to further data loss. Most times, when antidotes' backup data is obsolete, the restoration process fails completely; damaged disks remain unusable. 3. Format recovery programs cannot reconstruct data erased by low-level reformatting or erased by destructive high-level reformatting. Low-level formatting is employed by most hard disk controller manufacturers and can be activated by computer viruses (and by some DOS utilities); destructive high-level formatting occurs when users enter the FORMAT command using AT&T's or Compaq Computer's DOS and perhaps other OEM DOS versions. (Most DOS versions do not destructively format disks when the FORMAT command is used. Disk sectors are, instead, marked as "unused," but the data they contain remains intact until overwritten.) 4. If new data has been written to disks after they has been reformatted, deleted data cannot be reliably recovered. 5. 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 disks to a somewhat usable condition. 6. Infection antidotes can search for, find and remove only a small quantity of known viruses. In fact, most infection antidotes are designed to remove but a single computer virus strain. Other, uncataloged viruses remain active, undetectable and untouched. Rich Levin's CHECKUP (tm) Version 3.9 Page 18 7. Users of infection antidotes must constantly update those programs in order to remain reasonably current. Even then, antidote programs are almost always one step behind their viral counterparts. 8. The infection of normal program files with viral data is, in itself, severely corrupting. It is therefore likely that infection antidote programs, attempting to remove viral code, might cause further, irreparable damage. 9. Every executable program has its own special characteristics, its own internal file formatting. It is physically impossible for any infection antidote to remove all known viruses from all known program types--no ifs, ands or buts about it. Once again, it is safer and far more reliable to recover damaged disks or to eradicate infected files by restoring them from certified backup copies. There are no substitutes for regularly scheduled, conscientiously inventoried backups. File Comparison Utilities Virtually every copy of DOS arrives with at least one file comparison utility, using program names like COMP, DISKCOMP and FC. File comparison programs, be they provided with DOS or purchased independently, do one thing and do it well: they compare, letter for letter, byte for byte, two distinct copies of target file specifications. Because good file comparison utilities detect even subtle changes between files and because viruses must change files in order to infect them, anti-virus software vendors have jumped on the file-comparison bandwagon. It's easy to see why. File comparison utilities are simple to develop, a snap to document and can be brought quickly to the expanding anti-virus software market. What is the logic that lies behind the idea of using file comparison utilities as anti-virus programs? By comparing files in use against known good copies, viral infections can be identified. There are several problems, unfortunately, with this plain and simple technique: 1. The same level of protection is achieved using any file comparison utilities, including those provided with DOS at no extra charge. Rich Levin's CHECKUP (tm) Version 3.9 Page 19 2. A duplicate copy of every compared file must be stored on another disk or directory, a waste of costly disk space. 3. File comparison utilities, even when designed specifically as anti-virus programs, generally do not support features essential for the management of virus detection. Options like activity logs, alarms, data encryption, off-line storage, system locks, and both wildcard (* and ?) and subdirectory input file specifications are often lacking and are sorely missed. 4. Viruses can audit disk directories looking for file duplicates and infect both copies of target file specifications. Future file comparison checks would not detect differences between the two infected files. This is not as much of a problem, however, when the duplicated files are stored on different disks. 5. Most file comparison utilities designed specifically for virus detection prevent users from comparing anything more than system start-up files (IO.SYS, MSDOS.SYS and COMMAND.COM). All other files, including user data, remain unprotected. Virus Scanners Recently, a wave of programs that scan disks and files for known viral signatures has flooded the anti-virus software market. Even conservative IBM Corporation has gotten into the act, with its moderately effective, easily updated program called "The IBM Virus Scanning Program." Virus scanners, as already noted, search only for the specific viral signatures they've been programmed to detect. The shortcomings of conducting searches for fixed sets of program types should be obvious to everyone. Users, however, appear to be undeterred, as IBM's and similar virus scanning products continue to do well in the marketplace. Perhaps this is because searching for something we know--checking to see if there are any known viruses on your disks--makes sense to the average user. But in the nether-world of computer viruses, it's what we don't know that will hurt us. 1. Virus scanners can detect only a limited number and fixed set of known computer viruses. This means that new or modified viruses can be active, spreading and completely undetectable by out-of-date virus scanners in use. Rich Levin's CHECKUP (tm) Version 3.9 Page 20 2. Virus scanners require frequent, sometimes costly updates as new viruses are discovered or as old strains are updated. New viral signatures must be forever added to the virus scanners' search code. Users not using the latest virus scanner revisions are perilously out of date. 3. Most virus scanners are easily outwitted by modern computer viruses employing data encryption techniques to mask their viral signatures. Such viruses encode their tell-tale signs by either enciphering them or by mutating them. Because their viral signatures change with every new infection, nothing tangible remains for virus scanners to seek out and identify. Disk Mappers Disk mappers maintain centralized data files comprised of coded disk images ("disk maps"). These coded disk images contain snapshots of their target disk status' at any given point in time. With every run, disk mappers notify users of changes discovered between target disks and their coded disk images. Yet again, the anti-virus solution fails to provide an adequate defense against computer virus infections: 1. Disk mappers' output files can occupy huge amounts of disk space; they increase in direct proportion to the number of files and the size of disks being tracked. 2. Time consuming maintenance of disk mapper data files is generally required. As the condition of target disks change, entries must be sorted, updated, deleted or purged. 3. Disk mappers can be complex to operate because they must support many data-file maintenance options (like the sorting of the data base, the purging of obsolete entries and so on). 4. Disk mappers customarily update data files at system start-ups, increasing boot times. Rich Levin's CHECKUP (tm) Version 3.9 Page 21 5. Some disk mapping programs monitor all files, regardless of whether they're executable. While viruses can affect nonexecutable files, they cannot infect them. And since nonexecutable files (like .DOC and .TXT files) are always changing, (they're often created and maintained by users), disk mappers frequently cause false-alarms when changes in them are encountered. Better disk mapping schemes allow users to specify precisely what file names and types are to be monitored. 6. Viruses can detect, modify and delete disk mapper program and data files. 7. Some disk mapping programs convert files (including user data) to read-only status (meaning that the files cannot be readily updated or deleted), thereby assuring conflicts when users want to use their applications or perform general disk maintenance. Several disk mapping and other anti-virus schemes rely on memory-resident modules to intercept DOS commands in order to provide last-minute checks of programs about to run. That presents another different and unique set of problems. Memory-Resident Anti-Virus Programs Anti-virus programs employing TSR technology (an ad hoc attempt at multitasking under single-tasking DOS) typically monitor disk writes directed to specific files or provide last-minute checks of files about to run. Some also provide a degree of password protection while others monitor usage and the installation of new software and data files. The complications tendered by the use of anti-virus TSRs are, regrettably, numerous and severe: 1. Many computer configurations respond poorly to particular groupings of TSR programs--they crash, lockup or simply behave abnormally. Let's face it: TSR technology attempts to perform something that DOS was not designed to do--multitasking (run more than one program at a time). The methods used by TSR developers to coerce DOS to multitask remain unstandardized and notoriously troublesome. 2. Anti-virus TSRs often consume considerable portions of limited available RAM space. This means there is less memory space available for normal programs and data. Rich Levin's CHECKUP (tm) Version 3.9 Page 22 3. False alarms occur frequently, triggered by normal disk activity that is misinterpreted. 4. Unattended computer operations, such as e-mail transfers or file uploads and downloads, are subject to unanticipated, usually fatal interruptions when anti-virus TSRs activate. 5. Most anti-virus TSRs allow a only limited number of files to be monitored, leaving other files, user data included, totally unprotected. 6. System performance decreases as each BIOS- or DOS-driven task is intercepted for examination by anti-virus TSRs. Computer operations can, in rare cases, be slowed to a snail's pace, depending upon the number and type of active anti-virus TSR programs. 7. Viruses can directly manipulate disk controller hardware to bypass interception by anti-virus TSRs. 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 these reasons alone, anti-virus TSRs provide users with a false sense of security. In summary, while the criteria for the selection of a word processor, a spreadsheet program or an accounting application should be established in terms of the number of features available and their relative ease of use, there are a different set of priorities in play for the selection of anti-virus software. All the nifty, whiz-bang features in the world mean nothing if they do not add up to providing absolute, certain security. It's of the utmost importance to remember that viruses have complete control of PC system resources at the moment of infection. Anti-virus programs, even when renamed and stored in hidden subdirectories or stored on write-protected hard disks; even when they are hidden, read-only or embedded as vaccinated files; even if they are ruggedly reliable file comparison utilities, disk maps, TSR programs or device drivers, you name it--all share one fatal flaw: they are subject to the scrutiny of computer viruses when they examine their hosts. Anti-virus systems stored on nonremovable media, relying on support files stored on nonremovable media or residing in memory are themselves subject to infection! Rich Levin's CHECKUP (tm) Version 3.9 Page 23 HOW CHECKUP WORKS CHECKUP detects viral infections by comparing target file sizes, incremental and cumulative cyclic redundancy checks (CRCs) to previously recorded baseline values, optionally stored on removable media. CHECKUP examines files by first dissecting them into randomly sized blocks of data, using dynamic block size allocation techniques that allow files as small as one byte to be accurately checked. CHECKUP then scans and compares every byte of the target files on a block-by-block basis. If the recorded file sizes or any of the incremental or cumulative CRC comparisons do not match, CHECKUP alerts users that the target files have been modified. CHECKUP's incremental CRC system is superior to cumulative checksum totaling schemes. Future viruses may be able to calculate checksum totals prior to infections, pad their viral code with characters that maintain checksum integrity and then infect. Even more alarming is the fact that viruses can effortlessly exchange data bytes within data files--a potent form of data destruction that 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 reversed. Such changes in user data will pass checksum integrity checks, even though the data itself is corrupt. This kind of viral activity would defeat conventional checksum calculation programs, but not CHECKUP. It is impossible for a virus to maintain accurate intra-file (incremental) and cumulative CRCs. This is especially true relative to CHECKUP, where checked block sizes vary from one byte to near total file size, where the methods for calculating the CRCs are unknown (and are, in fact, dynamically appropriated) and where the CRC results are encrypted. To survive CHECKUP's scrutiny, viruses would need to know the block sizes, exact calculation entry points, CRC algorithms and the encryption keys used at initialization. The viruses would then have the difficult, if not impossible task of padding their viral code with dummy characters, since adjustments would have to occur every few hundred bytes or less. Even if viruses were able to achieve this high degree of adaptability, they would nevertheless be unable to operate in such internally scrambled conditions. Rich Levin's CHECKUP (tm) Version 3.9 Page 24 RUNNING CHECKUP CHECKUP's launch syntax is: [d:][path]CHECKUP [d:][path]filename[.ext] [d:][path] [/options] Where: * [d:][path] specifies the letter of the drive and the path that contain 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 process. * [d:][path] specifies the optional drive and path where you want CHECKUP's output files to be stored. * [/options] are one or more of CHECKUP's command-line actions (explained below). Notes: 1. If the first [d:][path] are not specified, the default drive and path are assumed. 2. 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. 3. The target file specification must be the first parameter on the CHECKUP command-line. 4. The global file name characters * and ? may be used to specify target files. 5. Output files are stored on the second [d:][path] specified. 6. If the output file drive and path are not specified, the drive and path of the input file specification are assumed. CHECKUP accepts all legal DOS path and file names. Running CHECKUP without any command-line parameters causes the correct invocation syntax and other helpful information to be displayed. Rich Levin's CHECKUP (tm) Version 3.9 Page 25 CHECKUP's Command-Line Options CHECKUP supports a variety of command-line options that allow you to tailor the program's actions to address specific application needs. CHECKUP's command-line options are provided as tools to aid in the control of CHECKUP's execution; CHECKUP does not require them in order to run. The switch character ("/") and the first two letters of the options selected must appear after the target file specification and after the optional output file specification on the CHECKUP command-line. Note that future releases of CHECKUP may implement changes to these options. Option Explanation ------------------------------------------------------- /? Display help screen Use this option to display help information when no other command-line options are entered. /BL[OCK]:#### Override auto-block sizes and use ####-byte blocks (1 - 9999) CHECKUP's default block sizes are automatically selected. Use this option to specify fixed data block sizes. Valid entries range from 1 to 9999 bytes. In general, the larger the selected block size, the faster CHECKUP processes the file. Testing shows that ideal block sizes range from 1024 to 2048 bytes; your testing may yield different results. The colon character (":") must appear before the specified block size value. For example, the commands /BL:1024 /BLOCK:1024 both specify a block size of 1024 bytes. This feature is available only in the registered version of CHECKUP. Rich Levin's CHECKUP (tm) Version 3.9 Page 26 /CH[ECKXUP] Allow checking of .X?? files CHECKUP normally does not explicitly check .XUP and related output files. Instead, changes to CHECKUP's output files, legitimate or otherwise, are always detected through the processing other target file specifications. Use this option to explicitly check CHECKUP's output files. See the section titled "CHECKUP'S .XUP FILES," below, for more information on CHECKUP's output files. /CO[LOR] Override auto-attributes and use color CHECKUP automatically detects the type of video adapter card installed (monochrome or color) and sets on-screen colors accordingly. Use this option if CHECKUP does not correctly detect your color video adapter card. /DE[BUG] Print verbose error messages Use this option to display extended error code data, in addition to CHECKUP's standard error messages. /DI[RECTORIES] Check subdirectories CHECKUP normally checks files in the specified [d:][path] directory only. Use this option to process files in subdirectories, beginning with the specified [d:][path] directory. Rich Levin's CHECKUP (tm) Version 3.9 Page 27 /EC[RC] Override CRCs and use enhanced CRCs CHECKUP automatically uses table-driven CRCs (cyclic redundancy checks) to detect changes in target files. Use this option to employ ECRCs, a proprietary superset of CRCs that provide better error checking but may take longer to run. This feature is available only in the registered version of CHECKUP. /ER[RORLOG] Log error messages to the printer Normally, CHECKUP does not send any information to the printer. All error messages are displayed on screen and are logged to the CHECKUP.LOG file. Use this option to send error messages to the printer in addition to both the screen and the CHECKUP.LOG file. See the section titled "THE CHECKUP.LOG FILE," below, for more information on the CHECKUP.LOG file. Rich Levin's CHECKUP (tm) Version 3.9 Page 28 /FA[ST] Override CRCs and use checksums CHECKUP automatically uses table-driven CRCs (cyclic redundancy checks) to detect changes in target files. Use this option to employ checksums. Checksums are often faster than CRCs and ECRCs, but they cannot detect adaptive checksum viruses and one potent type of data tampering. A small data /BL[OCK]: size (256 bytes or smaller) will cause CHECKUP's block check algorithm to detect adaptive checksum viruses with near 100% accuracy when /FA[ST] checking is used. Data tampering that uses byte swapping, however, might not be detected. See the section titled "HOW CHECKUP WORKS," above, for more information on block checks, block sizes, checksums, data tampering and byte swapping. This feature is available only in the registered version of CHECKUP. /HA[LT]:# Stop for # seconds after each file check (1 - 9) CHECKUP normally does not stop processing between files. Use this option to specify the amount of time CHECKUP should wait before proceeding to the next file in sequence. Valid entries range from 1 to 9 seconds. The colon character (":") must appear before the specified halt time value. For example, the commands /HA:1 /HALT:1 both specify a halt time of 1 second. Rich Levin's CHECKUP (tm) Version 3.9 Page 29 /HE[LP] Display help screen Use this option to display help information when no other command-line options are entered. /IN[FO] Display program information Use this option to display an informational message when no other command-line options are entered. /LI[MIT]:#### Set directory limit at #### directories (1 - 9999) CHECKUP's default directory limit is 99 directories. Use this option to manually set CHECKUP's directory limit. Valid entries range from 1 to 9999 directories. The colon character (":") must appear before the specified directory limit value. For example, the commands /LI:200 /LIMIT:200 both specify a directory limit of 200. This option has no effect unless the /DI[RECTORIES] option is used. /LO[CK] Lockup system when file modifications are detected CHECKUP normally does not lockup the system when file modifications are encountered. Use this option to secure the host system and to sound a continuous alarm when file modifications are detected. The host system must be rebooted in order to unlock it. Rich Levin's CHECKUP (tm) Version 3.9 Page 30 /LP[TLOG] Redirect CHECKUP.LOG file output to the printer Normally, CHECKUP does not send any information to the printer. All messages are displayed on screen and are logged to the CHECKUP.LOG file. Use this option to send the CHECKUP.LOG file output to the printer instead of to the log file output disk. See the section titled "THE CHECKUP.LOG FILE," below, for more information on the CHECKUP.LOG file. /MO[NO] Override auto-attributes and use monochrome CHECKUP automatically detects the type of video adapter card installed (monochrome or color) and sets on-screen colors accordingly. Use this option if CHECKUP does not correctly detect your monochrome, Hercules or Hercules-compatible video adapter card. /NE[WLOG] Erase old CHECKUP.LOG file Normally, CHECKUP appends new CHECKUP.LOG file data to old CHECKUP.LOG files. Use this option to delete the last CHECKUP.LOG file, if it exists, before CHECKUP adds any data to it. See the section titled "THE CHECKUP.LOG FILE," below, for more information on the CHECKUP.LOG file. Rich Levin's CHECKUP (tm) Version 3.9 Page 31 /PA[USE] Pause when file modifications are detected and before exiting CHECKUP normally does not pause processing when file modifications are detected or before exiting to DOS. Use this option to stop processing when file modifications are detected and before exiting to DOS. Pressing any key unpauses the host and resumes processing. /QU[IET] Suppress bells and whistles CHECKUP normally sounds beeps and alarms during normal processing. Use this option to suppress beeps, bells, buzzers, alarms and other noises. /RE[PLACE] Use replacement extension (.COM becomes .XOM) See the section titled "CHECKUP'S ALTERNATE OUTPUT FILE EXTENSIONS," below, for more information on this option. /SH[IFT] Use shifted extension (.COM becomes .XCO) See the section titled "CHECKUP'S ALTERNATE OUTPUT FILE EXTENSIONS," below, for more information on this option. Rich Levin's CHECKUP (tm) Version 3.9 Page 32 /ST[ACK]:##### Increase stack space by ##### bytes (1024 - 10240) CHECKUP's default stack space allocation is 3072 bytes. Use this option to increase CHECKUP's internal stack space by the number of bytes specified. Valid entries range from 1024 to 10240 bytes. THIS OPTION SHOULD NOT BE USED UNLESS "OUT OF STACK SPACE" ERRORS ARE ENCOUNTERED. The colon character (":") must appear before the specified stack allocation value. For example, the commands /ST:1024 /STACK:1024 both specify a stack size of 1024 bytes. /SU[PPRESSLOG] Suppress output of CHECKUP.LOG file CHECKUP normally maintains an output file named CHECKUP.LOG. Use this option to prevent CHECKUP from creating or updating the CHECKUP.LOG file. Suppressing the CHECKUP.LOG file will speed CHECKUP's operations. See the section titled "THE CHECKUP.LOG FILE," below, for more information on the CHECKUP.LOG file. Rich Levin's CHECKUP (tm) Version 3.9 Page 33 /WA[RNINGLOG] Log warning and error messages only CHECKUP normally maintains an output file named CHECKUP.LOG. Use this option to prevent CHECKUP from creating or updating the CHECKUP.LOG file, unless the update information consists of file modification or error-related data. Suppressing the output of non-warning-related data to the CHECKUP.LOG file will speed CHECKUP's operations. See the section titled "THE CHECKUP.LOG FILE," below, for more information on the CHECKUP.LOG file. CHECKUP's .XUP Files The first time a file is checked, CHECKUP creates an output file with the same file prefix and an .XUP extension, and stores the file in the target file's directory. These files, called ".XUP files" for short, are created once for every checked file. CHECKUP stores important control data in them. Access to the .XUP files are required during future file checks. To prevent viruses from gaining control of CHECKUP's files, use the clean floppy disk/batch file method described in the section titled "CREATING CLEAN CHECKUP FLOPPY DISKS," below. CHECKUP's Alternate Output File Extensions ".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 when checking different files with the same name. CHECKUP provides two command-line alternatives designed to resolve target filename conflicts. They are the /RE[PLACE] and the /SH[IFT] commands. Rich Levin's CHECKUP (tm) Version 3.9 Page 34 The /RE[PLACE] command The /RE[PLACE] command creates output files with "replacement" extensions. 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 would attempt to use OVERLAY.XUP--an incorrect data file as it contains output information gathered from OVERLAY.001. In this example, a nonfatal "Input/output file mismatch" error would occur if the /RE[PLACE] command was not used. The /SH[IFT] command The /SH[IFT] command creates output files with "shifted" extensions. CHECKUP replaces the first character of the input file extension with the letter X and then 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: OVERLAY.1 Input file OVERLAY.X1 Optional shifted extension OVERLAY.XUP Default CHECKUP output file OVERLAY.2 Input file OVERLAY.X2 Optional shifted extension OVERLAY.XUP Default CHECKUP output file Rich Levin's CHECKUP (tm) Version 3.9 Page 35 In this example, use of the /SH[IFT] command is preferable to the /RE[PLACE] command, as the /RE[PLACE] command does not resolve the following input/output file mismatches: OVERLAY.1 Input file OVERLAY.X Optional replacement extension OVERLAY.XUP Default CHECKUP output file OVERLAY.2 Input file OVERLAY.X Optional replacement extension OVERLAY.XUP Default CHECKUP output file When checking OVERLAY.2, CHECKUP would attempt to use either OVERLAY.XUP or OVERLAY.X (had the /RE[PLACE] command been used). Both are incorrect data files for checking OVERLAY.2, since they contain output information gathered from OVERLAY.1. In these examples, a nonfatal "Input/output file mismatch" error would occur if the /SH[IFT] command was not used. Use CHECKUP's alternate output file extension options whenever input/output file mismatch errors are encountered, when checking overlay files with numeric extensions or when checking different input files with the same name. Examples of CHECKUP Command-Line Usage 1. CHECKUP C:\*.* /DI /WA Check all files on C:\ Check all subdirectories below C:\ Log warning messages only 2. CHECKUP C:\*.* A:\ /DI /WA Check all files on C:\ Put .X?? output files on A:\ Check all subdirectories below C:\ Log warning messages only 3. CHECKUP C:\*.* C:\XUP /DI /WA Check all files on C:\ Put .X?? output files in C:\XUP Check all subdirectories below C:\ Log warning messages only Rich Levin's CHECKUP (tm) Version 3.9 Page 36 CHECKUP's Errorlevels 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] where [command] is any legal DOS instruction. This code demonstrates how a 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] where [command] is any legal DOS instruction. Lastly, this code excerpt shows how different commands can be executed for three different ERRORLEVELs: IF ERRORLEVEL 3 [command] IF ERRORLEVEL 2 [command] IF ERRORLEVEL 1 [command] where, again, [command] is any legal DOS instruction. 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. Rich Levin's CHECKUP (tm) Version 3.9 Page 37 The CHECKUP.LOG File CHECKUP maintains an ASCII text file named CHECKUP.LOG on the root directory of the logged disk. The CHECKUP.LOG file contains a detailed record of CHECKUP's activities and as such may prove invaluable in the event of a viral detection--it will be your only recorded history of viral exercises. You can view the CHECKUP.LOG file with any ASCII text editor and can delete it at any time. The CHECKUP.LOG file is provided as an informational tool only; CHECKUP does not require it in order to run. You can optionally SET a path to the CHECKUP log file directory. CHECKUP will store the CHECKUP.LOG file in the directory specified by either 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: SET LOG=C:\CANYA\DIGIT 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. Output of the CHECKUP.LOG file can be further controlled by using the /ER[RORLOG], /LP[TLOG], /SU[PPRESSLOG] and /WA[RNINGLOG] command-line options. See the section titled "CHECKUP'S COMMAND-LINE OPTIONS," above, for more information on controlling CHECKUP.LOG file output. Creating Clean CHECKUP Floppy Disks It is best to run CHECKUP through an AUTOEXEC.BAT file that resides on a certifiably "clean" floppy disk. This ensures that files are checked by a virgin 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. Many users successfully employ .XUP file renaming, archiving software and multiple directory storage tactics in their CHECKUP virus detection strategies. It is recommended, however, that users read this section to gain an understanding of the security benefits provided by use of the clean floppy disk/batch file method pioneered by CHECKUP. Rich Levin's CHECKUP (tm) Version 3.9 Page 38 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 the computer. Remove all floppy disks. Wait sixty seconds. 2. Insert a factory master copy of DOS into drive A:. Close the disk drive door, then turn the computer on. 3. Press ENTER in response to the computer's prompts for the current date and time (or enter the current date and time). 4. Insert a NEW, never used, unformatted floppy disk into drive B:. Close the disk drive door. 5. Enter the command: FORMAT B: /S The /S switch causes the FORMAT command to transfer the DOS system files to the disk in drive B:, making it "bootable." 6. After the floppy disk in drive B: has been formatted and the system files transferred, copy the XUP.BAT and CHECKUP.EXE files to the floppy disk in drive B:. 7. After the XUP.BAT and CHECKUP.EXE files have been copied to the floppy disk in drive B:, enter the following commands: B: REN XUP.BAT AUTOEXEC.BAT COPY CON CONFIG.SYS BUFFERS = 33 FILES = 25 8. Press F6, then press ENTER. Rich Levin's CHECKUP (tm) Version 3.9 Page 39 9. Remove the factory master DOS disk from drive A:. Replace it with the factory master disk of your favorite ASCII text editor. (An ASCII editor is any word processor capable of generating unformatted, nondocument text output. If you're uncertain of your word processor's ability to create pure ASCII text, use the EDLIN program provided on your factory master DOS diskettes instead.) 10. Run the ASCII editor and edit the AUTOEXEC.BAT file on drive B: to reflect the disks, paths and files you want CHECKUP to process. (For most users, the disk and path information provided in the sample XUP.BAT file will be sufficient.) 11. After you have finished editing the AUTOEXEC.BAT file on drive B:, remove the ASCII editor's factory master disk 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: empty). 12. Press and hold the Ctrl+Alt+Del keys to reboot the computer. CHECKUP will process the files specified in the AUTOEXEC.BAT file and store the .XUP files on the A: drive. Watch CHECKUP operate to insure files are processed according to the instructions you entered in the AUTOEXEC.BAT file. 13. 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. You may make a backup copy of the clean CHECKUP floppy disk at this time, provided the disk copy is created using the DISKCOPY command loaded from a write-protected, factory master copy of DOS. 14. Press and hold the Ctrl+Alt+Del keys to reboot the computer. Use the clean CHECKUP floppy disk to boot your computer whenever you check files again. Rich Levin's CHECKUP (tm) Version 3.9 Page 40 Remember that all viruses, no matter how sophisticated, share the same, simple weakness: they cannot infect programs or affect data unless they have access to them. By storing CHECKUP, the CHECKUP AUTOEXEC.BAT file and the .XUP files on clean, bootable floppy disks, and by using those clean disks *ONLY* to boot and run CHECKUP (and for *NO* other operations), you are isolating your CHECKUP system files and ensuring their reliable operation. CHECKUP's XUP.BAT/AUTOEXEC.BAT File An example of a suggested CHECKUP AUTOEXEC.BAT file for a single 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 resulting ERRORLEVELs and backup .XUP files as they are created. It is included in the CHECKUP archive file under the name of XUP.BAT and may be edited as necessary. Rich Levin's CHECKUP (tm) Version 3.9 Page 41 REM Rich Levin's XUP.BAT (tm) Version 3.9 REM Copyright (c) 1988-1990 Richard B. Levin REM All Rights Reserved REM REM This batch file demonstrates the preferred method REM for running CHECKUP. It maintains clean copies of REM CHECKUP, .XUP files and CHECKUP system files. REM Rename this file to AUTOEXEC.BAT and store it on a REM clean floppy disk. See CHECKUP.DOC for information REM on how to create a clean floppy disk. REM REM Set the system date and time: REM DATE TIME REM REM Make sure we're on the root directory of the target REM disk (substitute the disk drive letter of your REM choice): REM C: CD \ REM REM Check files and resulting ERRORLEVEL. The REM following commands cause CHECKUP to check every REM executable file on the target disk, to store the REM .XUP output files in the A:\XUP directory (since REM the root directory is limited in the number of REM files it can hold), to use a check block size of REM 1024 bytes (available on registered copies of REM CHECKUP) and to log only warning messages to the REM CHECKUP.LOG file. REM REM An ERRORLEVEL of 1 or higher indicates CHECKUP REM terminated abnormally. (CHECKUP supports four REM ERRORLEVELs; see CHECKUP.DOC for details.) In this REM example, system execution is halted by PAUSEing REM after a nonzero ERRORLEVEL is encountered. You REM may want to take different actions based on REM specific ERRORLEVELs. (Substitute your list of REM input files here): REM IF NOT EXIST A:\XUP\NUL MKDIR A:\XUP CHECKUP \*.COM A:\XUP /B:1024 /DI /NE /WA IF ERRORLEVEL 1 PAUSE CHECKUP \*.EXE A:\XUP /B:1024 /DI /WA IF ERRORLEVEL 1 PAUSE CHECKUP \*.SYS A:\XUP /B:1024 /DI /WA IF ERRORLEVEL 1 PAUSE REM REM End of CHECKUP.BAT Rich Levin's CHECKUP (tm) Version 3.9 Page 42 Executable files should be checked once daily, prior to being run, and before they are exported other systems. Static data, like program initialization files, should also be checked periodically. Checking dynamic data, like database and word processing files, usually results in CHECKUP detecting file modifications, since dynamic data is often user created and changed often. 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 the command line. Run-Time Messages and Explanations 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. The help screen was displayed. 4. Building directory list... CHECKUP was invoked with the /DI[RECTORIES] command-line option and is scanning the target disk, building an internal table of disk directory names to be checked. 5. Input filespec: CHECKUP is running and displaying the current status of its operations. The "Input filespec" message is displayed whenever CHECKUP is invoked using wildcard (* and ?) filespecs. Rich Levin's CHECKUP (tm) Version 3.9 Page 43 6. Input directory: Output directory: Checking input file: Against output file: CHECKUP is running and displaying the current status of its operations. * The "Input directory" is the name of the current [d:][path] being processed. * The "Output directory" is the name of the [d:][path] where CHECKUP's output files are being stored. * "Checking input file" is the name of the file being checked. * "Against output file" is the name of the output file used by CHECKUP to track changes in the current input file. 7. [ Esc ] Cancel [ Spc ] Pause [ <- ] Info CHECKUP is running and displaying the three input options available during its operations. * Pressing either the ESC key or the letter C key will cancel CHECKUP's operations and exit to DOS. * Pressing either the SPaCe bar or the letter P key will pause the program. * Pressing either the ENTER key (a/k/a RETURN, CR or NEWLINE on some terminals) or the letter I key will cause the INFO screen to be displayed. Rich Levin's CHECKUP (tm) Version 3.9 Page 44 8. Chkd: 0 Dirs: 0 Mod: 0 CHECKUP is running and displaying the current status of its operations. * "Chkd" is the number of files checked so far. * "Dirs" is the number of directories remaining to be checked. * "Mod" is the number of modified files CHECKUP has encountered. 9. Cancelled on demand Either the ESC or C key were pressed. CHECKUP discontinued file processing and returned to DOS. An ERRORLEVEL of 3 was set. 10. Press any key to continue Either the SPACE, P, CR or I key were pressed, or CHECKUP detected file size or data changes while the /PA[USE] command-line option was in effect. CHECKUP paused processing and displayed this message. 11. Checksums|CRCs|ECRCs calculated and logged CHECKUP processed the input file for the first time or updated an existing .XUP file to a new version. 12. File sizes are different The input file size changed since CHECKUP first processed it. An ERRORLEVEL of 1 was set. 13. Checksum|CRC|ECRC error on block # .... CHECKUP detected changes to the input file, beginning with the specified block number. An ERRORLEVEL of 1 was set. 14. Checksums|CRCs|ECRCs match The input file has not changed since CHECKUP last processed it. Rich Levin's CHECKUP (tm) Version 3.9 Page 45 15. CHECKUP ALERT CHECKUP detected file size or data changes. An ERRORLEVEL of 1 was set. 16. ... file(s) checked CHECKUP completed processing of one or more files. 17. System locked CHECKUP detected changes to an input file while the /LO[CK] command-line option was in effect. An ERRORLEVEL of 1 was set. Error Codes, Error Messages and Explanations The following error messages may be encountered when using CHECKUP. Explanations and suggested corrective actions are listed below. Please call for technical support if you encounter an error message that is not listed here or if you cannot resolve an error-related condition when using CHECKUP. Code ## Message ----------------------------------------------------------------- 00 Endless loop error See the explanation for error code # 256, below. 0 Unassigned error An unknown error occurred. Contact technical support. 0 Out of stack space More stack space was required than is available. Retry the operation after increasing CHECKUP's available stack space using the /ST[ACK]: command-line option. Rich Levin's CHECKUP (tm) Version 3.9 Page 46 7 Out of memory More memory was required than is available. Retry the operation after unloading TSRs (memory resident utilities like "SideKick") and device drivers, and after reducing the size of your DOS BUFFERS and FILES settings. Or, buy an expansion card to increase the amount of RAM. 14 Out of string space More string space was required than is available. Retry the operation after unloading TSRs (memory resident utilities like "SideKick") and device drivers, and after reducing the size of your DOS BUFFERS and FILES settings. Or, buy an expansion card to increase the amount of RAM. 24 Device timeout Indicates a hardware error (like an open disk drive door or a bad, nonexistent or incorrectly specified device, or an improperly connected device) or a hardware failure (such as a damaged disk or disk drive). Retry the operation after checking disks, disk drive doors, printers, switches, cables, connections and related hardware. 25 Device fault Indicates a hardware error (like an open disk drive door or a bad, nonexistent or incorrectly specified device, or an improperly connected device) or a hardware failure (such as a damaged disk or disk drive). Retry the operation after checking disks, disk drive doors, printers, switches, cables, connections and related hardware. Rich Levin's CHECKUP (tm) Version 3.9 Page 47 27 Out of paper The printer is out of paper or is not turned on. Retry the operation after checking the printer, the printer paper path, switches, cables, connections and related hardware. 51 Internal error A fatal error occurred. Contact technical support. 52 Bad file name or number A file name that does not conform to legal DOS file naming conventions was used. Retry the operation using a correct file name. 53 [filename] not found An input file specification does not exist. Retry the operation using a correct file specification. 57 Device I/O error An unrecoverable input or output error occurred while CHECKUP was using a device, such as a printer or a disk drive. Retry the operation. 61 Disk full There was not enough available storage space on the disk for CHECKUP to complete its operations. Retry the operation using another disk or delete some non-CHECKUP related files from the current disk. Rich Levin's CHECKUP (tm) Version 3.9 Page 48 64 Bad file name A file name that does not conform to legal DOS file naming conventions was used. Retry the operation using a correct file name. 67 Too many files CHECKUP was unable to process an input file. Retry the operation after increasing the number of files specified in your CONFIG.SYS FILES= parameter. If this error occurs while processing files in a disk's root directory or while storing CHECKUP's output files in a disk's root directory, delete some files from the target root directory. Disk root directories are limited in the number of files they can contain. 68 Device unavailable CHECKUP is attempting to access a device that is not on line or does not exist. Retry the operation after checking disks, disk drive doors, printers, switches, cables, connections and related hardware. 70 Permission denied An attempt was made to write to a write-protected disk or to access a locked file in a multiuser or networked environment. Retry the operation. 71 Disk not ready The disk drive is off or the disk drive door is open, or no disk is in the drive. Retry the operation after checking disks, disk drive doors, switches, cables, connections and related hardware. Rich Levin's CHECKUP (tm) Version 3.9 Page 49 72 Disk media error The disk drive hardware detected a physical flaw in the disk. Retry the operation. If the problem persists, try using a different disk or reformat the current disk. 75 Path/file access error CHECKUP was unable to make a correct connection between a path and a file name. Retry the operation using a valid path and file name. 76 Path not found CHECKUP was unable to find the specified path. Retry the operation using a valid path name. If you are using the LOG, TEMP or TMP environment variables to control the placement of the CHECKUP.LOG file, confirm that the path specified by the environment variable actually exists. See the section titled "THE CHECKUP.LOG FILE," above, for more information on the CHECKUP.LOG file. 253 Directory limit exceeded CHECKUP ran out of internal directory table storage space. Increase the capacity of CHECKUP's internal directory table by employing the /LI[MIT] command-line option. Rich Levin's CHECKUP (tm) Version 3.9 Page 50 254 Input/output file mismatch The input file was not the same as the one used to create the .XUP output file. Retry the operation using the correct input and output files. Try using either the /RE[PLACE] or /SH[IFT] command-line options to prevent most input/output file mismatches from occurring. 255 Input file contains 0 bytes The input file did not contain data. Retry the operation using a file that contains data. Retry the operation. 256 Loop error See the explanation for error code # 00, above. Conflicts with Other Anti-Rogue Programs Some versions of Flu_Shot+ and other anti-virus TSRs incorrectly flag CHECKUP as attempting to write to the input file being checked. Some releases of CHK4BOMB, an anti-bomb program, incorrectly identify CHECKUP as capable of reformatting 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. However, if you are concerned about the integrity of your copy of CHECKUP, 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. ADVANTAGES OF USING CHECKUP * CHECKUP is fast, taking only seconds to check most files. * CHECKUP is easy to use. There are no commands or switches to learn (they're optional), no maintenance modes, no extraordinary hardware requirements, no unusual installation procedures or other cumbersome features. Rich Levin's CHECKUP (tm) Version 3.9 Page 51 * 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- and MS-DOS-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 infections and alterations. * CHECKUP never writes to or modifies input files. * CHECKUP never writes to or modifies sensitive disk boot sectors nor does it tamper with disk partitions, file allocation tables or disk directories. * CHECKUP does not permanently reduce the amount of available RAM. * CHECKUP, when used as directed, does not reduce available disk space (although the optional CHECKUP.LOG file, if not deleted or off loaded, does consume some 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 office users alike. Rich Levin's CHECKUP (tm) Version 3.9 Page 52 * CHECKUP site licenses are affordable for small to medium sized businesses. * Nonprofit, not-for-profit, government and U.S. military agencies receive a 5% to 10% discount off the normal price of CHECKUP site licenses. * CHECKUP can be easily upgraded by mail or by 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 world-wide. A COLLECTION OF ANTI-TROJAN/ANTI-VIRUS TECHNIQUES No anti-virus system is foolproof, no anti-virus measures airtight. The trick is to create an obstacle course that any encroaching rogue software must deal with before it can breach the security of your systems. The more obstacles that are placed in the path of oncoming rogue software, the more likely it is that they will fail in their efforts to attack your data. It is with this thought in mind that this comprehensive collection of anti-rogue software management techniques are presented. By adopting the policies and procedures introduced below and by adding those of your own design, you can effectively fortify your systems without necessarily making everyday computing tasks harder, slower or more cumbersome. Implementation of any one of these anti-rogue measures will significantly increase your level of system security and decrease your chances of suffering a rogue software attack. Your contributions to this list are welcome. Boot From a Floppy Disk The importance of this particular anti-virus measure cannot be stressed enough. The irony of this procedure has not escaped us. For years, users wished for the ability to boot directly from their hard disks, instead of having to fish through diskettes for the current version of their valid boot disk. When hard disks became affordable, the once standard two floppy drive systems were pushed aside by the now minimum configuration of one floppy disk and one hard disk. Today, most users boot directly from their hard disks and rogue programmers know it. Rich Levin's CHECKUP (tm) Version 3.9 Page 53 The first log you can throw in the path of oncoming rogue programmers is to create and use bootable floppy disks. Bootable floppy disks guarantee your systems will always be operating under virgin DOS versions, including the kernel files (IO.SYS and MSDOS.SYS) and the shell program (COMMAND.COM). Provided the boot disks are write-protected (meaning the disk notches have been covered by tape or the write-protect tabs have been flipped to the "open" position), no computer viruses can infect or otherwise effect system boot files. Here's how you can create bootable floppy disks, in case you have never done so before: 1. Turn the computer off. Remove all floppy disks. Wait sixty seconds. 2. Insert a write-protected, factory master copy of DOS into the computer's A: drive. Turn the computer on. 3. Press ENTER in response to the computer's prompts for the current date and time (or enter the current date and time). 4. Type the command FORMAT A: /S and press ENTER. The computer will prompt you to enter a new disk into drive A:. 5. Remove the factory master copy of DOS from drive A: and store it in a safe place. Insert a new, never used, unformatted floppy disk into drive A:. 6. Press ENTER. The computer will convert the unformatted disk into a bootable floppy disk. When the bootable floppy disk has been created, you can continue to create more bootable floppy disks by entering the letter Y in response to the "Format another?" prompt. Rich Levin's CHECKUP (tm) Version 3.9 Page 54 7. When you have completed making bootable floppy disks, copy your AUTOEXEC.BAT and CONFIG.SYS files to the bootable floppy disks. If your CONFIG.SYS files contain DEVICE= statements, don't forget to copy the device drivers (files named in any DEVICE= statement) to the bootable floppy disks. If your AUTOEXEC.BAT files do not contain a SET COMSPEC statements, add one that sets the COMSPEC pointer to the location of your command processor. For most systems, the statement SET COMSPEC=C:\COMMAND.COM will be sufficient. Better yet, set the COMSPEC to point to drive A: (SET COMSPEC=A:\COMMAND.COM) and keep the write-protected, bootable floppy disk there. This trick insures that a clean, uninfectable copy of COMMAND.COM will be reloaded whenever the system requires access to the command processor. 8. Write-protect all of the bootable floppy disks you have created. Use the bootable floppy disks whenever you power-up your computer. Employ Virus Detection Software The only practical way to uncover computer virus infections is to use virus detection software stored off line. While the use of viral defense barriers will stop most viruses from stepping over the line and into your systems, it remains within the realm of possibility that a computer virus may somehow gain entry. Regular use of virus detection software, stored off line, is to computer security what regular checkups are to preventive dentistry: the earlier the bugs are detected, the better their damage can be minimized. When infected files are detected, users can simply delete them, in the process deleting the viruses lurking within them. Thus, instead of adopting a hysterical, "the sky is falling" attitude, users can calmly and confidently destroy the invaders immediately upon their arrival. Rich Levin's CHECKUP (tm) Version 3.9 Page 55 Use Pre-Run File Checkups Viruses can't replicate unless they can first load into memory and run. If a virus has invaded your systems, one way to put the brakes on replication is to check executable files before each and every run. This sounds like a lot of trouble, but it can be done fairly painlessly. The trick is to integrate file checks into DOS batch files or into system application menus. That way, if modifications of static application files are encountered, the batch files can exit without having loaded the suspect programs. This prevents virus-carrying files from providing viruses with an opportunity to load and replicate. At the same time, it flags the files as infected. Using the CHECKUP virus detection system, for example; instead of typing the "WORD" command to run Microsoft Word, use a batch file named "WRD.BAT" that reads as follows: @ECHO OFF ECHO OFF CLS REM Insert CHECKUP "Word" disk into drive A: PAUSE CD \WORD CHECKUP *.COM A:\ IF ERRORLEVEL 1 GOTO EXIT CHECKUP *.EXE A:\ IF ERRORLEVEL 1 GOTO EXIT WORD :EXIT Using this WRD.BAT file to invoke Microsoft Word permits CHECKUP to examine all of Microsoft Word's executable files. The programs will be allowed them to run if (and only if) they pass CHECKUP's scrutiny. Similar techniques should be employed when using other virus detection programs. While this approach does not provide the security of cold-boot system checkups (the computer is on and running when file checkups are engaged; thus, the entire process could be compromised by a resident virus), it is another weapon to keep in the virus fighter's arsenal. Likewise, it is far better to use this technique than to allow so-called vaccine programs to modify executable files to perform the same kind of checkups. Rich Levin's CHECKUP (tm) Version 3.9 Page 56 Change File Attributes Just as DOS files have file name, date and time stamps, they may also possess any combination of four attributes: "archive," "hidden," "read-only," and "system." Under OS/2 and other operating systems, even more file attributes are available. Files that have their archive bit set are those files which have been modified since the last time the system was backed up. Backup programs check files' archive bits when determining whether to back them up. Hidden files are those files not listed when a DIR command is entered. System files are the DOS kernels, IO.SYS and MSDOS.SYS. Read-only files cannot be written to, modified or deleted. A file can be changed to "read-only" status by simply turning on its read-only attribute. Poorly engineered viruses may not be able to alter read-only files. Well designed viruses can, however, simply turn off read-only attributes, infect, and then return the attributes to their original state. Changing file attributes is simply one of the many obstacles users can place in the path of rogue programmers. Sometimes it will work and sometimes it won't. Before changing file attributes, it should be noted that many programs write to their master executable files when saving configuration information. If such files have been converted to read-only, the read-only attribute must be turned off before reconfiguring 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.) Owners of the Norton Utilities can use Norton's FA.EXE to change file attributes. For example, to change all .COM files to read-only status using Norton's FA program, enter: FA *.COM /R+ /S FA *.EXE /R+ /S Later versions of DOS provide an ATTRIB or similar command. The following command uses DOS 4.01's ATTRIB command to render all .COM and .EXE files as read-only: ATTRIB +R *.COM /S ATTRIB +R *.EXE /S Rich Levin's CHECKUP (tm) Version 3.9 Page 57 Use Command-Processor Decoys An oft-overlooked feature of DOS is the SHELL command, available for use within CONFIG.SYS files. The SHELL command causes DOS to begin execution of a specified top-level command processor. If a SHELL command processor is not specified in CONFIG.SYS, DOS loads the default shell, COMMAND.COM. Experienced users can use the DOS "SHELL" command to rename and relocate COMMAND.COM to a directory other than its standard location, the root directory of boot disks. Users can then place a different copy of COMMAND.COM into the root directories. This may divert viruses into infecting the decoy copies instead of the actual command processors. The following steps are used to create decoy command processors: 1. Add the text SHELL = [d:][path]filename.ext /E:1024 /P as the last line of your CONFIG.SYS files, where [d:] is the letter of the disk drive, [path] is the subdirectory where the decoy command processors are stored and [filename.ext] is the name of the decoy files. For instance, if the decoy file was named FIZZFIZZ.EXE and stored in the C:\PLOP\PLOP directory, the correct SHELL command syntax would be SHELL = C:\PLOP\PLOP\FIZZFIZZ.EXE /E:1024 /P 2. Add the text SET COMSPEC = [d:][path]filename.ext to your AUTOEXEC.BAT files, where [d:][path]filename.ext equals the disk drive, path and filename specified in the SHELL command. Rich Levin's CHECKUP (tm) Version 3.9 Page 58 3. Using DOS' COPY command, rename and relocate COMMAND.COM to the name and location of the decoy file. The correct COPY command syntax for this operation is COPY \COMMAND.COM [d:][path]filename.ext where [d:][path]filename.ext equals the disk drive, path and filename specified in the SHELL command. In keeping with the above examples, this action would be performed by entering the command COPY \COMMAND.COM \PLOP\PLOP\FIZZFIZZ.EXE Once these steps have been taken, the affected systems would be running under a valid copy of COMMAND.COM, however renamed and relocated it may be. The original copy, still stored on the root directory, remains a tempting target for computer viruses, but it will never be accessed by end users--it has been disabled. In fact, users can go that one extra step and actually replace the old command processor with nothing more than a word processor .DOC file, renamed to read "COMMAND.COM." This virtually guarantees that the old command processor cannot be used. (Note that systems will "hang" if attempts are made to run decoy, nonexecutable COMMAND.COM files, since they are nothing more than dummy files.) Use Application File Decoys Did you know that .COM files can be renamed to .EXE files and .EXE files to .COM files, without any adverse effects? DOS doesn't care what the executable file extensions are; file types are processed at load time, using information stored inside them. This neat bit of information can throw a curve ball to computer viruses up at bat. You see, computer viruses must know the species of the files they are infecting, as every executable file type requires different infectious methods. COM files cannot be infected the same way .EXE files are and vice-versa. Users can safely reverse the executable file extensions of all their program files by entering the following commands in every directory containing executable code: REN *.COM *.KOM REN *.EXE *.COM REN *.KOM *.EXE Rich Levin's CHECKUP (tm) Version 3.9 Page 59 This reverses all executable file extensions and will confuse the bedazzles out of most computer virus programs. Of course, computer viruses are clearly capable of double checking their intended victims before infecting them, defeating this nifty little trick. But facts are facts: most, if not all computer viruses do not carefully check the nature of their intended targets--they use file extensions as their guide. Swapping executable file extensions will stop many a computer virus dead in its path. One note of warning: users should check each executable file by running them after their extensions have been swapped. Some programs may generate nonfatal error messages after they have been modified in this way. If that happens, simply return the program's file extension to its original name. Reinitialize the System A safe and sure-fire way to eliminate viruses lurking within disks' boot sectors is to reinitialize (remount) the operating system files. When the system is reinitialized, disk boot sectors are overwritten with fresh copies of the DOS kernel; hidden viruses are subsequently destroyed. Users should perform this task at least once a week because it's quick and easy to do, and because it's highly effective. Here's how to do it: 1. Turn the computer off. Remove all floppy disks. Wait sixty seconds. 2. Insert a write-protected, factory master copy of DOS into the computer's A: drive. Turn the computer on. 3. Press ENTER in response to the computer's prompts for the current date and time (or enter the current date and time). 4. Type the command SYS [d:] where [d:] equals the letter of the disk drive being reinitialized and press ENTER. After a moment, the message "System transferred" will be displayed. Rich Levin's CHECKUP (tm) Version 3.9 Page 60 5. Type the command COPY COMMAND.COM [d:] where [d:] equals the letter of the disk drive being reinitialized and press ENTER. After a moment, the message "1 file(s) copied" will be displayed. 6. Remove the factory master copy of DOS and put it in a safe place. That's all there is to it. The DOS kernel files are updated and secure. With regular use, system reinitialization prevents boot sector and command processor infectors from ever gaining a significant foothold in your systems. Reinstall Application Files Just as reinitializing low-level system files eliminates viruses lurking within them, so it is with the reinstallation of application files. As a precaution, users are well advised to periodically turn their computers off, reboot using write-protected, factory master copies of DOS and reinstall program files from write-protected master disks. When was the last time you reinstalled your word processor? Your DOS shell? Your spreadsheet program? When you purchased them, that's when. Since that time they've been sitting on your hard disks, unchanged (hopefully). Do yourself a favor: dig out the original master program disks, write-protect them if they're not already, power off your systems, reboot and reinstall. If any of your application files were infected prior to reinstalling them, they won't be afterwards! For archived (compressed) software, delete the files in use and reintroduce them by unarchiving them from their master archive files. Remember, it does no harm to freshen up your systems with new software installations and it certainly benefits those systems that may be harboring computer viruses. Reformat Hard Disks Many viruses secrete some or all of their viral code in disk sectors (storage areas) marked as "bad" or unusable. Computer operating systems will not read from or write to these bad disk sectors, so computer viruses hidden within them are well protected. In fact, most low-level DOS utilities do not even provide facilities for examining bad disk sectors. Rich Levin's CHECKUP (tm) Version 3.9 Page 61 Most users have never performed a low-level format of their hard disks, let alone a high-level format using the DOS FORMAT command. Only hard disk low-level formats are capable of scrubbing entire disk surfaces clean, removing all incorrectly labeled bad sectors and computer viruses in the process. Users should reformat their hard disks at least once every few months. Low-level disk reformatting is, unfortunately, not a task for the meek or inexperienced. Backups must be performed first, then the hard disk low-level reformatting program invoked, followed by use of DOS' FDISK program; finally, a high level format must be installed using the FORMAT command. While it would be nice to provide readers with a step-by-step guide to hard disk reformatting, there are no standard programs included with DOS that perform this task. Some hard disk controllers use the DEBUG program while others are delivered with proprietary software. In any case, low-level reformatting is best performed by experienced computer users. (The new generation of easy to use, nondestructive hard disk reformatters, like Gibson Research's SpinRite II, Gazelle's OPTune or OnTrack's DOSUTILS, will reformat hard disks, but they will not destroy viral code hidden in bad sectors.) Use Low-Level Disk Managers with Caution Programs that are capable of unerasing files, changing file attributes, sorting disk directories, viewing and editing disk sectors, and performing similar operations are called "low-level disk utilities." Of these programs, the best loved are the famous Norton Utilities (the original uneraser), published by Peter Norton Computing, Inc. Other well known disk utility collections are Bourbaki's 1DIR+, Central Point Software's PC-Tools, Fifth Generation System's Mace Utilities and the Xtree Company's XtreePro Gold. As with most other software genres, low-level disk managers have their fair share of public domain and shareware counterparts. When using software within this class, however, users are well advised to refrain from public domain and shareware solutions, staying instead with their commercial counterparts. This is because companies like Peter Norton Computing, Bourbaki, Central Point Software and Fifth Generation Systems spend many hours and thousands of dollars testing their programs on a variety of computing platforms. This insures they are safe and effective to use. In our experience, far too many PD and shareware clones of these popular low-level disk utilities were shoddily programmed, clearly untested and, sometimes, dangerous to use. Rich Levin's CHECKUP (tm) Version 3.9 Page 62 This is not to be read as an indictment of the PD and shareware disk utility software industry, but rather as a red flag raised in this specific software arena. All too often users run shareware disk unerasers or directory sorters, only to be confronted later with major cross-linking of files (which means their data is probably gone forever). Users are urged to use extreme caution when choosing and working with directory and FAT editors, directory sorters, disk optimizers, disk "snoopers," DOS shells, file movers, format recovery systems, partition-related tools, unerasers and other low-level DOS utilities. These programs manipulate critical data and one bug or errant keystroke can vaporize a disk. Observe Program Loading and Disk Access Times Observe the time it takes for programs to load. Infected files take longer because they carry the additional baggage of viral code and data. Plus, viruses typically conduct searches and new infections when infected files are loaded. These actions take time, thus, programs exhibiting longer than normal load times may be infected. Also, scrutinize disk accesses whenever possible. See how often and for how long your hard disk access light is on. 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 (input/output), especially during load time, may be infected. Log Available Disk Space Regularly check and log available disk space. Most aggressive viruses decrease storage space as they spread throughout a system. Every time they infect a new file, they add to its file size. This activity can be identified through rigorous monitoring. The following commands, added to AUTOEXEC.BAT, will track disk usage: CD \ DIR >> DIR.LOG TYPE DIR.LOG > PRN These commands cause a computer to log on to the root directory of the current disk and to append the output of a disk DIR command to a file called DIR.LOG. DIR.LOG is then printed on the printer. Make sure the printer is on when you boot up. Rich Levin's CHECKUP (tm) Version 3.9 Page 63 The last line of a disk directory usually contains the number of "bytes free" on the disk. By double checking the "bytes free" stored in the DIR.LOG file, users can follow the decrease in disk space as the system is used on a daily basis. Sudden decreases in the number of bytes free, without any obvious cause (such as the installation of a new software program) are a good indication of viral activity. Log Bad Sectors Regularly check and log the growth in bad sectors. Some viruses store their viral code or other needed data in good sectors marked as "bad." A sudden increase in the number or size of bad sectors is a good indication of viral activity, especially when more than one bad sector at a time appears. Like the logging of disk space usage, bad sector growth can also be identified through rigorous monitoring. The following commands, added to AUTOEXEC.BAT, will track the growth in bad sectors. Note that the CHKDSK program, provided with DOS, must be stored in the default directory or in a directory specified by the DOS PATH environment variable: CD \ CHKDSK >> CHKDSK.LOG TYPE CHKDSK.LOG > PRN These commands cause a computer to log on to the root directory of the current disk and to append the output of a CHKDSK command to a file called CHKDSK.LOG. CHKDSK.LOG is then printed on the printer. Make sure the printer is on when you boot up, otherwise, a "not ready" error will occur. CHKDSK typically outputs data in the following format. Your output may vary from this display, but the general layout should be the same. This CHKDSK reports shows that the subject disk has 4096 bytes in bad sectors: Rich Levin's CHECKUP (tm) Version 3.9 Page 64 Volume MOTHERBOARD created 12-15-1989 7:06p Volume Serial Number is 3414-1ACB 42661888 bytes total disk space 75776 bytes in 4 hidden files 55296 bytes in 22 directories 21037056 bytes in 683 user files 4096 bytes in bad sectors 21489664 bytes available on disk 2048 bytes in each allocation unit 20831 total allocation units on disk 10493 available allocation units on disk 655360 total bytes memory 188816 bytes free C:\BACKUP.LOG Contains 6 non-contiguous blocks C:\COMMAND.COM Contains 12 non-contiguous blocks C:\FRECOVER.BAK Contains 7 non-contiguous blocks C:\FRECOVER.DAT Contains 6 non-contiguous blocks C:\SD.INI Contains 2 non-contiguous blocks Realistically, the 4096 bytes in bad sectors should not change, although sometimes normal wear and tear on hard disks causes additional bad sectors to crop up. For the most part, though, bad sectors should not appear abruptly in great numbers. When they do, viral activity may be the cause. Shareware with Care Thousands of users now use their modems for more than just dialing the phone. People are telecommunicating via their computers 24 hours a day, all over the world. Every major metropolitan area in the USA now supports hundreds of BBSes, most of them free for the general computing public to use. Telecommunication has become so big that the world's leading electronic BBS, CompuServe, recently celebrated the addition of its 600,000th user to its member roster. BBSes offer files and conversation. Regardless of whether the services are free or not, the fact remains that the programs "uploaded" (sent into) BBSes may well be untested and of unknown origin. These same files are collected and catalogued by thousands of users and hundreds of user group libraries. The try-before-you-buy software marketplace, a marketing concept known as "shareware," has become so large and effective that many commercial shareware libraries have sprung up, offering disk collections, for a fee, of the same software titles found on local BBSes. Rich Levin's CHECKUP (tm) Version 3.9 Page 65 While major BBSes, like CompuServe, and major shareware distributors, like Nelson Ford's Public (software) Library (Houston, Texas), test software before making it available to users, BBSes and disk libraries do not, as a rule, test the software they offer. There are a number of simple schemes that function as protective measures for users while, at the same time, allowing them to enjoy the fruits of the shareware realm. Here they are. Tip #1 Do not, under any circumstances, run files downloaded from public access BBSes that do not validate users who upload. Faceless, nameless users are more likely to upload rogue programs than those users who can be tracked by law enforcement authorities. If the SysOp of a bulletin board did not contact you directly by phone, mail or automatic callback, you can be sure that other users have not been validated. Do not use software downloaded from that BBS. Tip #2 Do not run files downloaded from public access BBSes where the SysOps do not test and approve all files. Similarly, do not run files provided by shareware disk distributors, including your local users group, if the disk librarians do not test and approve all files. And always avoid at all costs the "Three disks for $3.00" type of operations; you can bet their proprietors haven't certified the disks. If the SysOp or disk librarian doesn't want to take the risk and check out their software, why should you? Feel free to ask SysOps and disk librarians if they evaluate or otherwise guarantee the programs stored in their libraries. Many have established formal policies for program evaluation and are happy to answer your questions regarding them. Tip #3 Examine executable files with binary file-viewing utilities like the ones included in 1DIR+, PC-Tools, XtreePro Gold and the Norton Commander. Look for suspicious comments and messages embedded in the code. Rogue programmers often place intimidating messages inside; comments like "Hey stupid! You just trashed your hard disk" or similar declarations. Programs found to contain such messages, profanity included, should be immediately discarded. Rich Levin's CHECKUP (tm) Version 3.9 Page 66 Tip #4 Download software from its source. The single most important and effective suggestion active shareware users can follow is this: get your shareware programs directly from the people who write them. Consider BBS downloads and shareware library diskettes more like advertisements than actual programs. If you like what the accompanying software documentation promises, look up the program author's name and phone number and arrange to get an evaluation copy. Most professional shareware authors run BBSes to support their products. By downloading shareware directly from their authors' BBSes, you are guaranteed complete, up to date and uncorrupted programs. Similarly, do not run programs unaccompanied by well written documentation or programs that do not include the name, address and telephone number of the author within the documentation. Programs delivered without documentation or contact information should be discarded. Even the most promising program is not worth the trouble if it ends up being nothing more than a cleverly disguised rogue. Tip #5 Use your head! Beware of suspicious files. A 128-byte .COM file that unarchives without documentation or contact information and whose description reads "Great Word Processor" is certainly suspect. Tip #6 Backup and write-protect hard disks. When testing new software for the first time, especially noncommercial software, it's wise to first backup the critical disk areas (like the boot sectors, partition and file allocation tables) and then install a hard disk write-protection utility. The FATSO program (available on many BBSes and through the Computer Virus Handbook's coupon offer) is capable of backing up and restoring critical disk areas; some other disk protection utilities may also support this ability. If rogue programs muck up critical disk areas, up to date backups can reliably restore systems to their original working condition. Note, however, that critical disk area backups must be performed immediately before running new software. Trying to restore bombed-out disks from backups more than a few minutes old will not reliably resurrect critical disk control data. Rich Levin's CHECKUP (tm) Version 3.9 Page 67 Shareware programs like BOMBSQUAD, DPROTECT, FLU_SHOT+, WPT (Write Protect Tab) or PROTECT (available on many BBSes and through the Computer Virus Handbook's coupon offer), can intercept and block software requests for conducting disk reads and writes. Blocking disk access is an effective way to stop most software bombs from detonating immediately upon loading. As TSRs, these programs may suffer from the drawbacks inherent in all memory-resident anti-virus programming, however, they provide adequate protection against poorly engineered bombs and viruses--fortunately, the most common kind. Tip #7 Beware of self-extracting archives. Self-extracting archives are executable programs that contain other programs in a compressed, executable format. When you run a self-extracting archive, it decompresses its contents and presents you with whatever program files and documentation the original archive contained. Self-extracting archives are also a classic delivery method used by bomb developers. It's quite easy to build a software bomb and call it a self-extracting archive. When users download and run the file, expecting to decompress its contents, they receive instead an exploded hard disk. The best defense against such trickery is, again, to employ hard disk write protection, to examine executable files before running them and to get programs directly from their authors. Don't Use Pirated Software Do not use hacked or pirated software. Software pirates, experts in breaking complex copy protection and data encryption schemes, have the skill and the tools needed to create bombs and viruses. In fact, some of the most celebrated cases of viral infections have been associated with software piracy. Also, some of the deadliest Trojans have been modified copies of well known applications. Don't be a cheapskate! Pay for the software you need and use. If the packages you need are simply too expensive for your budget, look to shareware work-alikes. They often cost far less and they perform just as well, sometimes better, than their commercial competitors. Buying software should be like any other purchase: what you can't afford to pay cash for, you certainly don't steal from the store. Be as honest as you think you are and protect yourself in the process--don't steal software. Rich Levin's CHECKUP (tm) Version 3.9 Page 68 Beware of Salesmen Bearing Gifts One overlooked segment of the computer virus time line is that of computer sales personnel, repair technicians, temporaries and rental PC users. Whenever a salesman demonstrates some hot new software program in your offices, whenever computers are sent out for repair or when a repair person visits your office, and whenever temporary help or rental PCs are brought in, the chances are good that infections can be contracted through the use of infected diagnostic software or other program types employed by the outside users. While you and your company are practicing safe computing and religiously applying virus detection software, you have no idea how well or how poorly protected the technicians bench at your local computer repair center is. Better PC managers will query prospective on-site and off-site repair centers as to their level of knowledge about computer viruses and as to what anti-virus measures they advocate and exercise internally. Personnel managers are well advised to restrict temporary help from bringing in either software from home or software provided by the temporary service agencies. Those salesmen, repair centers and temporary services who either poo-poo the computer virus problem or who respond with a puzzled "huh?" are best avoided. Backup! Backup your systems regularly! No systems exist in a vacuum, nor are any anti-virus or anti-Trojan techniques foolproof. Backup 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)! There are many fine, reliable programs available to speed throughput and ease the pain of backing up. Programs like Fifth Generation Systems' Fastback and Peter Norton's Backup are speedy, easy to use and reliable. And there's one backup program that every DOS user already owns: the BACKUP program provided with every copy of DOS. Contrary to popular belief, the latest version of MS-DOS' BACKUP program, v.4.01, is robust, quite good and essentially free. Do yourself and your systems a favor today: dig out your DOS manuals and read up on the BACKUP command. Then backup your hard disks and store the floppies or tapes away in a safe place. No matter what tragedies befall your systems--coffee spills, power surges, disk drives used as ash trays or rogue software attacks--data backups are the best lifesaver (and job saver) you'll ever have. Rich Levin's CHECKUP (tm) Version 3.9 Page 69 DIAGNOSING INFECTED COMPUTERS Imagine an unstoppable computer virus, designed to infiltrate systems regardless of what manner of anti-virus software and safe-computing methods are employed in their defense. Whenever virus watchers get together, talk inevitably turns to discussions of this much theorized, much rumored and much prophesied "killer virus"--the one that will get us all in the end. Much of the time, the virus narratives have some kinship to the "one that got away" yarns of avid fishermen. Somewhere out there, many experts believe, is the "big one." Many otherwise level-headed viral experts insist that such a virus is not only possible to create, but that one has either been created and is now in circulation or that one soon will be. To these prognosticators I respectfully say: "Prove it." I maintain that the creation of an omnipotent killer virus is an algorithmic impossibility. While robust viral code is certainly an attainable goal, it's simply too easy to isolate and otherwise defeat computer viruses, regardless of their design, by targeting their collective Achilles heel: the close examination of the parasites' host files. And there really isn't any reason to create killer viruses, anyway. Users continue to further the spread of easily created, low-technology viruses through continued ignorance of safe-computing practices. Rogue programmers need not spend the time necessary to create so-called killer viruses because the current crop of viral designs continues to do the job well. Regardless of whether your computers become infected by killer viruses or by the garden variety type, what do you do once infections take hold? How can you discern computer virus infections from end user errors, software bugs and hardware faults? What happens when religiously applied anti-virus and safe-computing measures fail? When memory-resident protection systems are bypassed, when less than perfect or improperly used virus detection systems are duped? There you are, alone, your data and perhaps your job on the line, with computer viruses dancing all over your hard disks. Personal computers are like a good pair of shoes; we use them everyday, sometimes all day, and we get to know them intimately. We become at one with the ebb and flow of certain operations, retaining the cognizance of oft used series of keystrokes in our fingertips, rather than our brains. We know just how fast it takes the disk drives to save certain files; we know when operations will drag and when they will zip along. Yes, it sounds ridiculous, but serious users are nodding in agreement--they know how it feels to have your heart in computing. Rich Levin's CHECKUP (tm) Version 3.9 Page 70 It's possible, though certainly not recommended, to identify computers infected with rogue code without resorting to the use of sophisticated anti-virus software. Like people who've come down with the flu, infected computers look sick and feel sick. Just as mothers can put their cheeks on their baby's forehead and know if their child is suffering with a fever, almost all computer users, regardless of their level of expertise, can "feel" when their computers are not running up to par. While computer systems protected by collections of well designed anti-virus software and by users employing safe-computing methods are safer than unprotected or poorly protected systems, all users still run the risk of computer virus infections. System managers and end users alike should learn to recognize the warning signs of viral infections. Systems exhibiting any of the following traits should be checked immediately by experienced viral diagnosticians, especially when more than one peculiarity is in evidence or when more than one computer is showing similar symptoms. If you are unable to locate a good viral consultant, please call us for advice (don't be shy; hundreds of users have been helped with their virus-related problems). Computer Virus Warning Signs 1. Computer operations seem sluggish. 2. Programs take longer than normal 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. The amount of available RAM suddenly or steadily decreases. DOS users can run the CHKDSK or MEM commands to monitor RAM usage. 8. Memory maps (like DOS 4.0's MEM command) reveal new TSR (memory resident) programs of unknown origin. 9. Normally well behaved programs function abnormally or crash without reason. Rich Levin's CHECKUP (tm) Version 3.9 Page 71 10. Programs encounter errors where they didn't before. 11. Programs generate undocumented messages. 12. Apparently benign, humorous "prank" programs mysteriously materialize and nobody admits to installing them. For instance, "black holes," bouncing balls, smiley faces, typos or "raining" alphabetic characters start to appear on screens. 13. Files mysteriously disappear. 14. Deleted file reappear. 15. Files are replaced with objects of unknown origin or are replaced with garbled data. 16. Names, extensions, dates, attributes or data changes on files or directories that have not been modified by users. 17. Data files or directories of unknown origin appear. 18. CHECKUP, or other virus detection systems, detect changes to static objects (files). Changes detected to dynamic objects (files that are expected to change regularly, like document and spreadsheet data files) are not necessarily indications of viral activities. What To Do When Your Systems Are Infected Swift action is called for when viral infections have been diagnosed and confirmed. The longer eradications are delayed, the larger the scope of infections can become; virus removal without loss of data can become impossible. Surprisingly, many users continue to compute under a foggy "business as usual" state of mind well after computer viruses have reared their ugly heads. Perhaps they are unaware of the severity of the problem or they think that the problem will go away in time. It won't. It is extremely important that users >STOP!> whatever it is they are doing immediately upon realizing that computer viruses are at work within their computers. That major spreadsheet you're working on won't amount to a hill of beans should computer viruses decide to fiddle with its data! Rich Levin's CHECKUP (tm) Version 3.9 Page 72 The following steps, performed immediately and in exact sequence upon detection of a virus, will usually cure systems from viral infections while maintaining the integrity of end user and system data: 1. Wash your hands and face. Wear rubber gloves if possible. Don a surgical mask. 2. Turn the computer off. Wait sixty seconds. 3. Remove all nonfixed storage media (floppy disks, removable disks cartridges, streaming tapes, etc.). 4. Disconnect all external, port-connected peripherals (print buffers, printers, spell-check devices hooked to keyboard cables, modems, etc.) except for the video monitor and the keyboard. 5. Write-protect all storage media. Standard 5.25" floppy disks can be write-protected by placing a tape tab over the square notch located at the upper right-hand corner of the disk. Standard 3.5" floppy disks can be write-protected by flipping the little plastic tab to the "up" position, thus exposing the hole in the upper right-hand corner of the disk. 6. Insert a write-protected, factory master copy of DOS into drive A:. Close the disk drive door, then turn the computer on. 7. Press ENTER in response to the computer's prompts for the current date and time (or enter the current date and time). 8. Log on to the disk being eradicated and delete all executable files in all directories. Those are the files featuring .COM, .EXE or .SYS extensions. Delete any other files you know to be executable (such as overlay files) from the infected disks. If any files are unable to be deleted, try to unprotect them by turning their read-only attribute to "off" using DOS' ATTRIB command. The following command turns the read-only attribute off on all files stored on the C: drive: ATTRIB -R C:\ /S Rich Levin's CHECKUP (tm) Version 3.9 Page 73 Users who don't have access to DOS' ATTRIB command can utilize Peter Norton's FA program or PC Magazine's ATTR program to modify read-only attributes. If, after turning files' read-only attributes off, the files cannot be deleted, users will have no choice but to completely reformat the infected disks. When this is the case, skip to step 20. Remember, encountering numerous "read-only" files is a possible indication of viral activity. 9. Turn off the computer. Wait sixty seconds. 10. Insert a write-protected, factory master copy of DOS into drive A:. Close the disk drive door, then turn the computer on. 11. Once again, press ENTER in response to the computer's prompts for the current date and time (or enter the current date and time). 12. Enter the following commands: SYS [d:] COPY COMMAND.COM [d:] where [d:] is the letter of the drive being eradicated. 13. After the DOS system files have been reinstalled via the SYS and COPY commands, manually reinstall all application programs, one by one, from their write-protected, factory master disks onto the disk being eradicated. 14. For an extra measure of security, reformat all external storage media (disks, tapes, etc.). Reinitialize (reset and clear) all external storage devices, like print spoolers, spell-check devices hooked to keyboard cables and so forth. (CAUTION: During the eradication process, do NOT insert disks containing IO.SYS, MSDOS.SYS, COMMAND.COM or any kernel-level or shell-level system files into the floppy drives unless they are write-protected, factory master copies. Destroy all storage media containing nonfactory master copies of DOS!) Rich Levin's CHECKUP (tm) Version 3.9 Page 74 15. After your application programs have been reinstalled onto the disk being eradicated, remove the write-protected, factory master copy of DOS from drive A:. 16. Turn the computer off. Wait sixty seconds, then turn the computer back on. 17. Backup the system onto new, never used storage media (floppy disks, streaming tapes, etc.) using whatever backup methods you prefer. Do not overwrite or append backup data to old backup disks or tapes. Incidentally, it's a good idea to maintain one backup of all executable program files and a separate backup of nonexecutable data files. 18. Replace all port-connected peripherals. 19. If the computer viruses reappear, you will have no choice but to reformat your floppy disks or low-level reformat your hard disks. Many hard disk controller low-level format routines are accessed through the DOS DEBUG program or through a program provided by the hard disk's manufacturer. If you don't know how to perform a low-level format on your hard disk, contact your computer dealer, consultant or hardware manufacturer for instructions, or call us for technical support. As these steps demonstrate, the key to nondestructive viral eradication is, essentially, to remove all executable files from the target disks and to replace them with known good copies. Technically, there's no need to remove and replace user data, since viruses cannot thrive in nonexecutable data files. Yes, viral data can be stored in user data files, but that data cannot be retrieved unless viruses can first load and run through infected executable files--the same files deleted during this eradication process. Thus, the act of "lifting off" all executable files and exchanging them with uninfected replacements effectively eliminates viral code. Even hearty boot sector infectors are utterly destroyed through these eradication steps, since the SYS command wipes the boot sectors clean as it updates them. Even more important, user data remains intact, avoiding massive re-keying of data, allowing a quick return to business as usual. Of course, data files damaged by viral activity will still require repair or replacement; however, when viruses are caught early in their infestation, such damage will be minimized. Rich Levin's CHECKUP (tm) Version 3.9 Page 75 Lastly, this key point should be evident and remembered by all users: when cleaning up virus-infested systems, use only write-protected, factory master program disks. Anything less than original factory master disks compromises the security of the eradication process. And finally, when in doubt, check it out--consult a viral expert for advice when all your efforts seem to fail. A GUIDE TO POPULAR VIRUS-RELATED TERMS The buzz words relating to the many faces of rogue software are often misused by both users and popular computer press alike. Worms are confused with viruses, the three types of software bombs are treated as one all-encompassing classification and so on. Hopefully, this guide to popular virus-related terms will help clear up this confusion. Antigen A program designed to remove one or more computer viruses from infected files. Anti-virus A program designed to prevent, detect or eradicate viral infections. Back door An undocumented, secret program feature known only to the program's designer. Bomb A program that unconditionally executes destructive instructions without user authorization. BSI Shorthand for "Boot Sector Infector." A virus that occupies the disk boot sectors (the kernel), among other areas. Bug A hardware or software error that causes a system or program to function incorrectly. Chameleon A program that emulates other programs. Often used to trick users into revealing passwords or other confidential information by emulating login procedures. Rich Levin's CHECKUP (tm) Version 3.9 Page 76 Checksum A fast error detection algorithm. Extremely accurate when combined with CHECKUP's dynamic block check algorithm. CPI Shorthand for "Command Processor Infector." A virus that occupies the system command processor (the shell), among other areas. CRC An error detection algorithm that provides, theoretically, 100% accuracy. Truly 100% accurate when combined with CHECKUP's dynamic block check algorithm. ECRC An proprietary CRC superset error detection algorithm supporting 100% accuracy and employed by CHECKUP. Disinfector See the definition of "Antigen," above. Eradicator See the definition of "Antigen," above. FSI Shorthand for "File-Specific Infector." A virus that searches for exact file names to infect. GPI Shorthand for "General Purpose Infector." A virus that can infect almost any executable files. Host See the definition of "Target," below. Hostess A yummy cupcake. Input file See the definition of "Target," below. Rich Levin's CHECKUP (tm) Version 3.9 Page 77 Logic bomb A program that conditionally executes destructive instructions 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 reformat the hard disk) if the social security number failed to appear in the records for three consecutive weeks. MPI Shorthand for "Multi-Purpose Infector." A virus that can simultaneously infect disk boot sectors (the kernel), command processors (the shell) and generic executable files. Rabbit See the definition of "Replicator," below. Replicator A program that creates--continuously and without end--independent, executable copies of itself. Rogue A program designed to deceive users or destroy user property without authorization. Target A computer or file that is subject to at least one category of rogue software. Rich Levin's CHECKUP (tm) Version 3.9 Page 78 Time bomb A program that conditionally executes destructive instructions 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 midnight). Trojan Horse A rogue program that pretends to be an ordinary program. Virus A program that modifies other programs to include an executable copy of itself. Virus detector A program designed to detect viral infections. Virus scanner A program designed to detect viral infections. Worm A program that consumes memory by traveling through it, much like a worm burrows through dirt or a program that travels through a network from computer to computer. CHECKUP'S RELEASE HISTORY Version -- Release date ----------------------- 1.0 April 01, 1988 2.0 December 18, 1988 3.0 April 12, 1989 3.9 April 29, 1990 Rich Levin's CHECKUP (tm) Version 3.9 Page 79 +---------------------------------+ | Give your files a CHECKUP! (tm) | +---------------------------------+ Rich Levin's CHECKUP (tm) Version 3.9 Page 80 This document was created using Microsoft WORD, version 5.0 Rich Levin's CHECKUP (tm) Version 3.9 Page 81 - End of CHECKUP.DOC - Rich Levin's CHECKUP (tm) Version 3.9 Page 82