Path: utzoo!attcan!uunet!lll-winken!lll-ncis!helios.ee.lbl.gov!pasteur!ucbvax!dewey.soe.berkeley.edu!oster
From: oster@dewey.soe.berkeley.edu (David Phillip Oster)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Suggestion for virus prevention
Keywords: CODE resource virus detection
Message-ID: <27491@ucbvax.BERKELEY.EDU>
Date: 12 Jan 89 03:06:03 GMT
References: <1272@viscous.sco.COM> <3614@tekig4.TEK.COM>
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster)
Organization: School of Education, UC-Berkeley
Lines: 29

In article <3614@tekig4.TEK.COM> bradn@tekig4.TEK.COM (Bradford Needham) writes:
>In fact, I recently added such code to my latest project (in Lightspeed C).
>The code has a table of the program's expected CODE resources and their
>sizes.  On startup, the program compares the size and Resource ID of
>each available CODE resource against the numbers in the table.  Any
>differences cause a dialog to appear, saying (basically) "This
>application may be infected by a virus.  Here's the CODE resource that
>looks funny."

Suggestions:

(o).  Compute a checksum also. (just treat the handle as a short **,
	and sum it.)

(o). Use a small tool application to create the data resource, rather than
doing it by hand.

(o). Allow a "magic number" checksum like, your initials, so you don't
need to run the utility each time.

(o) Use the same code at run time to see if your application has corrupted
itself by a wild store into its own code segment.  (I discovered that in
color quickdraw, a mal-formed color table can make DrawPicture() scribble
on the application heap using this technique.)


--- David Phillip Oster            --"When we replace the mouse with a pen,
Arpa: oster@dewey.soe.berkeley.edu --3 button mouse fans will need saxophone
Uucp: {uwvax,decvax}!ucbvax!oster%dewey.soe.berkeley.edu --lessons." - Gasee