jpd@eecs.nwu.edu (Phil Draughon (ACNS)) (04/18/88)
My colleague Bob Hablutzel got a copy of the Scores virus last
Thursday and disassembled it, and I've been studying and testing
it ever since. So far I've reverse-engineered about half the code
and have a thorough understanding of how it works. This note is a
preliminary report on what I know so far, after four days of
research. It also outlines plans for a disinfectant program.
The virus is definitely targeted against applications with
signatures VULT and ERIC. I don't know if any applications with
these signatures exist or are planned to be released.
The virus infects your system folder when you run an infected
program.
The virus lies dormant for two days after your system folder is
first infected. After two, four, and seven days various parts
wake up and begin doing their dirty work.
Two days after the initial infection the virus begins to spread to
other applications. I haven't completely finished figuring out
this mechanism, but it appears that only applications that are
actually run are candidates for infection.
After four days the second part of the virus wakes up. It begins
to watch for the VULT and ERIC applications. Whenever VULT or
ERIC is run it bombs after 25 minutes of use. If you don't have a
debugger installed you'll get a system bomb with ID=12. If you
have MacsBug installed you'll get a user break.
After seven days the third part of the virus wakes up. Whenever
VULT is run the virus waits for 15 minutes, then causes any
attempt to write a disk file to bomb. If you don't do any writes
for another 10 minutes the application will bomb anyway, as
described in the previous paragraph. There's also more code to
force a bomb after 45 minutes, but I can't see any way that this
code can be reached, given the forced bomb after 25 minutes.
The virus identifies VULT and ERIC by checking to see if the
application contains any resources of type VULT or ERIC.
Applications with signatures VULT and ERIC normally contain these
resources, but other applications normally don't.
I verified the behaviour of the virus by using ResEdit to add
empty resources of types VULT and ERIC to the TeachText
application. TeachText bombed as described above on an infected
system, even though TeachText itself was not infected! While
running my experiments I was in ResEdit on the infected system and
heard the disk whir. Sure enough, ResEdit was infected. I've
been running on an infected system with an infected ResEdit for
three days. I reset the system clock to fool the various parts of
the virus into thinking it was time for them to wake up. The
Finder has also become infected. ResEdit, Finder, and the rest of
the system seem to be functioning normally. Only my version of
TeachText modified to look like VULT or ERIC has been affected by
the virus.
If you repeat any of these experiments be very careful to isolate
the virus. I'm using a separate dual floppy SE to perform my
experiments, and I've carefully labelled and isolated all the
floppies I'm using. My main machine is an SE with a hard drive,
where I have MPW and my other tools installed. It's OK to look at
infected files on the main machine (e.g. with ResEqual, DumpCode,
etc.), but don't run any infected applications on the main machine
- that's how it installs itself and spreads. Children should not
attempt this without adult supervision :-)
An infected application contains an extra CODE resource of size
7026, numbered two higher than the previous highest numbered CODE
resource. Bytes 16-23 of CODE resource number 0 are changed to
the following:
0008 3F3C nnnn A9F0
where nnnn is the number of the new CODE resource.
You can repair an infected application by replacing bytes 16-23 of
CODE 0 by bytes 2-9 of CODE nnnn, then deleting CODE nnnn. I've
tried this using ResEdit on an infected version of itself, and it
works. The MPW utility ResEqual reports that the result is
identical to the original uninfected version.
The virus creates two new invisible files named Desktop (type
INIT) and Scores (type RDEV) in your system folder, and adds
resources to the files System, Note Pad File, and Scrapbook File.
Note Pad File and Scrapbook File are created if they don't already
exist. Note Pad File is changed to type INIT, and Scrapbook File
is changed to type RDEV. Both of these files normally have file
type ZSYS. The icons for these two files change from the usual
little Macintosh to the generic plain document icon. Checking
your system folder for this change is the easiest way to detect
that you're infected.
Copies of the following five resources are created:
Type ID Size Files
----- ----- ----- -------------------------------------
INIT 6 772 System, Note Pad File, Scrapbook File
INIT 10 1020 System, Desktop, Scores
INIT 17 480 System, Scrapbook File
atpl 128 2410 System, Desktop, Scores
DATA -4001 7026 System, Desktop, Scores
A disinfectant program would have to repair all infected
applications and clean up the system folder, undoing the damage
described above. I don't yet know exactly which files can be
infected, but I know for sure that Finder (file type FNDR) can get
infected, and that applications (file type APPL) can get infected.
For safest results the disinfectant should examine and disinfect
the resource forks of all the files on the disk. I recommend the
following algorithm:
Scan the entire file hierarchy on the disk, and for each file on
the disk check it's resource fork. Delete any and all resources
whose type, ID, and size match the table above. Delete all files
whose resorce forks become empty after this operation. If the
resource fork's highest numbered CODE resource is numbered two
more than the next highest numbered CODE resource, and if it's
size is 7026, then patch the CODE 0 resource as described above,
and delete the highest numbered CODE resource. Also examine all
files named Note Pad File and Scrapbook File. If their file type
is INIT or RDEV, change it to ZSYS.
I'm fairly confident that a disinfectant program implemented using
the algorithm above would sucessfully eradicate the virus from a
disk, restore all applications to their original uninfected state,
and not harm any non-viral software on the disk. It should work
even on disks with multiple infected system folders. I also
believe that it should work even if run on an infected system, and
even if the disinfectant program becomes infected itself! There's
a small chance that it could delete too many resources, and hence
damage some other application, but that's a small price to pay for
a clean system.
Getting rid of a virus is tricky, even with a disinfectant
program. The disinfectant program should be placed on a floppy
disk along with a system folder. Make a backup copy of this disk.
The machine should be booted using the startup disk you just made,
and then the disinfectant should be run on all the hard drives and
floppies in your collection, including the backup copy of the
startup disk you just made. Don't run any other programs or boot
from any other disks while disinfecting - you might get
reinfected. When you're all done, reboot from some other
(disinfected) disk and immediately erase the startup disk you used
to do the disinfecting, which may be (and probably is) infected
itself. This should absolutely, positively get rid of all traces
of the virus. The backup disk you made and disinfected should
contain an uninfected copy of the disinfectant program in case you
need to use it again.
There are at least two red herrings in the virus. It uses a
resource of type 'atpl', which is usually some sort of AppleTalk
resource. As far as I can tell, however, the virus does not
attempt to spread itself over networks. The 'atpl' resource is
used for something else entirely. This is not a bug. Also, the
virus creates the file Desktop in your system folder. This is
done on purpose. It is not a failed attempt to modify the
Finder's Desktop file in the root directory. The file is used by
the virus, and has nothing to do with the Finder.
I don't know why the virus seems to cause reported problems with
MacDraw, printing, etc. Perhaps it's a memory problem - the virus
permanently allocates 16,874 bytes of memory at system startup
(four blocks in the system heap of sizes 772, 40, 8, and 334, and
one bock at BufPtr of size 15360). I've only found one possible
bug in the virus code, and it looks pretty harmless. The code is
very sophisticated, however, and I can easily understand how I
might have overlooked a bug, or how it might interact in strange
unintended ways with other applications and parts of the system.
When we've finished completely cracking this virus we'll probably
distribute another report. I've posted these preliminary results
now to get the information out as quickly as possible. We also
hope to write the disinfectant program, if someone else doesn't
write it first.
I've decided not to distribute detailed information on how this
virus works. I'll distribute detailed technical information about
what it does and how to get rid of it, but not internal details.
This was a very difficult decision to make, because normally I
firmly believe in the enormous benifit of the free exchange of
code and information. The Scores virus is a very interesting and
complicated piece of code, I've learned a great deal about the Mac
by studying it, and I'm sure other people could learn a great deal
from it too. But I don't want to teach twisted minds how to write
these incredibly nasty bits of code. If I write the disinfectant
program, however, I will distribute its source, because I do want
to teach untwisted minds how to get rid of them.
So please don't bombard me with requests for more information.
You may be the nicest, most honest, incredibly important person,
but I won't tell you how it works. I'll make only two exceptions,
and that's for a very few of my colleagues at Northwestern
University, and for qualified representatives of Apple Computer.
Thanks to Howard Upchurch for giving us a copy of the virus, and
to Bob Hablutzel for helping me crack it.
John Norstad
Northwestern University
Academic Computing and Network Services
2129 Sheridan Road
Evanston, IL 60208
Bitnet: JLN@NUACC
Internet: JLN@NUACC.ACNS.NWU.EDU
Monday morning, April 18, 1988.