Forgot your password?
typodupeerror

How Encrypted Binaries Work In Mac OS X 365

Posted by ScuttleMonkey
from the under-the-hood dept.
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
    • by QuantumG (50515)
      I really don't get it. This is just using copyright to prevent competition isn't it? If these people hadn't copied the ROMs and instead had written their own ROMs which were compatible, we could have had an Apple II clone war long before the IBM PC clone war.. how can that possibly be a bad thing for the consumer, being that the clone war is essentially what made PCs mainstream?
      • by jmauro (32523)
        No, since IBM had an agreement with Microsoft that allowed them to sell the OS to other customers, if a clone could duplicate the IBM BIOS then it'd be no problem to run the Microsoft OS. It was one of the benefits of the design of DOS from CP/M. Since Apple controlled the OS and the hardware, they didn't have to license it to anyone even if they copied the BIOS.
  • by runlevel 5 (977409) <g.p.patnude@noSPAM.gmail.com> on Monday October 30, 2006 @07:22PM (#16650601)
    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.
    • by Trillan (597339) on Monday October 30, 2006 @07:54PM (#16651025) Homepage Journal
      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.
    • by jmorris42 (1458) *
      > WM's are huge apps and decrypting one before every startup would add a lot of work that has to be done at boot.

      I suspect the reason is because according to the article all encrypted apps are locked into memory and unswappable. If an attempt somehow manages to be made to page part of one out the system panics. Talk about a major reason NOT to want those versions of the binaries on one's system.....

      Notice though how this Apple fan manages to describe all of the details except how to remove the crap. T
      • Re: (Score:3, Insightful)

        by Megane (129182)

        The DSMOS extension, by definition, can't itself be encrypted so why didn't he run dump of it and either extract the key or confirm IntelMacs are using TCPA hardware so the wailing can begin?

        Maybe because of this little bit of text which is in both the binary and two copies of a file called LICENSE:

        Copyright (c) 2006 Apple Computer, Inc. All rights reserved.

        The purpose of this Apple software is to protect Apple copyrighted materials from unauthorized copying and use. You may not copy, modify, reverse

  • by Anonymous Coward
    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*
    • by Eric Smith (4379) *
      slowly turning evil again
      You're confused; their "evil bit" wasn't ever turned off. They only appeared to be less evil (and more innovative) than Microsoft. If you choose the lesser of two evils, you still get evil.

      [Disclaimer: I was once an Apple employee, but I didn't speak for them back then, and I certainly don't now.]

  • Typo? (Score:2, Funny)

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

    DSMOS - Do Steal Mac OS?
  • 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".

    • Apple isn't locking everyone into their OS and applications. They're just locking some people out.

      OS: They have released software that's specifically designed to allow you to run more than one OS on your computer. Microsoft, on the other hand, has a long history of making it damn hard to dual-boot.

      Applications: You aren't required to run any of these encrypted apps. Heck, if you don't want them you aren't even required to pay for the operating system - you can download a pretty heavily stripped down ve
    • by Firehed (942385)
      I'd like to take a short break here to point out that when the iTunes Music Store was first introduced, Steve Jobs didn't want DRMed tracks (IIRC, he wanted straight MP3, but it may have been unprotected AAC), but was forced to do so in order to get records to sign. It just worked out a hell of a lot better than he could have planned for.

      That said, you're probably spot-on.
  • by bcrowell (177657)
    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?
    • 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?
  • DSMOS (Score:2, Redundant)

    by krunk4ever (856261)
    did anyone else notice that DSMOS is an anagram of MS DOS?
  • 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.

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

When the weight of the paperwork equals the weight of the plane, the plane will fly. -- Donald Douglas

Working...