Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×

How Encrypted Binaries Work In Mac OS X 365

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."
This discussion has been archived. No new comments can be posted.

How Encrypted Binaries Work In Mac OS X

Comments Filter:
  • by KlaymenDK ( 713149 ) on Monday October 30, 2006 @07:21PM (#16650593) Journal
    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
  • why bother? (Score:4, Interesting)

    by oohshiny ( 998054 ) on Monday October 30, 2006 @07:49PM (#16650971)
    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.
  • by AxelTorvalds ( 544851 ) on Monday October 30, 2006 @07:55PM (#16651037)
    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.

  • by GodWasAnAlien ( 206300 ) on Monday October 30, 2006 @08:10PM (#16651213)
    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".

  • by ettlz ( 639203 ) on Monday October 30, 2006 @08:15PM (#16651257) Journal
    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?"
  • by DurendalMac ( 736637 ) on Monday October 30, 2006 @08:17PM (#16651279)
    The thing is, Apple's implementation of Widgets is very well done. 10.5 is going to improve it with better memory management and the easy creation of widgets from any section of a webpage. The MS sidebar is a clunky and cumbersome implementation, probably because MS can't design a really good user interface to save their lives.
  • by frdmfghtr ( 603968 ) on Monday October 30, 2006 @08:22PM (#16651321)
    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.

  • by Lars512 ( 957723 ) on Monday October 30, 2006 @10:01PM (#16652189)

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

    Maybe he's talking about placement. Corners are considered critical because the user can flick the mouse to them without having to get angle or distance right. Although, you can also set your mac to use these "critical" corners for expose, like I do. Then you always end up accidentally activating things when you try to click on corner icons. Doh!

  • by iphayd ( 170761 ) on Monday October 30, 2006 @11:15PM (#16652737) Homepage Journal
    The Spotlight menu bar item is infinitely large, as it occupies the top right corner (Fitt's Law).

    The grandparent poster is aware of this, and would apparently like to populate it with something that they would utilize more than spotlight. Frankly, I agree, as I tend to key command to spotlight anyhow, then always bring up the window because I want to see the file path, not open the file.

    Now, so that you understand why it is infinitely large:

    Close your eyes. Move your mouse to the top and right. Give it enough movement to reach it and click. Open your eyes. You will have the spotlight menu open. (Unless you are not in Tiger, then you will have whatever is in the top-right corner)

    Repeat this exercise, choosing different starting positions and different lengths of movement. Notice that you always end up on top of the Spotlight menu. (Unless you under-hit it, which is irrelevant because you don't have a penalty if you over shoot it.)

    This is the reason the Mac menu bars are at the top- You only have to aim on the x axis, not the y. It is also why contextual menus are handy (you don't have to aim to get to where your cursor is _right now_).
  • by jZnat ( 793348 ) * on Tuesday October 31, 2006 @12:36AM (#16653441) Homepage Journal
    So why don't you have to jump through hoops to install OS X? It has no annoying activation or some Apple Genuine Advantage (tm) daemon or anything. All they really do is request you don't illegally redistribute it instead of assuming that you're going to redistribute it and stopping you at any cost.
  • 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.
  • by porkchop_d_clown ( 39923 ) <mwheinz@nOSpAm.me.com> on Tuesday October 31, 2006 @11:15AM (#16657875)
    The way I read it, portions of the app are actually encrypted with AES; which is interesting because it implies the decryption key must be part of the kernel, which implies the key is fixed.

    So, I'm not sure what this actually accomplishes - I mean, it prevents you from easily disassembling binary, but how does it prevent you from running on non-Apple hardware?

    Maybe the key is physically burned on some chip in the hardware?
  • by BeBoxer ( 14448 ) on Tuesday October 31, 2006 @11:53AM (#16658521)
    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.
  • by Bastian ( 66383 ) on Tuesday October 31, 2006 @12:26PM (#16659163)
    I can do this with my computer, too.

    It's worth pointing out that reverse engineering and disassembling/decompiling are not the same thing. The latter might be useful for helping with the former, but the law doesn't say that anybody is required to make sure reverse engineering will be easy. It just says that that you're allowed to do it for various reasons. Nor do I think anyone has an ethical responsibility to make reverse engineering easy. In fact, if you're looking to reverse engineer something it's probably in your best interests to not disassemble any Apple binaries, since you'll want to be staying on the safe side of copyright law. This is why the Wine folks down't want anybody who has seen the source code to Windows getting involved in their project. Similarly, both AMD and Intel would probably think twice before hiring somebody who has worked on the other company's chip designs.

E = MC ** 2 +- 3db

Working...