Shareware 1 2 the Maxx

home *** CD-ROM | disk | FTP | other *** search

/ Shareware 1 2 the Maxx / sw_1.zip / sw_1 / VIRUS / VDS20T.ZIP / VDS.TXT < prev next >

Wrap

Text File | 1992-03-31 | 166KB | 3,196 lines

V D S VIRUS DETECTION SYSTEM version 2.0 Copyright ■ 1992 by VDS Advanced Research Group All Rights Reserved March 1992 Baltimore, MD 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 . . . . . . . . . . . . . . . . . . . . 11 C. Backing up the VDS distribution diskette . . . . . . . 12 D. Preparing the VDS emergency diskette . . . . . . . . . 13 E. Installing VDS on a hard drive . . . . . . . . . . . . 15 F. Testing VDS. . . . . . . . . . . . . . . . . . . . . . 17 1. Test Suite 1 (Simple) . . . . . . . . . . . . . . 18 2. Test Suite 2 (Advanced) . . . . . . . . . . . . . 19 G. How we tested VDS. . . . . . . . . . . . . . . . . . . 21 IV. OPERATION of VDS . . . . . . . . . . . . . . . . . . . . . 22 A. Operational Cycle. . . . . . . . . . . . . . . . . . . 22 B. How does VDS work. . . . . . . . . . . . . . . . . . . 23 C. VDS Device Driver. . . . . . . . . . . . . . . . . . . 25 D. VDSFSCAN . . . . . . . . . . . . . . . . . . . . . . . 31 E. Scenarios and Messages . . . . . . . . . . . . . . . . 33 F. Command Line Options/Flags . . . . . . . . . . . . . . 37 G. Common Questions and Answers . . . . . . . . . . . . . 39 V. VIRUS ATTACK METHODS. . . . . . . . . . . . . . . . . . . . 49 A. Virus defined. . . . . . . . . . . . . . . . . . . . . 49 B. Attack & spread methods. . . . . . . . . . . . . . . . 49 VI. PARTITION/BOOT SECTOR INFECTIONS . . . . . . . . . . . . . 53 A. Preliminary information. . . . . . . . . . . . . . . . 53 B. How to recover with CURE option. . . . . . . . . . . . 56 C. How to use VITALFIX. . . . . . . . . . . . . . . . . . 56 VII. HOW TO DEAL WITH VIRUSES. . . . . . . . . . . . . . . . . 58 A. Recommended Guidelines . . . . . . . . . . . . . . . . 58 B. Manual Recovery Procedure. . . . . . . . . . . . . . . 61 VIII. REGISTRATION and PRICES . . . . . . . . . . . . . . . . 66 A. How to get VDS . . . . . . . . . . . . . . . . . . . . 66 B. Trial version. . . . . . . . . . . . . . . . . . . . . 66 C. Complimentary version. . . . . . . . . . . . . . . . . 67 D. Personal version . . . . . . . . . . . . . . . . . . . 67 E. Academic version . . . . . . . . . . . . . . . . . . . 67 F. Non-profit & charity version . . . . . . . . . . . . . 67 G. Business version . . . . . . . . . . . . . . . . . . . 68 IX. TECHNICAL SUPPORT. . . . . . . . . . . . . . . . . . . . . 69 A. How to contact the developers. . . . . . . . . . . . . 69 B. Upgrades & bug fixes . . . . . . . . . . . . . . . . . 69 C. Phone numbers. . . . . . . . . . . . . . . . . . . . . 69 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 can CAPTURE some 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 all 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. 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. - 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. - 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) How many times did you have to deal with non-virus- related conflicts between programs? A) None B) 1 or more Q-3) Is all your valuable data backed up on at least two sets of storage media? A) Yes B) No Q-4) Have you backed up your data within the last month and verified that you can actually restore it? A) Yes B) No Q-5) Are all your original program diskettes write- protected? A) Yes B) No Q-6) 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-7) Do you know your hard drive type as designated in CMOS? ** This question applies to AT-class computers with battery backup 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 : 0 B: 2 Q-3) A : 0 B: 5 Q-4) A : 0 B: 2 Q-5) A : 0 B: 5 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 - 384K available memory (more if many executable files) - 500K free space on C drive - Less than 1000 executable files per partition - Must be installed and run from C:\VDS20 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 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 verification. 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. * 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 DATA. B. Installing VDS There are four 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 4. Test the operation of VDS 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. WARNING: IT IS EXTREMELY IMPORTANT THAT YOU DO NOT RUN ANY PROGRAMS OFF OF THE HARD DISK DURING INSTALLATION. VDS does 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. - 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 INSTALL.BAT and 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 put a DOS system diskette in drive A: and 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 emergency 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, it will abort installation and warn you. A list of all infected files and the viruses detected will be placed in C:\VDSFOUND.TXT. If all goes well, VDS will copy itself onto the hard disk in C:\VDS20 directory. - VDS will ask you if you would like to create a backup copy of your MBR 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 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 in five seconds. * 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:\VDS20\VDS.EXE -Verify *** VDS should be run from C:\VDS20 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:\VDS20\VDSDEV.DDR *** VDSDEV.DDR should be loaded from C:\VDS20 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. F. Testing VDS After you install VDS, you should test its operation to make sure that it is working properly. We will present a few simple methods to accomplish that. First suite of tests do not require much knowledge about DOS beyond basics, such as creating a directory, deleting a file and so on. The second suite of tests are more sophisticated since they involve manipulating vital areas of the hard drive. If you are not comfortable with using a low level disk editor, and do not know much about a boot sector etc., you should NOT attempt these operations. We have done extensive testing to ensure that VDS operates correctly under most circumstances. Unless you have a non-standard system such as one with a big hard drive partitioned using the Ontrack Disk Manager, you should not have any problems setting up VDS. 1. Test Suite 1 (Simple) We will simulate virus-like behavior by hand to see how VDS reacts. Follow these steps: 1. After installing VDS, create a temporary directory on your C drive. C:\> MD C:\TEMP <enter> 2. Copy a few executable files into C:\TEMP directory. C:\> COPY C:\UTILITY\A*.COM C:\TEMP <enter> C:\> COPY C:\UTILITY\B*.EXE C:\TEMP <enter> *** You should substitute whatever directory you use to keep your utility programs instead of UTILITY as shown above. 3. Now run VDS by rebooting your computer. VDS should go through verification process and at the end tell you that certain files are added. It should then look for known viruses in these files. It should not find any viruses; if it does, you may have a serious problem! You should also find a list of all of these new files in C:\VDS20\CVDSADD.TXT. Make sure VDS has found all the executable files in C:\TEMP directory. Allow VDS to update its database. 4. Now reboot the computer again. This time VDS should not report any additions since it updated the baseline in step 3 above. 5. Delete a few files from C:\TEMP directory and reboot again. 6. VDS should tell you that some files have been deleted. You should also find a list of these files in C:\VDS20\CVDSDEL.TXT. 7. Reboot again. The results should be similar to those in step 4 above. 8. Fire up a low level disk editor and load one of the files in C:\TEMP directory. Modify the file randomly and save the changes. 9. Run VDS to see if it picks up this modification. It should tell you the file is modified (or infected if the time stamp is not modified), and it should look for known viruses. 10. If you answer YES when VDS asks if you would like to override the alarm, VDS will update the baseline to reflect this modification. Next time you should not get an alarm message after update. If you answer NO, VDS will tell you that there are suspicious modifications detected and it will scan the affected file for known viruses. You should find a list of modified files (one in this case) in C:\VDS20\CVDSDANG.TXT. In this case, the baseline will not be updated. This concludes the first test suite. We have established that automatic database maintenance feature is working, newly added files get scanned for viruses, and any simple changes to a program file are detected. 2. Test Suite 2 (Advanced) Now let us present a little more challenge to VDS. Be warned that the following test procedure can render your hard disk unusable if it is not done correctly. If you are a novice computer user, please do NOT attempt this test. It is highly recommended that you backup your data or use a computer that is expendable as far as the data on its hard disk is concerned. Nevertheless, here is how to test some of the other features of VDS: *** These tests can be done with or without the VDS device driver loaded. If it is loaded, then you will get a warning message when necessary. If you chose to halt the computer when a suspicious modification is detected, then you will have to boot from a floppy diskette. 1. Fire up your favorite low level disk editor. Load the boot sector of C drive. Boot sector is located on logical sector 0 of a DOS partition. 2. Modify a few bytes of an ASCII message in the boot sector. Do not modify anything else. Messing up the code or the BPB (BIOS Parameter Block) can be disastrous. Change an error message, for example. Save the changes to the disk. 3. Reboot the computer and run VDS. As VDS is going through system area tests, it should pop up a message box telling you that the boot sector is modified, and it should attempt to restore it from the backup copy it made during installation. It should also show you the contents of the boot sector. After asking you to remove floppy diskettes, VDS should reboot the computer in 5 seconds. If VDSDEV.DDR is in your CONFIG.SYS, it would restore the boot sector before VDS.EXE even gets a chance to look at it! If the device driver restores the boot sector, it will place the modified boot sector in a file named BR.DAT inside the VDS20 directory. 4. This time the boot sector should pass the tests. Now look in the C:\VDS20 directory to see if there is a file named BOOTPOV.BBB or BR.DAT. This file should have the contents of the modified boot sector. Check if it has the changes you have made. 5. You can repeat steps 1 through 4 for the master partition sector (Master Boot Record), which is located on the first sector of track 0, head 0. You should get similar results. Be EXTRA careful with your master partition sector. 6. Fire up your low level disk editor again and load C:\VDS20\VDS.EXE. Modify some messages in the file. Do not modify the code. We are simulating a non-overwriting virus. If the program is crippled, it is just too obvious and the virus reveals its presence easily. 7. Now run VDS to see if it notices the modification to itself. It should tell you that VDS.EXE is modified and should heal itself automatically and reboot the computer in five seconds. If VDSDEV.DDR is in your CONFIG.SYS, it will warn you that VDS.EXE is modified. The VDS device driver does not attempt to recover VDS.EXE. 8. This time VDS.EXE should pass verification. If the self-recovery did not work, VDS will issue a warning and lockup the system. 9. You can repeat steps 6 through 8 for C:\COMMAND.COM. You should get similar results. 10. Also modify a copy of VDS on a diskette and try to install it. It should fail authentication. This concludes the second test suite. We have determined that VDS can detect and undo any changes to the boot/partition sector, COMMAND.COM and itself. This indicates that the VDS recovery module is working properly. The tests above do not, however, establish that VDS can handle more advanced viruses. What we have done merely simulates DUMB virus attacks. Simulating a STEALTH virus by hand is impossible. You need to have an active piece of code that will intercept any attempts to reveal modifications that it has done and undo them on the fly (call it real-time if you like to be fancier). G. How we tested VDS Our tests included live samples of 4096, Fish-6, Whale, NOINT, 512, Tequila, and Int13 viruses as well as quite a few others. If you are not familiar with these names, consider yourself fortunate. These viruses represent a much bigger threat than all of the other DUMB viruses put together! Most people claim that writing a virus is trivial even for an average programmer. That may be true for most viruses; however, some of the stealth viruses are definitely not created by novices. In fact, exploiting fine details of the DOS environment with such aptitude suggests that their creators are slightly more skilled than your average hacker! On the other hand, these people probably need a lot more psychiatric help than your average hacker. If VDS had been just another change detection program, it would not have been worth the effort; there are already so many of them in the market. The acid test that separates VDS from other anti-viral products is STEALTH viruses! When dealing with these viruses, no other product can claim the same level of strength that VDS can. Some products can even further the spread of infection. With the addition of mutation capability and encryption, anti-viral warfare is no longer a trivial practice in pattern matching. Let's face it folks, if you do not have a pattern to search for, and if that is what you rely on, then you are in for BIG trouble. VDS does not use pattern matching to detect the presence of viruses. That comes into play only during identification phase, which is peripheral to the real solution to the problem. We do not claim to be able to recognize every known virus in the world (as some do so falsely). VDS can identify a good many of them. What we claim is that VDS will detect any computer virus in the DOS environment. As soon as a positive detection is established, appropriate steps can be taken to eliminate the intruder. The spread can be controlled, and everyday work can progress without delay. In the long run, the risk factor is reduced and many man-hours of dealing with viruses are saved. VDS is an IS manager's dream come true! 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 cause a warning message, and 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.COM (must be in the ROOT directory of C: drive) and VDS.EXE are backed up in encrypted format to reduce the risk of intentional tampering. The backups will be used if these areas need to be recovered. When VDS is run, it creates a temporary database. It also verifies the integrity of the original database, and 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! VDS will verify the system areas and the executable files. It will generate reports 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 CVDSDANG.TXT, CVDSADD.TXT, CVDSDEL.TXT, CWARNING.TXT (first letter of the file name indicates the drive letter) in the C:\VDS20 directory. These are ASCII text files and can be printed or viewed easily. They should be examined before the next time VDS is run since they may be overwritten. VDS refers to the alterations that do not involve the time/date stamp or set the seconds field to an out-of-range value as INFECTIONS, and others as MODIFICATIONS. Modifications do NOT suggest they are legitimate. The reason for this distinction is that changes to a file will cause DOS to update the time/date stamp of that file. This can be circumvented by manipulating the directory entries directly, as done by some utility programs such as NORTON UTILITIES. Many viruses also manipulate the time/date stamp of the files they infect. They save the original time/date stamp, modify the file, and set the time/date stamp back to its original value (since DOS will update it during modification). 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 will be written to C:\VDSFOUND.TXT 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:\UNIDENT.TXT. 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 all 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 includes an option (SCAN option) to examine all possibly executable files and the system areas such as the partition/boot sector to determine whether a known virus is present. SCAN option is implicit 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 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. 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 4. DOS system files (named IBMBIO.COM and IBMDOS.COM on some systems) 5. C:\VDS20\VDS.EXE 6. C:\VDS20\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 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.0 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. 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:\VDS20\MBR.DAT and if it is BR, the file will be named C:\VDS20\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 data. Technical Details Some people may wonder how we can claim that VDSDEV.DDR 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 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 a fast and 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, 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. 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. Multiple Infections (YES/NO) 2. Scan Drive (Will search boot sectors if the target drive is A:, B:, or C:) 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. 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 that the user 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:\VDS20 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/APPEND before running VDS. Reason: VDS detected that either ASSIGN or APPEND was active. Action: These TSR programs come with DOS and allow users to modify the way DOS and other programs access the file system. Not to cause any conflicts, VDS refuses to run under such circumstances. You should run VDS before either of these programs. 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:\VDS20 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:\VDSFOUND.TXT 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:\UNIDENT.TXT 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 [{-|/} ? | S | I | C | H | T | V] [LCD | M | A | E | W] [D:] [n] D: Drive to process n number of logical drives starting from C Options H(elp), ? explains command line options and flags S(can) this option will search for known viruses on a given logical drive 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 E(rase) infected files will be deleted without prompting for confirmation A(ll) will scan all files for known viruses, false alarms more likely W(hole) will scan files completely, default is partial scan M(ulti) will look for multiple infections 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 SCAN and VERIFY at the same time; but it is acceptable to use SCAN, ERASE, ALL and WHOLE together. If you would like to scan for viruses and delete the infected files on C: drive, type the following: C:\VDS20\VDS.EXE -S -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:\VDSFOUND.TXT. If you press the ESC key during scan, VDS will ask you if you would like to stop 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 version 2.0, which is the one that we distribute publicly. Q - Can I run VDS under MS Windows? A - Not from within Windows. Since VDS requires access to system resources in an unsupervised manner, Windows would conflict with its operation. Think of VDS as an extension to the operating system to provide a virus- aware computing environment. You should run VDS before any other program, preferably from AUTOEXEC.BAT. 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 - No. We are currently working on an OS/2 version. Extensive testing has yet to be done. 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:\VDS20\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 data is very 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 refuse to run 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 or VDS with the SCAN option 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, which is part of the registered version of VDS. This utility automates locating MBR, and even constructing 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 to a floppy 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 twice as fast but less accurate than VERIFY mode (default). During scanning, VDS will operate in TURBO mode unless -W option is specified. When scanning for known viruses, VDS will search a variable amount of data in each file. If -W option is specified, it will search through the whole file. Some anti-viral programs use an offset value where a given pattern should be located if the file is infected. This speeds up the scanning process significantly at the cost of missing some viruses. The major drawback is that by adding a few junk bytes to the viral code, it is easy to fool these programs. VDS never uses offsets. For newly added program files, VDS does a thorough check (i.e. defaults to W option) 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 VDS20 directory. The only exceptions are the VDSFOUND.TXT and UNIDENT.TXT files and decoys which are placed in the root directory, since scanning can be performed without installation and there would be no VDS20 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:\VDS20 directory. 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 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 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. 4. COMMAND.COM recovery did not work. VDS assumes that the command interpreter is named COMMAND.COM and that it is located in the root directory. All verification and recovery is done on C:\COMMAND.COM. You must place it in root directory of C: drive, and everything should work just fine. 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. 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 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 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 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 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 backup copies are encrypted to prevent intentional tampering. 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. 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 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.0 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. We 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 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 511 ╔═════════════════╤═══╤═══╤══╤═══╤══════╗ ║ │ │ │ │ │ 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 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 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" or 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. Please remember to specify the diskette size you prefer; otherwise, we will send you VDS on a 5.25" diskette. Phone orders can be paid only by C.O.D (cash on delivery). 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. Trial version can only be paid by C.O.D. Please note that this phone number is NOT intended for technical support. A portion of all proceeds from the sale of VDS 2.0 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) * 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 * No integrity-checking device driver is generated 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. 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. 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. C. Phone numbers VDS free information/support 800 hotline and fax line will be in service in early May. We are also in the process of setting up a BBS to serve you better. Please accept our apologies for the inconvenience until that time.