Path: utzoo!attcan!uunet!portal!cup.portal.com!dan-hankins From: dan-hankins@cup.portal.com Newsgroups: comp.sys.amiga Subject: Re: The ultimate fix!!! Message-ID: <9381@cup.portal.com> Date: 24 Sep 88 02:39:51 GMT References: <681@zehntel.UUCP> <3084@hermes.ai.mit.edu> <4197@thorin.cs.unc Organization: The Portal System (TM) Lines: 36 XPortal-User-Id: 1.1001.5361 In article <4320@thorin.cs.unc.edu> bell@unc.cs.unc.edu (Andrew Bell) writes: >It can recognize it, but how much code will it take to change it? If there >are *multiple* bbcs around, the virus will have to account for many of them ... Okay, let's assume you've made it impractical for a virus writer to put his virus in the boot block. This is no deterrent. Any executable file is a potential virus carrier. One such IBM PC virus, called the Jerusalem Virus or JV after the location of its discovery, did just this. The JV would be tacked onto the beginning of an executable file. Whenever someone would run the file, JV would execute first and install itself in one of the system interrupt vectors. From then on, whenever someone would run a program on the infected machine, JV would get control at the system call to load the program, and would modify that file on disk to contain itself, if it could. On a particular Friday the 13th of this year, it would erase all magnetic media on the machine. On all other Friday the 13ths, it would degrade system performance. It was only caught because (a) it always made the executable 1800 bytes bigger, and (b) it didn't check to see if the file it was infecting was already infected. Therefore a frequently run utility would eventually grow too large to be loaded into memory, or the user would run out of disk space for no apparent reason. There are easy ways to avoid (a) and (b). Even with those giveaways, it managed to trash a lot of systems. And it never touched the boot block. Dan Hankins