Path: utzoo!attcan!uunet!samsung!shadooby!mailrus!ames!ncar!tank!eecae!netnews.upenn.edu!vax1.cc.lehigh.edu!sei.cmu.edu!krvw From: ut-emx!chrisj@cs.utexas.edu (Chris Johnson) Newsgroups: comp.virus Subject: Re: Sophisticated Viruses (Mac) Message-ID: <0001.8911221545.AA12086@hl.sei.cmu.edu> Date: 21 Nov 89 18:26:07 GMT Sender: Virus Discussion List Lines: 67 Approved: krvw@sei.cmu.edu christer@cs.umu.se (Christer Ericson) writes: >First, restoring the traps to their original values isn't that >difficult. These are initialized by the ROM, then there must be a >table from where all initial values are fetched from, right? As I >haven't been writing any viruses lately, I'm not sure if this table is >moving around from ROM version to ROM version, but attaining the start >address of this table for each and every ROM version isn't too >difficult. Also, the virus would of course restore the trap vector >after it's done, so why would there be crashes? Actually, it wouldn't There would be crashes because it's very common for software that patches traps to have interdependencies between its patches, i.e. one patch depends on data discovered and stored for later use by another patch. Removing only a portion of such patches will be likely to kill the machine sooner or later. Even if you remove *all* patches, the machine is still in grave danger since the INIT (or whatever did the patching) may have changed some key characteristics of the machine already - characteristics that it's patches would have isolated other software from while they were installed and operating. Further, restoring traps to their original values is going to remove all of the patches put in place by the System itself - the patches that keep that machine running inspite of bugs in the ROMs, etc. Also, whole portions of the OS and Toolbox will be removed by restoring traps to their initial values (as taken from the ROM) - this will kill the machine for sure. And even if you were to take the status of the trap table at some point early in the boot phase (after the key System patches had been made) and restore it much later (just before the first application is loaded, say) you would still be removing portions of the OS since the portions related to MultiFinder are added *after* (not before) all the INITs are loaded. Again, the machine dies for sure. Even if these changes to the trap table are temporary, the same problems inhere - portions of the OS are fully installed and operating while other portions have been partially or completely lobotomized by restoring their trap table entries to some initial value. Provided there were no inter- dependencies between routines in the OS (not to mention the Toolbox) this might not kill the machine immediately (but it would likely kill it event- ually), but since there *are* such interdependencies (often matched only in their importance by their subtlety), the machine is going to die very quickly. Writing well behaved patches is a black art on the best of days - writing the sort of un-patching patches discussed here would make that "black art" look like a carefree romp in the sunlit countryside. I don't think such patches could be implemented safely, and I don't think anyone clever enough to do so would be wasting his time working on viruses in the first place. >even have to change the trap vectors, it could call the ROM directly, >but I left that to your imagination to figure out (a fruitless >attempt, obviously) since I didn't want to give away freebies to >aspirant virus writers. Some things they'll have to figure out >themselves. > >/Christer All in all, I don't think the techniques dealt with in this discussion are significant simply because there are too many reliability and compatibility problems intrinsically linked to them. For what it's worth, - ----Chris (Johnson) - ----Author of Gatekeeper - ----chrisj@emx.utexas.edu