InVircible - User's Guide and Installation Instructions Copyright (C) 1990-1995 NetZ Computing Ltd Table of Contents I. Licensing Agreement II. Preface III. Quick Start Instructions IV. Using InVircible V. Suggested Protection Routine 1. Introduction 1.1 What Are Computer Viruses? 1.2 InVircible's Main Features 2. The Rescue Diskette 2.1 Preparation of the Rescue Diskette0 2.2 Customizing Your ResQdiskette 2.3 When Should You Renew The ResQdiskette? 3. Using the Main Menu (IVMENU) 3.1 IVMENU Special Keys 3.2 The IVMENU Caution Panel 3.3 Browsing Through 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 Windows NT, Windows 95 and OS/2 Environment 5.5 In Unattended Installations (BBS) 6. IVB - The Integrity Expert System 6.1 The Extra-Security Feature 6.2 Off-line Backup of the Database-Files-Tree 6.3 Excluding and Including Files from IVB's Checklist 6.4 The IVB.INI file 7. IVX - The Correlation Scanner 8. ResQdisk - The Disaster Recovery Tool 8.1 Reconstruction of the Boot Bloc 8.2 Regaining Access to an "Invalid Drive" 8.3 ResQdisk's Setup Utility 8.4 ResQdisk Professional 9. IVSCAN - The Virus Detection and Removal Scanner 9.1 Removing Generic Boot Viruses from Floppies 10. A Primer to Generic Anti-virus Methods 10.1 Virus Symptoms 10.2 How to Proceed in Case a Virus is Found in the Computer 10.3 Gathering Information on the Virus 10.4 How to Recover an Infected Computer 10.5 Advanced Virus Analysis Methods 10.6 Virus-Cooperative Integrity recovery 10.7 Virus-Cooperative Piggybacking (Retro-Piggybacking) 10.8 Virus-Cooperative (SeeThru) Boot Bloc Recovery 10.9 Removing Stealth Boot infectors from SCSI and MFM disks 10.10 Removing Boot Viruses from Floppies 10.11 Disaster Recovery - Regaining Access to a Hard Drive 10.12 Handling Cluster Infectors 10.13 Screening New Software 10.14 Common Problems, How to Handle Them 11. InVircible, Windows and OS/2 12. CPAV's Inoculation 13. InVircible and Memory Resident Anti-Virus (TSR) 14. Practicing Antivirus Strategies, The AV Practice Lab (AVPL) 15. Troubleshooting 16. Upgrading and Support Appendices A. Appendix A. - A Primer to Integrated Anti-virus B. Appendix B. - LAN Protection C. Appendix C. - Large Capacity IDE D. Appendix D. - IVX Advanced Options E. Appendix E. - Switches and Command Line Options F. Appendix F. - Glossary I. Licensing Agreement InVircible, ResQdisk and ResQpro (tm) are trademarks and copyright (c) 1990-95 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 or use of this software package, or part of, 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 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. Site License Certificate: The Purchaser of a Site License will be issued a License Certificate by NetZ Computing. The holder of the Certificate is entitled to free upgrades of IV during the License Term, as well as hotline support through a NetZ Authorized Agent. The possession of the NetZ License Certificate constitutes the sole proof of a genuine and legally acquired Site License. Alteration or reverse-engineering of the programs is not authorized, such attempts terminate this license agreement and may result in unpredictable damage and may have irreversible effects. 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. Disclaimer: In no event shall NetZ Computing Ltd., nor its Agents, 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. II. 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 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 online 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 review the manual in detail later. InVircible's basic features, the integrity module, the correlation scanner, the virus scanner and the ResQdisk tools 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 on 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 fail-safe and layered approach to protection from computer viruses. The first layer are the InVircible automatic detection and recovery features, embedded in IVINIT and IVB, which provides InVircible with extreme resistance to being bypassed or attacked by viruses. The second layer is IVB, the integrity analyzer and restorer that secures your files, detects and eradicates new viruses (especially the so-called "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 new--unknown viruses. In support of the above are: IVTEST, a probe that checks for viral activity in real time, and ResQdisk, an advanced tool for inspecting and recovering the critical boot sectors and configuration data of your hard disk. InVircible programs attempt recover themselves, successfully in most cases, if they become infected, from stealthy viruses too. InVircible does not allow a "fast infector" virus to "piggyback" its scanners and to infect an entire hard disk drive. InVircible utilize efficient virus activity probes, embedded in all its modules, instead of a memory resident (TSR) scanner or behavior blocker. InVircible allows you to automatically recover from many boot virus attacks or you may prefer to manually guide the recovery. III. Quick Start Instructions Insert the distribution floppy into drive A: or B: Run INSTALL/FAST from A: or from B: to start the quick installation procedure. The InVircible INSTALL first examines your system for viral activity and checks for boot and file infections of the hard drives. After these initial tests, InVircible then installs itself on your system to a default directory. Next, all files on hard disk drive partitions will be "secured" by IVB. 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 probe, is activated when you invoke a frequently used batch (BAT) file. Important: Preparation of a Rescue Diskette is critical for effective recovery from boot bloc and complex viral attacks. The preparation is needed before a virus infection may occur. IV. 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 module. Choose the Virus Scanner option to activate IVSCAN. The F1 key provides access to the 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 or directory to examine and whether to "validate", "secure", or "restore" files. When selecting IVSCAN, you choose the drive to scan and directory 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. V. Suggested Protection Routine IVINIT will check on any initialization of the computer that the boot bloc and operating system are intact. IVINIT will also remove boot viruses (in licensed mode only), after prompting the user. IVB will automatically run a DAILY check of your binary-executable files in the local partitions on the installed hard drives. CD-ROM drives are excluded from the DAILY check as there is no point in verifying them. 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 binary-executable files. Some changes in programs are expected if you generate your own applications, or replace a program's older version with a new one and the 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. An existing signatures file will be backed up when renewing the signatures file, thus you may step back in case it was a virus infection after all. 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. It's good practice to screen newly acquired software with an up-to-date on demand scanner. Screening by a scanner need to be run just once, before installing the software to your hard drive or to a file server. Ongoing real-time protection and recovery is provided by IV's probes and tools. It's worth scanning new software floppies with IVSCAN, it may detect generic and boot infectors that passed through the screening process. After installing new software to the hard disk, run IVB to secure the newly added executable file. Application programs do not change normally unless they have been upgraded. 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's 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. In most cases it is not a virus doing! When a genuine infection is found, then boot from the clean rescue diskette and first assess the full extent of the infection, before taking any corrective actions. IVB should be preferred whenever possible for removing viruses from files, provided the programs were secured before becoming infected. Only if no signatures exist, and the virus is known to IVSCAN, or to the third party on-demand scanner, then you may use the scanner to disinfect the programs. New viruses, unknown to IVSCAN or to the third party scanner, can still be found using IVX, and be renamed so that they will not constitute a viral threat. The renamed files can then be replaced from backup. 1. Introduction. 1.1. What are Computer Viruses? Computer viruses are computer code written by real, human 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 host's execution, either if it is just a boot sector or an executable file. Computer viruses are passed the same ways we obtain software; by sharing software with friends, downloading from BBS, with newly purchased PC and hard disks, in vacuum wrapped new software, and even on preformatted floppies. 1.1.1 Categories of Computer Virus Generally, there are two virus categories: - Viruses that infect through the boot sector or partition sector (MBR), or 'boot infectors'; - Viruses that infect through programs, or 'file infectors'; All encountered viruses fall into one of the above two categories or both. There are also bipartite or multipartite viruses that combine the properties of the two categories (boot and file). Examples of multipartite are Junkie and Natas, while Tequila is a bipartite as it does not infects the boot sector of floppies, just the mbr and EXE files. In late 1991, a new variant of file viruses emerged. It manipulates the file allocation table (FAT) pointers through the directory entries in order to spread. We will call them 'cluster infectors'. A last type are the 'companion viruses', these are a variant on the file infector. A companion virus takes advantage of the properties of the operating system by spawning a companion to the victim program. Below is a quick definition of terms that are used to describe viruses and techniques employed by viruses: 1.1.2 File Infectors. A file infector attacks executable program files, usually those having a COM or EXE extension name. Sometimes also files having the structure of an executable are targeted by viruses, regardless of their extension name. File infectors may corrupt non-executable files as well but they cannot spread this way. 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 in an infected file until the program 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 contained in these special sectors, first the partition bootstrap and then the system bootstrap, 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 put in the floppies' drive. 1.1.3 Multipartite Viruses (boot and file infectors) Multipartite viruses infect both executable files and boot-partition sectors, sometimes the boot sector on floppies too. Some multipartite become infectious only after rebooting the computer from the infected mbr, like Tequila, others are equally infectious if loaded from file or through the boot process. 1.1.4 Cluster infectors (file infectors). The cluster infectors are basically file infectors, with a unique infection mechanism. Cluster infectors 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, by manipulating pointers in the directory entry. Two well known such viruses are DIR_II and 1963 (Necropolis). DIR_II is almost extinct as it does not survive in DOS 5 and higher environment. Cluster infectors are also excellent piggybackers. 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 or actually remove themselves from the file, to reinfect it again when the inspection is over. 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 kbyte in length) to the file size. Stealth viruses are categorized as 'full stealth' and 'semi stealth'. The difference is explained later. Some boot viruses use stealth (spoofing) techniques too. Stealth boot viruses will deceit disk editing tools, except ResQdisk. Example of stealth boot viruses are Monkey, AntiEXE and B1-NYB. Natas and Gingerbread Man are multipartite viruses that use boot stealth 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 difficulties for anti-virus scanners, because they cannot look for a known virus signature. Polymorphic viruses have forced scanners to use methods based on heuristics, which increased their false alarm rate and rendered scanning more difficult. 1.1.5.4 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. InVircible's Main Features * It handles both known and unknown computer viruses. * It is extremely fast, professional and easy to operate; * It does not require frequent and 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 LAN (Local Area Networks). * Has an indispensable toolbox for computer security experts and advanced users. * Has generic procedures for full recovery from Dir-2 and 1963. * Utilizes sabotage-resistant protection designed to avoid both human- and virus-based deception. * Is piggybacking resistant to prevent InVircible from becoming a virus carrier. * Has extensive context-sensitive hypertext on-line help; and * Is financially affordable; 2. The Rescue Diskette. A Rescue Diskette is essential to disaster recovery and effective virus protection. The `1IV ResQdiskette is one of IV's strongest features. 2.1 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, its track zero, the CMOS settings, as well as the recovery of files (with the licensed version) in case of infection. 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. Disk Manager v6.03+), 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. Users of special boot drivers such as Ontrack's DM v6.03 for large capacity E-IDE are advised to read appendix B. 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. 2.2 Customizing Your ResQdiskette. You may add utilities such as your favorite ASCII editor, special drivers and configuration files to your ResQdiskette. IV will take care of Stacker and DoubleSpace disk compression. Other drivers should be added manually by the user. Format a floppy in drive A, copy the drivers and utilities you need to A:, and edit a:\config.sys and a:\autoexec.bat, if needed. IV's rescue disk procedure will edit it's commands into your startup files without erasing them. Start INSTALL /R and answer "No" when the program prompts if to erase the existing data. 2.3 When Should You Renew The ResQdiskette? The Rescue Diskette contains the PC's 'personal' data: a copy of the installed operating system, partition and boot sector images, a copy of track zero and the CMOS setup parameters. Whenever one of these is changed, such as when changing a DOS version, or modifying the disk partition, then renew then the ResQdiskette. It is recommended that you renew the ResQdiskette when upgrading InVircible. There is no need to renew the rescue diskette when new directories or programs are added on the disk. This is taken care of with the DAILY inspection of IVB. WARNING: The Rescue Diskette is unique for a specific hard disk. 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 bloc 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 preset 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 kbyte 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 Sentry-licensed mode status and will indicate "licensed" or "detection only". The empty field at the bottom is reserved for warning messages. 3.3 Browsing Through 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 H 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 be redirected to the printer through 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 C:\IV 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 License Installation/Removal sub-menu. Enables either the installation or removal of the InVircible license to/from the hard drive. This option is available only if you possess the original distribution diskette. The process is reversible. 4.2 Installation To or From LAN Server. InVircible is a universal anti-virus, recommended for both single user PC 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. If you prefer working in the Sentry mode then do not install the license record to workstations. 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. You can use IVLOGIN with the following command line options. The /RANDOM switch will set a random IVB signatures filename for each new installation. If you prefer a predefined signatures filename then use SIG=your_filename. No spaces are allowed in the last command. Using IVLOGIN plain will install with the default signature filename. 4.3 Installation under OS/2, Windows NT and Windows 95. The InVircible INSTALL procedure must be run from a plain DOS environment. If INSTALL is attempted from another environment then 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 in both IVMENU's Caution Panel and in the upper left corner of the program's panel. 5. Recommended Anti-Virus Strategy Effective anti-virus protection starts with the installation of InVircible on a clean computer. If found infected during first time installation, then first disinfect as explained elsewhere and install IV when clean. Once installed, IV detects viral deviations from the clean initial state and let restore programs and boot sectors to their pre-infected state. 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 for 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. 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 initialization 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. The IVB daily check will skip Read Only drives (CD ROM). Network and remote drives are not checked by the daily command. 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. The latter is recommended since its complementary command, UNFORMAT, is contained in DOS versions higher than 5 and the UNFORMAT program is backed up on IV's rescue diskette. Run MIRROR from the last line of your AUTOEXEC, before loading Windows, if you do. The InVircible system uses a non-TSR virus-activity probe and sampler, called IVTEST. Anti-viral TSR are limited only to known viruses, and they may be obtrusive at times, yet, 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 workstations that have a local hard drive. 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. For more details on how to protect a network read in appendix A. 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 copy. 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 viruses. 5.4 In Windows NT, Windows 95 and OS/2 environment. Non-DOS operating systems are inherently immune to DOS viruses. File infectors do not survive in the non-DOS environment. Although DOS programs can run in them in either a DOS Box or in full screen virtual DOS, these environment are not compatible enough for virus operation. The major threat from viruses to systems using Windows NT, Windows 95 and OS/2 is from dumb boot sector viruses, and the incidental infection of the hard disk with one of these viruses. Boot infectors are the most prevalent type of in the DOS environment, 50 to 70 percent of all reported incidents, although their percentage of the total number of viruses hardly exceeds 10 percent. Boot infectors will be around for as long as DOS is still used. Floppies will get infected by them and these floppies may find their way into the boot drive of NT servers, or computers using OS/2 or Windows 95. Boot viruses do not spread further from an 'infected' computer that runs under a non-DOS operating system. Some of these boot infectors have no effect on their host machines, others may prevent them from starting. The remedy to this problem is the InVircible rescue diskette. It will let to remove a boot virus from the hard disk and restore the system to operational status. Users tend to cheat themselves that boot viruses can always be removed after they struck, since these viruses are "known" to most anti-virus producers. The DA'BOYS, or FORM viruses for example do not keep a copy of the original uninfected boot sectors anywhere. No anti-virus can help recover a non-DOS disk from these simple boot infector. If you won't take precautions before struck, by preparing a rescue diskette, then it might be quite difficult, or impossible, to recover your hard drive after being hit. A rescue diskette is all it takes for gaining peace of mind from such eventuality. To prepare a rescue diskette for a non-DOS system proceed as follows. Format a DOS bootable floppy on a DOS machine. Copy RESQDISK.EXE to the floppy. Boot the non-DOS machine from that floppy and run the following from the A: drive: RESQDISK /B RESQDISK /Z/B These commands will create images of the mbr, the boot sector, the CMOS data and a copy of track zero, head zero. Windows 95 can be restarted in a full DOS session. Restart in DOS, install InVircible and prepare its rescue diskette. Now restart back into Win 95. Do not undertake anti-virus corrective maintenance, especially not of the boot bloc, when in a Windows session, nor when in a Windows DOS shell. Always exit Windows completely, or restart to full DOS before undertaking anti-virus corrective measures, especially of the hard disk. 5.5 In Unattended Installations (e.g. 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 For the user interested in more details, we recommend to read appendix A, a primer to Integrated Anti-virus. 6. IVB - The Integrity Expert System. IVB will secure, authenticate and restore executable programs from virus infection and virus-like modifications, except for cluster infectors (see Section 10). IVB takes a "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, when licensed, restores programs that have been secured. Prior to restoring files with IVB, scan with IVSCAN (after booting from the rescue diskette or from a clean DOS floppy) to discard the possibility of a known type. 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 cannot be restored, such as overwritten or ruined by a Trojan or virus. The [-] switch (space followed by a hyphen) indicates to IVB to operate on the specified directory only without including the sub-directories. 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 detect and replace a tampered record of a particular file, rather than void the database. When renewing a database file, the current one is backed up with the extension name '.000' and the backup is given a read-only attribute. This should let to recover from an erroneous replacement of the database file, should this happen. IVB processes executable files only. Files with the following extensions are processed automatically by IVB: BIN, COM, EXE, OV?, SYS, NLM, VLM, 386 and VXD. IVB has provisions for adding up to five (5) file types to its processing list. See in paragraph 6.4 how to do this. Before attempting the recovery of a file by IVB you will be prompted with three options: Restore, Skip or All (attempt to restore all). 6.1 The IVB Extra-Security Feature. IVB has extra security features 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 meg disk partition will require about 200 Kilobytes of space for an off-line InVircible backup. An off-line backup for a typical 1 Gbytes file server can be contained on a single 1.44 Mbytes diskette. 6.3 Excluding files from IVB's spec. There are instances where a secured file may change for non-viral reasons. You may then wish to exclude that file from IVB's list, without giving up the processing of other files with the same extension name. An example for such file is RANDSEED.BIN, a random seed sequence, used by the well known PGP program (Pretty Good Privacy), by Phil Zimmerman. See next how to do this. 6.4 The IVB.INI file. IVB.INI is a text file that contains parameters to initialize the IVB program. The file should reside in the same directory as IVB.EXE. IVB.INI can be edited with an ASCII editor. The following are the various entries allowed in the INI file: Signature file name: To set a signature filename other than the default, write a line as follows: SIG=filename. Only one such item is allowed in IVB.INI. Include list: To include a specific file type in IVB's specification list, add a line as follows: INCL=*.XYZ . DOS wildcards (*,?) are accepted in this entry. Up to five include specs are allowed in IVB.INI. Exception list: To exclude a file from being processed by IVB, add a line containing the following: SKIP=filename. Do not specify a full pathname, just the filename (up to 12 characters). Wildcards are not allowed in this entry and you may specify up to five (5) filenames that IVB should ignore. 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 bar-graph format, when 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, EXE to IVE, BIN to IVB etc. 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 detection threshold is set to 20%. 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: ²²--Structure, ±±--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 structure 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. For additional information on the correlation scanner and advanced methods for using IVX, see appendix D. 8. ResQdisk - The Disaster Recovery Tool. ResQdisk is a compact yet useful 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 the hard disk, if access was lost because of damage to boot data (messed CMOS data or damaged mbr-boot sector). ResQdisk deals uniquely with hard disks drives, not with floppies, uniquely prepared and configured with FDISK, under DOS. DOS disks are organized in sectors, which are 512 bytes data storage units. Any DOS hard drive has two, sometimes more, such vital sectors: the master boot sector (sometimes referred to as the partition table) and the system 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 zeroed sector will return an "invalid drive specification" message, fail to boot, deny access to the hard drive or simply read trash from the disk, depending on the kind of damage to the sector. 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. The user is encouraged to browse their hard drive with ResQdisk trough the various options. Every hard disk has a unique configuration of the boot sectors. 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. Navigating with ResQdisk. The direction keys can be used to navigate ResQdisk to the various configuration sectors of your hard disk(s). The content of the sector is displayed in the window, in black on cyan background. Use the following keys to browse through the sectors: Home: Go to the master boot record (mbr) at sector 0,0,1. Page Down: Go to next partition sector, it there exist one. Left arrow: Go to the active boot sector. Right arrow: Go to next partition boot sector, if there is one. Up & Down arrows: Browse trough sectors on track zero, head zero. Plus-Minus (ñ) keys: Change between hard drives 1 and 2. 8.1 Reconstruction of the Boot Bloc. 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, electrical surge, 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. 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/E-IDE 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. 8.4 ResQdisk Professional. Boot sectors Backup and Restore. Sector can be individually backed up or restored. To backup or restore a sector, go to the sector with the navigation keys and press "B" for backup or "R" for restore. IV's rescue diskette contains a backup for each critical sector. Edit functions (^E, E): Ctrl/Alt+E will open the editing menu. The currently displayed sector can be loaded to the clipboard and rewritten to another location. In addition to read and write, there are options to read a sector from file, to write a sector to file and to decrypt an encrypted sector. The latter is especially useful to recover from the Monkey virus. Analyze functions (^A, A): Ctrl/Alt+A will open the analyze menu. The displayed sector can be analyzed as a partition one or as a system boot sector. Boot sector functions (^B, B): There are instances where it is preferred to use DOS interrupts to access the system boot sector, rather than BIOS interrupt 13h. Such is the case when you need handle the boot sector of a Disk Manager partition. The ^B menu has the same options as ^E, but uses DOS instead of BIOS. The SYS option has the equivalent effect of a SYS C: command, on the boot sector, but without transferring the system files. Track zero menu (^Z, Z): The whole track zero, head zero can be backed, restored, or compared with the ^Z menu. The Ctrl+function keys. The Ctrl+function menu is displayed when pressing the slash "/" key. The following options are available under Ctrl+function: ^F1 Force a new master boot record (mbr), recalculated from the standard Dos boot sector found in sector 1,0,1. ResQdisk will use the PART.NTZ image file instead, if it exists. ^F1 will assume a SINGLE partition existed on the hard drive, unless there exists a PART.NTZ image with several partitions data. For disks with multiple partitions see ^F4, below. This function requires that the copy of IV is registered. ^F2 Force a new active system boot sector, recalculated from the master boot record data. ResQdisk will use the BOOT.NTZ image file instead, if it exists. This function requires that the copy of IV is registered. ^F3 Restore CMOS setup data. ResQdisk will use the data stored in the CMOS.NTZ file if it exist. Otherwise ResQdisk will do nothing. ^F4 Scan the entire disk for additional partitions and rebuild the mbr accordingly. This option is available only to registered users that purchased the Pro version (ResQpro) of InVircible. The ResQpro function, ^F4, can be enabled for a single on-line session by IV support agents. See ^F10 next. ^F10 Password to enable ResQdisk in Pro mode for a single session. Users in need can contact an authorized IV agent for online assistance. The agent can enable ResQdisk features for the current session and guide the user to help him regain access to the hard drive. The password is accessed by pressing ^F10. Read the password to the agent and he will respond with a matching one that will enable ResQdisk. IMPORTANT! The recovery features of ResQdisk suit hard disks prepared for DOS uniquely and configured with FDISK. Disaster recovery considerations are a good reason to avoid non-standard configuration schemes and access control that modify the boot sectors in any way. 9. IVSCAN - The Virus Detection and Removal Scanner. IVSCAN is a minimum virus scanner, with generic features added. IVSCAN is in no way a substitute for an up-to-date virus scanner. If you feel you need one for screening new software, or for disinfecting a machine before first installing InVircible to it, then we recommend that you look for one of the many shareware or commercial scanners available on BBS, from anonymous ftp sites, Compuserve and on the Internet. As a general rule, integrity restoration by IVB is superior to disinfection by IVSCAN, or by other scanners, since integrity restoration is not sensitive to the proper identification of the virus. Scanner, IVSCAN included, may misidentify a virus strain for another or can be fooled into "finding" one virus while it is another. The disinfection based on such error will usually result in the ruining of the program and it may take a long time until you spot and replace all the corrupted files. In addition, many viruses add 1 to 15 bytes of junk code that are not removed by scanners. While not causing any problem in most cases, there are programs that check their self integrity and will stop functioning if not restored to the byte. IVB will do that better than IVSCAN. 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 performed 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. retro-piggybacking). Detection of, and disinfection from 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 its 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 (disinfect 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. Just type: IVSCAN drive: /B IV contains a complimentary program, FIXBOOT, for bulk cleaning of the boot sector of floppy disks. FixBoot will install a generic clean boot sector to a diskette, in drive A or B. FixBoot can be used to prepare a clean bootable floppy, when the hard drive is infected with a boot infector. Insert a formatted floppy in the drive, transfer the system files with the DOS command SYS A: (or B:) and finally run FIXBOOT A: (or B:). Remove the floppy from the drive without attempting anything else, not even a DIR command, and write protect the floppy. The above technique usually works even in the presence of stealth viruses such as Monkey. 10. A Primer to Generic Anti-virus Methods. Generic techniques can cure damage from groups of viruses such as boot bloc infectors, stealthy file infectors and cluster infectors. First, assess the type of infection by its symptoms, then test the selected method on a sample diskette or directory. If successful, then apply the selected technique onto the entire infected disk. 10.1 Virus Symptoms. Computer viruses always disclose there presence sooner or later. InVircible alerts the user when sensing various effects that can be related to computer viruses. Among InVircible's messages, the following are of special interest: (1) Missing memory. (2) A stealth virus found active. (3) Own's file size "changed by 0 (zero!) bytes" (4) Piggybacking or file killer detected. (5) "faked partition (or boot) sector". (6) "Boot infector detected". 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 uses a few kbytes kernel in RAM, or certain BIOS use 1 kbyte of RAM when the machine was booted from a floppy, without being related to virus activity. Message (2) or (3) indicate that a stealth virus is active in the system. These messages are generated by IV's baits or the self integrity check, respectively. Message (4) indicates that a piggybacking process was detected and the search should be halted to prevent further spreading of the virus. This message is generated by the either one of IV's scanning programs, IVB, IVX and IVSCAN. Message (5) indicates the presence of a stealth virus in either the mbr or in the system boot sector. This message is issued by SeeThru, implemented in IVINIT, IVTEST and IVSCAN. Message (6) will be displayed when a boot infector is found in the mbr or the system boot sector of the hard disk or of a floppy. This message and message (5) may sometimes be displayed both. 10.2 How to Proceed in Case a Virus is Found in the Computer It is recommended that inexperienced users ask for assistance or leave disinfection to qualified and trained personnel. Inadequate virus removal procedures can be incredibly more harmful than continuing working with a virus in the computer! In case of doubt, then LEAVE THE COMPUTER ON AND WORKING until help arrives, and don't continue working while the virus is still active. You next best choice is to first backup valuable data and then switch the computer off in an orderly manner. Do not backup programs as they may be infected, and do not switch the computer off before having backed up important data. Act as if you might not be able to access the data on the hard disk the next time you restart the computer. 10.3 Gathering Information on the Virus. It is important to collect as much as possible information on the attacking virus as it will let you make informed decisions of how to best recover from the attack. The following are a sequence of tests to conduct, that will help you finding the facts about the virus. A virus can be a boot infector (mbr and-or a boot sector infector), it can be a file infector, a companion virus and it can be both (a bipartite or multipartite). There is also the slim possibility that you are dealing with a cluster infector, but this possibility is so rare that you may ignore it, at least in the first stages of your investigation. First run the IVTEST probe a couple of times. It will indicate whether there is memory stealing, check for boot infection and boot stealth, ant try hook the virus with a series of different baits. Boot infectors will be sampled into a PARTVIR.NTZ or BOOTVIR.NTZ file. A memory resident virus will usually generate a VIRUSAM.PLE file and sometimes a VIR-CODE file too. The former is the result of a baiting process, the latter will result from the self-baiting of IV's modules. Be aware that viruses can be extremely deceitful. Virus writers are constantly studying the anti-virus products and they develop techniques to evade detection methods. There is a continuously ongoing battle between virus writers and anti-virus developers. You will find that not all detection methods work on every virus, and you should not expect they do. InVircible's generic detection is built with a fail-safe methodology, assuming that the capturing of virus activity by a single sensor suffices to alert the user. With sophisticated viruses this is all that you may get - a single alert, by a single sensor, that something is wrong. An alert should prompt a virus aware user to further assess the situation. You should always assume the probability of a multipartite infector, even if only boot infection was found, and you need to discard this possibility before proceeding to recovery. Negative results to launching IVTEST does not mean there isn't a file infector active. A low risk approach would be to boot from the rescue diskette and run IVB, the integrity checker, from the floppy, on all the hard drive's files. The pattern will become immediately evident in case a file infector, or a multipartite was active on the disk. It's also worth to explore the mbr and boot sector with RESQDISK (from the main menu) whether they have changed, by simply 'restoring' both sectors from backup and watching if anything changes in their presentation on the display. Be sure that you are using the right rescue disk before attempting the above, for the right computer, and that the rescue is up-to-date. Finally, run the correlator, IVX, to see if there are more infected files than the ones reported by IVB. Select one of the modified files, pointed by IVB as the sample to compare to. See in section 7 how to use IVX. The files found in high correlation with the sample and not contained in IVB's report, are the most likely to having brought the infection into the computer. It may be worth running IVSCAN, in case the virus is contained in IVSCAN's database. If you wish, and have an up-to-date scanner other than IV's, then you may learn the name of the virus, provided it has one, and it is contained in the scanner's database. At this point you got sufficient information to proceed on removing the virus. 10.4 How to Recover an Infected Computer. Occasional infections of the boot bloc are usually recovered by IVINIT, during initialization, when run from autoexec. IVINIT's recovery is especially effective against stealth boot infectors. IVINIT will usually prompt to reboot the computer after disinfecting from a boot infector. Rebooting is necessary to remove the virus from memory too. When no more boot infection is reported after restarting the computer, you then know that the disinfection was successful. It is good practice to check your floppies after a boot infector was removed from the hard drive, since write-enabled disks that went through the drive are now probably infected. The simplest would be to process floppies in bulk with FIXBOOT. The latter will place a clean boot sector on floppies, regardless of whether they are infected or not. Not all boot infections are obvious. In case of a boot infection of the hard drive was found and IVINIT did not remove the virus: Boot from the rescue diskette and restore the mbr and boot sector from their image files by pressing F1 then F3, when in ResQdisk. File infectors are usually removed by IVB, after booting from the rescue diskette. First, run IVB in the default mode (check only) on the affected drive and assess the extent of the infection. Watch that all "changed" files follow the same pattern, i.e. their size increased by about the same number of bytes. Next, run the correlator, IVX, using one of the infected files as the reference sample. Establish the parameters for the best scan and watch the number of correlating files found. Usually, IVX will find more affected files than IVB. Save a copy of the infected sample on a floppy, you will need it later. Next run IVB in the restore mode (/R). Select between file by file or automatic recovery ("recover all" option) depending on the pattern of the changes. Finally, repeat the IVX correlation scan, this time by using the saved sample, from above. This time only the infected files that had no pre-infected signature will show up. You can use the "Rename" or "Erase" option to neutralize these files. The last step will provide a good idea of the source of infection of this particular computer, or file server. Renamed or erased files can be replaced from clean originals or backup. Use IVX, with the saved sample as reference, for the presence of the infector. Infected samples can be sent by e-mail or on floppy to NetZ Computing, for analysis. See in the on-line help for NetZ addresses. 10.5 Advanced Virus Analysis Methods. This section is written for advanced users and security experts only. Inexperienced users are advised to ask for assistance in case they believe they need to use the following methods. Full stealth viruses can be cleaned and removed from files by virus cooperative methods. Therefore, it is important to determine whether a virus is a full stealth one or only semi stealth. A virus is considered "full stealth" if the infected files exhibit no changes when inspected while the virus active in memory. The following is how to test this. Preferably run the tests on a dedicated test machine, or on a floppy, with the hard disk set to "not installed" in the setup. First, initialize new integrity signatures of the control group files with the IVB /S command. Next, infect the programs by whatever infection algorithm the virus uses (direct action, piggybacking, execute program etc.). While the virus is still active in memory, check the files with IVB's default mode. Full stealth viruses will report nothing, while semi-stealth viruses will report "file was modified, no change in size". 10.6 Virus-Cooperative Integrity Recovery. Full stealth viruses, except cluster infectors, can be fully recovered through virus cooperative methods. The most straightforward one is integrity recovery. This method takes advantage of the virus properties itself. Before applying this technique to large number of files, test it first on a control group and if successful, apply it on the affected directories and drives. Always prefer operating on selected directories rather than on whole drives or volumes. With the virus active in memory, secure the affected directory or drive with the command: IVB /S [pathname]. Activating the virus can be achieved by deliberately running an infected program. When done, reboot from the rescue diskette or from clean DOS and restore all files with the command IVB /R [pathname]. Do not use the same copy of IVB.EXE that was used for securing, even if IVB indicated that it restored itself. Some viruses reinfect on 'closing' the file. Use a clean copy of IVB, from the rescue diskette, for example. Test a few restored files by executing the programs, to assure the recovery was good. The following are viruses that respond well to cooperative integrity restoration: All strains of Frodo (4096), Tremor, Natas, Die-Hard_2, Hemlock and more. Natas and Hemlock are multipartite and need cleaning of the mbr too. The mbr infection of Natas and Hemlock is stealth too and can be recovered with cooperative SeeThru. See next section for details. 10.7 Virus-Cooperative Piggybacking (Retro-Piggybacking). Cluster infectors cannot be recovered with the above method because of their peculiar infection mechanism. It consists of inserting the virus code in the file by manipulating pointers in the directory entries or in the FAT. There are actually just a couple of such viruses, DIR_II and Necropolis (1963), with a few strains of each. DIR_II is almost extinct as it cannot survive in a DOS 5 environment and higher. Necropolis is in the wild and is still common in many places. Many full stealth viruses, and cluster infectors in particular, can be disinfected by virus-cooperative or retro-piggybacking. The principle behind this method is the same as in integrity recovery, except that the disinfection is performed with the virus actually in memory. Cooperative piggybacking is embedded in IVSCAN and can be invoked from the command line only. Inverse piggybacking if used in the wrong circumstances can cause irreversible damage to infected files. Therefore this method is not available from IVMENU. Some full stealth viruses like Tremor, Natas and Frodo can be disinfected by either cooperative integrity or retro-piggybacking, others can be fixed only by one method or the other. The way to find out which method suits a particular virus is by trial and error. Before applying a method to a large number of files, always test first on a control group containing a limited number of infected files, or on a dedicated test machine. Retro-piggybacking is effective against full stealth viruses only. 10.7.1 Retro-piggybacking (RP), method 1 (/M1). Retro-piggybacking, method 1 is activated by running: IVSCAN /M1 [pathname] This method is effective against full stealth viruses of the file infector type and against Necropolis (1963 - a cluster infector). Before activating RP method 1, turn off all disk caching as disk caches have a counter effect on retro-piggybacking. The simplest is to bypass config.sys and autoexec.bat by either renaming them, or pressing F5 while booting, if you run under DOS 6 or higher. The virus must be active in memory when starting RP method 1. Apply method 1 selectively only to directories that contain infected files. When done, reboot the computer without executing any other command, since the virus is still active in memory and the end of the process. Retro-piggybacking, method 1 is a single pass process. The files will be clean after rebooting. Method 1 is invoked automatically when running IVSCAN /R, and Necropolis (1963) is found active in memory. 10.7.2 Change attributes, cleaning method 2. Some viruses, DIR_II specifically, remove themselves from system files. Cleaning method 2 takes advantage of this property by changing the files' attributes with the virus active in memory, and restoring the attributes to original when rebooted clean. Method 2 is virus- -cooperative and will function only when the virus is active in memory. To invoke method 2 run: IVSCAN /M2 [pathname] When done, reboot the computer immediately, as the virus is still active in memory. You will notice that all the executable files seem to have "disappeared". They are still there, but their attribute was changed to a hidden, and you can't see them with the DIR command, nor run them by invoking the program's name. To restore the attributes to original, run from a clean copy of IVSCAN: IVSCAN /M3 [pathname] Cleaning method 2 is invoked automatically when running IVSCAN /R, and the DIR_II virus is found active in memory. 10.8 Virus-Cooperative (SeeThru) Boot Bloc Recovery. The master boot record (sector) of the hard disk is a favorite target for viruses. Those that use stealth are especially easy to recover from by cooperative generic methods. Stealth boot infectors usually hook BIOS interrupt 13h, the one used to read and write to absolute disk sectors, in order to conceal their own presence. InVircible uses low level tunneling techniques that "see through" virus stealthing of interrupt 13h. SeeThru is widely used in InVircible for the detection of boot infectors and their disinfection. IVINIT will suggest the recovery of the mbr in case stealth infections of the mbr is detected. IVSCAN will prefer cooperative SeeThru for the recovery of a stealthed mbr and ResQdisk will permit the manual recovery of the a stealthed mbr, providing visual control of the process. Cooperative SeeThru is safer than using the undocumented FDISK/MBR command. The latter will install a standard bootstrap program in the mbr, overwriting the current one, while retaining the existing partition data in the sector. While this procedure may help in many cases to remove an mbr infector, it may in others cases cause loss of access to the hard drive or cause it loose self booting capability. The FDISK/MBR undocumented command should not be used in case of infection by an overwriting mbr infector (Monkey for example), or when a special boot driver (DM 6.03+, EZ-Drive) is used, with access control systems, Boot Manager, OS/2 partitions, Windows NT or with other than FDISK partitions. Instead, the method based on cooperative SeeThru will reinstate the original mbr. InVircible will capture the original mbr as returned by the virus stealth and will rewrite it to the physical location of the mbr, on the hard disk. IV's SeeThru functions only with IDE and E-IDE drives. With other drive types like SCSI and MFM, use the technique described later. Whenever a boot infector is suspected, then assume that all floppies that were used on that computer might be infected as well. After disinfecting the hard drive, process all floppies with FIXBOOT, the complimentary utility provided with InVircible. FixBoot will install a standard DOS 5 boot sector to the floppies. 10.9 Removing Stealth Boot Infectors from SCSI and MFM Disks. The problem with tunneling under DOS and BIOS to find INT 13h's original handler is that there is always a way to defeat it, no matter what method is used. DOS and BIOS interrupts are virus realm. Viruses cannot thwart low level hardware tunneling, yet IV's SeeThru does not work on all drive types. When SeeThru is unavailable, then a message "SeeThru OFF" will pop up when running IVINIT, IVSCAN or IVTEST. This should not concern you unless something else happens. Boot infectors, except few, disclose their presence by memory stealing. They will also usually relocate the original mbr or boot sector to elsewhere on track zero. Others will patch the mbr without storing a copy anywhere, but will write virus code elsewhere on track zero. Boot infectors that use stealth conceal just the faked mbr itself. These properties can be used for detecting stealth virus doing on the hard disk. It's especially useful on drive where SeeThru is not available. When installing InVircible to the hard disk, an image of track zero is stored to disk root directory, in a hidden file. Non-stealth boot infectors are detected by IVINIT when executing the autoexec. The presence of a stealth boot infector will usually be indicated by memory stealing, Qemm will not load, or Windows' 32 bit access driver will not load. Each one of the above symptoms should alert the user of the possibility that a stealth boot virus infected the disk. Run ResQdisk and visually inspect track zero for the traces of unusual code that wasn't there before. You may wish to compare the current content of track zero to the one at the time you installed IV. Run ResQdisk an press ^Z. When you select compare, then ResQdisk will scan through track zero and stop on every sector that was changed from the time the backup was made. Non-stealth viruses can be removed the generic way. The best is to find the original but relocated mbr on track zero and to rewrite it to sector 1. Before proceeding verify with the 'analyze' (^A) function that the sector contains correct data that fits the hard drive. The number of partitions should fit and the total number of sectors, multiplied by 512, should approximately equal the partition's capacity. Pick the selected sector with ResQdisk's 'cut and paste' (^E) and write it back to sector 0,0,1. When no copy of the original mbr or boot sector can be found, and there is no rescue diskette either, then you may have no other choice except refreshing the bootstrap program (this is the one that gets infected) with a generic one. Both sectors can be refreshed by positioning ResQdisk on the desired sector and pressing F1-F4 in sequence. The DOS boot sector can be refreshed from ResQdisk's ^B menu and selecting 'SYS'. To remove a stealth boot virus, boot clean from the rescue diskette, run ResQdisk (the rescue floppy default) and restore the mbr by pressing "R". See section 8 for reading how to use ResQdisk. In case there is no rescue diskette and the computer is infected by a stealth boot infector then format a floppy in drive A:, transfer the system files to the floppy with the command SYS A:, next copy the RESQDISK.EXE module to the floppy, log onto the floppy and run RESQDISK/B, to create backup images of the boot and mbr sectors on the floppy. Since the virus is stealth, then the image files are those of the clean sectors. Finally, run FIXBOOT A: and remove the floppy from drive A without running any other command. If you have access to a clean computer then AFTER having prepared the boot images on the floppy, run SYS A: on the clean machine, instead of running FIXBOOT. Boot from the clean floppy and run RESQDISK /R for automatic recovery, or you may recover the sectors one by one under the visual inspection of ResQdisk. The following are exceptions when NOT use the generic F1-F4 mbr refresh method. Do not use it in case access control password software is installed to the hard drive, that use encryption of the mbr. Neither use this method when the partition data was overwritten by a virus. A rule of thumb is this: Boot the disk from the rescue diskette or from clean DOS. If the hard drive is inaccessible, then don't use F1-F4. Note that you should not use FDISK/MBR either in these conditions, as their function is the same. 10.10 Removing Boot Viruses from Floppies. Unlike the disinfection of programs, floppies' boot sectors can be disinfected easily without knowing what virus infected them. IVSCAN can be used to inspect floppies and will alert on the presence of both known and generic boot infectors. If found, IVSCAN will announce "boot virus [name] was detected". Not in all cases there will be a name, depending on whether the virus is contained in IVSCAN's database. Since InVircible prefers generic methods, then having a virus name is the exception with IV. If interested in the virus name, then you may want to scan it with your favorite scanner. Cleaning floppies from boot viruses can be done by IVSCAN, one by one, or in bulk processing by FIXBOOT. When a boot infection of a hard disk is found, then it's most likely that floppies are infected too in the workplace. First disinfect the hard drive as inspecting from an infected computer will infects the floppies processed. IVSCAN /R [drive] will attempt to find the original boot sector and remove known and generic boot viruses. IVSCAN /B will force a boot sector replacement, either by finding the original sector or by installing a standard one. Both switches, /R and /B have a limitation: They are unable to clean a floppy having a closed loop infection. This situation occurs when both the boot sector and the relocated 'original' boot sector are infected. IVSCAN will then announce on an 'indefinite loop infection' and abort. This is where FIXBOOT can fix the problem. FixBoot installs a standard boot sector to floppies of the following capacity: 360 kb, 720 kb, 1.2 meg, 1.44 meg or 2.88 meg. FixBoot will sense the floppy's capacity and select the right boot sector for it. It will also retain the floppy's bootability on condition that it's a DOS floppy, from version 4 and higher and from either the MS-DOS or PC-DOS flavor. FixBoot is useful to restore readability to floppies that became inaccessible because of a boot infection. A 1.44 floppy that was infected by B1-NYB will seem as unformatted when read in a clean, uninfected machine. FIXBOOT /S will prompt you to select a capacity for the floppy and fix that problem. When replacing an infected boot sector, FixBoot will announce that it replaced an infected boot sector. And last, FixBoot will prompt if to process another floppy, saving a lot of time in bulk processing of large number of floppies. The files stored on floppies processed by FixBoot will not be altered or affected by Fixboot in any way. 10.11 Disaster Recovery - Regaining Access to a Hard Drive. Loosing access to data on a hard drive is a common and daily eventuality with personal computing. If not caused by hardware failure, then InVircible can help in regaining access to the hard drive. First thing to do after installing InVircible is to prepare a rescue diskette as explained in section 2. We assume that you also make regular backups of your important data. We also advise that you use a FAT mirroring program, right in your autoexec.bat. MIRROR from DOS 5 is recommended since its complementary program, UNFORMAT, is available in DOS 5+ versions, and is also copied to the InVircible rescue floppy. Viruses are the least common cause for loosing access to a hard drive. The most common one is the wiping out of the setup data stored in the CMOS chip. This may happen in result of a mis-manipulation of the computer, or from electrical surges, and sometimes even from buggy software. An exhausted battery can also cause the same. In other cases a damaged mbr or DOS boot sector can be the reason for loosing access to a partition. The latter can be caused by a bad manipulation of FDISK, the SYS command, buggy software and sometimes just by a virus. When one of the above occurs, then first thing find your IV rescue diskette. Before proceeding, think if the rescue disk is up-to-date and reflects the current configuration of your machine. A rescue diskette should be renewed with every change to your hardware configuration or setup, change to the partitioning of the hard disk, upgrade of the operating system, and upgrade of the version of InVircible. Boot from the rescue diskette (you may need to setup the drive A parameters in case the CMOS was wiped clean). IV will start in the ResQdisk default mode. In case the problem is the CMOS, ResQdisk will prompt to restore the CMOS data from backup and reboot the computer. A damaged mbr or boot sector can be restored from backup either individually, by selecting the sector and pressing (R)estore, or automatically with F1-F3. Do not use the ^F1 and ^F2 (forced recovery of the mbr and boot sector, respectively) unless you are sure that the rescue floppy is up-to-date and contains valid and current data of the computer you are using it on. Always recover the mbr first, as a messed up mbr may point to the wrong location for the boot sector. You may find after recovering the mbr that the boot sector is just fine, but was inaccessible because of a bad mbr. Regaining access to a hard drive without having an IV rescue diskette is also possible, yet it requires a licensed copy of InVircible, a bootable DOS floppy and a few DOS programs such as FDISK, CHKDSK and UNFORMAT. Start by verifying the CMOS setup data and look for hardware problems. Set the hard disk parameters in the setup to its correct type, if you know what it is, or select any type that will let the computer boot. Even if wrong, the disk type can be corrected later, just get the machine started. Boot from a floppy, start ResQdisk and watch for its messages. Press F5 to read the setup and the manufacturer's IDE parameters. If the data makes sense in both columns, then the problem is not a hardware one. If on the other hand the IDE data is erratic (provided the hard drive is an IDE or E-IDE) then there might be a hardware problem. Switch then the computer off, disconnect the power cord, open the computer, check the power connection to the hard disk, the flat cables from the controller to the hard disk and the controller card's connector to the motherboard. Too often it's just a matter of a loose contact. Close the computer, connect to power and try again. The 'setup calculator' panel of ResQdisk (accessed through F5) should show sensible data. The right column should contain non-zero data for IDE or E-IDE drives. If it's empty or shows 'not an IDE', then try reducing speed (switch turbo off, or press Alt+Ctrl+minus) and restart ResQdisk. If the IDE data is now visible then you are having hardware mismatch between the hard disk and the IDE controller. The controller is usually the problem, rather than the motherboard or the hard disk. Try changing the hard disk mode in the setup, this might solve the problem. Common setup problems are: LBA is used with small capacity and older drives (don't use LBA if not needed!), mode 3 or 32 bit mode is used with hardware that does not support these modes. It's also possible that the hard drive is simply too slow (and perhaps too old) for the new Pentium/120 mhz just acquired. Use the ResQdisk setup utility (F5) for finding the original disk's configuration parameters. The parameters in the setup and those of IDE disk manufacturer may differ. However, they should combine to the same disk capacity. An IDE drive that was configured and formatted with setup parameters that differ from the manufacturer's will function improperly if those parameters are not restored to the same as when configured. Fortunately, these parameters can be found with a little detective work and the help of ResQdisk. Look with ResQdisk for the boot sector. It should normally be accessed with the Left arrow key. If not there then you may find it elsewhere on track zero. Suppose you found the DOS boot record in sector 0,0,52. Press ^A to check its content and note the number of heads and the hidden sectors. The latter is usually equal to the number of sectors per track. In this case the number of sectors per track should be 51. Now go to the setup utility (F5), set the number of heads and sectors per track to those found in the boor sector, and change the number of cylinders until the number in the "capacity" field equals that of the manufacturer's. Write down the parameters, exit ResQdisk and these parameters in the setup. Reboot, and the disk should be accessible. A different situation may exist when the mbr or the DOS boot sector were destroyed or their data was modified. ResQdisk can restore access to such drive when either of the two sectors exists, but not if both were destroyed. In such case you will need the ResQpro version. Another limitation of ResQdisk is that it can recover only the first partition of a physical hard drive. If the disk was partitioned with more than one logical partition, then you'll need ResQpro. InVircible Pro, with ResQpro is available from InVircible agents. ResQdisk will prompt to press ^F1 or ^F2 to reconstruct the mbr or the DOS boot sector, respectively. After reconstructing either of the above you need to reboot the computer in order of the renewed sector to become effective. To reconstruct both sectors, or to recover a higher partition you will need either a ResQpro kit, or to contact an IV agent, to authorize a single ResQpro session. When authorized, then press ^F4 to start searching for partitions on the hard disk. ResQpro will only handle DOS partition that were prepared with FDISK. It's important to understand the way FDISK prepares more than two partitions on a single physical disk. Each partition sector has provisions for up to four sub partitions. Yet the mbr contains usually only data for two partitions only: The primary DOS partition and an extended DOS partition, occupying the space left after allocating the primary DOS partition. Higher partitions are the subdivision of the extended DOS partition. The extended DOS partitions are usually written into the second partition's partition sector. ResQpro reconstructs the mbr only. Therefore, only two partitions need to be rewritten to the mbr. ResQpro will prompt and ask to confirm for every partition found while searching the disk. Only the first one should be confirmed. It is worth writing down the coordinates of all the partitions found, as it may be helpful if manual disk editing will be needed, later. ResQpro will report its finding and prompt before writing the data to the mbr. IV agents may authorize a single ResQpro session (see the AGENTS.LST). For ResQpro's password, run ResQdisk and press ^F10. Proceed as instructed by InVircible's hotline support. See also ResQdisk and ResQpro. 10.12 Handling Cluster Infectors. There are two known cluster infectors that appeared by the end of 1991, Necropolis (1963) and DIR_II. Both originate from Bulgaria. DIR_II is almost of no interest, as it does not survive in DOS 5 and higher. When not active in memory, CHKDSK will indicate that all infected files are crosslinked on the same cluster, usually the highest free one in the partition. To clean from DIR_II run IVSCAN as described above. To clean large partitions (more than 32 meg) with IVSCAN you will need to boot from DOS 4.01. For smaller partitions you may boot from DOS 3.30. CHKDSK will show allocation errors on files infected by Necropolis (1963), when the virus is not active in memory. 1963 is removed with IVSCAN by retro-piggybacking. Do not run retro-piggybacking on a drive infected with Necropolis, unless you are sure the virus is active in memory. 1963's presence in memory is clearly indicated by the response of IV's self integrity check. In case a cluster infector is suspected, then do not use the CHKDSK /F switch until the disk is completely disinfected! Using the /F switch will ruin the infected files beyond repair. 10.13 Screening New Software. The purpose of screening is to detect infected software at the earliest possible stage, and to prevent it from infecting other programs or hard drives. Screening consists of two stages: Preliminary screening against known and generic viruses. Scan all new software with an up-to-date third party virus scanner and with IVSCAN. Preliminary screening need to be run just once on all new software and distribution floppies. Active screening is performed under the surveillance of InVircible to capture new viruses that passed the preliminary screening process. Any virus that is unknown to the scanner may be considered as "new", at least to the scanner. As new, or virtually new viruses are caught at the active screening phase, then the updating rate of the scanner may be relaxed, compared to where InVircible is not used. Active Software Screening. The ideal screening machine is a stand alone PC (not connected to a network) with a hard disk running under DOS, and with functional applications installed on the hard disk. IV should be installed, all programs should be secured by IVB and an IV rescue diskette for that PC should exist. Install the software to be tested to the screening machine, as instructed by its producer and secure the new files by running IVB. Exert all the functional and executable modules of the software under test, then exit back to DOS. Run IVINIT, then IVB, on the whole drive content. Reboot and watch IV's tests for exception messages. Reboot clean from the rescue diskette, run a ResQdisk Compare track zero test to check for changes, run IVB on the hard drive to seek for changes and if nothing is found in any of the tests, then the software may be declared clean from virus. Software screening is especially important in the corporate and institutional environment where infected software could be distributed throughout the organization. Boot viruses are more prevalent, but their damage is limited to a local hard drive and they cannot propagate through the network. File viruses are far less prevalent, only 30% of the reported incidents, but their damage can be devastating as they may affect many files on hard drives and on file servers and they propagate across the network with the server acting as a virus mailbox between workstations. 10.14 Common Problems, How to Handle Them. The following are the most common alerts that IV may provide, and what to do in case they happen. Memory stealing: Normally attributed with boot infection. Watch for other messages while running IVINIT and IVB. If no other message appears, then run ResQdisk. Inspect track zero (^Z) in the Compare mode. Repeat the ResQdisk inspection from the rescue diskette, in case it's a stealth boot infector and the drive isn't an IDE. Boot infection: A boot infection will usually follow a memory stealing message. In the case of a stealth boot virus the "faked" sector warning will follow. The remedy to these viruses is in IVINIT, IVSCAN, ResQdisk and in the rescue diskette. Faked partition (or boot sector): Indicates the detection of a stealth boot infector on an IDE hard drive. Partition sector (mbr) infections are also considered as "boot". The remedy is SeeThru recovery with IVINIT, IVSCAN or ResQdisk. When a boot infection of the hard drive is detected, then assume that there floppies in the workplace could be infected too. After cleaning the hard drive, process floppies with FixBoot to remove possible boot viruses. Virus active in memory: A memory resident virus may disclose its presence in one or more ways. It may trigger the self baiting of the IV module, it can infect special baits launched by IV, and it the later case, the virus will be sampled into a sample file named VIR-CODE, VIRUSAM.PLE or in both. The sample files are used by the correlator scanner, IVX. Piggybacking detected: Indicates the activity of a fast infector or a file killer (a virus that erase files on selective criteria). Piggybackers infect host files while they are accessed such as with antivirus scanners for inspection. The detection is based on actual infection occuring on a few files. Known fast infectors can be removed in the screening process, while unknown and new piggybackers are detected by IV, before they caused any significant damage. The few programs that were 'sacrificed' in the detection of the process can almost always be recovered by IVB, or replaced from backup. Because of the risk of piggybacking, never run a scanner, not even IV's on a remote drive or a file server without assuring first that there is no piggybacking. Run an IV scanner on a write enabled local hard disk to discard such possibility. Full stealth fast infectors can be removed by virus coperative methods such as retro-piggybacking or cooperative integrity recovery. Virus was sampled to file: IV has a dedicated viral probe and sampler named IVTEST. IVTEST can run on demand to sample an active virus into files. IVTEST will also produce a PARTVIR or BOOTVIR sample when a boot infector is found. The type of sample, their size, and the meessages issued by IVTEST are very instructive in assessing the characteristics of the virus and should be reported to support personnel. File changed: The nature of the changes is always indicated by IVB. It can be an increase, or decrease in file size. An inconsistent change pattern is most probably a new version of a program. IVB will then prompt for renewing the signatures database. A single modified file or several modified ones, with an inconsistent change pattern are not a virus but something else. In such case check for file corruption with CHKDSK. Only a consistent change pattern in several files indicate a virus doing. The remedy is to restore the files to their preinfected state with IVB, after booting clean from the rescue diskette. 11. InVircible, Windows and OS/2. InVircible will function properly in DOS Box and in DOS Virtual Machine (VDM) environments of DOS connective operating systems. Since InVircible does not use, nor need memory resident components, then its integration in the new operating systems is simple and straightforward. For your convenience, InVircible is distributed with the IV.PIF and IV.ICO files, for importing IV into the Windows desktop. Refer to the Windows operation manual on how to import the IV PIF and icon files. Non-DOS operating systems are fairly immune to DOS viruses, and the latter are the only ones to be concerned about. DOS file infectors are inactive while in an OS/2 or Windows session. When running a task in a DOS Box, then DOS is emulated by the parent OS, and again, viruses are powerless in emulated DOS. Only when in a full screen VDM DOS shell, then DOS is reinstated, yet not fully, as in plain DOS. As far as virus are concerned, many will function in VDM just the same as in DOS, others may crash or behave strangely. InVircible functions properly in the VDM environment, with the same limitations imposed by the parent OS on all DOS applications. Therefore, when IV detects virus activity in a VDM session, then save the data of all open tasks, close all tasks in an orderly manner and exit to full plain DOS. Corrective anti-viral actions should always be run from full plain DOS. The main risk to the PC operating in other than DOS environment (Windows NT, Windows 95 and OS/2) comes from dumb DOS boot viruses. When an infected floppy is left in the boot drive and the PC is powered on and becomes infected, then in some cases the OS will start and just ignore the boot infection. Yet, in other cases the OS may not start at all, and in extreme cases, the hard drive may become inaccessible. The remedy to this situation is an IV rescue diskette. In some cases ResQdisk could recover access to an inaccessible drive without the rescue diskette, but you shouldn't rely on this, as it isn't guaranteed at all! Preparing a Rescue Diskette for a non-DOS Disk. The following procedure is recommended for Windows NT servers and OS/2 systems. On any DOS machine, prepare a bootable floppy and copy to it RESQDISK.EXE. Boot the target PC from the DOS floppy and run from the floppy: RESQDISK /B RESQDISK /Z/B ResQdisk will take snapshots of the mbr, the boot sector, track zero and the CMOS setup data. In case of an infection, boot from the rescue floppy and use ResQdisk to recover the setup data, the mbr, boot sector, or the whole track zero. Windows 95. Install IV normally if booting to DOS in Windows 95. Restart the computer in full DOS (Alt+F4, select "Restart in DOS") to install the IV license from the distribution floppy. The rescue diskette should be prepared from full DOS. Then restart the computer back to Windows 95. If booting Win 95 directly in Windows mode then import IV.PIF and edit the PIF command file with the Windows PIF editor. Replace the program to execute from IVMENU to IVB.EXE and change the command line argument from /0 to C: DAILY. OS/2 Boot Manager. Boot in DOS mode and install normally. NT Servers. The protection of an NT server doesn't differ from the protection of any server. See also in NETWORK, how to viruses in the network environment. 12. CPAV's Inoculation. CPAV is now a discontinued anti-virus product, yet there are still many copies around. CPAV had an option that would let a user to 'immunize' or inoculate executable programs with a protective shell. InVircible detects the CPAV inoculation in files and alerts the user of their presence. From other anti-virus products F-Prot does the same and there may be others as well. This file inoculation is the cause of problems. 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 waste quite a lot of disk space. Secondly, inoculation causes some programs to malfunction. Thirdly, the recovery of an immunized file will in most cases worsen the situation. In order to drop the virus the infected file should be run, at the risk of loading the virus into memory and infecting other files. And lastly, inoculation is ineffective against smart viruses like full stealth ones. InVircible's files, when inoculated by CPAV will be ruined irreversibly and will not restore themselves. When the CPAV inoculation is removed from IV files, then they will not function properly anymore. 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. Since InVircible can and does peel off the CPAV inoculation then there is no reason why a virus couldn't. InVircible will indicate files immunized by CPAV by either scanning them with IVSCAN or IVB. IVSCAN can remove CPAV's immunization in the "Remove" mode (IVSCAN /R). 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, CPAV. 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 used with the /R switch. 13. InVircible and Memory Resident Anti-Virus (TSR). Two type of TSR are used in various anti-virus packages: TSR scanners - the majority, and virus activity blockers, or behavior blockers. Anti-virus TSR affect the computer's performance and its normal operation. Some TSR, especially behavior blockers, interfere with InVircible's operation and with other applications as well. Among the adverse effects of anti-virus TSR are: They slow down the computer operation, especially disk access, they waste precious computer resources such as memory and CPU time, they tend to conflict with applications and they constantly risk crashing memory and hang the computer's operation. As for the TSR effectivity, it can only handle viruses contained in its database and thus needs frequent updating. An anti-virus TSR scanner database handles usually far less viruses than the on-demand scanner from the same producer. More viruses can be found simply by screening new software with the scanner than with the TSR. Therefore, it's more logical to screen new software once with a good scanner, than to constantly suffer the oppressiveness and inconvenience of the TSR. TSR scanners and TSR behavior blockers should be loaded after InVircible completed its tests in the autoexec, to avoid them from interfering with IV. 14. Practicing Antivirus Strategies, 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 online hypertext guide. AVPL is available from IV distributors, anonymous ftp sites, AOL and CompuServe. AVPL is freeware, the file name AVPLxxx.ZIP. XXX denotes the version. For users with knowledge about viruses: Rehearse with real viruses on an isolated (not in a network) computer to get the feel of what a virus attack is like. Experiment only with controllable and 'well behaved' viruses such as Stoned, Jerusalem and Frodo (4096). Avoid Trojans, and deliberately destructive viruses, there are rare and there is little to learn, if anything at all, from sheer destruction. 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. 15. Troubleshooting. InVircible uses unique low-level hardware access methods to dig out and remove tough and elusive viruses. Though, these very same methods sometimes uncover hidden flaws in hardware and incompatibilities. The most common are problems with an IDE drive, special controllers, and sometimes with special drivers used in the config.sys. Among the few spotted by IV are a model of Promise hard drive controller and an old series of hard drives from Maxtor. The latter was traced to a design problem with that specific series of IDE drives. Maxtor was notified and acknowledged they know about the problem. To find whether a problem is caused by a conflict of IV with hardware or a conflict with other software, then start DOS and bypass the autoexec and config by pressing F5 (DOS 6+ users) and run the IV module that malfunctioned in the clean DOS environment. If it works clean, then search for the cause in a drivers or TSR which is loaded before IV. Use the F8 key while starting DOS to step through the drivers, one by one. Use elimination until the driver, or TSR in conflict is found. You may then change the order in which TSR are loaded not to conflict with IV. In certain cases you may find that a driver or TSR that conflicts with IV, causes problems elsewhere too. In many cases you may give up the driver and improve performance. If the driver is absolutely necessary, then you may have to give up IV. Anti-virus scanners and behavior blocker TSR are a constant source of conflicts with InVircible. Scanner TSR with background checksumming, such as VSAFE and Norton AV (NAV) will trigger IV's piggybacking sensor. There isn't real virus piggybacking, but there is one of the checksummer. Background checksumming slows down disk access and you may wish to turn this option off. Behavior blockers such as Thunderbyte's TBfile and TBcheck intercept IV's self baiting and the bait launching processes and may crash the computer. If you need a memory resident behavior blocker then you should load it after the IV tests were completed. You should also remember not to run an IV module once the behavior blocker is loaded to memory. As mentioned elsewhere, IVB, the integrity analyzer will usually be the first to notice file structure problems such as crosslinked files and FAT allocation errors. In case inconsistent changes in files is reported, then check with CHKDSK and act accordingly. Common Problems: Most users are unaware of the problems caused by DOS's undelete tracker. It is loaded to memory with the UNDELETE /LOAD or /S (sentry) command. The undelete tracker will create a hidden directory with the name \SENTRY, often confused with the IV Sentry mode. A copy of deleted files are stored in the \SENTRY directory, until purged. Except eating up disk space, the undelete sentry tracker often causes false piggybacking alerts, or file killer presence alarm. If not really needed, then turn the undelete tracker OFF, or do not run the IV scanners when the tracker is loaded in memory. Since IVB DAILY is written to the beginning of the autoexec, before loading the UNDELETE sentry TSR, then there should be no problems with the IVB daily inspection. NetZ Anti-Virus Utilities: From time to time NetZ releases useful utilities to assist handling virus related problems and disaster recovery. A set of such utilities consists of FixBoot as described here, SWAPBOOT, used to swap drive A and B and let boot from B without requiring to open the computer cover for swapping the cables, and XMONKEY, a program that will remove the Monkey mbr infector from up to eight installed hard drives. The three utilities are freeware and are available from BBS and the world networks. Dedicated Purpose Packages: From time to time NetZ releases dedicated purpose packages containing one or two modules, with ad-hoc documentation. Such were RESQDISK - a dedicated disaster recovery package, IVX - dedicated signature extractor, signature and correlation scanner, and XCAIBUA - a dedicated virus scanner derived from IVSCAN, to constrict the outburst of the new Big Caibua virus. 16. Upgrading and Support. InVircible does not require frequent updates, thanks to its generic features. IV let recover from both known and unknown viral infections. Still, IVSCAN is seldom updated on a need-to basis, to handle just the most common fast spreading viruses. InVircible is undergoing a continuous improvement process through upgrading. As computer virus technology evolves, its counter techniques should evolve too, to cope with the new techniques. Such are SeeThru, introduced in 1993, the IV Armor and the new hyper-correlator, both introduced in 1994. In the ongoing process of developing InVircible, NetZ constantly adds new features and replace older ones. Thus, IV is continuously upgraded, while IVSCAN is just updated on an irregular basis. Thanks to its generic nature, a version of InVircible is usable for at least a year, or two, without really needing to either upgrade or update. At the most, IVSCAN will not identify a virus, but if properly used on regular basis - i.e. routine checks by IVINIT and daily inspection by IVB - then such viruses will be detected and can be removed too, without knowing their name. Upgrading your Licensed Copy of InVircible: Licensed copies of InVircible are upgraded by overwriting the old files with the new ones, on both the distribution floppy and on the hard disk. You may format the distribution floppy without voiding its license. The same applies to the hard disk. The disk can be formatted with DOS's FORMAT), be reconfigured with FDISK, without affecting the license. You may also install/uninstall disk compression software without needing to retract your license. Only Low Level Formatting, or unrecoverable hardware failure will cause loss of the IV license. This is why IV is provided with one spare license on the distribution floppy. InVircible's upgrades are available through BBS, the Internet, as well as from the major networks (CompuServe, AOL, ZiffNet, Prodigy etc.). IV and its upgrades can be downloaded through anonymous ftp from the author site at ftp.datasrv.co.il/pub/usr/netz/ or ftp.invircible.com, as well as from CompuServe (Go InVircible). IV is also available from SimTel and its mirrors. Timed Fully Featured IV Releases: From time to time NetZ releases a fully functional, yet timed version of InVircible. These releases can serve for the full evaluation of InVircible. The expiration date of the timed license is indicated in a file named EXPIRY.TXT. Past that date, the IV copy will revert to Sentry mode. Registered users should download the upgrade package instead. Support Through E-mail: Questions can be sent through e-mail to support@invircible.com, or to the Sysop (go InVircible) on CompuServe. Questions to the author should be addressed to netz@invircible.com. Appendix A. - A Primer to Integrated Anti-virus. ABSTRACT This appendix provides an introductory discussion of current generic methods of antivirus security. Integrity analyzers are contrasted with checksumming methods and several advanced generic techniques of virus capture and integrity analysis are introduced. These concepts are then applied to virus detection and system recovery with the conclusion that generic integrity analyzers provide the most fundamental component in an integrated antivirus security protocol. INTRODUCTION. Antivirus (AV) programs usually belong to one of the following categories: on-demand scanners, TSR scanners, activity blockers, and generic AV tools. While scanners and blockers are generally understood there is some confusion about what is meant by generic AV. For most users, as well as the majority of computer security experts, generic AV brings to mind only 'integrity checking.' However, checksumming isn't really a generic AV method. The term generic, from the Latin 'genus,' implies that a method is applicable to a group or kind, and exclusive of others. While checksumming applies to all viruses, it is not inclusive to ONLY viruses. The checksum of a file, or of a program, may change for many reasons most of which are not connected with virus infection. A few common, non-viral reasons for the changing of a file, and of its checksum, are its replacement with a newer version, self configuration, and corruption due to truncation and cross linking. There are other causes, as well. Checksumming has long been used for antivirus integrity testing since viruses need to change the hosts they invade in order to get executed and replicate. Most antivirus products now include some sort of integrity check. The majority use a CRC, while others use a proprietary checksum algorithm. Cryptographic methods like DES are used as well. While not yet reported, it is possible for a virus to compensate for its presence in a file after infecting it. A CRC algorithm is complex enough in order to assume that no virus writer will bother to include such an algorithm in the virus's code. Checksum integrity checking does not take full advantage of the capabilities of modern generic antivirus methods. These new technologies cover all aspects of antivirus protection. Some of the new capabilities are not possible with signature scanners and activity blockers. Generic techniques include virus capture, damage recovery, and advanced methods like correlation. GENERIC VIRUS CAPTURE. When a virus strikes, the first event to identify is that something is wrong. Since viruses are real programs and they have to execute their code somehow, then they necessarily leave traces. Virus capturing, the equivalent of detection in generic terminology, is based on the sensing of phenomena indicating the possible presence of a virus. This is different than finding a specific signature in memory or in a file which is the method used in scanners and TSR's. The range of useful phenomena for virus capturing is broad and includes self-baiting, self integrity checking, verification of memory stealing, launching bait sequences, sensing piggybacking or file killing, integrity checking (yes, this too), and the sensing of deception like the taking away of the file handle. It's also possible to use tunneling for capturing boot viruses, either by tracing the origin of certain interrupts, or with hardware access. All these generic methods do not require a priori knowledge of specific viruses, as is true with signature scanners. All viruses, if they conform to the definition of a virus, will disclose their presence to one or more of the sensing methods mentioned. This has important implications. Virus capturing methods can detect the activity of both existing and new viruses which isn't possible using known virus signatures. GENERIC INTEGRITY ANALYZERS. Integrity analyzers deserve special attention because they are the most powerful of the generic methods. A properly designed analyzer can tell you more about a virus, in a matter of moments, than any other tool. When properly used the integrity analyzer can determine the size of the attacking virus, whether it uses stealth, if it's full or only semi- stealth (there is a difference in recovering from each), and if the file is recoverable. To understand how integrity analyzers work it is instructive to compare them to integrity checkers. The latter calculates a number (CRC) that represents every byte in the processed file. Changing a single byte anywhere in the file will result in a different calculated CRC. For example, DOS's SETVER.EXE program contains the version table of programs written to a special section in the SETVER.EXE file. SETVER contains an 'internal overlay'. Entries can be added or removed from the SETVER table. Changes to the SETVER table are legitimate as it is the purpose of the program, and adding an entry or deleting an entry does not necessarily indicate infection. An integrity checker will detect changes to the SETVER table without distinguishing between changes due to a virus or a legitimate one. An antivirus integrity analyzer can tell the difference. The DOS programs that interest us are of two types, COM and EXE. There are other executable types, as well, such as SYS, OVL, DLL, and DRV, etc. Yet they are of no particular interest to us. Most of them are covered under the umbrella of the EXE and New EXE types. Every program has an entry point, this is where DOS starts reading the instructions and executing the program. The entry point is usually indicated by a 'jump' or 'call' instruction at the beginning of COM files, or by a set of pointers, contained in the header of EXE programs. In both cases, the entry point is well defined and can be found from the file parameters. When a virus infects a program, it either appends, prepends, or inserts its code into the file and then modifies the entry pointer(s) to start execution from the virus code. Let's assume, for example, that we take a snapshot of a few bytes at the entry point of the uninfected file. If we compare the entry point of an original and infected file, and the bytes at the same relative offset to the entry point, we'll see that they have changed. Normally we will find three kind of changes in the infected file when it is compared to the uninfected one. The header (or the jump address at the beginning of the file) has changed, the code itself at the entry point has changed, and the location of the entry point has changed, as well. Just a few significant bytes can reveal more information about virus infection than a complete file CRC, or the cryptographic signature of the whole file. Moreover, while the latter is incapable of revealing whether the change was caused by a virus, the data used in generic integrity analysis inherently contains this capability. We need, of course, a few more parameters to confirm whether the change is viral, or due to non-viral factors such as corruption, or perhaps installation of a newer version of the program. A possible way to discriminate between the options is to include in a file's integrity database parameters that should NOT change as a result of infection by a virus. The presence of these parameters in the modified file necessarily indicate a virus infection, and their absence implies that the change is not viral. Let's now consider the potential of integrity analyzers for determining the specific file alterations and methods of operation used by a particular virus, and how to handle them. Many of the newer viruses use stealth, although not all have full stealth capability. Discriminating between semi- and full stealth depends upon whether an integrity checker can detect changes when the virus is active in memory. If no changes are detected, then the virus is full stealth and cooperative methods can be used to remove it. If changes can be seen when the virus is active in memory, but no change can be seen in file size, then the virus is semi--stealth. Some semi--stealth viruses will show a DECREASE in file size by exactly the length of the virus code. This is the result of an unsuccessful attempt to conceal their presence. The conclusion, which is perhaps surprising to some, is that CRC methods, and cryptographic signatures, are not the best suited for antivirus integrity checking. A generic integrity analyzer is better adapted for this purpose. It can identify changes in program files specific to virus presence and also potentially critical virus characteristics. GENERIC RECOVERY FROM VIRUS ATTACKS. Generic recovery is the restoration of infected programs to their original, pre-infected state. Many security experts recommend a system should be recovered by deleting the infected programs and replacing them with clean ones from backup. The main reason experts recommend replacement instead of restoration, is because they claim that you can't be sure the restoration results in a byte for byte identity with the original program. The fact is, however, that this can be easily verified. In the highly technological world in which we live, there is no room for superstition or speculation, certainly not if the facts can be verified. For a privately owned PC, or for a critical application PC, replacement might be the simplest course of action. But in business network environments, where time is of prime importance, fast recovery of executable programs may be imperative. Critical data files can always be restored from backup if there is a concern for their integrity. In fact, rapid program restoration can speed the process of restoring critical data files from backup by returning a system to operational status more quickly. Computer viruses are deterministic code and they function in a deterministic way, too. Virus names like Satan and Devil's Dance are just folklore and have nothing to do with unnatural powers. The exactness of the recovery of a program from a virus can be verified easily by comparing, byte for byte, a restored program to a clean one from backup. In case of a massive infection, generically restore a few infected samples and compare them to clean originals to determine whether complete restoration is possible. If it is, then you can be sure that the restoration of the rest will be complete, as well. This results from the deterministic nature of a specific virus's method of infection and the inherent logical structure of executable files. An advantage of advanced generic methods is that file integrity authentication and file restoration can be accomplished using the same database files. This capability results from the generic nature of the processes involved. It also further demonstrates the value of generic integrity analysis over CRC and cryptographically based checksummers. The databases of the latter do not contain the information required to restore infected programs. A checksum (or CRC) is just a 16, 32 or 64 bit number. How can you restore a file with the knowledge that its pre-infected checksum was 1234 and when infected it is 4321? By contrast, when critical program file characteristics have been sampled and stored in databases, it is possible to use this information to restore files to their original condition, byte for byte. COOPERATIVE RECOVERY METHODS. A special category of generic recovery methods are the cooperative ones. These apply only to full stealth viruses of both the boot and file infector types. The principle involved is extremely simple. The recovery process takes advantage of the fact that a full stealth virus, either boot or file, will present the correct, uninfected data of the inspected sector or file, when the virus is active in memory. To recover from a stealthed boot infector (MBR infectors are referred to as "boot infectors," as well), simply copy the stealthed image of the infected sector and rewrite it to the same place using tunneling techniques. The advantage of cooperative recovery, over the undocumented 'generic' technique known as FDISK/MBR, is that with the cooperative one you write EXACTLY what was there in the master boot sector in the first place, while in many cases you might cause more harm than good with FDISK. There are products that implement this cooperative recovery method under the name 'SeeThru' technology. Another effective file recovery technique is by cooperative integrity checking. A new integrity database is established while the virus is still active in memory. Then the computer is rebooted and the programs are restored from the database made when the virus was resident. This technique is effective only against full stealth viruses. It has been implemented successfully against Tremor, a common virus in Germany, and works against other full stealth viruses such as NATAS, Die_Hard, Hemlock, N8fall, Invisible Man, Uruguay, and all strains of Frodo, as well. VIRUS ANALYZERS. The problem that haunts security experts when they face a new, or modified virus, is that it usually takes days, sometimes weeks or even months, until antivirus developers have an algorithm available to restore systems from the new virus. We have seen instances when whole enterprises were halted for days because of attacks from new viruses. Generic methods have a lot to offer in such situations. First, generic recovery will allow return of systems to operational status in the shortest possible time. In most cases, programs can be completely restored using the integrity database without waiting for the disassembly and analysis of the virus. In the case of destructive, overwriting viruses, the integrity database can be used to identify which files need to be removed and replaced. The correlation scanner, a breakthrough in generic AV technology, can be used to spot infected files that were not found by the integrity analyzer and the source of the infection, too. Since an attacking virus can be of an unknown type, then no scanner will find it. The file that brought the infection into the system will not have a pre-infected, "clean" record in the database since it was already infected when the database for it was created. The correlation scanner will find the original infector, and other infected files, by similarity to an infected sample identified by an integrity analyzer, captured through a baiting process, or designated by the user. Correlation scanners have recently been enhanced so that a library of signatures can now be used with them, as well. The generic correlator identifies similarities in the processing that a file undergoes during infection (a virus infection is a 'process'), in the cryptographic model used in the virus code, and the matching of a signature string. The correlation scanner has proven itself effective with plain, encrypted, and even polymorphic viruses. The correlator may replace the scanner in many cases, and can be used to disinfect a computer, without needing updates, and with no delays. It is a tool that empowers users to restore their systems independently of antivirus security experts who may not always have the resources to respond quickly to user needs and requests. INTEGRATED ANTIVIRUS PROTECTION. Having reviewed the basics of generic antivirus technology, let's now discuss overall antivirus strategy. An effective antivirus defense should consist of several elements. Because of its broad effective spectrum, generic protection can and should have a pivotal role in any integrated AV defense strategy. It can capture a virus that passes through a known virus screening process and act as a buffer BEFORE loading an activity blocker or TSR scanner, if one is used. On-demand and TSR scanners can detect only viruses that are contained in their signature database. Often, this does not include all known viruses. Therefore, virus scanning should always be PRECEDED by running a generic probe and integrity analyzer, especially before scanning a file server. There is always the risk that a new fast infector, or even a known one not included or accurately detected, is active in memory. Signature scanning, without first performing a generic integrity analysis, can infect every executable inspected by the scanner. The backbone of an integrated antivirus strategy is the integrity analyzer. First, you need to run it regularly in order to keep its database up to date. Secondly, it's arguably the most effective means to detect an infection in its earliest stage. Thirdly, it will be the first to capture the presence of a fast infector BEFORE it can infect any significant number of programs, even if the virus is new. And lastly, it provides a very effective way to quickly and fully recover a system to its original, pre-infected condition, in the event of an infection. Virus scanners are a convenience, for scanning new software before installation, and for scanning floppies. They do offer some potential for detecting known viruses prior to executing their hosts. However, no scanner detects all known viruses and new viruses are produced daily, as well. And, it is very easy to mask existing viruses from detection so that even a comprehensive scanner will fail to detect them. These are significant practical limitations that preclude use of signature scanners as a primary method of AV security and defense. The core component of a comprehensive AV defense can be modeled upon the military equivalent of a "fail safe." A "fail safe" is a counter defensive process that will operate despite unknown and variable conditions and methods of attack. Generic methodologies best implement this concept as they function without regard to the specific details prevailing at the time of the viral attack, and use multiple, overlapping and partially redundant mechanisms for virus capture and, if needed, system recovery. Deliberate redundancy means that one or more of the generic methods will operate effectively despite variability in virus hosts or methods of viral action. In contrast, signature based antivirus can only handle known threats, contained in their database. Therefore, a more defensible AV strategy combines generic capture and restoration methods with known virus scanners. A cost effective benefit of this approach is that scanners will not need to be updated as frequently since the main purpose of updates is to detect new viruses. The generic methods can act as both a buffer and safety net to protect systems until preventative methods using scanners are possible. Since it can take anywhere from days to months for signature detection and cleaning algorithms to be made available, generic methods provide a highly significant "fail safe" to overall AV defense strategies. Even more importantly, advanced generic methods such as those presented, here, will provide both virus capture AND system restoration immediately. The use of antivirus TSR's and activity blockers is debatable. They always adversely and, at times, significantly impact system performance and available resources. They can also interfere with normal program operation, and conflict with other applications. Finally, they can be used as vectors to spread infection across all files scanned when either a known or new virus not detected is present. Yet there are users that won't give them up. Sometimes this decision is based on the mistaken assumption that TSR's provide protection beyond what is available from scanners. In fact, the latter are invariably more comprehensive and reliable than their respective TSR, from the same vendor. From a practical standpoint, when generic, TSR scanner, and activity blocking methods are used the latter two should be run AFTER completing the generic tests and integrity analyses. Generics and AV TSR's do not coexist well. The latter intercept generic probes as if they were viruses. This is especially true of activity blockers. After gaining some experience with the various elements of an integrated antivirus strategy, users will be better able to decide how important signature scanning, TSR's, and activity blockers are to a cost effective, and efficient AV defense. Past experience shows that users tend with time to rely on generic AV since it proves dependable, and is the least intrusive and obstructive to them. Users don't disable generic AV methods like they often do with TSR's and scanners. This is true even after long periods without viral incidents because the generic methods do not interfere with normal system operation, consume system resources, or negatively impact system speed and performance. When a virus does strike, then the generic AV will be in place to capture it, stop it, and restore the system to operational status quickly. Appendix B. - 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 on-demand and TSR scanner, or 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 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 looking in the wrong place. 2. Virus scanning of file servers should be run sparingly and with utmost precautions. Since piggybacking cannot be sensed on file servers, then always run first generic probes to assure that the workstation you are working from is clean and the scanner is not being piggybacked by a virus. 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. 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 IVLOGIN will accept the following command arguments: If a random signature filename is desired, then add /RANDOM after the IVLOGIN filename. If a specific signature filename is preferred then add SIG=MY_NAME. No spaces are allowed in the SIG= argument. 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 C. - 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 translation (logical bloc 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 D. - 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. Appendix E. - Switches and Command Line Options. The following are a list of the switches and command line options available in the InVircible modules. INSTALL. /FAST Upgrade an existing installation or install with the default parameters. The installation is automatic, no prompting is available and the registration key will not be installed to the hard disk. /R Prepare an IV rescue diskette. IVMENU. [drive:] Load directory of the specified drive. /V Start IVMENU in virus scanner mode. /R Start IVMENU in ResQdisk mode. /0 Start IVMENU at zero level (all sub-menus closed). IVINIT. /NOCMOS Skip CMOS data comparison, recommended for notebooks and laptops. Also use on computers that use the CMOS for power saving ("Green") data. IVTEST. /Q Quiet mode. Do not display to screen, except when virus activity was found. IVLOGIN. /RANDOM Install with random signature file name. SIG=name Install with specified signatures' file name. IVB. DAILY Run complete daily inspection of all local drives and directories. WEEKLY Same as DAILY, but weekly. /NOSTOP Do not stop for prompting the user. For unattended systems. /ESC Enables escaping the daily check, in Sentry mode. /NOMEM Skip brief memory check. /S Secure all executable files, overwrites existing signatures. /R Restore modified files. /D Restore modified and recoverable files, delete modified and unrecoverable ones. /V Remove current signature files. /X name Overrides current signature filename, use "name" as signature filename. - Operate on specified directory only, do not continue to sub directories. IVSCAN. /R Remove virus from infected file, if algorithm exists in IVSCAN. /D Remove virus if possible, delete file if no removal algorithm exists in IVSCAN. /B Inspect floppy boot sector, force boot sector replacement, if no original sector found. /EX Scan only files with executable extension filenames. - Operate only on specified directory, do not continue to sub directories. IVX. arg1 First argument after program name: Pathname of file to use as sample. Wildcards are allowed. arg2 Second argument: Path where to start scanning. arg3 Third argument: Number of bytes past the entry point, where to look for a signature string. RESQDISK. /B Backup the mbr, boot sector and CMOS data. /R Restore the mbr, boot sector and CMOS data from image. Prompt before writing data to CMOS. /Z Track zero functions. Use with /B or /R, above. /2 Operate on disk # 2. Use with all switches above. /DM Boot sector of Disk Manager partition. Use with /B, /R and /2, above. FIXBOOT. /IBM Force a PC-DOS type boot sector instead of the MS-DOS one. /S Prompt for a floppy size (360, 720, 1.2, 1.44, 2.88) and force a boot sector of the selected size. Appendix F. - Glossary Piggybacking: Technique used by a fast infecting virus. The virus installs a memory resident handler that monitors DOS for 'open', 'close', 'find- -first' and 'find-next' calls and hooks its infection routine to the captured handler. Retro-piggybacking: A disinfection technique used by InVircible, taking advantage of piggybacking to clean after the virus. Tunneling: A method to bypass 'underneath' a BIOS or DOS service. SeeThru: A tunneling technique used by InVircible to 'tunnel' under interrupt 13h, used for absolute disk read/write, to thwart int 13h stealth.