padgett%tccslr.dnet@mmc.com (A. Padgett Peterson) (06/28/91)
Allright, enough already. So there was a conflict between two SCAN programs that caused a "false positive" when one was run immediately following another. This is nothing new to the anti-virus industry, a few months ago two products much closer related than Vir-X and whatever the other one was consistantly reported the "12-Tricks" when run one after the other. Until recently when memory scanning became de-rigeur, and thank goodness it did, no-one bothered to clean memory following a scan. Remember the Prodigy STAGE.DAT controversy a few months ago ? It all started when someone scanned the disks before installing the *P* upgrade and discovered a host of virus names and strings inside the .DAT file. Why ? My thought is that *P* needed to create a contiguous fixed-size file on disk and did it the simplest way possible: by just creating a giant memory buffer (without putting anything in it) and copying it to disk to create the STAGE.DAT file. Whatever happened to be in memory at the time was just swept along. Since a scanner had just been run that left all of the strings in memory, this became STAGE.DAT. Now clearing free memory is trivial, one easy way would be for a scanner to clear memory before loading, but then if a virus was present a) the system would probably crash and b) you would not get a virus report. I fully expect the next generation of anti-virus tools to be able to disconnect a virus from memory when found (if it can identify it, it should be able to remove it and at least determine if it is active or not). On the subject of encryption, I agree with Ross, a trivial one is sufficient to avoid false positives at least until signatures reach a significant portion of the number of ten-byte signatures - on the close order of 10^24 - which should take a while. To keep them encrypted at all times except when individually used would cause an extreme preformance loss for something that is already slow. Meanwhile, the real key piece of information seems to have been missed - - why the signatures were still in memory. When the second scanner loaded, it should have overwritten the RAM Ross was using therefore, for this to happen, Ross's code, when expanded in memory, had to be longer than the subsequent program. (why there probably have not been more "false positives" rather than any deliberate avoidance). I suspect that the "virus" string found was near the end of the expanded search string list and the list followed the executable code. Consequently, there may be an easier way than wiping memory - in a program you have a choice as to where buffers are placed. If the decrypted strings were kept in a buffer area at the front of the program and followed by the executable code that (hopefully) does not match anyone else's viral signatures, any other scanner that follows should overwrite all the strings before starting. Since when loading "high" a quick way to lock up a machine is to use expanding buffers beyond the file size, these concepts should also be considered by any memory resident routine. Just some thoughts, Padgett Somewhere west of Orlando ps Life is a learning process, when one stops, so does the other. - app