home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Shareware 1 2 the Maxx
/
sw_1.zip
/
sw_1
/
VIRUS
/
9DS210T.ZIP
/
VDS.TXT
< prev
next >
Wrap
Text File
|
1992-07-11
|
153KB
|
2,843 lines
V
D
S
VIRUS DETECTION SYSTEM
version 2.10
Copyright (c) 1992 by VDS Advanced Research Group
All Rights Reserved
July 1992
Baltimore, MD, U.S.A.
WARNING
THIS SOFTWARE AND MANUAL ARE BOTH PROTECTED BY U.S.
COPYRIGHT LAW (TITLE 17 UNITED STATES CODE). UNAUTHORIZED
REPRODUCTION AND/OR SALES MAY RESULT IN IMPRISONMENT OF UP
TO ONE YEAR AND FINES OF UP TO $10,000 (17 USC 506).
COPYRIGHT INFRINGERS MAY ALSO BE SUBJECT TO CIVIL LIABILITY.
DISCLAIMER
The developers of VDS make no warranty of any kind,
either express or implied, with respect to this software and
accompanying documentation. In no event shall the developers
be liable for any damages arising out of the use of or
inability to use the included programs. The entire risk as to
the results and performance of this software package is
assumed by the customer. We specifically disclaim any implied
warranties of merchantability or fitness for any purpose. Use
at your own risk.
The developers of VDS reserve the right to revise the
software and accompanying documentation and to make changes in
the contents without obligation to notify any person of such
revision or changes.
TRIAL VERSION
You are hereby granted permission to use this software
package on any computer you own personally. Use of the trial
version of VDS in a business/academic/government environment
is not permitted. You must obtain the appropriate registered
version for that purpose. Failure to do so is considered a
violation of the Copyright Law and is subject to legal action.
Certain features of VDS are not implemented in the trial
version. Please refer to the REGISTRATION and PRICES section
of this documentation for details.
TABLE OF CONTENTS
I. INTRODUCTION. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
A. Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
B. What is VDS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
C. Why VDS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
D. Where is VDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
E. Deficiencies in other products . . . . . . . . . . . . . . . . . . . . 3
F. Do you need anti-viral programs. . . . . . . . . . . . . . . . . . . . 5
1. VDS Risk Factor Analysis Test. . . . . . . . . . . . . . . . . . 7
II. SYSTEM REQUIREMENTS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
A. Hardware & Software. . . . . . . . . . . . . . . . . . . . . . . . . . 10
B. Which files are processed. . . . . . . . . . . . . . . . . . . . . . . 10
III. INSTALLATION. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
A. Files on VDS distribution diskette . . . . . . . . . . . . . . . . . . 11
B. Installing VDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
C. Backing up the VDS distribution diskette . . . . . . . . . . . . . . . 12
D. Preparing the VDS emergency diskette . . . . . . . . . . . . . . . . . 13
E. Installing VDS on a hard drive . . . . . . . . . . . . . . . . . . . . 15
IV. OPERATION of VDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
A. Operational Cycle. . . . . . . . . . . . . . . . . . . . . . . . . . . 18
B. How does VDS work. . . . . . . . . . . . . . . . . . . . . . . . . . . 19
C. VDS Device Driver. . . . . . . . . . . . . . . . . . . . . . . . . . . 21
D. VDSFSCAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
E. Scenarios and Messages . . . . . . . . . . . . . . . . . . . . . . . . 28
F. Command Line Options/Flags . . . . . . . . . . . . . . . . . . . . . . 32
G. Common Questions and Answers . . . . . . . . . . . . . . . . . . . . . 33
V. VIRUS ATTACK METHODS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
A. Virus defined. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
B. Attack & spread methods. . . . . . . . . . . . . . . . . . . . . . . . 43
VI. PARTITION/BOOT SECTOR INFECTIONS . . . . . . . . . . . . . . . . . . . . . . 47
A. Preliminary information. . . . . . . . . . . . . . . . . . . . . . . . 47
B. How to recover with CURE option. . . . . . . . . . . . . . . . . . . . 50
C. How to use VITALFIX. . . . . . . . . . . . . . . . . . . . . . . . . . 50
VII. HOW TO DEAL WITH VIRUSES. . . . . . . . . . . . . . . . . . . . . . . . . . 52
A. Recommended Guidelines . . . . . . . . . . . . . . . . . . . . . . . . 52
B. Manual Recovery Procedure. . . . . . . . . . . . . . . . . . . . . . . 54
VIII. REGISTRATION and PRICES . . . . . . . . . . . . . . . . . . . . . . . . . 58
A. How to get VDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
B. Trial version. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
C. Complimentary version. . . . . . . . . . . . . . . . . . . . . . . . . 59
D. Personal version . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
E. Academic version . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
F. Non-profit & charity version . . . . . . . . . . . . . . . . . . . . . 59
G. Business version . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
IX. TECHNICAL SUPPORT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
A. How to contact the developers. . . . . . . . . . . . . . . . . . . . . 61
B. How to get VDS on the Internet . . . . . . . . . . . . . . . . . . . . 62
C. Upgrades & bug fixes . . . . . . . . . . . . . . . . . . . . . . . . . 62
I. INTRODUCTION
A. Background
Even though computer viruses are not unique to personal
computers, lack of built-in hardware control mechanisms and
secure operating systems make PCs more vulnerable than other
computers. In addition, the tremendous amount of software
exchange among users contributes to the proliferation of
viruses.
While anti-viral products are also increasing in number,
the PC world has yet to see a comprehensive solution based on
a scientific analysis and sophisticated techniques. A common
feature shared by these anti-viral programs is their pattern
searching approach. They simply look for a sequence of
identifying bytes (not necessarily consecutive) inside the
existing executable code such as program files and boot
sector. This is a very attractive idea from a business
standpoint, but it is neither a comprehensive nor a viable
solution.
If the focus had been on analyzing viral behavior rather
than pattern matching and keeping the market alive through
forcing users to upgrade frequently, computer viruses may have
been less of a threat than they certainly are today. Some
software companies jump on the bandwagon, and using their good
reputation for other products they developed previously, cheat
the user community with false promises to put an end to the
virus problem. Although their efforts to provide a partial
solution are recognized, they have the capacity to produce
better quality products that can eradicate most possible
viruses.
VDS (Virus Detection System) was developed in reaction to
the limitations of existing anti-viral programs. Due to the
large number of ways that viruses can exploit the DOS
environment, the anti-viral methods employed in practice are
often ad hoc and cannot easily be formalized. VDS makes a
judicious choice of systematic approaches to the detection of
viruses.
A general virus detector is not theoretically possible. By
the same token, a general virus that can evade all detection
attempts is not possible given the same limitations of the
target system. VDS attempts to prove this second point for one
specific operating environment, the venerable DOS.
B. What is VDS?
VDS is a set of programs designed to contain the spread of
computer viruses that target PCs running MS/PC DOS 3.0 or
above by providing early detection and quick recovery. The
operation of VDS is similar to that of an integrity shell in
that it is NOT virus-specific. The current implementation,
however, is not a shell that verifies programs before they are
run. Instead, VDS does a thorough check of the system every
time the PC is started and notifies the user of any suspicious
modifications detected. Please make no mistake, VDS is not
just another modification detector or virus scanner.
C. Why VDS?
- It is NOT virus-specific
- It does NOT need frequent upgrades
- It does NOT require much user expertise
- It is NOT a TSR with possible conflicts
- It works even when a stealth virus is ACTIVE in memory
- It can handle any size DOS disk
- It is compatible with DOS 3.0 and above
- It supports MS Windows 3.0 & 3.1
- It works on DR DOS 6.0 systems (non-compressed only)
- It can CAPTURE some memory-resident viruses to speed up
diagnosis
- It can recover a damaged partition table easily
- It can fix an infected boot sector on the fly
- It is blazingly FAST
- It includes an automated boot sector recovery tool
- It comes with a fast, easy-to-use scanner that can work on
network drives
- It is CHEAP
- It can usually HEAL itself even when infected
- It automatically updates the baseline database after
additions/deletions
- It can identify many common viruses
D. Where is VDS?
A copy of VDS that performs an integrity check of the
system areas such as the partition and the boot sector, and
potentially executable files on hard disks can be ordered from
the developers by U.S. mail or by phone. Please refer to the
REGISTRATION and PRICES section of this documentation for
details.
VDS is the outcome of an independent research project
concerning computer viruses and defense mechanisms. It uses
sophisticated techniques to detect most possible viruses in
the DOS environment. It has proved to be effective against all
current and simulated viruses. It does not suffer from the
limitations of most commercially available anti-viral software
packages. These limitations will be discussed in the next
section.
If you are faced with the problem of recurring virus
infections, or have data that just cannot be replaced without
significant loss, you are invited to try VDS on your system.
With VDS in place, viruses cease to be an impediment to
productivity. Beta-test version of VDS has been installed at
a site which has a Novell Netware local area network. Within
three weeks of installation, all attacks by Stoned, Jerusalem,
and 4096 viruses were effectively caught and eliminated. The
test site now enjoys an increased sense of security. What's
more the computer services personnel and the end-users do not
have to waste any resources just to deal with viruses. We have
found VDS to be especially effective against Stoned, Dark
Avenger, Jerusalem, and 4096 viruses during our tests.
E. Deficiencies in other products
This section is intended to be humorous as well as
informative. Sensitive individuals should skip this section.
These days, there are more anti-viral software packages in
the market than common viruses! Nearly everyone who has
access to a few viruses comes up with his own virus scanner
with the claim of breaking all speed records set by the
competition. One such product is so blindingly fast that it
cannot see even the viruses it has scan strings for!
Similarly, some product reviewers get their stopwatches and
virus samples ready and babble the same old rhetoric about the
numerous (but irrelevant) features of these anti-viral
programs. This situation hurts the end-users in a non-obvious
way: it adds to the existing confusion about what the problem
is and what a good solution should entail. Other self-
described experts contribute to the mass confusion by throwing
in their share of advice about what to do. There is at least
one piece of advice in a published paper stating that the
computer should be left powered on until top management is
notified, as if top management would be delighted to see the
"F... You Lamer" message the virus is flashing on the screen!
What if you have the sales figures for the past six months on
the hard disk and the virus wants to low level format it? Let
us make it clear, however, that there are some very
experienced and knowledgeable experts in this field, and they
deserve credit. Our criticism applies only to those who are
better off saying nothing.
Why all this confusion? Is it because the virus problem is
getting out of hand, or is it because most anti-viral programs
lack the sophistication to deal with new viruses? No one
denies that the number of viruses is growing day by day. Some
of them are hacked versions of older viruses, others are new
creations of sick minds, and still others are products of
irresponsible (to say the least) so-called researchers.
There are more than 1000 computer viruses that target PCs
as of this writing. This number might double in a year or two.
Anti-viral software companies are hard at work trying to keep
up with the new strains. They categorize the samples they can
obtain, extract patterns to be able to identify them, and
upgrade their programs to stay competitive with the rest.
Meanwhile, the end-users are forced to pay more to renew their
site licenses or to upgrade to the latest version.
Anti-viral software products fall into two categories:
- DUMB anti-virals
- SMART anti-virals
By mere coincidence, viruses also fall into two categories:
- DUMB viruses
- STEALTH viruses
Even end-users fall into two categories:
- Those who can be easily fooled
- Those who cannot be easily fooled
As logic dictates, a DUMB anti-viral product can be
expected to deal with only the DUMB viruses in an effective
manner. Only the SMART anti-virals can be effective against
both DUMB and STEALTH viruses. End-users who can be fooled
easily fall prey to marketing hypes and invest in DUMB anti-
virals and will go have a good night's sleep with the illusion
that their computer is safe. One day, a STEALTH beast on the
prowl hits their systems. Days pass by, even weeks pass by.
The virus spreads to other computers. One day, something
strange happens and someone notices an abnormality. First
everyone panics a little, then a confident end-user declares
that he has this great anti-viral program from QuackCom Inc.
to take care of the intruder. He goes out to exterminate the
virus.
Not only the anti-viral cannot find anything wrong, the
virus spreads even more as he checks the computers. You can
hope that this is just another horror story that cannot happen
to you (or to us). For those of us who do not want to take a
chance, only a SMART anti-viral will do. We cannot settle for
less, neither should you. Being fooled once does not make
anyone a fool, but insisting on foolishness leaves doubt in
everyone's mind.
In this document, we present various aspects of anti-viral
products as well as viruses. You should be able to get an idea
about what makes a virus STEALTH and what makes an anti-viral
DUMB or SMART. Equipped with this knowledge and UNwillingness
to pay big prices, you can go out to find an anti-viral
program that will give you a reasonable amount of assurance.
By the way, you do NOT need a stopwatch, only some anti-viral
product reviewers must have one!
Following is an overview of some deficiencies noted in
today's other antiviral products:
- They are virus-specific. They can detect only the known
strains. Some of them are slightly better since they
provide an external mechanism for end-users to add new
patterns to search for. However, this still relies on the
availability of a unique pattern that can be used to detect
a specific virus. Many polymorphic viruses require other
solutions, and cannot be dealt with by adding new
signatures.
- They are slow. It is neither practical nor acceptable to
have a program to do pattern matching all over a large disk
with lots of executable files on a regular basis. As the
number of viruses continue to grow (more than 1000 as of
this writing), these programs will get even slower (except
the ones that "cut corners").
- They are vulnerable to "stealth" viruses that mask
infections. Most of them can even contribute to the spread
of these types of viruses while not even being able to
detect them! This "cure-worse-than-the-disease" syndrome
was not apparent until the onslaught of stealth viruses.
- They are expensive. Many sell for more than $100. Others
charge ridiculous site licensing fees.
- They need upgrades almost on a monthly basis. This sure
keeps the business alive! The end-user is forced to pay
more money while still not having enough guarantee that his
system is not at risk.
- They conflict with some application programs. Some are
RAM-resident, not only causing conflicts but also taking up
a chunk of precious 640K. Others modify programs to add
self-checking code (known as immunization). Ironically,
this is also vulnerable to stealth viruses, and can even
cripple some programs.
- They rely directly on DOS during verification. Since DOS
does not claim to provide a virus-resistant environment,
these anti-viral products are destined to be defeated
sooner or later.
F. Do you need anti-viral programs?
Unfortunately, the answer is a resounding YES. It is just
too much of a gamble not to have one in place these days. The
question then becomes "how much protection against viruses do
you need?". There is no simple answer. If you look at the
capabilities of numerous anti-viral packages in the market,
you will get an idea of what is available. You can then
consider your risk factor and make a decision.
There are a variety of techniques used by anti-viral
programs. Some of them are so paranoid (you would think their
developers should seek professional assistance!!!) that they
interfere with your regular work by issuing too many
unwarranted alarms. The more serious problem is that the users
become desensitized very quickly and tend to ignore all the
warnings. The end result is a high-tech version of the old
"cry wolf" story.
Technically, there are some other problems associated with
these products. Their reliance on interrupt monitoring (for
the most part) opens the door for the next virus that uses a
direct jump to easily bypass them. You are better off not
investing in such a product. Their false claims to stop
viruses is as effective as preventing the common flu during
winter.
At the other end of the scale, you have products that are
so pessimistic they claim it is impossible to provide enough
protection after DOS is loaded. They either encrypt everything
on the hard disk so that it can be accessed only by using
their program, or they replace the master partition sector and
again supervise all access. One such program claims to be
unobtrusive, and then goes ahead to replace your master
partition sector! Some kind of solution. Alas, there is no
law against distributing weekend hacks to the public.
Another one comes with a card that must be plugged into a
slot on the system bus. Not only this product is expensive, it
has questionable effects on system performance. Suppose your
company owns 800 computers, and suppose they all have an empty
slot to plug this card in without any conflicts with the other
adapters already installed. Someone has to go around and open
up each machine to install the card. Can you imagine the
trouble you can get in if these guys decide to upgrade the
card next month! With software-based anti-virus programs, you
can at least just copy the new version to your hard disk every
month. Stay a good distance away from these products for your
own good. They claim to send a bolt of lightning from above
and punish all viruses; please beware, because your wallet
might be the only thing that gets struck!
The most common variety is called a virus scanner. Their
operation is based on the assumption that a unique sequence of
bytes (not necessarily consecutive) extracted from the viral
code will be present in all infected files. They simply search
for this pattern and tell you if the file contains that
pattern, indicating possible infection. It is sad that these
products, which do a good service, give the user a false sense
of security. What if your system is attacked by a new virus?
What if the virus is smart enough to evade this kind of
detection? These products make sense only as part of a
stronger and more comprehensive package such as VDS. The only
other feasible use for these products is to look for known
viruses on floppy diskettes.
Many people believe that the biggest shortcoming of virus
scanners is that they may cause false alarms since the same
string used to identify a virus can be present in a clean
program file. Although there is a chance that this may happen,
it is a rare occurrence. The biggest problem with the virus
scanners is their inability to detect new viruses.
Another type of anti-viral product checks for modifications
to the files and the system areas. These products usually
compute some kind of checksum value to recognize any changes.
They certainly have a chance to catch new viruses. The problem
is that the more advanced viruses cannot be detected easily.
These viruses are capable of masking any modifications they
make. There are some poor implementations of change detection
approach. One such program sold by a company, which also
developed a respectable disk utility in the past, is one of
the worst implementations we have encountered. Very
disappointing!
Please do not confuse VDS with these change detection
programs. VDS uses a proprietary triple-pass verification
technique that is not specific to the DOS environment. Let us
just say that VDS is superior by design as well as
implementation. Do not take our word for it; find out for
yourself by calling (410) 247-7117 and ordering a copy of VDS
now!
1. VDS Risk Factor Analysis Test
Following test is intended to serve as a simple tool to
evaluate the vulnerability of your computer(s). It is not a
comprehensive risk indicator; however, it covers the most
basic and often neglected areas. The test is not associated
with the VDS package, although the interpretation section is.
Remember that if your score lands in category 3 or 4, anything
less than a comprehensive anti-viral measure will not be
effective in the long run.
Q-1) How many different viruses attacked your computer(s) over
the past two years?
A) None B) 1 or more
Q-2) If your answer to question #1 was B (1 or more), did you
install an anti-viral program to protect your computer?
A) Yes B) No
Q-3) How many times did you have to deal with non-virus-
related conflicts between programs?
A) None B) 1 or more
Q-4) Is all your valuable data backed up on at least two sets
of storage media?
A) Yes B) No
Q-5) Have you backed up your data within the last month and
verified that you can actually restore it?
A) Yes B) No
Q-6) Are all your original program diskettes write-protected?
A) Yes B) No
Q-7) Do you have a copy of your master boot record (or just
the partition table) copied either on a floppy diskette
or printed?
A) Yes B) No
Q-8) Do you frequently play games that you borrowed from your
friends on your computer?
A) No B) Yes
Q-9) Do other people (including PC technicians) use your
computer sometimes?
A) No B) Yes
Q-10) Do you add/install new programs on your hard disk more
than once a month?
A) No B) Yes
Score Scale
Q-1) A : 0 B: 10
Q-2) A : -9 B: 0
Q-3) A : 0 B: 2
Q-4) A : 0 B: 5
Q-5) A : 0 B: 2
Q-6) A : 0 B: 5
Q-7) A : 0 B: 2
Q-8) A : 0 B: 5
Q-9) A : 0 B: 10
Q-10) A : 0 B: 10
1) Very Low Risk : 0 - 5
2) Low Risk : 6 - 10
3) High Risk : 11 - 25
4) Very High Risk : 26 and above
Interpretation
If your score falls in category:
1) Little reason to worry about viruses. Anti-viral programs
are optional for you.
2) Your computing habits will probably isolate your computer
from getting infected. A periodic usage of an anti-viral
program is advisable.
3) There is a good chance you will experience a viral attack
if it has not already happened. VDS can help you reduce
your risk factor significantly.
4) You should not only install VDS on your system but also
re-evaluate your computing habits. You are walking on
thin ice!
II. SYSTEM REQUIREMENTS
A. Hardware & Software
- MS/PC-DOS 3.0 or higher
- Hard disk (not compressed or encrypted)
- 384K available memory (more if many executable files)
- 500K free space on C drive
- Less than 1500 executable files per partition
- Must be installed and run from C:\VDS210 directory
- Largest file processed is 2M bytes
B. Which files are processed
VDS considers any file with one of the following extensions as
executable, and therefore a potential carrier of viral code:
COM, EXE, SYS, OV?, APP, BGI, XTP, BIN, DLL, NLM, LAN, CMD,
LIB, DDR
There may be other extensions (in fact, the extension of a file is
irrelevant to DOS LOAD/EXEC routine), but these are the most
common ones.
III. INSTALLATION
A. Files on VDS distribution diskette
VDS distribution diskette contains the following files:
VDS.EXE This is the VDS program file used for
installation and integrity checking.
WARNING.TXT Information on incompatibilities with certain
systems.
INSTALL.TXT Steps to install VDS on a hard disk.
HILITES.TXT List of key features of VDS and other
information.
ORDERFRM.TXT Order form you can mail in to get a registered
copy of VDS.
WHATSNEW.TXT List of enhancements and bug fixes since
previous release of VDS.
VDS.TXT This is the technical documentation for VDS
VITALFIX.EXE This is an automated recovery utility to be
used in the case of MBR or floppy BR
infections.
VDSFSCAN.EXE This is a virus identification program that
can be used to scan floppy diskettes and
network drives.
*Boot Sector This is not a file, but our special boot
sector placed on the distribution diskettes
and used during installation. To make a backup
of VDS distribution diskette, you need to use
DISKCOPY not just COPY so that the special
boot sector is copied over as well.
*VDSDEV.DDR The customized device driver to do extra
checks on system areas; very effective against
MBR/BR viruses.
* Available only in the registered versions of VDS, not
trial version.
Note: During installation a customized device driver will
be created. This device driver is not on the
distribution diskette. It will be automatically
generated by the VDS installation routine. Trial
version does not have this feature. The purpose of
this device driver is to provide another layer of
integrity checks on system areas such as the master
boot record and the command interpreter. NEVER
ATTEMPT TO RUN THE GENERATED DEVICE DRIVER ON A
DIFFERENT COMPUTER; IT MAY CAUSE DAMAGE TO YOUR
MASTER BOOT RECORD IN SOME CASES.
B. Installing VDS
There are three simple steps to install VDS:
1. Make a backup of the VDS distribution diskette
2. Prepare an emergency diskette
3. Install VDS on the hard disk
The emergency diskette will be used in the case of infections
that affect the master boot/partition sector or MBR (if VDS cannot
repair it on the fly). The floppy restoration process requires you
to use this VDS emergency diskette. If you think you can afford
taking a chance on losing your partition table, which may be
acceptable in a lab environment where the hard drives hold only
programs not data, step 1 can be omitted. Individuals who keep
their data on their hard drives are encouraged to go through step
1, the preparation of an emergency diskette. This two-minute
procedure can save you much agony if one day the partition table is
wiped out either by accident or by a malicious virus.
Note that the installation on the hard disk expects you to
boot the computer from a floppy diskette. VDS will search the hard
disk for known viruses during installation. Booting from a floppy
diskette is necessary to ensure that there are no memory-resident
viruses present. Also, make sure that the version of DOS on the
system floppy diskette is the same as the one installed on your
hard drive.
WARNING: IT IS EXTREMELY IMPORTANT THAT YOU DO NOT RUN ANY
PROGRAMS OFF OF THE HARD DISK DURING INSTALLATION.
VDS will not modify your AUTOEXEC.BAT or CONFIG.SYS without
your approval. Remember, however, the VDS device driver and program
should be run as early as possible. They should not cause any
conflicts since neither of them are memory-resident. The device
driver releases its memory after initialization.
STEP 1: C. Backing up the VDS distribution diskette
- Turn the computer OFF.
*** It is very important that you do NOT perform a
warmboot by holding down Ctrl-Alt-Del keys. It is
possible for a virus to "fake" a warmboot while it
stays in memory.
- Place a write-protected, clean (preferably original) MS/PC-
DOS system diskette in drive A: and close the drive door.
- Turn the computer ON.
*** Some computers can boot from the hard disk even
when there is a floppy diskette in drive A: and the
door is closed. For example, some Zenith computers
let you specify the default boot drive and save
that information in CMOS configuration. If you have
one of these computers, you need to modify the
setup so that the computer can be booted from a
floppy diskette in A: drive. After installation,
you can set it back to boot from the hard drive.
- After the computer boots up, use DISKCOPY command to make
an image copy of the VDS distribution diskette. Simply
copying the files is not enough. The distribution diskette
contains a special boot sector that is needed during
installation. TRIAL version of VDS does not require a
special boot sector and can be backed up using the COPY
command. If you have two identical floppy drives, place the
original distribution diskette in drive A: and a blank
diskette in drive B:, and type the following command:
A:\>DISKCOPY A: B: <enter>
*** If your computer has only one floppy diskette drive
or one of them is 5.25" and the other one is 3.5",
you need to use the same drive to make a backup.
Simply insert the correct diskette when prompted.
DISKCOPY refers to the original diskette (VDS
distribution diskette in this case) as the SOURCE
diskette, and the backup one as the DESTINATION
diskette. If you receive a "Bad command or file
name" message, that means the DOS diskette in A:
drive does not have DISKCOPY program on it. You
need to put the DOS diskette with the DISKCOPY
program in A: drive before you issue the command
shown above.
- Store away the original VDS distribution diskette, and
label the backup copy VDS distribution diskette. Place a
write-protect tab on the backup diskette. From now on,
whenever we refer to the VDS distribution diskette, it
means the backup VDS distribution diskette you have just
prepared.
STEP 2: D. Preparing the VDS emergency diskette
- Turn the computer OFF.
- Place a write-protected, clean (preferably original) system
diskette in drive A: and close the drive door.
- Turn the computer ON.
*** Some computers can boot from the hard disk even
when there is a floppy diskette in drive A: and the
door is closed. For example, some Zenith computers
let you specify the default boot drive and save
that information in CMOS configuration. If you have
one of these computers, you need to modify the
setup so that the computer can be booted from a
floppy diskette in A: drive. After installation,
you can set it back to boot from the hard drive.
- After the computer boots up, format a blank floppy diskette
with /S option to make it bootable. The command to do this
is:
A:> FORMAT B: /S <enter> or
A:> FORMAT A: /S <enter> if the diskette
drives are of
different size.
- Copy SYS.COM from the original system diskette onto this
diskette.
- Copy CHKDSK.EXE from the original system diskette onto this
diskette.
- Copy VDS.EXE from the VDS distribution diskette onto this
diskette.
- Copy VITALFIX.EXE from the VDS distribution diskette onto
this diskette.
- Copy VDSFSCAN.EXE from the VDS distribution diskette onto
this diskette.
- Copy REPAIR.BAT from the VDS distribution diskette onto
this diskette.
* Copy any device drivers you need to access the hard drive
onto the VDS emergency diskette. Most people can skip
this.
* Create a simple CONFIG.SYS file on the floppy disk
activating the device drivers above. Make sure you
activate the copy of the driver you placed onto the
floppy, not the one on the hard disk!
- Label it VDS emergency. Do NOT write-protect it yet.
- Continue with step 3.
STEP 3: E. Installing VDS on a hard drive
- Turn the computer OFF.
*** It is very important that you do not perform a
warmboot by holding down Ctrl-Alt-Del keys. It is
possible for a virus to "fake" a warmboot while it
stays in memory.
- If you are installing a registered copy of VDS, place the
backup VDS distribution diskette in drive A:. If you are
installing a TRIAL copy of VDS, then put a MS/PC-DOS system
diskette in drive A:.
- Turn the computer ON.
- VDS distribution diskette contains a special boot sector
that initializes the system for installation. After the
system is ready, it will ask you to remove the distribution
diskette and to put a DOS system diskette in drive A:, and
to press a key to reboot. You should NOT turn off the
computer at this time. If you do not follow this procedure,
VDS will refuse to install.
- When asked, place a write-protected, clean (preferably
original) system diskette in drive A: and close the drive
door.
- Press a key to reboot.
*** Some computers can boot from the hard disk even
when there is a floppy diskette in drive A: and the
door is closed. For example, some Zenith computers
let you specify the default boot drive and save
that information in CMOS. If you have one of these
computers, you need to modify the setup so that the
computer can be booted from a floppy diskette in A:
drive. After installation, you can set it back to
boot from the hard drive.
- Run CHKDSK on every drive where you will install VDS to
make sure the files are not corrupted. If they are, correct
the discrepancies by running CHKDSK with the /F option.
A:> CHKDSK C: <enter>
- Place VDS distribution diskette in drive A:
- At the DOS prompt, type the following:
A:\INSTALL <enter>
*** <enter> means that you should press the ENTER key.
- VDS will authenticate itself to make sure it is not a
modified copy. You will then see the list of files and
directories scroll by as VDS is scanning for infections and
creating the baseline profile of all executable files on
the disk. There should be lots of disk activity. You can
actually observe this by looking at the drive light, or you
should at least hear the disk head move around. If VDS
finds that there are infected files, you will be asked if
VDS should remove them. If there are any infected files
left on the disk, VDS will abort installation and warn you.
A list of all infected files and the viruses detected will
be placed in C:\VDS-STAT.LOG. If all goes well, VDS will
copy itself onto the hard disk in C:\VDS210 directory.
- VDS will ask you if you would like to create a backup copy
of your system areas on the emergency diskette. Answer
affirmative by pressing the 'Y' key.
- At the end of the installation, registered versions of VDS
will generate a customized device driver for your computer.
VDS will give you an opportunity to customize the device
driver to your liking. Specifically, you will be prompted
to add an optional message that will be embedded within the
device driver. This message will be displayed if the system
areas fail integrity checks. You will also have a chance to
choose whether you would like to have the VDS device driver
to halt the system in the case of an emergency. We
especially encourage businesses to include a message such
as "Call System Administrator x5112 ASAP!", as well as to
turn on the halt option so that the incident gets reported.
- If this is the first time you are installing VDS on your
computer, it will ask you if you would like to have VDS
modify your AUTOEXEC.BAT and CONFIG.SYS to add the
necessary lines to load VDSDEV.DDR and run VDS.EXE every
time you reboot the computer. These lines will be added
only if you approve it; otherwise, you need to add them
yourself using a text editor. The original CONFIG.SYS file
will be copied to CONFIG.VDS, and the original AUTOEXEC.BAT
file will be copied to AUTOEXEC.VDS. You can write-protect
the emergency diskette at this time and store it in a
convenient location. When VDS informs you that the computer
will restart, please remove floppy diskettes immediately.
VDS will reboot the computer as soon as you press a key.
* If you choose not to have VDS modify your AUTOEXEC.BAT,
you should place the following line in your AUTOEXEC.BAT
as the first line.
C:\VDS210\VDS.EXE -Verify
*** VDS should be run from C:\VDS210 directory as
shown above. Do not rename VDS.EXE. VDS will
not run if it detects otherwise.
* If you choose not to have VDS modify your CONFIG.SYS, you
should place the following line in your CONFIG.SYS as the
first line.
DEVICE = C:\VDS210\VDSDEV.DDR
*** VDSDEV.DDR should be loaded from C:\VDS210
directory as shown above. Do not rename
VDSDEV.DDR. It will not function properly if
it detects otherwise.
- The computer should boot from the hard disk. If VDS is
installed correctly, you will see it verify the complete
system and tell you what it is doing at every step.
IV. OPERATION of VDS
A. Operational Cycle
After VDS has been installed on a known-to-be-clean system, a
complete verification of the hard disk is done each time the
machine is started. For best results, VDS should be run from the
AUTOEXEC.BAT. It can also be run, just like any other program, at
the user's discretion, although some TSRs loaded afterwards may get
deactivated by VDS. The following chart illustrates the operational
cycle on a computer protected by VDS:
┌───────────────────┐
│ virus-free system │
└──────────┬────────┘
│
┌──────────┴────────┐
│ VDS installation │ baseline established
└──────────┬────────┘
┌───────────────┤
│ ┌──────────┴────────┐
│ │ reboot │
│ └──────────┬────────┘
│ │
│ ┌──────────┴────────┐ ┌──────────────────────┐
│ │ before DOS is ├───┤ MBR/BR virus attack │
│ │ loaded │ └──────────────────────┘
│ └──────────┬────────┘
│ │
│ ┌──────────┴────────┐ ┌──────────────────────┐
│ │ DOS loads VDSDEV ├───┤ detection/restoration│
│ │ │ └──────────────────────┘
│ └──────────┬────────┘
│ │
│ ┌──────────┴────────┐
│ │ VDS verifies │ ┌───────────────────────┐
│ │ the system ├───┤ detection/restoration │
│ │ │ └───────────────────────┘
│ └──────────┬────────┘
│ │ passed / baseline updated
│ ┌──────────┴────────┐
│ │ │ ┌───────────────────────┐
│ │ regular use ├───┤ virus introduced │
│ │ │ └───────────────────────┘
│ └──────────┬────────┘
│ │
└───────────────┘
Note that from the point the virus enters the system until the
next time the system is checked again, there is a possibility for
damage. In every open system where introduction of viruses cannot
be prevented, this security hole exists. Even if there is a BIOS-
level, hardware-based integrity checking system in place, the virus
still has the opportunity to do damage during regular use. However,
the spread of viruses can be effectively contained and losses can
be minimized. If a mechanism such as VDS is used, viruses are no
more of a threat than an unexpected hardware failure, for which the
best known cure is frequent backups. The problem intensifies
because of the uncontrolled spread, not because all viruses are
extremely destructive.
B. How does VDS work?
This section omits many details about the operation of VDS on
purpose. The reader might get the idea that VDS is just
another change detector. Rest assured that it is much stronger
than any other software solution and more elegant than any
hardware solution available. We believe that not disclosing
certain information is in the best interest of the users. We
realize that this approach will not stop a determined hacker
from figuring out the details about the operation of VDS;
however, it certainly will not help him either.
The first time VDS is installed, a baseline for all executable
files and the system areas such as the master partition and the
boot sector is established. A sophisticated technique based on a
cryptographic checksum is used to generate unique signatures. File
name, size, date, time and signature are combined to initialize the
records in the database. A similar authentication scheme is also
used for the VDS program itself and the database files it creates.
The partition sector, boot sector, command interpreter and VDS.EXE
are backed up in encoded format to reduce the risk of intentional
tampering. The backups will be used if these areas need to be
recovered. The MBR/BR backups on the emergency diskette are not
encoded.
When VDS is run, it creates a temporary database. It also
verifies the integrity of its own code. If it finds that no
tampering has taken place, VDS introduces decoys (small executable
programs created at run-time) to the system to see if an active
virus will take the bait. Under normal circumstances, there is no
legitimate reason why these decoys should be altered by any
program. If the decoys are attacked, this indicates the presence of
a virus with great accuracy. VDS will tell you whether the attacker
was of STEALTH or DUMB variety. If the modifications are masked by
the virus, it is considered to be STEALTH, and DUMB otherwise. VDS
uses a proprietary triple-pass verification mechanism to detect if
the virus attempted to mask the modifications it has made.
On the other hand, some viruses do not fall for decoys that
easily. Their propagation pattern is less predictable. If the virus
activates, however, it will be captured and placed in either
POV.CCC or POV.XXX (an acronym for Prisoner Of VDS) depending on
which decoy it attacks. POV files can later be used to analyze the
captured intruder. The reason for the strange extensions (XXX
instead of EXE and CCC instead of COM) is to prevent activation of
the virus if someone runs the POV files inadvertently. If you
capture an intruder, please mail it to us on a diskette for
interrogation, i.e. examination! You will have an opportunity to
place the captured intruder in a file of your choosing, preferably
on a floppy diskette.
VDS will verify the system areas and the executable files. It
will generate a report on modified files, newly added files, and
files deleted since the last time VDS was run. The user is given an
opportunity to override any alarms that may be set off. The
database is updated if necessary. Note that moving a program file
from one directory to another will be reported as deleted from the
old directory and added to the new directory. If any changes in the
form of infection, software configuration, addition or deletion of
files are encountered, VDS creates VDS-STAT.LOG file in the
C:\VDS210 directory. This is an ASCII text file and can be printed
or viewed easily. It contains a date and time line showing when VDS
has run. It is very useful to check this log when an infection is
discovered to find out how the virus was introduced to the system.
If suspicious modifications appear, VDS attempts to identify
any virus(es) that may be responsible for the changes. A report of
all identified viruses and the victims affected as well as date and
time of operation will be appended to C:\VDS-STAT.LOG file. VDS
looks for known viruses in all newly added files to provide early
identification of viruses introduced to the system. If no known
viruses are identified, then the names of scanned files will be
written to C:\VDS-STAT.LOG. If a file is determined to be modified,
the user will be given a chance to positively erase it. Positive
erase means that the file will be overwritten to the end of the
last cluster it occupies and then deleted. This operation is
necessary since DOS leaves the contents of erased files intact. It
only removes the file access information from its tables.
Although the developers of VDS do not place much emphasis on
knowing the cute names of viruses, this feature is provided so the
curious user does not have to buy a virus scanner for
identification purposes. Please remember that the main goal of VDS
is to detect most possible viruses, not to identify all known ones
by name. Patterns extracted from most known viruses are publicly
available. An average programmer can come up with a little program
that looks for certain strings in a given file (although it may be
slower than the commercial scanning utilities). Paying for such a
utility is not a wise investment. Besides, VDS examines all
possibly executable files and the system areas such as the
partition/boot sector to determine whether a known virus is present
during installation. You can also use VDSFSCAN.EXE to search your
network drives and diskettes for common viruses.
The user can examine reported files at his discretion, and
take whatever action he deems necessary. When a possible viral
attack is detected, our recommendation is to turn off the computer,
boot from a write-protected floppy (preferably the VDS emergency
diskette prepared during installation), and replace the suspicious
files with the originals. VDS does not attempt to remove the
viruses that it identifies (assuming it is possible to remove,
which is not the case with many viruses). In the case of infected
files, so-called virus cleaning software is NOT recommended, and is
not necessary. These utilities can be convenient to treat
infections that affect other areas of the disk such as the master
boot record (MBR). Many computer users might find it confusing to
fiddle with the disk at a low level, and do more harm while trying
to fix the problem. In most cases, VDS will restore the
partition/boot sector automatically.
VDS provides a CURE option that will repair the partition
sector using the backup copy saved on VDS emergency diskette. If
you did not prepare an emergency diskette, and the hard disk
becomes inaccessible, then you should either use VITALFIX.EXE or
try a manual recovery. In most cases, any experienced computer user
can restore the disk by following simple instructions. We strongly
suggest that you backup your master boot record on a floppy
diskette. You can use VITALFIX for this operation.
C. VDS Device Driver
Registered versions of VDS will create a customized device
driver for your computer during installation. The purpose of this
device driver is to detect any modifications to system areas. These
areas include:
1. Master Boot Record (MBR)
2. Boot Record (BR) of the active partition
3. C:\COMMAND.COM (or user-specified command shell)
4. DOS system files (named IBMBIO.COM and IBMDOS.COM on some
systems)
5. C:\VDS210\VDS.EXE
6. C:\VDS210\VDSDEV.DDR (self)
7. Base memory size (after taking EBDA -extended BIOS data
area- present on some PS/2s and clones into
consideration)
If modified, the device driver (VDSDEV.DDR) will attempt to
recover the affected areas in the case of MBR and BR. If only the
partition table is modified, not the loader code in MBR, then
VDSDEV.DDR will issue a warning message and not attempt recovery.
This eliminates the possibility of causing damage if the device
driver was not installed but simply copied over from another
computer. If all system areas pass the integrity checks, then you
will not notice any difference in the operation of your computer
(except for our "glorious" copyright message). VDSDEV.DDR adds 3-5
seconds to boot-up time.
Additional features include:
- Capturing MBR/BR viruses in a file
- Option to halt the system in the case of infections
- Customized (user-supplied) message display
- 0-K memoryless operation!
- 0-conflict operation!
- Superior handling of MBR/BR viruses and other system
infectors
The installation procedure will provide you with an
opportunity to include your customized message in the device
driver. This message will be displayed if a suspicious modification
is found. You will also be able to specify whether you would like
to have the device driver to halt the computer in the case of a
suspicious modification. If the system administrator wants to have
strict control over such incidents, it is a good idea to turn on
this option accompanied with a message to contact the system
administrator.
In the long run, the system administrator will be able to keep
track of all incidents and contain the spread of viral infection.
Once the spread is contained, the threat of viruses becomes
insignificant.
Assuming you chose to halt the CPU in the case of a
modification and that MBR was found to be modified, here is an
example message that you may get when the hard drive is attacked by
the Stoned-2 virus:
VDSDEV 2.10 Copyright (c) 1992 VDS Advanced Research Group
Unusual base memory size. Possible MBR/BR virus.
MBR on first hard disk failed integrity check. Possible
virus.
Attempting to recover MBR . . .
--> Call PC System Administrator x5112 Immediately!
Initiating immediate CPU shut-down
*** CPU Halted ***
You will also hear a beep. If you choose not to halt the
system, then the device driver will reboot the computer after
recovery attempt. In most cases, the recovery will be successful,
and there is no need for further action. At any rate, it is
advisable to check the floppy diskettes recently used on that
computer. You should also examine C:\VDS210\VDS-STAT.LOG for more
information.
The only time the recovery may not result in a clean system is
when a multi-partite virus attacks. Such viruses can infect both
executable files and MBR or BR. Even if the device driver fixes,
say MBR, it will be reinfected by the virus as soon as an infected
program is run later on. In that case, the device driver will
recover and reboot every time. For this reason, it is a good idea
to choose to halt the CPU and boot from a system floppy diskette
and then eliminate the virus.
Since the recovery operation restores the original contents of
the MBR or BR, the virus will no longer be present. To determine
the cause of modification, and get a better idea about which virus
you are dealing with, the device driver will place the contents of
the modified area in a file. If MBR is modified, the file will be
named C:\VDS210\MBR.DAT and if it is BR, the file will be named
C:\VDS210\BR.DAT. You can examine the contents of this file later
on. If you find that it was a known virus, then you should
definitely search the floppy diskettes used on that computer for
that particular virus. If it is a new virus, it may still be
possible to extract a pattern to search for. You are also
encouraged to send a copy to the developers of VDS.
In our tests, we have found the VDS device driver to be
extremely effective against system infectors such as Stoned, NoInt,
4096 and others. If nothing else, you should at least have
VDSDEV.DDR as a first line of defense against viruses. If you
experience any problems, please let us know so we may determine the
cause and come up with a viable solution. Please remember that the
VDS device driver created for one computer should not be run on a
different computer; otherwise, it may cause damage to the MBR.
Technical Details
Some people may wonder how we can claim that our device driver
will not take up any memory and that it will not conflict with most
other programs. The reason is quite simple: VDSDEV.DDR goes away
after it completes its mission (which is to detect suspicious
modifications to the system areas) and releases the memory it is
given by DOS. Since it does not change any interrupt vectors, there
should not be any conflicts with other programs.
This approach differs from other anti-viral products that
provide a memory resident or device driver level defense against
viruses. They implement an active monitor that is always in memory
and watching for suspicious activity. Although this may sound more
secure, we consider such an implementation overkill as well as
inelegant for several reasons.
The first reason is obvious: it takes up a chunk of precious
640K memory. This problem can be minimized under DOS 5.0 if it is
possible to load the program high. Not everyone has DOS 5.0 and
some computers cannot take advantage of this feature at all.
The second reason is that it may conflict with other programs.
Some of these products may even cause damage to your files since
most active monitors intercept disk access. It is possible to
design a very robust and reliable program; however, other
applications may not be so well-behaved and still create such
problems.
The third reason is the degradation of overall system
performance. Most active monitors are quite aggressive policing
every disk activity that takes place. The price is CPU cycles and
increased disk access time.
The fourth reason is that these products are useless against
certain types of viruses. They attempt to stop viruses before they
can get into the computer. Some viruses can completely bypass all
monitors and spread infection easily. Such viruses reduce the
monitoring mechanism to "playing catch" in memory.
Even worse, booting from an infected floppy diskette may cause
the hard drive to get infected. So-called "Stoned" virus is able to
spread in this manner although it is one of the less advanced
beasts.
The fifth reason is the frequency of false alarms these
products issue even when a legitimate program is accessing the
files. After some time, users tend to either ignore almost all
alarms or remove the anti-viral program from their machines.
Another reason is more personal and debatable. It has to do
with evaluating your risk factor and determining what kind of a
solution is more appropriate. Here are some questions we suggest
that you should ask yourself:
1. Is it worth having an active TSR (terminate-and-stay-
resident monitor, implemented either as a device driver
or a regular program) that can cause conflicts, take up
memory, degrade system performance, and issue many false
alarms while being prone to certain viruses?
2. Is it sufficient to have a device driver level integrity
checking mechanism that takes no more than 3-5 seconds
only once during boot-up, does not use up any memory,
does not cause conflicts with other programs but one that
is still 99% effective?
What makes the answers to these questions debatable is how to
measure effectiveness. Our stand on this is obvious. Nevertheless,
please take a moment to look at the "big picture" without paying
attention to marketing hype and other irrelevant criteria presented
by some other anti-viral product developers. Ask yourself how many
viruses attacked your computers over the past two years. Ask
yourself how many times you had to deal with non-virus related
conflicts between programs or hardware failures. Evaluate your risk
factor in simple terms. Is all your important data backed up on at
least two sets of storage media? Are all your original program
diskettes write-protected? Do you have a copy of your partition
table? Do you know your hard drive type as designated in CMOS? How
many times a month do you download software from faraway BBSes? Do
you frequently play games (that you borrow from your friends) on
your computer? Do you let other people use your computer often?
When was the last time you added many different programs to your
hard disk? The list of questions can go on and on.
Let us make it clear that we do not intend to paint a scary
picture for no reason. These are the types of questions everyone
who wishes to practice safe-computing should ask himself. Our
recommendation is: Take sensible, simple precautions against both
viruses and other forms of potential damage to your computing
resources and data. There is no need to become paranoid and lose
your perspective.
All of the programs in the VDS package are designed to provide
a simple but effective way to contain the spread of computer
viruses that target PCs running MS/PC DOS. The only way to stop
viruses (ignoring theory for a moment) is by containing their
spread and reducing them to rare occurrences. This is the essence
of our approach to solving this high-tech problem.
We have seen sites where the "Stoned" virus reigned supreme.
It was like a permanent attachment to users' disks. Worse yet,
people were convinced that it was impossible to get rid of it
completely since it had a habit of coming back. It was only three
weeks after installation of VDS that Stoned became a nightmare of
the past.
Then there was "Jerusalem" with a little black box appearing
on the screen for no obvious reason. It did not even survive as
long as Stoned did.
Everyone at that site heard about computer viruses, most of
them had one in their machines. A few people even heard about
theories that prove why viruses cannot be stopped. They do not
believe those theories any more. They believe there are effective
solutions such as VDS. If you need convincing, please give VDS a try.
D. VDSFSCAN
VDSFSCAN is an easy-to-use virus scanner that works on DOS-
compatible drives, including LAN server drives. It offers two modes
of operation: interactive and command-line. Interactive mode is
based on a simple menu system that makes it very easy to access
advanced features of VDSFSCAN, and it offers context-sensitive help
(F1 key). Command-line mode can be activated from batch files. It
accepts various options to customize the operation of VDSFSCAN.
Once VDSFSCAN is loaded in memory, you can scan multiple diskettes
easily.
The main menu offers six options to choose from:
1. Set Options
a. Target Drive
i) Selected from a scrollable list of drives
b. Scan Whole File (YES/NO)
c. Scan All Files (YES/NO)
d. Scan Every Drive (YES/NO)
e. Recursive (YES/NO)
f. Erase Infected Files (YES/NO)
g. Generate Report (YES/NO)
h. Log Errors (YES/NO)
i. Network Drive (YES/NO)
j. Multiple Infections (YES/NO)
k. Wildcard specification (*.* by default)
l. Quiet mode (YES/NO)
m. Pause flag (YES/NO)
2. Scan Drive
Will search boot sectors if the target drive is A:, B:,
or C:, as well as program files on the disk.
3. Scan Directory
Subdirectories within subdirectories will be explored if
the recursive option is set to YES
4. Scan File
Certain areas of executable files will be searched for
known viruses. If the Whole File option is set to YES,
the file will be searched in its entirety. If the All
Files option is set to YES, then every file will be
examined, regardless of its type.
5. Scan MBR/BR
Master boot sector (hard disk only) and boot sector of
the target drive (only for A:, B:, and C: drives) will
be searched for viruses known to reside in these areas.
If a virus is identified, VDSFSCAN will offer to remove
the virus. You will also have the option to place a copy
of the affected area in a file for examination.
6. Quit
Ends the session. ESC key serves a similar purpose.
You can move between selections using the up and down arrow
keys and press ENTER to activate the item you selected.
Alternatively, you can press the highlighted letter of a selection.
ESC key will get you out of a menu, or it will prompt you to stop
the search operation during virus scan. CTRL-BREAK will also prompt
you to stop the search.
We encourage users to start their computer with a clean,
write-protected, and bootable DOS system diskette to ensure that no
viruses are active in memory while scanning. Some viruses
manipulate file access and try to hide their existence or spread
the infection to other programs. Although, VDSFSCAN will attempt to
check for such viruses, the only guaranteed way to do an untampered
search is after booting the computer from a clean system diskette.
VDSFSCAN will also check its own program file to make sure it
is not modified, possibly indicating a virus infection. In such
cases, it will warn you with a message, and abort its operation. We
prefer the user to run an unmodified copy of VDSFSCAN to ensure
correct operation.
In the case of boot sector infections, VDSFSCAN will ask you
if you would like to remove an identified virus. This option
applies to master boot sectors on hard drives and boot sectors on
floppy drives. You should use the SYS program included with DOS to
remove boot sector infectors from the active partition of a hard
drive or to keep a system floppy diskette bootable. When VDSFSCAN
removes a virus from the boot sector of a floppy diskette, it
constructs a BPB (BIOS Parameter Block) for the diskette and adds
instructions to display a message you would get from a non-bootable
diskette. In any case, the viral code will be overwritten. In the
case of the hard drive master boot sector, VDSFSCAN keeps the
partition table intact and replaces the loader code, again
overwriting any viral instructions. It will also attempt to verify
that the partition table actually corresponds to the disk layout.
E. Scenarios and Messages
During its operation, VDS may issue several warning messages.
Following is a list of scenarios that will highlight common
warnings, their reasons, and recommended actions to take.
Message: COMMAND.COM is modified. Will attempt to restore.
Reason: This message refers to the DOS interpreter that
displays the prompts, runs other programs, and
controls file access.
Action: VDS will attempt to restore it by using the backup
copy of COMMAND.COM stored in C:\VDS210 directory
during installation and rebooting the system. After
the system comes back up, VDS will repeat the
verification process. If COMMAND.COM fails
verification this time, VDS will abort operation
and ask you to boot from a write-protected floppy
diskette and run REPAIR.
Message: Partition sector modified. Will attempt to restore.
Reason: There is a good chance that either a partition
sector infector has entered the system, or some
other damage to the partition sector has occurred.
Some non-standard versions of DOS (Zenith etc.)
supposedly modify the partition sector, and use
certain areas to store variable information. VDS
does a complete check and makes no provisions for
non-standard systems. We have no intention of
compensating for such a bizarre utilization of
system areas by these vendors.
Action: VDS will attempt to restore the partition sector
and reboot the system. If the verification fails
again, VDS will abort the restoration attempt and
recommend a floppy recovery using the VDS emergency
diskette.
Message: No message, VDS simply hangs the machine.
Reason: If VDS has been running just fine, but stopped
functioning now, then VDS.EXE may be corrupted
either by accident or by an overwriting virus which
failed to preserve its victim's operation. It is
also possible that some TSR program caused a
conflict. Assuming VDS runs as the first program in
your AUTOEXEC.BAT file, and CONFIG.SYS is not
modified, you should assume the worst case: a virus
attack.
Action: Reboot the computer from VDS emergency diskette or
a write-protected known-to-be-clean system
diskette. If you have prepared the VDS emergency
diskette, then run VDS from A drive with the CURE
option:
A:\VDS -C <enter>
* You can simply run REPAIR.BAT
Message: VDS requires DOS 3.0 or higher to run.
Reason: The version of DOS installed on your computer was
below 3.0.
Action: You need to upgrade to DOS 3.0 or above. VDS will
not run on systems with a lower DOS version.
Message: VDS cannot initialize.
Reason: VDS could not initialize its data structures.
Action: Assume it is a virus attack and run VDS from a
floppy diskette using CURE option. If this happens
during installation you either have a non-standard
hard drive or another conflict has occurred.
Certain security programs that encrypt the master
boot record will also cause this conflict. If that
is the case, you have to either forego these other
programs or VDS. Non-standard partitions (e.g.,
those created by Ontrack Disk Manager) may cause
this message as well.
Message: Error occurred during installation.
Reason: This is a generic message that indicates a
malfunction during installation.
Action: You should see some other error messages come up
before this one. The cause can be determined based
on those. Go back and check if you followed all the
steps in the installation procedure.
Message: Error occurred during verification.
Reason: This is a generic message that indicates a
malfunction during verification.
Action: You should see some other error messages come up
before this one. The cause can be determined based
on those. Go back and check if you have changed
anything on your system, such as adding a device
driver to your CONFIG.SYS and so on.
Message: VDS cannot continue operation; Aborting . . .
Reason: VDS detected an unstable environment.
Action: Make sure you followed the installation
instructions. Another reason is attempting to run
VDS under a debugger.
Message: You have to coldboot the computer from floppy disk.
Reason: CURE and INSTALL options require that the computer
is booted from a DOS system floppy diskette.
Action: Turn the computer off. Place a bootable DOS
diskette in drive A: and turn the computer on.
Message: You must cancel ASSIGN before running VDS.
Reason: VDS detected that ASSIGN was active.
Action: This TSR program comes with DOS and allows users to
modify the way DOS and other programs access the
file system by making one drive letter correspond
to another one. Not to cause any conflicts, VDS
refuses to run under such circumstances. You should
run VDS before this program.
Message: Boot from VDS distribution diskette for
installation.
Reason: The computer was not booted using the VDS
distribution diskette.
Action: INSTALL option requires that the computer is first
coldbooted from the VDS distribution diskette and
then a DOS system floppy diskette when you are
asked to do so. Please follow the installation
instructions. This message applies only to the
registered versions of VDS. Trial version does not
come with a special distribution diskette.
Message: VDS cannot locate SELFDATA.VDS; Aborting . . .
Reason: VDS could not find its database file.
Action: This file is located in C:\VDS210 directory. It is
created during installation and updated when
necessary. You should not delete it. Reinstalling
VDS is the only way to recreate it. If you would
like to backup this information, make sure you also
backup the CVDSDATA.VDS files.
Message: Different DOS version. If you upgraded DOS,
reinstall VDS.
Reason: DOS version during installation was different than
the current one.
Action: The system floppy used during installation should
have the same DOS version you have on the hard
disk.
Message: Operation of VDS is affected. Cannot continue.
Reason: VDS could not establish a secure environment.
Action: If this message comes up after VDS has been working
okay, then a virus infection is possible. It is
also possible that you added a program that
modified the hard disk in an unconventional manner.
Message: Need 512K free space on hard disk to install VDS.
Reason: VDS found that there is not enough space on the
hard disk.
Action: You should delete some files to free up space on
the hard disk and then try to run VDS again.
Message: Suspicious modifications detected.
Reason: VDS has found that some executable files have been
modified.
Action: First take a look at the C:\VDS210\VDS-STAT.LOG to
find out if any viruses were identified. If some
files are determined to be infected by a virus,
note their names either by printing this file or
writing down their names. Also look at
C:\VDS210\VDS-STAT.LOG to find out other modified
files. Again, either print this file or write down
the names of the modified files. If you cannot
remember why any of these modifications should have
occurred, then assume they are also infected by a
virus (safe than sorry). Reboot your computer from
a write-protected system diskette (preferably VDS
emergency diskette), and replace all the suspicious
files with the originals. You can use CURE option
to eliminate the possibility of a boot/partition
sector infection (again VDS would have told you if
they were modified). Now reboot the computer from
the hard disk. Depending on the results follow the
procedure above until everything passes the
verification test. In most cases, only a few files
will be infected and this procedure will be very
simple. Having an early detection will contain the
spread of infection. In the long run, viruses will
no longer be a serious threat to your computer
system.
F. Command Line Options/Flags
VDS [{-|/} ? | I | C | H | T | V] [LCD | E | W | X] [D:] [n]
D: Drive to process
n number of logical drives starting from C
Options
H(elp), ? explains command line options and flags
I(nit) used to install VDS the first time
C(ure) used to recover from partition/boot sector
infections
V(erify) used to look for modifications (default option)
T(urbo) less accurate but fast verification of system areas
and files
Flags
LCD forces to use monochrome attributes, easier to read
on laptops, or monochrome systems with a color card
E(rase) infected files will be deleted without prompting
for confirmation
W(hole) will scan files completely, default is partial scan
X(clude) run in compatibility mode
The options and flags must be immediately preceded either with
a '-' or '/'. If no option is specified, VDS will default to
VERIFY. You need to specify only the first letter of an option. The
order may be reversed so that the number of drives are specified
before the options. If you enter more than seven command line
arguments, only the first seven will be recognized, and the rest
will be ignored. All options are disjoint, meaning that you can
specify only one of them. The flags can be used together with each
other and the options, although the CURE option ignores everything
else. For example, you cannot have both CURE and VERIFY at the same
time; but it is acceptable to use TURBO, ERASE, and WHOLE together.
If you would like to do a turbo check of C: drive and delete the
infected files, type the following:
C:\VDS210\VDS.EXE -T -E C: <enter>
The colon (:) after the drive letter is required. The drive
letter must be C or higher. The list of deleted files that had a
virus will be placed in C:\VDS-STAT.LOG. If you press the ESC key
during scan, VDS will ask you if you would like to stop the
operation. If you answer affirmative, it will abort the scanning
process except during installation.
G. Common Questions and Answers
This section addresses some common questions about VDS.
Q - Do I have to know a lot about viruses to be able to use
VDS on my system?
A - Not at all. One of the design goals was to create a
program that can be easily used by novice computer users.
Viruses present some unique complexities even to the
experienced computer security experts. VDS can alleviate
most virus-related problems automatically. You are,
however, encouraged to become familiar with general
guidelines to deal with computer viruses.
Q - Where is VDS version 1.0?
A - The first version was installed at a few selected test
sites. Many changes and improvements are incorporated
into versions 2.0 and 2.10, which are the ones that we
distribute publicly.
Q - Can I run VDS under MS Windows 3.0 & 3.1?
A - Yes, you can. We recommend that you either create a PIF
file with full window option on, or shell to DOS first.
Do not try to switch tasks while VDS.EXE is running.
Using the -Xclude option can help avoid system lockup.
VDSFSCAN can run in the background. VITALFIX should NEVER
be run from inside Windows since it accesses the hard
disk directly.
Q - Is VDS compatible with DOS 4.01 and 5.0?
A - Yes, indeed! We have tested VDS on various systems
running MS/PC DOS 3.0. 3.1, 3.2, 3.3, 4.01 and 5.0. We
did not encounter any problems. Please let us know if you
do.
Q - Can I run VDS under OS/2?
A - Maybe. You can run it in OS/2 DOS box in a limited
fashion. Please specify the -Xclude option to avoid
conflicts.
Q - I have a program that requires to be run before other
programs in AUTOEXEC.BAT. Since VDS should be the first
program to run, how can I resolve this conflict?
A - There is no conflict from a technical point of view. The
other programs that force you to run them first usually
revector several interrupts to their memory resident
code. If another program grabs these interrupts, then
they would not be able to guarantee proper operation.
Running VDS as the first program does not affect these
programs since VDS is not memory-resident and it does not
hook any interrupts. VDS can be classified as an
integrity shell; although in the current implementation,
once it is finished verifying the system, it simply goes
away. If you run other resident programs, however, they
may conflict with the operation of VDS, and probably get
disabled by VDS (depending on the order of execution
during setup). The solution is to run VDS as the very
first program in AUTOEXEC.BAT. Remember that the other
programs need protection against viruses as well. If VDS
runs first, it can check them before a possibly infected
program is run. If VDS itself is infected, it will notice
that fact and warn you.
Q - What is the purpose of the VDS device driver? Will it
cause conflicts with other device drivers that I have?
A - The purpose of the VDS device driver is to ensure that
the system areas are not modified. These areas include
the MBR, active partition's boot record, DOS system files
and COMMAND.COM. The device driver will also check itself
and C:\VDS210\VDS.EXE to make sure they are not modified.
In our tests, the VDS device driver was able to detect
all MBR and BR viruses as well as other system infectors
that target COMMAND.COM. The operation of the device
driver will be transparent (except for our "glorious"
copyright message) unless a suspicious modification is
detected.
No, the VDS device driver should not cause any conflicts
with other device drivers or programs as long as it is
loaded first. Unlike many other device drivers, it simply
goes away after initialization, releasing all memory it
was given by DOS during loading. Just place the VDS
device driver as the first command in your CONFIG.SYS and
everything should be just fine. Our philosophy is to
provide a non-intrusive, non-conflicting anti-viral
program that is easy to use.
Remember, however, that the device driver is not intended
to run on any other computer besides the one it was
customized for. If you attempt to use it on a different
computer, damage to your MBR is likely.
Q - Does VITALFIX work on IDE drives?
A - Yes, it does. VITALFIX is compatible with all types of
hard drives currently in use. This includes drives with
MFM, RLL, IDE, SCSI, and ESDI controllers. The only
problem we have come across was on disks that used a
compression or security program that rendered the disk
unreadable unless all access was done through the
interface these programs provided. VITALFIX cannot
tolerate such restrictions since it must have direct
access to the bare drive. Anything less would open up a
security loophole if a virus is active when VITALFIX is
operating. It is always a good idea to boot the computer
from the original DOS diskette before using VITALFIX. As
a precaution, VITALFIX checks the partition table to find
out if the drive has any non-DOS partitions, and will
warn you if this is the case. In some cases, the
partition table may not be available to make that
determination. If you know you have non-DOS partitions
or compressed partitions, we strongly suggest that you
do not use VITALFIX to perform any of the functions that
involve writes to the disk.
Q - My computer is infected with a virus already. How can I
use VDS to deal with this problem?
A - The approach to this problem depends on what kind of a
virus you are dealing with. VDSFSCAN can help you locate
which parts of the system are affected if it is a virus
that can be identified using our search strings.
If it is a boot sector infector, you can simply turn off
the computer, boot from a write-protected floppy diskette
and run SYS program to put a clean boot sector onto your
hard drive. If it is a program file infector, you need
to replace the infected files from the original
distribution diskettes.
In the case of partition sector viruses, we recommend
that you use VITALFIX.EXE. This utility automates
locating MBR, and even constructs one if necessary.
You may be able to get the original partition sector
back, if the virus relocated it to another sector on
track 0, head 0 (as some do). You need to fire up a low-
level disk editor, and look through head 0, track 0. The
first sector contains the Master Boot Record (partition
sector), and may have been replaced by the virus code.
Look at each sector (17 of them on an MFM drive), and see
if any one has AA55 as the last two bytes in the sector.
These identification bytes are present on all legitimate
partition sectors as well as boot sectors. Remember that
this is a trial-and-error process, so it may not work.
You may want to seek assistance from a local computer
"guru" if necessary. Make sure you save the current copy
of the partition sector on a floppy diskette first.
If the hard disk is accessible after booting from a
floppy diskette, then the partition table (64 bytes near
the end of the master boot record) may still be valid.
The code that loads the active boot sector may belong to
the virus. If you can extract the partition table
information from the current copy of the partition
sector, you may even be able to place it into a good
partition sector you get from a similar computer with a
similar disk and the same DOS version. You can then place
this combination of partition table from the infected
system and partition sector code from the clean system
on top of the current partition sector on the infected
system and reboot. This might just do the trick. Be very
careful, however, and backup all your data files before
starting this surgical operation. You might end up
clearing the MBR and repartitioning the disk as a last
resort.
Q - I have a big hard disk partitioned using Ontrack Disk
Manager. Why can't VDS run on my system?
A - Ontrack provides a device driver that makes it possible
to access drives with non-standard geometries such as
more than 1024 cylinders. VDS has yet to be tested in
that environment. We chose to be on the safe side by not
attempting to run on systems that we have not tested.
Such TSR utilities deal with the hard disk at a very low-
level, and if there is a conflict, may cause damage.
Taking such a risk without extensive testing is something
we certainly avoid.
Q - Does VDS have a TURBO mode versus a SECURE mode?
A - Yes. If you use -T switch, VDS will operate in TURBO
verification mode, which is faster but less accurate than
VERIFY mode (default). For newly added program files, VDS
does a thorough scan for known viruses.
Q - How does VDS encryption work? Is there a possibility
that my disk may become inaccessible?
A - There is NO chance your disk will become inaccessible
because of VDS encryption. VDS encrypts only its data and
backup files. Please do not confuse this with some other
programs that encrypt the hard disk completely or in part
to disallow unsupervised access. This approach is not
something we recommend or use unless you are into top
secret stuff! Secrecy has little to do with viruses.
Q - How secure is VDS encryption scheme?
A - Our purpose was not to come up with an unbreakable (if
there is any such scheme) encryption method, but to use
something more secure than good old XOR. Contrary to
popular belief, the robustness of an anti-viral integrity
system cannot be measured by the sophistication of the
encryption algorithm it uses. Some people even believe
that they can deal with "stealth" viruses easily if they
use an encryption scheme that cannot be forged. That is
not so. The stealth viruses intercept the verification
routine's attempts to access the modified executables on
the disk, and present them with a clean copy. No matter
how sophisticated the algorithm used to generate a
signature is, it will be fooled every time since the
verifier is getting clean (the same as the original)
input. While these people are perfecting the technique
to compute a one-way cipher of extreme complexity,
"stealth" viruses are having a ball on the disk they
choose to invade. Of course, if a direct attack is a
concern, then more secure encryption methods are very
useful. In the DOS environment, manipulating the disk
access is much easier and works in most cases. So, if
someone tells you they got a superior multi-stage
encryption routine that can come up with secure keys for
their anti-viral product, just ask them why they chose
to waste their time on such an endeavor! Viruses are not
an attack to the secrecy but to the integrity and
availability of computer systems. Unfortunately, many
self-described experts seem to confuse these separate
issues.
Q - I heard some programs create hidden files on the disk.
Does VDS create any hidden files?
A - Absolutely not. We have nothing to hide from the end-
users! Almost everything VDS creates is restricted to
the VDS210 directory. The only exceptions are the VDS-
STAT.LOG (unless installed) and decoys which are placed
in the root directory, since scanning can be performed
without installation and there would be no VDS210
directory.
Q - Does the VDS authentication scheme eliminate the
possibility of a trojan version of the program?
A - To some extent. "Trojanization" has been a problem with
many software packages in the market. VDS authentication
scheme provides a reasonable amount of assurance that the
copy you have is actually created by the original
developers. It is possible to circumvent this mechanism
and display a fake message. This can be considered a
direct attack. Remember, a direct attack against any
program is possible (you can safely ignore those who
claim otherwise). The purpose is to provide another layer
of security. If every software product in the market put
in as much effort as VDS does, there would be less
incidents of trojans. You should get your programs from
reliable sources. If you see a program claiming to do
major database work, and it is only 4K long, you should
double-check on it!
Q - I backup my hard disk regularly. Do I still need an anti-
viral program to be safe?
A - Yes, you still need a program such as VDS. Backups can
help when recovering from damage. The problem is by the
time you notice that the system is infected, the virus
may have been transferred to the backup media. When you
restore the system, you may very well restore the virus
too! In some cases, the virus may corrupt the backup
diskettes and render them useless. One person reported
that Stoned virus corrupted all his backup diskettes
while he tried to backup his hard disk to be able to
perform a low-level format. Unfortunately, the Stoned
virus was active in memory at the time. By the way, when
was the last time you verified that you can actually
restore from your backups?
Q - What are "POV" files?
A - POV stands for "Prisoner Of VDS". These files are created
by VDS when it detects an active virus in memory that
attacks upon file access. When VDS introduces decoys into
the system, some viruses immediately attack them. VDS
notices this fact and captures the intruder in a file.
VDS will also capture a modified boot or partition sector
in POVBOOT.BBB or POVPART.PPP file in C:\VDS210
directory. If VDSDEV.DDR captures a modified MBR or BR,
VDS.EXE will notice that and scan the saved copy, as well
as rename it (MBR-000x.POV or BR-0000x.POV) so that up
to ten such samples can be caught. This feature speeds
up the diagnosis process. In other words, you will have
the captured virus stored in a file that you can analyze
(or have someone analyze it since this would require
familiarity with the 80x86 assembly language). Initially
we used this feature during testing. Some friends
suggested that it might be a good idea to keep this
feature in the production version as well; so there it
is. Remember that not every virus can be caught this way.
If you catch a virus, you are encouraged to mail it on
a diskette to us for analysis.
Q - Is it possible to make VDS run faster?
A - That depends on how fast your hard drive subsystem is.
The bottleneck in the operation of VDS is disk I/O. VDS
uses a very sophisticated multi-buffering scheme to
maximize performance. One thing VDS cannot (no other
program for that matter) do is to change the speed of the
underlying hard drive subsystem. If you have a caching
hard disk controller, VDS will run faster. If your
interleave factor is not set to optimum value, for
example, disk access will be slowed down. Another factor
is the number of executable files on the disk. The more
files you have, the longer VDS will take. File
fragmentation is another factor that can slow things
down. In other words, anything that can speed up disk
access in general can make VDS run faster. VDS also runs
faster in TURBO mode than in SECURE mode.
Q - Why can't I run VDS on a floppy diskette?
A - VDS will check if it is running on a hard disk, and will
abort operation if it finds otherwise. The reason is one
of practicality. A verification system like VDS makes
sense on a medium that is central to the operation of a
computer system. You should, however, search your floppy
diskettes for known viruses using VDSFSCAN.
Q - My company wants to purchase VDS for all our PCs, but we
are not sure if there is an expiration date on use of
VDS? Is it necessary to renew the VDS site license on
a regular basis?
A - A registered copy of VDS can be used by the licensee
indefinitely. There is no limited license that expires
in time. We believe that the end-user has a right to run
a program he paid for as long as he is satisfied with its
operation. Updated versions of VDS will be made available
only for a nominal fee that is independent of the number
of copies licensed.
Q - Is it possible for a data file to become infected by a
virus?
A - The criteria for a virus to do anything at all is that
it must gain control of the CPU. An ordinary data file
will never have such control. The possibility exists for
macro or script files that some application software
packages provide to automate certain operations. There
are no common viruses that exploit this feature. Another
possibility is to cause damage as a side effect, for
example, by redefining a key sequence as a substitute for
a destructive command, assuming a driver such as ANSI.SYS
is loaded. Again, these are very limited ways that a
virus can propagate, if at all. Batch files can also be
used to activate a program that contains a virus. The
problem is that it is too obvious and will be detected
easily.
Q - I heard a lot of things about how Artificial Intelligence
could be very effective against viruses. Does VDS employ
any AI techniques?
A - VDS is based on real intelligence, not artificial!!! AI
is an overused term these days. Almost every new product
claims to have certain AI capabilities. VDS employs
powerful heuristics and extremely sophisticated
techniques to detect almost any virus that attacks MS-DOS
systems. It is not, however, similar to rule-based
inference engines. There are some neural network models
that can be trained to recognize viral behavior. So far
these models could not go beyond the lab environment. If
the detection process takes almost half an hour (as some
do), it is not feasible to run such a program every time
the system is restarted. VDS takes a more practical
approach to boost the performance to acceptable limits.
A more accurate description of the way VDS uses AI
techniques would be "it calculates a suspicion factor
based on various operational parameters in the system,
and adapts its behavior according to this factor."
Purists would not consider this artificial intelligence
in the strict sense of the term; however, if we can
determine a set of operational parameters that can
accurately represent the state of a clean system, then
at any point in time we may be able to detect whether the
state of the system has reached a certain condition. That
is exactly what we need: to determine if there is a virus
present while reducing false alarms to an acceptable
level. The assumption is that the parameters for a virus-
free state is known a priori.
Q - I could not find any virus-specific information in the
documentation that came with VDS? Am I missing
something?
A - No, you are not missing anything. We do not place much
emphasis on knowing details about every virus, although
we do quite a bit of analysis on virus samples we obtain.
Most viruses can be categorized based on which system
resources they exploit. There are some published works
that contain virus-specific information. We do not wish
to duplicate such efforts. If you would like to obtain
detailed information on a specific virus, please refer
to some of those lists (we do not endorse or recommend
any particular list). It is a good idea to consult two
or more such lists since they tend to contain inaccurate
information. Patricia Hoffman has been maintaining a
comprehensive list of virus-specific information for a
long time, and it is publicly available. Latest version
of this product comes with a browser utility to make it
easier to locate entries in the list. You can access her
BBS via a modem. The number to the BBS, named Excalibur!,
is (408) 244-0813.
H. Known Problems and Conflicts
This section addresses various conflicts or problems with the
operation of VDS that we are aware of. You are encouraged to report
any problems you discover.
1. SETVER.EXE that comes with MS/PC DOS 5.0 causes false
alarms.
SETVER.EXE program modifies itself to keep track of programs and
the version of DOS they should get as a result of INT 21h, function
30h call. Many consider such self-modifying programs "ill-behaved".
Until developers of DOS come up with a better way to accomplish the
same task, you are likely to get false alarms. We do not intend to
accommodate use of such a questionable practice.
2. VDSDEV.DDR gets confused when loaded high under DOS 5.0.
You do not need to load VDSDEV.DDR high. Since it releases all of
its memory after it is done, you will not lose any memory from
640K. Use DEVICE command not DEVICEHIGH in your CONFIG.SYS to
activate the driver.
3. Decoys do not function on Stacker volumes.
We do not recommend usage of a disk compression program like
Stacker in combination with VDS. Do not even install VDS on such
disks. We have not done extensive testing under such environments
and cannot guarantee safe operation.
V. VIRUS ATTACK METHODS
A. Virus defined
A computer virus is a piece of (executable) code that has the
capability to replicate itself (replication task), in part or full,
by attaching to other existing code. The attachment does not have
to be physical, as is the case with "spawning/companion" variety,
but it usually involves physical modification of other existing
code. The virus can also have a damage mechanism (manipulation
task) in addition to its propagation capability. If it does not
replicate, it is not considered to be a virus.
B. Attack & spread methods
We will now present some information on common strategies MS-
DOS viruses use in practice. This section is by no means an
exhaustive listing of viral methods; it is intended to provide
unexposed users with preliminary knowledge of the subject matter.
We will also present a few general principles such as the
following:
1. Any modifiable (directly or indirectly) and executable
piece of code in a system can be a target for viral
attack.
Certain areas are exploited more often either because they
simplify the implementation of the viral code or they provide a
good platform to achieve a high infection rate. The interrupt
mechanism in the MS-DOS environment is one such area. Many viruses
gain control of the CPU upon activation of an interrupt. The viral
modifications to the interrupt mechanism fall into two major
categories:
1. Redirection of interrupts by replacing the contents of
the interrupt vector table.
2. Direct modification of the interrupt handler code where
a vector address points to.
An example for #1 is Dark Avenger. The addresses of certain
interrupts are modified to point to the virus in memory. The virus
gains control of the CPU whenever the "hooked" interrupt is
invoked.
The best-known example for #2 is 4096 (Frodo). The interrupt
handler code for INT 21h is modified by planting a jump instruction
so that the destination is the viral code active in memory. This
subtle change is more difficult to detect using typical interrupt
monitoring software. Many "experts" believe that it is not possible
to detect modifications this virus (and similar viruses) has done
while it is active in memory. VDS has no such restrictions.
Many system services, including file access, are provided by
the DOS INT 21h handler. Most viruses hook this interrupt, using
either #1 or #2, so that they can propagate. Some viruses also
supervise any request to access an infected file, and undo the
changes on the fly in order to evade detection. This behavior is
referred to as "stealth", and is quite effective in practice.
A virus usually inserts its own code before the original
program (either by modifying the entry point or by placing a jump
instruction to the viral code) so it can gain control and modify
the environment to its advantage. Non-overwriting viruses may be
able to preserve full functionality of the programs they infect.
After they are done replicating or doing whatever damage they
intend, they pass control to the original program. The user will
probably not notice the difference. These viruses can stay dormant
longer than those that cause permanent damage to programs during
infection. For example, if your word processor refuses to run one
morning, you will try to find out why.
Another method of infection does not involve physical
modification of program files, but rather exploits a feature in
DOS. So-called companion viruses create a program file with the
same name as their victim, but with a COM extension instead of EXE.
Under DOS, a COM program will execute if there are two files: One
with a COM extension and one with an EXE extension. Therefore, when
the user types the name of the program, the companion virus is what
DOS will execute. Under DOS 5.0, you can eliminate this ambiguity
by specifying the extension as well as the file name. After it is
done whatever the virus author intended, the virus runs the actual
program that the user meant to run. Since no physical modification
of the victim takes place, one must specifically check for such
viruses. Simply looking for changes in files is not enough. There
are only a few viruses that infect in this manner.
Some other viruses attack both master boot record or boot
record of the active partition and program files on the disk. These
viruses are sometimes called multi-partite. It may seem that such
beasts have a better chance to spread; however, they are far less
common in practice. One reason might be that they are more
complicated to program. The more complicated a program is, the
higher the number of bugs it has. Due to serious bugs in the virus
code, they easily reveal their presence. Ironically, simple viruses
like Stoned are quite widespread.
Some viruses try to evade identification by scanners. They
usually encrypt their code with a different encryption key so that
the newly infected file will seem to contain a different virus.
Simple viruses in this category use the same decryption routine in
every instance of the virus, and therefore they are easily caught.
More sophisticated ones add a couple of junk instructions inside
the decryption routine, and rearrange them differently in new
infections. These junk instructions do not have any effect on the
decryption method, but they serve to make it difficult to extract
a simple search string to scan for.
Even more advanced encryptive viruses exist. Some people refer
to these as polymorphic viruses. They use a different
encryption/decryption routine (e.g., by using different
instructions to accomplish the same computation) for each new
instance of the virus, making it extremely difficult to scan for.
Good news is that all these beasts modify other existing executable
code to be able to replicate. They are as easy to detect as their
dumber cousins, just more difficult to name.
2. Any control mechanism that relies on the accuracy or
availability of information (including the mechanism
itself) which is stored on a medium (including RAM) that
is prone to modification by the attacker can be defeated.
Some viruses target the partition or the boot sector of disks.
They may move the original sector contents to another location on
the disk. They usually hook low level disk access routines so if
someone tries to peek at their hiding place, they can present the
original copy of the sector and pretend nothing is modified. They
can also protect themselves by disallowing write access to their
location. This is yet another variation of stealth techniques. The
Brain virus is one such beast that uses similar tricks to evade
detection. These viruses have tremendous flexibility to modify the
system to their advantage since they gain control very early in the
system startup process. The strength of VDS comes from its triple-
pass verification technique that makes it extremely difficult to
hide such a change in the DOS environment.
Researchers categorize viruses in many different ways such as
direct action viruses and so on. This level of detail is not
necessary for our discussion. Whether the virus activates when
another program accesses the disk, or it looks for a target on its
own is beside the point. The beast is spreading all over the disk,
and after getting onto floppy diskettes, it will spread to other
computers. And that is a BIG concern!
3. PC-based local area networks are NOT immune to viral
attacks.
Network connections pose another question by making it easier
for the virus to travel from one location to another. As long as
the user has write access to the programs on a disk, it may be able
to infect it. If the program file happens to be on a file server,
all those that run it may cause the virus to jump to their local
machines. Can you imagine what could happen if the
superuser/supervisor runs an infected program on the LAN by
mistake?
It is a misconception that PC-based networks are less
susceptible to viruses. The boundaries of information flow are not
always well-defined. Although many popular LAN operating systems
provide various control mechanisms that can be used to implement
robust anti-viral measures, many sites do not take advantage of
them. If the users allow each other to access one another's
directories, for example, the risk of infection is very high, and
the rate of infection may be even higher compared to spread via
floppy diskettes. Since many common viruses employ "ill-behaved"
programming techniques, they cannot infect network file servers
even when write/modify access is granted. This does not eliminate
the risk by any means, but simply makes it less evident.
4. Electronic bulletin boards do not necessarily contain
infected software.
There have been some extreme remarks about the dangers of
downloading software from electronic bulletin boards (BBS). In
actuality, the sysop (the person that maintains the BBS) has to
take pains to ensure his board is free of malicious software to be
able to keep a good reputation. On the other hand, there are
supposedly some hacker BBSs that provide viruses, even in source
code. Your chance of bumping into one of these is very little.
Please do not be afraid to explore what the BBSs in your area have
to offer. Many useful programs such as VDS are available for the
cost of a local phone call. There is no need to be paranoid about
the situation, just be aware of the possibilities. It is always a
good idea to get software only from well-recognized bulletin boards
such as the ones maintained by user groups. It is a good practice
to search the programs you download for known viruses.
5. Write-protected floppy diskettes cannot be infected by
a virus as long as the floppy drive is working correctly.
This is why you should always place a write-protect tab on all
original diskettes if they are not already protected. The spread of
viruses can be effectively slowed down by careful use of
appropriate control mechanisms. Some people recommend using dark
matt write-protect tabs rather than the shiny silver ones; we did
not have any problems with either kind.
VI. PARTITION/BOOT SECTOR INFECTIONS
A. Preliminary information
It seems that there is much confusion about the difference
between a partition sector (Master Boot Record is another name for
it) and a boot sector among many PC users. If you are already
familiar with the organization of a typical hard disk, you can skip
the rest of this section; otherwise, please read on.
The very first sector on a typical hard disk stores the
partition information for the disk. Within the partition sector, a
64-byte area contains enough information to locate all physical
partitions on the disk, and shows which partition is the active
partition. The active partition is used to boot the computer. There
can be four physical partitions on a disk. The partition sector is
located outside of any partition boundaries and has enough code to
determine the active partition, load the boot sector in that
partition and transfer control to it. The code in the partition
sector does not care which operating system it is loading. In fact,
one reason for having partitions is to allow coexistence of
multiple operating systems on one hard disk. FDISK program that
comes with DOS is used to manipulate the partition table.
Each partition has a boot sector. The boot sector holds
certain information about that partition (in an area called BIOS
Parameter Block or BPB) such as the number of sectors and number of
FATs (file allocation table). In the case of the active partition,
it also contains some code that loads the operating system. DOS
partitions can be either primary or extended (extended partitions
were added in DOS 3.3). The extended partition can be further
subdivided into logical drives.
FORMAT program with the /S option is used to make the active
DOS partition bootable by setting up the necessary operating system
files. FORMAT must also be run on every partition to be able store
files. This is called high-level formatting. Floppy disks do not
have partition sectors, they only have a boot sector. That's one
reason low-level and high-level formatting is combined into one
procedure in the case of floppy diskettes.
Since the partition sector contains vital information to
access the drive, it is important that this information be
protected. If you lose your partition sector, you might have to
wipe out the MBR, and repartition the disk. Of course, this
operation would make all files inaccessible. Fortunately, it is
hardly ever necessary to take such an extreme step. If you have VDS
in place, you should be able to restore your partition table
information easily.
Nevertheless, if you cannot reconstruct the partition table so
that you can backup your files, or if you just want to get rid of
a virus residing in the MBR, you should know a few important facts.
1. A complete low level format of the entire hard disk is
not necessary. Using a low level disk editor, you can write zeroes
over the contents of the MBR and repartition the disk. This will
get rid of the virus. In fact, certain types of hard drives, namely
IDE, are not designed to be low level formatted by the end-user.
Low level format is necessary on brand new drives that do not come
pre-formatted from the manufacturer. Getting rid of an MBR virus is
just a matter of removing its code from MBR and putting a fresh
copy of the standard MBR code.
2. FDISK will not put a fresh copy of the MBR code if the
disk is already partitioned; therefore, an MBR virus can survive
repartitioning by standard FDISK. This might surprise you, but it
is a fact so dangerous to ignore. Worse yet, FDISK will destroy the
boot records and FATs of any modified partitions. For example, if
you repartition a drive with exactly the same parameters, you will
still lose access to your files.
*** MS/PC DOS 5.0 includes an improved version of the FDISK
program. It can replace the MBR code only, while leaving
the partition table intact. Unfortunately, the DOS
technical documentation does not mention this capability.
The command is:
FDISK /MBR
3. If the partition table is intact, as is the case in most
infections, you can recover all your data easily. To do this, you
should use a utility like VITALFIX, or do it manually following the
instructions in this document. For details, see the section titled
MANUAL RECOVERY PROCEDURE under HOW TO DEAL WITH VIRUSES.
Following diagram illustrates the organization of a typical
hard disk.
┌───────────────────────────────────┐
│ Master Boot Record │ Sec 1, Cyl 0, Head 0
├───────────────────────────────────┤
│ │
├───────────────────────────────────┤
│ Active Partition Boot Sector │
├───────────────────────────────────┤
│ File Allocation Table 1 (FAT#1) │
├───────────────────────────────────┤ Partition 1
│ File Allocation Table 2 (FAT#2) │
├───────────────────────────────────┤
│ Root Directory │
├───────────────────────────────────┤
│ │
│ Data Area for files │
│ │
├───────────────────────────────────┤
│ Other Partition Boot Sector │
├───────────────────────────────────┤
│ FAT#1 │
├───────────────────────────────────┤
│ FAT#2 │ Partition 2
├───────────────────────────────────┤
│ Root Directory │
├───────────────────────────────────┤
│ │
│ Data Area for files │
│ │
└───────────────────────────────────┘
B. How to recover with CURE option
If the partition table or the boot sector is modified, you can restore
it as follows:
1. Turn off the computer.
2. Place the write-protected VDS emergency diskette in drive A.
3. Turn on the computer.
4. Run REPAIR.BAT.
A:\REPAIR <enter>
VDS will attempt to use the backup copy of the affected area to restore
it. If it detects that the backup copy is also modified, it will abort the
restoration attempt so as not to do more harm than good! The restoration
process involves the partition sector, boot sector on the active partition,
and COMMAND.COM as well as IBMBIO.COM and IBMDOS.COM. VDS considers leaving
the task of restoring the system files to SYS the safest approach.
5. If all goes well, VDS will ask you to remove any floppy diskettes and
press a key to reboot the system. All system areas should pass the
verification tests this time. If they do not, the restoration attempt
was unsuccessful, and a manual recovery is necessary.
C. How to use VITALFIX
VITALFIX is a utility program designed to automate recovery from an MBR
(master boot record) infection.
It can place a fresh copy of MBR code without disturbing the existing
partition table. It can backup an MBR to a file on a floppy diskette. It even
allows you to take a clean MBR from one computer, and a partition table from
an infected one, combine them together and put it back on the infected system,
effectively replacing the viral code while leaving the partition table intact.
This is possible since most computers partitioned using the same FDISK
program will contain similar code, and differ only in the contents of their
partition tables.
If you simply let VITALFIX construct an MBR for you, you will have our
MBR code placed on your disk. Since this piece of code has to do "standard"
stuff, there should not be any problems. Please let us know if it does not work
on your system. We have tested it on several IBM computers and compatibles
with a variety of hard disks. It seems to work just fine.
VITALFIX is a menu-driven program. You simply highlight the option you
are interested in and press enter. You could also press the first letter of an
option to activate it. Context-sensitive help is available by pressing the F1
key.
VITALFIX has some interesting features such as the capability to search
for a relocated MBR all over a hard disk and to view the contents of any given
sector. You can also write contents of a file to a sector and vice versa. It
also allows you to edit sectors. Please be very careful when doing any write
operations since a simple mistake could damage your data.
You should always boot the computer from a write-protected, clean
system diskette before using VITALFIX. This will eliminate any memory resident
viruses or programs that may interfere with disk operations. By the way,
VITALFIX can bypass most software-only active monitor anti-viral programs
that try to control disk access!
VII. HOW TO DEAL WITH VIRUSES
A. Recommended Guidelines
When dealing with viruses, there are a few rules to go by, all of which
make good common sense. These rules are:
1. If there is a possibility that your hard drive is infected, do not use a
floppy diskette on that computer unless it is write-protected.
Rationale: If you did NOT coldboot the computer from a clean
floppy diskette, the virus may be active in memory and
it can infect the floppy diskettes used in the drives.
This is, after all, a common way for spreading
infections among computers.
2. Do not boot a hard drive system from a floppy diskette unless you are
positive that the floppy is virus-free.
Rationale: This follows from Rule #1. The virus can infect the
hard disk. The result is a hard disk that passes on the
virus to other floppies. The floppy can carry a boot
sector virus even if it was not formatted to be a
system diskette, because all DOS diskettes have a
boot sector.
3. If your PC is connected to a local area network, and you detect that
your system may be infected by a virus, disconnect your PC from the
network immediately.
Rationale: The purpose is to isolate the infection in order to
minimize the spread, and reduce the time required to
clean the system. Make sure you know how to
disconnect only your PC. Pulling out the wrong cable
may bring down a whole subsection of the network.
4. If you receive new programs (especially games), test them on a machine
that does not have valuable data before installing these programs on
other computers.
Rationale: This precaution will help prevent the introduction of
new viruses into the system. Even shrink-wrapped
software may contain a virus. There have been some
unfortunate incidents where major computer companies
shipped infected diskettes to their customers by
mistake.
5. If you do not feel technically competent to handle a virus attack,
contact someone who can help.
Rationale: Dealing with viruses can be a very tricky business.
You cannot afford to leave a single infected file on
your system. It takes only one infected program to
continue the spread of the virus.
6. When you want to backup your hard disk, boot from a write-protected,
clean floppy diskette. Preferably use file-by-file backup mode instead
of image backup.
Rationale: Some viruses remain active in memory and interfere
with disk access. They are likely to corrupt the
backup diskettes. File-by-file mode gives you a
better chance to recover damaged backups.
7. Write protect all original diskettes as well as their backups before
using them.
Rationale: This would prevent infection of your program
diskettes should they be used in an infected system.
Besides, during recovery you can be assured that the
originals are not corrupted.
8. Before using programs that came on floppy diskettes, search them for
known viruses.
Rationale: Many companies are just beginning to realize the
threat the viruses pose. They may or may not have a
virus-free program development environment. It is
better not to take any chances and check the
diskettes yourself. If you find a write-protected,
original program diskette to be infected, first
contact the company that sold you the disk and
complain.
B. Manual Recovery Procedure
This section assumes you have a standard system partitioned using FDISK,
and running MS/PC DOS 3.0 or above. If you have a hard drive with a non-
standard geometry, then the following procedure may be more complicated.
Exercise caution during this recovery procedure, since you could
accidentally render your disk unusable. If you can access the hard disk
after booting the computer from a floppy diskette, you should backup all
your data files first.
If you know or suspect that your hard drive is infected by a virus, you
can attempt to restore it by carefully verifying that each point in the
execution path during start-up is clean. To do that, you need to know what
points are in the execution path. Refer to the diagram below.
First get a write-protected (preferably the original) DOS system
diskette. You cannot format a diskette on a possibly infected system, and be
positive that the diskette does not get infected. Some viruses stay in memory
and infect the floppy diskettes whenever they are accessed. Turn the
computer OFF. Place the system diskette in drive A: and close the drive door.
Turn the computer ON. Never trust that a warm-boot (Ctrl-Alt-Del) will get rid
of a memory resident virus. Some viruses are known to fake a warm-boot. Worse
yet, some vicious viruses activate their damage routine when you press Ctrl-
Alt-Del combination. If you turn the computer OFF, then the contents of random
access memory will be erased, flushing everything including a virus.
The purpose of the following procedure is to clean the system areas of
a computer with a hard disk so that it is safe to boot from the hard disk.
Verification of other program files are not considered in this discussion.
Recommended recovery procedure for infected program files is to replace them
with the originals. A utility program such as VDSFSCAN that searches for
infected programs can speed up the process. Virus cleaning utilities are NOT
recommended. If you know or suspect that a program is infected, copy over the
original from the distribution diskette. This is the cleanest and the safest
approach.
To attempt recovery, you will need a low level disk editor that allows
you to read and write any sector on the disk. If you feel intimidated by
manipulating your disk in this manner, please do not attempt a manual recovery
without the help of a friend who has experience performing this type of an
operation. Nevertheless, VITALFIX program in the VDS 2.10 package is very
handy to do such low level manipulations.
On a standard PC, the startup sequence looks like the following:
Stage 1.
point A point B
╔════════════╗ ┌────────────┐
║ ROM ║ │ Master │
║ ║ │ Boot │
║ BIOS ║ │ Record │
║ ║ │ Code │
║ CODE ║ │ [0, 0, 1] │
║ ║ │ │
║ ║ │ │
╚════════════╝ └────────────┘
Stage 2.
point C point D point E
┌────────────┐ ┌───────────┐ ┌────────────┐
│ Boot │ │ IBMBIO.COM│ │ IBMDOS.COM │
│ Record │ │ or │ │ or │
│ Code in │ │ IO.SYS │ │ MSDOS.SYS │
│ Active │ │ │ │ │
│ Partition │ │ │ │ │
│ │ │ │ │ │
└────────────┘ └───────────┘ └────────────┘
point F point G point H
┌────────────┐ ┌─────────────┐ ┌───────────────┐
│ Device │ │ COMMAND.COM │ │ Programs │
│ Drivers │ │ │ │ in │
│ in │ │ │ │ AUTOEXEC.BAT │
│ CONFIG.SYS │ │ │ │ │
│ │ │ │ │ │
│ │ │ │ │ │
│ │ │ │ │ │
└────────────┘ └─────────────┘ └───────────────┘
Stage 1 is independent of any operating system. Point A is implemented
in hardware and is not modifiable (shadow/flash RAM leaves a shadow of doubt),
therefore cannot be infected. At point B, the code resides on the hard disk
(head 0, cylinder 0, sector 1). The purpose of point B is to provide a mechanism
to load different operating systems. You can have your disk partitioned so
that one partition is for DOS, while another one is for some other operating
system. By marking one of them as active in the partition table (located within
the Master Boot Record), you can control which operating system will load upon
bootup. The code in MBR simply locates the active partition by examining the
partition table, loads the code in the boot sector of that partition and
transfers control to it. The MBR is attacked by viruses such as Stoned since
it provides very early control of the system. More sophisticated viruses can
easily redirect BIOS disk access routines (the vector addresses reside in the
first 1024 bytes of RAM and are modifiable) to evade detection.
Stage 2 is where a specific operating system comes into play. In the case
of DOS, the code at point C loads the first system file (IBMBIO.COM) and
transfers control to it. After initializing the DOS kernel, IBMBIO.COM
processes the CONFIG.SYS file. Each device driver listed in CONFIG.SYS is
loaded and initialized. IBMDOS.COM is also loaded at this time. At point G,
COMMAND.COM gets control and processes AUTOEXEC.BAT file if there is one.
Except for point A, all other points in the execution path are modifiable.
You must assume that any modifiable code is prone to viral infections. During
recovery you must assume the worst case and handle each point as if it is
infected by a virus. You must also remember that a higher point depends on a
lower point. In other words, if you do not clean point B, you cannot guarantee
that point C will not be compromised afterwards.
The MBR code (point B) is easily replaceable. The key item at point B is
the partition table which contains vital information to access the disk. If the
hard disk is accessible after booting from a floppy (e.g., DIR C: works fine),
then there is a good chance the partition table is intact. You should
immediately extract the partition table information (64 bytes total) from the
first sector on head 0, cylinder 0 and store it in a file on a floppy diskette.
If you have a similar (uninfected) computer with a hard disk, you should make
a copy of its MBR in a file. The next step is to combine the partition table that
you stored away with the clean MBR you have taken from the uninfected
computer. The result is an uninfected MBR that can be used to replace the
infected one. Make sure when you combine the two pieces, you are editing at
the correct offset within the MBR sector. Our VITALFIX utility automates this
whole process (except swapping diskettes, of course!). Here is a simple picture
to clear things up:
Master Boot Record
Sector 1 on head 0, cylinder 0
partition table
1 447 512
╔═════════════════╤═══╤═══╤══╤═══╤══════╗
║ │ │ │ │ │ AA ║
║ MBR Code │ 1 │ 2 │ 3│ 4 │ 55 ║
║ │ │ │ │ │ ║
╚═════════════════╧═══╧═══╧══╧═══╧══════╝
Note that the partition table has four entries making it possible to
divide the disk into four distinct areas. The MBR code is the same on most PCs
as long as you use the same FDISK program. The partition table depends on how
the disk is set up. The last two bytes must be AA55 by convention.
Some viruses simply relocate the whole MBR sector to another location
on the disk, then place their code in sector 1, head 0, cylinder 0. They also
redirect disk access routines and present the original copy when someone
attempts to access the MBR. This is an evasion technique used by certain
viruses that target the MBR. Since you have booted from a clean floppy
diskette, you do not have to worry about this. If you can find the original MBR
on the disk (usually relocated to another sector on head 0, cylinder 0), then
you could simply put it back to sector 1, head 0, cylinder 0 to recover. For
example, one variant of Stoned virus places the original MBR to sector 7, head
0, cylinder 0. In that case, follow the procedure outlined above.
Once you restore the MBR, you can move on to point C and verify it. The
easiest way to accomplish that is to use SYS.COM program included with DOS.
SYS will put a fresh copy of the boot sector code as well as replacing
IBMBIO.COM and IBMDOS.COM. This operation cleans points C, D, and E (three birds
with one stone).
Point F involves verifying each device driver listed in the CONFIG.SYS
file. Unless you need a device driver to access the disk due to non-standard
geometry, you can simply delete (or rename) CONFIG.SYS. Otherwise, you have
to copy the device drivers from the original diskettes to the hard disk. Make
sure you are copying over the ones that CONFIG.SYS activates.
Point G is easy to take care of by copying COMMAND.COM from the original
DOS diskette to the hard disk. If you have a shell statement in CONFIG.SYS that
specifies a different command interpreter, then make sure you replace that
one with the original.
Point H can be handled by deleting (or renaming) AUTOEXEC.BAT since it is
not required.
Now the system is ready to be booted from the hard disk without
reactivating a possible virus. Of course, the first time you run an infected
program, everything you have cleaned so far might get reinfected. Did we say
dealing with viruses can be a little tricky?
VIII. REGISTRATION and PRICES
A. How to get VDS?
You can obtain a registered copy of VDS by writing to the following
address:
Attn: Tarkan Yetiser
VDS Advanced Research Group
P.O. Box 9393
Baltimore, MD 21228
Please fill out the order form included with this documentation. As soon
as we receive your purchase order, you will be sent the VDS package on a 5.25"
and 3.5" DSDD diskette, a printed manual, and a registration number to be used
in all future dealings. Processing may take up to two weeks. If you discover
that the distribution diskette you have received is damaged, you can ask for
a new diskette (to be shipped free of charge) within two weeks after you
receive VDS.
If you do not want to wait, you can leave a message on the answering
machine at (410) 247-7117 giving your name (s-p-e-l-l your last name please)
and address. For registered versions, you should also spell out the name that
should be placed inside the program. This name will be displayed at the bottom
of the screen to identify the licensee. We prefer that you pay by C.O.D (cash
on delivery), by money order or by sending in the payment with your order. If
your company policy does not allow C.O.D. purchases, please leave a brief
message with your phone number and someone will contact you for a more
suitable arrangement. Please note that this phone number is NOT intended for
technical support.
A portion of all proceeds from the sale of VDS 2.10 will be donated to
help the homeless people in Baltimore City.
B. Trial version
A trial version of VDS is available on several electronic bulletin board
systems across the continental U.S., and can be downloaded free of charge. You
can also obtain a copy of the trial version on a diskette from the developers
by calling (410) 247-7117 and leaving your name and address. Please specify
that you would like to get the TRIAL version. If specified properly, we will ship
you the trial version only for $7 US anywhere within the continental U.S.A. If
you later choose to become a registered VDS user, we will credit this $7
towards the payment for the registered version. You are encouraged to
upload the trial version of VDS to the electronic bulletin board systems in
your area. Please upload the documentation as well as the programs. You can
also give your friends a trial copy of VDS.
The trial version has the same user interface and operational
characteristics (with certain limitations) as the registered version. Here are
some of the limitations of the trial version:
* Supports a single DOS partition (C: drive)
* No integrity-checking device driver is generated
* There is a promotional opening screen only during installation
* It does not have a line showing the licensee's name/serial number
* No printed manual is included
C. Complimentary version
Complimentary version of VDS is made available to certain individuals
as a courtesy of VDS Advanced Research Group. These individuals include
product reviewers for well-known computer magazines, managers of anti-viral
research labs and others we recognize as people who have contributed to the
fight against viruses. Complimentary version cannot and need not be ordered.
D. Personal version
Personal version costs $25 US plus the cost of shipping. You may make
backup copies of the distribution diskette you received for your own use only.
You may NOT upload any part of it to bulletin board systems. You may, however,
use VDS on as many computers as you personally own.
E. Academic version
Academic institutions can obtain VDS for $300 US plus the cost of
shipping to be used on up to 1000 computers that they own. VDS can be
installed on each additional computer for 10 cents per machine. Students,
faculty and staff can install VDS on their home computers at no extra charge.
We encourage administrators to promote virus awareness on campus to be able
to contain the spread of infections.
F. Non-profit & charity version
If you are a charitable non-profit organization, you are allowed to
install VDS on all computers you own at no extra charge besides the $25 US
registration fee and the cost of shipping. Please send us a brief message
stating the nature of your activities and needs from a computing standpoint.
G. Business version
Purchases for use in business and government environments are subject
to separate conditions as follows:
Organizations, including federal, state and local government agencies,
and companies are required to obtain a business version of VDS. Business
version costs:
$25 US for each computer
or
$300 US for up to 100 computers, and $1 US for each additional
computer.
You are given a 30-day trial period to evaluate the suitability of VDS
to your needs. If you are not satisfied with its operation in any way or not
convinced that VDS can provide the kind of protection you think is necessary
for your computers, you can simply return it for a refund.
Special Offer:
We recognize that most virus infections in business environments are
introduced by contaminated employee diskettes. Today many people use
their home PCs to finish up some work and usually bring the diskettes
they used at home to work. In recognition of this fact, the developers
of VDS are glad to extend the business version site license to cover
employees' home computers at NO EXTRA CHARGE. This coverage does not
include outside consultants hired on a temporary basis.
We encourage managers to ask their employees to install VDS on their
home computers if they are going to exchange diskettes between the PCs
at work and the one(s) at home. Such a policy would serve to reduce the
risk of introducing viruses to the company PCs as well as to promote
virus awareness among the employees.
At one site, the manager had the company employees to answer the
VDS Risk Analysis Test and asked those who scored high (meaning higher
risk) to install VDS on their home computers. Employees were also
encouraged to report any infections they have discovered without any
fear of reproach. We strongly encourage other managers to display such
positive attitude.
IX. TECHNICAL SUPPORT
A. How to contact the developers
The best way to get in touch with the developers of VDS for technical
assistance, or to order a customized version of VDS is by U.S. mail. You can
write to the following address stating your complaints, requests, and
questions:
Attn: Tarkan Yetiser
VDS Advanced Research Group
P.O. Box 9393
Baltimore, MD 21228
You should allow about two weeks to receive an answer, though it may
take much less time in most cases.
B. How to get VDS on the Internet
If you have FTP (file transfer protocol) access to Internet sites, you
can download a copy of the trial version of VDS from various anonymous-FTP
sites for free. Following are Internet addresses to such sites:
address: 128.252.135.4
subdir: mirrors\msdos\trojan-pro
address: 129.109.1.207
subdir: anonymous\pub\virus\pc
address: 130.160.4.7
subdir: pub/ibm-antivirus
address: 192.88.110.20
subdir: PD1:<MSDOS.TROJAN-PRO>
Example session:
ftp> FTP 128.252.135.4
.....
....
User Name: ANONYMOUS
Password : GUEST
.....
.....
ftp> CD MIRRORS\MSDOS\TROJAN-PRO
ftp> BINARY
ftp> GET VDS210T.ZIP
.....
.....
ftp> BYE
C. Upgrades & bug fixes
When VDS is upgraded, or there have been major bug fixes, all registered
users will be notified, and may ask for the latest version only for the cost of
shipping and handling. The first user who reports a major bug will receive a
free personal copy of VDS as soon as the problem is corrected. This rewarding
scheme applies only to the personal version of VDS.