💾 Archived View for spam.works › mirrors › textfiles › virus › fungen9.cvp captured on 2023-06-16 at 21:02:39.
-=-=-=-=-=-=-
FUNGEN9.CVP 911127
System checking
The measures described in the previous two columns will detect
file infecting viral programs (within limits.) However, a very
large class, or perhaps a number of sub-classes, of viral
programs do not make any changes to program files on the disk.
Boot sector infectors replace or move the "boot program"
resident on almost every disk. Although these viri are
extremely common, surprisingly few "change detectors" bother to
make any check of this area at all. One reason may be that a
number of computers make regular changes to the boot sector for
various purposes.
"Companion" viri, while they are associated with certain
programs, do not make any changes to existing program files at
all. Similar claims can be made for "system" viri, such as the
DIR-II virus, which leaves the file intact, but changes the
directory entry in order that the virus, which "officially" does
not exist on the disk, gets called first.
It is, therefore, necessary to check much more than the size and
image of the individual program files on the disk in order to
detect viral infections. The boot sector (and master/partition
boot record) should be checked, although it is possible that a
certain area should be excluded from checking in the case of
certain computers. A check on the total number of programs, and
names, should also be kept separate from the system directory.
A copy of the directory and file allocation table should also be
kept, especially in regard to program files.
System memory, and the allocation of system interrupts, should
also be checked. This is problematic during normal operations,
as programs tend to use, and sometimes not fully release, areas
of memory and interrupts as they work. Therefore, the best time
to do such checking is at boot time, even before drivers and
programs have loaded from the startup files. (DISKSECURE does
this to great effect. So did F-PROT's F-DRIVER.SYS -- which led
to unfortunate conflicts with MS-DOS 5.0. The security
programmer's lot is not an easy one, with virus writers,
legitimate programs and even operating systems continually
finding new and "interesting" ways to do things.) It is also
possible, however, and quite desirable, to take a "snapshot" of
memory immediately after the startup sequence. This should be
able to detect any changes made to programs involved in the boot
sequence, as well as other changes. (It may also "catch"
program traps which "redirect" a "warm" boot in order to avoid
disk security devices.)
copyright Robert M. Slade, 1991 FUNGEN9.CVP 911127