5 ms·

Reversing a MacOS Kernel Extension

100 points by supro 9y ago

saagarjha 9y ago
> Reversing the Unprotect Algorithm Protected binaries have everything after the first three pages encrypted with 512-bit Blowfish. The key is the “Don’t steal Mac OS X” poem (I believe with spaces removed): Your karma check for today: There once was was a user that whined his existing OS was so blind, he'd do better to pirate an OS that ran great but found his hardware declined. Please don't steal Mac OS! Really, that's way uncool. (C) Apple Computer, Inc. Fun fact: CommonCrypto doesn’t do Blowfish with a key size this large anymore due to CVE-2016-1802: https://blog.timac.org/2016/0710-blowfish-operations-with-key-size-longer-than-448-bits-in-macos-10-11-5-ios-9-3-2/ https://blog.timac.org/2016/0710-blowfish-operations-with-ke...
- codetrotter 9y ago
  > Note that using Blowfish with a key longer than 448 bits is not recommended as it weakens the security guaranteed by the algorithm. That is quite interesting. This is the kind of thing that people like me, who are not cryptographers, would not have expected. We are taught to always think longer is better.
  - heavenlyblue 9y ago
    No - what people are being taught instead is to never implement cryptography themselves and leave that to somebody who knows what he is doing.
    - nothrabannosir 9y ago
      Key length is a user-facing parameter of encryption libraries.
      - heavenlyblue 9y ago
        Library interface does not imply safe interface. More often than not one is required to study the supplied documentation, but even then some libraries require a certain amount of domain knowledge before one could apply their programming skills. That goes beyond security.
        nothrabannosir 9y ago
        The reason we're talking about it is because someone sang the "leave crypto to the experts" tune. Apparently not, because this was about key size. Responsibility for which is punted by experts to non-experts. I'm not saying don't study the docs. I'm pointing out the irony in bring up this "leave it to the experts" platitude, when it's so clearly about something left to end users. And to that effect: if interfaces are not safe, why are experts designing unsafe interfaces? I'm tired of this victim blaming in crypto failures.
    - JohnStrangeII 9y ago
      Yes, it's always good to leave X to somebody who knows how to do X. However, this ought not be left to "professional" cryptographers. After all, "professional" merely means you're getting paid for it. History has shown again and again that many professional cryptographers do not know what their doing at all. From Crypto AG, over Wifi encryption standards, early SSL encryption, to cell phone encryption standards professional cryptography has failed again and again. There's probably more snake oil in commercial cryptography than in open-source hobbyist projects. Professional cryptographers, as well as intelligence agencies and police authorities around the world have a vested interest in perpetuating the myth that you shouldn't roll your own crypto, even though they know that e.g. certain combinations of cryptographic primitives or higher round numbers in existing algorithms are more secure at best and no less secure in the worst case. There are many other modifications that would potentially strengthen cryptography, e.g. triple encryption with minimum key or cascading ciphers. The advocacy against home-made cryptography started in response to the cyperhpunk movement in the 90s, which was perceived as a threat for a very simple reason: Nonstandard implementations need to be reverse-engineered individually, and this is very labour intensive and can become prohibitively expensive even for large well-funded government agencies. Use of standard libraries is therefore much more desirable, as it also makes it easier to tailor your side-channel attacks to the endpoint. Moreover, if there is a weakness in a library, it can be exploited on more systems. Also, you can attack the servers and machines of fewer developers, e.g. exchange binaries when they are downloaded.
      - lisper 9y ago
        > History has shown again and again that many professional cryptographers do not know what their doing at all. Case in point: you should never use plain-text ascii as a key directly. You should always run your source key through a KDF, which will produce an actual key of the proper length. Also, what matters is not the length of the key, but how much entropy it has. Anything more than 128 bits is serious overkill.
        therein 9y ago
        This is very good advice that I find almost nobody I know follows. It is such a simple step that covers such a large attack surface that I am surprised this isn't more common practice since it gives you a nice peace of mind on the input. Every other time I suggest it in code review, I get a `but it works without it` and then I have to re-explain a bunch of stuff.
    - mschuster91 9y ago
      > No - what people are being taught instead is to never implement cryptography themselves and leave that to somebody who knows what he is doing. The point is: what is "implement"? If I use OpenSSL (or any other crypto library with Blowfish), and I don't know about this length issue, I'm still screwed.
      - heavenlyblue 9y ago
        Software developers tend to assume that any domain they create for is already so well-established that there’s a single web page on the internet that will explain how to do eveything. For example, in physics it’s laws of physics. You can sometimes get away with reading an article on wikipedia and it’s probably going to tell you how things are today and a decade in the future. For security it’s special cases. Being, for example: that certain hash functions will loose on their entropic properties if applied twice. This changes almost every year - and someone needs to keep their docs up to date so that you could know that. The issue is that security is incredibly contemporary in nature; while laws of physics most developers deal with haven’t changed for at least half a century.
- Matt3o12_ 9y ago
  What would be the purpose of such a "bad" encryption? Apple must have known that it is not difficult to decrypt the protected binaries, so what is the point? To deter people who are not determined enough to learn about the code? To tell people who do decrypt them not to seal code?
  - saagarjha 9y ago
    It’s probably meant as a slight deterrent. People who are determined to Hackintosh are going to do it anyways; this just puts a small barrier in place to them doing so. Plus, the poem makes them feel bad about their actions.
    - 95014_refugee 9y ago
      Technical Protection Measures.
      - saagarjha 9y ago
        It's not a very good one, is it? Nothing close to what iOS does. Nice username BTW ;)
  - EvanAnderson 9y ago
    I'd assume it's for the same reason that that Oracle used a poem in one of their protocols[1]-- to make distributing the key copyright infringement. [1] https://dacut.blogspot.com/2008/03/oracle-poetry.html https://dacut.blogspot.com/2008/03/oracle-poetry.html
fouc 9y ago
Funny - reverse engineer C++ calls by using google instead.
joy123 9y ago
Well, change is the only constant, I agree that we should “Don’t steal Mac OS X” poem team https://quickbooksupports.co/ https://quickbooksupports.co/ has taken a pledge to guide.
Fnoord 9y ago
(2016)
aymenim 9y ago
This is interesting, I wonder if this the same encryption used to encrypt app store apps as well, I believe on iOS the kernel extension is fairplay, it would be interesting to know if someone tried to decrypt an app without a jailbroken device.

100 points by supro 9y ago

> Reversing the Unprotect Algorithm Protected binaries have everything after the first three pages encrypted with 512-bit Blowfish. The key is the “Don’t steal Mac OS X” poem (I believe with spaces removed): Your karma check for today: There once was was a user that whined his existing OS was so blind, he'd do better to pirate an OS that ran great but found his hardware declined. Please don't steal Mac OS! Really, that's way uncool. (C) Apple Computer, Inc. Fun fact: CommonCrypto doesn’t do Blowfish with a key size this large anymore due to CVE-2016-1802: https://blog.timac.org/2016/0710-blowfish-operations-with-key-size-longer-than-448-bits-in-macos-10-11-5-ios-9-3-2/ https://blog.timac.org/2016/0710-blowfish-operations-with-ke...

codetrotter 9y ago
> Note that using Blowfish with a key longer than 448 bits is not recommended as it weakens the security guaranteed by the algorithm. That is quite interesting. This is the kind of thing that people like me, who are not cryptographers, would not have expected. We are taught to always think longer is better.
- heavenlyblue 9y ago
  No - what people are being taught instead is to never implement cryptography themselves and leave that to somebody who knows what he is doing.
  - nothrabannosir 9y ago
    Key length is a user-facing parameter of encryption libraries.
    - heavenlyblue 9y ago
      Library interface does not imply safe interface. More often than not one is required to study the supplied documentation, but even then some libraries require a certain amount of domain knowledge before one could apply their programming skills. That goes beyond security.
      - nothrabannosir 9y ago
        The reason we're talking about it is because someone sang the "leave crypto to the experts" tune. Apparently not, because this was about key size. Responsibility for which is punted by experts to non-experts. I'm not saying don't study the docs. I'm pointing out the irony in bring up this "leave it to the experts" platitude, when it's so clearly about something left to end users. And to that effect: if interfaces are not safe, why are experts designing unsafe interfaces? I'm tired of this victim blaming in crypto failures.
  - JohnStrangeII 9y ago
    Yes, it's always good to leave X to somebody who knows how to do X. However, this ought not be left to "professional" cryptographers. After all, "professional" merely means you're getting paid for it. History has shown again and again that many professional cryptographers do not know what their doing at all. From Crypto AG, over Wifi encryption standards, early SSL encryption, to cell phone encryption standards professional cryptography has failed again and again. There's probably more snake oil in commercial cryptography than in open-source hobbyist projects. Professional cryptographers, as well as intelligence agencies and police authorities around the world have a vested interest in perpetuating the myth that you shouldn't roll your own crypto, even though they know that e.g. certain combinations of cryptographic primitives or higher round numbers in existing algorithms are more secure at best and no less secure in the worst case. There are many other modifications that would potentially strengthen cryptography, e.g. triple encryption with minimum key or cascading ciphers. The advocacy against home-made cryptography started in response to the cyperhpunk movement in the 90s, which was perceived as a threat for a very simple reason: Nonstandard implementations need to be reverse-engineered individually, and this is very labour intensive and can become prohibitively expensive even for large well-funded government agencies. Use of standard libraries is therefore much more desirable, as it also makes it easier to tailor your side-channel attacks to the endpoint. Moreover, if there is a weakness in a library, it can be exploited on more systems. Also, you can attack the servers and machines of fewer developers, e.g. exchange binaries when they are downloaded.
    - lisper 9y ago
      > History has shown again and again that many professional cryptographers do not know what their doing at all. Case in point: you should never use plain-text ascii as a key directly. You should always run your source key through a KDF, which will produce an actual key of the proper length. Also, what matters is not the length of the key, but how much entropy it has. Anything more than 128 bits is serious overkill.
      - therein 9y ago
        This is very good advice that I find almost nobody I know follows. It is such a simple step that covers such a large attack surface that I am surprised this isn't more common practice since it gives you a nice peace of mind on the input. Every other time I suggest it in code review, I get a `but it works without it` and then I have to re-explain a bunch of stuff.
  - mschuster91 9y ago
    > No - what people are being taught instead is to never implement cryptography themselves and leave that to somebody who knows what he is doing. The point is: what is "implement"? If I use OpenSSL (or any other crypto library with Blowfish), and I don't know about this length issue, I'm still screwed.
    - heavenlyblue 9y ago
      Software developers tend to assume that any domain they create for is already so well-established that there’s a single web page on the internet that will explain how to do eveything. For example, in physics it’s laws of physics. You can sometimes get away with reading an article on wikipedia and it’s probably going to tell you how things are today and a decade in the future. For security it’s special cases. Being, for example: that certain hash functions will loose on their entropic properties if applied twice. This changes almost every year - and someone needs to keep their docs up to date so that you could know that. The issue is that security is incredibly contemporary in nature; while laws of physics most developers deal with haven’t changed for at least half a century.
Matt3o12_ 9y ago
What would be the purpose of such a "bad" encryption? Apple must have known that it is not difficult to decrypt the protected binaries, so what is the point? To deter people who are not determined enough to learn about the code? To tell people who do decrypt them not to seal code?
- saagarjha 9y ago
  It’s probably meant as a slight deterrent. People who are determined to Hackintosh are going to do it anyways; this just puts a small barrier in place to them doing so. Plus, the poem makes them feel bad about their actions.
  - 95014_refugee 9y ago
    Technical Protection Measures.
    - saagarjha 9y ago
      It's not a very good one, is it? Nothing close to what iOS does. Nice username BTW ;)
- EvanAnderson 9y ago
  I'd assume it's for the same reason that that Oracle used a poem in one of their protocols[1]-- to make distributing the key copyright infringement. [1] https://dacut.blogspot.com/2008/03/oracle-poetry.html https://dacut.blogspot.com/2008/03/oracle-poetry.html

fouc 9y ago

Funny - reverse engineer C++ calls by using google instead.

joy123 9y ago

Well, change is the only constant, I agree that we should “Don’t steal Mac OS X” poem team https://quickbooksupports.co/ https://quickbooksupports.co/ has taken a pledge to guide.

Fnoord 9y ago

(2016)

aymenim 9y ago

This is interesting, I wonder if this the same encryption used to encrypt app store apps as well, I believe on iOS the kernel extension is fairplay, it would be interesting to know if someone tried to decrypt an app without a jailbroken device.