Counterfit said:
Earlier someone asked how it could infect JPEG and GIF files. I'm not sure if GIF has it, but many JPEG's include EXIF data, like an ID3 tag for pictures. I don't know if it could also include executable code, but that's were it would be. Of course, if you download a 4.4MB JPEG and it's 256 colors and 100x400 pixels... 😀
Well as long as you want to keep only the double-click feature alive every format can be abused that way because the program can simply open a partly view of itselft in the real app (e.g. by copying the "good" parts into another file and opening that).
But if you want to be able to open the thing by hand in that app you'd need a format that takes being filled with garbage like mp3 does.
😉
Now something I learned from toying around with this:
There is a big misconception running around with this little program. The actual runnable code is
NOT in the ID3 tag. It's in the resource fork.
What is in the ID3 tag is mostly just the meta information needed for the OS to recognize the program as such and a jump command to reach the actual code in the resource fork. The most simple way to show this is cutting off the resource fork with a tool like GrimRipper [1] and then trying to start the prog. It will bounce and die without doing anything simply because the code is gone but the meta-data claiming this to be an app is still there.
Actually some code is still there. The data fork starts with a jump into the resource fork. That one will be executed, all of the massive amount of zero instructions in that fork (it's empty) will be executed as well and the app simply runs out. 😉
On the other hand when you manually open the thing in iTunes you'll hear the same demented laughter as before while starting the complete file so the mp3 data is obviously still there.
If the author had really done what he claimed (namely putting the code into the id3 tag) there would have been no need for a data fork as carbon apps that need no resources don't have one either.
You can see this yourself when opening the app with the resource fork cut off. It runs without an error message which surely would come if carbon apps would need to have a resource fork.
As for noticing something wrong with the filesize for the given picture quality + size (for pics) / encoding + length (for audio):
sorry dude no chance. A 100k virus is already hopelessly bloated and putting it into a 3 MB .mp3 or .jpeg would not change the size enough to cause people to wonder what's going on.
[1] -
http://www.versiontracker.com/dyn/moreinfo/macosx/16168