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