V I R A L   I M M U N I T Y   F O R   M S - D O S   S Y S T E M S

Copyright (c) 1988 J. Winslade.  This file may be freely
reproduced and distributed no profit is realized by doing so.

14-MAR-88

This technique is not presented as a 'cure-all', nor does it
suggest that it, or any other technique will render a system
totally immune from all types of virus and trojan attacks.  It is
a technique that, when implemented and used properly, offers a
system and user a certain degree of immunity from some of the
'virus' programs that are making the rounds in the MS-DOS
community as of this date.

I won't get into the story behind it in this article, but several
months ago I had reason to make a 'patched' version of MS-DOS in
which the default command processor was not named COMMAND.COM.
Although I did not realize it at the time, I had created a
version of the operating system that had a certain degree of
natural immunity from many of the current generation of virus
programs.

Many of the virus programs do their dirty work by modifying or
replacing the default command processor, COMMAND.COM.  There are
been programs that will trap attempts to reference that file.
There are techniques for thwarting attempts to modify it, such as
setting it to read-only status, but all of them that I have seen
can be bypassed by any virus writer who is anything but
incompetent.

Memory-resident virus sniffers can protect against overt attempts
to infect a disk, especially by those techniques that have been
studied by their developers, but they cannot handle all cases and
they necessitate the loading of Yet Another memory resident
program at boot time.

Setting the attributes on COMMAND.COM to read-only does offer
some degree of protection, thus causing a write protection
exception when a write to COMMAND.COM is attempted, but any
programmer worth his or her salary knows how to clear a read-only
attribute from within an application.

Performing this modification is relatively simple for the user
who has moderate experience in patching programs with DEBUG or
another debugger or disk editor.  It is not for the rank
beginner.  It is impractical to give step-by-step cookbook
instructions, since the references to the default command
processor name, COMMAND.COM, appear in different locations in the
different versions and releases of PC-DOS / MS-DOS.  If you don't
know what you are doing, find someone who does who can help you.

A modified DOS of this type has been running on a multi-station
LAN for the past four months or so.  It appears to be well
behaved and no apparent problems have been encountered.  All
application software appears to function normally.  (A user
program normally has no business referring to COMMAND.COM.)  As I
stated before, this was not an attempt to immunize the system
from virus programs.  We do not normally run games or public-
domain utilities on the network, so we have no reason to believe
that an attempt at infection has occurred.  After some thought,
we realized that the immunity was a side effect of the earlier
modification.

Four files in the standard PC-DOS / MS-DOS must be modified:

1. IBMBIO.COM (PC-DOS) or IO.SYS (MS-DOS)
2. IBMDOS.COM (PC-DOS) or MSDOS.SYS (MS-DOS)
3. COMMAND.COM
4. FORMAT.COM

To perform the modification, examine the four files listed above
using DEBUG (or whatever) and change ALL references to
COMMAND.COM to the name you have decided to use for your new
command processor.  For example, KOMMAND.COM may be used, and the
modification may be done simply by changing all references within
the four files from COMMAND.COM to KOMMAND.COM.  It is not
imperative that FORMAT.COM is modified.  This is only to allow
FORMAT to place the properly named modified command processor on
new disks that are prepared with the FORMAT/S command.

It is recommended that the modification be performed on a scratch
disk and the system on the scratch disk be thoroughly tested
before the modified files are transferred to the normal system
disk.

After the modified operating system is installed on the target
machine, it should behave normally with the exception that any
reference to COMMAND.COM will fail and any file appearing on the
system under the name of COMMAND.COM will be ignored by the
operating system.

Comments concerning this document may be directed to:

Sysop, DRBBS Technical BBS
(402) 896-3537 (24h, 3-12-24)

Good Day!          JSW