Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!swrinde!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!netnews.upenn.edu!vax1.cc.lehigh.edu!cert.sei.cmu.edu!krvw
From: mike@pyrite.SOM.CWRU.Edu (Michael Kerner)
Newsgroups: comp.virus
Subject: Re: Hypercard Antiviral Script? (Mac)
Message-ID: <0006.9106261903.AA01188@ubu.cert.sei.cmu.edu>
Date: 26 Jun 91 01:01:06 GMT
Sender: Virus Discussion List <VIRUS-L@LEHIIBM1>
Lines: 26
Approved: krvw@sei.cmu.edu

I agree that with do's it becomes harder to insure that you catch a
virus, but I also think that it would be relatively easy to spawn out
(e.g. if the virus writer came up with his or her own encryption
method and used the stack script with do's to unencrypt the scripts)
and check fields and so forth for the necessary SETs.  I hadn't
thought about your idea before, but it is clever and does cloud the
issue some more.  What can make it even harder is if the commands to
be DOne are in a file which is also encrypted, and the stack first
unencrypts the files then uses the code in the files and in the fields
to unencrypt the other scripts that must be run.  My biggest concern,
though, is that there will also be a resource lurking in a stack whose
name and type and contents, obviously, can be changed to disguise them
by the virus calling a code resource that it has attached to itself
and thus fooling everyone, including the GateKeeper-like module of
SAM.  Why some virus hack hasn't done this yet is beyond me.  The
virus could be coded to encrypt itself on some date or time parameter
and need the system date or some similar mechanism to untie itself,
thereby making detection pretty difficult at best.  The detection
program would then have to look for the decoding resource, which may
also be obscured by making it look like something else.

My head is spinning from all the possibilities.  I'm just glad I don't
have a PC and have to tolerate all their virus problems.  To think
this all started on a Mac.

Mike