Re: [vox-tech] Re: [vox] Linux viruses?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [vox-tech] Re: [vox] Linux viruses?
On 2004.06.15 14:43, Jeff Newmiller wrote:
On Tue, 15 Jun 2004, Micah J. Cowan wrote:
Here is an example of such bad code (see also my post on the topic at
it's very brief):
> On Tue, Jun 15, 2004 at 09:32:39AM -0700, Jeff Newmiller wrote:
> > On Mon, 14 Jun 2004, Micah J. Cowan wrote:
> > [...]
> > > I have also felt that the very low market-share of Mac OS (in
> > > comparison to Winblows) simply kept the attention of virus-
> > > of it.
> > I used to be a Mac-phile back in Mac128 and MacPlus days.
> So was I.
> > I used to
> > collect lots of Mac software off of USENET binary distributions
> > newsgroups. Virus problems were much worse in that OS than under
> > because with code stored in the structured Resource Fork, adding
> > pre-execution code was relatively easy.
> I don't see how that made it more easy than to add code to a DOS
> executable, and remembering from those days, I'm surprised to hear
> say it was much worse than for DOS: my recollections are somewhat
I thought the grammatical construction "that OS" followed by "than
DOS" would have made my meaning clear. Anyway, you apparently _did_
misunderstand me... DOS executables don't have structured resource
with relocatable code all over the place, so infecting DOS executables
required some tricky code alterations, and there wasn't much memory to
The Macintosh system had system calls that allowed one to very easily
manipulate the resource fork of any file, adding and removing resources.
Given a resource type (MENU) and a resource number (145), there was a
system call that would find the resource on disk, load the resource into
memory, and return a pointer to that chunk of memory. All done in a very
standardized way. And there was another call which did the reverse. All
in a very standardized way.
The operating system stored a lot of important things in the resource
fork of its own files - the System file (which contained most of the OS
code) was stored entirely in the resource fork, and the System file's
resource fork was a part of the "resource chain" for every running
The resources were well formatted. It was well known, for example, how to
read and edit MENU resources (which defined the items on a menu) or WIND
resources (which defined the sizes, and titles of windows of resources),
and where certain pieces of data belonged in these resources.
In MENU and WIND resources (as well as a few others), one of the data
fields was a resource number for a code resource that could be used to
customize how the menu or window was drawn. For example, in the MENU
resource, one could specify that resource 145 was to be used to draw the
menu. And the system knew that when a MENU asked it to load #145, that it
needed to load MDEF resource 145. (There was a standard MDEF resource
that most programs used to draw their menus, so the programmers didn't
have to relearn from scratch - it resided in the System file.)
All of this was very automatic. When your program specified that MENU
#243 needs to be on the menu bar, the system would load MENU #243, and
whatever MDEF it asked for. The next time the user would click the menu,
forcing it to draw itself, the MDEF would execute.
How would this work for a virus? Supposing this were an MDEF virus (a
virus that lived in an MDEF resource)
The virus is distributed in some kind infected application (maybe it
starts off life in a trojan horse). The user clicks the menu, and the
MDEF virus runs. The MDEF virus says to itself "I'm running. I'm know
that I always live in MDEF #145", so it uses the generic resource manager
system calls to load MDEF #145 into memory. It then proceeds to find
another unsusptecting file (usually an application program) to infect. It
opens the file, uses the generic resource manager calls to save that
piece of memory into MDEF #145 in the new file. Then it loads up all of
the MENU resources in that file and changes them so that they will use
the infected MDEF #145 to draw themselves. It closes the file because
it's done infecting that file. Presto: a new program has been infected.
This is easier than DOS, where you'd need to deal with the whole
executable. The virus would need to find its own code (which would
probably be living at a relatively random place in the file) - one would
need to then read the virus, find a file, and write the virus to a
location in the new executable, without breaking that executable. This
took a knowledge of assembly language and machine language that Macintosh
viruses did not need.
Despite all this, the only Macintosh virus I ever saw in the wild was
MerryXmas, a HyperCard virus which had a completely different attack
vector. Yes, folks, when the news came out that a Microsoft product was
the first product that could spread viruses in *documents* rather than
executables, I already knew that it wasn't unique. HyperCard viruses had
already been spreading for in HyperCard stacks years.
Despite all this, the viruses that spread today are *much* less crafty
than anything you needed to do on the Mac or DOS.
I usually have a GPG digital signature included as an attachment.
See http://www.gnupg.org/ for info about these digital signatures.
My key was last signed 10/14/2003. If you use GPG *please* see me about
signing the key. ***** My computer can't give you viruses by email. ***
Description: PGP signature
vox-tech mailing list