Copyright (c) 1990 - 1995 All Rights Reserved to NetZ Computing Ltd., Israel User's Guide and Installation Instructions Warranty And Licensing Agreement InVircible and ResQdisk (Tm) 1990-1995 are trademarks and copyright with all rights reserved to NetZ Computing Ltd. (NCL), Israel. You, as the purchaser of license rights to the software, are herein referred to as the Licensee. The Licensee may not assign the license rights to the software without the prior agreement of NCL. The installation of this software package constitutes acceptance and full agreement to the terms and conditions of this warranty and licensing agreement, in so doing the Licensee agrees to be bound by said provisions. This is a legal agreement between the Licensee as the end user -- and NetZ Computing Ltd. who is the owner of all rights to the software. Usage of the InVircible software indicates acceptance of the terms and conditions. License: InVircible is licensed, it is not sold. The Licensee is obtaining limited rights to use the InVircible software. The Licensee is licensed to use InVircible on a single IBM-style personal computer. The distribution floppy of InVircible has provisions for licensing two installations to the hard disk. Only one installation to one hard disk is licensed with this disk package. The second installation is reserved for the Licensee as a backup. Site licenses are available for individuals or organizations with multiple installation requirements. Alteration or reverse-engineering of the programs is not authorized, such attempts terminate this license agreement and may result in unpredictable and irreversible damage. Limited Warranty/Limitation of Remedies: Defective diskettes will be replaced, at no charge, if they are returned freight pre-paid, within 30 days of the original purchase date. The sole remedy available to the Licensee will be limited to the replacement of defective diskettes as outlined, or a refund at the purchase price of this software program package. InVircible is provided "as is". The Licensee assumes all responsibility for the determination of the suitability of this software for Licensee's configuration and the results and performance of this software program package. NetZ Computing, the distributor, and their suppliers do not warrant, guarantee, or make any representations regarding the use of, or the results obtained with, the program in terms of correctness, accuracy, reliability, legality, or otherwise. In no event shall NetZ Computing Ltd., the distributor, nor anyone else involved in the creation, production, or delivery, of this product be held liable for any damages, loss of profit, consequential, or other damages, that may arise out of the Licensee's use or inability to use the InVircible programs. Some states do not allow excluding or limiting implied warranties or limiting liability for incidental or consequential damages, so the above limitation may not apply to the Licensee. This limited warranty and license agreement is governed by the laws of the State of Israel. Table Of Contents Preface Quick Start Instructions 1. Introduction 1.1 What are computer viruses? 1.2 InVircible's Main Features. 2. Getting Started. 2.1 Working from the InVircible Floppy. 2.2 Preparation of the Rescue Diskette. 3. Using the Main Menu (IVMENU). 3.1 IVMENU Special Keys. 3.2 The IVMENU Caution Panel. 3.3 The Last IVB, IVSCAN or IVX Report. 4. InVircible Installation . 4.1 Installation to Hard-disk. 4.2 Installation to LAN Server. 4.3 Installation Under OS/2. 4.4 Installation in the Sentry Mode. 5. Recommended Anti-Virus Strategy. 5.1 In the Single User Environment. 5.2 In a Network Environment. 5.3 In the Institutional Environment 5.4 In Unattended Installations (e.g. Bulletin Board Systems). 6. IVB - The file Protection & Restoration Program 6.1 The Extra-Security Feature. 6.2 Off-line Backup of the Database-Files-Tree. 7. IVX - The Correlation Scanner. 8. ResQdisk - The Boot-Area and CMOS Maintenance program. 8.1 Reconstruction of the Boot Block. 8.2 Regaining Access to an "Invalid Drive". 8.3 ResQdisk's Setup Utility. 9. IVSCAN - The Virus Detection and Removal Scanner 9.1 Removing Generic Boot Viruses from Floppies 10. A Primer to Generic and Special Methods. 10.1 Generic Method Selection 10.2 Generic Boot-Block Recovery 10.3 Fat Manipulators Removal 10.4 Inverse Piggy-Backing (IP). 10.5 The Virus Interrogation technique. 10.6 Forced Self Restoration. 10.7 Screening New Software. 11. Importing InVircible into Windows. 12. Virus Handling under OS/2. 13. Central Point Anti Virus Inoculation 14. The Antivirus TSR (Terminate and Stay Resident). 15. Procedures to Use if Virus Activity is Suspected. 16. Practicing InVircible, the AV Practice Lab (AVPL). Appendices Appendix A. - LAN Protection Appendix B. - Large Capacity IDE. Appendix C. - IVX advanced options. Preface This manual provides the essential information for the installation and use of InVircible. The InVircible software is user friendly, intuitive and will provide long-lasting virus protection. After installation InVircible functions unobtrusively without the need for ongoing user actions. The key component of InVircible is a rule-based Expert System that insures that most of virus attacks will be detected and removed from your IBM PC-class DOS system. For those situations where complex or compound virus attacks are detected, InVircible's utilities and this manual's guidelines provide for a user directed thoroughly complete restoration. In addition to background and program documentation, this manual provides guidelines for minimizing ongoing threats to the well-being of your PC's health. InVircible may be installed and used with assistance only from the on-line user help, so many InVircible users operate without the manual. A Quick Start section in this manual guides the user who prefers to install immediately and re view the manual in detail later. InVircible's basic features, the integrity checker, the correlation scanner, the virus scanner and the ResQdisk program are accessed via a menu using the IVMENU command. Command line execution is also available. Advanced features are integral components of the InVircible package; those advanced features are used rarely during day-to day operation in defense against simple virus attacks. Since most virus attacks are uncomplicated solo attacks of your system, InVircible's basic features will give you excellent ongoing protection. The advanced features are always available for simple or complex virus attacks and provide you with leading edge technology capabilities to eradicate even the most clever and troublesome viruses. InVircible provides a layered approach to protection from computer viruses. The first layer are the InVircible automatic detection and recovery features, embedded in IVINIT, which provides InVircible with extreme resistance to being bypassed or attacked by viruses. The second layer is the IVB integrity checker and restorer that secures your files, detects and eradicates new viruses (especially the "unrecoverable" viruses) and recovers the files that become infected with one or more viruses. The third layer are IVX and IVSCAN, the correlation and virus scanners for tracing down infected files and for the elimination of common or unknown viruses. In support of the above are: IVTEST, a module that checks computer memory for viral activity in real time, and ResQdisk, an advanced tool for inspecting and recovering the critical boot sectors and data of your hard disk. InVircible avoids common problems of other anti-virus software. InVircible programs recover themselves in case they become infected, even from stealthy viruses. InVircible does not allow a "fast infector" virus to "piggyback" its scanners and to infect an entire hard disk drive. InVircible utilize an efficient virus activity probe instead of memory resident (TSR - terminate and stay resident) component in its protection scheme. InVircible allows you to automatically recover from virus attacks; or you may prefer to manually guide the recovery. Quick Start Instructions Insert the InVircible diskette into the A: or B: floppy drive. Type A: or B: at the command prompt line. Type INSTALL/FAST to start the quick installation procedure. The InVircible INSTALL first examines your system for in- memory viral activity and infected hard disk drive boot areas and files. After these initial tests, InVircible then installs itself on your system to a default directory. If you prefer to install InVircible with parameters other than the default then use the plain INSTALL command. During the installation phase, all files on hard disk drive partitions will be scanned, then "secured" by IVB, the integrity checker. Although InVircible's functions are designed to be exceptionally fast, this initial scanning and securing of a large number of files may take a few minutes, so please be patient! Whenever a choice is provided, the default selection is the recommended choice. We encourage you to configure your system so that IVTEST, the real time viral activity checker, is activated when you invoke a frequently used batch (BAT) file (see Sections 4). NOTE: Preparation of a Rescue Diskette (Section 2) is critical for effective recovery from boot block and complex viral attacks. The preparation is needed before a virus infection may occur. Using InVircible Type IVMENU to access the user-friendly menu. Choose your selection by using the keyboard or a mouse. The Integrity Test option activates IVB, the integrity checker. Choose the Virus Scanner option to activate IVSCAN, the virus scanner. The F1 key provides access to the extensive, on-line, interactive hypertext manual. You may exit InVircible by pressing the F10 key, Alt+X, Alt+Q or clicking the mouse on the 'quit' field from the main panel. The escape key (Esc) returns you to the previous IVMENU panel. After IVB is selected, you choose the drive partition and directories to examine and whether to "validate", "secure", or "restore" files. When selecting IVSCAN, you choose the drive partition to scan, the directory (or directories) to examine, and whether to "scan" viruses or "remove" them also. For IVB and IVSCAN, it is usually best to utilize the default choice first, i.e., either "validating" or "scanning". These advisory modes notify you of suspicious activity. You may then make an informed decision regarding the appropriate action to take. Suggested Protection Routine IVINIT will check on any initialization of the computer that the boot block and operating system are intact. IVB will automatically run a daily check of all your executable files in all local partitions on the hard drive. IVB is the primary tool for monitoring the integrity of files and for their recovery in the event of a virus infection. IVB will report changes in executable files. Some changes in executable files are expected if you generate your own applications and program executable filenames are reused. IVB will normally prompt and suggest the renewal of the database file in a directory, in case the changes are a new version of a program. Yet, software developers will need to be aware when alterations are legitimate and when they are not. User generated executable should be secured immediately with IVB. When installing new software packages, scan the diskettes with IVSCAN before installation. After installation run IVB on all directories to secure any added executable file. Application programs such as DOS or Windows do not change normally unless they have been upgraded or purposely changed such as adding or deleting an entry to the SETVER table. A consistent change pattern reported by IVB indicates a viral infection. IVB provides this information both on screen and in a report file (IVB.RPT) placed in the partition root directory. Print this file to help assess the situation if you suspect virus activity. A report of only a single file having become modified requires you to proceed carefully ! Viruses rarely infect only one file, so an indication of a single modified file may not necessarily indicate the presence of a virus. When a genuine infection is found, try IVSCAN first, to discard the possibility of an infection by a common virus. Viruses unknown to IVSCAN may be removed using IVB, provided the programs were secured before becoming infected. New viruses, unknown to IVSCAN or where no securing signatures exist, can be found using IVX. The suspected files can have their extension name be renamed to a non- executable one and the files can then be replaced from backup. 1. Introduction 1.1. What are Computer Viruses? Computer viruses are sophisticated computer code written by imaginative programmers, having little respect to other's people work. Their motives are many, but the indisputable fact is that there exist already thousands of them, and several new ones are written daily! Viruses have to be purposely designed and written, they don't just appear from nowhere. However, to be a virus, there is one characteristic this program must have: It must replicate (or copy) itself so that it can spread. In order to assure its continuous spreading, the virus program must take control of the program's execution, either if it is a bootstrap program or an application file. Computer viruses are passed the same ways we obtain software; by copying from friends, from bulletin board systems, with newly purchased PCs and even in vacuum wrapped new software. 1.1.1 Categories of Computer Virus There has been much discussion regarding computer viruses and elaborate technical names are being used, such as stealthy, polymorphic, multipartite, spawning and self- encrypting. In reality, there are only two general virus categories: (1) Viruses that infect through the boot sector or partition table (MBS); (2) Viruses that infect through files; All encountered viruses fall into one of the above two categories or both. There are multipartite viruses that combine the properties of the two categories (boot and file). Such are the Junkie, Natas and Tequila viruses. A new variant of file viruses emerged in late 1991. It manipulates the file allocation table (FAT) in order to spread. We will call them FAT manipulators or cluster infectors. For the sake of reference, below is a quick definition of terms that are used to describe viruses and techniques employed by viruses: 1.1.2 File Viruses A file infector attacks executable program files, having a COM or EXE extension name. File infectors may corrupt non- executable files as well but they cannot spread this way, unless the affected file is renamed to an executable filename and executed. Many file viruses are memory resident (TSR). After an infected file is executed, they will remain resident in the computer's memory until the computer is turned off. While in memory they will continue to infect other programs and may interfere with normal operations. If the computer is turned off they will lie dormant until an infected file is executed and then load themselves back into memory again until the next time the computer is turned off. 1.1.3 Boot Viruses Boot viruses attack boot records and master boot records (MBR, sometimes referred as the partition sector). When the computer is turned on, it runs a couple of tiny program from the hard disk, first the partition bootstrap and then the boot loader, to ready itself for work. In case of a boot infection, one of these programs may simply be a virus. Boot viruses will remain active in memory while the computer is on. During this time they will infect write enabled floppies that the computer accesses. 1.1.3 Multipartite Viruses (boot and file infectors) Multipartite viruses infect both executable files and boot- partition sectors. When the computer is turned on the virus will be active and infect additional programs that are executed. Multipartite viruses are sometimes referred to as 'droppers', meaning that when an infected file is executed, it will drop its own boot program into the hard drive boot area. 1.1.4 FAT Manipulators (file infectors) The FAT manipulators are basically file infectors, with a unique infection mechanism. FAT manipulators are inherently stealth viruses because they hide the increase in file length, although the virus code is actually appended to the file. The way it is done is by inserting the extra clusters in the file's clusters chain in the FAT. Two well known such viruses are Dir-2 and 1963 (Necropolis). FAT manipulators are also excellent piggy-backers. 1.1.5 Techniques used by Computer Viruses. 1.1.5.1 Stealth Stealth viruses are so named because they actively seek to hide themselves to prevent detection. Stealth viruses that infect files will subtract their own size (in bytes) from the infected host file at any time that a directory (DIR) command is executed. The Whale virus is a good example of this. When it infects a file it adds 9216 bytes (and some mutations may reach even 16 Kb in length) to the file size (a copy of itself). If the DIR command is issued, it subtracts the virus length (9216 bytes) from the displayed host file length. Thus it effectively hides itself from the computer operator eye and from the operating system. Some boot viruses use stealth (spoofing) techniques too. Stealth boot viruses will deceit editing tools such as Norton's Disk Editor. Example of stealth boot viri are Monkey and Noint. Natas and Gingerbread Man are multipartite viruses that use boot spoofing too. 1.1.5.2 Encryption Most of modern viruses use encryption to evade detection by scanners. An encrypted virus has a very short common encryptor (from as few as 3 bytes, to a couple of dozen bytes) and the rest of the virus code is encrypted and differs from copy to copy of the virus. The detection of encrypted viruses cause high false alarm rates due to the ambiguity in the detection of the short common string. 1.1.5.3 Mutation Engine or Polymorphism Polymorphic viruses are a higher order of encrypted viruses. In addition to encryption, they use a "mutations generator" that scrambles the encryption too. A polymorphic virus mutates itself, so that each occurrence is totally different from the one before. This creates huge difficulties for anti- virus scanners, because they cannot look for a 'known' virus signature. Polymorphic viruses have rendered scanners effectively useless since they cannot be removed by an algorithmic approach. 1.1.5.4 Spawning (or Companion) Viruses. Companion viruses take advantage of the precedence DOS gives to COM over EXE files in the order of execution. If there are two files bearing the same name, one with a COM extension name and the other with an EXE extension, then DOS will execute the COM file first. A companion virus is basically a Trojan that "infects" EXE files by spawning itself into a companion COM file, bearing the same name as the EXE file. Sometimes the companion virus file will have its attribute set to 'hidden', to avoid its detection by the DIR command. 1.2 InVircible's Main Features * It handles both known and unknown computer viruses. * It is extremely fast, professional and easy to operate; * Does not require any costly updates; * Is self-sufficient and provides real time recovery from new or unknown viruses. Does not need outside assistance; * Has Extremely low false-alarm or 'false positives', with the highest probability of 'true positives' detection; * Uses a unique unobtrusive file protection and restoration scheme. * Has an automatically updating distributed database for restoration of files. * Has redundant and user-defined security features. * Uses a unique generic virus behavior probe and sampler. * Is not memory-resident and does not adversely affect computer performance. * Uses unique programs that automatically check themselves for, and restore themselves from virus infection. * Is friendly and uses a menu-driven user interface. * Features an interactive installation utility. * Is compatible with all major LANs (Local Area Networks). * Has an indispensable toolbox for computer security experts and advanced users. * Has generic procedures for full recovery from the Dir-2 and 1963 FAT and directory manipulators. * Utilizes sabotage-resistant protection designed to avoid both human- and virus-based deception. * Is piggybacking resistant to prevent InVircible from be coming a virus carrier. * Has extensive context-sensitive hypertext on-line help; and * Is financially affordable; 2. Getting Started 2.1 Working from the InVircible Floppy. InVircible is to be used from the hard disk drive. Yet, it can be used from the original distribution floppy. Boot the computer from either a DOS diskette or from the hard disk. Put the original diskette in one of the floppy drives and run IVMENU from the InVircible diskette. For reading the on- line hypertext manual either run IVHELP or use the F1 key when in IVMENU. 2.2 Preparation of the Rescue Diskette. The Rescue Diskette is a bootable floppy, containing the necessary InVircible programs, the hard-disk's boot-areas image files, the data stored in the CMOS, a copy of your AUTOEXEC.BAT and CONFIG.SYS and some useful DOS files such as FDISK, SYS, and UNFORMAT. It enables to recover the boot areas of a given hard-disk, the CMOS settings, as well as the recovery of files in case of infection. The Rescue Diskette is fully operable only on a computer that has the license installed on the hard disk. Install InVircible normally to the hard disk and reboot the computer to make the installation effective. Insert a formatted diskette into drive A and run INSTALL/R. First, the system and InVircible files will be transferred to the diskette, to make it bootable. Then, the boot areas of your hard-drive will be backed-up to the diskette. Write-protect the diskette. Partitioning device drivers (e.g. SpeedStor), disk- compression (Stacker, SuperStor, DoubleSpace), password drivers etc., required to recognize partitions or drives at booting time, should be installed onto the Rescue Diskette. DoubleSpace, Stacker and Ontrack's Disk Manager are all taken care of by InVircible. In other cases, copy the driver to the rescue-disk and edit its CONFIG.SYS file by an ASCII editor. It should contain an appropriate DEVICE line for each driver to be loaded at booting time. There is no point in preparing a Rescue Diskette for a computer without a hard disk. The Rescue Diskette is individual to the specific hard-disk for which it was prepared. Rescue Diskettes should never be swapped between computers. 3. Using the Main Menu (IVMENU). IVMENU may be started in different modes by using the command line options. By default IVMENU will start in the Integrity Check mode, on the current drive. IVMENU's command line syntax is: IVMENU [/switch] [drive:] Switches: /V to start in the Virus Scan mode, /R to start the ResQdisk boot block maintenance utility. The "drive" option will home IVMENU to a different than the current drive at startup. The switches and the drive option may be used in combination in any order. There are several ways to change options and modes with IVMENU, just use the keyboard or the mouse anyway you like. Any "sensible" action will respond accordingly. 3.1 IVMENU Special Keys. Alt + key combinations: the Alt key combined with either I, H, R or V will switch to the Integrity Check, Hyper- Correlator, ResQdisk or Virus Scanner respectively. Ctrl + key combination: the Ctrl key, when combined with a character from A to Z will change the current drive to the one selected, if available. Alt + G shortcut control: the shortcut hot-key is labeled "Go" when a mouse is found or "Alt + G" when the mouse is inactive. The shortcut control may be used to proceed with the selected mode without further selections. Press Alt+G or click the mouse on the green "traffic light" at the top center of IVMENU's display. 3.2 The IVMENU Caution Panel. The CAUTION PANEL is at the right-hand side of IVMENU's main screen. It displays various parameters on InVircible settings as well as selected warnings, related to possible virus problems. The first two entries are dedicated to memory stealing alert. In case DOS reports less than the expected memory, a message indicating the number of missing kilobytes will pop up. The message will prompt for confirmation to set the alert threshold to the difference detected. Once set, IVMENU and the InVircible programs will ignore missing memory, if equal to the set threshold. The threshold is reset automatically to zero when IVMENU detects more DOS memory than the current threshold setting. A Low memory message will be displayed in case missing memory is detected and the user didn't confirm the setting of the threshold. There are instances when less than 640 Kbytes of DOS base memory is normal, such as with certain settings of the setup or in certain compatibles, especially when booted from a diskette (Acer, some Dell models, HP etc.). The third entry is the current database file name. This filename may be changed through IVMENU by selecting Rename from the Integrity Check menu. IVMENU will prompt for a name, or ask to press Enter to reset to the IVB.NTZ default filename. See also for "extra security" in the IVB topic. The fourth entry indicates the available space in bytes on the target drive. In case the available space on disk decreases, a Disk space lost! message will come up, indicating the number of bytes "lost". In case lost space is reported, one should be aware of the possibility of virus piggybacking. IVB or IVSCAN will stop the scanning process in case piggybacking is detected. The fifth entry indicates the frequency of the full disk Integrity Check. If InVircible was properly installed, it should be either DAILY or WEEKLY. If not, re-INSTALL InVircible as detailed elsewhere. The last entry checks for the license status and will indicate "licensed" or "detection only". The empty field at the bottom is reserved for warning messages. 3.3 The Last IVB, IVSCAN or IVX Report. The last report generated by either IVB, IVSCAN or IVX can be viewed on screen through IVMENU. Select the Last Report in the Integrity Check or Virus Scan mode. The IVX report can be viewed in either modes by pressing the X key and then Enter. The report files are written to the target's root directory and named IVSCAN.RPT, IVB.RPT or IVX.RPT. The report file can redirected to the printer by DOS command, either PRINT filename or TYPE filename > PRN. 4. InVircible Installation 4.1 Installation to Hard-disk. Insert the InVircible diskette in drive A or B. Log-in to that drive. Run INSTALL to begin the installation. The INSTALL program will prompt for the directory to install to. Type the full pathname of the preferred location or just press Enter for the default, when prompted. The Utilities sub-menu, has the following options: a. The Batches sub-menu. Enables the insertion/removal of the IVTEST command to/from batch files in specified directories. The installation of the IVTEST probe in batch files is optional. IVTEST will be installed in its "quiet" mode. IVTEST messages will be displayed only if suspect activity is detected. b. The Rescue-Disk sub-menu, for the preparation of the diskette. c. The On-line Registration sub-menu. Enables the on-line licensing of InVircible by telephone. Call your local dealer for more details. d. The Key Installation/Removal sub-menu. Enables either the installation or removal of the InVircible license to/from the hard drive. The process is reversible. 4.2 Installation To or From LAN Server. InVircible is a universal anti-virus, recommended for both single user PCs as well as for all popular LAN brands. INSTALL enables the installation of InVircible to a file server or to a workstation in a network. The default is installation to a single user PC's hard disk. Select where to install InVircible (singe user PC - the default -, to a file server, or to a workstation in a network) from the Install sub-menu. Note that the installation (or removal) of the license to the hard disk can be done from the original diskette only. InVircible may be installed to any chosen directory on the server. The contents of the server should be secured by the LAN manager. All stations connected to the network and equipped with a hard-drive need individual licensing. The file server does not need the installation of the registration key. Any workstation in the network having a hard disk may be infected prior to logging-in to the network. Therefore, any such station needs its own InVircible installation. For LAN administrators: It is possible to install InVircible to all workstations, from the server. The IVLOGIN utility is provided with the distribution floppy. IVLOGIN checks if there is a hard disk and whether IV is installed on it. In case it is not, IV will be installed automatically with its default parameters. Add the IVLOGIN command in the LOGIN script, with the full pathname where the IVLOGIN.EXE file is located. IVLOGIN must be in the same directory as the IV files. 4.3 Installation Under OS/2. The InVircible INSTALL procedure must be run from a plain DOS environment. If INSTALL is attempted from OS/2, a warning message will request the user to boot from DOS and try again. 4.4 Installation in the Sentry Mode. There are instances when only the detection and alerting functions of InVircible's are needed. To install InVircible in the sentry mode (detection only), just skip the key transfer step in the installation procedure by running INSTALL/FAST or by leaving the write protect of the InVircible diskette in the protect position. The retraction of the license from the hard disk back to the diskette will also switch InVircible to the sentry mode. The sentry mode is indicated by the "Detection only" label instead of "Licensed", in IVMENU's Caution Panel and in the upper left corner of the program's panel. 5. Recommended Anti-Virus Strategy 5.1 In the Single User Environment. Install InVircible to the hard drive, as instructed above. The INSTALL utility will edit the AUTOEXEC file, after prompting for permission, and add the necessary commands for automatic tests to be run on the computer initialization. None of the InVircible programs will load itself and stay resident in memory. Once it completed its function, it will unload and leave the maximum of available memory to the applications. From now on, InVircible will detect and correct the most severe problems right at initialization. These include partition or boot sector tampering and certain operating system changes. Boot viruses such as Michelangelo, Stoned and Monkey will simply be purged from the disk immediately at startup. It some cases, InVircible may just alert, without correcting, on the presence of a suspected activity in the computer. Such alert is accompanied by a message describing the generic nature of the problem and the recommended corrective action. On first booting at any given-date, IVB will scan through all the hard disk local partitions. On successive initializations on the same date, only the root directory will be scanned. Added programs will be automatically secured on the daily scan. If weekly scans are preferred, change the DAILY argument to WEEKLY, in the AUTOEXEC file. Read Only drives (CD ROM): CD drives cannot (and need not) be secured. The INSTALL utility will normally detect ROM drives and disable their daily check. In case it hasn't, just add a space and a dash at the end of the daily command. For example, if D: is a CD drive, modify the command as follows: IVB C: DAILY - Make frequent data backups. Data should be backed-up at reasonable intervals. Programs should be backed-up only once or kept preferably on the original distribution disks. It is highly recommended to regularly run a FAT backup program, such as MIRROR from DOS 5 or IMAGE from Norton Utilities, from the last line of the AUTOEXEC. The InVircible system uses a unique virus-activity probe and sampler, called IVTEST. Since the reliability of memory-resident activity monitors is limited only to known viruses, and some of them are obtrusive or risky, there is need to verify from time to time, that a viral process is not spreading in the system. This is achieved by the automatic running of IVTEST, from frequently used BATCH files. The INSTALL utility will add the appropriate command into specified directories. 5.2 In a Network Environment. Any workstation equipped with a hard disk, should have its own InVircible installation. The InVircible distribution diskette for LAN installations has multiple license keys, according to the number of licensed users. The license key should be installed only to local hard disks, in workstations equipped with. It is recommended that the LAN manager run a daily IVB inspection of selected directories of the server. This can be done by adding command lines in the network schedule file or script. IVB returns an errorlevel exit-code. Errorlevel 0 means no findings, and anything else may indicate virus activity. Test for errorlevel 1 in batch or script files for suspect activity alerting. It is normal to find modified files in users directories, especially if they develop software. On the other hand, modified files with a consistent change pattern should alert on the possibility of a virus in the system. IVB will assess whether the changes may be a new version of a former program. IVB will then prompt if to renew the database file for that specific directory. 5.3 In the Institutional Environment Most institutional installations involve combinations of single users and network users, requiring an anti-virus plan that is a combination of the preceding strategies. Many large institutions also have an anti-virus policy requiring that virus related problems be dealt with only by qualified personnel. In this situation the InVircible license key is not installed or is removed from systems not authorized to deal with virus removal. Systems running IV in the sentry mode are still protected, but recovery of these systems from virus attacks is performed only by qualified personnel with access to an InVircible licensed floppy. Especially useful in an institutional environment are IVX and ResQdisk (see Sections 8 and 9). These utilities provide indispensable help to the institute's computer security experts for the recovery of "lost" hard drives and for tracking down sources of infection, especially of new vi ruses. 5.4 In Unattended Installations (e.g. Bulletin Board Systems - BBS). There are instances when the operation of a PC is unattended, such as in bulletin board systems etc. The daily inspection of IVB may in such cases pause the system, if the system was rebooted and IVB found changes in programs, when compared to their store signatures. To bypass the pause use the /nostop switch on IVB's command line in the AUTOEXEC, as follows: IVB C: DAILY /NOSTOP 6. IVB - The File Protection & Restoration Program. IVB will secure, authenticate and restore executable programs from virus infection and virus-like modifications, except for FAT/directory manipulators (see Section 10). IVB takes a 66 byte "snapshot" (signature) of critical information from each executable file and stores this information in each directory's InVircible database. This process is called "securing". The information is then used during "authentication" (also called "validation") to determine whether a file is modified by a virus. The database is also used to "restore" files that have been modified by viruses. Viruses are characterized by unique properties: They replicate into other programs, they modify the host program and they normally affect more than one program. All these anomalies are unmistakably detected by IVB. Common viruses will usually increase the size of a file, while Trojan-Horses typically decrease the size of a file by overwriting it. If IVB detects that more than one file is "modified" or "changed in size", then virus activity is indicated. A single modified file, or an inconsistent change pattern, may be a new version of an existing program. IVB will usually detect a version change and suggest to resecure the directory. IVB restores programs that have been secured. Prior to restoring files with IVB, scan first with IVSCAN to assure that the virus is not of a known type. Recovery with IVSCAN should be tried first, before restoring with IVB. The IVB command-line syntax is: IVB [-] [drive:\directory] [/option] The default drive and directory are the current ones. The various options are: none for authentication (the default), /S for secure, /R for restore, /D for delete and /V for the removal of the database files. Let IVMENU guide you through the options. The Delete option will erase files that have been decreased in size (potential Trojans) or files that cannot be restored safely. The [-] switch (space followed by a hyphen) indicates to IVB to operate on the specified directory only without continuing to any other directory or sub-directory. IVB will automatically secure added files when run in the default mode. The secure mode is to be used in case IVB indicates a modified file, which is a replacement rather than a modified one. Use the single directory switch to resecure a single directory by selecting it through IVMENU. IVB is tamper-resistant and will replace the database file of a particular file, if tampered with. IVB secures executable files (COM, EXE, SYS) only. Before attempting the recovery of a file by IVB you will be prompted with three options: Restore, Skip or All (restore all). 6.1 The IVB Extra-Security Feature. IVB has an extra security feature which allows the user to define the name of the database files. The default name is IVB.NTZ. This will prevent the destruction or modification of the IVB database files by a dedicated virus. It allows the user to define a unique database file name, other than the default. To set a different name to the database files use the Rename option from IVMENU's default. The database filename in use is indicated in the Caution Panel of IVMENU. 6.2 Off-line Backup of the InVircible Database. There are instances when an off-line backup of the database- files tree is desirable. Making such a backup is easy using the Off-line Backup option. Use IVMENU to produce an exact replica of the database file's tree on a previously formatted diskette in either floppy drive A: or B:. If necessary, the database files may be restored to their original locations by the Restore option of the Off-line Backup mode from IVMENU. A typical 200 Mbytes disk partition will require about 200 Kilobytes of space for an off-line InVircible backup. Attention LAN managers: An off-line backup for a typical 1 Gbytes file server can be contained on a single 1.44 Mbytes diskette. 7. IVX - The Correlation Scanner. IVX is a generic correlator, based on the comparison of files to a sample known to be infected. This way, IVX detects all the files that were infected by the same virus and can even trace down the source of the infection. IVX is ideal for isolating new viruses, or disinfecting a machine with no previous installation of InVircible on it. InVircible generates its own samples through IVINIT and IVTEST, either or both Virusample and Vir-Code. A file designated by IVB as changed, may also be used as a valid sample. IVX runs from either the command line or from IVMENU. The command line syntax is: IVX [pathname of sample file] [drive:\directory to search] Wildcards (*.?) are allowed in the sample's pathname. The IVX report is displayed in a graphic format, after the correlator completes its scan. You may also want to review the IVX report through IVMENU. Suspected files may be renamed through IVX to non executable extension names: COM to IVC and EXE to IVE. IVX will prompt before actually renaming a file. The renamed files may be safely copied to a floppy and sent or e-mailed to us for further analysis and evaluation. The detection threshold of IVX can be adjusted in a range from 1%, for highly polymorphic viruses, to 100%. The default is set to 20% of correlation. Tips for using IVX. The correlator is a powerful tool in the hands of a trained user and its findings are usually conclusive from the very first run. Yet, you should be aware that virus writers make great efforts to conceal their virus' presence. Therefore, do not expect a perfect match, but rarely, when using IVX with real viruses. The results of IVX should be regarded as relative, i.e. the files with the higher correlation are the more likely to be infected. Plain viruses may exhibit anything from 40% to 100% correlation to the sample, while highly polymorphic viruses may have as low as 4%. The conclusive evidence is that non-infected files are in even lower correlation with the sample. Before launching IVX, spot a few infected files that could be used as samples. The easiest is to look for them in the DOS directory. Frequently used files are usually the first victims of an infection. Boot from a clean DOS floppy and run IVX from a write protected or IV Armored floppy. When dealing with a virus that infects both COM and EXE files, prefer an infected EXE file as the sample, as it contains more relevant information than infected COM. The results will be more conclusive than with a COM sample. Before renaming suspected files through IVX, try a few runs with different detection thresholds. Review the report to chose the best threshold. The best is when all infected files are captured and the report contains no false positives. It's preferable to replace a few extra files in case of doubt, than to risk reinfection. Examples: Legend: ²²--Statistics, ±±--Encryption, °°--String. C:\JERUSALEM\ ±±±±±±±±±±±±±±±±±±±°°°°°°°° 60 CHKDSK.EXE ±±±±±±±±±±±±±±±±±±±°°°°°°°° 60 EMM386.EXE ±±±±±±±±±±±±±±±±±±±°°°°°°°° 60 EXPAND.EXE ²²²²²²²²²²²²²²²²²²²±±±±±±±±±±±±±±±±±±±°°°°°°°° 100 DISKCOMP.COM ²²²²²²²²²²²²²²²²²²²±±±±±±±±±±±±±±±±±±±°°°°°°°° 100 MODE.COM ²²²²²²²²²²²²²²²²²²²±±±±±±±±±±±±±±±±±±±°°°°°°°° 100 MORE.COM The first example is of the Jerusalem virus. It infects both COM and EXE files. The sample used in this illustration is Virusample file, created automatically by IVTEST. The report shows 100% correlation of the COM files and 60% for EXE, since Jerusalem is a plain non-encrypted virus. If we had used Vir-Code instead, the results would be 100% correlation for EXE and 60% for COM, as Vir-Code is an EXE style sample, while Virusample is usually a COM one. The threshold was set to 50%, to filter out false positives. C:\MALTESE\ ±±±±±±±±±±±±±±±±±±± 40 FORMAT.COM ±±±±±±±±±±±±±±±±±±± 40 MODE.COM ±±±±±±±±±±±±±±±±±±± 40 MORE.COM ²²²²²²²²²²²²²²²²²²²±±±±±±±±±±±±±±±±±±±°°°°°°°° 100 DELTREE.EXE ²²²²²²²²±±±±±±±±±±±±±±±±±±± 56 EXE2BIN.EXE ²²²²²²²²±±±±±±±±±±±±±±±±±±± 56 EXPAND.EXE ²²²²²²²²²²²²²²²²²²²±±±±±±±±±±±±±±±±±±±± 80 FC.EXE The second example was taken from Maltese Amoeba (alias Irish) and is especially interesting. Irish is heavily encrypted, although it is not considered as polymorphic. DELTREE.EXE is used as the sample. Note the dispersion in the correlation factor. Note also that the largest common correlation is contributed by encryption (the middle shading). As a rule, encrypted viruses will show no contribution from string matching, with most of the similarity due to encryption, and sometimes some contribution due to statistical matching. The threshold was set to 30% in this case. Practicing IVX. It may be worth to practice with IVX so that you know what to do when the real thing happens. You may use IVX to trace down files that were processed in the same way. For example, all InVircible files, except IVHELP, were processed by LZEXE runtime compression. Try the following: IVX C:\IV\IVB.EXE C:\ All the files that correlate higher than 65% are treated by LZEXE as well. Now, if you correlate with IVHELP.EXE as the sample, IVX will find programs that were processed by PKLITE. You will find a few of in the DOS directory. Other compression schemes that can be used to practice IVX are: DIET and Microsoft's ExePack. Correlate to \DOS\EXPAND.EXE for ExePack and set the detection threshold to 70. For DIET, correlate to Frisk's F-PROT.EXE (if you got a copy) and set the threshold to 50. 8. ResQdisk - The Boot-Areas and CMOS Maintenance Program. ResQdisk is a compact yet extremely powerful utility capable of repairing damage to the hard disk partition or boot sector, removing known and unknown partition or boot viruses, restoring self booting capability to hard disks and regaining access to "lost" hard disks. ResQdisk deals uniquely with hard disks drives, not with floppies. Disks are organized in sectors, which are 512 bytes data storage units. Any DOS hard drive has two such vital sectors: the master boot sector (sometimes referred to as the partition table) and the boot sector. Floppies have only a boot sector. These sectors are favorite targets for computer viruses, since they contain tiny programs that load first at booting time. A damaged or missing sector will return an "invalid drive specification" message, fail to boot, deny access to the hard drive or simply read trash from the disk. For maximum safety, the boot area images are written to the Rescue Diskette, since an inaccessible disk will deny access to the backup written to itself. ResQdisk's options are displayed on the menu bar, at the screen's bottom. Press F1 or "/" to see more options. The F1-F2 key sequence will backup the boot areas and the F1- F3 sequence will restore from backup images to disk. Each sector can be individually backed up or restored by shifting to the desired sector on screen (use the cursor direction keys) and pressing either B for backup or R for restore. Every disk has a unique partition and boot sector. Do not attempt to swap or copy boot areas between hard-disks. This might end up with an unreadable contents of the transplant's receptor. 8.1 Reconstruction of the Boot Block. ResQdisk has special routines for the reconstruction of the hard disk partition or boot sector, in case they have been damaged or cannot be recovered. For example, incidentally booting a disk which is infected with Stoned with a floppy infected by Michelangelo will not boot anymore by itself, although it can be booted from a DOS floppy. Attempting to restore the partition with the FDISK command may end up with the complete loss of the whole disk content. ResQdisk makes it easy; all that is needed is the following keys sequence: Press the 'Home' key, then F1, then F4 Tampering with the boot sector is corrected by the sequence: Left arrow, F1, F4 8.2 ResQdisk's Special Functions. It may happen that the disk setup parameters stored in the CMOS become invalid because of a weak battery, a setup error and sometimes even bad software. If this happens then reboot the computer from the rescue diskette and press when IVMENU finished loading into memory. Answer yes to the query "Attempt to restore the CMOS data?". The computer will then automatically reboot with the restored CMOS parameters. To see ResQdisk special functions menu press the "/" (slash) key. Warning! ResQdisk should not be used on disks that have a boot area password or access control device installed on them. These devices are highly susceptible to cause total loss of the whole disk content. As a rule of thumb: If a hard disk can be accessed after booting from a DOS floppy, then the partition refresh procedure may be used safely. 8.3 ResQdisk's Setup Utility. ResQdisk has a built-in setup calculator. This may be especially useful with IDE hard drives, in case the CMOS data was erased or nullified and there is no available data on the drive parameters. All that is needed is to select a random disk type from the setup table, boot from a DOS floppy and run ResQdisk. The F5 function key will identify the manufacturer's parameters of the hard disk. All that is needed now is to set the CMOS data to the correct type and restart the computer. ResQdisk can also be used to regain access to an inaccessible hard drive, whether either the partition sector or the boot sector was damaged. ResQdisk will indicate "Press Ctrl F1" or "Press Ctrl F2" to rebuild the partition or the boot sector respectively. 9. IVSCAN - The Virus Detection and Removal Scanner. While disinfecting a computer, with IVSCAN or else, the user must be aware of the possibility that a virus might be active in the computer's memory (memory-resident). Since a virus in memory has taken control of the computer, a general rule is to reboot an infected computer from the write- protected Rescue Diskette, or from a clean write-protected DOS diskette. The disinfection of a hard-disk must be per formed only from the Rescue Diskette and not from the suspected drive itself, unless InVircible's programs specifically recommend execution in an infected environment (e.g. Inverse Piggybacking). Detection of, and disinfection from known and common viruses is done by IVSCAN. The program is activated via IVMENU or directly from the command line. The command line syntax is: IVSCAN [-] [where and what to scan] [/Option] Parameters in [ ] are optional. If no option is chosen IVSCAN will detect viruses without removing them (the default). The default scan path are the current directory and its sub-directories. The use of wildcards (*,?) is allowed in specifying where and what to scan for. The options are: /R to restore the file (if it can), /D to delete infected files that IVSCAN cannot recover, /B to recover or replace a suspected boot sector in floppies, or MBR on hard drive. /EX to scan executable files only. The [-] parameter will limit IVSCAN to process the specified directory only. Examples: To scan the entire C: partition for viruses in the Detection- Only mode type: IVSCAN C:\ To use IVSCAN for detecting and eliminating viruses automatically only from COM files in the DOS directory, type: IVSCAN + C:\DOS\*.COM /R - The space before the hyphen is required. If the hyphen is not used, this command will cause IVSCAN to begin at the specified directory and scan all subsequent sub-directories. If IVSCAN indicates "use IVB to restore" and the affected files were properly secured, then restore them with IVB (see Section 6). Use the Delete option as a last resort. A list of infected, deleted and restored files will be written to a IVSCAN.RPT file in the root directory of the processed drive, to help you replace the deleted files. Before attempting the recovery of a file IVSCAN will prompt you with three options: Recover, Skip or All (recover all). 9.1 Removal of Generic Boot Viruses. Boot viruses are transferred from one computer to another by accidentally booting from an infected floppy (the infected diskette is left in drive A and the computer is rebooted), even if the floppy is not bootable, just infected! IVSCAN provides for the replacement of the boot sector in floppies with a standard DOS boot sector. The same procedure will remove generic boot infectors and even restore readability to 3.5" floppies that were hit by boot infectors such as Michelangelo. Just type: IVSCAN drive: /B IVSCAN restores files infected by viruses included in its repertoire. For infectors unknown to IVSCAN use IVB. 10. A Primer to Generic and Special Methods. Generic techniques can cure damage from groups of viruses such as boot-block infectors, stealthy file infectors and FAT manipulators. First, assess the type of infection by its symptoms, then test the suggested method on a sample diskette or directory. If successful, apply the selected technique onto the entire infected disk. 10.1 Generic Method Selection As a rule, viruses always disclose there presence sooner or later. InVircible provides alerts when sensing various effects that are unmistakably related to computer viruses. Among InVircible's messages, the following are of special interest: (1) "... Kbytes are missing from total available memory." (2) "A stealthy virus is active in system." (3) "File size changed by 0 (zero!) bytes ... " (4) "Free disk space decreased by ... bytes, program halted!" (5) "Partition (or boot) sector is faked!" (6)"The disk is infected by a boot infector!" Message (1) indicates "memory stealing", attributed mostly to the presence of a boot or partition infector. Certain file infectors do the same, and this possibility should be first discarded. Also, some programs such as DesqView, or certain BIOSes (PS, Dell, Acer and some laptops) cause the same without being related to virus activity. Message (2) or (3) indicate that a stealthy virus is active in the system. Message (4) indicates that a piggybacking process was detected and the search was halted to prevent further spreading of the virus. Message (5) indicates the presence of a stealth virus in one of the boot area sectors. Message (6) will be displayed when an unknown boot infector is found in one of the boot areas of the hard disk or of a floppy. In case the virus is common, InVircible will recommend on the corrective action. If not, then proceed as follows. It is recommended that less experienced users ask for assistance or leave the following procedures to qualified personnel, since dealing with smart viruses requires training and inexperienced users may do more harm than good. For the expert user. If one or more of the above messages are returned, then proceed with the following tests. Run IVB in its default mode with the virus in memory and watch if "modified files" are reported. In case such files are reported with the virus in memory, the virus is not a perfect stealthy one and cannot be restored by the Inverse Piggybacking or by the Integrity Interrogation generic methods. Next, boot from the Rescue Diskette and run IVSCAN to eliminate the possibility of a common infector. In case that IVSCAN reports the possibility of an unknown boot or partition infector, then proceed with the generic boot- block recovery. Non-perfect stealthy viruses can be recovered by IVB if the disk contents was previously secured. If the virus is a perfect stealthy (only), select either the Virus Interrogation technique or the Inverse Piggy- backing. Always try first on a floppy, which is the best technique to use for a particular virus. Beware of FAT manipulators! Run CHKDSK on the damaged unit, without the /F switch, when booted from a clean DOS diskette. Watch if file allocation error or cross-linking of executable files is reported. If yes, this may be the doing of a FAT manipulating virus. Do not attempt repair with disk fixing utilities if infected by a FAT manipulator. Any such attempt will end in massive and irreversible damage. In all cases, it is advised to test the selected method on a sample diskette and if successful, to apply it to the infected units. 10.2 Generic Boot-Block Recovery InVircible and DOS provide for the recovery of both the Master Boot Sector, also known as the partition table sector, and the plain Boot Sector. Both sectors are found only on hard disks, while floppies have only a boot-sector. Floppies: IVSCAN provides for the recovery of a large spectrum of known and generic boot infectors, and will suggest the replacement of the sector with a standard DOS 5 one, in case a potential unknown infector is found. Hard Disk: The recovery should always start by inspecting the partition table first. Run ResQdisk to get acquainted with the look of both the master-boot-sector (MBS) and the system-boot-sector of your hard-drive. In case of boot-block tampering, boot from the Rescue Diskette and visually inspect both sectors by running ResQdisk. Some infectors such as FLIP will cause only minor changes, perceivable only to the expert observer, some as Stoned will show a message such as "Your PC is Stoned, Legalize Marijuana!". The restoration of both sectors is straightforward by ResQdisk . There are instances when there is no copy of the original sector to restore from, and no Rescue Diskette exists. For example, consecutive infections by Stoned and Michelangelo will not leave an original MBS. Master Boot Sectors can be restored by ResQdisk, provided the drive is accessible and readable after booting from a DOS disk in drive A. Enter the ResQdisk program and proceed with the F1 - F4 function keys sequence. This procedure is the equivalent of the DOS-5 undocumented command: FDISK/MBR. Caution! Do not use the ResQdisk F1-F4 procedure in the following cases: (1) There is an active virus-prevention TSR in memory. Ad dressing the master-boot-sector may be diverted by such TSR and this may end in total loss of access to the hard- drive. (2) The same applies for hard-disks with a software password installed. Uninstall the password prior to proceeding with this technique. (3) Partitioning schemes other than DOS FDISK such as Disk Manager and SpeedStor are not suitable for this technique. As a safety precaution, first backup the boot-areas on the original InVircible diskette by ResQdisk and the F1-F2 keys sequence. The current boot areas can be restored later by ResQdisk. An alternative way to ResQdisk, for replacing the boot sector is by booting from a clean DOS diskette, necessarily of the same DOS version as installed on the hard disk and transferring a fresh sector by the command SYS C: The Rescue Diskette will normally contain the SYS.COM file and it may be used for the purpose. In case of a damaged or nullified boot sector, DOS will not let to renew the sector by the sys command (the message "invalid media type" is returned by DOS), and ResQdisk will become the only way to recover the drive. Recovery from Boot Stealth Viruses. The procedure that follows will probably never be necessary for the licensed user, as boot spoofers are taken care of in IVINIT, right at boot time, as well as in IVSCAN. It is brought here mainly as a work-around for non-licensed users and to explain the mechanics of boot spoofers. ResQdisk can be used for the recovery from boot stealth viruses. Inappropriate procedures with boot spoofers may cause the loss of access to the hard disk, as happens indeed with quite many scanner and TSR anti virus products. ResQdisk enables full recovery from viruses such as from Monkey, Newbug, Quox and many others. The presence of a boot stealth virus is announced by IVINIT or IVTEST, with the message "faked partition (or boot) sector". The virus is then sampled into a file labeled PARTVIR or BOOTVIR accordingly. Run ResQdisk and confirm the presence of the stealth virus by switching between SeeThru "ON" and "OFF" - with the F9 key, while watching the master partition sector, or the boot sector. Create a backup of the infected sector by pressing the "B" key, while SeeThru is OFF. The backup content is the true boot sector. Licensed users may switch now the SeeThru to "ON" and restore the sector from the backup by pressing the "R" key. The original sector, rendered by the virus, will be written to the hard disk, in its right place. Non-licensed users will have to run the above from a floppy, reboot the machine from clean DOS and then restore the original sector in place by running ResQdisk from the floppy. Exit ResQdisk and reboot the computer without running anything else! The computer will restart with a clean boot block. Note that the recovery from boot stealth viruses must run with the virus ACTIVE in memory! 10.3 Fat Manipulators Removal The FAT manipulating viruses appeared at the end of 1991 and use a new method for propagation, based on the modification of the FAT pointers chain. There are now at least two widespread such viruses, DIR-2 (Creeping Death) and 1963 (Niemela). These viruses are inherently stealthy and propagate extremely fast. Standard passive scanners are useless and harmful against these viruses. Countless hard disks were unnecessarily destroyed by the use of passive anti virus scanners against these two viruses. MSAV, the virus scanner distributed with Microsoft's MS-DOS 6, is an example of a passive scanner. Although it detects the 1963 (Niemela) virus and claims to clean it from infected files, in reality it ruins all the files it "cleans" from this virus. InVircible provides a totally safe and extremely efficient means for both the detection and the full recovery from these and other FAT manipulators. FAT manipulators are removed by an active Inverse Piggybacking process. The presence of DIR-2 or 1963 is detected by InVircible programs and is indicated by a warning message. In case a FAT manipulator virus activity is suspected, do not use the DOS CHKDSK/F switch, until the disk is completely disinfected! Using the /F switch while a FAT manipulating virus is active will cause massive and irreversible damage . 10.4 Inverse Piggy-Backing (IP). The Inverse Piggy-Backing (also called cooperative virus removal) is a generic technique embedded in IVSCAN. It is based on forcing the infecting virus to disinfect its own doing. There are two available methods actually, labeled /M1 and /M2. Method 1 is effective against "light" stealthy infectors such as 4096 (Frodo) and 1963 (Niemela). Method 2 is to be used to disinfect from the more "stubborn" ones such as DIR-2 and future FAT manipulators. Inverse Piggybacking is selected from IVMENU, from the Virus Scanner mode. The command line syntax for Inverse Piggybacking is: IVSCAN drive: /Mn, /Mn being the method switch and "n" its number, for example, type IVSCAN C: /M1 to run method 1 on drive C. Inverse Piggy-Backing should start with the virus loaded in memory. Start by purposely running an infected file. In most case the operating system itself will be infected so that you may proceed directly to disinfection. The DIR-2 virus will lock up the computer if run under DOS-5 or DR-DOS-6. To disinfect from DIR-2 one should boot from DOS lower than 5. Method 1 is a single pass procedure. The processed drive will be operable after its completion. Method 2 requires two passes. On the first one COM/EXE files will be processed by the virus itself. A second pass with the IVSCAN /M3 switch restore the files to their original state. Disks processed with the /M2 switch, except partition C, will require processing with the /M3 switch to have their executable files restored to original. Only partition C will be automatically cycled by M2/M3 processing. The IVSCAN.EXE program should reside on drive C for complete and automatic processing of this drive. Important! Turn off all disk caching before starting Inverse Piggybacking. Some disk caches oppose the IP technique. InVircible takes care of turning off the SMARTDRV.EXE cache. For other brands, consult the cache documentation on how to turn it off. Floppies and hard-disk partitions, other than C should be processed first. Partition C will be processed last. When finished with C, automatic rebooting will occur. Caution! Do not run any program, nor address the hard drive until rebooted, otherwise the drive will be immediately re infected. 10.5 The Integrity Interrogation technique. This technique is a two step procedure. First, file database are established from an infected environment, then the files are restored by IVB , from a clean environment. The theoretical basis of this method lies in the fact that some viruses are so perfectly "stealthy", that they "show" the true uninfected file data to the operating system, when inquired about. Start by booting the computer from the infected drive itself. Make sure the virus is active by running a program known to be infected. IVB should be installed on the processed drive. Run IVB drive: /S (or the Secure option from IVMENU) on the entire directory or drive. Restart from the Rescue Diskette and run IVB in its Restore mode. 10.6 Forced Self Restoration. The InVircible programs (except IVHELP, which is licensed from another vendor) will normally restore themselves in case they are attacked by a virus. In certain cases the program will get infected and stuck, thus inhibiting its self recovery. In such cases a little assistance from the user will be helpful: just type the infected program's name with the /FR (forced recovery) switch. For example, IVB/FR. Switch the computer off afterward since the virus may be now resident in memory. 10.7 Screening New Software. InVircible is ideal for screening new software, to assure it is free of virus. Software screening is especially important in organizations, where viruses are usually introduced with new software, without having been screened first. The screening of software should be performed on an isolated computer (never when logged into a network). InVircible should be installed on the screening computer and a rescue diskette prepared for it. Install the new software on the hard disk according to its manufacturer's instructions, then "secure" it with IVB before actually running it. The new software should then be run and all its executable modules should be exercised. Reboot the computer from the rescue diskette and scan the hard disk with IVB for changes in files. Inspect the boot block for changes with ResQdisk. Compare the MBS and boot sector by individually "restoring" them from backup and watch for changes. Now reboot the computer from its own hard disk and watch for InVircible's warning messages. If all tests passed without findings then the software is most likely clean from known or unknown viruses. 11. Importing InVircible into Windows InVircible is distributed with IV.PIF and IV.ICO files, to operate under Windows. Both files will be copied to the InVircible default directory by the Install utility. Start Windows normally and import InVircible into Windows by selecting New from the File menu and the Browse radio button. Use IV.PIF as the command line and IV.ICO as InVircible's icon. We also suggest to add Alt+Ctrl+V as the shortcut key, when in the properties change menu. Now InVircible can be activated from Windows by either double clicking on its icon, or by pressing Alt+Ctrl+V. As stated elsewhere in this guide, viruses operate only in the DOS environment. InVircible sometimes uses virus cooperative techniques. Viruses are not "well behaved" in an environment different from DOS. Therefore, it is recommended that only passive tasks such as integrity checking or virus scanning is done from Windows. Active disinfection, such as Inverse Piggybacking should not be attempted from Windows, but only from plain DOS. 12. Virus Handling Under OS/2 Computer viruses are often called DOS viruses, which implies that they are programmed to operate only under DOS. However, any operating system that is DOS compatible is susceptible to DOS viruses when in DOS compatibility mode. InVircible is compatible with the IBM OS/2+ operating system when in DOS mode. Because DOS internals are interpreted differently by OS/2, DOS viruses behave unexpectedly in an OS/2-DOS environment. Whenever InVircible detects viral activity in an OS/2 environment, proceed as follows: Simply COLD BOOT the computer from the Rescue Diskette and proceed normally with IVSCAN and IVB procedures. All virus disinfection should be undertaken only in a DOS environment. Do NOT attempt to boot DOS from the OS/2 dual booting system when viral activity is reported or suspected. When done, reboot the computer normally. 13. Central Point Anti Virus Inoculation The CPAV Inoculation or self integrity check is the cause of many unexplained malfunctions. Many programs do not tolerate being inoculated, especially not DOS files, but not only them. The inoculation process consists of the encapsulation of executable files (COM and EXE) in a protective shell, like a cocoon. The inoculation adds about 700 or 900 bytes to COM and EXE files, respectively. The inoculation also modifies the programs in other ways. Inoculation has many drawbacks and practically no merits. First, the 700 to 900 bytes added waste a lot of disk space. Second, inoculation causes programs to malfunction, especially under MS-DOS-6+. Third, the recovery of an immunized file will in most cases worsen the situation. In order to drop the virus the infected file must be run, at the risk of loading the virus into memory and infecting other files. And last, inoculation is useless against smart viruses and is not worth the trouble! Except for its malfunctions, there are good reasons why not to inoculate programs. The inoculation may hide a virus that infected the file prior to its inoculation. A dedicated virus may simply peel off the inoculation, infect the file and then re inoculate it as if nothing happened. InVircible will indicate files immunized by CPAV by either scanning with IVSCAN or IVB. Unfortunately there are differences between versions of CPAV, so it is safer to disimmunize files by the same product that inoculated them in the first place. Use the following procedure only if there is no other alternative, and with all precautions. Backup the files to be recovered. IVSCAN will remove the CPAV inoculation from files when in the virus "remove" mode. 14. The Antivirus TSR (Terminate and Stay Resident). Memory resident programs (TSR) have been in use since computer viruses appeared in 1987. Their purpose is to prevent the penetration of a virus to the computer. Unfortunately, the TSR virus prevention is based on too many weak assumptions. Anti virus TSR look only for viruses included in their database. There are today as many as 5000 known viruses and their number increases at a constant rate of 50 to 100 per month. This number takes a heavy toll on the size of the database attached to the TSR and occupies precious memory space. Anti-virus TSR can be aggressive, affect the computer's performance, interfere with other applications, cause conflicts in memory and are potentially dangerous! For example, a typical and common AV TSR slows the computer by a factor of 3 to 5 and is notorious for having knocked out many hard disks that it was supposed to protect, without the slightest trace of any virus. The TSR simply defeated itself by derouting interrupt 13 (the one used for disk read and write) to deceive boot viruses, and fell in its own trap! TSRs need to be constantly updated. The assumption that the producer of the TSR will be the first to examine any new virus, proved to be false in most cases. The TSR is useless against new viruses, neither will it detect a known, but modified virus. Practically, a TSR older than six months is out-of-date, in most cases it is already obsolete at the date of its announcement. VSAFE, the anti-virus TSR distributed with MS-DOS 6, is a grim reminder of this fact. Anti virus TSR suffer from false alarms and the higher the number of viruses a product detects, the higher is the rate of its false alarms. The common user has practically no means to distinguish between a false alarm and a real virus. Furthermore, TSR are incapable of distinguishing between a real virus and a faked signature, which explains their susceptibility to false alarms. For example, the following string of 10 bytes, when added to any program, will mislead McAfee's antivirus products to believe the program is infected with the Jerusalem virus. Consequently, VSHIELD (the TSR) will inhibit the execution of the program, SCAN will "detect" the Jeru-A virus and CLEAN will ravage the file containing the string as if it was really infected with "Jerusalem". The faked Jerusalem virus string, in hex notation: 03 F3 A5 26 C6 06 FE 03 CB 58 AV TSR got bad reputation over the past years: the number of incidents in which anti-virus TSR were the direct cause of severe damage surpassed those caused by genuine viruses. Weighing the pros and cons for and against anti-virus TSR leads to the conclusion that TSR are a constant nuisance and threat to the health of your computer. The remote possibility that a TSR will really stop a banal virus attack, that could be removed anyway by less dangerous means, is not worth the trouble and the risks of the TSR! 15. Procedures to Use if Virus Activity is Suspected. When dealing with computer viruses, awareness is the key to success. Do not improvise. Do not panic or act hastily. If there is no apparent damage, in most cases no further damage will occur until the computer is switched off and rebooted. Computer viruses are nothing else than programs themselves. A computer will not become infected unless an infected program is executed. Reading data cannot cause infection whatsoever! If you suspect the computer is infected with a virus, proceed as follows: a. Do not switch the computer off immediately. If you have already turned off the computer, do not reboot the computer from its own hard-disk but rather from the Rescue-Diskette or from a clean and write-protected DOS floppy. b. Save the data of the last job you were working on and exit normally from the application you were in. Do not start a new job as long as the computer wasn't verified and cleaned. The following steps will enable you to recover from a virus event with the minimum of disruption: a. Have the Rescue Diskette always ready as well as a copy of your favorite backup program, both on write protected diskettes. b. Boot from the Rescue Diskette and backup all important data. Programs can always be reloaded from original disks, data cannot. Copy several infected files to a diskette for later inspection. Do not start disinfecting the computer without completing the above steps. There is a possibility that irreversible things may happen in the course of virus removal. In fact, most of the damage caused by viral incidents is the result of inappropriate disinfection procedures. c. After the system is cold rebooted from the Rescue Disk, first run IVSCAN to test for common viruses. Remove the viruses as described in section 10. Next run IVB. d. After disinfection, do not hurry restoring files from backup, without verifying its contents first! The backups are likely to contain the same virus you just removed. Consider rebuilding your applications from the original software manufacturer's diskettes. Retain data only from the most recent backups, to minimize the possibility of repeated infections from your own backups. Viruses propagate in many ways. Smart viruses use stealth, self encryption or both. The more programs run, the higher the chances are of unintentionally activating a virus. Do not use shell programs or utilities while disinfecting a computer, certainly not from the infected disk itself. Do not run any program from the infected disk. Use plain and internal DOS commands such as DEL, REN, COPY etc. If you feel uncomfortable with these limitations, ask for assistance from a more knowledgeable user. All programs should be run from write-protected diskettes and reliable sources. The only exceptions are when explicitly instructed to work from an infected environment, such as for Inverse Piggybacking or Virus Interrogation, as explained elsewhere. Be consistent! Do not mix InVircible with other anti-virus software or hardware. Unraveling the results of mixing anti- virus methods is similar to attempting a medical diagnosis for an intoxicated patient that has swallowed multiple self- prescribed drugs. A virus in memory is a virus in control of the computer, while you may believe you are. Viruses are extremely deceitful programs, and will mislead even experienced users. Many viruses seek to infect the command interpreter. This is the file denominated by the environment string "COMSPEC" when typing the SET command. Therefore, it is good practice to replace the COMSPEC file from an original diskette. Also, rename the AUTOEXEC.BAT and the CONFIG.SYS to non-executable names until disinfection is completed. 16. Practicing InVircible, the AV Practice Lab (AVPL). NetZ Computing provides a practicing environment named the Anti Virus Practice Lab (AVPL). AVPL is complementary to antivirus software and was developed for the purpose of practicing anti virus techniques in general and InVircible's in particular. It is best used in concert with InVircible. Yet it can be used with any AV product to learn about viruses and how to protect your PC and network against them. AVPL is a self contained tool that will let you practice several virus attack scenarios and how to recover from them. Although AVPL is designed to be used with the advanced generic anti-virus tools of InVircible, it can also be used to evaluate AV products in general. AVPL allows to "infect" selected computer programs in a virus like way, to install master boot sector (MBR) infectors to the hard disk, and to practice InVircible to identify the simulated viruses and recover from them. The "infections" produced by AVPL are ultimately harmless. The viruses created by AVPL will not replicate. They can not spread through a process of spontaneous replication to other programs or disks. They will only affect the program files in a target directory selected by the user and the hard drive of the system on which AVPL is installed. Therefore, the user can be assured that only those programs and the hard disk of their system can be affected by AVPL. AVPL will ONLY affect program files and the hard drive chosen by the user. Programs that are affected by AVPL can be "cleaned" either through the use of the Uninstall option of AVPL, through InVircible or through the DOS delete command. MBR infections that were installed by AVPL can be removed as well by AVPL's Uninstall option, or through the use of the ResQdiskette. It is important that you prepare a Rescue Diskette before you begin experimenting with AVPL. Prior to experimenting with AVPL please read its on-line hypertext guide. AVPL is available from all InVircible distributors as well as from anonymous ftp sites on Internet and BBS. AVPL is freeware, the file name of the package is AVPL101.ZIP. For Computer Security Experts and Advanced Users. Rehearse with real viruses on an isolated (not in a network) computer to get the feel of what a virus attack is like. Virus simulating programs are worthless in the forming of computer security experts. On the contrary, any anti-virus program that responds to a simulated virus is also susceptible to false alarms and will destroy programs in an attempt to remove an imaginary virus. Experiment only with "controllable" viruses such as Stoned, Jerusalem and Frodo (4096). And last, prepare a recovery plan and simulate it on a small scale, prior to being hit by a real computer virus. When the real thing happens, you will feel much more at ease if you have an idea of what a real virus attack is like and have practiced before. Appendix A. - LAN Protection The following describes how to implement InVircible for the protection of local area networks (LAN). At this date, there are no known viruses that affect the operation of Novell's Netware software. Yet, DOS viruses may affect executable and non executable DOS objects, stored on file servers. An infected object, such as a DOS shared application, when executed, can further spread the infection, from one workstation to another networked station. As a general rule, boot and MBR infectors, excluding multipartite ones, will not propagate through the network from one station to another. The effects of such viruses are retained locally and will not extend outside of the affected workstation. A file server can even be started with its MBR infected by Stoned or Michelangelo, and none of the other stations will suffer anything or even notice there is something wrong with the server hard disk! On the other hand, many file viruses can survive the Netware login process, or become active when already logged onto the network, and infect files on either the local disks, or on the file server. Virus Propagation in a Network. File viruses are usually categorized as direct action viruses and memory resident viruses. Some memory resident viruses are also known as "fast infectors" or piggybackers. All three terms refer to the propagation mechanism of file viruses. Direct action viruses infect additional file(s) every time an infected file is executed. Since the virus is not memory resident then the infection of more files will not occur on the execution of a program that is not actually infected. The criteria and pattern upon which additional files become infected can be anything: i.e. infecting files in the current directory, down the directories tree, along the DOS search path, at random etc. Memory resident viruses usually load into the workstation's memory, when the first infected file is executed. It doesn’t matter where from it is executed, either from the local disk, or from the remote disk of the file server. From then on, any file that will be executed and fits the infection criteria of the particular virus (that is now memory-resident), will become infected itself. Many memory resident viruses have a direct action mode of infection too, in addition to the memory resident infection mode, as described above. Piggybackers are memory resident viruses that will infect any file that is "opened" or "closed" by the operating system. The programs that are the most likely to become carriers of fast infectors are virus scanners of all sort, as these programs are the only ones that “open” and “close” every single program on a drive, while scanning them! It is thus essential that antivirus scanning programs, whether scanners or integrity checkers, be equipped with anti piggybacking features. For the moment, only InVircible has this ability. It’s reasonable to assume that all programs that were loaded to a file server were clean from viruses at the time they were loaded. Then how come that later on, some of these programs become infected? The answer is simple: An infection that originated from one of the workstations found its way to an application on the file server. If another workstation called and executed the infected program on the file server, then that station’s memory - and eventually its hard disk - will become an additional source for the spreading of the virus. Later on, the newly infected station will infect additional applications on the server. The most common pattern of how massive infections occur on file servers, and spread across the network to all workstations, is because of unaware network supervisors and the excessive use of virus scanners! the classical scenario is as follows: A new virus manages to infect a workstation. Most network managers unjustifiably rely on their scanner(s), anti virus TSR and on antivirus NLM. Being misled by a false sense of security, they overlook and reject the possibility that the scanner itself may be the source of an infection. Over self-confidence and ignorance are usually the excuse for not implementing better antivirus means than NLM scanners and TSR. Sooner or later, the supervisor will log-in with full read-write rights (supervisor or not ?!) and scan for viruses with a piggybacked scanner. The results are obvious. The lessons to be learned are: 1. Since virus infections in network always start from a workstation, then workstations should be checked for virus presence prior to connecting to the network. Especially those PC that have local hard disk, as their chances to become infected are infinitely higher than those that boot from a network startup floppy, or from ROM-DOS. Antivirus that are initialized from the network, upon login, are stupid, insufficient, and worthless. The same applies to NLM too. 2. Virus scanning of file servers should be run sparingly and with utmost precautions. Since piggybacking cannot be sensed on file servers, for technical reasons, then scanners should always be tested first on a local hard disk (never from a floppy) to give a piggybacker the opportunity to disclose its own presence. Only piggybacking resistant scanners should be used on file servers, unfortunately there is only a single such product on the market - IVSCAN from the InVircible package. Antivirus Protection in a Networked System. The strategy of how to protect a networked system from virus attacks consists of a few simple steps. First, have InVircible installed on all stations that have a hard disk. This way, every such station will be verified before the station has a chance to connect to the network and can contaminate the server. To facilitate the task, InVircible can be installed directly from the file server, to workstations having a hard disk. IV is provided with the IVLOGIN.EXE program. All that the supervisor need to do is to install IV into a dedicated directory on the server and invoke the IVLOGIN program from within the users login script. The following explains how to do it in a Novell network, every LAN manager knows how to adapt it to his own network brand. Suppose IV was installed to F:\PUBLIC\IV. Run SYSCON and select "Supervisor Options" from the menu, then select "User LOGIN Script". Add the following line into the script: # F:\PUBLIC\IV\IVLOGIN.EXE Instead of virus scanning, better is to secure and verify the file server content with IVB, the integrity analyzer and generic restorer. This can be done by issuing the command: C:\IV\IVB F: DAILY It is recommended to run InVircible's Off-line Backup periodically, once a week, or twice a month. The Off- line Backup will produce a copy of the directories tree on floppy, with their respective signatures files, in case these were lost or tampered with. See elsewhere in this manual for how to run the off-line signature's tree backup. Cleaning a File Server from a Virus Attack. Whenever a virus is detected in a network, then act in an orderly way. While the virus is still active, try to obtain good virus samples on your local disk. Start by making sure that the COMSPEC points to the local disk (type SET to verify where to the COMSPEC variable points). Correct if necessary by typing SET COMSPEC=C:\COMMAND.COM. Run C:\IV\IVTEST, from the local disk. If lucky, IVTEST will generate two samples: Vir-Code and Virusam.ple. These will be valuable later, especially if the infection was caused by a variant or a new virus. Now proceed with the disinfection of the local disk. Use the rescue diskette if necessary. Try to locate the source of the infection on your own local disk by correlating with IVX. Consult the IV documentation if needed. During the disinfection of the local disk, learn the characteristics of the virus. If known by IVSCAN, then it's simple. If new or unknown to IVSCAN, then use IVB and note which type of files it infects (COM, EXE, SYS, OVL etc.), and what's the virus size. With IVX and the virus samples, find out what are the best correlation parameters to easily find all infected files, eliminating "noise" (detection threshold, correlation to Vir-Code and Virusam.ple, level of correlation, relative weight of statistical fitness, crypto model and string matching). When the local disk is totally clean, login to the network manually (execute the login batch line by line). Avoid the execution of any file from the server itself. Novell Netware systems administrators: Do not run LOGIN from the server, as the files in the login directory may be infected. Keep a clean copy of the F:\LOGIN directory on your hard disk, or on an IV Armored floppy and run LOGIN from the floppy or from the hard drive, in order to log in as 'supervisor'. Now assess the extent of the virus spread on the server by using IVSCAN (for viruses contained in its database), IVB and IVX. Before cleaning the server, shutdown all workstations in an orderly manner. All stations should be switched off, since the virus might still be memory resident. All the stations with hard disk should be disinfected individually before hooking them again to the network. The file server should be restored and cleaned in the following order. First use IVB/R for the fastest and best restoration of affected programs (provided they were secured beforehand). Next use IVSCAN /R, if the virus is known to IV, to restore those files missed by IVB (no signatures). If the virus is unknown to IVSCAN, then correlate with IVX to find out all files missed by IVB. Either rename the suspected files or delete them. Both options exist in IVX. Print the IVB/IVSCAN/IVX reports after each step. You may need to delete a few files that IVB could not restore, by using IVB/D. Replace the files that were renamed or deleted by IVB/IVSCAN/IVX (as in the reports' printout). Restart the network and resume operation. The methods described above should let you to resume network operation even after severe virus incidents, within half an hour to a couple of hours, while it could take a couple of days to a couple of weeks by other means. Appendix B. - Large Capacity IDE. There are a few facts that you should know when using the new large capacity IDE drives. They are becoming popular for their great performance and affordable price. These drives are designed to work with new mother-boards and BIOS, capable of handling more than 1024 cylinders. The 80x86 BIOS was limited by its designers to handle geometries of up to 64 sectors, 256 heads and 1024 cylinders, altogether 8.38 gigabytes, in sectors of 512 bytes. The newer BIOS have LBA (logical block access), or a translation which accept higher than 1024 cylinders in the setup. To overcome the BIOS limitation of the older boards, these drives require the installation of a special boot driver, if you use them with an older BIOS, and you want access to the drive's full capacity. The driver replaces the standard mbr and is written from sector 2 and on, on track zero. When booting, the special mbr bootstrap loads the driver from track 0 into memory, and then continues booting the OS. Without the special driver you can't access the hard drive at all. You may not install the boot driver and configure the drive with FDISK, but then you can only access 528 mbytes. When using the special driver, you will not be able to access the hard drive when booting from a plain DOS floppy. You need to install the driver to the floppy and load it trough the floppy's config.sys, as a `device'. There are two makers of these drives, Ontrack (Disk Manager) and Micro House (EZ-Drive and DrivePro). Some large capacity IDE models can emulate two physical hard drives, just by the flip of a couple of jumpers, in case LBA isn't available. You won't need then the special driver. Both drivers use stealth, probably to protect the special mbr from being overwritten accidentally. Yet the stealth self protection is active only when booted with the driver in memory. There are several possibilities to circumvent the protection. There are several good reasons why to avoid the use of the special boot drivers. It takes 4 kbyte off the conventional 640 K memory. Since the driver loads first, before the memory manager, then there is no way to relocate it in high memory at a later stage. The hard drive cannot be accessed when booting from a plain DOS floppy, The special mbr and the driver are extremely vulnerable. They are overwritten by simple boot infectors, or even by attempting to remove such virus with the FDISK/MBR command. Disaster recovery utilities do not exist to recover the special driver in case of damage. The re-installation of the driver destroys all data already on the drive by wiping the FAT and the root directory clean. Simple and careless manipulation may end in the loss of the disk content. The following are DO and DON'T DO if you use one of the special boot drivers: Do NOT run FDISK/MBR on the drive, as it will overwrite the special bootstrap loader with a plain one. The disk will not boot anymore by itself. Yet it can still be accessed from a floppy containing the driver in the config.sys. Do NOT install mbr immunization to such drive, for the same reason as above. Do NOT install an access control or security system that writes anything to the mbr, to the boot sector, or to track 0. Most such systems do just that! You will be locked out of your system, for good! Common disaster recovery (rescue) programs do not work properly with the Disk Manager boot driver. As track 0 is stealthed then the rescue utility will backup the wrong data. A rescue floppy prepared by such utility is worse than not having one at all, since it will `restore' wrong information to the drive, for _sure._ Do not forget floppies in your drive A. Such floppy, if infected with quite simple boot/mbr infectors may cause loss of self booting capability, or the total loss of access to the hard drive! If you have two IDE hard drives, and no LBA is available in the setup then make the large IDE drive number 2. It will be safer against most mbr infectors, immune to FDISK/MBR, and safe from immunization. :-) Install InVircible and prepare its rescue diskette. Starting from version 6.01D, InVircible's rescue disk procedure contains special features for these drives. The most important is `Seeing Through' the Ontrack stealthing of the boot loader and the backup of the true content of track zero. The following is how to recover access to a large capacity IDE, if self booting or access were lost: Damage to the system files: Insert a bootable floppy in drive A, with the same version and OS as installed on the hd. Start the computer and press the space bar when prompted to boot from a floppy. When DOS is up, issue the command SYS C: In case the mbr or one of the driver's sectors was overwritten by a virus. If you prepared an InVircible rescue diskette, then boot from the floppy and it will automatically enter the ResQdisk program. Press ^Z and select "Restore" of track 0. If you didn't prepare an IV rescue disk, then first prepare a boot floppy with the FORMAT drive: /S command. Copy the drivers to the floppy (in Disk Manager's case copy DMDRVR.BIN and XBIOS.OVL from the DM 6.03 distribution diskette and edit A:CONFIG.SYS. Write a line containing DEVICE=DMDRVR.BIN in the config. Boot from the floppy just prepared and see if you can access the drive. If yes then run MIRROR C: . Now reinstall the special driver from its distribution diskette, preferably in the manual mode (DM/M). If lucky, and the damage is not too severe, you may even spare yourself the next step. You will get a warning message that all data on the drive will be lost. Proceed anyway! Now boot from the floppy once more and run UNFORMAT C:. That should do the trick. Appendix C. - IVX advanced options. This appendix is for the advanced user, computer security experts and system administrators. IVX, the hyper-correlator of InVircible, can be used in one of the following modes: - As a statistical correlator, to detect statistical similarities between files. - As a signature extractor, for establishing a scan signature from an infected sample. - As a scanner, from a signatures library. - For searching a text string in files. - As a signature scanner, from a user defined signature. All modes can be entered from the interactive dialogue menu. Only the statistical mode can be entered directly from the command line. The statistical correlator. This mode is started by designating an infected file to compare to. If there exist a ViruSample, Vir-Code or both, then IVX will pick them automatically for sampling, in the "Auto" mode. IVX will analyze the sample file and establish its correlation parameters in three categories: structure, crypto model and signature. IVX extracts a signature from the sample file, where possible. The signature is automatically added to the IVX.LOG file, in the IVX directory. The statistical mode is detailed in section 7, The Correlation Scanner. Extracting signatures. Finding a good signature needs common sense, patience and experience. Yet, it's not always possible to find a valid signature for every virus. With some viruses, IVX will extract a valid signature on the first run, others may need the user intervention. The following are valid signatures, extracted automatically by IVX, as stored in IVX.LOG, on the author's hard drive. BB8513E3262CAEA8B892 ; E:\F_VIR\CAIBUA.COM Big Caibua 8BCC0EFA178BE78EC08D ; E:\F_VIR\DIE_HARD.EXE Die Hard 378B0E4B8B053CD5043D ; E:\F_VIR\FRODO.COM Frodo, 100 Years 072E8E1645002E8B2643 ; E:\F_VIR\FRIDAY13.COM Jerusalem.1808, Standard Each line contains a single signature, made of ten bytes (in hex notation), then a ';' mandatory separator, and a description. IVX will write the full pathname of the sample file as description. In the above, it's obvious that the sample are all from the file viruses directory on the author's drive. The last entry in each line (the name of the virus) was added with a text editor. Free text is allowed past the ';' separator, as IVX will ignore anything to its right. To decide whether a signature is good, simply scan for that signature through several infected files. If IVX finds the signature in all, then the signature is good. There are instances when a signature extracted from an infected COM sample is not found in EXE files, and vice versa. Sometimes, the signature taken from the EXE sample is good for both, or the one from the COM sample is good for both. There is one way to find out: Trial and error. It's possible that you'll need two signatures for the same virus, one for EXE, another for COM files. There are instances when 'wildcards' may be needed. Suppose we found an exotic new virus and when correlated for in the statistical mode, no match is found for a signature. Yet, when looking in the log file we may see that the signatures 'almost' match, except for a few bytes that change value in the different signatures. You may then replace these bytes by a '??' wildcard. IVX will ignore the byte at the specific position. Let's look at an example. Suppose we obtained signatures for the following samples, all from the Exotic virus infections: 8BFF0EFA178BE78EC08D ; SAMPLE-1.COM 8BCC0EFA178BE7FFC08D ; SAMPLE-2.EXE 8BCC0EFA178BE78EC08D ; SAMPLE-3.COM 8BFF0EFA178BE7FFC08D ; SAMPLE-5.EXE A good signature for the Exotic virus will look as follows, with bytes 2 and 8 replaced with the ?? wildcard. The same can be used when adopting user defined signatures from other than IVX sources. 8B??0EFA178BE7??C08D ; Exotic virus signature. Using the Signature mode. User defined signatures can be entered in three different ways: - As an existing IVX signature, from the IVX.LOG library, or by adding a new, or editing an existing signature in the library. - As an ASCII string, from the keyboard. The search for ASCII is case sensitive and looks for a perfect match. - As an hex signature, from the keyboard. Wildcards are allowed. Start IVX, select the 'Signature' mode and IVX will prompt for one of the above. Pressing 'A' will start the ASCII entry mode, 'H' will start the hex entry mode, and Enter will open the LOG file for browsing and selection. The 'Signature' mode can be used in a staggered scan strategy. The probability of an occasional occurrence of the same signature with 10 valid bytes is fairly low. Even six valid bytes still provide a fair margin against false alarms. Therefore, the signature scan mode of IVX can use sometimes for the final scan, to eliminate the 'noise' that may exist in the statistical mode. For that purpose, a good signature should be extracted first through the statistical mode, and validated as explained. Then the final run is executed in 'signature' mode, with 100% match and no false positives. Using IVX for virus alert. A common user with no background in virus or antivirus matters, when hit by a new virus, like Big Caibua (April 1995), can issue a virus alert on the net within minutes. After he/she confirmed the validity of the signature, of course. The message should contain the signature extracted by IVX, as found in the IVX.LOG file. Conversely, all users of InVircible (or IVX) can add the signature to their IVX.LOG file and scan for the new virus through their programs. IVX can also be used as a signature scanner for user defined signatures obtained from other sources. There is no limitation on the number of signatures that can be stored in the IVX.LOG file, except your patience for browsing till you find the right one.