FUNGEN6.CVP 911101 Change detection A virus has to change *something*. This fact is absolutely fundamental to the operation of computer viral programs, and therefore, in a sense, provides a guaranteed form of virus prevention or detection. If we make a machine that cannot change anything (and the disadvantages of this have been thoroughly discussed) we can prevent infection. If any change made can be detected, then any infection can be detected, although discriminating between an infection and a valid change remains problematic. It is interesting to note that the early antiviral programs, at least the most widely used ones, relied first upon activity monitoring and then signature scanning. Nowadays almost all antiviral programs implement some version of automated change detection. The detection of the first viri, and the ongoing research into new strains, relies almost entirely on "manual" methods of change detection. This method of detection is available to anyone who has a computer and the most basic tools of the operating system. It is, of course, made somewhat easier with the more advanced "utility" programs available on the market, but the best defence remains a thorough knowledge of your computer, and what it is supposed to be doing. A knowledge of what programs are on the computer, and a list of file sizes and creation dates is a simple piece of protection requiring no special programs whatsoever. This one simple tool, however, can provide detection of most file infecting viri. It will even detect "stealth" viri if the computer is booted from a clean system disk before the check is made. DEBUG is provided with every copy of MS-DOS, and can be used to view, and make a copy of, the boot record of every disk. (Partition boot records of hard disks are beyond the reach of DEBUG, but within the reach of F-PBR, from 1.xx versions of FPROT.) Memory maps (and hex dumps of boot sectors) are not easy to read, even for experienced, but non-programming, users. However, it is not necessary that the user understand all the entries in a boot sector or memory map. It is only necessary that the user have a printout of a run of, say, MEM/C in an initially clean state, and then be able to spot a difference in a subsequent run of the program. In reality, of course, most users will not take the time and trouble to check for changes in the system. Most users want a program which will do it for them, and preferably one which will do the checking automatically, and alert them to anything wrong. copyright Robert M. Slade, 1991 FUNGEN6.CVP 911101