Path: utzoo!utgpu!watmath!clyde!att!pacbell!ames!oliveb!tymix!antares!jms
From: jms@antares.UUCP (joe smith)
Newsgroups: comp.sys.amiga
Subject: Re: IRQ virus
Summary: can't protect the checksum
Message-ID: <330@antares.UUCP>
Date: 10 Jan 89 08:15:29 GMT
References: <27@snll-arpagw.UUCP> <3243@sugar.uu.net> <28@snll-arpagw.UUCP>
Reply-To: jms@antares.UUCP (joe smith)
Organization: Tymnet QSATS, San Jose CA
Lines: 45

In article <28@snll-arpagw.UUCP> paolucci@snll-arpagw.UUCP (Sam Paolucci) writes:
> 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.
>
>Ideally the checksum should be done by the startup code, and all the hunks
>should be included in the check.
>					-+= SAM =+-

You realize, of course, that the expected checksum has to be stored in the
file.  It has to be where the checksumming routine can find it, to do the
compare.  If the checksumming routine was a standard library routine called
from _main, then it is a trivial task for a virus to start at _main, locate
the checksumming routine, locate the checksum word, and modify it.  Which
means that your checksum protection has been rendered worthless.  Or, the
virus could locate the JSR that calls the checksumming routine and replace
it with a NOP.  Again, disabling the protection.

Here's another monkey-wrench.  When AmigaDOS loads the program, the various
hunks get loaded into noncontiguous memory.  The loader applies 16-bit and
32-bit relocation to words on the hunks that point to other hunks.  This
means that the in-memory copy of the program does not look like the on-disk
copy.  Unless you can locate all words subject to relocation, and have the
checksumming routine cancel the effect of the loader's modifications, you
will not be able to get a consistent checksum out of the im-memory copy.

Although programs are provided with the name of the command that started
them, AmigaDOS does not include the directory name.  This means that you
cannot reliably locate the on-disk copy of the program to check it.  Even
if you search through the path list, a really nasty virus can do all its
dirty work and write out a good copy of the program to RAM: so that it
looks like the program was invoked from an uninfected copy.

The only thing I would trust along these lines would be seperate utility
and checksum list stored on a write-protected disk that watches over the
files I'm concerned about.  One program can be trusted to check another,
but you can't rely a program being able to check itself.

-- 
+----------------------------------------------------------------------------+
| TYMNET:JMS@F29  CA:"POPJ P,"  UUCP:{ames|pyramid}oliveb!tymix!antares!jms  |
| INTERNET:(Real Soon Now)   Amiga Hacker   PHONE:Joe Smith @ (408)922-6220  |
+----------------------------------------------------------------------------+