
       InVircible  - User's Guide and Installation Instructions
              Copyright (C) 1990-1995 NetZ Computing Ltd

  Table of Contents

      I.      Licensing Agreement
      II.     Preface
      III.    Quick Start Instructions
      IV.     Using InVircible
      V.      Suggested Protection Routine

      1.      Introduction
      1.1     What Are Computer Viruses?
      1.2     InVircible's Main Features

      2.      The Rescue Diskette
      2.1     Preparation of the Rescue Diskette0
      2.2     Customizing Your ResQdiskette
      2.3     When Should You Renew The ResQdiskette?

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

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

      5.      Recommended Anti-Virus Strategy
      5.1     In the Single User Environment
      5.2     In a Network Environment
      5.3     In the Institutional Environment
      5.4     In Windows NT, Windows 95 and OS/2 Environment
      5.5     In Unattended Installations (BBS)

      6.      IVB - The Integrity Expert System
      6.1     The Extra-Security Feature
      6.2     Off-line Backup of the Database-Files-Tree
      6.3     Excluding and Including Files from IVB's Checklist
      6.4     The IVB.INI file

      7.      IVX - The Correlation Scanner

      8.      ResQdisk - The Disaster Recovery Tool
      8.1     Reconstruction of the Boot Bloc
      8.2     Regaining Access to an "Invalid Drive"
      8.3     ResQdisk's Setup Utility
      8.4     ResQdisk Professional

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

      10.     A Primer to Generic Anti-virus Methods
      10.1    Virus Symptoms
      10.2    How to Proceed in Case a Virus is Found in the Computer
      10.3    Gathering Information on the Virus
      10.4    How to Recover an Infected Computer
      10.5    Advanced Virus Analysis Methods
      10.6    Virus-Cooperative Integrity recovery
      10.7    Virus-Cooperative Piggybacking (Retro-Piggybacking)
      10.8    Virus-Cooperative (SeeThru) Boot Bloc Recovery
      10.9    Removing Stealth Boot infectors from SCSI and MFM disks
      10.10   Removing Boot Viruses from Floppies
      10.11   Disaster Recovery - Regaining Access to a Hard Drive
      10.12   Handling Cluster Infectors
      10.13   Screening New Software
      10.14   Common Problems, How to Handle Them

      11.     InVircible, Windows and OS/2

      12.     CPAV's Inoculation

      13.     InVircible and Memory Resident Anti-Virus (TSR)

      14.     Practicing Antivirus Strategies, The AV Practice Lab (AVPL)

      15.     Troubleshooting

      16.     Upgrading and Support

      Appendices

      A.      Appendix A. - A Primer to Integrated Anti-virus
      B.      Appendix B. - LAN Protection
      C.      Appendix C. - Large Capacity IDE
      D.      Appendix D. - IVX Advanced Options
      E.      Appendix E. - Switches and Command Line Options
      F.      Appendix F. - Glossary

  I. Licensing Agreement

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

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

  License: InVircible is licensed, it is not sold. The Licensee is
  obtaining limited rights to use the InVircible software. The Licensee is
  licensed to use InVircible on a single personal computer. The distribution
  floppy of InVircible has provisions for licensing two installations to the
  hard disk. Only one installation to one hard disk is licensed with this
  disk package. The second installation is reserved for the Licensee as a
  backup. Site licenses are available for individuals or organizations with
  multiple installation requirements.

  Site License Certificate: The Purchaser of a Site License will be
  issued a License Certificate by NetZ Computing. The holder of the
  Certificate is entitled to free upgrades of IV during the License Term, as
  well as hotline support through a NetZ Authorized Agent. The possession of
  the NetZ License Certificate constitutes the sole proof of a
  genuine and legally acquired Site License.

  Alteration or reverse-engineering of the programs is not authorized, such
  attempts terminate this license agreement and may result in unpredictable
  damage and may have irreversible effects.

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

  InVircible is provided "as is". The Licensee assumes all responsibility for
  the determination of the suitability of this software for Licensee's
  configuration and the results and performance of this software program
  package. NetZ Computing, the distributor, and their suppliers do not
  warrant, guarantee, or make any representations regarding the use of, or
  the results obtained with, the program in terms of correctness, accuracy,
  reliability, legality, or otherwise.

  Disclaimer: In no event shall NetZ Computing Ltd., nor its Agents, nor
  anyone else involved in the creation, production, or delivery, of this
  product be held liable for any damages, loss of profit, consequential, or
  other damages, that may arise out of the Licensee's use or inability to use
  the InVircible programs. Some states do not allow excluding or limiting
  implied warranties or limiting liability for incidental or consequential
  damages, so the above limitation may not apply to the Licensee. This
  limited warranty and license agreement is governed by the laws of the State
  of Israel.

  II. Preface.

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

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

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

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

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

  InVircible programs attempt recover themselves, successfully in most cases,
  if they become infected, from stealthy viruses too. InVircible does not
  allow a "fast infector" virus to "piggyback" its scanners and to infect an
  entire hard disk drive. InVircible utilize efficient virus activity probes,
  embedded in all its modules, instead of a memory resident (TSR) scanner or
  behavior blocker.

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


  III. Quick Start Instructions

  Insert the distribution floppy into drive A: or B:

         Run INSTALL/FAST from A: or from B: to start the quick
         installation procedure.

  The InVircible INSTALL first examines your system for viral activity and
  checks for boot and file infections of the hard drives. After these initial
  tests, InVircible then installs itself on your system to a default
  directory. Next, all files on hard disk drive partitions will be "secured"
  by IVB. This initial scanning and securing of a large number of files may
  take a few minutes, so please be patient! Whenever a choice is provided,
  the default selection is the recommended choice. We encourage you to
  configure your system so that IVTEST, the real time viral activity probe,
  is activated when you invoke a frequently used batch (BAT) file.

  Important: Preparation of a Rescue Diskette is critical for effective
  recovery from boot bloc and complex viral attacks. The preparation is
  needed before a virus infection may occur.


  IV. Using InVircible

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

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

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


  V. Suggested Protection Routine

  IVINIT will check on any initialization of the computer that the boot bloc
  and operating system are intact. IVINIT will also remove boot viruses (in
  licensed mode only), after prompting the user.

  IVB will automatically run a DAILY check of your binary-executable files in
  the local partitions on the installed hard drives. CD-ROM drives are
  excluded from the DAILY check as there is no point in verifying them.

  IVB is the primary tool for monitoring the integrity of files and for their
  recovery in the event of a virus infection. IVB will report changes in
  binary-executable files. Some changes in programs are expected if you
  generate your own applications, or replace a program's older version with a
  new one and the filenames are reused. IVB will normally prompt and suggest
  the renewal of the database file in a directory, in case the changes are a
  new version of a program. An existing signatures file will be backed up
  when renewing the signatures file, thus you may step back in case it was a
  virus infection after all.

  Yet, software developers will need to be aware when alterations are
  legitimate and when they are not. User generated executable should be
  secured immediately with IVB.

  It's good practice to screen newly acquired software with an up-to-date on
  demand scanner. Screening by a scanner need to be run just once, before
  installing the software to your hard drive or to a file server. Ongoing
  real-time protection and recovery is provided by IV's probes and tools.
  It's worth scanning new software floppies with IVSCAN, it may detect
  generic and boot infectors that passed through the screening process. After
  installing new software to the hard disk, run IVB to secure the newly added
  executable file.

  Application programs do not change normally unless they have been upgraded.
  A consistent change pattern reported by IVB indicates a viral infection.
  IVB provides this information both on screen and in a report file (IVB.RPT)
  placed in the partition's root directory. Print this file to help assess
  the situation if you suspect virus activity. A report of only a single file
  having become modified requires you to proceed carefully ! Viruses rarely
  infect only one file, so an indication of a single modified file may not
  necessarily indicate the presence of a virus. In most cases it is not a
  virus doing!

  When a genuine infection is found, then boot from the clean rescue diskette
  and first assess the full extent of the infection, before taking any
  corrective actions. IVB should be preferred whenever possible for removing
  viruses from files, provided the programs were secured before becoming
  infected. Only if no signatures exist, and the virus is known to IVSCAN, or
  to the third party on-demand scanner, then you may use the scanner to
  disinfect the programs.

  New viruses, unknown to IVSCAN or to the third party scanner, can still be
  found using IVX, and be renamed so that they will not constitute a viral
  threat. The renamed files can then be replaced from backup.


  1. Introduction.

  1.1. What are Computer Viruses?

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

  Computer viruses are passed the same ways we obtain software; by sharing
  software with friends, downloading from BBS, with newly purchased PC and
  hard disks, in vacuum wrapped new software, and even on preformatted
  floppies.

  1.1.1 Categories of Computer Virus

  Generally, there are two virus categories:

  -  Viruses that infect through the boot sector or partition sector (MBR),
     or 'boot infectors';
  -  Viruses that infect through programs, or 'file infectors';

  All encountered viruses fall into one of the above two categories or both.
  There are also bipartite or multipartite viruses that combine the
  properties of the two categories (boot and file). Examples of multipartite
  are Junkie and Natas, while Tequila is a bipartite as it does not infects
  the boot sector of floppies, just the mbr and EXE files.

  In late 1991, a new variant of file viruses emerged. It manipulates the
  file allocation table (FAT) pointers through the directory entries in order
  to spread. We will call them 'cluster infectors'.

  A last type are the 'companion viruses', these are a variant on the file
  infector. A companion virus takes advantage of the properties of the
  operating system by spawning a companion to the victim program.

  Below is a quick definition of terms that are used to describe viruses and
  techniques employed by viruses:

  1.1.2 File Infectors.

  A file infector attacks executable program files, usually those having a
  COM or EXE extension name. Sometimes also files having the structure of an
  executable are targeted by viruses, regardless of their extension name.
  File infectors may corrupt non-executable files as well but they cannot
  spread this way.

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

  1.1.3 Boot Viruses

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

  1.1.3 Multipartite Viruses (boot and file infectors)

  Multipartite viruses infect both executable files and boot-partition
  sectors, sometimes the boot sector on floppies too. Some multipartite
  become infectious only after rebooting the computer from the infected mbr,
  like Tequila, others are equally infectious if loaded from file or through
  the boot process.

  1.1.4 Cluster infectors (file infectors).

  The cluster infectors are basically file infectors, with a unique infection
  mechanism. Cluster infectors are inherently stealth viruses because they
  hide the increase in file length, although the virus code is actually
  appended to the file. The way it is done is by inserting the extra clusters
  in the file's clusters chain, by manipulating pointers in the directory
  entry. Two well known such viruses are DIR_II and 1963 (Necropolis). DIR_II
  is almost extinct as it does not survive in DOS 5 and higher environment.
  Cluster infectors are also excellent piggybackers.


  1.1.5 Techniques used by Computer Viruses.

  1.1.5.1 Stealth.

  Stealth viruses are so named because they actively seek to hide themselves
  to prevent detection. Stealth viruses that infect files will subtract their
  own size (in bytes) from the infected host file at any time that a
  directory (DIR) command is executed or actually remove themselves from the
  file, to reinfect it again when the inspection is over. The Whale virus is
  a good example of this. When it infects a file it adds 9216 bytes (and some
  mutations may reach even 16 kbyte in length) to the file size. Stealth
  viruses are categorized as 'full stealth' and 'semi stealth'. The
  difference is explained later.

  Some boot viruses use stealth (spoofing) techniques too. Stealth boot
  viruses will deceit disk editing tools, except ResQdisk. Example of stealth
  boot viruses are Monkey, AntiEXE and B1-NYB. Natas and Gingerbread Man are
  multipartite viruses that use boot stealth too.

  1.1.5.2 Encryption.

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

  1.1.5.3 Mutation Engine or Polymorphism

  Polymorphic viruses are a higher order of encrypted viruses. In addition to
  encryption, they use a "mutations generator" that scrambles the encryption
  too. A polymorphic virus mutates itself, so that each occurrence is totally
  different from the one before. This creates difficulties for anti-virus
  scanners, because they cannot look for a known virus signature. Polymorphic
  viruses have forced scanners to use methods based on heuristics, which
  increased their false alarm rate and rendered scanning more difficult.

  1.1.5.4 Companion Viruses.

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


  InVircible's Main Features

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


  2. The Rescue Diskette.

  A Rescue Diskette is essential to disaster recovery and effective virus
  protection. The `1IV ResQdiskette is one of IV's strongest features.

  2.1 Preparation of the Rescue Diskette.

  The Rescue Diskette is a bootable floppy, containing the necessary
  InVircible programs, the hard-disk's boot-areas image files, the data
  stored in the CMOS, a copy of your AUTOEXEC.BAT and CONFIG.SYS and some
  useful DOS files such as FDISK, SYS, and UNFORMAT. It enables to recover
  the boot areas of a given hard-disk, its track zero, the CMOS settings, as
  well as the recovery of files (with the licensed version) in case of
  infection.

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

  Partitioning device drivers (e.g. Disk Manager v6.03+), disk-compression
  (Stacker, SuperStor, DoubleSpace), password drivers etc., required to
  recognize partitions or drives at booting time, should be installed onto
  the Rescue Diskette. DoubleSpace, Stacker and Ontrack's Disk Manager are
  all taken care of by InVircible. Users of special boot drivers such as
  Ontrack's DM v6.03 for large capacity E-IDE are advised to read appendix B.

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

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

  2.2 Customizing Your ResQdiskette.

  You may add utilities such as your favorite ASCII editor, special drivers
  and configuration files to your ResQdiskette. IV will take care of Stacker
  and DoubleSpace disk compression. Other drivers should be added manually
  by the user.

  Format a floppy in drive A, copy the drivers and utilities you need to A:,
  and edit a:\config.sys and a:\autoexec.bat, if needed. IV's rescue disk
  procedure will edit it's commands into your startup files without erasing
  them. Start INSTALL /R and answer "No" when the program prompts if to
  erase the existing data.

  2.3 When Should You Renew The ResQdiskette?

  The Rescue Diskette contains the PC's 'personal' data: a copy of the
  installed operating system, partition and boot sector images, a copy of
  track zero and the CMOS setup parameters. Whenever one of these is
  changed, such as when changing a DOS version, or modifying the disk
  partition, then renew then the ResQdiskette. It is recommended that you
  renew the ResQdiskette when upgrading InVircible.

  There is no need to renew the rescue diskette when new directories or
  programs are added on the disk. This is taken care of with the DAILY
  inspection of IVB.

  WARNING: The Rescue Diskette is unique for a specific hard disk. Rescue
  Diskettes should never be swapped between computers.


  3. Using the Main Menu (IVMENU).

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

                        IVMENU [/switch] [drive:]
         Switches:

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

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

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

  3.1 IVMENU Special Keys.

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

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

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

  3.2 The IVMENU Caution Panel.

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

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

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

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

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

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

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

  3.3 Browsing Through Last IVB, IVSCAN or IVX Report.

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


  4. InVircible Installation

  4.1 Installation to Hard-disk.

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

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

  The Utilities sub-menu, has the following options:

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

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

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

  d. The License Installation/Removal sub-menu. Enables either the
     installation or removal of the InVircible license to/from the hard
     drive. This option is available only if you possess the original
     distribution diskette. The process is reversible.

  4.2 Installation To or From LAN Server.

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

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

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

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

  All stations connected to the network and equipped with a hard-drive need
  individual licensing. If you prefer working in the Sentry mode then do not
  install the license record to workstations. The file server does not need
  the installation of the registration key. Any workstation in the network
  having a hard disk may be infected prior to logging-in to the network.
  Therefore, any such station needs its own InVircible installation.

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

  You can use IVLOGIN with the following command line options. The /RANDOM
  switch will set a random IVB signatures filename for each new installation.
  If you prefer a predefined signatures filename then use SIG=your_filename.
  No spaces are allowed in the last command. Using IVLOGIN plain will install
  with the default signature filename.

  4.3 Installation under OS/2, Windows NT and Windows 95.

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

  4.4 Installation in the Sentry Mode.

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

  The sentry mode is indicated in both IVMENU's Caution Panel and in the
  upper left corner of the program's panel.


  5. Recommended Anti-Virus Strategy

  Effective anti-virus protection starts with the installation of InVircible
  on a clean computer. If found infected during first time installation, then
  first disinfect as explained elsewhere and install IV when clean.

  Once installed, IV detects viral deviations from the clean initial state
  and let restore programs and boot sectors to their pre-infected state.


  5.1 In the Single User Environment.

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

  From now on, InVircible will detect and correct the most severe problems
  right at initialization. These include partition or boot sector tampering
  and certain operating system changes.

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

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

  The IVB daily check will skip Read Only drives (CD ROM). Network and remote
  drives are not checked by the daily command.

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

  It is highly recommended to regularly run a FAT backup program, such as
  MIRROR from DOS 5. The latter is recommended since its complementary
  command, UNFORMAT, is contained in DOS versions higher than 5 and the
  UNFORMAT program is backed up on IV's rescue diskette. Run MIRROR from the
  last line of your AUTOEXEC, before loading Windows, if you do.

  The InVircible system uses a non-TSR virus-activity probe and sampler,
  called IVTEST. Anti-viral TSR are limited only to known viruses, and they
  may be obtrusive at times, yet, there is need to verify from time to time,
  that a viral process is not spreading in the system. This is achieved by
  the automatic running of IVTEST, from frequently used BATCH files. The
  INSTALL utility will add the appropriate command into specified
  directories.

  5.2 In a Network Environment.

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

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

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

  5.3 In the Institutional Environment.

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

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


  5.4 In Windows NT, Windows 95 and OS/2 environment.

  Non-DOS operating systems are inherently immune to DOS viruses. File
  infectors do not survive in the non-DOS environment. Although DOS programs
  can run in them in either a DOS Box or in full screen virtual DOS, these
  environment are not compatible enough for virus operation.

  The major threat from viruses to systems using Windows NT, Windows 95 and
  OS/2 is from dumb boot sector viruses, and the incidental infection of the
  hard disk with one of these viruses.

  Boot infectors are the most prevalent type of in the DOS environment, 50 to
  70 percent of all reported incidents, although their percentage of the
  total number of viruses hardly exceeds 10 percent. Boot infectors will be
  around for as long as DOS is still used. Floppies will get infected by them
  and these floppies may find their way into the boot drive of NT servers, or
  computers using OS/2 or Windows 95.

  Boot viruses do not spread further from an 'infected' computer that runs
  under a non-DOS operating system. Some of these boot infectors have no
  effect on their host machines, others may prevent them from starting. The
  remedy to this problem is the InVircible rescue diskette. It will let to
  remove a boot virus from the hard disk and restore the system to
  operational status.

  Users tend to cheat themselves that boot viruses can always be removed
  after they struck, since these viruses are "known" to most anti-virus
  producers. The DA'BOYS, or FORM viruses for example do not keep a copy of
  the original uninfected boot sectors anywhere. No anti-virus can help
  recover a non-DOS disk from these simple boot infector. If you won't take
  precautions before struck, by preparing a rescue diskette, then it might be
  quite difficult, or impossible, to recover your hard drive after being hit.
  A rescue diskette is all it takes for gaining peace of mind from such
  eventuality.

  To prepare a rescue diskette for a non-DOS system proceed as follows.
  Format a DOS bootable floppy on a DOS machine. Copy RESQDISK.EXE to the
  floppy. Boot the non-DOS machine from that floppy and run the following
  from the A: drive:

              RESQDISK /B
              RESQDISK /Z/B

  These commands will create images of the mbr, the boot sector, the CMOS
  data and a copy of track zero, head zero.

  Windows 95 can be restarted in a full DOS session. Restart in DOS, install
  InVircible and prepare its rescue diskette. Now restart back into Win 95.

  Do not undertake anti-virus corrective maintenance, especially not of the
  boot bloc, when in a Windows session, nor when in a Windows DOS shell.
  Always exit Windows completely, or restart to full DOS before undertaking
  anti-virus corrective measures, especially of the hard disk.

  5.5 In Unattended Installations (e.g. BBS).

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

                          IVB C: DAILY /NOSTOP

  For the user interested in more details, we recommend to read appendix A, a
  primer to Integrated Anti-virus.


  6. IVB - The Integrity Expert System.

  IVB will secure, authenticate and restore executable programs from virus
  infection and virus-like modifications, except for cluster infectors (see
  Section 10).

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

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

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

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

  IVB, when licensed, restores programs that have been secured. Prior to
  restoring files with IVB, scan with IVSCAN (after booting from the rescue
  diskette or from a clean DOS floppy) to discard the possibility of a known
  type. The IVB command-line syntax is:

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

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

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

  Let IVMENU guide you through the options.

  The Delete option will erase files that cannot be restored, such as
  overwritten or ruined by a Trojan or virus.

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

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

  IVB is tamper-resistant and will detect and replace a tampered record of a
  particular file, rather than void the database. When renewing a database
  file, the current one is backed up with the extension name '.000' and the
  backup is given a read-only attribute. This should let to recover from an
  erroneous replacement of the database file, should this happen.

  IVB processes executable files only. Files with the following extensions
  are processed automatically by IVB: BIN, COM, EXE, OV?, SYS, NLM, VLM, 386
  and VXD. IVB has provisions for adding up to five (5) file types to its
  processing list. See in paragraph 6.4 how to do this.

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

  6.1 The IVB Extra-Security Feature.

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

  6.2 Off-line Backup of the InVircible Database.

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

  A typical 200 meg disk partition will require about 200 Kilobytes of space
  for an off-line InVircible backup. An off-line backup for a typical 1
  Gbytes file server can be contained on a single 1.44 Mbytes diskette.

  6.3 Excluding files from IVB's spec.

  There are instances where a secured file may change for non-viral reasons.
  You may then wish to exclude that file from IVB's list, without giving up
  the processing of other files with the same extension name. An example for
  such file is RANDSEED.BIN, a random seed sequence, used by the well known
  PGP program (Pretty Good Privacy), by Phil Zimmerman. See next how to do
  this.

  6.4 The IVB.INI file.

  IVB.INI is a text file that contains parameters to initialize the IVB
  program. The file should reside in the same directory as IVB.EXE. IVB.INI
  can be edited with an ASCII editor. The following are the various entries
  allowed in the INI file:

  Signature file name: To set a signature filename other than the
  default, write a line as follows: SIG=filename. Only one such item is
  allowed in IVB.INI.

  Include list: To include a specific file type in IVB's specification
  list, add a line as follows: INCL=*.XYZ . DOS wildcards (*,?) are accepted
  in this entry. Up to five include specs are allowed in IVB.INI.

  Exception list: To exclude a file from being processed by IVB, add a
  line containing the following: SKIP=filename. Do not specify a full
  pathname, just the filename (up to 12 characters). Wildcards are not
  allowed in this entry and you may specify up to five (5) filenames that IVB
  should ignore.


  7. IVX - The Correlation Scanner

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

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

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

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

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

  The IVX report is displayed in a bar-graph format, when the correlator
  completes its scan. You may also want to review the IVX report through
  IVMENU.

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

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

  Tips for using IVX.

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

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

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

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

  Examples:

    Legend: --Structure, --Encryption, --String.

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

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

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

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

  Practicing IVX.

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

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

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

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

  For additional information on the correlation scanner and advanced methods
  for using IVX, see appendix D.


  8. ResQdisk - The Disaster Recovery Tool.

  ResQdisk is a compact yet useful utility capable of repairing damage to the
  hard disk partition or boot sector, removing known and unknown partition or
  boot viruses, restoring self booting capability to hard disks and regaining
  access to the hard disk, if access was lost because of damage to boot data
  (messed CMOS data or damaged mbr-boot sector).

  ResQdisk deals uniquely with hard disks drives, not with floppies, uniquely
  prepared and configured with FDISK, under DOS.

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

  For maximum safety, the boot area images are written to the Rescue
  Diskette, since an inaccessible disk will deny access to the backup written
  to itself. ResQdisk's options are displayed on the menu bar, at the
  screen's bottom. The user is encouraged to browse their hard drive with
  ResQdisk trough the various options.

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

  Navigating with ResQdisk. The direction keys can be used to navigate
  ResQdisk to the various configuration sectors of your hard disk(s). The
  content of the sector is displayed in the window, in black on cyan
  background. Use the following keys to browse through the sectors:

     Home: Go to the master boot record (mbr) at sector 0,0,1.
     Page Down: Go to next partition sector, it there exist one.
     Left arrow: Go to the active boot sector.
     Right arrow: Go to next partition boot sector, if there is one.
     Up & Down arrows: Browse trough sectors on track zero, head zero.
     Plus-Minus () keys: Change between hard drives 1 and 2.

  8.1 Reconstruction of the Boot Bloc.

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

  ResQdisk makes it easy; all that is needed is the following keys sequence:
  Press the 'Home' key, then F1, then F4

  Tampering with the boot sector is corrected by the sequence:

                           Left arrow, F1, F4

  8.2 ResQdisk's Special Functions.

  It may happen that the disk setup parameters stored in the CMOS become
  invalid because of a weak battery, electrical surge, a setup error and
  sometimes even bad software. If this happens then reboot the computer from
  the rescue diskette and press <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.

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

  8.3 ResQdisk's Setup Utility.

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

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


  8.4 ResQdisk Professional.

  Boot sectors Backup and Restore. Sector can be individually backed up or
  restored. To backup or restore a sector, go to the sector with the
  navigation keys and press "B" for backup or "R" for restore. IV's rescue
  diskette contains a backup for each critical sector.

  Edit functions (^E,E): Ctrl/Alt+E will open the editing menu. The
  currently displayed sector can be loaded to the clipboard and rewritten to
  another location. In addition to read and write, there are options to read
  a sector from file, to write a sector to file and to decrypt an encrypted
  sector. The latter is especially useful to recover from the Monkey virus.

  Analyze functions (^A,A): Ctrl/Alt+A will open the analyze menu. The
  displayed sector can be analyzed as a partition one or as a system boot
  sector.

  Boot sector functions (^B,B): There are instances where it is preferred to
  use DOS interrupts to access the system boot sector, rather than BIOS
  interrupt 13h. Such is the case when you need handle the boot sector of a
  Disk Manager partition. The ^B menu has the same options as ^E, but uses
  DOS instead of BIOS. The SYS option has the equivalent effect of a SYS C:
  command, on the boot sector, but without transferring the system files.

  Track zero menu (^Z,Z): The whole track zero, head zero can be backed,
  restored, or compared with the ^Z menu.

  The Ctrl+function keys. The Ctrl+function menu is displayed when pressing
  the slash "/" key. The following options are available under Ctrl+function:

  ^F1    Force a new master boot record (mbr), recalculated from the standard
         Dos boot sector found in sector 1,0,1. ResQdisk will use the
         PART.NTZ image file instead, if it exists. ^F1 will assume a SINGLE
         partition existed on the hard drive, unless there exists a PART.NTZ
         image with several partitions data. For disks with multiple
         partitions see ^F4, below. This function requires that the copy of
         IV is registered.

  ^F2    Force a new active system boot sector, recalculated from the master
         boot record data. ResQdisk will use the BOOT.NTZ image file instead,
         if it exists. This function requires that the copy of IV is
         registered.

  ^F3    Restore CMOS setup data. ResQdisk will use the data stored in the
         CMOS.NTZ file if it exist. Otherwise ResQdisk will do nothing.

  ^F4    Scan the entire disk for additional partitions and rebuild the mbr
         accordingly. This option is available only to registered users that
         purchased the Pro version (ResQpro) of InVircible. The ResQpro
         function, ^F4, can be enabled for a single on-line session by IV
         support agents. See ^F10 next.

  ^F10   Password to enable ResQdisk in Pro mode for a single session. Users
         in need can contact an authorized IV agent for online assistance.
         The agent can enable ResQdisk features for the current session and
         guide the user to help him regain access to the hard drive. The
         password is accessed by pressing ^F10. Read the password to the
         agent and he will respond with a matching one that will enable
         ResQdisk.

  IMPORTANT! The recovery features of ResQdisk suit hard disks prepared for
  DOS uniquely and configured with FDISK. Disaster recovery considerations
  are a good reason to avoid non-standard configuration schemes and access
  control that modify the boot sectors in any way.


  9. IVSCAN - The Virus Detection and Removal Scanner.

  IVSCAN is a minimum virus scanner, with generic features added. IVSCAN is
  in no way a substitute for an up-to-date virus scanner. If you feel you
  need one for screening new software, or for disinfecting a machine before
  first installing InVircible to it, then we recommend that you look for one
  of the many shareware or commercial scanners available on BBS, from
  anonymous ftp sites, Compuserve and on the Internet.

  As a general rule, integrity restoration by IVB is superior to disinfection
  by IVSCAN, or by other scanners, since integrity restoration is not
  sensitive to the proper identification of the virus. Scanner, IVSCAN
  included, may misidentify a virus strain for another or can be fooled into
  "finding" one virus while it is another. The disinfection based on such
  error will usually result in the ruining of the program and it may take a
  long time until you spot and replace all the corrupted files. In addition,
  many viruses add 1 to 15 bytes of junk code that are not removed by
  scanners. While not causing any problem in most cases, there are programs
  that check their self integrity and will stop functioning if not restored
  to the byte. IVB will do that better than IVSCAN.

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

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

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

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

  The options are:

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

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

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

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

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

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

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

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


  9.1 Removal of Generic Boot Viruses.

  Boot viruses are transferred from one computer to another by accidentally
  booting from an infected floppy (the infected diskette is left in drive A
  and the computer is rebooted), even if the floppy is not bootable, just
  infected! IVSCAN provides for the replacement of the boot sector in
  floppies with a standard DOS boot sector. Just type:

                            IVSCAN drive: /B

  IV contains a complimentary program, FIXBOOT, for bulk cleaning of the boot
  sector of floppy disks. FixBoot will install a generic clean boot sector to
  a diskette, in drive A or B. FixBoot can be used to prepare a clean
  bootable floppy, when the hard drive is infected with a boot infector.
  Insert a formatted floppy in the drive, transfer the system files with the
  DOS command SYS A: (or B:) and finally run FIXBOOT A: (or B:). Remove the
  floppy from the drive without attempting anything else, not even a DIR
  command, and write protect the floppy.

 The above technique usually works even in the presence of stealth
 viruses such as Monkey.


  10. A Primer to Generic Anti-virus Methods.

  Generic techniques can cure damage from groups of viruses such as boot bloc
  infectors, stealthy file infectors and cluster infectors.

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

  10.1 Virus Symptoms.

  Computer viruses always disclose there presence sooner or later. InVircible
  alerts the user when sensing various effects that can be related to
  computer viruses. Among InVircible's messages, the following are of special
  interest:

         (1) Missing memory.
         (2) A stealth virus found active.
         (3) Own's file size "changed by 0 (zero!) bytes"
         (4) Piggybacking or file killer detected.
         (5) "faked partition (or boot) sector".
         (6) "Boot infector detected".

  Message (1) indicates memory stealing, attributed mostly to the presence of
  a boot or partition infector. Certain file infectors do the same, and this
  possibility should be first discarded. Also, some programs such as DesqView
  uses a few kbytes kernel in RAM, or certain BIOS use 1 kbyte of RAM when
  the machine was booted from a floppy, without being related to virus
  activity.

  Message (2) or (3) indicate that a stealth virus is active in the system.
  These messages are generated by IV's baits or the self integrity check,
  respectively.

  Message (4) indicates that a piggybacking process was detected and the
  search should be halted to prevent further spreading of the virus. This
  message is generated by the either one of IV's scanning programs, IVB, IVX
  and IVSCAN.

  Message (5) indicates the presence of a stealth virus in either the mbr or
  in the system boot sector. This message is issued by SeeThru, implemented
  in IVINIT, IVTEST and IVSCAN.

  Message (6) will be displayed when a boot infector is found in the mbr or
  the system boot sector of the hard disk or of a floppy. This message and
  message (5) may sometimes be displayed both.

  10.2 How to Proceed in Case a Virus is Found in the Computer

  It is recommended that inexperienced users ask for assistance or leave
  disinfection to qualified and trained personnel. Inadequate virus removal
  procedures can be incredibly more harmful than continuing working with a
  virus in the computer!

  In case of doubt, then LEAVE THE COMPUTER ON AND WORKING until help
  arrives, and don't continue working while the virus is still active. You
  next best choice is to first backup valuable data and then switch the
  computer off in an orderly manner. Do not backup programs as they may be
  infected, and do not switch the computer off before having backed up
  important data. Act as if you might not be able to access the data on the
  hard disk the next time you restart the computer.


  10.3 Gathering Information on the Virus.

  It is important to collect as much as possible information on the attacking
  virus as it will let you make informed decisions of how to best recover
  from the attack. The following are a sequence of tests to conduct, that
  will help you finding the facts about the virus.

  A virus can be a boot infector (mbr and-or a boot sector infector), it can
  be a file infector, a companion virus and it can be both (a bipartite or
  multipartite). There is also the slim possibility that you are dealing with
  a cluster infector, but this possibility is so rare that you may ignore it,
  at least in the first stages of your investigation.

  First run the IVTEST probe a couple of times. It will indicate whether
  there is memory stealing, check for boot infection and boot stealth, ant
  try hook the virus with a series of different baits. Boot infectors will be
  sampled into a PARTVIR.NTZ or BOOTVIR.NTZ file. A memory resident virus
  will usually generate a VIRUSAM.PLE file and sometimes a VIR-CODE file too.
  The former is the result of a baiting process, the latter will result from
  the self-baiting of IV's modules.

     Be aware that viruses can be extremely deceitful. Virus writers are
     constantly studying the anti-virus products and they develop techniques
     to evade detection methods. There is a continuously ongoing battle
     between virus writers and anti-virus developers. You will find that not
     all detection methods work on every virus, and you should not expect
     they do. InVircible's generic detection is built with a fail-safe
     methodology, assuming that the capturing of virus activity by a single
     sensor suffices to alert the user. With sophisticated viruses this is
     all that you may get - a single alert, by a single sensor, that
     something is wrong. An alert should prompt a virus aware user to further
     assess the situation.

  You should always assume the probability of a multipartite infector, even
  if only boot infection was found, and you need to discard this possibility
  before proceeding to recovery. Negative results to launching IVTEST does
  not mean there isn't a file infector active.

  A low risk approach would be to boot from the rescue diskette and run IVB,
  the integrity checker, from the floppy, on all the hard drive's files. The
  pattern will become immediately evident in case a file infector, or a
  multipartite was active on the disk.

  It's also worth to explore the mbr and boot sector with RESQDISK (from the
  main menu) whether they have changed, by simply 'restoring' both sectors
  from backup and watching if anything changes in their presentation on the
  display. Be sure that you are using the right rescue disk before attempting
  the above, for the right computer, and that the rescue is up-to-date.

  Finally, run the correlator, IVX, to see if there are more infected files
  than the ones reported by IVB. Select one of the modified files, pointed by
  IVB as the sample to compare to. See in section 7 how to use IVX. The files
  found in high correlation with the sample and not contained in IVB's
  report, are the most likely to having brought the infection into the
  computer.

  It may be worth running IVSCAN, in case the virus is contained in IVSCAN's
  database. If you wish, and have an up-to-date scanner other than IV's, then
  you may learn the name of the virus, provided it has one, and it is
  contained in the scanner's database.

  At this point you got sufficient information to proceed on removing the
  virus.


  10.4 How to Recover an Infected Computer.

  Occasional infections of the boot bloc are usually recovered by IVINIT,
  during initialization, when run from autoexec. IVINIT's recovery is
  especially effective against stealth boot infectors. IVINIT will usually
  prompt to reboot the computer after disinfecting from a boot infector.
  Rebooting is necessary to remove the virus from memory too. When no more
  boot infection is reported after restarting the computer, you then know
  that the disinfection was successful.

  It is good practice to check your floppies after a boot infector was
  removed from the hard drive, since write-enabled disks that went through
  the drive are now probably infected. The simplest would be to process
  floppies in bulk with FIXBOOT. The latter will place a clean boot sector on
  floppies, regardless of whether they are infected or not.

  Not all boot infections are obvious. In case of a boot infection of the
  hard drive was found and IVINIT did not remove the virus: Boot from the
  rescue diskette and restore the mbr and boot sector from their image files
  by pressing F1 then F3, when in ResQdisk.

  File infectors are usually removed by IVB, after booting from the rescue
  diskette. First, run IVB in the default mode (check only) on the affected
  drive and assess the extent of the infection. Watch that all "changed"
  files follow the same pattern, i.e. their size increased by about the same
  number of bytes.

  Next, run the correlator, IVX, using one of the infected files as the
  reference sample. Establish the parameters for the best scan and watch the
  number of correlating files found. Usually, IVX will find more affected
  files than IVB. Save a copy of the infected sample on a floppy, you will
  need it later.

 Next run IVB in the restore mode (/R). Select between file by file or
 automatic recovery ("recover all" option) depending on the pattern of
 the changes.

  Finally, repeat the IVX correlation scan, this time by using the saved
  sample, from above. This time only the infected files that had no
  pre-infected signature will show up. You can use the "Rename" or "Erase"
  option to neutralize these files. The last step will provide a good idea of
  the source of infection of this particular computer, or file server.
  Renamed or erased files can be replaced from clean originals or backup. Use
  IVX, with the saved sample as reference, for the presence of the infector.

  Infected samples can be sent by e-mail or on floppy to NetZ Computing, for
  analysis. See in the on-line help for NetZ addresses.


  10.5 Advanced Virus Analysis Methods.

  This section is written for advanced users and security experts only.
  Inexperienced users are advised to ask for assistance in case they believe
  they need to use the following methods.

  Full stealth viruses can be cleaned and removed from files by virus
  cooperative methods. Therefore, it is important to determine whether a
  virus is a full stealth one or only semi stealth.

  A virus is considered "full stealth" if the infected files exhibit no
  changes when inspected while the virus active in memory. The following is
  how to test this. Preferably run the tests on a dedicated test machine, or
  on a floppy, with the hard disk set to "not installed" in the setup.

  First, initialize new integrity signatures of the control group files with
  the IVB /S command. Next, infect the programs by whatever infection
  algorithm the virus uses (direct action, piggybacking, execute program
  etc.). While the virus is still active in memory, check the files with
  IVB's default mode. Full stealth viruses will report nothing, while
  semi-stealth viruses will report "file was modified, no change in size".


  10.6 Virus-Cooperative Integrity Recovery.

  Full stealth viruses, except cluster infectors, can be fully recovered
  through virus cooperative methods. The most straightforward one is
  integrity recovery. This method takes advantage of the virus properties
  itself. Before applying this technique to large number of files, test it
  first on a control group and if successful, apply it on the affected
  directories and drives. Always prefer operating on selected directories
  rather than on whole drives or volumes.

  With the virus active in memory, secure the affected directory or drive
  with the command: IVB /S [pathname]. Activating the virus can be achieved
  by deliberately running an infected program.

  When done, reboot from the rescue diskette or from clean DOS and restore
  all files with the command IVB /R [pathname]. Do not use the same copy of
  IVB.EXE that was used for securing, even if IVB indicated that it restored
  itself. Some viruses reinfect on 'closing' the file. Use a clean copy of
  IVB, from the rescue diskette, for example.

  Test a few restored files by executing the programs, to assure the recovery
  was good.

  The following are viruses that respond well to cooperative integrity
  restoration: All strains of Frodo (4096), Tremor, Natas, Die-Hard_2,
  Hemlock and more. Natas and Hemlock are multipartite and need cleaning of
  the mbr too. The mbr infection of Natas and Hemlock is stealth too and can
  be recovered with cooperative SeeThru. See next section for details.


  10.7 Virus-Cooperative Piggybacking (Retro-Piggybacking).

  Cluster infectors cannot be recovered with the above method because of
  their peculiar infection mechanism. It consists of inserting the virus code
  in the file by manipulating pointers in the directory entries or in the
  FAT. There are actually just a couple of such viruses, DIR_II and
  Necropolis (1963), with a few strains of each.

  DIR_II is almost extinct as it cannot survive in a DOS 5 environment and
  higher. Necropolis is in the wild and is still common in many places.

  Many full stealth viruses, and cluster infectors in particular, can be
  disinfected by virus-cooperative or retro-piggybacking. The principle
  behind this method is the same as in integrity recovery, except that the
  disinfection is performed with the virus actually in memory. Cooperative
  piggybacking is embedded in IVSCAN and can be invoked from the command line
  only. Inverse piggybacking if used in the wrong circumstances can cause
  irreversible damage to infected files. Therefore this method is not
  available from IVMENU.

  Some full stealth viruses like Tremor, Natas and Frodo can be disinfected
  by either cooperative integrity or retro-piggybacking, others can be fixed
  only by one method or the other. The way to find out which method suits a
  particular virus is by trial and error. Before applying a method to a large
  number of files, always test first on a control group containing a limited
  number of infected files, or on a dedicated test machine.

  Retro-piggybacking is effective against full stealth viruses only.

  10.7.1 Retro-piggybacking (RP), method 1 (/M1).

  Retro-piggybacking, method 1 is activated by running:

                          IVSCAN /M1 [pathname]

  This method is effective against full stealth viruses of the file infector
  type and against Necropolis (1963 - a cluster infector).

  Before activating RP method 1, turn off all disk caching as disk caches
  have a counter effect on retro-piggybacking. The simplest is to bypass
  config.sys and autoexec.bat by either renaming them, or pressing F5 while
  booting, if you run under DOS 6 or higher.

  The virus must be active in memory when starting RP method 1. Apply method
  1 selectively only to directories that contain infected files. When done,
  reboot the computer without executing any other command, since the virus is
  still active in memory and the end of the process.

  Retro-piggybacking, method 1 is a single pass process. The files will be
  clean after rebooting. Method 1 is invoked automatically when running
  IVSCAN /R, and Necropolis (1963) is found active in memory.

  10.7.2 Change attributes, cleaning method 2.

  Some viruses, DIR_II specifically, remove themselves from system files.
  Cleaning method 2 takes advantage of this property by changing the files'
  attributes with the virus active in memory, and restoring the attributes to
  original when rebooted clean. Method 2 is virus- -cooperative and will
  function only when the virus is active in memory. To invoke method 2 run:

                          IVSCAN /M2 [pathname]

  When done, reboot the computer immediately, as the virus is still active in
  memory. You will notice that all the executable files seem to have
  "disappeared". They are still there, but their attribute was changed to a
  hidden, and you can't see them with the DIR command, nor run them by
  invoking the program's name. To restore the attributes to original, run
  from a clean copy of IVSCAN:

                          IVSCAN /M3 [pathname]

  Cleaning method 2 is invoked automatically when running IVSCAN /R, and the
  DIR_II virus is found active in memory.


  10.8 Virus-Cooperative (SeeThru) Boot Bloc Recovery.

  The master boot record (sector) of the hard disk is a favorite target for
  viruses. Those that use stealth are especially easy to recover from by
  cooperative generic methods. Stealth boot infectors usually hook BIOS
  interrupt 13h, the one used to read and write to absolute disk sectors, in
  order to conceal their own presence.

  InVircible uses low level tunneling techniques that "see through" virus
  stealthing of interrupt 13h. SeeThru is widely used in InVircible for the
  detection of boot infectors and their disinfection.

  IVINIT will suggest the recovery of the mbr in case stealth infections of
  the mbr is detected. IVSCAN will prefer cooperative SeeThru for the
  recovery of a stealthed mbr and ResQdisk will permit the manual recovery of
  the a stealthed mbr, providing visual control of the process.

  Cooperative SeeThru is safer than using the undocumented FDISK/MBR command.
  The latter will install a standard bootstrap program in the mbr,
  overwriting the current one, while retaining the existing partition data in
  the sector. While this procedure may help in many cases to remove an mbr
  infector, it may in others cases cause loss of access to the hard drive or
  cause it loose self booting capability. The FDISK/MBR undocumented command
  should not be used in case of infection by an overwriting mbr infector
  (Monkey for example), or when a special boot driver (DM 6.03+, EZ-Drive) is
  used, with access control systems, Boot Manager, OS/2 partitions, Windows
  NT or with other than FDISK partitions.

  Instead, the method based on cooperative SeeThru will reinstate the
  original mbr. InVircible will capture the original mbr as returned by the
  virus stealth and will rewrite it to the physical location of the mbr, on
  the hard disk.

  IV's SeeThru functions only with IDE and E-IDE drives. With other drive
  types like SCSI and MFM, use the technique described later.

  Whenever a boot infector is suspected, then assume that all floppies that
  were used on that computer might be infected as well. After disinfecting
  the hard drive, process all floppies with FIXBOOT, the complimentary
  utility provided with InVircible. FixBoot will install a standard DOS 5
  boot sector to the floppies.


  10.9 Removing Stealth Boot Infectors from SCSI and MFM Disks.

  The problem with tunneling under DOS and BIOS to find INT 13h's original
  handler is that there is always a way to defeat it, no matter what method
  is used. DOS and BIOS interrupts are virus realm. Viruses cannot thwart low
  level hardware tunneling, yet IV's SeeThru does not work on all drive
  types. When SeeThru is unavailable, then a message "SeeThru OFF" will pop
  up when running IVINIT, IVSCAN or IVTEST. This should not concern you
  unless something else happens.

  Boot infectors, except few, disclose their presence by memory stealing.
  They will also usually relocate the original mbr or boot sector to
  elsewhere on track zero. Others will patch the mbr without storing a copy
  anywhere, but will write virus code elsewhere on track zero. Boot infectors
  that use stealth conceal just the faked mbr itself. These properties can be
  used for detecting stealth virus doing on the hard disk. It's especially
  useful on drive where SeeThru is not available.

  When installing InVircible to the hard disk, an image of track zero is
  stored to disk root directory, in a hidden file. Non-stealth boot infectors
  are detected by IVINIT when executing the autoexec. The presence of a
  stealth boot infector will usually be indicated by memory stealing, Qemm
  will not load, or Windows' 32 bit access driver will not load. Each one of
  the above symptoms should alert the user of the possibility that a stealth
  boot virus infected the disk.

  Run ResQdisk and visually inspect track zero for the traces of unusual code
  that wasn't there before. You may wish to compare the current content of
  track zero to the one at the time you installed IV. Run ResQdisk an press
  ^Z. When you select compare, then ResQdisk will scan through track zero and
  stop on every sector that was changed from the time the backup was made.

  Non-stealth viruses can be removed the generic way. The best is to find the
  original but relocated mbr on track zero and to rewrite it to sector 1.
  Before proceeding verify with the 'analyze' (^A) function that the sector
  contains correct data that fits the hard drive. The number of partitions
  should fit and the total number of sectors, multiplied by 512, should
  approximately equal the partition's capacity.

  Pick the selected sector with ResQdisk's 'cut and paste' (^E) and write it
  back to sector 0,0,1. When no copy of the original mbr or boot sector can
  be found, and there is no rescue diskette either, then you may have no
  other choice except refreshing the bootstrap program (this is the one that
  gets infected) with a generic one. Both sectors can be refreshed by
  positioning ResQdisk on the desired sector and pressing F1-F4 in sequence.
  The DOS boot sector can be refreshed from ResQdisk's ^B menu and selecting
  'SYS'.

  To remove a stealth boot virus, boot clean from the rescue diskette, run
  ResQdisk (the rescue floppy default) and restore the mbr by pressing "R".
  See section 8 for reading how to use ResQdisk.

  In case there is no rescue diskette and the computer is infected by a
  stealth boot infector then format a floppy in drive A:, transfer the system
  files to the floppy with the command SYS A:, next copy the RESQDISK.EXE
  module to the floppy, log onto the floppy and run RESQDISK/B, to create
  backup images of the boot and mbr sectors on the floppy. Since the virus is
  stealth, then the image files are those of the clean sectors. Finally, run
  FIXBOOT A: and remove the floppy from drive A without running any other
  command. If you have access to a clean computer then AFTER having prepared
  the boot images on the floppy, run SYS A: on the clean machine, instead of
  running FIXBOOT.

  Boot from the clean floppy and run RESQDISK /R for automatic recovery, or
  you may recover the sectors one by one under the visual inspection of
  ResQdisk.

  The following are exceptions when NOT use the generic F1-F4 mbr refresh
  method. Do not use it in case access control password software is installed
  to the hard drive, that use encryption of the mbr. Neither use this method
  when the partition data was overwritten by a virus. A rule of thumb is
  this: Boot the disk from the rescue diskette or from clean DOS. If the hard
  drive is inaccessible, then don't use F1-F4. Note that you should not use
  FDISK/MBR either in these conditions, as their function is the same.


  10.10 Removing Boot Viruses from Floppies.

  Unlike the disinfection of programs, floppies' boot sectors can be
  disinfected easily without knowing what virus infected them. IVSCAN can be
  used to inspect floppies and will alert on the presence of both known and
  generic boot infectors. If found, IVSCAN will announce "boot virus [name]
  was detected". Not in all cases there will be a name, depending on whether
  the virus is contained in IVSCAN's database. Since InVircible prefers
  generic methods, then having a virus name is the exception with IV. If
  interested in the virus name, then you may want to scan it with your
  favorite scanner.

  Cleaning floppies from boot viruses can be done by IVSCAN, one by one, or
  in bulk processing by FIXBOOT. When a boot infection of a hard disk is
  found, then it's most likely that floppies are infected too in the
  workplace. First disinfect the hard drive as inspecting from an infected
  computer will infects the floppies processed. IVSCAN /R [drive] will
  attempt to find the original boot sector and remove known and generic boot
  viruses. IVSCAN /B will force a boot sector replacement, either by finding
  the original sector or by installing a standard one. Both switches, /R and
  /B have a limitation: They are unable to clean a floppy having a closed
  loop infection. This situation occurs when both the boot sector and the
  relocated 'original' boot sector are infected. IVSCAN will then announce on
  an 'indefinite loop infection' and abort.

  This is where FIXBOOT can fix the problem. FixBoot installs a standard boot
  sector to floppies of the following capacity: 360 kb, 720 kb, 1.2 meg, 1.44
  meg or 2.88 meg. FixBoot will sense the floppy's capacity and select the
  right boot sector for it. It will also retain the floppy's bootability on
  condition that it's a DOS floppy, from version 4 and higher and from either
  the MS-DOS or PC-DOS flavor. FixBoot is useful to restore readability to
  floppies that became inaccessible because of a boot infection. A 1.44
  floppy that was infected by B1-NYB will seem as unformatted when read in a
  clean, uninfected machine. FIXBOOT /S will prompt you to select a capacity
  for the floppy and fix that problem. When replacing an infected boot
  sector, FixBoot will announce that it replaced an infected boot sector. And
  last, FixBoot will prompt if to process another floppy, saving a lot of
  time in bulk processing of large number of floppies.

  The files stored on floppies processed by FixBoot will not be altered or
  affected by Fixboot in any way.


  10.11 Disaster Recovery - Regaining Access to a Hard Drive.

  Loosing access to data on a hard drive is a common and daily eventuality
  with personal computing. If not caused by hardware failure, then InVircible
  can help in regaining access to the hard drive.

  First thing to do after installing InVircible is to prepare a rescue
  diskette as explained in section 2. We assume that you also make regular
  backups of your important data. We also advise that you use a FAT mirroring
  program, right in your autoexec.bat. MIRROR from DOS 5 is recommended since
  its complementary program, UNFORMAT, is available in DOS 5+ versions, and
  is also copied to the InVircible rescue floppy.

  Viruses are the least common cause for loosing access to a hard drive. The
  most common one is the wiping out of the setup data stored in the CMOS
  chip. This may happen in result of a mis-manipulation of the computer, or
  from electrical surges, and sometimes even from buggy software. An
  exhausted battery can also cause the same.

  In other cases a damaged mbr or DOS boot sector can be the reason for
  loosing access to a partition. The latter can be caused by a bad
  manipulation of FDISK, the SYS command, buggy software and sometimes just
  by a virus.

  When one of the above occurs, then first thing find your IV rescue
  diskette. Before proceeding, think if the rescue disk is up-to-date and
  reflects the current configuration of your machine. A rescue diskette
  should be renewed with every change to your hardware configuration or
  setup, change to the partitioning of the hard disk, upgrade of the
  operating system, and upgrade of the version of InVircible.

  Boot from the rescue diskette (you may need to setup the drive A parameters
  in case the CMOS was wiped clean). IV will start in the ResQdisk default
  mode. In case the problem is the CMOS, ResQdisk will prompt to restore the
  CMOS data from backup and reboot the computer.

  A damaged mbr or boot sector can be restored from backup either
  individually, by selecting the sector and pressing (R)estore, or
  automatically with F1-F3. Do not use the ^F1 and ^F2 (forced recovery of
  the mbr and boot sector, respectively) unless you are sure that the rescue
  floppy is up-to-date and contains valid and current data of the computer
  you are using it on. Always recover the mbr first, as a messed up mbr may
  point to the wrong location for the boot sector. You may find after
  recovering the mbr that the boot sector is just fine, but was inaccessible
  because of a bad mbr.

  Regaining access to a hard drive without having an IV rescue diskette is
  also possible, yet it requires a licensed copy of InVircible, a bootable
  DOS floppy and a few DOS programs such as FDISK, CHKDSK and UNFORMAT.

  Start by verifying the CMOS setup data and look for hardware problems. Set
  the hard disk parameters in the setup to its correct type, if you know what
  it is, or select any type that will let the computer boot. Even if wrong,
  the disk type can be corrected later, just get the machine started.

  Boot from a floppy, start ResQdisk and watch for its messages. Press F5 to
  read the setup and the manufacturer's IDE parameters. If the data makes
  sense in both columns, then the problem is not a hardware one. If on the
  other hand the IDE data is erratic (provided the hard drive is an IDE or
  E-IDE) then there might be a hardware problem. Switch then the computer
  off, disconnect the power cord, open the computer, check the power
  connection to the hard disk, the flat cables from the controller to the
  hard disk and the controller card's connector to the motherboard. Too often
  it's just a matter of a loose contact. Close the computer, connect to power
  and try again.

  The 'setup calculator' panel of ResQdisk (accessed through F5) should show
  sensible data. The right column should contain non-zero data for IDE or
  E-IDE drives. If it's empty or shows 'not an IDE', then try reducing speed
  (switch turbo off, or press Alt+Ctrl+minus) and restart ResQdisk. If the
  IDE data is now visible then you are having hardware mismatch between the
  hard disk and the IDE controller. The controller is usually the problem,
  rather than the motherboard or the hard disk. Try changing the hard disk
  mode in the setup, this might solve the problem. Common setup problems are:
  LBA is used with small capacity and older drives (don't use LBA if not
  needed!), mode 3 or 32 bit mode is used with hardware that does not support
  these modes. It's also possible that the hard drive is simply too slow (and
  perhaps too old) for the new Pentium/120 mhz just acquired.

  Use the ResQdisk setup utility (F5) for finding the original disk's
  configuration parameters. The parameters in the setup and those of IDE disk
  manufacturer may differ. However, they should combine to the same disk
  capacity. An IDE drive that was configured and formatted with setup
  parameters that differ from the manufacturer's will function improperly if
  those parameters are not restored to the same as when configured.
  Fortunately, these parameters can be found with a little detective work and
  the help of ResQdisk.

  Look with ResQdisk for the boot sector. It should normally be accessed with
  the Left arrow key. If not there then you may find it elsewhere on track
  zero. Suppose you found the DOS boot record in sector 0,0,52. Press ^A to
  check its content and note the number of heads and the hidden sectors. The
  latter is usually equal to the number of sectors per track. In this case
  the number of sectors per track should be 51.

  Now go to the setup utility (F5), set the number of heads and sectors per
  track to those found in the boor sector, and change the number of cylinders
  until the number in the "capacity" field equals that of the manufacturer's.
  Write down the parameters, exit ResQdisk and these parameters in the setup.
  Reboot, and the disk should be accessible.

  A different situation may exist when the mbr or the DOS boot sector were
  destroyed or their data was modified. ResQdisk can restore access to such
  drive when either of the two sectors exists, but not if both were
  destroyed. In such case you will need the ResQpro version. Another
  limitation of ResQdisk is that it can recover only the first partition of a
  physical hard drive. If the disk was partitioned with more than one logical
  partition, then you'll need ResQpro. InVircible Pro, with ResQpro is
  available from InVircible agents.

  ResQdisk will prompt to press ^F1 or ^F2 to reconstruct the mbr or the DOS
  boot sector, respectively. After reconstructing either of the above you
  need to reboot the computer in order of the renewed sector to become
  effective.

  To reconstruct both sectors, or to recover a higher partition you will need
  either a ResQpro kit, or to contact an IV agent, to authorize a single
  ResQpro session. When authorized, then press ^F4 to start searching for
  partitions on the hard disk. ResQpro will only handle DOS partition that
  were prepared with FDISK. It's important to understand the way FDISK
  prepares more than two partitions on a single physical disk. Each partition
  sector has provisions for up to four sub partitions. Yet the mbr contains
  usually only data for two partitions only: The primary DOS partition and an
  extended DOS partition, occupying the space left after allocating the
  primary DOS partition.

  Higher partitions are the subdivision of the extended DOS partition. The
  extended DOS partitions are usually written into the second partition's
  partition sector. ResQpro reconstructs the mbr only. Therefore, only two
  partitions need to be rewritten to the mbr. ResQpro will prompt and ask to
  confirm for every partition found while searching the disk. Only the first
  one should be confirmed. It is worth writing down the coordinates of all
  the partitions found, as it may be helpful if manual disk editing will be
  needed, later. ResQpro will report its finding and prompt before writing
  the data to the mbr.

  IV agents may authorize a single ResQpro session (see the AGENTS.LST). For
  ResQpro's password, run ResQdisk and press ^F10. Proceed as instructed by
  InVircible's hotline support.

  See also ResQdisk and ResQpro.


  10.12 Handling Cluster Infectors.

  There are two known cluster infectors that appeared by the end of 1991,
  Necropolis (1963) and DIR_II. Both originate from Bulgaria.

  DIR_II is almost of no interest, as it does not survive in DOS 5 and
  higher. When not active in memory, CHKDSK will indicate that all infected
  files are crosslinked on the same cluster, usually the highest free one in
  the partition. To clean from DIR_II run IVSCAN as described above. To clean
  large partitions (more than 32 meg) with IVSCAN you will need to boot from
  DOS 4.01. For smaller partitions you may boot from DOS 3.30.

  CHKDSK will show allocation errors on files infected by Necropolis (1963),
  when the virus is not active in memory. 1963 is removed with IVSCAN by
  retro-piggybacking. Do not run retro-piggybacking on a drive infected with
  Necropolis, unless you are sure the virus is active in memory. 1963's
  presence in memory is clearly indicated by the response of IV's self
  integrity check.

  In case a cluster infector is suspected, then do not use the CHKDSK /F
  switch until the disk is completely disinfected! Using the /F switch will
  ruin the infected files beyond repair.


  10.13 Screening New Software.

  The purpose of screening is to detect infected software at the earliest
  possible stage, and to prevent it from infecting other programs or hard
  drives. Screening consists of two stages:

     Preliminary screening against known and generic viruses. Scan all
     new software with an up-to-date third party virus scanner and with
     IVSCAN. Preliminary screening need to be run just once on all new
     software and distribution floppies.

     Active screening is performed under the surveillance of InVircible
     to capture new viruses that passed the preliminary screening process.
     Any virus that is unknown to the scanner may be considered as "new", at
     least to the scanner. As new, or virtually new viruses are caught at the
     active screening phase, then the updating rate of the scanner may be
     relaxed, compared to where InVircible is not used.

  Active Software Screening.

  The ideal screening machine is a stand alone PC (not connected to a
  network) with a hard disk running under DOS, and with functional
  applications installed on the hard disk. IV should be installed, all
  programs should be secured by IVB and an IV rescue diskette for that PC
  should exist.

  Install the software to be tested to the screening machine, as instructed
  by its producer and secure the new files by running IVB.

  Exert all the functional and executable modules of the software under test,
  then exit back to DOS. Run IVINIT, then IVB, on the whole drive content.
  Reboot and watch IV's tests for exception messages.

  Reboot clean from the rescue diskette, run a ResQdisk Compare track
  zero test to check for changes, run IVB on the hard drive to seek for
  changes and if nothing is found in any of the tests, then the software may
  be declared clean from virus.

  Software screening is especially important in the corporate and
  institutional environment where infected software could be distributed
  throughout the organization. Boot viruses are more prevalent, but their
  damage is limited to a local hard drive and they cannot propagate through
  the network. File viruses are far less prevalent, only 30% of the reported
  incidents, but their damage can be devastating as they may affect many
  files on hard drives and on file servers and they propagate across
  the network with the server acting as a virus mailbox between
  workstations.


  10.14 Common Problems, How to Handle Them.

  The following are the most common alerts that IV may provide, and what to
  do in case they happen.

  Memory stealing: Normally attributed with boot infection. Watch for
  other messages while running IVINIT and IVB. If no other message appears,
  then run ResQdisk. Inspect track zero (^Z) in the Compare mode. Repeat
  the ResQdisk inspection from the rescue diskette, in case it's a stealth
  boot infector and the drive isn't an IDE.

  Boot infection: A boot infection will usually follow a memory stealing
  message. In the case of a stealth boot virus the "faked" sector warning
  will follow. The remedy to these viruses is in IVINIT, IVSCAN, ResQdisk and
  in the rescue diskette.

  Faked partition (or boot sector): Indicates the detection of a stealth
  boot infector on an IDE hard drive. Partition sector (mbr) infections are
  also considered as "boot". The remedy is SeeThru recovery with IVINIT,
  IVSCAN or ResQdisk.

  When a boot infection of the hard drive is detected, then assume that there
  floppies in the workplace could be infected too. After cleaning the hard
  drive, process floppies with FixBoot to remove possible boot viruses.

  Virus active in memory: A memory resident virus may disclose its
  presence in one or more ways. It may trigger the self baiting of the IV
  module, it can infect special baits launched by IV, and it the later case,
  the virus will be sampled into a sample file named VIR-CODE, VIRUSAM.PLE or
  in both. The sample files are used by the correlator scanner, IVX.

  Piggybacking detected: Indicates the activity of a fast infector or a
  file killer (a virus that erase files on selective criteria). Piggybackers
  infect host files while they are accessed such as with antivirus scanners
  for inspection. The detection is based on actual infection occuring on a
  few files. Known fast infectors can be removed in the screening process,
  while unknown and new piggybackers are detected by IV, before they caused
  any significant damage. The few programs that were 'sacrificed' in the
  detection of the process can almost always be recovered by IVB, or replaced
  from backup.

  Because of the risk of piggybacking, never run a scanner, not even
  IV's on a remote drive or a file server without assuring first that
  there is no piggybacking. Run an IV scanner on a write enabled local
  hard disk to discard such possibility.

  Full stealth fast infectors can be removed by virus coperative methods such
  as retro-piggybacking or cooperative integrity recovery.

  Virus was sampled to file: IV has a dedicated viral probe and sampler
  named IVTEST. IVTEST can run on demand to sample an active virus into
  files. IVTEST will also produce a PARTVIR or BOOTVIR sample when a boot
  infector is found. The type of sample, their size, and the meessages issued
  by IVTEST are very instructive in assessing the characteristics of the
  virus and should be reported to support personnel.

  File changed: The nature of the changes is always indicated by IVB. It
  can be an increase, or decrease in file size. An inconsistent change
  pattern is most probably a new version of a program. IVB will then prompt
  for renewing the signatures database. A single modified file or several
  modified ones, with an inconsistent change pattern are not a virus but
  something else. In such case check for file corruption with CHKDSK. Only a
  consistent change pattern in several files indicate a virus doing. The
  remedy is to restore the files to their preinfected state with IVB, after
  booting clean from the rescue diskette.


  11. InVircible, Windows and OS/2.

  InVircible will function properly in DOS Box and in DOS Virtual Machine
  (VDM) environments of DOS connective operating systems. Since InVircible
  does not use, nor need memory resident components, then its integration in
  the new operating systems is simple and straightforward.

  For your convenience, InVircible is distributed with the IV.PIF and IV.ICO
  files, for importing IV into the Windows desktop. Refer to the Windows
  operation manual on how to import the IV PIF and icon files.

  Non-DOS operating systems are fairly immune to DOS viruses, and the latter
  are the only ones to be concerned about. DOS file infectors are inactive
  while in an OS/2 or Windows session. When running a task in a DOS Box, then
  DOS is emulated by the parent OS, and again, viruses are powerless in
  emulated DOS. Only when in a full screen VDM DOS shell, then DOS is
  reinstated, yet not fully, as in plain DOS. As far as virus are concerned,
  many will function in VDM just the same as in DOS, others may crash or
  behave strangely. InVircible functions properly in the VDM environment,
  with the same limitations imposed by the parent OS on all DOS applications.

  Therefore, when IV detects virus activity in a VDM session, then save the
  data of all open tasks, close all tasks in an orderly manner and exit to
  full plain DOS. Corrective anti-viral actions should always be run from
  full plain DOS.

  The main risk to the PC operating in other than DOS environment (Windows
  NT, Windows 95 and OS/2) comes from dumb DOS boot viruses. When an infected
  floppy is left in the boot drive and the PC is powered on and becomes
  infected, then in some cases the OS will start and just ignore the boot
  infection. Yet, in other cases the OS may not start at all, and in extreme
  cases, the hard drive may become inaccessible.

  The remedy to this situation is an IV rescue diskette. In some cases
  ResQdisk could recover access to an inaccessible drive without the rescue
  diskette, but you shouldn't rely on this, as it isn't guaranteed at all!

  Preparing a Rescue Diskette for a non-DOS Disk. The following procedure
  is recommended for Windows NT servers and OS/2 systems. On any DOS machine,
  prepare a bootable floppy and copy to it RESQDISK.EXE. Boot the target PC
  from the DOS floppy and run from the floppy:

         RESQDISK /B
         RESQDISK /Z/B

  ResQdisk will take snapshots of the mbr, the boot sector, track zero and
  the CMOS setup data. In case of an infection, boot from the rescue floppy
  and use ResQdisk to recover the setup data, the mbr, boot sector, or the
  whole track zero.

  Windows 95. Install IV normally if booting to DOS in Windows 95.
  Restart the computer in full DOS (Alt+F4, select "Restart in DOS") to
  install the IV license from the distribution floppy. The rescue diskette
  should be prepared from full DOS. Then restart the computer back to Windows
  95.

  If booting Win 95 directly in Windows mode then import IV.PIF and edit the
  PIF command file with the Windows PIF editor. Replace the program to
  execute from IVMENU to IVB.EXE and change the command line argument
  from /0 to C: DAILY.

  OS/2 Boot Manager. Boot in DOS mode and install normally.

  NT Servers. The protection of an NT server doesn't differ from the
  protection of any server. See also in NETWORK, how to viruses in the
  network environment.


  12. CPAV's Inoculation.

  CPAV is now a discontinued anti-virus product, yet there are still many
  copies around. CPAV had an option that would let a user to 'immunize' or
  inoculate executable programs with a protective shell. InVircible detects
  the CPAV inoculation in files and alerts the user of their presence. From
  other anti-virus products F-Prot does the same and there may be others as
  well.

  This file inoculation is the cause of problems. Many programs do not
  tolerate being inoculated, especially not DOS files, but not only them.

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

  Inoculation has many drawbacks and practically no merits. First, the 700 to
  900 bytes waste quite a lot of disk space. Secondly, inoculation causes
  some programs to malfunction. Thirdly, the recovery of an immunized file
  will in most cases worsen the situation. In order to drop the virus the
  infected file should be run, at the risk of loading the virus into memory
  and infecting other files. And lastly, inoculation is ineffective against
  smart viruses like full stealth ones. InVircible's files, when inoculated
  by CPAV will be ruined irreversibly and will not restore themselves. When
  the CPAV inoculation is removed from IV files, then they will not function
  properly anymore.

  Except for its malfunctions, there are good reasons why not to inoculate
  programs. The inoculation may hide a virus that infected the file prior to
  its inoculation. A dedicated virus may simply peel off the inoculation,
  infect the file and then re inoculate it as if nothing happened. Since
  InVircible can and does peel off the CPAV inoculation then there is no
  reason why a virus couldn't.

  InVircible will indicate files immunized by CPAV by either scanning them
  with IVSCAN or IVB. IVSCAN can remove CPAV's immunization in the "Remove"
  mode (IVSCAN /R).

  Unfortunately there are differences between versions of CPAV, so it is
  safer to disimmunize files by the same product that inoculated them in the
  first place, CPAV.

  Use the following procedure only if there is no other alternative, and with
  all precautions. Backup the files to be recovered. IVSCAN will remove the
  CPAV inoculation from files when used with the /R switch.


  13. InVircible and Memory Resident Anti-Virus (TSR).

  Two type of TSR are used in various anti-virus packages: TSR scanners - the
  majority, and virus activity blockers, or behavior blockers.

  Anti-virus TSR affect the computer's performance and its normal operation.
  Some TSR, especially behavior blockers, interfere with InVircible's
  operation and with other applications as well.

  Among the adverse effects of anti-virus TSR are: They slow down the
  computer operation, especially disk access, they waste precious computer
  resources such as memory and CPU time, they tend to conflict with
  applications and they constantly risk crashing memory and hang the
  computer's operation.

  As for the TSR effectivity, it can only handle viruses contained in its
  database and thus needs frequent updating. An anti-virus TSR scanner
  database handles usually far less viruses than the on-demand scanner from
  the same producer. More viruses can be found simply by screening new
  software with the scanner than with the TSR. Therefore, it's more logical
  to screen new software once with a good scanner, than to constantly suffer
  the oppressiveness and inconvenience of the TSR.

  TSR scanners and TSR behavior blockers should be loaded after InVircible
  completed its tests in the autoexec, to avoid them from interfering with
  IV.


  14. Practicing Antivirus Strategies, the AV Practice Lab (AVPL).

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

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

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

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

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

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

  Prior to experimenting with AVPL please read its online hypertext guide.
  AVPL is available from IV distributors, anonymous ftp sites, AOL and
  CompuServe. AVPL is freeware, the file name AVPLxxx.ZIP. XXX denotes the
  version.

  For users with knowledge about viruses: Rehearse with real viruses on an
  isolated (not in a network) computer to get the feel of what a virus attack
  is like. Experiment only with controllable and 'well behaved' viruses such
  as Stoned, Jerusalem and Frodo (4096). Avoid Trojans, and deliberately
  destructive viruses, there are rare and there is little to learn, if
  anything at all, from sheer destruction.

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


  15. Troubleshooting.

  InVircible uses unique low-level hardware access methods to dig out and
  remove tough and elusive viruses. Though, these very same methods sometimes
  uncover hidden flaws in hardware and incompatibilities. The most common are
  problems with an IDE drive, special controllers, and sometimes with special
  drivers used in the config.sys.

  Among the few spotted by IV are a model of Promise hard drive controller
  and an old series of hard drives from Maxtor. The latter was traced to a
  design problem with that specific series of IDE drives. Maxtor was notified
  and acknowledged they know about the problem.

  To find whether a problem is caused by a conflict of IV with hardware or a
  conflict with other software, then start DOS and bypass the autoexec and
  config by pressing F5 (DOS 6+ users) and run the IV module that
  malfunctioned in the clean DOS environment. If it works clean, then search
  for the cause in a drivers or TSR which is loaded before IV. Use the F8 key
  while starting DOS to step through the drivers, one by one.

  Use elimination until the driver, or TSR in conflict is found. You may then
  change the order in which TSR are loaded not to conflict with IV. In
  certain cases you may find that a driver or TSR that conflicts with IV,
  causes problems elsewhere too. In many cases you may give up the driver and
  improve performance. If the driver is absolutely necessary, then you may
  have to give up IV.

  Anti-virus scanners and behavior blocker TSR are a constant source of
  conflicts with InVircible. Scanner TSR with background checksumming, such
  as VSAFE and Norton AV (NAV) will trigger IV's piggybacking sensor. There
  isn't real virus piggybacking, but there is one of the checksummer.
  Background checksumming slows down disk access and you may wish to turn
  this option off.

  Behavior blockers such as Thunderbyte's TBfile and TBcheck intercept IV's
  self baiting and the bait launching processes and may crash the computer.
  If you need a memory resident behavior blocker then you should load it
  after the IV tests were completed. You should also remember not to run
  an IV module once the behavior blocker is loaded to memory.

  As mentioned elsewhere, IVB, the integrity analyzer will usually be the
  first to notice file structure problems such as crosslinked files and FAT
  allocation errors. In case inconsistent changes in files is reported, then
  check with CHKDSK and act accordingly.

  Common Problems: Most users are unaware of the problems caused by DOS's
  undelete tracker. It is loaded to memory with the UNDELETE /LOAD or
  /S (sentry) command. The undelete tracker will create a hidden directory
  with the name \SENTRY, often confused with the IV Sentry mode. A copy of
  deleted files are stored in the \SENTRY directory, until purged. Except
  eating up disk space, the undelete sentry tracker often causes false
  piggybacking alerts, or file killer presence alarm. If not really
  needed, then turn the undelete tracker OFF, or do not run the IV scanners
  when the tracker is loaded in memory. Since IVB DAILY is written to the
  beginning of the autoexec, before loading the UNDELETE sentry TSR, then
  there should be no problems with the IVB daily inspection.

  NetZ Anti-Virus Utilities: From time to time NetZ releases useful
  utilities to assist handling virus related problems and disaster recovery.
  A set of such utilities consists of FixBoot as described here, SWAPBOOT,
  used to swap drive A and B and let boot from B without requiring to open
  the computer cover for swapping the cables, and XMONKEY, a program that
  will remove the Monkey mbr infector from up to eight installed hard drives.
  The three utilities are freeware and are available from BBS and the world
  networks.

  Dedicated Purpose Packages: From time to time NetZ releases dedicated
  purpose packages containing one or two modules, with ad-hoc documentation.
  Such were RESQDISK - a dedicated disaster recovery package, IVX - dedicated
  signature extractor, signature and correlation scanner, and XCAIBUA - a
  dedicated virus scanner derived from IVSCAN, to constrict the outburst of
  the new Big Caibua virus.


  16. Upgrading and Support.

  InVircible does not require frequent updates, thanks to its generic
  features. IV let recover from both known and unknown viral infections.
  Still, IVSCAN is seldom updated on a need-to basis, to handle just the
  most common fast spreading viruses.

  InVircible is undergoing a continuous improvement process through
  upgrading. As computer virus technology evolves, its counter techniques
  should evolve too, to cope with the new techniques. Such are SeeThru,
  introduced in 1993, the IV Armor and the new hyper-correlator, both
  introduced in 1994.

  In the ongoing process of developing InVircible, NetZ constantly adds new
  features and replace older ones. Thus, IV is continuously upgraded, while
  IVSCAN is just updated on an irregular basis.

  Thanks to its generic nature, a version of InVircible is usable for at
  least a year, or two, without really needing to either upgrade or update.
  At the most, IVSCAN will not identify a virus, but if properly used on
  regular basis - i.e. routine checks by IVINIT and daily inspection by IVB -
  then such viruses will be detected and can be removed too, without knowing
  their name.

  Upgrading your Licensed Copy of InVircible: Licensed copies of
  InVircible are upgraded by overwriting the old files with the new ones, on
  both the distribution floppy and on the hard disk. You may format the
  distribution floppy without voiding its license. The same applies to the
  hard disk. The disk can be formatted with DOS's FORMAT), be reconfigured
  with FDISK, without affecting the license. You may also install/uninstall
  disk compression software without needing to retract your license. Only Low
  Level Formatting, or unrecoverable hardware failure will cause loss of the
  IV license. This is why IV is provided with one spare license on the
  distribution floppy.

  InVircible's upgrades are available through BBS, the Internet, as well as
  from the major networks (CompuServe, AOL, ZiffNet, Prodigy etc.).

  IV and its upgrades can be downloaded through anonymous ftp from the author
  site at ftp.datasrv.co.il/pub/usr/netz/ or ftp.invircible.com, as well as
  from CompuServe (Go InVircible). IV is also available from SimTel and its
  mirrors.

  Timed Fully Featured IV Releases: From time to time NetZ releases a
  fully functional, yet timed version of InVircible. These releases can serve
  for the full evaluation of InVircible. The expiration date of the timed
  license is indicated in a file named EXPIRY.TXT. Past that date, the IV
  copy will revert to Sentry mode. Registered users should download the
  upgrade package instead.

  Support Through E-mail: Questions can be sent through e-mail to
  support@invircible.com, or to the Sysop (go InVircible) on CompuServe.
  Questions to the author should be addressed to netz@invircible.com.


  Appendix A. - A Primer to Integrated Anti-virus.

  ABSTRACT

  This appendix provides an introductory discussion of current generic
  methods of antivirus security. Integrity analyzers are contrasted with
  checksumming methods and several advanced generic techniques of virus
  capture and integrity analysis are introduced. These concepts are then
  applied to virus detection and system recovery with the conclusion that
  generic integrity analyzers provide the most fundamental component in an
  integrated antivirus security protocol.

  INTRODUCTION.

  Antivirus (AV) programs usually belong to one of the following categories:
  on-demand scanners, TSR scanners, activity blockers, and generic AV tools.
  While scanners and blockers are generally understood there is some
  confusion about what is meant by generic AV. For most users, as well as the
  majority of computer security experts, generic AV brings to mind only
  'integrity checking.'

  However, checksumming isn't really a generic AV method. The term generic,
  from the Latin 'genus,' implies that a method is applicable to a group or
  kind, and exclusive of others. While checksumming applies to all viruses,
  it is not inclusive to ONLY viruses. The checksum of a file, or of a
  program, may change for many reasons most of which are not connected with
  virus infection. A few common, non-viral reasons for the changing of a
  file, and of its checksum, are its replacement with a newer version, self
  configuration, and corruption due to truncation and cross linking. There
  are other causes, as well.

  Checksumming has long been used for antivirus integrity testing since
  viruses need to change the hosts they invade in order to get executed and
  replicate. Most antivirus products now include some sort of integrity
  check. The majority use a CRC, while others use a proprietary checksum
  algorithm. Cryptographic methods like DES are used as well. While not yet
  reported, it is possible for a virus to compensate for its presence in a
  file after infecting it. A CRC algorithm is complex enough in order to
  assume that no virus writer will bother to include such an algorithm in the
  virus's code.

  Checksum integrity checking does not take full advantage of the
  capabilities of modern generic antivirus methods. These new technologies
  cover all aspects of antivirus protection. Some of the new capabilities are
  not possible with signature scanners and activity blockers. Generic
  techniques include virus capture, damage recovery, and advanced methods
  like correlation.

  GENERIC VIRUS CAPTURE.

  When a virus strikes, the first event to identify is that something is
  wrong. Since viruses are real programs and they have to execute their code
  somehow, then they necessarily leave traces. Virus capturing, the
  equivalent of detection in generic terminology, is based on the sensing of
  phenomena indicating the possible presence of a virus. This is different
  than finding a specific signature in memory or in a file which is the
  method used in scanners and TSR's. The range of useful phenomena for virus
  capturing is broad and includes self-baiting, self integrity checking,
  verification of memory stealing, launching bait sequences, sensing
  piggybacking or file killing, integrity checking (yes, this too), and the
  sensing of deception like the taking away of the file handle. It's also
  possible to use tunneling for capturing boot viruses, either by tracing the
  origin of certain interrupts, or with hardware access.

  All these generic methods do not require a priori knowledge of specific
  viruses, as is true with signature scanners. All viruses, if they conform
  to the definition of a virus, will disclose their presence to one or more
  of the sensing methods mentioned. This has important implications. Virus
  capturing methods can detect the activity of both existing and new viruses
  which isn't possible using known virus signatures.

  GENERIC INTEGRITY ANALYZERS.

  Integrity analyzers deserve special attention because they are the most
  powerful of the generic methods. A properly designed analyzer can tell you
  more about a virus, in a matter of moments, than any other tool. When
  properly used the integrity analyzer can determine the size of the
  attacking virus, whether it uses stealth, if it's full or only semi-
  stealth (there is a difference in recovering from each), and if the file is
  recoverable.

  To understand how integrity analyzers work it is instructive to compare
  them to integrity checkers. The latter calculates a number (CRC) that
  represents every byte in the processed file. Changing a single byte
  anywhere in the file will result in a different calculated CRC.

  For example, DOS's SETVER.EXE program contains the version table of
  programs written to a special section in the SETVER.EXE file. SETVER
  contains an 'internal overlay'. Entries can be added or removed from the
  SETVER table. Changes to the SETVER table are legitimate as it is the
  purpose of the program, and adding an entry or deleting an entry does not
  necessarily indicate infection. An integrity checker will detect changes to
  the SETVER table without distinguishing between changes due to a virus or a
  legitimate one. An antivirus integrity analyzer can tell the difference.

  The DOS programs that interest us are of two types, COM and EXE. There are
  other executable types, as well, such as SYS, OVL, DLL, and DRV, etc. Yet
  they are of no particular interest to us. Most of them are covered under
  the umbrella of the EXE and New EXE types. Every program has an entry
  point, this is where DOS starts reading the instructions and executing the
  program. The entry point is usually indicated by a 'jump' or 'call'
  instruction at the beginning of COM files, or by a set of pointers,
  contained in the header of EXE programs. In both cases, the entry point is
  well defined and can be found from the file parameters.

  When a virus infects a program, it either appends, prepends, or inserts its
  code into the file and then modifies the entry pointer(s) to start
  execution from the virus code. Let's assume, for example, that we take a
  snapshot of a few bytes at the entry point of the uninfected file. If we
  compare the entry point of an original and infected file, and the bytes at
  the same relative offset to the entry point, we'll see that they have
  changed. Normally we will find three kind of changes in the infected file
  when it is compared to the uninfected one. The header (or the jump address
  at the beginning of the file) has changed, the code itself at the entry
  point has changed, and the location of the entry point has changed, as
  well.

  Just a few significant bytes can reveal more information about virus
  infection than a complete file CRC, or the cryptographic signature of the
  whole file. Moreover, while the latter is incapable of revealing whether
  the change was caused by a virus, the data used in generic integrity
  analysis inherently contains this capability. We need, of course, a few
  more parameters to confirm whether the change is viral, or due to non-viral
  factors such as corruption, or perhaps installation of a newer version of
  the program. A possible way to discriminate between the options is to
  include in a file's integrity database parameters that should NOT change as
  a result of infection by a virus. The presence of these parameters in the
  modified file necessarily indicate a virus infection, and their absence
  implies that the change is not viral.

  Let's now consider the potential of integrity analyzers for determining the
  specific file alterations and methods of operation used by a particular
  virus, and how to handle them. Many of the newer viruses use stealth,
  although not all have full stealth capability. Discriminating between semi-
  and full stealth depends upon whether an integrity checker can detect
  changes when the virus is active in memory. If no changes are detected,
  then the virus is full stealth and cooperative methods can be used to
  remove it. If changes can be seen when the virus is active in memory, but
  no change can be seen in file size, then the virus is semi--stealth. Some
  semi--stealth viruses will show a DECREASE in file size by exactly the
  length of the virus code. This is the result of an unsuccessful attempt to
  conceal their presence.

  The conclusion, which is perhaps surprising to some, is that CRC methods,
  and cryptographic signatures, are not the best suited for antivirus
  integrity checking. A generic integrity analyzer is better adapted for this
  purpose. It can identify changes in program files specific to virus
  presence and also potentially critical virus characteristics.


  GENERIC RECOVERY FROM VIRUS ATTACKS.

  Generic recovery is the restoration of infected programs to their original,
  pre-infected state. Many security experts recommend a system should be
  recovered by deleting the infected programs and replacing them with clean
  ones from backup. The main reason experts recommend replacement instead of
  restoration, is because they claim that you can't be sure the restoration
  results in a byte for byte identity with the original program. The fact is,
  however, that this can be easily verified. In the highly technological
  world in which we live, there is no room for superstition or speculation,
  certainly not if the facts can be verified. For a privately owned PC, or
  for a critical application PC, replacement might be the simplest course of
  action. But in business network environments, where time is of prime
  importance, fast recovery of executable programs may be imperative.
  Critical data files can always be restored from backup if there is a
  concern for their integrity. In fact, rapid program restoration can speed
  the process of restoring critical data files from backup by returning a
  system to operational status more quickly.

  Computer viruses are deterministic code and they function in a
  deterministic way, too. Virus names like Satan and Devil's Dance are just
  folklore and have nothing to do with unnatural powers. The exactness of the
  recovery of a program from a virus can be verified easily by comparing,
  byte for byte, a restored program to a clean one from backup. In case of a
  massive infection, generically restore a few infected samples and compare
  them to clean originals to determine whether complete restoration is
  possible. If it is, then you can be sure that the restoration of the rest
  will be complete, as well. This results from the deterministic nature of a
  specific virus's method of infection and the inherent logical structure of
  executable files.

  An advantage of advanced generic methods is that file integrity
  authentication and file restoration can be accomplished using the same
  database files. This capability results from the generic nature of the
  processes involved. It also further demonstrates the value of generic
  integrity analysis over CRC and cryptographically based checksummers. The
  databases of the latter do not contain the information required to restore
  infected programs. A checksum (or CRC) is just a 16, 32 or 64 bit number.
  How can you restore a file with the knowledge that its pre-infected
  checksum was 1234 and when infected it is 4321? By contrast, when critical
  program file characteristics have been sampled and stored in databases, it
  is possible to use this information to restore files to their original
  condition, byte for byte.

  COOPERATIVE RECOVERY METHODS.

  A special category of generic recovery methods are the cooperative ones.
  These apply only to full stealth viruses of both the boot and file infector
  types.

  The principle involved is extremely simple. The recovery process takes
  advantage of the fact that a full stealth virus, either boot or file, will
  present the correct, uninfected data of the inspected sector or file, when
  the virus is active in memory.

  To recover from a stealthed boot infector (MBR infectors are referred to as
  "boot infectors," as well), simply copy the stealthed image of the infected
  sector and rewrite it to the same place using tunneling techniques. The
  advantage of cooperative recovery, over the undocumented 'generic'
  technique known as FDISK/MBR, is that with the cooperative one you write
  EXACTLY what was there in the master boot sector in the first place, while
  in many cases you might cause more harm than good with FDISK. There are
  products that implement this cooperative recovery method under the name
  'SeeThru' technology.

  Another effective file recovery technique is by cooperative integrity
  checking. A new integrity database is established while the virus is still
  active in memory. Then the computer is rebooted and the programs are
  restored from the database made when the virus was resident. This technique
  is effective only against full stealth viruses. It has been implemented
  successfully against Tremor, a common virus in Germany, and works against
  other full stealth viruses such as NATAS, Die_Hard, Hemlock, N8fall,
  Invisible Man, Uruguay, and all strains of Frodo, as well.

  VIRUS ANALYZERS.

  The problem that haunts security experts when they face a new, or modified
  virus, is that it usually takes days, sometimes weeks or even months, until
  antivirus developers have an algorithm available to restore systems from
  the new virus. We have seen instances when whole enterprises were halted
  for days because of attacks from new viruses.

  Generic methods have a lot to offer in such situations. First, generic
  recovery will allow return of systems to operational status in the shortest
  possible time. In most cases, programs can be completely restored using the
  integrity database without waiting for the disassembly and analysis of the
  virus. In the case of destructive, overwriting viruses, the integrity
  database can be used to identify which files need to be removed and
  replaced.

  The correlation scanner, a breakthrough in generic AV technology, can be
  used to spot infected files that were not found by the integrity analyzer
  and the source of the infection, too. Since an attacking virus can be of an
  unknown type, then no scanner will find it. The file that brought the
  infection into the system will not have a pre-infected, "clean" record in
  the database since it was already infected when the database for it was
  created. The correlation scanner will find the original infector, and other
  infected files, by similarity to an infected sample identified by an
  integrity analyzer, captured through a baiting process, or designated by
  the user. Correlation scanners have recently been enhanced so that a
  library of signatures can now be used with them, as well.

  The generic correlator identifies similarities in the processing that a
  file undergoes during infection (a virus infection is a 'process'), in the
  cryptographic model used in the virus code, and the matching of a signature
  string. The correlation scanner has proven itself effective with plain,
  encrypted, and even polymorphic viruses.

  The correlator may replace the scanner in many cases, and can be used to
  disinfect a computer, without needing updates, and with no delays. It is a
  tool that empowers users to restore their systems independently of
  antivirus security experts who may not always have the resources to respond
  quickly to user needs and requests.


  INTEGRATED ANTIVIRUS PROTECTION.

  Having reviewed the basics of generic antivirus technology, let's now
  discuss overall antivirus strategy. An effective antivirus defense should
  consist of several elements. Because of its broad effective spectrum,
  generic protection can and should have a pivotal role in any integrated AV
  defense strategy. It can capture a virus that passes through a known virus
  screening process and act as a buffer BEFORE loading an activity blocker or
  TSR scanner, if one is used.

  On-demand and TSR scanners can detect only viruses that are contained in
  their signature database. Often, this does not include all known viruses.
  Therefore, virus scanning should always be PRECEDED by running a generic
  probe and integrity analyzer, especially before scanning a file server.
  There is always the risk that a new fast infector, or even a known one not
  included or accurately detected, is active in memory. Signature scanning,
  without first performing a generic integrity analysis, can infect every
  executable inspected by the scanner.

  The backbone of an integrated antivirus strategy is the integrity analyzer.
  First, you need to run it regularly in order to keep its database up to
  date. Secondly, it's arguably the most effective means to detect an
  infection in its earliest stage. Thirdly, it will be the first to capture
  the presence of a fast infector BEFORE it can infect any significant number
  of programs, even if the virus is new. And lastly, it provides a very
  effective way to quickly and fully recover a system to its original,
  pre-infected condition, in the event of an infection.

  Virus scanners are a convenience, for scanning new software before
  installation, and for scanning floppies. They do offer some potential for
  detecting known viruses prior to executing their hosts. However, no scanner
  detects all known viruses and new viruses are produced daily, as well. And,
  it is very easy to mask existing viruses from detection so that even a
  comprehensive scanner will fail to detect them. These are significant
  practical limitations that preclude use of signature scanners as a primary
  method of AV security and defense.

  The core component of a comprehensive AV defense can be modeled upon the
  military equivalent of a "fail safe." A "fail safe" is a counter defensive
  process that will operate despite unknown and variable conditions and
  methods of attack.

  Generic methodologies best implement this concept as they function without
  regard to the specific details prevailing at the time of the viral attack,
  and use multiple, overlapping and partially redundant mechanisms for virus
  capture and, if needed, system recovery. Deliberate redundancy means that
  one or more of the generic methods will operate effectively despite
  variability in virus hosts or methods of viral action. In contrast,
  signature based antivirus can only handle known threats, contained in their
  database.

  Therefore, a more defensible AV strategy combines generic capture and
  restoration methods with known virus scanners. A cost effective benefit of
  this approach is that scanners will not need to be updated as frequently
  since the main purpose of updates is to detect new viruses. The generic
  methods can act as both a buffer and safety net to protect systems until
  preventative methods using scanners are possible. Since it can take
  anywhere from days to months for signature detection and cleaning
  algorithms to be made available, generic methods provide a highly
  significant "fail safe" to overall AV defense strategies. Even more
  importantly, advanced generic methods such as those presented, here, will
  provide both virus capture AND system restoration immediately.

  The use of antivirus TSR's and activity blockers is debatable. They always
  adversely and, at times, significantly impact system performance and
  available resources. They can also interfere with normal program operation,
  and conflict with other applications. Finally, they can be used as vectors
  to spread infection across all files scanned when either a known or new
  virus not detected is present. Yet there are users that won't give them up.
  Sometimes this decision is based on the mistaken assumption that TSR's
  provide protection beyond what is available from scanners. In fact, the
  latter are invariably more comprehensive and reliable than their respective
  TSR, from the same vendor.

  From a practical standpoint, when generic, TSR scanner, and activity
  blocking methods are used the latter two should be run AFTER completing the
  generic tests and integrity analyses. Generics and AV TSR's do not coexist
  well. The latter intercept generic probes as if they were viruses. This is
  especially true of activity blockers.

  After gaining some experience with the various elements of an integrated
  antivirus strategy, users will be better able to decide how important
  signature scanning, TSR's, and activity blockers are to a cost effective,
  and efficient AV defense. Past experience shows that users tend with time
  to rely on generic AV since it proves dependable, and is the least
  intrusive and obstructive to them. Users don't disable generic AV methods
  like they often do with TSR's and scanners. This is true even after long
  periods without viral incidents because the generic methods do not
  interfere with normal system operation, consume system resources, or
  negatively impact system speed and performance.

  When a virus does strike, then the generic AV will be in place to capture
  it, stop it, and restore the system to operational status quickly.


  Appendix B. - LAN Protection

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

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

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

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

  Virus Propagation in a Network.

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

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

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

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

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

  The lessons are:

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

  2. Virus scanning of file servers should be run sparingly and with utmost
     precautions. Since piggybacking cannot be sensed on file servers, then
     always run first generic probes to assure that the workstation you are
     working from is clean and the scanner is not being piggybacked by a
     virus. Scanners should always be tested first on a local hard disk
     (never from a floppy) to give a piggybacker the opportunity to disclose
     its own presence.

  Antivirus Protection in a Networked System.

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

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

                       # F:\PUBLIC\IV\IVLOGIN.EXE

  IVLOGIN will accept the following command arguments: If a random signature
  filename is desired, then add /RANDOM after the IVLOGIN filename. If a
  specific signature filename is preferred then add SIG=MY_NAME. No spaces
  are allowed in the SIG= argument.

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

                           C:\IV\IVB F: DAILY

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

  Cleaning a File Server from a Virus Attack.

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

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

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

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

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

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

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

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

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


  Appendix C. - Large Capacity IDE.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


  Appendix D. - IVX Advanced Options.

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

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

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

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

  -  As a scanner, from a signatures library.

  -  For searching a text string in files.

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

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

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

  Extracting signatures.

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

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

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

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

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

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

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

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

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

  Using the Signature mode.

  User defined signatures can be entered in three different ways:

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

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

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

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

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

  Using IVX for virus alert.

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

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

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


  Appendix E. - Switches and Command Line Options.

  The following are a list of the switches and command line options available
  in the InVircible modules.

  INSTALL.

     /FAST    Upgrade an existing installation or install with the default
              parameters. The installation is automatic, no prompting is
              available and the registration key will not be installed to the
              hard disk.

         /R   Prepare an IV rescue diskette.

  IVMENU.

   [drive:]   Load directory of the specified drive.

         /V   Start IVMENU in virus scanner mode.

         /R   Start IVMENU in ResQdisk mode.

         /0   Start IVMENU at zero level (all sub-menus closed).

  IVINIT.

    /NOCMOS   Skip CMOS data comparison, recommended for notebooks and
              laptops. Also use on computers that use the CMOS for power
              saving ("Green") data.

  IVTEST.

         /Q   Quiet mode. Do not display to screen, except when virus
              activity was found.

  IVLOGIN.

    /RANDOM   Install with random signature file name.

   SIG=name   Install with specified signatures' file name.

  IVB.

      DAILY   Run complete daily inspection of all local drives and
              directories.

     WEEKLY   Same as DAILY, but weekly.

    /NOSTOP   Do not stop for prompting the user. For unattended systems.

       /ESC   Enables escaping the daily check, in Sentry mode.

     /NOMEM   Skip brief memory check.

         /S   Secure all executable files, overwrites existing signatures.

         /R   Restore modified files.

         /D   Restore modified and recoverable files, delete modified and
              unrecoverable ones.

         /V   Remove current signature files.

    /X name   Overrides current signature filename, use "name" as signature
              filename.

          -   Operate on specified directory only, do not continue to sub
              directories.

  IVSCAN.

         /R   Remove virus from infected file, if algorithm exists in IVSCAN.

         /D   Remove virus if possible, delete file if no removal algorithm
              exists in IVSCAN.

         /B   Inspect floppy boot sector, force boot sector replacement, if
              no original sector found.

        /EX   Scan only files with executable extension filenames.

          -   Operate only on specified directory, do not continue to sub
              directories.

  IVX.

       arg1   First argument after program name: Pathname of file to use as
              sample. Wildcards are allowed.

       arg2   Second argument: Path where to start scanning.

       arg3   Third argument: Number of bytes past the entry point, where to
              look for a signature string.

  RESQDISK.

         /B   Backup the mbr, boot sector and CMOS data.

         /R   Restore the mbr, boot sector and CMOS data from image. Prompt
              before writing data to CMOS.

         /Z   Track zero functions. Use with /B or /R, above.

         /2   Operate on disk # 2. Use with all switches above.

        /DM   Boot sector of Disk Manager partition. Use with /B, /R and /2,
              above.

  FIXBOOT.

       /IBM   Force a PC-DOS type boot sector instead of the MS-DOS one.

         /S   Prompt for a floppy size (360, 720, 1.2, 1.44, 2.88) and force
              a boot sector of the selected size.


  Appendix F. - Glossary

   Piggybacking: Technique used by a fast infecting virus. The virus installs
   a memory resident handler that monitors DOS for 'open', 'close', 'find-
   -first' and 'find-next' calls and hooks its infection routine to the
   captured handler.

   Retro-piggybacking: A disinfection technique used by InVircible,
   taking advantage of piggybacking to clean after the virus.

   Tunneling: A method to bypass 'underneath' a BIOS or DOS service.

   SeeThru: A tunneling technique used by InVircible to 'tunnel' under
   interrupt 13h, used for absolute disk read/write, to thwart int 13h
   stealth.
