🚀 go-pugleaf

> It starts simply enough.  When an infected application is run on a
> new system, the system folder is infected.  Two invisible folders
> are created, one named Desktop and the other Scores (hence the
> name).  Thus the Scores infection gets to start early and go
> "resident".  (INITs of 6, 10 and 17 are created.  This led to later
> problems with other INITs numbered the same way that were mistakenly
> thought to be infected.)

The "Desktop" and "Scores" items are files, not folders. It has been
proposed that semi-sophisticated users with a means of looking at
invisible files would be tricked into thinking that the "Desktop" file
was the Finder's "Desktop" file (the Finder's Desktop file is at the
root level, not in the System folder), and that the "Scores" file
would be dismissed as belonging to some undefined game or another. All
of these files contained enough information to perpetuate the virus,
even if one or more of them was removed.

Scores took advantage of a hole which allowed INIT resources to reside
in invisible files. This hole was closed in System 6.0.3, I believe.
Invisible files are no longer eligible to be executed as control panel
(cdev) or system extension (INIT) files. It is definitely closed in
System 6.0.7 and up.

> The Note Pad and Scrapbook files, if not already present, are
> created.  The file types for these files are changed, as are the
> normal icons.

As well as their contents.

> The virus waits two days before it starts to infect applications. 
> Thus the Scores might almost seem to be an early form of the
> multipartite virus, since it "toggles" between system and
> application files.  However, it is only after the infection has
> entered the system folder that the other activities take place.

The actual infection mechanism of Scores is nearly identical to that
of the nVIR virus: A modified CODE resource installs an INIT; the INIT
modifies further CODE resources in a _Launch trap. One of the INITs is
the vector; the others are the payload. Blocking access to the System
file and disallowing creation of INIT/cdev files without user
permission disables this mechanism.

 --- Joe M.