How Encrypted Binaries Work In Mac OS X

An anonymous reader writes "By now we know that OS X uses encrypted binaries for some critical apps like Dock, Finder and LoginWindow. Amit Singh explains the implementation of this protection scheme which makes use of the AES crypto algorithm and a special memory pager in Mach. The so called Do Not Steal Mac OS X (DSMOS) kernel extension helps along the way by decrypting things for the special pager when apps get executed. A funny thing is that if you print the pointer at address 0xFFFF1600 in your own app you get as output Apple's karma poem for crackers! According to the article there are 8 protected binaries in OSX including Rosetta and Spotlight meta data demon. Interestingly Apple's window server is NOT one of those."

It sure was simpler back in the day!

This is not the first "Do not steal Mac OS" they've done, although the first version never really got tested in action.

http://www.folklore.org/StoryView.py?project=Macin tosh&story=Stolen_From_Apple.txt&sortOrder=Sort%20 by%20Date&detail=medium&search=stolen [folklore.org]

History repeating! :D

One reason not to encrypt the windowing system

WM's are huge apps and decrypting one before every startup would add a lot of work that has to be done at boot. According to the article, "the SystemUIServer binary within SystemUIServer.app", is encrypted and that is presumably a larege component of the WM. Also, it's virtually useless without the the dock and finder anyway.

Re:One reason not to encrypt the windowing system

No, SystemUIServer is the process that runs Apple's menu do-dads, like the battery indicator, volume menu, iChat menu, keychain menu, clock, spotlight menu... basically, everything in the top right corner. Except for menus that 3rd party applications add, which are always to the left of the SystemUIServer items.

Originally, developers could inject their own menus into it if they figured out Apple's undocumented API for it. However, Apple shut that down (in 10.2, I think) since an unstable menu would destabilize all of Apple's menus. They're all run in the same address space, presumably to allow Apple to cut some corners in their command-drag reordering system. After 10.2, some developers hacked it to allow them to inject other menus into it. Maybe that's what Apple is trying to stop.

Even so, it's a really odd pick for encryption.

whoa, people still like Apple?

By now we know that OS X uses encrypted binaries for some critical apps like Dock, Finder and LoginWindow.

Actually, I *didn't* know that. I'm not going to "steal" the OS, why is Apple hiding parts of it from me? What else is hiding in there?

Apple seems to be very slowly turning evil again. *sigh*

Broken Encryption

If the eyes can see it, it can be copied. If the ears can hear it, it can be copied. If your mind can imagine it, it can be made. All it takes is time.

Thank you JaS.

http://www.kore-net.com/office/1.png [kore-net.com]

Typo?

The so called Do Not Steal Mac OS X (DSMOS) kernel extension...

DSMOS - Do Steal Mac OS?

DRM binaries eliminate competition

Microsoft would love to do the same thing,
and would I guess that they are planning to, but letting Apple pull it first, as Apple can get away with it.

Microsoft: "Apple used DRM music first, so locking everyone into our music player with DRM/Encrypted-Music is no worse".

Microsoft: "Apple used DRM binaries first, so locking everyone into our OS and Applications with DRM/Encrypted-Binaries is no worse".

where does dsmos_page_transform() get the key?

TFA says dsmos_page_transform() decrypts the page. Fine, but where does this get the decryption key? It's essential to store the key in a secure place, but this article doesn't mention it ...

I need to put the controller down...

...because the first image that pops into my head when I read DSMOS is an android with hot pink hair that kicks ass.

duh?

The article explained lots of specifics, but none of the general ideas behind it. Are the binaries encrypted, or just signed? Does the hardware have a public key hardwired into it, and if so, can someone just extract that key from a particular mac, for everybody else to use? Can Apple's mechanism be used to forbid people from running software that doesn't come from a vendor that's registered itself with Apple? Are the components we're talking about open-source, or not?

DSMOS

did anyone else notice that DSMOS is an anagram of MS DOS?

Where is the HOWTO?

Well that was useless.

Where is the tutorial on how to get our own apps loaded into this special no-pageout protected memory area so that they aren't screwed up by idiots clicking "yes" on a web popup? Every bit of protection helps.

What a waste of resources

It's a big problem with commercial software nowadays, they concentrate far more on anti piracy measures like this than actually improving the product...
Their developers are struggling against the cracking groups instead of improving the product, and every end user has to waste processor cycles running this crap and decrypting these binaries. Meanwhile, every version will eventually get cracked and put up on a p2p network.
Whatever Apple do, people will run pirate copies of OSX... But it doesn't run quite so well, it's slow and unstable... Even so, it lets far more people get experience with the OS than would have otherwise, i know several people who ran pirated osx on generic whiteboxes and then went out and bought a mac. Widespread piracy never hurt microsoft either, do you really think windows would be so prevelant in asia and russia if everyone had to pay full price for it?
A pirated OSX is a sub standard experience, like running a demo, and the people who pirate it are people who would never have bought macs to start with... Isn't it better to give them a taster in the hope that a few of them will change their opinion and buy a mac having had a small experience of osx?
From my experience, one of the guys i mentioned above hadn't used a mac since the days of system 7, and didn't like those old versions of macos at all. He'd heard OSX was much better, but had never used it and wasn't willing to buy a mac just to try it... Having run a pirated OSX for a couple of weeks, he bought an imac and now has a macbook too.

DSMOS

"Do Not Steal Mac OS X (DSMOS)"? Where's the "N"? Surely DSMOS actually stands for "Do Steal Mac OS"!

The Assimilation of Apple continues...

x86 architecture...

Windows XP running on Apple machines...

Encrypted binaries....

Ethical way to dump Apple's hardware requirements?

I'm getting pretty fed up with Apple's hardware. I don't like it. I don't like my Macbook Pro much at all, and if there was a legal way to run OS X on a Thinkpad I'd jump to it. Well, after dealing with bank account issues.

How about buying a Thinkpad and a Mac mini Core Duo, destroying the mini, and running that licensed copy of OS X on the Thinkpad?

Probably still illegal, but should be on firm ethical ground. Apple got their money, and I'm not running the OS on two machines.

Is this really a "feature"?

An interpreter script is a text file that traditionally begins with the #! characters followed by a path to the interpreter. Files not containing the #! line are treated as shell scripts--not by the kernel, but by the execvP stub in the C library. If the stub gets an ENOEXEC error from the kernel when such a file's execution is attempted, it reattempts execution by using "/bin/sh" as the first argument to execve() and the file as the next argument.

I think Linux does the same thing, although I haven't checked. Somehow, this just feels wrong to me. If it's not a valid binary, and doesn't start with #!, why not just fail? Why keep trying? /bin/sh is pretty forgiving. I'm pretty sure if you told it to execute a saved email or HTML file it would happily try every line in the file looking for valid commands. It's not hard to imagine this feature being one link in the chain which enables some exploit. After all, it's relatively easily to get shell commands into a users mailbox or web cache files. Making it possible for the system to natively execute a mailbox or HTML file just seems dangerous. Maybe that's just me.

Lack of details

Unfortunately the article doesn't explain in any way the really interesting points. For instance:

- How is the decryption key protected ? If it is included in the kernel binary you can read it.

- How is the kernel protected? Can you write a modified kernel that use the kernel extension unmodified and allows you to look at the decrypted code ?

- Can you run the kernel on an emulator (on a mac) that relays the calls to the TC chip so that the kernel thinks it is on a Mac while making it possible for you to look at the decrypted code and package an unencrypted binary back ? If not, why ?

These are some of the things I'd be interested in knowing.

Re:Signed binaries = good, encrypted binaries = ba

Disregarding the content of your comment, you're still confusing encryption with obfuscation.

What you see here is obfuscation.

Re:Signed binaries = good, encrypted binaries = ba

So what? OSX is based on BSD and does not need GPL compliance.

Re:Signed binaries = good, encrypted binaries = ba

OSX is denying the user one of the fundamental Freedoms.

Uh, it might be a "fundamental Freedom" if you had a "fundamental Right" of some sort to do as you wish with other people's IP. Unfortunately, you don't. A significant number of people make a good living for themselves and their families working for companies that, while being very understanding and supportive of the free software movement in its proper place, gain competitive advantage over their peers by employing the best intellectual talent to solve problems with technological solutions that if copied would eliminate any sort of advantage that company may have in solving a certain problem.

Re:Signed binaries = good, encrypted binaries = ba

If you purchase a physical item, do you still think of it as the seller's property after you've paid for it and taken it home?

When I purchase a car, the car is my property. Honda is not trampling on my liberties by not giving me all the CAD files and whatnot that were used to make my car.

Re:Some poem

Would you rather it did? I'm finding it a nice statement in its own right.

Re:Signed binaries = good, encrypted binaries = ba

The problem with signed binaries is that you either have a list of binaries that are signed, that is hardcoded into the kernel to check (BAD), or all binaries have to be signed (BAD). The only workable alternative is have a list of files and have that file signed.

What MacOS X does, is try to start the application. If it's encrypted, it's decrypted as part of the load process into memory. If not, well, it's not. I'm certain you can replace OS X's encrypted binaries with unencrypted ones of equivalent functionality - it just won't go through the same code path since it doesn't need decryption. This way, during development, the software isn't signed and it's trivial to get working (rather than having to constantly resign it as part of the build process). Once finalized, it's encrypted, and unless the kernel has a bug, it should work the as if it was unencrypted.

Anyhow, when has DRM really stopped anyone determined to break it? Those who are going through the effort to break this are either doing it for fun, or aren't buying a Mac. I can think of one way to grab the decrypted code right out of memory... (requires external hardware). I'm sure someone else creative can figure it out. There are probably another dozen ways to do it without needing external hardware as well.

How hard is reverse engineering?

Even though the source is not available, binaries can be reverse-engineered

Just wondering. How easy is it to reverse-engineer a massive closed-source piece of software (like, say, MS Windows)?

Such a reverse-engineering job would be of obvious commercial interest (especially to parties who work in countries with lax regulatory regimes), so there is an obvious incentive to do it.

However, my "armchair" estimation is that it is nearly impossible, since there exist parts of the world with large numbers of skilled computer scientists, and lax copyright laws. But so far there is no evidence that anyone has reverse-engineered Windows, or anything similar, on a large scale (e.g., I am not aware of any Russian web sites where you can download source of closed programs).

However, I am not a software engineer. Are there any experts out there who can enlighten me? I'm rather curious.

Re:Love mac - hate some of the choices

I would by no means debate your techncal reasoning, but the reason Apple thinks of these things as worth protecting is because the vast majority of users don't find using locate in a terminal window a better method. I might also add that if you take advantage of the metadata in apps like iPhoto, iMovie and even Pages you will find Spotlight can be pretty useful, but you do have to at least slightly adjust your work flow.

And honestly,unless your Mac is pretty old the Dock is hardly that massive of a resource hog.

why bother?

It doesn't really matter what they protect, they are simply trying to make copying OS X wholesale more cumbersome. Functionally, there is nothing in OS X that would be worth disassembling for anybody: there are already open source implementations of Spotlight, Finder, SystemUIServer, Doc, and all the other stuff, and arguably, the open source versions are technically better. The thing that makes Macs shine and sell is the packaging and integration, not the technology.

Re:Signed binaries = good, encrypted binaries = ba

Actually they're up to about 6% marketshare in the USA, and I think about 8% in the EU. And as for relevance, Apple, like Google are figureheads. When Apple do something, the rest of the market take notice. Like Widgets in OS X 10.4.....after Apple released this, Microsoft weighed in with 'Gadgets' (Yes, I know widgets come from Konfabulator, but Apple made them famous, and after Apple did so, Yahoo! bought Konfabulator, something that wouldn't have happened without Apple copying it in Tiger). So what Apple do is important because you tend to find 6 months after Apple do something, everyone else does too. I wouldn't be at all surprised if Microsoft use the encrypted binary idea in Vista SP1 or whatever comes after Vista (too late to put in Vista). I also wouldn't be at all surprised if Microsoft totally screw it up.

It's easy to make up freedom definitions

"Freedom is when you don't have to do nothing or pay for nothing,
I want to be free!" - Frank Zappa, "Teenage Wind"

Re:Signed binaries = good, encrypted binaries = ba

What if the CPU does the decryption in realtime? Then you can use encrypted binaries to prevent certain types of attacks because the attacker would have to inject encrypted instructions in to an overflow...

I think a patent was just filed for this kind of technology.

Re:Oh look, we can scramble a binary.

"Hi, I'm a PC."
"And I'm a Mac. My insides are all scrambled up. It protects me from dangerous crackers."
"All scrambled up?"
"Yep, that's right, my most important parts are very heavily scrambled."
"Does it hurt when you poop?"
"like you wouldn't believe"

Re:Oh look, we can scramble a binary.

Where do you think iPods come from?

Re:Signed binaries = good, encrypted binaries = ba

Wow... and this comment posted only a week or so after an article on Slashdot reported that Apple has seen a marketshare increase yet again, to something like 4.6%.

I know... I shouldn't feed trolls.... Maybe I should have taken offense at the insinuation that all GNU freaks have beards (including the women) instead....

Re:A nice benefit of this...

Actually, it's copy protection written into the firmware. By locking down the hardware side, and making their software incompatible with anything else, they've DRM'd the software while making you feel fresh all day. But we all know what that smell is covering up.

Re:Printing 0xFFFF1600 ?

I'm running 10.2.8 - quite old. Printing 0xFFFF1600 as a string with printf causes a seg. fault on my box.

well that's one hell of an Easter egg!

Re:Mac Zealot Moderator Alert

Thank-you. Maybe I should expand on the question as: "This is a curious little piece of technology, and something similar could no-doubt be hacked into Linux or BSD with an a few hours' coding, but I doubt ordinary users of said OSs would use or tolerate such a thing. So, other than discouraging reverse-engineering and attempts to run OS X on non-Apple hardware, precisely how does this benefit those who will use the system? And does this really merit a Slashdot story?"

Re:Printing 0xFFFF1600 ?

Same here, version 10.3.9.

Re:Love mac - hate some of the choices

I also can't stand spotlight. It is a resource hog and doesn't work well, plus it takes up critical real estate on the menu bar.

"Critical real estate on the menu bar"? Exactly how big is your Spotlight icon? Mine is less than half the size of my little fingernail on my 12" iBook, as big across as the menu bar is thick. I hardly call that "critical" but if that's your opinion, then so be it.

Re:Love mac - hate some of the choices

also can't stand spotlight. It is a resource hog and doesn't work well, plus it takes up critical real estate on the menu bar. "locate" in an xterm works much better. At least removing spotlight entirely was possible.

Except that "locate" doesn't index the contents all your files... including Email. That is what makes spotlight powerful. But yeah, it sucks what the indexer starts at really bad times. Like if you plug in a Firewire drive.

-matthew

Re:Signed binaries = good, encrypted binaries = ba

OK. So what? OS X is not Open Source. Parts are but on the whole OS X is a closed source application. Secondly Encrypting some vulnerable application help prevent future viruses from infecting some key applications To hide running apps, Logging passwords, etc... I am actually happy to hear this it shows that Apple care about security and are actively preventing future hacks from spreading in the future.

Re:That poem is scary..

I think the point is that most of the people who are running OS X on PC hardware did NOT pay for a copy of OS X. It specifically says "pirate" in the poem there. Now the question of paying for it then running it on your PC hardware IS another story. Personally I see no problem with this, but I wouldn't bother, legal or no. Stability and having things "just work" is nice. Criminalizing this activity seems silly, but Apple's also not the kind of company to say "Here's a supported configuration, you can install on other configurations but we won't support it." They like to sell an experience rather than individual units of utility. It may be stupid, but it is certainly well withing their rights to take this kind of action.

Re:That poem is scary..

The fundamental purpose of Copyright law is to allow a creator to control how their works are disseminated. Obviously, Apple wants you to buy their hardware if you want to run their software, and they're perfectly within their rights to do so.

Say Chevy offers Radiohead $1 Million to use one of their recordings in a stupid truck ad, and Radiohead refuses. By your logic, Chevy should then have the right to use the recording anyway, because since Radiohead refused to sell them the song they're not losing any money.

You may think it's right, but hundreds of years of copyright law would disagree.

Re:That poem is scary..

The US Treasury would disagree with you: http://www.ustreas.gov/education/faq/currency/lega l-tender.shtml#q1 [ustreas.gov]. Then again, what do they know?