jonah@amos.ling.ucsd.edu (Jonah Stich) (07/20/89)
I wasalking to a friend, (a Mac owner) and the topic of resource forks came up. According to him, it is possible to put a virus into a resource fork, which can then aid it in spreading to other programs (I wasn't sure wether I bought that last bit). Anyways, is this a problem that us humble IIGS users may soon encounter? I hope not.... Jonah
dlyons@Apple.COM (David Lyons) (07/20/89)
In article <6851@sdcsvax.UCSD.Edu> jonah@amos.ling.ucsd.edu (Jonah Stich) writes: >I wasalking to a friend, (a Mac owner) and the topic of resource forks came up. >According to him, it is possible to put a virus into a resource fork, which can >then aid it in spreading to other programs (I wasn't sure wether I bought that >last bit). Anyways, is this a problem that us humble IIGS users may soon >encounter? I hope not.... Easy question. No--on the GS, I don't see how having resource forks makes life any easier for viruses. Why? Because the trick to spreading a virus is putting code someplace where it will be executed. The system already loads and gives control to Init files in the System.Setup directory and desk accessories in the Desk.Accs directory. It does this with the regular data fork; no change with resource forks. So far it seems that GS users have better things to do than write viruses; the only ones I've seen affect ProDOS 8 applications only. --Dave Lyons, Apple Computer, Inc. | DAL Systems AppleLink--Apple Edition: DAVE.LYONS | P.O. Box 875 AppleLink--Personal Edition: Dave Lyons | Cupertino, CA 95015-0875 GEnie: D.LYONS2 or DAVE.LYONS CompuServe: 72177,3233 Internet/BITNET: dlyons@apple.com UUCP: ...!ames!apple!dlyons My opinions are my own, not Apple's.
jonah@amos.ling.ucsd.edu (Jonah Stich) (07/21/89)
In article <33316@apple.Apple.COM> dlyons@Apple.COM (David Lyons) writes: >In article <6851@sdcsvax.UCSD.Edu> jonah@amos.ling.ucsd.edu (Jonah Stich) writes: >So far it seems that GS users have better things to do than write viruses; >the only ones I've seen affect ProDOS 8 applications only. Probably GS users would rather use their fine computer than destroy it. I had a horrible thought after having posted this - maybe it will put some ideas in some jerks head. Gee, I hope not. Wouldn't want to be responsible for something like that :( Jonah
captkidd@athena.mit.edu (Ivan Cavero Belaunde) (07/21/89)
In article <6851@sdcsvax.UCSD.Edu> jonah@amos.ling.ucsd.edu (Jonah Stich) writes: > >I wasalking to a friend, (a Mac owner) and the topic of resource forks came up. >According to him, it is possible to put a virus into a resource fork, which can >then aid it in spreading to other programs (I wasn't sure wether I bought that >last bit). Anyways, is this a problem that us humble IIGS users may soon >encounter? I hope not.... Actually, resource forks should make virus spread harder, not easier. While one can hide a virus in a resource fork, the same can be done in a data fork. The thing is, since all code resides in the resource fork, and modifications to resources go through manager calls, it is possible to intercept these and consequently have a very effective virus defense. People familiar with the Mac will know of the programs Vaccine and GateKeeper, which work in this way by monitoring resource manager calls. Thus, it should be an improvement in the virus situation. -Ivan "American Love. Like coke in green glass bottles ... they don't make it anymore." -Rorschach in _Watchmen_ Internet: captkidd@athena.mit.edu
farrier@Apple.COM (Cary Farrier) (07/21/89)
In article <6851@sdcsvax.UCSD.Edu> jonah@amos.ling.ucsd.edu (Jonah Stich) writes: > >I wasalking to a friend, (a Mac owner) and the topic of resource forks came up. >According to him, it is possible to put a virus into a resource fork, which can >then aid it in spreading to other programs (I wasn't sure wether I bought that >last bit). Anyways, is this a problem that us humble IIGS users may soon >encounter? I hope not.... Resource forks do not lend themselves to the spreading of viruses any more than any other disk structure on a ProDOS disk (so you don't have anything to worry about). Cary Farrier +------------------------------------+ | #include "All.Standard.Disclaimers"| +------------------------------------+
jazzman@claris.com (Sydney R. Polk) (07/22/89)
From article <12865@bloom-beacon.MIT.EDU>, by captkidd@athena.mit.edu (Ivan Cavero Belaunde): > Actually, resource forks should make virus spread harder, not easier. While > one can hide a virus in a resource fork, the same can be done in a data fork. > The thing is, since all code resides in the resource fork, and modifications > to resources go through manager calls, it is possible to intercept these and > consequently have a very effective virus defense. People familiar with the > Mac will know of the programs Vaccine and GateKeeper, which work in this way > by monitoring resource manager calls. Thus, it should be an improvement in > the virus situation. Acutally, on the Mac, code is in the resource fork. On the GS, it is in the data fork to be compatable with old applications. -- Syd Polk | Wherever you go, there you are. jazzman@claris.com | Let the music be your light. GO 'STROS! | These opinions are mine. Any resemblence to other GO RICE! | opinions, real or fictitious, is purely coincidence.
bh1e+@ANDREW.CMU.EDU (Brendan Gallagher Hoar) (07/22/89)
Hmmm.. On the Mac, does the CODE (ID=0) resource get executed automatically by the op sys, or does it get called by the DATA fork? Let me rephrase that. If a Mac file has a CODE (ID 0) resource, is the DATA fork executed before it? Some mac viri (viruses?) move the original CODE ID 0 resource to some other resource # and inserted their own code in ID 0. Following the train of thought (I know, mine is really hard to follow...even by me!), is there a mechanism in GS/OS that loads code from the resource forks of programs before executing the code in the data fork? Reply only if my rambling makes sense to you...I'm a bit tired right now... :) bh1e+@andrew.cmu.edu
dlyons@Apple.COM (David Lyons) (07/25/89)
In article <12865@bloom-beacon.MIT.EDU> captkidd@athena.mit.edu (Ivan Cavero Belaunde) writes: >[...] >Actually, resource forks should make virus spread harder, not easier. While >one can hide a virus in a resource fork, the same can be done in a data fork. >The thing is, since all code resides in the resource fork, and modifications >to resources go through manager calls, it is possible to intercept these and >consequently have a very effective virus defense. People familiar with the >Mac will know of the programs Vaccine and GateKeeper, which work in this way >by monitoring resource manager calls. Thus, it should be an improvement in >the virus situation. A couple of notes: On the GS, code is usually *not* stored in the resource fork. It's still in the data fork like before. There *is* support for Code Resources, but they are not executed automatically. When the system launches an application, it just InitialLoad-s the file, which uses only the data fork. Once the application starts running, it is free to call StartUpTools to open its resource fork (it can open its resource fork in more complicated ways if it really wants to). Once the application's resource fork is open, resources will generally be searched for there before the Sys.Resources file is searched. This means (for example) that the Icon Button control definition procedure (which is code) could come from the application instead of the Sys.Resources file. If the application decides to open documents as resource files, then resources could come from the documents too. This is not something that most applications will do--certainly not applications that were released before 5.0 was out. On the GS, I don't think resources would be the most convenient way for a virus to spread itself, so don't anybody get too paranoid about resources. For that matter, don't get too paranoid about viruses at all: just be careful. *DO* keep good backups! Some day your hard drive will implode and be struck by lightning, and the people you hired to re-tile the bathroom walls will mistake most of your 3.5" disks for bathroom wall tiles, and you'll be glad you took my advice. (Or, if you didn't, you'll be sorry you didn't.) --Dave Lyons, Apple Computer, Inc. | DAL Systems AppleLink--Apple Edition: DAVE.LYONS | P.O. Box 875 AppleLink--Personal Edition: Dave Lyons | Cupertino, CA 95015-0875 GEnie: D.LYONS2 or DAVE.LYONS CompuServe: 72177,3233 Internet/BITNET: dlyons@apple.com UUCP: ...!ames!apple!dlyons My opinions are my own, not Apple's.
rlw@pro-embassy.UUCP (Ron Wilson) (10/08/89)
Network Comment: to #223 by obsolete!dlyons%apple.com In Call-APPLE Quarterly, I read that it is possible to put executable code in the resource fork of a file.
dlyons@Apple.COM (David Lyons) (10/14/89)
In article <8910101231.AA13476@trout.nosc.mil> rlw@pro-embassy.UUCP (Ron Wilson) writes: >Network Comment: to #223 by obsolete!dlyons%apple.com > >In Call-APPLE Quarterly, I read that it is possible to put executable >code in the resource fork of a file. Yes, and it's also possible to put executable code in the DATA fork of a file, or in the boot blocks, or in places on the disk that are currently unused, or whatever. The trick in *all* cases is to arrange for the code to actually *be executed*. Having resource forks does not help virus writers a whole lot. The system does not automatically execute code in resource forks just because it's there. -- --Dave Lyons, Apple Computer, Inc. | DAL Systems AppleLink--Apple Edition: DAVE.LYONS | P.O. Box 875 America Online: Dave Lyons | Cupertino, CA 95015-0875 GEnie: D.LYONS2 or DAVE.LYONS CompuServe: 72177,3233 Internet/BITNET: dlyons@apple.com UUCP: ...!ames!apple!dlyons My opinions are my own, not Apple's.
jeffn@pro-houston.cts.com (Jeff Noxon) (10/15/89)
Network Comment: to #1248 by dlyons@apple.com I had the understanding that various MAC viruses would add a code resource and then PATCH the program to cause the resource to be executed. Since most S16 programs in assembly begin with the same code, it can be replaced and executed elsewhere. |uucp: [ucsd, nosc] ..!crash!pro-houston!jeffn | "If I wanted your opinion, | |inet: jeffn@pro-houston.cts.com | I would have given it | |arpa: crash!pro-houston!jeffn@nosc.mil | to you!" |
jeffn@pro-houston.cts.com (Jeff Noxon) (10/15/89)
Network Comment: to #1248 by dlyons@apple.com I$had the understanding that various MAC viruses would add a code resource and then PATCH the program to cause the resource to be executed. Since most S16 programs in assembly begin with the same code, it can be replaced and executed elsewhere. |uucp: [ucsd, nosc] ..!crash!pro-houston!jeffn | "If I wanted your opinion, | |inet: jeffn@pro-houston.cts.com $ | I would have given it | |arpa: crash!pro-houston!jeffn@nosc.mil | to you!" |
wombat@claris.com (Scott Lindsey) (10/15/89)
In article <8910142319.AA12114@trout.nosc.mil> jeffn@pro-houston.cts.com (Jeff Noxon) writes: > Network Comment: to #1248 by dlyons@apple.com > I had the understanding that various MAC viruses would add a code resource and > then PATCH the program to cause the resource to be executed. Since most S16 > programs in assembly begin with the same code, it can be replaced and executed > elsewhere. It's not so easy. For starters, on the Mac, all code is stored in resources, so you can modify code in memory, then write the resource out (or even flag it as modified and let the resoure manager write it out at shutdown). On the GS, *very*little* code is stored resources. So, you'd have to go out to disk yourself to modify code. Secondly the architecture of the Macintosh and the 68000 CPU causes ALL code to be absolutely relocatable. There is no OMF. That's why the Macintosh has no loader apart from the Resource Manager. Monkeying around with OMF is quite a different proposition than modifying absolute code. Finally, it's not very valid to say that "most S16 programs in assembly begin with the same code." Here's the first 4 instructions of a random sampling of S16 applications I had around: APW Shell AWGS PWorks Gold DPaintII Installer MSGS HodgePodge _________ ____ ___________ ________ _________ ____ __________ PHB PHK BRL +1EB8 PHD BRL +51 PHK PHK PHK PLB PHB TSC EOR 6F,s PLB PLB PLB TDC PHK SEC BVS +7B TDC TDC STA 0A38 STA 2318 PLB SBC #FB ADC (69) STA F8C9 STA 26DC Definitely some similarities, but nothing a virus could bank on, let alone use to its advantage. So, as Dave said, it's simple to add a code resource to an application. Getting it executed without the application's assistance is something else. Scott Lindsey |"Cold and misty morning. I heard a warning borne in the air Claris Corp. | About an age of power when no one had an hour to spare" ames!claris!wombat| DISCLAIMER: These are not the opinions of Claris, Apple, wombat@claris.com | StyleWare, the author, or anyone else living or Dead.