FUNPIV4.CVP 911020 Viral code "association" The simplest way for a viral program to avoid the detection that results from modifying the code of an existing program is not to modify the original program. This is an elementary solution, but would seem to have the drawback that, unless you do change the file in some way, the virus will never be called. There is a "solution" to this problem, and (if I may be allowed some enthusiasm for the concept, if not the reprehensible act) a rather elegant one at that. In a given situation, computers may be presented with a number of possible courses of action. The action taken first is decided by pre-programmed precedence. A number of programs may have very similar names, leading to potential confusion about which one is to be run in a given invocation. In the case of MS-DOS, for example, SET.COM, SET.EXE and SET.BAT are all "executable" files. In the normal course of events, any one could be invoked by giving the command "SET". If all three files exist, which one is to be run? The precedence of program invocation under MS-DOS is that .COM files are first, .EXE second and .BAT last. If three files of the same name do exist, this does not imply that all three will be run in that sequence, but rather that giving the command "SET" will always invoke only the SET.COM file. A certain class of viral programs; known variously as "companion", "spawning" or "precedence" viri; use this feature of the operating system. They "infect" a file with an .EXE extension simply by creating another file with the same name, but a .COM extension. Thus the .COM file is always executed in place of the original .EXE file. The original file remains unchanged, and no manner of "change detection" will tell you any different. (In order to further avoid detection the viral file will generally end with a very specific "call" to the original program, and the viral program has the "hidden" attribute set. In the Macintosh and other GUI operating systems, it is possible for a virus to take precendence by "overlaying" an existing icon with another which is either transparent or identical to the first.) Fortunately, companion viri are by no means perfect. For one thing, they are limited to those programs which are "lower" in the order of precedence. For another, the "hidden" attribute is relatively easy to overcome (particularly in MS-DOS), and an alphabetical listing of files will quickly turn up the anomaly of identical names. Of the antiviral packages tested so far, no change detector alerts to duplicate names, although many may alert the user by asking the user to "validate" a file that has been in use for some time. It will probably not be long, however, before this is a common feature. copyright Robert M. Slade, 1991 FUNPIV4.CVP 911020