The following information is a developer must read – bad news for hackintosh users – and good news for (future) Mac users. Keeping the bad guys out… to help protect you and your hardware. The side effect is that it might stop people, eventually, from using the latest and greatest aka OS X 10.9 Mavericks on a hack (didn’t happen in the 10.9 GM but it may still happen in 10.10). Well. Until someone comes up with another great hack of course.
Protecting the kernel
- OS X 10.9 code signing verification for kexts
- OS X 10.9 all kexts signatures are verified
- OS X 10.9 unsigned or invalid signatures are non fatal (with one* exception)
- OS X 10.9 Signed kexts will not load on releases prior to OS X 10.8
- Valid code signatures will eventually be mandatory for all kexts
- Use kextutil -tn to verify your kext
Kext loading
- OS X 10.9 auto-load, on-demand load by CFBundleIdentifier, and kernel cache build
- Searches in /System/Library/Extensions and /Library/Extensions
- Must code sign* kexts in /Library/Extensions
Where we want your kexts installed
- Auto-load kexts required for rooting, or auto-searching ofkexts
- OS X 10.9, /Library/Extensions MUST be signed!
- OS X 10.9, /Systems/Library/Extensions (for compatibility)
- OS X 10.9 and earlier, install unsigned kexts in /System/Library/Extensions
- All other kexts
- Signed kexts CAN go into: /Library/Extensions
- Do not install anywhere in /System (locked in the
nearfuture). - Other common locations still OK
Kext signing
- New with OS X 10.9, certificate for signing applications and kexts
In OS X 10.9
- Kexts in /Library/Extensions will NOT load if they are unsigned or have a signature verification error
- Users will see the “no load” alert dialog (need to OK it)
- Kexts outside /Library/Extensions will load if they are unsigned or have a signature verification error
- But users will see this – rather annoying – dialog
- Code signature verification warnings and error messages
- Most common code signature verification error codes
- -67030: something in kext bundle was modified
- -67062: kext is not signed
- Code signing error codes are in Security.framework:
- #include <Security/CSCommon.h>
Example after modified Info.plist:
com.apple.kextd[40]: WARNING – Invalid signature -67030 for kext URL = “file:///Users/local/AppleSamplePCI.kext/”, ID – “com.example.apple-samplecode.driver.SamplePCI”
Conclusions:
All kernel extensions in: /Library/Extensions must be signed and unsigned or otherwise invalid kexts in: /System/Library/Extensions will trigger an annoying dialog.
Apple also said that the /System directory will be locked in the future, but didn’t mention when or in which version of OS X that would be done. We just have to wait and see when it happens, but if this is introduced (in whatever OS version that may be) then we are locked out and that means that editing plists and/or patching bin (executable) files of signed kexts will be impossible, and since there are plenty kexts that need a binary and/or plist patch… you soon get the picture.
Source: Apple WWDC session video (707) and PDF.
Edit: Example of “Kernel extensions are not from identified developers” added.
Edit 2: Source added. Part about the locking of the /System directory reworded, this because it is unclear in which version of OS X it will be locked down.
Edit 3: Reworded a sentence that stated that people would be unable to use OS X 10.9 Mavericks on their hack. Sorry folks. I had no idea that this was still there. Should have been changed a long time ago, but I forgot about it.
Thanks to joe75 for the heads up!
Pike's Universum 
Might be under NDA. careful.
Yikes! You are right! I missed it, but it is there in the PDF – which I didn’t read until now:
“These are confidential sessions—please refrain from streaming, blogging, or taking pictures”
A little too late now. Thanks anyway!
FUD! Im sure many other people besides myself have already edited kexts we need 10.9 and Im just as sure there people using old SL kexts as well..
Login with your Apple developer ID and look for WWDC session video 707. It’s all there.
Something that we will need to patch when the time comes if it gets locked out.
I don’t know if patching will be possible, but I surely hope so. Will do some testing with signed/unsigned kext later today.
I have modded several kexts in 10.9 and have used unsigned ones as well. Modded kexts show no errors. unsigned had a pop pop and said to ignore and never had it come up again. Besides the way boot work Apple can not stop loading of kext. They would have to change the entire way Mac OS X boots to lock out modded or unsigned kexts.
Sure. You can still edit kexts, with this DP, but this will change before the final release. I mean. Nobody expects Apple to lock out everyone over night. Not until the most important companies are ready for it.
In the end we will just have to bypass it. Where does (if it does) log that all kexts are signed and to continue?
Hi pike , so in future on my sistem x79 with 3930 k i will a problem with speed step , i read a news maverics that osx will not have ‘problems with native speed step, this news and’ false for you?
I cannot predict the future. Nobody can. But from the looks of it I’d say that anyone in need of patched kexts is in trouble. Apple already asked developers to sign up for an Apple developer ID for Mac apps, but now they want us to sign all of our work. Which is good news for end-users, but not so good for hack folks. So if this requirement is made mandatory for the official release of OS X 10.9 then yes. Trouble is ahead of you.
I am confident, that you guru solve this problem I hope so
Pike – Can I repost, or at least post a link to this article in project OS, with full reference to you of course…?
But of course. This kind of stuff need to reach all interested developers in time. Clover devs included.
Appreciated – thank you
I wonder if we can just modify the cert/signing authority list to add a 3rd party server or run a local server that will allow us to run self signed kexts. Clearly we’ll need to make some changes to the way we edit .plists & kexts.
Whatever one puts together, another will take apart…eventually.
Mieze had mentioned on I.M. that if we get Dev accounts we can self sign our kexts, including things like open source fakesmc. As long as we dont share and get those signatures revoked that should be safe. So it seems the biggest issue is finding ways to patch intel or third party kexts and keep them working in a locked down future OS. I know there are legacy kext methods that can work for some things but AppleHDA for instance might be a big struggle. Any initial ideas on how to deal with that? Could appleHDA be made to work through a legacy kext style injection?
Thanks,
g\
Like I said. Having a developer id/certificate will enable you to sign (your own) kexts, and thus that is not the problem. It is however an extra hurdle to take. The rest will have to wait. No idea yet really.
So, perhaps the worst case scenario is all we have to do in the future is pay Apple for a Dev account and sign our own kexts to get our Hacks’ working. A small price to pay and Apple rakes in $99/year multiplied by thousands. Apple has tolerated us paying $30/upgrade for a few years now and could have easily cut us off, so I would not put it past them to implement this. Regardless, the community will always find a way around any hurdle Apple throws at us. Been ‘hacking since 2006, I am not worried.:P
We may as well be getting preference to switch it off. Like installing with apps from unidentified developers.
1. Pike – I regret you/we were criticised you know where, my comments to the STAFF member were in private – but life is too short to be concerned by narrow mindfulness!
2. I became a hacker thru Apple’s inability to acknowledge the overheating issues with the 2009 MacPro, which in the end involved the intervention of SJ himself. Having spent $Ks over the years since the early G4 days I have no problem with the EULA when they were shipping goods that were not of merchantable quality – yes there was a small claims case here.
That is totally besides the point and off topic – however I wonder how much Apple make out of hackers who pay for apps and memberships? I was always surprised that Apple did not introduce a DRM check to validate the equipment that their OS runs on?
3. A great deal I am sure, and likely now is a good time for an amnesty of sorts as Apple needs to acknowledge the existence of the hackers who by design prefer to build their own kit, rather than buy genuine Apple goods that they cannot modify sufficiently to satisfy their own needs.
I believe that there might be an opening for a real entrepreneur appointed by Apple to provide a bridge to overcome the difficulties that their “lockdown” might prove to what must be more than a small percentage of their user base. I do not believe that the Dev account would ever work as Apple have to approve the kexts for signature, and why oh why was FakeSMC.kext never renamed to AppleEMC.kext?
We see with the new MacPro that Apple is moving away from supplying kit that can be user modified, and everything they make looks good and is a brand that will appeal and there will always be the fanboyz that will buy the real thing, but perhaps time for change. if Apple where to acknowledges there are those with the PC boxes that like to use OSX (the system) without the will or the need for a designer box, and who won’t be a source of support – then somebody close to Apple need to tell them its 2013.
No worries. I can handle it. The thing is that Apple has more on their sleeves but that info isn’t even shared, but I have said too much already – since this info was meant to be confidentially – so I just let them be what they are… uninformed.
No worries!
1. The kernel is still open source… We can modify it however we like. And on Hackintoshes, we control the bootloader, not Apple, so they can’t check the kernel signature like they do on iOS devices. 😛
2. I think it actually might be possible to just add another root certificate besides Apple’s and sign fake developer certificates with it. You could then sign everything as if you were a developer and generate as many developer certificates as you want (that work only with your system). This seems to be a much cleaner solution than modifying the kernel to not check code signatures at all… Do your changes, resign the kext and you’re done. However, if an attacker wants to place a kext into your system, he will most likely not succeed… Well, unless he pays 99$ to Apple, anyways… and they call it security… LOL.
I actually think that it would be fair if Apple added another root certificate besides their own and gave you the private key when you purchase a device. (I’m talking mainly about iOS devices here, but if they ever decide to lock down Macs too, it will apply to them too) They would generate a new key pair for each device. This way I, the OWNER of my device will have the same level of control over my device as Apple has, which seems completely fair to me, as I have paid for the device, after all. If Apple ever does that, then everybody will be happy! Ordinary users will continue to enjoy their safe locked system, and hackers will be able to codesign whatever they want to be running on their devices.
All my 3rd party drivers run in Clover/kexts except the AppleHDA for me. If the AppleHDA binary is patched can an Apple Developers account give you access to sign only your kexts? Can an Apple System kext be modified and re-signed with such an account?
No. You cannot resign Apple binaries, but what you can do to get the AppleHDA.kext working, without having to specify kext-dev-mode=1 is to use the kext method that I explained in my blog (google for: “New style of AppleHDA.kext patching | Pike’s Universum”. And because of that I no longer have to use kext-dev-mode=1.
Note: Currently only AppleHDA892.kext and AppleHDA887.kext are whitelisted, but that should improve over time… when people start to submit crash reports.
This seems old but what im confuse ise, does mavericks supports kext-dev-mode flag? Afaik, only yosemite.
Yup. It was introduced in Yosemite and is taken out in El Capita again.
Pingback: STM32VL Discovery board on Mac OS X - A.Quarter.To.Seven