AntiGax

Download the AntiGax package in either MacBinary II format or BinHex format (these URLs change with each new version - the links here will always get you the latest version)

Information on using AntiGax is contained in the readme contained above. The source code is also included. Please read the readme before using it.

There are a number of other programs which you might want to check out that also offer protection from Graphics Accelerator.

1/10/98: AntiGax v1.1 now available
I haven't had any feedback on applications which v1.0 couldn't repair, so there aren't any bug fixes in v1.1. What it does have is features: An optional log, to record which apps have been repaired, and an examination (as opposed to repairing) function, where infected apps are simply recorded (or the health of an individual app is assessed). Infected applications could then be repaired individually or reinstalled.

4/10/98: GAx Defender
GAx Defender, an extension which scans and repairs applications as you launch them, is now included along with AntiGax in the package above. Now you can stop manually scanning every application you download (this is what you should have been doing :-)

4/10/98: AntiGax v1.2 now available
Version 1.2 fixes some real oversights in the previous version - in particular, control panels and faceless background applications are now checked as well as ordinary applications. (thanks to Jon Mircea). This affects only AntiGax, as GAx Defender checked these originally. The handling of locked applications (and FBAs, etc.) has been improved as well.

10/10/98: AntiGax v1.3/GAx Defender v1.1 now available
AntiGax v1.3 adds a number of major features. These include: a System check, which checks for the virus extension and checks for an infected or damaged System file; file damage checks, which determine whether uninfected files have been damaged by the virus; and the ability to check any given file (instead of just recognized types). See the ReadMe for more information and features.
GAx Defender also now does damage checks, and it checks the System file on startup (for both infection and damage) as well. It will not however attempt to repair your System - that's AntiGax's job.

NEW 13/10/98: GAx Defender v1.1.1 now available
GAx Defender v1.1.1 fixes (I hope!) a problem where it crashed ClarisWorks. It was due to using up too many of ClarisWorks' carefully allotted master pointers, so MoreMasters got called at a bad time. Now we keep no master ptrs to MENUs (after exiting), so if v1.0.1 worked, then so should v1.1.1. It has been included in the AntiGax v1.3 package above, but you can download it separately if you prefer.

So what's the story?

The Findings:
Well, for most of the time it is pretty harmless. It is mostly poorly written (the author seems to think the 'Time' lowmem is in ticks instead of seconds), and it does a whole lot of ... well... generally stupid things.
However, if anyone clicks on a menu of or launches an infected application, between 6:00am and 6:59am, on the 6th or the 12th of the month (either, and any month), it would deliver its payload. And its payload is.... recursively deleting every non-application on the system disk! This will occur if an infected application is running even if it has been prevented from spreading further by, say, putting a folder with the same name as the extension in the extensions folder.

Technicalities:
The virus manifests itself in two forms - one as INIT 33 in the extension '\001Graphics Accelerator' in the extensions folder, and the other as an MDEF resource of ID 1 to 255 in infected applications.

It identifies itself in both cases with the string 'JS' as the 8th and 9th bytes.

When it is called as an INIT, it patches InitMenus, and records the location of the 'AddResource' trap (it uses this to infect applications when this has been patched by a later extension)

When the InitMenus patch is called, it first determines whether the calling application is infected. The target MENU is the first one in the file. It then makes a copy of itself, with the target MENU resource inserted near the start of its code. It replaces every byte in the MENU resource with an 'f'. Then it obfuscates the copy (including the saved resource) by xoring with a random byte. It also changes the registers used by the de-obfuscation code to random values. (Presumably to defeat pattern-matching anti-virus programs, but it doesn't encrypt its data, which has the string 'Graphics Accelerator' in it twice!). It then finds an MDEF ID unused in the current file and saves the copy to that. Then it finds a suitable MENU resource to redirect to itself (suitable = uses std MDEF and has lowest rsrc ID). It sets the MDEF field of this resource to be the ID it has put itself at.

When it is called as an MDEF, it first replaces the resource with all 'f''s with what it should be, then if the time is right, executes its payload. If the time is not right, it makes sure that the extension is in the extensions folder (i.e. that there is an INIT ID 33 in the file 'Graphics Accelerator' ... but if it can't open the file it just aborts)

Well, that pretty much covers it. But there's an interesting story behind why there is no system stuff infected (on my system at least):
InitMenus is called 5 times during startup for me, once before extensions load, to actually initialize menus, twice by the Appearance Extension, and twice by the Finder.

It is called twice by both of these because InitWindows (which they call first) actually calls InitMenus internally.

The Appearance extension contains MDEFs but not any MENUs ... however, it is in a complicated arangement with the system file whereby 'Get1Resource' from it can actually get them from the system file. So MENU resources from the system are actually loaded and modified. The MDEF it tries to add to 'Appearance Extension' fails because it is opened as read-only. And the changes to the system are usually never written out (unless you move sounds around or something) because UpdateResFile/CloseResFile is never called on it (not even when you restart/shutdown)

The Finder (in 8.1 anyway) is also immune, but for a different reason - it can't find a menu to redirect to itself, because all of the Finder MENUs use non-standard MDEFs, and it only redirects those using the std (i.e. 0) MDEF. This may however be different with earlier Finders (not those using FMNUs 'though).

Last updated 13/10/98 02:30 AEST