JHSangster@DOCKMASTER.ARPA (10/30/89)
Bob McCabe of the University of Guelph wrote (27 Oct) "it struck me that it should be possible to work out a scheme by which any program could check itself at load time for infection..." This is quite true, and in fact there is at least one commercial anti-virus product out there which implements this idea. (There may well be others.) The one I have noticed is VACCINATE PLUS, by Computer Integrity Corp. of Boulder Colorado. Along with several other anti-viral tools, this product includes an "INSTALL" utility which "vaccinates" the boot track and all executables on the disk. "Vaccination" consists of appending a cryptographic "seal" checking module (smaller than a typical virus!) and patching the load module header so that this module executes first, then passes control to the original application program if the program is "clean", otherwise halting and issuing a warning message. According to Larry Martin of Computer Integrity Corp., the resulting protection is entirely transparent to the end user, i.e. no keystrokes are required, you just run a program in the normal way, and it runs normally unless the file has been infected, in which case it issues the warning and returns control to DOS. Computer Integrity Corp. can be reached by phone at (303) 449-7377 (FAX number is 449-7477). Their address is PO Box 17721, Boulder CO 80308. (I have no commercial connection with this company.) Regarding the specific scheme Bob McCabe described, i.e. computing a CRC on a program and then encrypting it, it is fairly well known that since the CRC process is linear over the binary field (commonly called "GF(2)" by algebraists), it is little more than a high school algebra exercise to make your desired changes to the program, then make a few more bits' worth of additional changes (determined by simple linear algebra over GF(2)) which restore the CRC bits to their former value so that they will still perfectly match the bits recovered from the encrypted CRC -- thus defeating the protection scheme. The only trick, in an executable program, is to set up the code so that the additional bits you have to diddle to restore the CRC do not adversely affect execution, e.g. include a branch around them or whatever suits your fancy. The basic idea is OK, but you need to use a "one-way" hash function, rather than something readily invertible like a linear CRC. See Dorothy Denning's book or any of a number of recent articles for ideas on better hash functions, or use one of the "chained" modes of the DES which have been proposed for detecting data alterations. The key (so to speak) property that is needed is that it must be difficult to construct a second message or in this case computer program with the same value for the hashing function's output. - -John Sangster SPHINX Technologies, Incorporated (617) 235-8801 P.O. Box 81287 Wellesley Hills, MA 02181