dhesi@bsu-cs.bsu.edu (Rahul Dhesi) (03/20/89)
HOW TO PROTECT YOUR MS-DOS MICROCOMPUTER FROM VIRUSES
My method is simple, and guarantees that when my system boots there is
no virus active. It doesn't guarantee that a virus won't get activated
later when I execute a user program.
1. Always boot from a floppy disk. Keep this floppy disk write-
protected. A virus can do *absolutely nothing* to override a
write-protect tab on a floppy disk unless the drive is defective. On
the boot disk, have a clean copy of the operating system copied from
your original MS-DOS distribution disk. My CONFIG.SYS file on the
floppy looks contains this line:
shell = c:\COMMAND.COM c:\ /e:2000 /p
This tells MS-DOS to always load the command interpreter from drive C:
from now on, so that after the boot is completed, I won't need the boot
disk in drive A: any more. (It also increases the available
environment space at the same time, something you probably need to do
anyway.) This didn't work properly with MS-DOS 2.x, but it does work
with MS-DOS 3.x.
2. In autoexec.bat on drive A:, I have lines like this:
c:
bincmp /COMMAND.COM /bin/XXXXX.COM
The first line changes the current drive to C:. The second runs a
program that does a straight byte-by-byte comparison of the files
/COMMAND.COM and /bin/XXXXX.COM (which is just an extra copy of
COMMAND.COM) and reports any discrepancy. It takes but an instant.
(By the way, I have changed the names to "bincmp" and "/bin/XXXXX.COM"
so no virus author can recognize them easily and write a virus to
attack them. Even if somebody did, I would know by simply checking to
make sure XXXXX.COM had not changed relative to COMMAND.COM on the boot
disk.)
So long as the boot disk and COMMAND.COM on drive C: are not corrupted,
there is no virus active at boot time. I don't care about the system
files (IBMDOS.COM and IBMBIO.COM) on drive C: because they are not used
at all.
If COMMAND.COM ever changes, bincmp will report an error unless the
virus was smart enough to figure out which the file /bin/XXXXX.COM was
and changed it identically, or if it was smart enough to figure out
which the bincmp program was and change that. This is very, very
unlikely.
Keeping the system immune to a virus *after* you boot is harder, since
you may execute programs that have a virus attached to them. But if I
ever suspect something fishy is active in memory I simply have to
switch the system off and back on and I know it's not in memory any
more.
P.S. I set my switchar to -, so I can use / in pathnames. If you
don't do this, just use \ instead in pathnames.
--
Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi
ARPA: dhesi@bsu-cs.bsu.edu