Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!mailrus!uflorida!ukma!rutgers!apple!well!odawa
From: odawa@well.UUCP (Michael Odawa)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Suggestion for virus prevention
Keywords: CODE resource virus detection
Message-ID: <10330@well.UUCP>
Date: 12 Jan 89 22:50:48 GMT
References: <1272@viscous.sco.COM> <3614@tekig4.TEK.COM> <27491@ucbvax.BERKELEY.EDU>
Reply-To: odawa@well.UUCP (Michael Odawa)
Organization: Simple Software, Mill Valley, CA
Lines: 48

In article <1272@viscous.sco.COM> jamesm@sco.COM (James M. Moore) writes:
>Would having programs... check their CODE resources 
>...help prevent the spread of the current strain of viruses?


Yes, the method will work, with certain reservations.  This is the same
anti-viral technique that the Software Development Council and its
regional organizations (SEF, Mass Software Council, Washington Software
Assn., etc.) have devised for our members.

You should check not only for uninvited CODEs, but also nVIRs and Hpat's
and other potentially executeable resources.

One reservation is that everyone should use a slightly different coding
technique, giving their product a special twist, so that a virus cannot
defeat all programs' integrity checks at once.

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."

This is a great addition to our techniques, and a perfect example of the
innovation we are trying to encourage.

We also recommend that your program refuse to continue running (i.e., that
you ExitToShell() after notifying the user) if its integrity has been 
compromised.

A second reservation is that there are certain viruses in circulation that
infect system software but not applications.  This technique, when only
applied to applications, cannot protect against system viruses.

A third reservation is that, since the virus war can be escalated
infinitely, it would be theoretically possible to devise a virus that
didn't detectably alter executeable resources.  

However, creating such a virus would be very difficult.  To do so would 
take not only programming skills, but a very malicious motivation. 
People of that bent belong in jail.

Michael Odawa
President, Software Development Council
odawa@well.uucp