| Severity | * |
| Aka | |
| Additive version | v1.0 |
| Additive author | John Dalgliesh |
| Download Additive | MacBinary or BinHex |
CODE9811 infects only applications (type 'APPL'). It does this by making an invisible copy of the application under a different name (consisting of uppercase letters) in the same folder. The original application contains only the virus in its CODE resources, and a large number of other resources of weird types (the same number of types as in the original application). I assume it does this to evade some antivirus program (I know not which). The real application is given a new random creator, so opening one if its document doesn't launch it by accident.
During infection, the original application is left alone and the virus file is built under the encrypted name (all uppercase letters, but arrived at by transforming the original name). Then when it's done it swaps the contents of the two files by means of a seldom-used call (I've never used it anyway - FSpExchangeFiles). This is also presumably to avoid detection by watchdog antivirus programs (I don't have any so I don't know if it works :)
When an infected application is launched, the virus first checks to see if it was launched by double-clicking a file. If so, it displays a message similar to one displayed by the Finder: 'Some files couldn't be opened from within the Finder. Try opening them from within their respective application.' and quits.
If there weren't any files to open, it next scans for antivirus programs, attempting to delete any that it finds. It scans based on the creator of the file - first in the root directory of the volume which it was launched from, then in the current Control Panels, Extensions, and System folders. It deletes files it determines are antivirus related using FSpExchangeFiles with an empty file. The Control Panels and Extensions folders are scanned recursively; the root directory and System folder are not.
Then it gets on with the actual infecting of other applications - first it picks a volume to scan through a complicated mechanism understood only to its author. (It always seemed to choose my RAM Disk for some reason :) It then performs a partial recursive scan of the volume looking for applications ('APPL''s) to infect. When it gets to a folder there is a 50-50 chance it will explore it or skip it. It determines that an application is infected by the presence of a TEXT resource ID 8650. It also skips invisible applications, so you don't end up with a chain of infections.
Finally it gets on with its payload, which is quite harmless. It draws 'worms' all over the screen - little yellow dots that move and leave behind a black trail (eating away at the screen) After a while the worms can get trapped inside one of three rectangles in the centre of the screen - these rectangles for the shape of a big pi. The worms get trapped when they fall into one of the rectangles. Trapped worms leave behind red trails, so little by little the pi is exposed (This bit is quite good actually ... but it would have been better if the worms could move between rectangles :). After another little while a message appears above the pi: 'You have been hacked by the Praetorians!' with smaller text pi's on either side. After this appears (or maybe earlier - I wasn't looking too closely) if you press the command key it restarts your computer.
It displays its payload on a Monday (with 25% chance) or on August 22nd (also 25% chance). If it doesn't do the worms, then it gets on with the business of launching the application: It renames the invisible file to be the same name as the original with a space appended. Then it launches the almost-correctly named application (so the right name appears in the menu bar), waits for it to launch, then re-renames it back to the same uppercase letters and exits. If it runs into problems (such as the invisible application not being there) it just displays a message 'Out of memory!' and exits.
And that's it. I didn't go into the infection in great detail, because it does lots of really weird stuff with counting resources and adding padding onto data forks, and as it doesn't effect the recoverability of the application, I am perfectly happy to be ignorant of the details :)
The CODE9811 Additive was developed before, after, in between and alongside Agax, so the story is long and complicated and not very interesting. The testing, however, was actually quite ... interesting ... for me, because I only had one computer to do it on (a PowerBook), and no backup system software/etc. So I'm sure you'll believe that I was pretty confident that it worked before I tried it out :)
Writing the Additive was actually quite easy, because the virus is a completely standard C program - and it even has meaningful (MacsBug) debugging symbols in it!
Just as a diversion, if you have an infected application and you want to see the bit with the worms, then make the following changes to CODE resource 1. (you should still be able to repair it, but I haven't tried it so make sure it's not an important app!)
| Offset | Change From | Change To | Why |
|---|---|---|---|
| 0C74 | 661E | 4E71 | Every day not just Monday |
| 0C8C | 6F06 | 4E71 | 100% of the time not 25% |
| 0F76 | 4E56 | 4E75 | Don't infect anything |
| 27C0 | 4E56 | 4E75 | Don't delete AV programs |
Now when you run the application, you get to see the worms make the pi (when you press the command key you will be restarted, so don't have other programs running). You will have to make sure Defender isn't checking resource forks or launched applications or it won't let you run it.
Thanks to Tomas Risberg for introducing me to this virus.
None that I know of.
Back to Additive index
Back to Agax home page
Last updated 15/1/1999