DP Tool Club 24/CD_ASCQ_24_0995.iso/vrac/invbfree.zip/MANUAL.TXT

Text File | 1995-06-20 | 106KB | 2,195 lines

                     Copyright (c) 1990 - 1995
         All Rights Reserved to NetZ Computing Ltd., Israel


                          User's Guide
                               and
                   Installation Instructions

                Warranty And Licensing Agreement

 InVircible and ResQdisk (Tm) 1990-1995 are trademarks and copyright
 with all rights reserved to NetZ Computing Ltd. (NCL), Israel. You, as
 the purchaser of license rights to the software, are herein referred to
 as the Licensee. The Licensee may not assign the license rights to the
 software without the prior agreement of NCL.

 The installation of this software package constitutes acceptance and
 full agreement to the terms and conditions of this warranty and
 licensing agreement, in so doing the Licensee agrees to be bound by
 said provisions. This is a legal agreement between the Licensee as the
 end user -- and NetZ Computing Ltd. who is the owner of all rights to
 the software. Usage of the InVircible software indicates acceptance of
 the terms and conditions.

 License: InVircible is licensed, it is not sold. The Licensee is
 obtaining limited rights to use the InVircible software. The Licensee
 is licensed to use InVircible on a single IBM-style personal computer.
 The distribution floppy of InVircible has provisions for licensing two
 installations to the hard disk. Only one installation to one hard disk
 is licensed with this disk package. The second installation is reserved
 for the Licensee as a backup. Site licenses are available for
 individuals or organizations with multiple installation requirements.
 Alteration or reverse-engineering of the programs is not authorized,
 such attempts terminate this license agreement and may result in
 unpredictable and irreversible damage.

 Limited Warranty/Limitation of Remedies: Defective diskettes will be
 replaced, at no charge, if they are returned freight pre-paid, within
 30 days of the original purchase date. The sole remedy available to the
 Licensee will be limited to the replacement of defective diskettes as
 outlined, or a refund at the purchase price of this software program
 package.

 InVircible is provided "as is". The Licensee assumes all responsibility
 for the determination of the suitability of this software for
 Licensee's configuration and the results and performance of this
 software program package. NetZ Computing, the distributor, and their
 suppliers do not warrant, guarantee, or make any representations
 regarding the use of, or the results obtained with, the program in
 terms of correctness, accuracy, reliability, legality, or otherwise. In
 no event shall NetZ Computing Ltd., the distributor, nor anyone else
 involved in the creation, production, or delivery, of this product be
 held liable for any damages, loss of profit, consequential, or other
 damages, that may arise out of the Licensee's use or inability to use
 the InVircible programs. Some states do not allow excluding or limiting
 implied warranties or limiting liability for incidental or
 consequential damages, so the above limitation may not apply to the
 Licensee. This limited warranty and license agreement is governed by
 the laws of the State of Israel.


                           Table Of Contents

 Preface

 Quick Start Instructions

 1. Introduction
 1.1 What are computer viruses?
 1.2 InVircible's Main Features.

 2. Getting Started.
 2.1 Working from the InVircible Floppy.
 2.2 Preparation of the Rescue Diskette.

 3. Using the Main Menu (IVMENU).
 3.1 IVMENU Special Keys.
 3.2 The IVMENU Caution Panel.
 3.3 The Last IVB, IVSCAN or IVX Report.

 4. InVircible Installation .
 4.1 Installation to Hard-disk.
 4.2 Installation to LAN Server.
 4.3 Installation Under OS/2.
 4.4 Installation in the Sentry Mode.

 5. Recommended Anti-Virus Strategy.
 5.1 In the Single User Environment.
 5.2 In a Network Environment.
 5.3 In the Institutional Environment
 5.4 In Unattended Installations (e.g. Bulletin
     Board Systems).

 6. IVB - The file Protection & Restoration Program
 6.1 The Extra-Security Feature.
 6.2 Off-line Backup of the Database-Files-Tree.

 7. IVX - The Correlation Scanner.

 8. ResQdisk - The Boot-Area and CMOS Maintenance program.
 8.1 Reconstruction of the Boot Block.
 8.2 Regaining Access to an "Invalid Drive".
 8.3 ResQdisk's Setup Utility.

 9.  IVSCAN - The Virus Detection and Removal Scanner
 9.1  Removing Generic Boot Viruses from Floppies

 10. A Primer to Generic and Special Methods.
 10.1 Generic Method Selection
 10.2 Generic Boot-Block Recovery
 10.3 Fat Manipulators Removal
 10.4 Inverse Piggy-Backing (IP).
 10.5 The Virus Interrogation technique.
 10.6 Forced Self Restoration.
 10.7 Screening New Software.

 11. Importing InVircible into Windows.
 12. Virus Handling under OS/2.
 13. Central Point Anti Virus Inoculation
 14. The Antivirus TSR (Terminate and Stay Resident).
 15. Procedures to Use if Virus Activity is Suspected.
 16. Practicing InVircible, the AV Practice Lab (AVPL).

 Appendices

 Appendix A. - LAN Protection
 Appendix B. - Large Capacity IDE.
 Appendix C. - IVX advanced options.


 Preface

 This manual provides the essential information for the installation and
 use of InVircible. The InVircible software is user friendly, intuitive
 and will provide long-lasting virus protection. After installation
 InVircible functions unobtrusively without the need for ongoing user
 actions.

 The key component of InVircible is a rule-based Expert System that
 insures that most of virus attacks will be detected and removed from
 your IBM PC-class DOS system. For those situations where complex or
 compound virus attacks are detected, InVircible's utilities and this
 manual's guidelines provide for a user directed thoroughly complete
 restoration. In addition to background and program documentation, this
 manual provides guidelines for minimizing ongoing threats to the
 well-being of your PC's health. InVircible may be installed and used
 with assistance only from the on-line user help, so many InVircible
 users operate without the manual. A Quick Start section in this manual
 guides the user who prefers to install immediately and re view the
 manual in detail later.

 InVircible's basic features, the integrity checker, the correlation
 scanner, the virus scanner and the ResQdisk program are accessed via a
 menu using the IVMENU command. Command line execution is also
 available. Advanced features are integral components of the InVircible
 package; those advanced features are used rarely during day-to day
 operation in defense against simple virus attacks. Since most virus
 attacks are uncomplicated solo attacks of your system, InVircible's
 basic features will give you excellent ongoing protection. The advanced
 features are always available for simple or complex virus attacks and
 provide you with leading edge technology capabilities to eradicate even
 the most clever and troublesome viruses.

 InVircible provides a layered approach to protection from computer
 viruses. The first layer are the InVircible automatic detection and
 recovery features, embedded in IVINIT, which provides InVircible with
 extreme resistance to being bypassed or attacked by viruses. The second
 layer is the IVB integrity checker and restorer that secures your
 files, detects and eradicates new viruses (especially the
 "unrecoverable" viruses) and recovers the files that become infected
 with one or more viruses. The third layer are IVX and IVSCAN, the
 correlation and virus scanners for tracing down infected files and for
 the elimination of common or unknown viruses.

 In support of the above are: IVTEST, a module that checks computer
 memory for viral activity in real time, and ResQdisk, an advanced tool
 for inspecting and recovering the critical boot sectors and data of
 your hard disk.

 InVircible avoids common problems of other anti-virus software.
 InVircible programs recover themselves in case they become infected,
 even from stealthy viruses. InVircible does not allow a "fast infector"
 virus to "piggyback" its scanners and to infect an entire hard disk
 drive. InVircible utilize an efficient virus activity probe instead of
 memory resident (TSR - terminate and stay resident) component in its
 protection scheme.

 InVircible allows you to automatically recover from virus attacks; or
 you may prefer to manually guide the recovery.


 Quick Start Instructions

 Insert the InVircible diskette into the A: or B: floppy drive.

        Type A: or B: at the command prompt line.
        Type INSTALL/FAST to start the quick installation procedure.

 The InVircible INSTALL first examines your system for in- memory viral
 activity and infected hard disk drive boot areas and files. After these
 initial tests, InVircible then installs itself on your system to a
 default directory. If you prefer to install InVircible with parameters
 other than the default then use the plain INSTALL command. During the
 installation phase, all files on hard disk drive partitions will be
 scanned, then "secured" by IVB, the integrity checker. Although
 InVircible's functions are designed to be exceptionally fast, this
 initial scanning and securing of a large number of files may take a few
 minutes, so please be patient! Whenever a choice is provided, the
 default selection is the recommended choice. We encourage you to
 configure your system so that IVTEST, the real time viral activity
 checker, is activated when you invoke a frequently used batch (BAT)
 file (see Sections 4).

 NOTE: Preparation of a Rescue Diskette (Section 2) is critical for
 effective recovery from boot block and complex viral attacks. The
 preparation is needed before a virus infection may occur.

 Using InVircible

 Type IVMENU to access the user-friendly menu. Choose your selection by
 using the keyboard or a mouse.

 The Integrity Test option activates IVB, the integrity checker. Choose
 the Virus Scanner option to activate IVSCAN, the virus scanner. The F1
 key provides access to the extensive, on-line, interactive hypertext
 manual. You may exit InVircible by pressing the F10 key, Alt+X, Alt+Q
 or clicking the mouse on the 'quit' field from the main panel. The
 escape key (Esc) returns you to the previous IVMENU panel.

 After IVB is selected, you choose the drive partition and directories
 to examine and whether to "validate", "secure", or "restore" files.
 When selecting IVSCAN, you choose the drive partition to scan, the
 directory (or directories) to examine, and whether to "scan" viruses or
 "remove" them also. For IVB and IVSCAN, it is usually best to utilize
 the default choice first, i.e., either "validating" or "scanning".
 These advisory modes notify you of suspicious activity. You may then
 make an informed decision regarding the appropriate action to take.


 Suggested Protection Routine

 IVINIT will check on any initialization of the computer that the boot
 block and operating system are intact.

 IVB will automatically run a daily check of all your executable files
 in all local partitions on the hard drive. IVB is the primary tool for
 monitoring the integrity of files and for their recovery in the event
 of a virus infection. IVB will report changes in executable files. Some
 changes in executable files are expected if you generate your own
 applications and program executable filenames are reused. IVB will
 normally prompt and suggest the renewal of the database file in a
 directory, in case the changes are a new version of a program. Yet,
 software developers will need to be aware when alterations are
 legitimate and when they are not. User generated executable should be
 secured immediately with IVB. When installing new software packages,
 scan the diskettes with IVSCAN before installation. After installation
 run IVB on all directories to secure any added executable file.

 Application programs such as DOS or Windows do not change normally
 unless they have been upgraded or purposely changed such as adding or
 deleting an entry to the SETVER table. A consistent change pattern
 reported by IVB indicates a viral infection. IVB provides this
 information both on screen and in a report file (IVB.RPT) placed in the
 partition root directory. Print this file to help assess the situation
 if you suspect virus activity. A report of only a single file having
 become modified requires you to proceed carefully ! Viruses rarely
 infect only one file, so an indication of a single modified file may
 not necessarily indicate the presence of a virus.

 When a genuine infection is found, try IVSCAN first, to discard the
 possibility of an infection by a common virus.

 Viruses unknown to IVSCAN may be removed using IVB, provided the
 programs were secured before becoming infected.

 New viruses, unknown to IVSCAN or where no securing signatures exist,
 can be found using IVX. The suspected files can have their extension
 name be renamed to a non- executable one and the files can then be
 replaced from backup.


 1. Introduction

 1.1. What are Computer Viruses?

 Computer viruses are sophisticated computer code written by imaginative
 programmers, having little respect to other's people work. Their
 motives are many, but the indisputable fact is that there exist already
 thousands of them, and several new ones are written daily! Viruses have
 to be purposely designed and written, they don't just appear from
 nowhere. However, to be a virus, there is one characteristic this
 program must have: It must replicate (or copy) itself so that it can
 spread. In order to assure its continuous spreading, the virus program
 must take control of the program's execution, either if it is a
 bootstrap program or an application file.

 Computer viruses are passed the same ways we obtain software; by
 copying from friends, from bulletin board systems, with newly purchased
 PCs and even in vacuum wrapped new software.

 1.1.1 Categories of Computer Virus

 There has been much discussion regarding computer viruses and elaborate
 technical names are being used, such as stealthy, polymorphic,
 multipartite, spawning and self- encrypting. In reality, there are only
 two general virus categories:

        (1) Viruses that infect through the boot sector or partition
            table (MBS);
        (2) Viruses that infect through files;

 All encountered viruses fall into one of the above two categories or
 both. There are multipartite viruses that combine the properties of the
 two categories (boot and file). Such are the Junkie, Natas and Tequila
 viruses.

 A new variant of file viruses emerged in late 1991. It manipulates the
 file allocation table (FAT) in order to spread. We will call them FAT
 manipulators or cluster infectors.

 For the sake of reference, below is a quick definition of terms that
 are used to describe viruses and techniques employed by viruses:

 1.1.2 File Viruses

 A file infector attacks executable program files, having a COM or EXE
 extension name. File infectors may corrupt non- executable files as
 well but they cannot spread this way, unless the affected file is
 renamed to an executable filename and executed.

 Many file viruses are memory resident (TSR). After an infected file is
 executed, they will remain resident in the computer's memory until the
 computer is turned off. While in memory they will continue to infect
 other programs and may interfere with normal operations. If the
 computer is turned off they will lie dormant until an infected file is
 executed and then load themselves back into memory again until the next
 time the computer is turned off.


 1.1.3 Boot Viruses

 Boot viruses attack boot records and master boot records (MBR,
 sometimes referred as the partition sector). When the computer is
 turned on, it runs a couple of tiny program from the hard disk, first
 the partition bootstrap and then the boot loader, to ready itself for
 work. In case of a boot infection, one of these programs may simply be
 a virus. Boot viruses will remain active in memory while the computer
 is on.     During this time they will infect write enabled floppies
 that the computer accesses.


 1.1.3 Multipartite Viruses (boot and file infectors)

 Multipartite viruses infect both executable files and boot- partition
 sectors. When the computer is turned on the virus will be active and
 infect additional programs that are executed. Multipartite viruses are
 sometimes referred to as 'droppers', meaning that when an infected file
 is executed, it will drop its own boot program into the hard drive boot
 area.


 1.1.4 FAT Manipulators (file infectors)

 The FAT manipulators are basically file infectors, with a unique
 infection mechanism. FAT manipulators are inherently stealth viruses
 because they hide the increase in file length, although the virus code
 is actually appended to the file. The way it is done is by inserting
 the extra clusters in the file's clusters chain in the FAT. Two well
 known such viruses are Dir-2 and 1963 (Necropolis). FAT manipulators
 are also excellent piggy-backers.

 1.1.5 Techniques used by Computer Viruses.

 1.1.5.1 Stealth

 Stealth viruses are so named because they actively seek to hide
 themselves to prevent detection. Stealth viruses that infect files will
 subtract their own size (in bytes) from the infected host file at any
 time that a directory (DIR) command is executed. The Whale virus is a
 good example of this. When it infects a file it adds 9216 bytes (and
 some mutations may reach even 16 Kb in length) to the file size (a copy
 of itself). If the DIR command is issued, it subtracts the virus length
 (9216 bytes) from the displayed host file length. Thus it effectively
 hides itself from the computer operator eye and from the operating
 system.

 Some boot viruses use stealth (spoofing) techniques too. Stealth boot
 viruses will deceit editing tools such as Norton's Disk Editor. Example
 of stealth boot viri are Monkey and Noint. Natas and Gingerbread Man
 are multipartite viruses that use boot spoofing too.

 1.1.5.2 Encryption

 Most of modern viruses use encryption to evade detection by scanners.
 An encrypted virus has a very short common encryptor (from as few as 3
 bytes, to a couple of dozen bytes) and the rest of the virus code is
 encrypted and differs from copy to copy of the virus. The detection of
 encrypted viruses cause high false alarm rates due to the ambiguity in
 the detection of the short common string.

 1.1.5.3 Mutation Engine or Polymorphism

 Polymorphic viruses are a higher order of encrypted viruses. In
 addition to encryption, they use a "mutations generator" that scrambles
 the encryption too. A polymorphic virus mutates itself, so that each
 occurrence is totally different from the one before. This creates huge
 difficulties for anti- virus scanners, because they cannot look for a
 'known' virus signature. Polymorphic viruses have rendered scanners
 effectively useless since they cannot be removed by an algorithmic
 approach.

 1.1.5.4 Spawning (or Companion) Viruses.

 Companion viruses take advantage of the precedence DOS gives to COM
 over EXE files in the order of execution. If there are two files
 bearing the same name, one with a COM extension name and the other with
 an EXE extension, then DOS will execute the COM file first. A companion
 virus is basically a Trojan that "infects" EXE files by spawning itself
 into a companion COM file, bearing the same name as the EXE file.
 Sometimes the companion virus file will have its attribute set to
 'hidden', to avoid its detection by the DIR command.

 1.2 InVircible's Main Features

 *  It handles both known and unknown computer viruses.
 *  It is extremely fast, professional and easy to operate;
 *  Does not require any costly updates;
 *  Is self-sufficient and provides real time recovery from new or
    unknown viruses. Does not need outside assistance;
 *  Has Extremely low false-alarm or 'false positives', with the highest
    probability of 'true positives' detection;
 *  Uses a unique unobtrusive file protection and restoration scheme.
 *  Has an automatically updating distributed database for restoration
    of files.
 *  Has redundant and user-defined security features.
 *  Uses a unique generic virus behavior probe and sampler.
 *  Is not memory-resident and does not adversely affect computer
    performance.
 *  Uses unique programs that automatically check themselves for, and
    restore themselves from virus infection.
 *  Is friendly and uses a menu-driven user interface.
 *  Features an interactive installation utility.
 *  Is compatible with all major LANs (Local Area Networks).
 *  Has an indispensable toolbox for computer security experts and
    advanced users.
 *  Has generic procedures for full recovery from the Dir-2 and 1963 FAT
    and directory manipulators.
 *  Utilizes sabotage-resistant protection designed to avoid both human-
    and virus-based deception.
 *  Is piggybacking resistant to prevent InVircible from be coming a
    virus carrier.
 *  Has extensive context-sensitive hypertext on-line help; and
 *  Is financially affordable;


 2. Getting Started

 2.1 Working from the InVircible Floppy.

 InVircible is to be used from the hard disk drive. Yet, it can be used
 from the original distribution floppy. Boot the computer from either a
 DOS diskette or from the hard disk. Put the original diskette in one of
 the floppy drives and run IVMENU from the InVircible diskette. For
 reading the on- line hypertext manual either run IVHELP or use the F1
 key when in IVMENU.

 2.2 Preparation of the Rescue Diskette.

 The Rescue Diskette is a bootable floppy, containing the necessary
 InVircible programs, the hard-disk's boot-areas image files, the data
 stored in the CMOS, a copy of your AUTOEXEC.BAT and CONFIG.SYS and some
 useful DOS files such as FDISK, SYS, and UNFORMAT. It enables to
 recover the boot areas of a given hard-disk, the CMOS settings, as well
 as the recovery of files in case of infection. The Rescue Diskette is
 fully operable only on a computer that has the license installed on the
 hard disk.

 Install InVircible normally to the hard disk and reboot the computer to
 make the installation effective. Insert a formatted diskette into drive
 A and run INSTALL/R. First, the system and InVircible files will be
 transferred to the diskette, to make it bootable. Then, the boot areas
 of your hard-drive will be backed-up to the diskette. Write-protect the
 diskette.

 Partitioning device drivers (e.g. SpeedStor), disk- compression
 (Stacker, SuperStor, DoubleSpace), password drivers etc., required to
 recognize partitions or drives at booting time, should be installed
 onto the Rescue Diskette. DoubleSpace, Stacker and Ontrack's Disk
 Manager are all taken care of by InVircible.

 In other cases, copy the driver to the rescue-disk and edit its
 CONFIG.SYS file by an ASCII editor. It should contain an appropriate
 DEVICE line for each driver to be loaded at booting time.

 There is no point in preparing a Rescue Diskette for a computer without
 a hard disk. The Rescue Diskette is individual to the specific
 hard-disk for which it was prepared. Rescue Diskettes should never be
 swapped between computers.


 3. Using the Main Menu (IVMENU).

 IVMENU may be started in different modes by using the command line
 options. By default IVMENU will start in the Integrity Check mode, on
 the current drive. IVMENU's command line syntax is:

                        IVMENU [/switch] [drive:]
        Switches:

        /V to start in the Virus Scan mode,
        /R to start the ResQdisk boot block maintenance utility.

 The "drive" option will home IVMENU to a different than the current
 drive at startup. The switches and the drive option may be used in
 combination in any order.

 There are several ways to change options and modes with IVMENU, just
 use the keyboard or the mouse anyway you like. Any "sensible" action
 will respond accordingly.


 3.1 IVMENU Special Keys.

 Alt + key combinations: the Alt key combined with either I, H, R or V
 will switch to the Integrity Check, Hyper- Correlator, ResQdisk or
 Virus Scanner respectively.

 Ctrl + key combination: the Ctrl key, when combined with a character
 from A to Z will change the current drive to the one selected, if
 available.

 Alt + G shortcut control: the shortcut hot-key is labeled "Go" when a
 mouse is found or "Alt + G" when the mouse is inactive. The shortcut
 control may be used to proceed with the selected mode without further
 selections. Press Alt+G or click the mouse on the green "traffic light"
 at the top center of IVMENU's display.

 3.2  The IVMENU Caution Panel.

 The CAUTION PANEL is at the right-hand side of IVMENU's main screen. It
 displays various parameters on InVircible settings as well as selected
 warnings, related to possible virus problems.

 The first two entries are dedicated to memory stealing alert. In case
 DOS reports less than the expected memory, a message indicating the
 number of missing kilobytes will pop up. The message will prompt for
 confirmation to set the alert threshold to the difference detected.
 Once set, IVMENU and the InVircible programs will ignore missing
 memory, if equal to the set threshold. The threshold is reset
 automatically to zero when IVMENU detects more DOS memory than the
 current threshold setting.

 A Low memory message will be displayed in case missing memory is
 detected and the user didn't confirm the setting of the threshold.
 There are instances when less than 640 Kbytes of DOS base memory is
 normal, such as with certain settings of the setup or in certain
 compatibles, especially when booted from a diskette (Acer, some Dell
 models, HP etc.).

 The third entry is the current database file name. This filename may be
 changed through IVMENU by selecting Rename from the Integrity Check
 menu. IVMENU will prompt for a name, or ask to press Enter to reset to
 the IVB.NTZ default filename. See also for "extra security" in the IVB
 topic.

 The fourth entry indicates the available space in bytes on the target
 drive. In case the available space on disk decreases, a Disk space
 lost! message will come up, indicating the number of bytes "lost". In
 case lost space is reported, one should be aware of the possibility of
 virus piggybacking. IVB or IVSCAN will stop the scanning process in
 case piggybacking is detected.

 The fifth entry indicates the frequency of the full disk Integrity
 Check. If InVircible was properly installed, it should be either DAILY
 or WEEKLY. If not, re-INSTALL InVircible as detailed elsewhere.

 The last entry checks for the license status and will indicate
 "licensed" or "detection only". The empty field at the bottom is
 reserved for warning messages.


 3.3 The Last IVB, IVSCAN or IVX Report.

 The last report generated by either IVB, IVSCAN or IVX can be viewed on
 screen through IVMENU. Select the Last Report in the Integrity Check or
 Virus Scan mode. The IVX report can be viewed in either modes by
 pressing the X key and then Enter. The report files are written to the
 target's root directory and named IVSCAN.RPT, IVB.RPT or IVX.RPT. The
 report file can redirected to the printer by DOS command, either PRINT
 filename or TYPE filename > PRN.

 4. InVircible Installation

 4.1 Installation to Hard-disk.

 Insert the InVircible diskette in drive A or B. Log-in to that drive.
 Run INSTALL to begin the installation.

 The INSTALL program will prompt for the directory to install to. Type
 the full pathname of the preferred location or just press Enter for the
 default, when prompted.

 The Utilities sub-menu, has the following options:

     a. The Batches sub-menu. Enables the insertion/removal of the
        IVTEST command to/from batch files in specified directories. The
        installation of the IVTEST probe in batch files is optional.
        IVTEST will be installed in its "quiet" mode. IVTEST messages
        will be displayed only if suspect activity is detected.

     b. The Rescue-Disk sub-menu, for the preparation of the diskette.

     c. The On-line Registration sub-menu. Enables the on-line licensing
        of InVircible by telephone. Call your local dealer for more
        details.

     d. The Key Installation/Removal sub-menu. Enables either the
        installation or removal of the InVircible license to/from the
        hard drive. The process is reversible.

 4.2 Installation To or From LAN Server.

 InVircible is a universal anti-virus, recommended for both single user
 PCs as well as for all popular LAN brands.

 INSTALL enables the installation of InVircible to a file server or to a
 workstation in a network. The default is installation to a single user
 PC's hard disk.

 Select where to install InVircible (singe user PC - the default -, to
 a file server, or to a workstation in a network) from the Install
 sub-menu. Note that the installation (or removal) of the license to the
 hard disk can be done from the original diskette only.

 InVircible may be installed to any chosen directory on the server. The
 contents of the server should be secured by the LAN manager.

 All stations connected to the network and equipped with a hard-drive
 need individual licensing. The file server does not need the
 installation of the registration key. Any workstation in the network
 having a hard disk may be infected prior to logging-in to the network.
 Therefore, any such station needs its own InVircible installation.

 For LAN administrators: It is possible to install InVircible to all
 workstations, from the server. The IVLOGIN utility is provided with the
 distribution floppy. IVLOGIN checks if there is a hard disk and whether
 IV is installed on it. In case it is not, IV will be installed
 automatically with its default parameters. Add the IVLOGIN command in the
 LOGIN script, with the full pathname where the IVLOGIN.EXE file is
 located. IVLOGIN must be in the same directory as the IV files.

 4.3 Installation Under OS/2.

 The InVircible INSTALL procedure must be run from a plain DOS
 environment. If INSTALL is attempted from OS/2, a warning message will
 request the user to boot from DOS and try again.

 4.4 Installation in the Sentry Mode.

 There are instances when only the detection and alerting functions of
 InVircible's are needed. To install InVircible in the sentry mode
 (detection only), just skip the key transfer step in the installation
 procedure by running INSTALL/FAST or by leaving the write protect of
 the InVircible diskette in the protect position. The retraction of the
 license from the hard disk back to the diskette will also switch
 InVircible to the sentry mode.

 The sentry mode is indicated by the "Detection only" label instead of
 "Licensed", in IVMENU's Caution Panel and in the upper left corner of
 the program's panel.

 5. Recommended Anti-Virus Strategy

 5.1 In the Single User Environment.

 Install InVircible to the hard drive, as instructed above. The INSTALL
 utility will edit the AUTOEXEC file, after prompting for permission,
 and add the necessary commands for automatic tests to be run on the
 computer initialization. None of the InVircible programs will load
 itself and stay resident in memory. Once it completed its function, it
 will unload and leave the maximum of available memory to the
 applications.

 From now on, InVircible will detect and correct the most severe
 problems right at initialization. These include partition or boot
 sector tampering and certain operating system changes. Boot viruses
 such as Michelangelo, Stoned and Monkey will simply be purged from the
 disk immediately at startup.

 It some cases, InVircible may just alert, without correcting, on the
 presence of a suspected activity in the computer. Such alert is
 accompanied by a message describing the generic nature of the problem
 and the recommended corrective action.

 On first booting at any given-date, IVB will scan through all the hard
 disk local partitions. On successive initializations on the same date,
 only the root directory will be scanned. Added programs will be
 automatically secured on the daily scan. If weekly scans are preferred,
 change the DAILY argument to WEEKLY, in the AUTOEXEC file.

 Read Only drives (CD ROM): CD drives cannot (and need not) be secured.
 The INSTALL utility will normally detect ROM drives and disable their
 daily check. In case it hasn't, just add a space and a dash at the end
 of the daily command. For example, if D: is a CD drive, modify the
 command as follows:

                        IVB C: DAILY -

 Make frequent data backups. Data should be backed-up at reasonable
 intervals. Programs should be backed-up only once or kept preferably on
 the original distribution disks.

 It is highly recommended to regularly run a FAT backup program, such as
 MIRROR from DOS 5 or IMAGE from Norton Utilities, from the last line of
 the AUTOEXEC.

 The InVircible system uses a unique virus-activity probe and sampler,
 called IVTEST. Since the reliability of memory-resident activity
 monitors is limited only to known viruses, and some of them are
 obtrusive or risky, there is need to verify from time to time, that a
 viral process is not spreading in the system. This is achieved by the
 automatic running of IVTEST, from frequently used BATCH files. The
 INSTALL utility will add the appropriate command into specified
 directories.

 5.2 In a Network Environment.

 Any workstation equipped with a hard disk, should have its own
 InVircible installation. The InVircible distribution diskette for LAN
 installations has multiple license keys, according to the number of
 licensed users. The license key should be installed only to local hard
 disks, in workstations equipped with.

 It is recommended that the LAN manager run a daily IVB inspection of
 selected directories of the server. This can be done by adding command
 lines in the network schedule file or script. IVB returns an errorlevel
 exit-code. Errorlevel 0 means no findings, and anything else may
 indicate virus activity. Test for errorlevel 1 in batch or script files
 for suspect activity alerting.

 It is normal to find modified files in users directories, especially if
 they develop software. On the other hand, modified files with a
 consistent change pattern should alert on the possibility of a virus in
 the system. IVB will assess whether the changes may be a new version of
 a former program. IVB will then prompt if to renew the database file
 for that specific directory.

 5.3 In the Institutional Environment

 Most institutional installations involve combinations of single users
 and network users, requiring an anti-virus plan that is a combination
 of the preceding strategies. Many large institutions also have an
 anti-virus policy requiring that virus related problems be dealt with
 only by qualified personnel. In this situation the InVircible license
 key is not installed or is removed from systems not authorized to deal
 with virus removal. Systems running IV in the sentry mode are still
 protected, but recovery of these systems from virus attacks is
 performed only by qualified personnel with access to an InVircible
 licensed floppy.

 Especially useful in an institutional environment are IVX and ResQdisk
 (see Sections 8 and 9). These utilities provide indispensable help to
 the institute's computer security experts for the recovery of "lost"
 hard drives and for tracking down sources of infection, especially of
 new vi ruses.

 5.4 In Unattended Installations (e.g. Bulletin Board Systems - BBS).

 There are instances when the operation of a PC is unattended, such as
 in bulletin board systems etc. The daily inspection of IVB may in such
 cases pause the system, if the system was rebooted and IVB found
 changes in programs, when compared to their store signatures. To bypass
 the pause use the /nostop switch on IVB's command line in the AUTOEXEC,
 as follows:

                     IVB C: DAILY /NOSTOP

 6. IVB - The File Protection & Restoration Program.

 IVB will secure, authenticate and restore executable programs from
 virus infection and virus-like modifications, except for FAT/directory
 manipulators (see Section 10).

 IVB takes a 66 byte "snapshot" (signature) of critical information from
 each executable file and stores this information in each directory's
 InVircible database. This process is called "securing". The information
 is then used during "authentication" (also called "validation") to
 determine whether a file is modified by a virus. The database is also
 used to "restore" files that have been modified by viruses.

 Viruses are characterized by unique properties: They replicate into
 other programs, they modify the host program and they normally affect
 more than one program. All these anomalies are unmistakably detected by
 IVB.

 Common viruses will usually increase the size of a file, while
 Trojan-Horses typically decrease the size of a file by overwriting it.
 If IVB detects that more than one file is "modified" or "changed in
 size", then virus activity is indicated.

 A single modified file, or an inconsistent change pattern, may be a new
 version of an existing program. IVB will usually detect a version
 change and suggest to resecure the directory.

 IVB restores programs that have been secured. Prior to restoring files
 with IVB, scan first with IVSCAN to assure that the virus is not of a
 known type. Recovery with IVSCAN should be tried first, before
 restoring with IVB. The IVB command-line syntax is:

              IVB [-] [drive:\directory] [/option]

 The default drive and directory are the current ones. The various
 options are:

      none for authentication (the default),
      /S for secure,
      /R for restore,
      /D for delete and
      /V for the removal of the database files.

 Let IVMENU guide you through the options.

 The Delete option will erase files that have been decreased in size
 (potential Trojans) or files that cannot be restored safely.

 The [-] switch (space followed by a hyphen) indicates to IVB to operate
 on the specified directory only without continuing to any other
 directory or sub-directory.

 IVB will automatically secure added files when run in the default mode.
 The secure mode is to be used in case IVB indicates a modified file,
 which is a replacement rather than a modified one. Use the single
 directory switch to resecure a single directory by selecting it through
 IVMENU.

 IVB is tamper-resistant and will replace the database file of a
 particular file, if tampered with.

 IVB secures executable files (COM, EXE, SYS) only.

 Before attempting the recovery of a file by IVB you will be prompted
 with three options: Restore, Skip or All (restore all).


 6.1 The IVB Extra-Security Feature.

 IVB has an extra security feature which allows the user to define the
 name of the database files. The default name is IVB.NTZ. This will
 prevent the destruction or modification of the IVB database files by a
 dedicated virus. It allows the user to define a unique database file
 name, other than the default. To set a different name to the database
 files use the Rename option from IVMENU's default. The database
 filename in use is indicated in the Caution Panel of IVMENU.

 6.2 Off-line Backup of the InVircible Database.

 There are instances when an off-line backup of the database- files tree
 is desirable. Making such a backup is easy using the Off-line Backup
 option. Use IVMENU to produce an exact replica of the database file's
 tree on a previously formatted diskette in either floppy drive A: or
 B:. If necessary, the database files may be restored to their original
 locations by the Restore option of the Off-line Backup mode from
 IVMENU.

 A typical 200 Mbytes disk partition will require about 200 Kilobytes of
 space for an off-line InVircible backup.

 Attention LAN managers: An off-line backup for a typical 1 Gbytes file
 server can be contained on a single 1.44 Mbytes diskette.


 7. IVX - The Correlation Scanner.

 IVX is a generic correlator, based on the comparison of files to a
 sample known to be infected. This way, IVX detects all the files that
 were infected by the same virus and can even trace down the source of
 the infection. IVX is ideal for isolating new viruses, or disinfecting
 a machine with no previous installation of InVircible on it.

 InVircible generates its own samples through IVINIT and IVTEST, either
 or both Virusample and Vir-Code. A file designated by IVB as changed,
 may also be used as a valid sample.

 IVX runs from either the command line or from IVMENU. The command line
 syntax is:

       IVX [pathname of sample file] [drive:\directory to search]

 Wildcards (*.?) are allowed in the sample's pathname.

 The IVX report is displayed in a graphic format, after the correlator
 completes its scan. You may also want to review the IVX report through
 IVMENU.

 Suspected files may be renamed through IVX to non executable extension
 names: COM to IVC and EXE to IVE. IVX will prompt before actually
 renaming a file. The renamed files may be safely copied to a floppy and
 sent or e-mailed to us for further analysis and evaluation.

 The detection threshold of IVX can be adjusted in a range from 1%, for
 highly polymorphic viruses, to 100%. The default is set to 20% of
 correlation.

 Tips for using IVX.

 The correlator is a powerful tool in the hands of a trained user and
 its findings are usually conclusive from the very first run. Yet, you
 should be aware that virus writers make great efforts to conceal their
 virus' presence. Therefore, do not expect a perfect match, but rarely,
 when using IVX with real viruses. The results of IVX should be regarded
 as relative, i.e. the files with the higher correlation are the more
 likely to be infected. Plain viruses may exhibit anything from 40% to
 100% correlation to the sample, while highly polymorphic viruses may
 have as low as 4%. The conclusive evidence is that non-infected files
 are in even lower correlation with the sample.

 Before launching IVX, spot a few infected files that could be used as
 samples. The easiest is to look for them in the DOS directory.
 Frequently used files are usually the first victims of an infection.
 Boot from a clean DOS floppy and run IVX from a write protected or IV
 Armored floppy.

 When dealing with a virus that infects both COM and EXE files, prefer
 an infected EXE file as the sample, as it contains more relevant
 information than infected COM. The results will be more conclusive than
 with a COM sample.

 Before renaming suspected files through IVX, try a few runs with
 different detection thresholds. Review the report to chose the best
 threshold. The best is when all infected files are captured and the
 report contains no false positives. It's preferable to replace a few
 extra files in case of doubt, than to risk reinfection.

 Examples:

 Legend: ▓▓--Statistics, ▒▒--Encryption, ░░--String.

 C:\JERUSALEM\
 ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░░░                    60  CHKDSK.EXE
 ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░░░                    60  EMM386.EXE
 ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░░░                    60  EXPAND.EXE
 ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░░░ 100 DISKCOMP.COM
 ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░░░ 100 MODE.COM
 ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░░░ 100 MORE.COM

 The first example is of the Jerusalem virus. It infects both COM and
 EXE files. The sample used in this illustration is Virusample file,
 created automatically by IVTEST. The report shows 100% correlation of
 the COM files and 60% for EXE, since Jerusalem is a plain non-encrypted
 virus. If we had used Vir-Code instead, the results would be 100%
 correlation for EXE and 60% for COM, as Vir-Code is an EXE style
 sample, while Virusample is usually a COM one. The threshold was set to
 50%, to filter out false positives.

 C:\MALTESE\
 ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒                            40  FORMAT.COM
 ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒                            40  MODE.COM
 ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒                            40  MORE.COM
 ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░░░ 100 DELTREE.EXE
 ▓▓▓▓▓▓▓▓▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒                    56  EXE2BIN.EXE
 ▓▓▓▓▓▓▓▓▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒                    56  EXPAND.EXE
 ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒        80  FC.EXE

 The second example was taken from Maltese Amoeba (alias Irish) and is
 especially interesting. Irish is heavily encrypted, although it is not
 considered as polymorphic. DELTREE.EXE is used as the sample. Note the
 dispersion in the correlation factor. Note also that the largest common
 correlation is contributed by encryption (the middle shading). As a
 rule, encrypted viruses will show no contribution from string matching,
 with most of the similarity due to encryption, and sometimes some
 contribution due to statistical matching. The threshold was set to 30%
 in this case.

 Practicing IVX.

 It may be worth to practice with IVX so that you know what to do when
 the real thing happens. You may use IVX to trace down files that were
 processed in the same way. For example, all InVircible files, except
 IVHELP, were processed by LZEXE runtime compression. Try the following:

                        IVX C:\IV\IVB.EXE C:\

 All the files that correlate higher than 65% are treated by LZEXE as
 well. Now, if you correlate with IVHELP.EXE as the sample, IVX will
 find programs that were processed by PKLITE. You will find a few of in
 the DOS directory.

 Other compression schemes that can be used to practice IVX are: DIET
 and Microsoft's ExePack. Correlate to \DOS\EXPAND.EXE for ExePack and
 set the detection threshold to 70. For DIET, correlate to Frisk's
 F-PROT.EXE (if you got a copy) and set the threshold to 50.


 8. ResQdisk - The Boot-Areas and CMOS Maintenance Program.

 ResQdisk is a compact yet extremely powerful utility capable of
 repairing damage to the hard disk partition or boot sector, removing
 known and unknown partition or boot viruses, restoring self booting
 capability to hard disks and regaining access to "lost" hard disks.

 ResQdisk deals uniquely with hard disks drives, not with floppies.

 Disks are organized in sectors, which are 512 bytes data storage units.
 Any DOS hard drive has two such vital sectors: the master boot sector
 (sometimes referred to as the partition table) and the boot sector.
 Floppies have only a boot sector. These sectors are favorite targets
 for computer viruses, since they contain tiny programs that load first
 at booting time. A damaged or missing sector will return an "invalid
 drive specification" message, fail to boot, deny access to the hard
 drive or simply read trash from the disk.

 For maximum safety, the boot area images are written to the Rescue
 Diskette, since an inaccessible disk will deny access to the backup
 written to itself. ResQdisk's options are displayed on the menu bar, at
 the screen's bottom. Press F1 or "/" to see more options.

 The F1-F2 key sequence will backup the boot areas and the F1- F3
 sequence will restore from backup images to disk. Each sector can be
 individually backed up or restored by shifting to the desired sector on
 screen (use the cursor direction keys) and pressing either B for backup
 or R for restore.

 Every disk has a unique partition and boot sector. Do not attempt to
 swap or copy boot areas between hard-disks. This might end up with an
 unreadable contents of the transplant's receptor.

 8.1 Reconstruction of the Boot Block.

 ResQdisk has special routines for the reconstruction of the hard disk
 partition or boot sector, in case they have been damaged or cannot be
 recovered. For example, incidentally booting a disk which is infected
 with Stoned with a floppy infected by Michelangelo will not boot
 anymore by itself, although it can be booted from a DOS floppy.
 Attempting to restore the partition with the FDISK command may end up
 with the complete loss of the whole disk content.

 ResQdisk makes it easy; all that is needed is the following keys
 sequence:

             Press the 'Home' key, then F1, then F4

 Tampering with the boot sector is corrected by the sequence:

                     Left arrow, F1, F4

 8.2 ResQdisk's Special Functions.

 It may happen that the disk setup parameters stored in the CMOS become
 invalid because of a weak battery, a setup error and sometimes even bad
 software. If this happens then reboot the computer from the rescue
 diskette and press <Enter> when IVMENU finished loading into memory.
 Answer yes to the query "Attempt to restore the CMOS data?". The
 computer will then automatically reboot with the restored CMOS
 parameters.

 To see ResQdisk special functions menu press the "/" (slash) key.

 Warning! ResQdisk should not be used on disks that have a boot area
 password or access control device installed on them. These devices are
 highly susceptible to cause total loss of the whole disk content. As a
 rule of thumb: If a hard disk can be accessed after booting from a DOS
 floppy, then the partition refresh procedure may be used safely.

 8.3 ResQdisk's Setup Utility.

 ResQdisk has a built-in setup calculator. This may be especially useful
 with IDE hard drives, in case the CMOS data was erased or nullified and
 there is no available data on the drive parameters. All that is needed
 is to select a random disk type from the setup table, boot from a DOS
 floppy and run ResQdisk. The F5 function key will identify the
 manufacturer's parameters of the hard disk. All that is needed now is
 to set the CMOS data to the correct type and restart the computer.

 ResQdisk can also be used to regain access to an inaccessible hard
 drive, whether either the partition sector or the boot sector was
 damaged. ResQdisk will indicate "Press Ctrl F1" or "Press Ctrl F2" to
 rebuild the partition or the boot sector respectively.

 9. IVSCAN - The Virus Detection and Removal Scanner.

 While disinfecting a computer, with IVSCAN or else, the user must be
 aware of the possibility that a virus might be active in the computer's
 memory (memory-resident). Since a virus in memory has taken control of
 the computer, a general rule is to reboot an infected computer from the
 write- protected Rescue Diskette, or from a clean write-protected DOS
 diskette. The disinfection of a hard-disk must be per formed only from
 the Rescue Diskette and not from the suspected drive itself, unless
 InVircible's programs specifically recommend execution in an infected
 environment (e.g. Inverse Piggybacking).

 Detection of, and disinfection from known and common viruses is done by
 IVSCAN. The program is activated via IVMENU or directly from the
 command line. The command line syntax is:

              IVSCAN [-] [where and what to scan] [/Option]

 Parameters in [ ] are optional. If no option is chosen IVSCAN will
 detect viruses without removing them (the default). The default scan
 path are the current directory and its sub-directories. The use of
 wildcards (*,?) is allowed in specifying where and what to scan for.

 The options are:

          /R to restore the file (if it can),
          /D to delete infected files that IVSCAN cannot recover,
          /B to recover or replace a suspected boot sector in floppies,
             or MBR on hard drive.
          /EX to scan executable files only.

 The [-] parameter will limit IVSCAN to process the specified directory
 only.

 Examples: To scan the entire C: partition for viruses in the Detection-
 Only mode type:
                           IVSCAN C:\

 To use IVSCAN for detecting and eliminating viruses automatically only
 from COM files in the DOS directory, type:

                    IVSCAN + C:\DOS\*.COM /R -

 The space before the hyphen is required. If the hyphen is not used,
 this command will cause IVSCAN to begin at the specified directory and
 scan all subsequent sub-directories.

 If IVSCAN indicates "use IVB to restore" and the affected files were
 properly secured, then restore them with IVB (see Section 6). Use the
 Delete option as a last resort. A list of infected, deleted and
 restored files will be written to a IVSCAN.RPT file in the root
 directory of the processed drive, to help you replace the deleted
 files.

 Before attempting the recovery of a file IVSCAN will prompt you with
 three options: Recover, Skip or All (recover all).

 9.1  Removal of Generic Boot Viruses.

 Boot viruses are transferred from one computer to another by
 accidentally booting from an infected floppy (the infected diskette is
 left in drive A and the computer is rebooted), even if the floppy is
 not bootable, just infected! IVSCAN provides for the replacement of the
 boot sector in floppies with a standard DOS boot sector. The same
 procedure will remove generic boot infectors and even restore
 readability to 3.5" floppies that were hit by boot infectors such as
 Michelangelo. Just type:

                       IVSCAN drive: /B

 IVSCAN restores files infected by viruses included in its repertoire.
 For infectors unknown to IVSCAN use IVB.


 10. A Primer to Generic and Special Methods.

 Generic techniques can cure damage from groups of viruses such as
 boot-block infectors, stealthy file infectors and FAT manipulators.

 First, assess the type of infection by its symptoms, then test the
 suggested method on a sample diskette or directory. If successful,
 apply the selected technique onto the entire infected disk.


 10.1 Generic Method Selection

 As a rule, viruses always disclose there presence sooner or later.
 InVircible provides alerts when sensing various effects that are
 unmistakably related to computer viruses. Among InVircible's messages,
 the following are of special interest:

 (1)  "... Kbytes are missing from total available memory."
 (2)  "A stealthy virus is active in system."
 (3)  "File size changed by 0 (zero!) bytes ... "
 (4)  "Free disk space decreased by ... bytes, program halted!"
 (5)  "Partition (or boot) sector is faked!" (6)"The disk is infected by
       a boot infector!"

 Message (1) indicates "memory stealing", attributed mostly to the
 presence of a boot or partition infector. Certain file infectors do the
 same, and this possibility should be first discarded. Also, some
 programs such as DesqView, or certain BIOSes (PS, Dell, Acer and some
 laptops) cause the same without being related to virus activity.

 Message (2) or (3) indicate that a stealthy virus is active in the
 system.

 Message (4) indicates that a piggybacking process was detected and the
 search was halted to prevent further spreading of the virus.

 Message (5) indicates the presence of a stealth virus in one of the
 boot area sectors. Message (6) will be displayed when an unknown boot
 infector is found in one of the boot areas of the hard disk or of a
 floppy.

 In case the virus is common, InVircible will recommend on the
 corrective action. If not, then proceed as follows.

 It is recommended that less experienced users ask for assistance or
 leave the following procedures to qualified personnel, since dealing
 with smart viruses requires training and inexperienced users may do
 more harm than good.

    For the expert user.

    If one or more of the above messages are returned, then proceed with
    the following tests.

    Run IVB in its default mode with the virus in memory and watch if
    "modified files" are reported. In case such files are reported with
    the virus in memory, the virus is not a perfect stealthy one and
    cannot be restored by the Inverse Piggybacking or by the Integrity
    Interrogation generic methods.

    Next, boot from the Rescue Diskette and run IVSCAN to eliminate the
    possibility of a common infector. In case that IVSCAN reports the
    possibility of an unknown boot or partition infector, then proceed
    with the generic boot- block recovery.

    Non-perfect stealthy viruses can be recovered by IVB if the disk
    contents was previously secured.

    If the virus is a perfect stealthy (only), select either the Virus
    Interrogation technique or the Inverse Piggy- backing. Always try
    first on a floppy, which is the best technique to use for a
    particular virus.

    Beware of FAT manipulators! Run CHKDSK on the damaged unit, without
    the /F switch, when booted from a clean DOS diskette. Watch if file
    allocation error or cross-linking of executable files is reported.
    If yes, this may be the doing of a FAT manipulating virus.

    Do not attempt repair with disk fixing utilities if infected by a
    FAT manipulator. Any such attempt will end in massive and
    irreversible damage.

 In all cases, it is advised to test the selected method on a sample
 diskette and if successful, to apply it to the infected units.


 10.2 Generic Boot-Block Recovery

 InVircible and DOS provide for the recovery of both the Master Boot
 Sector, also known as the partition table sector, and the plain Boot
 Sector. Both sectors are found only on hard disks, while floppies have
 only a boot-sector.

 Floppies:

 IVSCAN provides for the recovery of a large spectrum of known and
 generic boot infectors, and will suggest the replacement of the sector
 with a standard DOS 5 one, in case a potential unknown infector is
 found. Hard Disk:

 The recovery should always start by inspecting the partition table
 first. Run ResQdisk to get acquainted with the look of both the
 master-boot-sector (MBS) and the system-boot-sector of your hard-drive.
 In case of boot-block tampering, boot from the Rescue Diskette and
 visually inspect both sectors by running ResQdisk. Some infectors such
 as FLIP will cause only minor changes, perceivable only to the expert
 observer, some as Stoned will show a message such as "Your PC is
 Stoned, Legalize Marijuana!". The restoration of both sectors is
 straightforward by ResQdisk .

 There are instances when there is no copy of the original sector to
 restore from, and no Rescue Diskette exists. For example, consecutive
 infections by Stoned and Michelangelo will not leave an original MBS.
 Master Boot Sectors can be restored by ResQdisk, provided the drive is
 accessible and readable after booting from a DOS disk in drive A.

 Enter the ResQdisk program and proceed with the F1 - F4 function keys
 sequence. This procedure is the equivalent of the DOS-5 undocumented
 command: FDISK/MBR.

 Caution! Do not use the ResQdisk F1-F4 procedure in the following
 cases:

 (1)   There is an active virus-prevention TSR in memory. Ad dressing
      the master-boot-sector may be diverted by such TSR and this may
      end in total loss of access to the hard- drive.
 (2)  The same applies for hard-disks with a software password
      installed. Uninstall the password prior to proceeding with this
      technique.
 (3)  Partitioning schemes other than DOS FDISK such as Disk Manager and
      SpeedStor are not suitable for this technique.

 As a safety precaution, first backup the boot-areas on the original
 InVircible diskette by ResQdisk and the F1-F2 keys sequence. The
 current boot areas can be restored later by ResQdisk.

 An alternative way to ResQdisk, for replacing the boot sector is by
 booting from a clean DOS diskette, necessarily of the same DOS version
 as installed on the hard disk and transferring a fresh sector by the
 command SYS C: The Rescue Diskette will normally contain the SYS.COM
 file and it may be used for the purpose. In case of a damaged or
 nullified boot sector, DOS will not let to renew the sector by the sys
 command (the message "invalid media type" is returned by DOS), and
 ResQdisk will become the only way to recover the drive.

 Recovery from Boot Stealth Viruses.

 The procedure that follows will probably never be necessary for the
 licensed user, as boot spoofers are taken care of in IVINIT, right at
 boot time, as well as in IVSCAN. It is brought here mainly as a
 work-around for non-licensed users and to explain the mechanics of boot
 spoofers.

 ResQdisk can be used for the recovery from boot stealth viruses.
 Inappropriate procedures with boot spoofers may cause the loss of
 access to the hard disk, as happens indeed with quite many scanner and
 TSR anti virus products. ResQdisk enables full recovery from viruses
 such as from Monkey, Newbug, Quox and many others.

 The presence of a boot stealth virus is announced by IVINIT or IVTEST,
 with the message "faked partition (or boot) sector". The virus is then
 sampled into a file labeled PARTVIR or BOOTVIR accordingly.

 Run ResQdisk and confirm the presence of the stealth virus by switching
 between SeeThru "ON" and "OFF" - with the F9 key, while watching the
 master partition sector, or the boot sector. Create a backup of the
 infected sector by pressing the "B" key, while SeeThru is OFF. The
 backup content is the true boot sector.

 Licensed users may switch now the SeeThru to "ON" and restore the
 sector from the backup by pressing the "R" key. The original sector,
 rendered by the virus, will be written to the hard disk, in its right
 place. Non-licensed users will have to run the above from a floppy,
 reboot the machine from clean DOS and then restore the original sector
 in place by running ResQdisk from the floppy.

 Exit ResQdisk and reboot the computer without running anything else!
 The computer will restart with a clean boot block. Note that the
 recovery from boot stealth viruses must run with the virus ACTIVE in
 memory!

 10.3 Fat Manipulators Removal

 The FAT manipulating viruses appeared at the end of 1991 and use a new
 method for propagation, based on the modification of the FAT pointers
 chain. There are now at least two widespread such viruses, DIR-2
 (Creeping Death) and 1963 (Niemela). These viruses are inherently
 stealthy and propagate extremely fast. Standard passive scanners are
 useless and harmful against these viruses. Countless hard disks were
 unnecessarily destroyed by the use of passive anti virus scanners
 against these two viruses. MSAV, the virus scanner distributed with
 Microsoft's MS-DOS 6, is an example of a passive scanner. Although it
 detects the 1963 (Niemela) virus and claims to clean it from infected
 files, in reality it ruins all the files it "cleans" from this virus.

 InVircible provides a totally safe and extremely efficient means for
 both the detection and the full recovery from these and other FAT
 manipulators. FAT manipulators are removed by an active Inverse
 Piggybacking process.

 The presence of DIR-2 or 1963 is detected by InVircible programs and
 is indicated by a warning message.

 In case a FAT manipulator virus activity is suspected, do not use the
 DOS CHKDSK/F switch, until the disk is completely disinfected! Using
 the /F switch while a FAT manipulating virus is active will cause
 massive and irreversible damage .

 10.4 Inverse Piggy-Backing (IP).

 The Inverse Piggy-Backing (also called cooperative virus removal) is a
 generic technique embedded in IVSCAN. It is based on forcing the
 infecting virus to disinfect its own doing. There are two available
 methods actually, labeled /M1 and /M2.

 Method 1 is effective against "light" stealthy infectors such as 4096
 (Frodo) and 1963 (Niemela).

 Method 2 is to be used to disinfect from the more "stubborn" ones such
 as DIR-2 and future FAT manipulators. Inverse Piggybacking is selected
 from IVMENU, from the Virus Scanner mode.

 The command line syntax for Inverse Piggybacking is:

                           IVSCAN drive: /Mn,

     /Mn being the method switch and "n" its number, for example, type
     IVSCAN C: /M1 to run method 1 on drive C.

 Inverse Piggy-Backing should start with the virus loaded in memory.
 Start by purposely running an infected file. In most case the operating
 system itself will be infected so that you may proceed directly to
 disinfection.

 The DIR-2 virus will lock up the computer if run under DOS-5 or
 DR-DOS-6. To disinfect from DIR-2 one should boot from DOS lower than 5.

 Method 1 is a single pass procedure. The processed drive will be
 operable after its completion.

 Method 2 requires two passes. On the first one COM/EXE files will be
 processed by the virus itself. A second pass with the IVSCAN /M3 switch
 restore the files to their original state. Disks processed with the /M2
 switch, except partition C,      will require processing with the /M3
 switch to have their executable files restored to original.

 Only partition C will be automatically cycled by M2/M3 processing. The
 IVSCAN.EXE program should reside on drive C for complete and automatic
 processing of this drive.

 Important! Turn off all disk caching before starting Inverse
 Piggybacking. Some disk caches oppose the IP technique. InVircible
 takes care of turning off the SMARTDRV.EXE cache. For other brands,
 consult the cache documentation on how to turn it off. Floppies and
 hard-disk partitions, other than C should be processed first. Partition
 C will be processed last. When finished with C, automatic rebooting
 will occur.

 Caution! Do not run any program, nor address the hard drive until
 rebooted, otherwise the drive will be immediately re infected.

 10.5 The Integrity Interrogation technique.

 This technique is a two step procedure. First, file database are
 established from an infected environment, then the files are restored
 by IVB , from a clean environment.

 The theoretical basis of this method lies in the fact that some viruses
 are so perfectly "stealthy", that they "show" the true uninfected file
 data to the operating system, when inquired about.

 Start by booting the computer from the infected drive itself. Make sure
 the virus is active by running a program known to be infected. IVB
 should be installed on the processed drive.

 Run IVB drive: /S (or the Secure option from IVMENU) on the entire
 directory or drive. Restart from the Rescue Diskette and run IVB in its
 Restore mode.

 10.6 Forced Self Restoration.

 The InVircible programs (except IVHELP, which is licensed from another
 vendor) will normally restore themselves in case they are attacked by a
 virus. In certain cases the program will get infected and stuck, thus
 inhibiting its self recovery. In such cases a little assistance from
 the user will be helpful: just type the infected program's name with
 the /FR (forced recovery) switch. For example, IVB/FR. Switch the
 computer off afterward since the virus may be now resident in memory.


 10.7 Screening New Software.

 InVircible is ideal for screening new software, to assure it is free of
 virus. Software screening is especially important in organizations,
 where viruses are usually introduced with new software, without having
 been screened first.

 The screening of software should be performed on an isolated computer
 (never when logged into a network). InVircible should be installed on
 the screening computer and a rescue diskette prepared for it.

 Install the new software on the hard disk according to its
 manufacturer's instructions, then "secure" it with IVB before actually
 running it. The new software should then be run and all its executable
 modules should be exercised. Reboot the computer from the rescue
 diskette and scan the hard disk with IVB for changes in files. Inspect
 the boot block for changes with ResQdisk. Compare the MBS and boot
 sector by individually "restoring" them from backup and watch for
 changes. Now reboot the computer from its own hard disk and watch for
 InVircible's warning messages. If all tests passed without findings
 then the software is most likely clean from known or unknown viruses.


 11. Importing InVircible into Windows

 InVircible is distributed with IV.PIF and IV.ICO files, to operate
 under Windows. Both files will be copied to the InVircible default
 directory by the Install utility.

 Start Windows normally and import InVircible into Windows by selecting
 New from the File menu and the Browse radio button. Use IV.PIF as the
 command line and IV.ICO as InVircible's icon.

 We also suggest to add Alt+Ctrl+V as the shortcut key, when in the
 properties change menu. Now InVircible can be activated from Windows by
 either double clicking on its icon, or by pressing Alt+Ctrl+V.

 As stated elsewhere in this guide, viruses operate only in the DOS
 environment. InVircible sometimes uses virus cooperative techniques.
 Viruses are not "well behaved" in an environment different from DOS.
 Therefore, it is recommended that only passive tasks such as integrity
 checking or virus scanning is done from Windows. Active disinfection,
 such as Inverse Piggybacking should not be attempted from Windows, but
 only from plain DOS.

 12. Virus Handling Under OS/2

 Computer viruses are often called DOS viruses, which implies that they
 are programmed to operate only under DOS. However, any operating system
 that is DOS compatible is susceptible to DOS viruses when in DOS
 compatibility mode.

 InVircible is compatible with the IBM OS/2+ operating system when in
 DOS mode. Because DOS internals are interpreted differently by OS/2,
 DOS viruses behave unexpectedly in an OS/2-DOS environment. Whenever
 InVircible detects viral activity in an OS/2 environment, proceed as
 follows:

 Simply COLD BOOT the computer from the Rescue Diskette and proceed
 normally with IVSCAN and IVB procedures. All virus disinfection should
 be undertaken only in a DOS environment. Do NOT attempt to boot DOS
 from the OS/2 dual booting system when viral activity is reported or
 suspected. When done, reboot the computer normally.


 13. Central Point Anti Virus Inoculation

 The CPAV Inoculation or self integrity check is the cause of many
 unexplained malfunctions. Many programs do not tolerate being
 inoculated, especially not DOS files, but not only them.

 The inoculation process consists of the encapsulation of executable
 files (COM and EXE) in a protective shell, like a cocoon. The
 inoculation adds about 700 or 900 bytes to COM and EXE files,
 respectively. The inoculation also modifies the programs in other ways.

 Inoculation has many drawbacks and practically no merits. First, the
 700 to 900 bytes added waste a lot of disk space. Second, inoculation
 causes programs to malfunction, especially under MS-DOS-6+. Third, the
 recovery of an immunized file will in most cases worsen the situation.
 In order to drop the virus the infected file must be run, at the risk
 of loading the virus into memory and infecting other files. And last,
 inoculation is useless against smart viruses and is not worth the
 trouble!

 Except for its malfunctions, there are good reasons why not to
 inoculate programs. The inoculation may hide a virus that infected the
 file prior to its inoculation. A dedicated virus may simply peel off
 the inoculation, infect the file and then re inoculate it as if nothing
 happened.

 InVircible will indicate files immunized by CPAV by either scanning
 with IVSCAN or IVB.

 Unfortunately there are differences between versions of CPAV, so it is
 safer to disimmunize files by the same product that inoculated them in
 the first place. Use the following procedure only if there is no other
 alternative, and with all precautions.

 Backup the files to be recovered. IVSCAN will remove the CPAV
 inoculation from files when in the virus "remove" mode.

 14. The Antivirus TSR (Terminate and Stay Resident).

 Memory resident programs (TSR) have been in use since computer viruses
 appeared in 1987. Their purpose is to prevent the penetration of a
 virus to the computer.

 Unfortunately, the TSR virus prevention is based on too many weak
 assumptions. Anti virus TSR look only for viruses included in their
 database. There are today as many as 5000 known viruses and their
 number increases at a constant rate of 50 to 100 per month. This number
 takes a heavy toll on the size of the database attached to the TSR and
 occupies precious memory space.

 Anti-virus TSR can be aggressive, affect the computer's performance,
 interfere with other applications, cause conflicts in memory and are
 potentially dangerous! For example, a typical and common AV TSR slows
 the computer by a factor of 3 to 5 and is notorious for having knocked
 out many hard disks that it was supposed to protect, without the
 slightest trace of any virus. The TSR simply defeated itself by
 derouting interrupt 13 (the one used for disk read and write) to
 deceive boot viruses, and fell in its own trap!

 TSRs need to be constantly updated. The assumption that the producer of
 the TSR will be the first to examine any new virus, proved to be false
 in most cases. The TSR is useless against new viruses, neither will it
 detect a known, but modified virus. Practically, a TSR older than six
 months is out-of-date, in most cases it is already obsolete at the date
 of its announcement. VSAFE, the anti-virus TSR distributed with MS-DOS
 6, is a grim reminder of this fact.

 Anti virus TSR suffer from false alarms and the higher the number of
 viruses a product detects, the higher is the rate of its false alarms.
 The common user has practically no means to distinguish between a false
 alarm and a real virus.

 Furthermore, TSR are incapable of distinguishing between a real virus
 and a faked signature, which explains their susceptibility to false
 alarms. For example, the following string of 10 bytes, when added to
 any program, will mislead McAfee's antivirus products to believe the
 program is infected with the Jerusalem virus. Consequently, VSHIELD
 (the TSR) will inhibit the execution of the program, SCAN will "detect"
 the Jeru-A virus and CLEAN will ravage the file containing the string
 as if it was really infected with "Jerusalem". The faked Jerusalem
 virus string, in hex notation:

                    03 F3 A5 26 C6 06 FE 03 CB 58

 AV TSR got bad reputation over the past years: the number of incidents
 in which anti-virus TSR were the direct cause of severe damage
 surpassed those caused by genuine viruses.

 Weighing the pros and cons for and against anti-virus TSR leads to the
 conclusion that TSR are a constant nuisance and threat to the health of
 your computer. The remote possibility that a TSR will really stop a
 banal virus attack, that could be removed anyway by less dangerous
 means, is not worth the trouble and the risks of the TSR!


 15. Procedures to Use if Virus Activity is Suspected.

 When dealing with computer viruses, awareness is the key to success. Do
 not improvise. Do not panic or act hastily. If there is no apparent
 damage, in most cases no further damage will occur until the computer
 is switched off and rebooted.

 Computer viruses are nothing else than programs themselves. A computer
 will not become infected unless an infected program is executed.
 Reading data cannot cause infection whatsoever!

 If you suspect the computer is infected with a virus, proceed as
 follows:

   a.  Do not switch the computer off immediately. If you have already
       turned off the computer, do not reboot the computer from its own
       hard-disk but rather from the Rescue-Diskette or from a clean and
       write-protected DOS floppy.

   b.  Save the data of the last job you were working on and exit
       normally from the application you were in. Do not start a new job
       as long as the computer wasn't verified and cleaned.

 The following steps will enable you to recover from a virus event with
 the minimum of disruption:

   a.  Have the Rescue Diskette always ready as well as a copy of your
       favorite backup program, both on write protected diskettes.

   b.  Boot from the Rescue Diskette and backup all important data.
       Programs can always be reloaded from original disks, data cannot.
       Copy several infected files to a diskette for later inspection.
       Do not start disinfecting the computer without completing the
       above steps. There is a possibility that irreversible things may
       happen in the course of virus removal. In fact, most of the
       damage caused by viral incidents is the result of inappropriate
       disinfection procedures.

   c.  After the system is cold rebooted from the Rescue Disk, first run
       IVSCAN to test for common viruses. Remove the viruses as
       described in section 10. Next run IVB.

   d.  After disinfection, do not hurry restoring files from backup,
       without verifying its contents first! The backups are likely to
       contain the same virus you just removed. Consider rebuilding your
       applications from the original software manufacturer's diskettes.
       Retain data only from the most recent backups, to minimize the
       possibility of repeated infections from your own backups.

 Viruses propagate in many ways. Smart viruses use stealth, self
 encryption or both. The more programs run, the higher the chances are
 of unintentionally activating a virus.

 Do not use shell programs or utilities while disinfecting a computer,
 certainly not from the infected disk itself. Do not run any program
 from the infected disk.

 Use plain and internal DOS commands such as DEL, REN, COPY etc. If you
 feel uncomfortable with these limitations, ask for assistance from a
 more knowledgeable user. All programs should be run from
 write-protected diskettes and reliable sources. The only exceptions are
 when explicitly instructed to work from an infected environment, such
 as for Inverse Piggybacking or Virus Interrogation, as explained
 elsewhere.

 Be consistent! Do not mix InVircible with other anti-virus software or
 hardware. Unraveling the results of mixing anti- virus methods is
 similar to attempting a medical diagnosis for an intoxicated patient
 that has swallowed multiple self- prescribed drugs.

 A virus in memory is a virus in control of the computer, while you may
 believe you are. Viruses are extremely deceitful programs, and will
 mislead even experienced users.

 Many viruses seek to infect the command interpreter. This is the file
 denominated by the environment string "COMSPEC" when typing the SET
 command. Therefore, it is good practice to replace the COMSPEC file
 from an original diskette. Also, rename the AUTOEXEC.BAT and the
 CONFIG.SYS to non-executable names until disinfection is completed.

 16. Practicing InVircible, the AV Practice Lab (AVPL).

 NetZ Computing provides a practicing environment named the Anti Virus
 Practice Lab (AVPL). AVPL is complementary to antivirus software and was
 developed for the purpose of practicing anti virus techniques in general
 and InVircible's in particular.

 It is best used in concert with InVircible. Yet it can be used with any
 AV product to learn about viruses and how to protect your PC and network
 against them.

 AVPL is a self contained tool that will let you practice several virus
 attack scenarios and how to recover from them. Although AVPL is designed
 to be used with the advanced generic anti-virus tools of InVircible, it
 can also be used to evaluate AV products in general.

 AVPL allows to "infect" selected computer programs in a virus like way,
 to install master boot sector (MBR) infectors to the hard disk, and to
 practice InVircible to identify the simulated viruses and recover from
 them. The "infections" produced by AVPL are ultimately harmless. The
 viruses created by AVPL will not replicate. They can not spread through a
 process of spontaneous replication to other programs or disks. They will
 only affect the program files in a target directory selected by the user
 and the hard drive of the system on which AVPL is installed. Therefore,
 the user can be assured that only those programs and the hard disk of
 their system can be affected by AVPL. AVPL will ONLY affect program files
 and the hard drive chosen by the user.

 Programs that are affected by AVPL can be "cleaned" either through the
 use of the Uninstall option of AVPL, through InVircible or through the
 DOS delete command.

 MBR infections that were installed by AVPL can be removed as well by
 AVPL's Uninstall option, or through the use of the ResQdiskette. It is
 important that you prepare a Rescue Diskette before you begin
 experimenting with AVPL.

 Prior to experimenting with AVPL please read its on-line hypertext guide.
 AVPL is available from all InVircible distributors as well as from
 anonymous ftp sites on Internet and BBS. AVPL is freeware, the file name
 of the package is AVPL101.ZIP.


 For Computer Security Experts and Advanced Users.

 Rehearse with real viruses on an isolated (not in a network) computer
 to get the feel of what a virus attack is like. Virus simulating
 programs are worthless in the forming of computer security experts. On
 the contrary, any anti-virus program that responds to a simulated virus
 is also susceptible to false alarms and will destroy programs in an
 attempt to remove an imaginary virus. Experiment only with
 "controllable" viruses such as Stoned, Jerusalem and Frodo (4096).

 And last, prepare a recovery plan and simulate it on a small scale,
 prior to being hit by a real computer virus. When the real thing
 happens, you will feel much more at ease if you have an idea of what a
 real virus attack is like and have practiced before.


 Appendix A. - LAN Protection

 The following describes how to implement InVircible for the protection
 of local area networks (LAN).

 At this date, there are no known viruses that affect the operation of
 Novell's Netware software. Yet, DOS viruses may affect executable and
 non executable DOS objects, stored on file servers. An infected object,
 such as a DOS shared application, when executed, can further spread the
 infection, from one workstation to another networked station.

 As a general rule, boot and MBR infectors, excluding multipartite ones,
 will not propagate through the network from one station to another. The
 effects of such viruses are retained locally and will not extend
 outside of the affected workstation. A file server can even be started
 with its MBR infected by Stoned or Michelangelo, and none of the other
 stations will suffer anything or even notice there is something wrong
 with the server hard disk!

 On the other hand, many file viruses can survive the Netware login
 process, or become active when already logged onto the network, and
 infect files on either the local disks, or on the file server.

 Virus Propagation in a Network.

 File viruses are usually categorized as direct action viruses and
 memory resident viruses. Some memory resident viruses are also known as
 "fast infectors" or piggybackers. All three terms refer to the
 propagation mechanism of file viruses. Direct action viruses infect
 additional file(s) every time an infected file is executed. Since the
 virus is not memory resident then the infection of more files will not
 occur on the execution of a program that is not actually infected. The
 criteria and pattern upon which additional files become infected can be
 anything: i.e. infecting files in the current directory, down the
 directories tree, along the DOS search path, at random etc.

 Memory resident viruses usually load into the workstation's memory,
 when the first infected file is executed. It doesnÆt matter where from
 it is executed, either from the local disk, or from the remote disk of
 the file server. From then on, any file that will be executed and fits
 the infection criteria of the particular virus (that is now
 memory-resident), will become infected itself. Many memory resident
 viruses have a direct action mode of infection too, in addition to the
 memory resident infection mode, as described above.

 Piggybackers are memory resident viruses that will infect any file that
 is "opened" or "closed" by the operating system. The programs that are
 the most likely to become carriers of fast infectors are virus scanners
 of all sort, as these programs are the only ones that ôopenö and
 ôcloseö every single program on a drive, while scanning them! It is
 thus essential that antivirus scanning programs, whether scanners or
 integrity checkers, be equipped with anti piggybacking features. For
 the moment, only InVircible has this ability.

 ItÆs reasonable to assume that all programs that were loaded to a file
 server were clean from viruses at the time they were loaded. Then how
 come that later on, some of these programs become infected? The answer
 is simple: An infection that originated from one of the workstations
 found its way to an application on the file server. If another
 workstation called and executed the infected program on the file
 server, then that stationÆs memory - and eventually its hard disk -
 will become an additional source for the spreading of the virus. Later
 on, the newly infected station will infect additional applications on
 the server.

 The most common pattern of how massive infections occur on file
 servers, and spread across the network to all workstations, is because
 of unaware network supervisors and the excessive use of virus scanners!
 the classical scenario is as follows: A new virus manages to infect a
 workstation. Most network managers unjustifiably rely on their
 scanner(s), anti virus TSR and on antivirus NLM. Being misled by a
 false sense of security, they overlook and reject the possibility that
 the scanner itself may be the source of an infection. Over
 self-confidence and ignorance are usually the excuse for not
 implementing better antivirus means than NLM scanners and TSR. Sooner
 or later, the supervisor will log-in with full read-write rights
 (supervisor or not ?!) and scan for viruses with a piggybacked scanner.
 The results are obvious.

 The lessons to be learned are:

 1. Since virus infections in network always start from a workstation,
    then workstations should be checked for virus presence prior to
    connecting to the network. Especially those PC that have local hard
    disk, as their chances to become infected are infinitely higher than
    those that boot from a network startup floppy, or from ROM-DOS.
    Antivirus that are initialized from the network, upon login, are
    stupid, insufficient, and worthless. The same applies to NLM too.

 2. Virus scanning of file servers should be run sparingly and with
    utmost precautions. Since piggybacking cannot be sensed on file
    servers, for technical reasons, then scanners should always be
    tested first on a local hard disk (never from a floppy) to give a
    piggybacker the opportunity to disclose its own presence. Only
    piggybacking resistant scanners should be used on file servers,
    unfortunately there is only a single such product on the market -
    IVSCAN from the InVircible package.

 Antivirus Protection in a Networked System.

 The strategy of how to protect a networked system from virus attacks
 consists of a few simple steps.

 First, have InVircible installed on all stations that have a hard disk.
 This way, every such station will be verified before the station has a
 chance to connect to the network and can contaminate the server. To
 facilitate the task, InVircible can be installed directly from the file
 server, to workstations having a hard disk. IV is provided with the
 IVLOGIN.EXE program. All that the supervisor need to do is to install
 IV into a dedicated directory on the server and invoke the IVLOGIN
 program from within the users login script. The following explains how
 to do it in a Novell network, every LAN manager knows how to adapt it
 to his own network brand. Suppose IV was installed to F:\PUBLIC\IV. Run
 SYSCON and select "Supervisor Options" from the menu, then select "User
 LOGIN Script". Add the following line into the script:

                       # F:\PUBLIC\IV\IVLOGIN.EXE

 Instead of virus scanning, better is to secure and verify the file
 server content with IVB, the integrity analyzer and generic restorer.
 This can be done by issuing the command:

                     C:\IV\IVB F: DAILY

 It is recommended to run InVircible's Off-line Backup periodically,
 once a week, or twice a month. The Off- line Backup will produce a copy
 of the directories tree on floppy, with their respective signatures
 files, in case these were lost or tampered with. See elsewhere in this
 manual for how to run the off-line signature's tree backup.

 Cleaning a File Server from a Virus Attack.

 Whenever a virus is detected in a network, then act in an orderly way.

 While the virus is still active, try to obtain good virus samples on
 your local disk. Start by making sure that the COMSPEC points to the
 local disk (type SET to verify where to the COMSPEC variable points).
 Correct if necessary by typing SET COMSPEC=C:\COMMAND.COM. Run
 C:\IV\IVTEST, from the local disk. If lucky, IVTEST will generate two
 samples: Vir-Code and Virusam.ple. These will be valuable later,
 especially if the infection was caused by a variant or a new virus.

 Now proceed with the disinfection of the local disk. Use the rescue
 diskette if necessary. Try to locate the source of the infection on
 your own local disk by correlating with IVX. Consult the IV
 documentation if needed. During the disinfection of the local disk,
 learn the characteristics of the virus. If known by IVSCAN, then it's
 simple. If new or unknown to IVSCAN, then use IVB and note which type
 of files it infects (COM, EXE, SYS, OVL etc.), and what's the virus
 size. With IVX and the virus samples, find out what are the best
 correlation parameters to easily find all infected files, eliminating
 "noise" (detection threshold, correlation to Vir-Code and Virusam.ple,
 level of correlation, relative weight of statistical fitness, crypto
 model and string matching).

 When the local disk is totally clean, login to the network manually
 (execute the login batch line by line). Avoid the execution of any file
 from the server itself.

 Novell Netware systems administrators: Do not run LOGIN from the
 server, as the files in the login directory may be infected. Keep a
 clean copy of the F:\LOGIN directory on your hard disk, or on an IV
 Armored floppy and run LOGIN from the floppy or from the hard drive, in
 order to log in as 'supervisor'.

 Now assess the extent of the virus spread on the server by using IVSCAN
 (for viruses contained in its database), IVB and IVX. Before cleaning
 the server, shutdown all workstations in an orderly manner. All
 stations should be switched off, since the virus might still be memory
 resident. All the stations with hard disk should be disinfected
 individually before hooking them again to the network.

 The file server should be restored and cleaned in the following order.
 First use IVB/R for the fastest and best restoration of affected
 programs (provided they were secured beforehand). Next use IVSCAN /R,
 if the virus is known to IV, to restore those files missed by IVB (no
 signatures). If the virus is unknown to IVSCAN, then correlate with IVX
 to find out all files missed by IVB. Either rename the suspected files
 or delete them. Both options exist in IVX. Print the IVB/IVSCAN/IVX
 reports after each step. You may need to delete a few files that IVB
 could not restore, by using IVB/D.

 Replace the files that were renamed or deleted by IVB/IVSCAN/IVX (as in
 the reports' printout). Restart the network and resume operation.

 The methods described above should let you to resume network operation
 even after severe virus incidents, within half an hour to a couple of
 hours, while it could take a couple of days to a couple of weeks by
 other means.


 Appendix B. - Large Capacity IDE.

 There are a few facts that you should know when using the new large
 capacity IDE drives. They are becoming popular for their great
 performance and affordable price.

 These drives are designed to work with new mother-boards and BIOS,
 capable of handling more than 1024 cylinders. The 80x86 BIOS was
 limited by its designers to handle geometries of up to 64 sectors, 256
 heads and 1024 cylinders, altogether 8.38 gigabytes, in sectors of 512
 bytes.

 The newer BIOS have LBA (logical block access), or a translation which
 accept higher than 1024 cylinders in the setup.

 To overcome the BIOS limitation of the older boards, these drives
 require the installation of a special boot driver, if you use them with
 an older BIOS, and you want access to the drive's full capacity.

 The driver replaces
 the standard mbr and is written from sector 2 and on, on track zero.
 When booting, the special mbr bootstrap loads the driver from track 0
 into memory, and then continues booting the OS. Without the special
 driver you can't access the hard drive at all. You may not install the
 boot driver and configure the drive with FDISK, but then you can only
 access 528 mbytes.

 When using the special driver, you will not be able to access the hard
 drive when booting from a plain DOS floppy. You need to install the
 driver to the floppy and load it trough the floppy's config.sys, as a
 `device'. There are two makers of these drives, Ontrack (Disk Manager)
 and Micro House (EZ-Drive and DrivePro).

 Some large capacity IDE models can emulate two physical hard drives,
 just by the flip of a couple of jumpers, in case LBA isn't available.
 You won't need then the special driver.

 Both drivers use stealth, probably to protect the special mbr from
 being overwritten accidentally. Yet the stealth self protection is
 active only when booted with the driver in memory. There are several
 possibilities to circumvent the protection.

 There are several good reasons why to avoid the use of the special boot
 drivers.

    It takes 4 kbyte off the conventional 640 K memory. Since the driver
    loads first, before the memory manager, then there is no way to
    relocate it in high memory at a later stage.

    The hard drive cannot be accessed when booting from a plain DOS
    floppy,

    The special mbr and the driver are extremely vulnerable. They are
    overwritten by simple boot infectors, or even by attempting to
    remove such virus with the FDISK/MBR command.

    Disaster recovery utilities do not exist to recover the special
    driver in case of damage. The re-installation of the driver destroys
    all data already on the drive by wiping the FAT and the root
    directory clean. Simple and careless manipulation may end in the
    loss of the disk content.

 The following are DO and DON'T DO if you use one of the special boot
 drivers:

    Do NOT run FDISK/MBR on the drive, as it will overwrite the special
    bootstrap loader with a plain one. The disk will not boot anymore by
    itself. Yet it can still be accessed from a floppy containing the
    driver in the config.sys.

    Do NOT install mbr immunization to such drive, for the same reason
    as above.

    Do NOT install an access control or security system that writes
    anything to the mbr, to the boot sector, or to track 0. Most such
    systems do just that! You will be locked out of your system, for
    good!

    Common disaster recovery (rescue) programs do not work properly with
    the Disk Manager boot driver. As track 0 is stealthed then the
    rescue utility will backup the wrong data. A rescue floppy prepared
    by such utility is worse than not having one at all, since it will
    `restore' wrong information to the drive, for _sure._

    Do not forget floppies in your drive A. Such floppy, if infected
    with quite simple boot/mbr infectors may cause loss of self booting
    capability, or the total loss of access to the hard drive!

    If you have two IDE hard drives, and no LBA is available in the
    setup then make the large IDE drive number 2. It will be safer
    against most mbr infectors, immune to FDISK/MBR, and safe from
    immunization. :-)

    Install InVircible and prepare its rescue diskette. Starting from
    version 6.01D, InVircible's rescue disk procedure contains special
    features for these drives. The most important is `Seeing Through'
    the Ontrack stealthing of the boot loader and the backup of the
    true content of track zero.

 The following is how to recover access to a large capacity IDE, if self
 booting or access were lost:

    Damage to the system files: Insert a bootable floppy in drive A,
    with the same version and OS as installed on the hd. Start the
    computer and press the space bar when prompted to boot from a
    floppy. When DOS is up, issue the command SYS C:

    In case the mbr or one of the driver's sectors was overwritten by a
    virus. If you prepared an InVircible rescue diskette, then boot from
    the floppy and it will automatically enter the ResQdisk program.
    Press ^Z and select "Restore" of track 0.

    If you didn't prepare an IV rescue disk, then first prepare a boot
    floppy with the FORMAT drive: /S command. Copy the drivers to the
    floppy (in Disk Manager's case copy DMDRVR.BIN and XBIOS.OVL from
    the DM 6.03 distribution diskette and edit A:CONFIG.SYS. Write a
    line containing DEVICE=DMDRVR.BIN in the config.

    Boot from the floppy just prepared and see if you can access the
    drive. If yes then run MIRROR C: .

    Now reinstall the special driver from its distribution diskette,
    preferably in the manual mode (DM/M). If lucky, and the damage is
    not too severe, you may even spare yourself the next step.

    You will get a warning message that all data on the drive will be
    lost. Proceed anyway! Now boot from the floppy once more and run
    UNFORMAT C:. That should do the trick.


 Appendix C. - IVX advanced options.

 This appendix is for the advanced user, computer security experts and
 system administrators.

 IVX, the hyper-correlator of InVircible, can be used in one of the
 following modes:

 -  As a statistical correlator, to detect statistical similarities
    between files.

 -  As a signature extractor, for establishing a scan signature from an
    infected sample.

 -  As a scanner, from a signatures library.

 -  For searching a text string in files.

 -  As a signature scanner, from a user defined signature.

 All modes can be entered from the interactive dialogue menu. Only the
 statistical mode can be entered directly from the command line.

 The statistical correlator. This mode is started by designating an
 infected file to compare to. If there exist a ViruSample, Vir-Code or
 both, then IVX will pick them automatically for sampling, in the "Auto"
 mode. IVX will analyze the sample file and establish its correlation
 parameters in three categories: structure, crypto model and signature.
 IVX extracts a signature from the sample file, where possible. The
 signature is automatically added to the IVX.LOG file, in the IVX
 directory. The statistical mode is detailed in section 7, The
 Correlation Scanner.


 Extracting signatures.

 Finding a good signature needs common sense, patience and experience.
 Yet, it's not always possible to find a valid signature for every
 virus. With some viruses, IVX will extract a valid signature on the
 first run, others may need the user intervention.

 The following are valid signatures, extracted automatically by IVX,
 as stored in IVX.LOG, on the author's hard drive.

 BB8513E3262CAEA8B892 ; E:\F_VIR\CAIBUA.COM     Big Caibua
 8BCC0EFA178BE78EC08D ; E:\F_VIR\DIE_HARD.EXE   Die Hard
 378B0E4B8B053CD5043D ; E:\F_VIR\FRODO.COM      Frodo, 100 Years
 072E8E1645002E8B2643 ; E:\F_VIR\FRIDAY13.COM   Jerusalem.1808, Standard

 Each line contains a single signature, made of ten bytes (in hex
 notation), then a ';' mandatory separator, and a description. IVX will
 write the full pathname of the sample file as description. In the
 above, it's obvious that the sample are all from the file viruses
 directory on the author's drive. The last entry in each line (the name
 of the virus) was added with a text editor. Free text is allowed past
 the ';' separator, as IVX will ignore anything to its right.

 To decide whether a signature is good, simply scan for that signature
 through several infected files. If IVX finds the signature in all, then
 the signature is good. There are instances when a signature extracted
 from an infected COM sample is not found in EXE files, and vice versa.
 Sometimes, the signature taken from the EXE sample is good for both, or
 the one from the COM sample is good for both. There is one way to find
 out: Trial and error. It's possible that you'll need two signatures for
 the same virus, one for EXE, another for COM files.

 There are instances when 'wildcards' may be needed. Suppose we found an
 exotic new virus and when correlated for in the statistical mode, no
 match is found for a signature. Yet, when looking in the log file we
 may see that the signatures 'almost' match, except for a few bytes that
 change value in the different signatures. You may then replace these
 bytes by a '??' wildcard. IVX will ignore the byte at the specific
 position. Let's look at an example. Suppose we obtained signatures for
 the following samples, all from the Exotic virus infections:

 8BFF0EFA178BE78EC08D ; SAMPLE-1.COM
 8BCC0EFA178BE7FFC08D ; SAMPLE-2.EXE
 8BCC0EFA178BE78EC08D ; SAMPLE-3.COM
 8BFF0EFA178BE7FFC08D ; SAMPLE-5.EXE

 A good signature for the Exotic virus will look as follows, with bytes
 2 and 8 replaced with the ?? wildcard. The same can be used when
 adopting user defined signatures from other than IVX sources.

 8B??0EFA178BE7??C08D ; Exotic virus signature.


 Using the Signature mode.

 User defined signatures can be entered in three different ways:

 - As an existing IVX signature, from the IVX.LOG library, or by adding
   a new, or editing an existing signature in the library.

 - As an ASCII string, from the keyboard. The search for ASCII is case
   sensitive and looks for a perfect match.

 - As an hex signature, from the keyboard. Wildcards are allowed.

 Start IVX, select the 'Signature' mode and IVX will prompt for one of
 the above. Pressing 'A' will start the ASCII entry mode, 'H' will start
 the hex entry mode, and Enter will open the LOG file for browsing and
 selection.

 The 'Signature' mode can be used in a staggered scan strategy. The
 probability of an occasional occurrence of the same signature with 10
 valid bytes is fairly low. Even six valid bytes still provide a fair
 margin against false alarms. Therefore, the signature scan mode of IVX
 can use sometimes for the final scan, to eliminate the 'noise' that may
 exist in the statistical mode. For that purpose, a good signature
 should be extracted first through the statistical mode, and validated
 as explained. Then the final run is executed in 'signature' mode, with
 100% match and no false positives.


 Using IVX for virus alert.

 A common user with no background in virus or antivirus matters, when
 hit by a new virus, like Big Caibua (April 1995), can issue a virus
 alert on the net within minutes. After he/she confirmed the validity of
 the signature, of course.

 The message should contain the signature extracted by IVX, as found in
 the IVX.LOG file. Conversely, all users of InVircible (or IVX) can add
 the signature to their IVX.LOG file and scan for the new virus through
 their programs.

 IVX can also be used as a signature scanner for user defined signatures
 obtained from other sources. There is no limitation on the number of
 signatures that can be stored in the IVX.LOG file, except your patience
 for browsing till you find the right one.