Slashdot Mirror
Mac OS X Trojan Horse Infects MP3s
frequnkn writes "The Mac News Network reports that Intego has anounced an update to their anti-virus app for snagging the first Mac OS X Trojan horse, MP3Concept (MP3Virus.Gen), which exploits a weakness in Mac OS X where applications can appear to be other types of files."
So what?
Mac OS X can have trojans. Mac OS X can have viruses. Mac OS X can have security issues.
It's just a lot harder to exploit all of these things on Mac OS X for numerous logistical, technical, and statistical reasons.
It is a real concept. There is an example of the trojan, or "virus" (sic), here: http://www.scoop.se/~blgl/virus.mp3.sit
However, it seems that this may be at best questionable, as the "proof of concept" is nothing more than a standalone CFM application that has been given a creator type of 'APPL' (recognized by Mac OS X as a Carbon application), but with the file extension '.mp3', the standard mp3 icon, and the contents of an mp3 (which Mac OS X displays to the user an mp3). While the file does indeed appear at first glance to be an ordinary mp3, what can admittedly be potentially dangerous, it is in fact an application.
Additionally, as a CFM application, the file needs to be transported in such a way as to keep the resource fork intact, massively reducing its utility.
I predict a future security update with disallow this behavior...
This does not change the fact that Mac OS X is fundamentally and philosophically far more secure than alternatives.
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8 &oe=UTF-8&safe=off&frame=right&th=631707378ffe9292 &seekm=blgl-5D750C.02150821032004%40news.bahnhof.s e#link6
It appears that this is merely a proof of concept virus, hence, it is utterly benign. It was not made with any malicious intent, but to demonstrate one way that OS X could be exploited. The discussion group is concerned with making OS X more secure, not less.
Somehow, Intego got wind of it and blew it out of proportion, but I suppose it is theoretically possible that future viruses could be modeled on it. However I'm sure that Apple could, even more quickly, release a security update that fixes this.
Somebody on macnn.com pointed out this: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8 &oe=UTF-8&safe=off&frame=right&th=631707378ffe9292 &seekm=blgl-5D750C.02150821032004%40news.bahnhof.s e#link6
This is nothing new... people have been doing this for years on Windows. OS X lets you hide file extensions too, so MyMusic.mp3.app can show up as MyMusic.mp3. The article seems a little misleading at first -- the ID3 tag isn't executed, its a full fledged application that contains an MP3 file.
.mp3 extension, rather than showing the file as an application, leading users to believe that they can double-click the file to listen to it. But double clicking the file launches the hidden code, which can damage or delete files on computers running Mac OS X, then iTunes to play the music contained in the file, to make users think that it is really an MP3 file . While the first versions of this Trojan horse that Intego has isolated are benign, this technique opens the door to more serious risks.
It would take me about 15 minutes to write my own "trojan horse" of this nature... Don't make a big fuss over nothing.
From the MacNN article:
The company says that Mac OS X displays the icon of the MP3 file, with an
Sanity is not statistical.
It can delete your personal files and such, but beyond that it would require a password.
No. The RIAA had a widely publicized program where they hired programers/crackers to create bots to find MP3s (and report them -- there was a slashdot story about a guy with a name similar to some artist who got an automatically generated cease and desist letter, asking him to stop distributing MP3s he made). The WSJ also had an article about "experiments" the RIAA was doing to break into users computers and delete MP3 files that were pirated. (Nevermind that pirated MP3 files would be indistinguishable from ones which were ripped for Fair Use).
To quote my girlfriends mother talking about John Ashcroft, "I hope their [Members of the RIAA] stomachs explode and the devil comes take them".
The last big 'virus' scare for the mac was a number of years ago with the 'autostart worm'. As I understood it, it was an app that took advantage when you put a music cd in, it would automatically launch and play. The system was simply fooled into thinking the worm was a CD and not an application.
I have been surprised there haven't been more exploits using this method. I stick a music cd in any computer now (mac/win/*nix) and the OS launches and tries to play it.
Also, many windows install disks have the autoinstaller application which, I suppose, could be spoofed into launching automatically too, by a malicious code writer. It automatically launches simply by inserting a CD.
Am I correct in assuming all modern OS have some file validation routine to check these autostart/autolaunch applications?
Hey, leave comments about my mother out of this!
Deborked link
This would only work if the trojan could somehow learn your admin password, such as a key logger, and then trasnmit it to the outside. If you are using an app such as Little Snitch then you would be imediately alerted once this trojan tries to do this.
The resource fork is a remnant of the pre-OS X days. Pre-Mac OS X files, including applications, had two "forks": data and resource. When Mac OS X was created, it had the ability to run its own native applications, as well as two types of "Carbon" applications, Carbon being an API that allowed portability of applications using a subset of the old Mac OS programming APIs. One type of Carbon application, CFM, uses a resource fork for, among other things, file metadata. One of these pieces of metadata is something called Type and Creator. "Type", in this case, is set to APPL, and thus identifies itself as an application. While OS X decides to display the file as an MP3, the launching behavior is that of an application - just an oversight. The issue I was referring to was the resource fork must be kept intact in order for the file to still work - and any type of binary transfer WITHOUT special handling or compression (e.g. StuffIt, MacBinary, etc) will strip the resource fork and render this little "trojan" useless.
Also, if you knew the first thing about Mac OS X, you'd readily admit that the design philosophy and fundamentals of the OS do make it far, far more secure than, say, Windows.
assuming this is a serious question, try this for explanation.
The traditional Mac OS file system has two forks, a data fork, which is where normal data (like an MP3) lives, and a resource fork, which contains stuff like window designs, icons, bitmaps etc. for applications. I guess the executable code also lives there as well.
.app extension) which is a problem, although Windows does the same by default, it is possible to turn it off in Windows. Personally I'd give all executables a special label highlight to show that they're programs.
Depending on what you do with the file, the resource fork can be stripped easily, which is why Apple switched to a bundled format for most Mac OS X stuff, and why stuff like binhex and macbinary exist, to combine both parts of a file into a normal data file.
This does hilight an annoyance with Mac OS X, that applications never have an extension shown in Finder (old style Mac ones don't have them, newer bundle ones hid the
10 PRINT "LOOK AROUND YOU ";
20 GOTO 10
It's not highly unlikely. There was a story about a similar exploit in .XM just this week on Slashdot, and a major MP3 exploit in WinAMP before. It's a major problem with software -- most of the time, developers do not validate stuff coming from data files to the degree that they do stuff coming in from the network, so it's a lot easier to manage to pull off a buffer overflow or similar. It used to be that a major malware transmission vector was disks. Next was worms, over the network (but that's pretty easy to secure). But in a day and age where P2P networks exist all over, a good attack is against any programs reading data files downloaded from someone else. Audio files, video files, compressed files, games...you name it.
May we never see th
It's an application, but it's playable as an mp3 if you force iTunes to try to play it.
.mp3 that can actually be played as an mp3. A neat hack, but still just a renamed trojan at heart.
A mac application has a "resource fork" in addition to the traditional data. When the OS runs an app it looks at both the data and resource forks. In the trojan in the article, the resource fork contains executable code, so the OS considers it an application and executes it if you tell it to. If you look at the info window (not just the renamed extension) the OS calls it an application.
However, the data fork in this trojan is a real mp3. When the OS runs the application it considers the data fork to be junk and ignores it. However, if you open iTunes and tell it to play the trojan, it will see the mp3 in the data fork and play it.
The bottom line is, this is just a trojan renamed to be
Type/creator is no better than extensions, it's just that you can't see them. So while your APPL/VND type creator is there, it's no different than just naming your file:
.jpg.vba or whatever, since by default windows hides the extension (same thing as type/creator). And resource forks, being non-standard on most other OS's means that every time you move files around you lose meta-data that has to be rebuilt. Type/creator solves nothing, the only real solution would be using dynamic typing, but that won't work because there are so many files that are similar (look in your magic database, you'll see that stuff like Z machine files are not included because they cause too many false positives)
file.mp3.APPL.VND
And this is precisely how the exact same "information hiding" works in windows with
Extensions really have been the best solution, though there is room for improvement.
Free Online Woodworking Resources Directory
ResEdit.
Is this rock and roll, or a form of state control?
# file *.mp3 The "file" command doesn't see the file we are talking about as an app, but as a plain old MP3.
It should be noted that the would-be virus code is not executed by OS X when opened with an audio application. It skips over the JMP (or however they implemented the hack) and just plays the audio content.
If you throw virus.mp3 into your favorite p2p sharing system (or a web site, or most sharing methods other than AFP) the downloader will only get the data fork. That's why they had to put it in a .SIT archive first. Now you have to include code to rearchive the trojan before passing it on.
To do self-propagation right, go for pure data fork. Maybe AppleScript. A simple version would just read from AddressBook.app and spew to Mail.app. Bonus points if you detect/use other email clients too, including OS 8/9.
It's not executed when you open it in a music player, it's executed when you open it in Finder.
.mp3 extension; apparently the HFS+ filetype takes precedence over the file's extension on OS X.
.zip file with Mac metadata extensions, an xtar archive, a MacBinary file, etc., then decode it, then double-click the MP3 inside. Since there is basically no legitimate reason to encode an MP3 with one of those archivers when transmitting it over the internet, this trojan is extremely easy to avoid; don't double-click MP3s that were extracted from Stuffit archives and similar places.
.zip with a password supplied in the e-mail and then running the contents to enable a worm to spread, so it's not entirely implausible. I'd like to think that Mac users have a higher average intelligence when it comes to virus safety, but I'm not too confident.
I haven't looked at this trojan, but I participated in a theoretical discussion of the possibility on usenet a couple of weeks ago (interesting timing, that) and the theory isn't that strange anyway.
The way it works is that it's actually a full-blown application. It's a Carbon CFM application, which is stored as a single file. There's a resource in the resource fork of the file which tells the OS where the actual executable code can be found; this allows the application's code to be embedded inside a larger chunk of data. The whole thing is then typed APPL with the HFS+ metadata filetype, but given a
If you open the file from your music player, it's a real MP3 that just happens to have a bunch of junk (trojan code) in an ID3 tag. It plays, nothing else happens. If you double-click it in the Finder, though, the Finder sees that it's an application and launches it, and then you're doomed. The app can do whatever it wants at that point. Presumably one of the very first things it does is open itself with your MP3 player so as to give the appearance of functioning like a regular MP3 file, and then it can go around infecting or deleting files at will.
This isn't a particularly dangerous trojan. Because of the dependence on HFS+ metadata and resource forks, the app can't be transported raw, it has to be encoded. So you absolutely cannot be infected by double-clicking an MP3 you got from Kazaa. You have to download an archive file, like a Stuffit archive, a disk image, a
For a successful internet worm to result from this, the recipients have to do two steps. First they would have to decompress the file that was sent to them, then they'd have to find the results and open it. Of course, we know from the example of Windows worms that enough users will go through the trouble of opening an encrypted
Mod down posts with a "Free Mac Mini/iPod" sig, they're spam!
You can turn off extension hiding in OSX.
Utterly wrong. This is a CFM executable with no hidden extension. Double-clicking on it from the Finder will execute it, but dragging the file on to iTunes will only play the MP3 stream inside the file. Mail.app, however, correctly identifies it as an executable when you try to open it from inside an email.
There are no tiger attacks in my area and it's all because this rock I'm holding keeps the tigers away.
Type and creator are not stored in the resource
fork nor the data fork. You could think of them
as a third, fixed-size fork. At least, that's what
Siracusa of Ars Technica wrote.
Ben "You have your mind on computers, it seems."
How about you just not open any archived email attachments (.sit or .zip files) that you're not expecting? If the file is transferred bare, without being in a compressed archive, the resource fork is stripped, and the application is rendered inoperable. If you're downloading and opening .sit and .zip files you're not expecting, then you got what you deserved. The low marketshare of Macs practically assures that you won't really affect anyone but your own dumb self.
"I like systems, their application excepted", George Sand (French)
It's not necessarily the Finder displaying this trojan application the same as an MP3 file. In fact I'd expect that the Finder is displaying the correct icon for the app.
How could you have a classic-style application that looks like an MP3 file? Simply copy the standard MP3 icon out of iTunes and put it into the resource fork of the app as it's icon.
There is no simple, convenient way I see of solving this problem without enforcing that all applications should have a ".app" suffix. This policy would be OK for new apps but would create big legacy problems.
The file is a CFM application. As others have pointed out, this means that it has a resource fork which it needs in order to be able to run. Thus, it must be downloaded as a compressed file. If the resource fork is stripped, it is harmless, as the payload will never be executed.
Its name ends in ".mp3", and the included icon is copied from an iTunes MP3 file, but its type code is APPL, an application. The data fork is a valid MP3 with PowerPC executable code inside the ID3 tags. When given to iTunes or another MP3 player, it simply plays the included sounds without executing code. When double-clicked on from the Finder, the surrounding bits of MP3 file appear to be ignored and the code is executed. The payload for the proof-of-concept displays a dialog box, then tells iTunes to play the file itself, presumably via AppleScript.
When double-clicked, it shows up in the dock as an application, though this could be suppressed in an actual hostile trojan just like many utility programs do. In the Finder, if one is using column view, it is identified as an Application instead of an MP3 File, and its icon is shown instead of a QuickTime-style playback bar for previewing the contents.
In terms of an actual exploit, the only thing going on that is even possibly questionable at an OS level is the presence of other stuff in the data fork before the Joy!peffpwpc tag. I am not certain if this is allowed in the definition of what a PEF executable is supposed to look like. Aside from that, there is nothing else that is tricking the OS into doing something it shouldn't do, only legally included information that is deceptive to a user who is not looking carefully at things.
BeOS virus ? Something to keep you awake at night... BeOS could also set arbitrary icons for files to disguise their real types. This problem is nothing new.
--
I romp with joy in the bookish dark
NeXT did it for a good reason:
.app directory so all the resources, bitmaps, and supporting files are in that one directory. That is why I can reinstall OS X and have MS Office X and all my other applications still work without reinstalling everything. I suppose they could still do fat binaries as well if they ever decided to do so.
NeXTSTEP ran on four different hardware platforms and had fat binaries. Within the foo.app directory, there'd be foo-moto, foo-386, foo-sparc, and foo-hpux binaries. The OS would then attempt to execute the appropriate binary for the hardware platform the OS was running on.
OS X uses the
I tried every decent and legal way I could think of to resolve the issue w/the business before I rented the chicken suit
no i think the mach-o objects (the code) is fat. one file contain the executable, while the directory contain all the datas... especially the interface definitions. in theory you could copy English.interface directory, cant remember the actual name and do the interface translation in the interface builder.
On Windows we had Trojans of this level of complexity -- really little more complex or interesting than distributing an AOL password phisher as porn and/or a game -- ten years ago. This can effect anything from Palm OS up to a mainframe. It'd be something to be scared about if a worm came out for OS X that can infect without any user action.
Safari just opens the archive in that case.
.sit archive. Neither of these exceptions poses any danger.
It only opens files once. It doesn't then open what the files produce. There are two exceptions to this; one is that anything that's gzipped is un-gzipped and then opened or not based on the contents, the other is that stuffit will automatically mount a disk image contained in a
One thing to keep in mind is that this trick only tricks the user. If the Finder knows it's an executable application, any other app on the system can find out too.
This is not an exploit of anything, it's just a cleverly designed application that looks like a music file to a human being. It can't be run without active participation by the user.
Mod down posts with a "Free Mac Mini/iPod" sig, they're spam!
MacOS has always had a virus scanner, even though most viruses were for Windows. Disenfectant was written by John Norstad at Northwestern UNiversity. Great freeware app, and protected agasint all known mac viruses, of there were literally on the order of 20 or so (while there were thousands of Windows ones). The best part was the Monty Python foot that came down in the About Box.
In NeXTStep V1.0( and I think 2.0), the entire application was stored in a Mach-O format file. Ultimately, there were resource issues involved in trying to keep the entire application and it's resources in a single Mach-O file, which resulted in this being splitup into a diretcory containing the resources, and the Mach-O file retaining the executable data required by the system loader.
That's not all that different from how classic Mac OS apps were stored in different resource areas of a file.
That doesn't provide any protection. While UFS doesn't support any of the HFS+ metadata, OS X fakes it. Find a monolithic-file Carbon app and stick it on your UFS drive; you'll notice an extra dot file showing up in the directory where it's stored. This is where OS X keeps the resource fork and stuff like the type and creator codes on filesystems that don't support them directly.
Mod down posts with a "Free Mac Mini/iPod" sig, they're spam!
Because Microsoft Office (the mac port) adds the functionality of vbs-worms!
This comment does not represent the views or opinions of the user.
This isn't the first OSX virus.
I think the first one was back during version 10.0 and was named something like "The Simpsons". If I remember correctly, that one was written in Applescript and it was fairly benign.
I believe the only damage it did was send out the contents of your address book or something like that. Not really disastrous.
You can be emailed the trojan in its uncompressed (dangerous) form as an attachment. Emailers encode the resource fork and email clients automatically decode it when you single-click on the attachment e.g. in Mail.app on MacOS X.
Mail.app is nice enough to warn you that you're about to execute an application and gives you the option to "Open" "Cancel", or "Save". If you're cavalier and just click the "Open", you're hosed. If you click "Save" and later activate the saved file in the Finder, you're hosed.
I do not know if other email clients are even that kind though.
The Intego Virus Barrier software just flags as "infected" any CFM executable whose name ends in a common file extension... which is why it STUPIDLY flagged as viruses the BMP, PCX and PNG plugins for Photoshop Elements. Which means it does not even check for a dot and something else before the file extension.
Proof (jpg)
Can you say "crappy" ? I'm sure you could.
Maybe we deserve this world ?
There was even a worm which exploited the vulnerability behind the last item on that list.
The problem with Apache vs. IIS comparisons is that they are hardly fair. IIS comes with tons of dangerous examples and extensions. Bugs in widespread Apache modules are usually not attributed to Apache itself. There's nothing wrong with that, but it doesn't give you much information which web server, when configured properly, is more secure.
The linked article (and most coverage of this trojan) is very misleading. This trojan does not delete files, propagate itself, or infect other files. The press release from Intego just says that a trojan like this could do those things. Read the press release for yourself.
Intego Press Release
The important thing to realize here is that Mac OS X, while very secure, is not perfect. And no matter what OS you are using, you should be very careful what you double click! Let's hope Apple nails this quickly!
The resource fork is not CFM-specific, and is not where metadata goes. Metadata, like the type and creator, are stored along with info like the filename. A file can have this metadata without having a resource fork.
A resource fork is used for extra data. Pre-OS X applications store dialogs, sounds, pictures, icons, strings, and even program code in the resource fork. All files on Mac OS X are capable of having resource forks, this is used by programs like BBEdit which store cursor & window position in the resource fork of text files you create.
Mac OS X is only capable of running one type of application binary, the Mach-O executable. When you run a CFM (Code Fragment Manager) application, launch services will run the 'LaunchCFMApp' program transparently. Normal CFM programs require a 'cfrg' resource in order to function, as well as a 'carb' resource to launch outside the Classic environment. CFM applications aren't necessarily Carbon, but that's by far the most common case.
The program isn't all that special. It has a custom icon, like every other application, but the icon looks like an MP3. If you transfer it without archiving it with Stuffit or MacBinary, the type & creator get killed (can't launch) and the resource fork goes away (no custom icon, can't launch). Since the data fork is a valid MP3 file, when you launch the stripped version it will open iTunes and play. You can also strip the file by going to the command line, and running 'cp virus.mp3 virus2.mp3'.
The 'cfrg' (Code FRaGment) resource is usually created automatically by development tools. It specifies where in the data fork the application code resides. So it's trivial to create an application that is also valid as a different kind of file.
I suspect it will catch the kind of people who put '.' in their $PATH, browse slashdot as root, and open email attachments in Microsoft Outlook.
Oh, and don't think that Mac users haven't had *problems* with viruses, as any Hypercard programmer will tell you (I hated MerryXmas virus).
. . . just give us your credit card number and everything will be fine.
But seriously; they paint the situation much worse than it currently really is, because they want ordinary users to be frightened of getting a virus. And that's because people who are frightened of getting viruses buy anti-virus packages.
It looks like someone noticed a potential security flaw to do with the way MacOS X presents files and file types to the user. He asked around on a Mac programming group to make sure he wasn't being paranoid, people there confirmed it was possible and one even made a test case (totally benign - it runs code but does nothing else). Here's a link to that thread on google groups.
Intego caught wind of this, and immediately issued a press release describing how the sky is falling, noone can trust anything any more, claiming credit for the discovery, and by the way have you noticed we sell a product which will prevent infection? Buy it now!
NS 3.3 ran on four platforms. That was the last version I used, and I distinctly remember it. There were even NeXTSTEP utilities that "thinned" out these fat applications and only left the thin executable you needed.
I tried every decent and legal way I could think of to resolve the issue w/the business before I rented the chicken suit
Most OS X boxes will have been installed with default settings.
Most OS X boxes will be used by only one person.
Most of these people will be running as a user in the admin group, since that's the type of user that is created during the installation process.
Users in the admin group can sudo to root.
So, the assumption that the trojan will run as the default user created during install, which is in the admin group and can sudo things to UID 0, is completely reasonable. Heck it wouldn't even qualify as "small", let along "big".
Nextstep did run on four platforms, and NeXT did use fat binaries. The binaries for the architectures were together in one MachO binary file, each in a different MachO segment. NeXT's fat binaries didn't use the resource fork like Apple's did.
.lproj directories for interfaces for different languages.
... [ ... [-create] [-thin arch_type] [-replace arch_type file- ... [-remove arch_type] ... [-extract arch_type] ... ... [-output output_file] [-segalign ...
Commandline programs, which have no directory bundle, could be fat, because the architectures were just concatenated. Mach just goes to the appropriate segment to find your computer's binary.
There was a tool called 'lipo' which was used to remove architectures from a binary, and otherwise manipulate them.
lipo as in liposuction, from 'fat binary'.
The directories you're thinking about are perhaps the different
lipo is still in OS X, apparently unchanged.
NAME
lipo - create or operate on fat files
SYNOPSIS
lipo [-info] [-detailed_info] [-arch arch_type input_file]
input_file]
name]
[-extract_family arch_type]
arch_type value]
The lipo command creates or operates on ``fat'' (multi-architecture)
files. It only ever produces one output file, and never alters the
input file. The operations that lipo performs are: listing the archi-
tecture types in a fat file; creating a single fat file from one or
more input files; thinning out a single fat file to one specified
architecture type; and extracting, replacing, and/or removing architec-
tures types from the input file to create a single new fat output file.
Someone should point out that the distinction that you're making is in name only. The actual codebase is the same, rebranded as "OPENSTEP" when they published their API for open implementation. For all non-marketroid intents and purposes, NeXTstep did run on four architectures. I had the pleasure of using it on i486, an HP "Gecko" PA-RISC workstation, and one of those noisy Tadpole SPARC laptops.
And although the code segments were not interleaved within the same file in the way that you're thinking, the actual term was "fat binary" both inside NeXT and within the user community. There was even a tool called "lipo" (as in liposuction) to strip out the architectures that you didn't need. It still lives in /usr/bin on MacOS X today.
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
Sorry to burst your bubble, but the whole 'app is really a directory' thing is a SOLUTION to the 'resource fork' storage problem. And it allows for cleanly implemented multi-platform 'fat' binaries. Apple's Classic fat binaries were kludgy, the CODE resource fork held the 68K binary and the data fork held the PowerPC binary, hardly extensible.
I've got an OSX install on purely UFS, and sure enough, it allows you to pack x86 and PPC binaries (or multiple PPC/X86 binaries, for optimization/bitness) into the same *.app so you can have one application file that executes on multiple architectures. It might not be Apple's hacked-up old kludgy way to get a 'fat binary' but it's effectively the same result but done MUCH cleaner and capable of living on many diverse file-systems.
Imagine how cool it would be to have ONE shared 'applications' folder mounted read-only on all your clients, the x86 clients execute the x86 code from camino.app and the PPC machines execute the PPC code from the same place. It would be an administrator's utopia!
"Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails
NextStep ran on Motorola 68k (Next slab and cube), PA RISC (HP workstations), Sparc (Sun workstations), and Intel (specific PC's). Applications could be compiled fat on any of the four platforms and run on all four platforms with no modification.
jfs
The only thing worse than a Democrat is a Republican.
Another "informative" comment by someone who hasn't read the article yet. Bravo; you're a jackass.
Look, it's simple. This is a Carbon app. It's a single file. This could potentially be used to attack both OS9 and OS X users. This is not a case of "the directory is the app" as you think.
What makes this spoof so easy is that they've taken advantage of OS X's handling of both resource forks AND file extensions, so that Finder makes it appear that the file is, in fact, an MP3. If you do a Command-I you (apparently) see that it's an application.
I wondered how long it'd be before someone took advantage of this...
Stating on Slashdot that I like cheese since 1997.
Okay but that is not really necessary on Darwin anyway because it uses Mach-O instead of something like ELF (most modern UNIX-likes) or XCOFF (basically what the PPC data fork code really was prior to MacOS X) and this allows the same binary FILE to have copies for various architectures in it. Check out:
This came from NeXT too. WhatDid you know about the ARCH variable and the automounter? Do a man automount on solaris say. This is how you can create a map in NIS for /foosw say, where /foosw/bin is different for sparc and x86 while /foosw/include are the same say. Then you have dirs like /export/foosw/bin-x86, /export/foosw/bin-sparc, /export/foosw/include (or you may like to use a structure like /export/foosw/x86/ and /export/foosw/sparc/ with symlinks pointing up a dir for common stuff) which you export over NFS. On solaris check-out isaexec,
isalist, and friends to see how to have different optimized verions of the same binary. (The trick there is with subdirs like sparcv9 etc.) Each other OS (and sometimes it is a compiler-toolchain provided trick) handles this in its own way. You can even have optimized dynamic libraries, in elf just link with the appropriate -R options creating special dirs for the different targets. In solaris you may be able to be even more nifty about this all. Do this sometime on a recent solaris box:
Take a look at AT_SUN_PLATFORM. Now do:Take a look at and this should give you an idea of how to do something similar.Anyway, the thing you wish for has been solved a long time ago, and in a more clean fashion, without resorting to treating applications like directories.
I chose UFS fo my desktop for three reasons:
1. Case sensitive.
2. Thought it would be more resistant to corruption.
3. To see if it had any other advantages or disadvantages.
What I found was that it's a lot slower on laptops, but about the same real-world speed on desktops. Several third-party apps needed TLC to work right, because case sensitivity broke them. Cloning using Carbon Copy Cloner doesn't work with UFS.
I still use that UFS desktop, but I think next time I wipe it I'll go HFS+. I heard I can enable case-sensitivity in HFS+ now, so the benefits of HFS outweigh those of UFS for me now.
I'd like to see Apple implement resource forks as a plugin for reiser4 and then make darwin/OSX work on top of it. I think reiser4 would kick HFS+ arse.
"Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails