jalden@eleazar.dartmouth.edu (Joshua M. Alden) (06/06/91)
Awhile back people mentioned a Hypercard script to deal with the
recent Hypercard virus. Then someone mentioned that their script
wasn't reliable, and someone else said he'd write a new one, and that
was the last I've heard of it.
Has anyone got a reliable script? Or at least a script which
works in known circumstances?
- -Josh.
- --
Josh Alden, Consultant, Dartmouth Computing | #61 Hidden Lane
Private mail: Joshua.Alden@dartmouth.edu | West Lebanon, NH 03784-9720
Virus mail: Virus.Info@dartmouth.edu | (603) 643-2840EIVERSO@cms.cc.wayne.edu (06/13/91)
Your best defense is locking your home stack, or constantly searching your home stack for script modifications. You can try editing the script of a stack before opening it, but the virus might be in any object in the new stack. Even though you can check the params of a set command for the word "script", no unlocked stack will be safe until Apple prevents using the set command in a end to HyperCard I'd elaborate, but wouldn't feel right about explaining how to commit sabotage. - --Eric
mike@pyrite.SOM.CWRU.Edu (Michael Kerner) (06/13/91)
I said I was going to rewrite my scripts to handle new trojans/viri, however I am trying to consider some options. The main problem is that there is no way to catch the parameters of the SET function in HC 2.1. So, while I play with different virus scenarios (i.e. writing ones that I think will do certain things, using certain HC resources, I want to try and find some common link between them. The answer, then, will be unable to intercept and stop infection, but will have to work beforehand. The problem with this is that a field of all stacks that have been checked needs to be kept, and everytime that a stack is opened, the field must be examined to see if this particular stack has been checked. However, the problem with that is that existing checked stacks may have been infected and will thus escape detection. So, while my solution appears to be the simplest (i.e. check all stacks to begin with then keep a running list), the time spent by the user seems to be very long. So, the story on this is: unless there seems to be some need/desire emerge for a new stack/utility to do this work, I'm moving slowly. As I said before, if anyone else feels like beating me to the punch with a solution of their own, feel free - but don't you DARE charge $$ for it. Mikey. Mac Admin WSOM CSG CWRU mike@pyrite.som.cwru.edu
EIVERSO@cms.cc.wayne.edu (06/14/91)
Mike writes... - ------------------------------------------------------------------ The main problem is that there is no way to catch the parameters of the SET function in HC 2.1. - ----------------------------------------------------------------- I write... According to the release notes, you can catch the parameters of a Set in HC 2.1 But that doesn't matter since a Send to HyperCard is untrappable. Mike later writes... - ----------------------------------------------------------------- The problem with this is that a field of all stacks that have been checked needs to be kept, and everytime that a stack is opened, the field must be examined to see if this particular stack has been checked. - ------------------------------------------------------------------ I write... Unfortunately if the virus stack traps for the OpenStack Message it becomes harder to know when a new stack has been opened. You could have the user induce the checking proceedure, but then it would be too late and your Home Stack script could be wiped out or other worse things could happen by then. Mike again.... - -------------------------------------------------------------------- As I said before, if anyone else feels like beating me to the punch with a solution of their own, feel free - but don't you DARE charge $$ for it. - -------------------------------------------------------------------- Me again... The only solution seems to be, check your Home Stack periodicaly, or lock it, and always make backups of important stacks. Apple MUST prevent using a Set command within a Send to HyperCard or no stack will be safe!! Sounds scary doesn't it? >Mikey. >Mac Admin >WSOM CSG >CWRU >mike@pyrite.som.cwru.edu and me... - --Eric
mike@pyrite.SOM.CWRU.Edu (Michael Kerner) (06/21/91)
Actually, Eric, you will find that there appears to be a bug in 2.0v2, and you can intercept SETs that are SEND'ed (sorry, but SEN(t)D?)...anyway, having not tried this trick in 2.1, I don't know if it will work...and, as usual, I wouldn't trust the documentation - try looking at the params of the SET command. As far as the rest of this discussion goes, I have been playing with fire & my own viri (for test purposes, folks, so relax...then again, with the couple of times I've been corrected, these critters wouldn't do much harm anyway...) and as long as LockMessages is set, and as long as one checks the script of stack xxx before opening it, it's essentially impossible to infect yourself by opening a stack - ASSUMING YOU CHECK THE SCRIPT OF THE STACK FIRST. The code to scan a stack is essentially the same as the SearchScript code that y'all will find in your HOME stack, only you have to modify it to accept a file name (answer file...everyone remember now?...) anyway, after you do that, the search string is "set the script of". HOWEVER, it is possible that someone has the viri sitting in an XCMD or XFCN which they invoke, so you should also check the resources they have attached to their stack...so you see, it becomes a pain to simply scan the stack script because you also need to scan the resources to be effective. Mike. Mac Admin WSOM CSG CWRU mike@pyrite.som.cwru.edu
bcarter@claven.idbsu.edu (06/24/91)
Greetings, >The code to scan a stack is essentially the same as the SearchScript >code that y'all will find in your HOME stack, only you have to modify >it to accept a file name (answer file...everyone remember now?...) >anyway, after you do that, the search string is "set the script of". >HOWEVER, it is possible that someone has the viri sitting in an XCMD >or XFCN which they invoke, so you should also check the resources they >have attached to their stack...so you see, it becomes a pain to simply >scan the stack script because you also need to scan the resources to >be effective. I doubt that a general scanner for HyperTalk viruses can be created due to the fact that all one has to do is encode the text of the script to be inserted, and make decoding part of the infection process. Using this method along with "do"s you would never see a plain text "set the script of" until it was too late. It wil probably be necessary to do as utilities such as Virex do, and enter specific characteristics of each virus for which to search. This is a tough area, every time someone here comes up with a way of blocking this sort of thing someone else comes up with a way around it. <-> Bruce Carter, Courseware Development Coordinator bcarter@claven.idbsu.edu Boise State University, Boise, ID 83725 duscarte@idbsu.bitnet (This message contains personal opinions only) (208)385-1250@phone
EIVERSO@cms.cc.wayne.edu (06/26/91)
From: mike@pyrite.SOM.CWRU.Edu (Michael Kerner) [stuff deleted]... >and as long as LockMessages is set, and as long as one checks the >script of stack xxx before opening it, it's essentially impossible to >infect yourself by opening a stack - ASSUMING YOU CHECK THE SCRIPT OF >THE STACK FIRST. >The code to scan a stack is essentially the same as the SearchScript >code that y'all will find in your HOME stack, only you have to modify >it to accept a file name (answer file...everyone remember now?...) >anyway, after you do that, the search string is "set the script of". >HOWEVER, it is possible that someone has the viri sitting in an XCMD >or XFCN which they invoke, so you should also check the resources they >have attached to their stack...so you see, it becomes a pain to simply >scan the stack script because you also need to scan the resources to >be effective. Mike, I appreciate what you're about & am not trying to engage in one-upmanship but.... Don't forget that the script could be in any object not just the stack script or an XCMD. Maybe SearchScript checks all objects, I forget. You won't find the string if it's cocantenated--i.e.: on openCard put "set the scr" & "ipt of ..." into virusVariable --search would miss this --other malicious code goes here end openCard Thanks for the advice about being able to check for a "set" within a "send" I will really believe it after I test it, though. If you'd like, I could send you the exact script which I believe can bypass any HC "vaccine". Others need not ask, especially don't contact my ID directly. - --Eric
mike@pyrite.SOM.CWRU.Edu (Michael Kerner) (06/26/91)
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