Gatebreak: Signed Kexts for Everyone

[mrheat]

you should also notice the installer is just doing its work right, when executed from the actual booted 10.9 partition... i tried to apply from booted 10.8 on a 10.9 (you should somehow hide the volume selection window, it can be confusing) partition it messed on the 10.8 i had to manually revert from 10.8 single user...

updating with hwmonitor breaks the gatekeeper i think, because modified fakesmc is coming with installer too

 

[nobodynose]

In light of mrheat's comment that updating HWMonitor from the Github site probably breaks Gatebreak, I decided to try reinstalling Gatebreak (after removing the existing FakeSMC). It didn't work - the installation failed. Attached is the install.log.

 

[TheNuck]

Gatebreak is giving me issues as well. What's the uninstall procedure?

I've got the standard FakeSMC.kext back in place but I keep getting these bad boys in console:

com.apple.kextd[12]: ERROR: invalid signature for org.gatebreak.driver.CPUSensors, will not load

What else do I need to kill?

Thanks,
nuck

 

[SJ_UnderWater]

you can't just overwrite some of the kexts willy-nilly, they come together. Either revert all files, or continue using the previous ones. You must remove FakeSMC and the plugins if you want to stop seeing those messages. Installer has a Show Files panel which tells you what will be installed for any package.
There's nothing wrong with the kexts themselves, but if you install other things over them, yes you will have issues.

 

[RehabMan]

Finally having time to take a detailed look at this. Thanks for looking into this and coming up with these tricks. It's clever.

I notice in the replacement requirements, you substitute a 'cert leaf[field...]' for 'cert 0[field...]', but I'm a bit confused by what I read here: https://developer.apple.com/library...ingGuide/RequirementLang/RequirementLang.html

In particular, "certificate leaf—the signing certificate; same as certificate -1"

Is changing the requirement to "cert 0" from "cert leaf"/"cert -1" the intention?

At any rate, my goal was to try and reproduce your results. I use my own FakeSMC, so using your version is not an option. I have a Developer ID that I can sign with (although not enabled for kext signing) although it appears your goal is to sign with something other than a developer id? Also I wasn't sure what version of OS X these binaries were from, so I figured better to do my own patch. It is just a string replacement after all.

So I set out to patch my own, and started with this script:

#!/bin/bash
set -x
function patchKextBinary()
{
    kextbin=$1
    perl -pi -e 's|anchor apple generic and certificate 1\[field\.1\.2\.840\.113635\.100\.6\.2\.6\] and certificate leaf\[field\.1\.2\.840\.113635\.100\.6\.1\.13\] and certificate leaf\[field\.1\.2\.840\.113635\.100\.6\.1\.18\]|\(\(anchor apple generic and cert 1\[field\.1\.2\.840\.113635\.100\.6\.2\.6\]\) or anchor trusted\) and \(cert leaf\[field\.1\.2\.840\.113635\.100\.6\.1\.13\] and cert 0\[field\.1\.2\.840\.113635\.100\.6\.1\.18\]\)|g' $kextbin
    codesign -s "Mac Developer:" -f $kextbin
}
mkdir patched
cp unpatched/* patched
patchKextBinary patched/kextcache
patchKextBinary patched/kextd
patchKextBinary patched/kextutil

I made a directory, copied all vanilla kextcache/kextd/kextutil to unpatched. Then ran the script, did some verifications that the patch was correct (bin compares without signing), then copied back to original locations to try.

I started with a non-essential kext so having an issue would not prevent boot (I used my ACPIDebug.kext). I placed the kext in /Library/Extensions (removed from /S/L/E) and signed with:

codesign -s "Mac Developer:" --deep -f /Library/Extensions/ACPIDebug.kext

This did not work. kextcache would reject the kext due to 'invalid signature'. So, then I used codesign to verify the signature. That was successful. So it is not that the signature is invalid, but rather that it doesn't meet kextcache requirements...

So, I decided to loosen up the requirements. I changed my patch to just 'anchor trusted' (you can pad with spaces or \x00, your choice... the string is a C-style NUL terminated string).

This is the patch:

perl -pi -e 's|anchor apple generic and certificate 1\[field\.1\.2\.840\.113635\.100\.6\.2\.6\] and certificate leaf\[field\.1\.2\.840\.113635\.100\.6\.1\.13\] and certificate leaf\[field\.1\.2\.840\.113635\.100\.6\.1\.18\]|anchor trusted\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00|g' $kextbin

This time it worked. The kextcache build was successful and the kext loaded as expected from /Library/Extensions.

I isolated it to the fact that the two trailing requirements are both not met (I tried with each standalone):

and cert leaf[field.1.2.840.113635.100.6.1.13] 
and cert leaf[field.1.2.840.113635.100.6.1.18]

So my developer id cert does not meet either of those two requirements. I also tried generating my own root CA (I'm a noob here, so I used 'Certificate Assistant'). I also tried signing directly with the 'Gatebreak Root CA' but that does not even work for codesign.

Should I be requesting a cert from [email protected]? Or am I doing something else wrong.

 

[SJ_UnderWater]

I guess I'll have to reply by-line:

I notice in the replacement requirements, you substitute a 'cert leaf[field...]' for 'cert 0[field...]', but I'm a bit confused by what I read here: https://developer.apple.com/library...ingGuide/RequirementLang/RequirementLang.html

In particular, "certificate leaf—the signing certificate; same as certificate -1"

Is changing the requirement to "cert 0" from "cert leaf"/"cert -1" the intention?

The requirements say "positive integers count from the leaf (0) toward the anchor" and "the value for the leaf certificate and root certificate are 0 and -1, respectively". If you found a typo, contact Apple.

I have a Developer ID that I can sign with (although not enabled for kext signing) although it appears your goal is to sign with something other than a developer id?

kextcache would reject the kext due to 'invalid signature'. So, then I used codesign to verify the signature. That was successful. So it is not that the signature is invalid, but rather that it doesn't meet kextcache requirements...

So, I decided to loosen up the requirements. I changed my patch to just 'anchor trusted' (you can pad with spaces or \x00, your choice... the string is a C-style NUL terminated string).

This time it worked. The kextcache build was successful and the kext loaded as expected from /Library/Extensions.

I isolated it to the fact that the two trailing requirements are both not met (I tried with each standalone):

and cert leaf[field.1.2.840.113635.100.6.1.13] 
and cert leaf[field.1.2.840.113635.100.6.1.18]

There are a whole bunch of issues here.

• I drew your attention to these OIDs back when kext certificates became available, you demurred. Just because a certificate says Developer ID doesn't mean it passes Apple's requirements for kexts.
• Kext certificates look almost exactly the same except for ...6.1.13 and ...6.1.18. Again, I called your attention to this a long time ago.
• If you have kext certificates through Apple (a special request made online), then you have no need for Gatebreak.
• Trying a normal Developer ID, or bypassing the specific requirements is pointless, you might as well not check certificates at all.
• Running `codesign` without specifying the code requirement only confirms that the signature itself is valid.
• `kextutil -tn <kext>` is a safe way to test kexts
• You should be signing the patched binaries with another certificate to replace the seals broken by patching, making sure to preserve the existing metadata. Without an exact match, they might as well be unsigned.
• My objective was to create a system with no dependencies on Apple, that's why I posted all of the materials necessary to create a certificate authority which passes the requirements. I even annotated the OIDs so others could make sense of them.

So my developer id cert does not meet either of those two requirements. I also tried generating my own root CA (I'm a noob here, so I used 'Certificate Assistant'). I also tried signing directly with the 'Gatebreak Root CA' but that does not even work for codesign.

Should I be requesting a cert from [email protected]? Or am I doing something else wrong.

The script I provided does (nearly) all of the work, so I don't see why you would use Certificate Assistant, knowing or not that it can't even create these kinds of certificates anyway.
You can't sign with the Gatebreak root certificate because I've only provided the public key which cannot be used to sign, only verify. I think you need to reread my three threads on this topic.

 

[RehabMan]

I guess I'll have to reply by-line:

Sorry for my noobness... I do not have a PhD in cryptography.

The requirements say "positive integers count from the leaf (0) toward the anchor" and "the value for the leaf certificate and root certificate are 0 and -1, respectively". If you found a typo, contact Apple.

OK... looks like an inconsistency/typo in the docs provided by Apple (no surprise there). I was just trying to make sure I understood the substitutions you were making.

There are a whole bunch of issues here.
[*]I drew your attention to these OIDs back when kext certificates became available, you demurred. Just because a certificate says Developer ID doesn't mean it passes Apple's requirements for kexts.

I realize that, but was under the impression that gatebreak was intended to bypass the kext signing requirements.

[*]Kext certificates look almost exactly the same except for ...6.1.13 and ...6.1.18. Again, I called your attention to this a long time ago.
[*]Trying a normal Developer ID, or bypassing the specific requirements is pointless, you might as well not check certificates at all.

Again, I thought the purpose of gatebreak was so signing with a kext cert was not necessary. And I see what you're doing now... you're using a kind of 'fake' kext cert...

And I think I get it, your requirements are tighter and still check that the kexts are signed like a kext would normally be signed, but eliminating the requirements that they use an apple cert. Because it is impossible to get an apple cert that satisfies all the requirements without requesting one from apple and exposing identity when the kext is made available for download.

[*]Running `codesign` without specifying the code requirement only confirms that the signature itself is valid.

So... when I run codesign, I must specify the 'code requirement' as well as the cert, which presumably already has this information?

And to sign I need to use -r "((anchor apple generic and cert 1[field.1.2.840.113635.100.6.2.6]) or anchor trusted) and (cert leaf[field.1.2.840.113635.100.6.1.13] and cert 0[field.1.2.840.113635.100.6.1.18])"

And the cert needs to have the ...1.13 and ...1.18 capability injected into it? I will look further into your script and see if I can generate such a cert.

I would appreciate any insight you might have on the specific params I should use for codesign.

[*]`kextutil -tn <kext>` is a safe way to test kexts

Great tip for quick checking. Final test is kextcache/kextload for me...

[*]You should be signing the patched binaries with another certificate to replace the seals broken by patching, making sure to preserve the existing metadata. Without an exact match, they might as well be unsigned.

As I noted, the binaries don't even need to be re-signed. It looks like a major hole in Apple's security here.

What do you mean by "making sure to preserve the existing metadata?" Is there some specific param to accomplish that in codesign?

If you could publish the codesign command lines you use for signing both the FakeSMC.kext and the binaries, that would be great.

[*]My objective was to create a system with no dependencies on Apple, that's why I posted all of the materials necessary to create a certificate authority which passes the requirements. I even annotated the OIDs so others could make sense of them.[/list]

But we still have the (as an intentional choice) dependency on the ...1.13 and ...1.18, although you're able to inject those into a non-Apple cert. At least that's my noob understanding at the moment.

The script I provided does (nearly) all of the work, so I don't see why you would use Certificate Assistant, knowing or not that it can't even create these kinds of certificates anyway.
You can't sign with the Gatebreak root certificate because I've only provided the public key which cannot be used to sign, only verify. I think you need to reread my three threads on this topic.

So the gatebreak cert is only useful to those using your FakeSMC.kext... It is not useful for others wishing to sign additional kexts. I thought you were implying otherwise when you wrote "The point of this method isn't to spawn tens or hundreds of independent authorities for signed kexts, whenever possible groups should create one authority: by website, working group, or other affiliation."

So although you wrote that in the subject documenting the process of creating the gatebreak cert, it is not your intention that the gatebreak cert is to be used that way (gatebreak is not "working group, or other affiliation"). The gatebreak cert is only useful as a signing authority for the kexts/binaries *you* plan on distributing.

Correct?

----

I will look further into creating my own cert with your script...

---

One other item...

If I understand correctly, we could simplify the code requirements from:

((anchor apple generic and cert 1[field.1.2.840.113635.100.6.2.6]) or anchor trusted) and (cert leaf[field.1.2.840.113635.100.6.1.13] and cert 0[field.1.2.840.113635.100.6.1.18])

To:

anchor trusted and cert leaf[field.1.2.840.113635.100.6.1.13] and cert leaf[field.1.2.840.113635.100.6.1.18]

My reasoning is this...

The expression '((anchor apple generic and cert 1[field.1.2.840.113635.100.6.2.6]) or anchor trusted)' allows either '(anchor apple generic and cert 1[field.1.2.840.113635.100.6.2.6])' OR just 'anchor trusted' to satisfy the requirement. All signatures that satisfy the first (left of 'or') will satisfy the second (right of 'or').

In other words, it is like:

if (x > 1 || x > 0)

can be simplified to:

if (x > 0)

Please correct me if I'm wrong. Thanks!

 

[SJ_UnderWater]

I realize that, but was under the impression that gatebreak was intended to bypass the kext signing requirements.

Again, I thought the purpose of gatebreak was so signing with a kext cert was not necessary. And I see what you're doing now... you're using a kind of 'fake' kext cert...

And I think I get it, your requirements are tighter and still check that the kexts are signed like a kext would normally be signed, but eliminating the requirements that they use an apple cert. Because it is impossible to get an apple cert that satisfies all the requirements without requesting one from apple and exposing identity when the kext is made available for download.

But we still have the (as an intentional choice) dependency on the ...1.13 and ...1.18, although you're able to inject those into a non-Apple cert. At least that's my noob understanding at the moment.

The only requirement strictly needing a bypass is that the certificate come from Apple. As I wrote in another thread, Apple may not approve certificates for certain kexts, and there's always the possibility they will be revoked. I see no need to tamper with the rest.

So... when I run codesign, I must specify the 'code requirement' as well as the cert, which presumably already has this information?

And to sign I need to use -r "((anchor apple generic and cert 1[field.1.2.840.113635.100.6.2.6]) or anchor trusted) and (cert leaf[field.1.2.840.113635.100.6.1.13] and cert 0[field.1.2.840.113635.100.6.1.18])"

And the cert needs to have the ...1.13 and ...1.18 capability injected into it? I will look further into your script and see if I can generate such a cert.

I would appreciate any insight you might have on the specific params I should use for codesign.

My point was, if you want `codesign` verification to mean anything, you must also pass-in the code requirement that kextutil/kextcache/kextload will apply (-R); `codesign -v` alone only checks the signature itself. They aren't "injections", they're extensions, which apply to every certificate under the sun. You can't have certificate revocation lists and key usages without them.

As I noted, the binaries don't even need to be re-signed. It looks like a major hole in Apple's security here.

This is another fallacy. Apple takes the time to sign their binaries, and you can bet that they will eventually be verified at runtime. The problem is things aren't entirely in place at the moment, and running my `psverify` tool will demonstrate that the seals can break even under normal conditions. Once they're ready (like Mavericks being the transitional release for kext signing), Apple will again flip the switch.

What do you mean by "making sure to preserve the existing metadata?" Is there some specific param to accomplish that in codesign?

If you could publish the codesign command lines you use for signing both the FakeSMC.kext and the binaries, that would be great.

I don't see why you're rebuilding the kext* tools, since I provide them. If you really want to make them yourself, as a learning exercise, familiarize yourself with the `codesign` man-page, and compare the `codesign` output before and after you patch and re-sign.

So the gatebreak cert is only useful to those using your FakeSMC.kext... It is not useful for others wishing to sign additional kexts. I thought you were implying otherwise when you wrote "The point of this method isn't to spawn tens or hundreds of independent authorities for signed kexts, whenever possible groups should create one authority: by website, working group, or other affiliation."

So although you wrote that in the subject documenting the process of creating the gatebreak cert, it is not your intention that the gatebreak cert is to be used that way (gatebreak is not "working group, or other affiliation"). The gatebreak cert is only useful as a signing authority for the kexts/binaries *you* plan on distributing.

The "Gatebreak cert" is not the Jesus Certificate, there isn't even just one; you've also examined the code requirement so you know it doesn't mention the Gatebreak CA. I explicitly and repeatedly refer to the certificate authority script because anyone signing kexts will need to run it. It makes absolutely no sense on any level to provide a single root certificate and its private key for public use; even Apple "vends" certificates, so if I wanted to distribute I would do at least that. Only the root certificate is installed in the System keychain; the leaves are used to sign files, enclosing the intermediates to complete the chain. The "use" of the root certificate is to attest to the contents of the files in the installer (even the installer itself). If I posted a certificate capable of signing kexts, what would stop someone from signing a malicious kext with it and convincing others to install it? With the Gatebreak root certificate already installed, there would be nothing stopping it from being loaded.

The example I gave could be applied this way: if you provide all of the kexts for the machines you support (or at least the kexts you prepare/compile yourself), then that is one "affiliation" and therefore one certificate authority. What I _don't_ think should happen is anyone with the inclination making one change to one Info.plist, opening Certificate Assistant and creating a single, unsafe root certificate with no extensions which specify its use, then signing and loading that kext. It would be even worse if that kext was then posted for others, potentially with the certificate's private key. Just because Gatebreak allows non-Apple certificates doesn't mean we should throw out all Trust; we might as well remove the signing requirement entirely.

The expression '((anchor apple generic and cert 1[field.1.2.840.113635.100.6.2.6]) or anchor trusted)' allows either '(anchor apple generic and cert 1[field.1.2.840.113635.100.6.2.6])' OR just 'anchor trusted' to satisfy the requirement. All signatures that satisfy the first (left of 'or') will satisfy the second (right of 'or').!

That's not how it works. While the "anchor apple generic" is also trusted, that doesn't mean other trusted certificate chains also have intermediates which specify the Apple Inc Developer Program extension. Having a trusted root or trusted chain is not carte blanche to do whatever you want. Even Apple strictly types the kext certificates they give out, otherwise a Push Notification certificate or some other could sign a kext and load. Security is not about doing the least, it's about dotting all the i's.

 

[SJ_UnderWater]

I should also mention:
No one is under any obligation to use the FakeSMC I provide (which is only as a convenience, and as an example, including the use of NVRAM), but it's probably best that most use the Gatebreak utilities since I'm doing all the work, including maintaining a certificate authority and installer which automatically adds it. I am not competing with other kext developers in any way, the Gatebreak installer represents only the absolute minimum necessary to get things off the ground. I am, of course, the maintainer of the certificate authority and the kext* binaries signed by that authority, but while I provide FakeSMC with my NVRAM modifications, this is only because FakeSMC is the only kext required for hackintoshes; together they constitute the bare minimum. If and when FakeSMC catches up with these developments in a way I think is secure (I previously criticized the current NVRAM solution), I will stop maintaining my copy.

 

[RehabMan]

That's not how it works. While the "anchor apple generic" is also trusted, that doesn't mean other trusted certificate chains also have intermediates which specify the Apple Inc Developer Program extension. Having a trusted root or trusted chain is not carte blanche to do whatever you want. Even Apple strictly types the kext certificates they give out, otherwise a Push Notification certificate or some other could sign a kext and load. Security is not about doing the least, it's about dotting all the i's.

Are you saying there is input where 'anchor apple generic or anchor trusted' does not evaluate the same as 'anchor trusted'?