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