l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
February 3: Social gathering
Next Installfest:
Latest News:
Jan. 2: Happy new year! LUGOD turns 16!
Page last updated:
2004 Jun 18 00:41

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
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:

> 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- writers
> > > 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 you
> say it was much worse than for DOS: my recollections are somewhat
> different.

I thought the grammatical construction "that OS" followed by "than under
DOS" would have made my meaning clear. Anyway, you apparently _did_
misunderstand me... DOS executables don't have structured resource forks
with relocatable code all over the place, so infecting DOS executables
required some tricky code alterations, and there wasn't much memory to
"hide" in.
Here is an example of such bad code (see also my post on the topic at http://apple.slashdot.org/comments.pl?sid=103394&cid=8810110, although it's very brief):

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 application.

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. ***

Attachment: pgp00007.pgp
Description: PGP signature

vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
EDGE Tech Corp.
For donating some give-aways for our meetings.