Path: utzoo!attcan!uunet!lll-winken!ames!mailrus!cornell!uw-beaver!microsoft!w-colinp
From: w-colinp@microsoft.UUCP (Colin Plumb)
Newsgroups: comp.sys.amiga
Subject: Re: IRQ virus
Message-ID: <216@microsoft.UUCP>
Date: 8 Jan 89 05:03:30 GMT
References: <27@snll-arpagw.UUCP>
Reply-To: w-colinp@microsoft.UUCP (Colin Plumb)
Organization: Microsoft Corp., Redmond WA
Lines: 25

In article <27@snll-arpagw.UUCP> paolucci@snll-arpagw.UUCP (Sam Paolucci) writes:
>Why not have the executable generate
>its own checksum when the code is generated, and have this checksum
>reside in the executable itself.  Then when the program is started up
>the first thing it does is compute its checksum and it checks the
>result with the one stored in the code.  If the two match then it
>runs, otherwise it doesn't and a message to that effect could be
>printed out.

The problem with this is that it makes it a lot harder for me to, say,
patch the binary to get rid of a DF1: hard reference or similar thing,
and most importantly, the checksum doesn't get computed until _main
gets called, and the virus patches itself in before that.

Thus, the virus has already done its dirty work, so the warning isn't as
useful, and, if sufficiently clever, it may delete itself from the program
being run so the checksum turns up negative.

You want some external means of certifying a program good.  This is also
why the checksum program should print out the computed checksum, and not
take an argument to comapre it with, even though this makes shell scripts
somewhat more difficult, lest the virus find and patch it to return
"good" at all times.
-- 
	-Colin (uunet!microsof!w-colinp)