Apr 90 Mousehole
Volume Number: 6
Issue Number: 4
Column Tag: Mousehole Report
Trojan Horses 
By Larry Nedry, Mousehole BBS
From : Arlen
Re: Trojan Horse Alert!
We have detected a new (to us) Macintosh trojan at the University of Alberta. Two
different strains have been identified. Both are dangerous.
The first strain is embedded in a program called ‘Mosaic’, type=APPL and
Creator=????. When launched, it immediately destroys the directories of all available
physically unlocked hard and floppy disks, including the one it resides on. The attacked
disks are renamed ‘Gotcha!’.
Unmounted but available SCSI hard disks are mounted and destroyed by the trojan. The
files of hard disks are usually recoverable with one of the available commercial file
utility programs, but often the data file names are lost. Files on floppy diskettes
usually lose their Type and Creator codes as well, making recovery a non-trivial
procedure.
The second strain was detected in a Public Domain program called ‘FontFinder’,
Type=APPL and Creator=BNBW. It has a trigger date of 10 Feb 90. Before that date,
the application simply displays a list of the fonts and point sizes in the system file.
On or after the trigger date, the trojan is invoked and disks are attacked as for the first
strain. The trojan can be triggered by setting forward the Mac system clock.
Because the second strain has a latency period during which it is nondestructive, it is
much more likely,to be widespread. Both trojans were originally downloaded from a
local Macintosh BBS here in Edmonton. The second version was part of a Stuffit!
archive named ‘FontFinder.sit’ that also contained documentation and the source code
for the FontFinder application. The source code does NOT contain the source code for the
trojan.
A quick and dirty search string for VirusDetective (v/3.01 or later) has been
developed that appears to detect the trojan engine in both strains. It is:
Resource CODE & ID = 1 & Data 44656174685472616B
Note that this will detect the currently known versions, but may or may not detect
mutated versions of this trojan.
There is some evidence that these trojans are related based on preliminary
investigation of the code. It has been speculated that the second is an ‘improved’
version of the first (more sophisticated), or that the two versions were developed by
two individual perpetrators working with the same trojan engine. There easily could
be more versions either circulating or being developed.
This appears to be the first deliberately destructive malicious code that targets on the
Macintosh. There is some suspicion that one or both have been developed locally. There
is also the possibility that one or both were uploaded from a BBS in the Seattle,
Washington area.
Our investigation is far from complete, but it is continuing. Please warn your Mac
users to make proper back-ups on a regular basis, be suspicious of all software not
received from a trusted source until tested, and generally, to practice ‘safe
computing’.
There was also a third trojan, less destructive than the other two called Virus Info,
which is an application (this should make one suspicious immediately), that was
supposed to give information on several of the recent viruses, including samples of
code used in these viruses. Instead as soon as you run the application it trashes your
Finder, and then quits causing a crash because there is no Finder to exit to. There was
no other apparent damage done by this trojan
I wasn’t sure if any one here had seen this note. I figured on a board this populated
somebody would post it before I got around to it, but I decided to err on the side of
redundancy. It seems the vandals are catching up with the Mac.
It’s disappointing. I almost didn’t upload the notice, hoping that if we all ignored the
cretins they’d go away. But I know they won’t. And in the meantime a lot of innocents
would get hurt.
I find it frustrating that our computers and the networks we’ve built to link the
country together (nets made both of silicon and of flesh) must be fouled by this
pestilence. I wish they’d take their paint cans and spray their crud somewhere else.
Strike that. No, I don’t. I don’t want to wish them on anyone else. I want them gone,
permanently and irrevocably. But how??
From: Jmoreno
Re: Submenus
I’m writing a program where sub-menu needs to change depending on the top-most
window. How can I switch the sub-menu back and forth when ever there is a activate
event? Any and all suggestion would be GREATLY suggested, I’m going crazy (there are
those who say I’ve BEEN crazy for years now but ignore them).
From: Jumpcut
Re: Submenus
Can’t you use the SetItemCmd call? Just wait for an activate event in your event loop
and switch between the two menus as needed. (You’ll have to load them both from the
resource file when you start.)
From: Jmoreno
Re: Submenus
I’d thought of tha; the problem is my app doesn’t limit the number of windows, and I’d
like for each window/file to have it’s own menu, so how do I get a menuID for each
that’s in the proper range, and don’t I have to worry about DA’s adding their own