Clover General discussion

[arsradu]

It won't set up the RtVariables. These have to be added to your config.plist. Otherwise SIP is active and the kexts will be omitted from the post-update cache rebuild. This post from blackosx explains the CSR variables (I also added the BooterConfig one though I'm not really sure what it does). Look at the 8 digits in the brackets after 0x67. Now look at the list of CSR values from bottom to top and you'll see the matching pattern of the 0 and 1s. You enable or disable the values using 0 or 1 and list them in a string starting from the bottom of the list. When you convert the binary string to hex you get 0x67.

 

Injection still doesn't work from EFI. So if (like me) you want to be able to boot a vanilla installer you'll have to stick with DB3 or PB1 and then copy the kexts to /L/E afterwards. Not ideal, but we just have to wait for the Clover guys to get injection working again.

Thanks a lot, Riley. Very much appreciated.

 

So basically, to get it running, I need to move my kexts in L/E, edit the config.plist, and I'm good to go. Right? And for now, stick to DP3/PB1 if I need a fresh install.

 

Crystal clear.

 

One thing I'll need to find out by myself (I guess you don't have Yosemite anymore, and that's ok ) and I'll post the result, if no one else replies in the meantime: I need to find out if this method will create any issues on current Yosemite installations. Moving the kexts probably won't create any issues since the systems are different, but adding those things in config.plist....might, because there is only one config.plist used to boot both OSes. So I will test that, and let you guys know.

 

Again, big thank you for your explanation!

[blackosx]

arsradu - Yosemite will not be affected by the addition of the CsrActiveConfig RtVariable entry in config.plist.

[arsradu]

arsradu - Yosemite will not be affected by the addition of the CsrActiveConfig RtVariable entry in config.plist.

And here's the answer to that question.

 

Thank you very much, blackosx!

[mhaeuser]

Well hello. Please read my blog post again (edited for clarity) and then remember that it is about kext injection in El Capitan with full SIP already in place. Also. I wasn't talking about implementing NVRAM settings. Just plain kext injection, but the proper way, which is still not done. Yes. I wonder why nobody told slice how he could fix it, but then again the DP4 that broke kext injection is how old again?

 

About the people who told you that they had been using "this" (whatever that may be) before, is rubbish. My POC is about El Capitan, and I do this without kext-dev-mode (in Mavericks/Yosemite) and/or rootless=0 in El Capitan. Neither do I need any of the CSR flags. That makes it a totally different story.

 

Alright, your latest 'revision' of the post is indeed clearing up a little (maybe would be good if you actually 'marked' changes so they are visible easily). You still use rootless arg/CSR flags to replace the prelinkedkernel in /S/L/K/ from what I can see.

 

So, what I meant the users did:

They copied the kexts to /S/L/E (I see you doing that as well, as you say you move them in Step 2). After, they rebuild the cache (Step 1's Note assumes that already). The cache now has the unsigned kexts in them and it loads quite well. Finally, they removed the kext-dev-mode flag (rootless/CSR flags in your PoC). What I see you doing after is moving the kexts out of the Extensions folders and change their paths in the __PRELINK_INFO:__info data from the prelinkedkernel (not 100% sure about the seg/sect names). If I understood all you are doing, the outcode is the exact same - unsigned kexts in cache and SIP enabled - beside that your kexts are in a different folder... because you moved them and changed strings.

For Clover's kext injection the path of the kext doesn't really matter anyway, as it's assumed on the ESP which is generally unmounted (except if you might change it to '/Volumes/EFI/Clover/kexts/10.11/...' while it is mounted). The interesting part for kext injection is what the cache updater is doing - splitting the kext's Info.plist, appending the binary to the kernel, add the partial Info.plist with _Prelinked info to the __info sect and so on, ... - and that isn't really addressed in your post.

I assumed the fact that signatures are only checked when building the cache as known (maybe not broadly, but it was provable within a few minutes and quite a few people did, maybe even without knowing what it meant) and beside that, I saw you showing that the kext can be moved out of /S/L/E, which of course works as the prelinkedkernel has everything necessary. The interesting part is changing the path as Resource accessing (e.g. layouts for AppleHDA) should still work that way. Would be cool if Clover injected kexts from the OS X partition as well as that means AppleHDA dummies can be injected into the cache and still work... hopefully.

Your point about the boot.plist still being in /Library is a nice one as well, as that way you could create and load such a modded prelinkedkernel entirely without disabling security. But otherwise, I see more value in researching how the prelinkedkernel is built and parsed so we can append kexts in memory, rather than letting the OS X utils do it.

[Pike R. Alpha]

Alright, your latest 'revision' of the post is indeed clearing up a little (maybe would be good if you actually 'marked' changes so they are visible easily). You still use rootless arg/CSR flags to replace the prelinkedkernel in /S/L/K/ from what I can see.

Yipes. No I don't. Thanks for spotting this – point 8 and 9 edited (with a note what I changed).

 

So, what I meant the users did:

They copied the kexts to /S/L/E (I see you doing that as well, as you say you move them in Step 2). After, they rebuild the cache (Step 1's Note assumes that already). The cache now has the unsigned kexts in them and it loads quite well. Finally, they removed the kext-dev-mode flag (rootless/CSR flags in your PoC). What I see you doing after is moving the kexts out of the Extensions folders and change their paths in the __PRELINK_INFO:__info data from the prelinkedkernel (not 100% sure about the seg/sect names). If I understood all you are doing, the outcode is the exact same - unsigned kexts in cache and SIP enabled - beside that your kexts are in a different folder... because you moved them and changed strings.

For Clover's kext injection the path of the kext doesn't really matter anyway, as it's assumed on the ESP which is generally unmounted (except if you might change it to '/Volumes/EFI/Clover/kexts/10.11/...' while it is mounted). The interesting part for kext injection is what the cache updater is doing - splitting the kext's Info.plist, appending the binary to the kernel, add the partial Info.plist with _Prelinked info to the __info sect and so on, ... - and that isn't really addressed in your post.

I assumed the fact that signatures are only checked when building the cache as known (maybe not broadly, but it was provable within a few minutes and quite a few people did, maybe even without knowing what it meant) and beside that, I saw you showing that the kext can be moved out of /S/L/E, which of course works as the prelinkedkernel has everything necessary. The interesting part is changing the path as Resource accessing (e.g. layouts for AppleHDA) should still work that way. Would be cool if Clover injected kexts from the OS X partition as well as that means AppleHDA dummies can be injected into the cache and still work... hopefully.

Your point about the boot.plist still being in /Library is a nice one as well, as that way you could create and load such a modded prelinkedkernel entirely without disabling security. But otherwise, I see more value in researching how the prelinkedkernel is built and parsed so we can append kexts in memory, rather than letting the OS X utils do it.

Correct. __PRELINK_INFO is used for the dictionary and __PRELINK_TEXT for the binaries. Note that signatures are stripped off before they get inserted into the pre linkedkernel. I did not add this info for a reason, because I have a tool that does everything for you.

 

About AppleHDA. Sure. Audio works here from /Extra/Extensions with my dummy kext, but I had to change the bundle names to the new path or it didn't work (bundle errors in system.log) so Apple is definitely checking the paths and bails out with an error when they can't be found.

 

I sure hope so that kext injection works a.s.a.p. when even I have no use of it, but I want everyone to be happy. The main problem with my write ups is that I have v dry little time, and then frustration and errors do slip in from time to time. Sorry for that.

 

Cheers!

[mhaeuser]

Your revised 'Step 8' should not need 'rootless=0', so I would remove the note.

Otherwise, the AppleHDA note is basically what I said and why I think changing the path is interesting.

 

Guess it's all clear now.

[arsradu]

So that didn't work quite as expected. I got no bootable El Capitan and now Yosemite doesn't boot either. I guess there is something I missed. I just don't know what. I'm reinstalling El Capitan DP1 right now, just to have a proper way to revert changes in config.plist. I guess I'll just wait for the Clover team to get the injection sorted out.

[WaldMeister]

Upgraded to Public Beta 3 with Clover rev 3252.

Kexts loaded from /L/E/.

 

Audio works (Clover binpatch), and so does patching the Intel HD4600 kexts, framebuffer and id from 0412 to 0416. 

 

Before the upgrade i disabled SIP with csrutil disable, now on PB3 i get the following error enabling it: 

Last login: Thu Jul 30 20:56:21 on console
Restored session: do 30 jul 2015 20:54:33 CEST
p70:~ Lex$ csrutil status
System Integrity Protection status: disabled.
p70:~ Lex$ csrutil disable
csrutil: failed to modify system integrity configuration. This tool needs to be executed from the Recovery OS.
p70:~ Lex$ sudo csrutil enable
Password:
csrutil: failed to modify system integrity configuration. This tool needs to be executed from the Recovery OS.

[En0r1m]

You could try running this command through your recovery partition?

[WaldMeister]

You could try running this command through your recovery partition?

In PB 2 this was possible from the OS, so something has changed in this matter. 

[tachikaze]

beta 5 also doesn't allow setting this from a normal boot . . .

[Asgorath]

That's the whole point of the new CsrActiveConfig setting in config.plist, you can set this to the same value as "csrutil disable" on a real Mac (currently 0x67 as I understand it).  This lets Clover set the NVRAM variable for the OS, since you can't modify the csr-active-config value directly outside of the recovery OS.

[tachikaze]

Anybody know what is CSR, btw, and how is it different from MSR?

 

I assume it's structured nvram storage, so both Windows and OS X can share it, but CSR seems more complex than MSR . . .

 

If I have a gigabyte Z97 mb, is it safe to boot into the 10.11 installer and (try to) turn security off via the utility menu command?

 

Apple says once you do that that setting will persist between OS installs, since it is in NV storage . . .

[mhaeuser]

NVRAM is always shared as it's hardware storage (on the flash chip). Also, MSR is a type of CPU register and even if I'm not sure what CSR is an acronym for, it's related to Apple's security.

[tachikaze]

Decided to go with v2.3k 3252, SIP is no longer in the house!

 

Here's hoping Apple stays cool with that . . .

[Pike R. Alpha]

Anybody know what is CSR, btw, and how is it different from MSR?

 

I assume it's structured nvram storage, so both Windows and OS X can share it, but CSR seems more complex than MSR . . .

 

If I have a gigabyte Z97 mb, is it safe to boot into the 10.11 installer and (try to) turn security off via the utility menu command?

 

Apple says once you do that that setting will persist between OS installs, since it is in NV storage . . .

Code Signing Restrictions, which works with entitlements, linked in with the signing of applications and kexts. If you need extra privileges, then you have to tell Apple why and ask Apple to lift it for you. If Apple thinks that it is something that is too restrictive, then they may lift it for everyone.

[Slice]

Anybody know what is CSR, btw, and how is it different from MSR?

 

I assume it's structured nvram storage, so both Windows and OS X can share it, but CSR seems more complex than MSR . . .

 

If I have a gigabyte Z97 mb, is it safe to boot into the 10.11 installer and (try to) turn security off via the utility menu command?

 

Apple says once you do that that setting will persist between OS installs, since it is in NV storage . . .

csr-active-config variables has AppleBootGuid and so will not affect Windows.

[rotoyouoio]

 

 

so is there any hope that we'll get back kext injection from the esp? if not, then perhaps clover can inject kexts to L/E from its esp storage if they are absent? seems like the nearest solution

 

also, does binary kext patching work only with 0x67 config? that's a question not only for Slice

[Slice]

so is there any hope that we'll get back kext injection from the esp?

I hope we will resolve the problem.

[calibre™]

i am maybe missing something in here... Is there such rootless=0 in Yosemite? I never had use it except for kext-dev-mode

[magnifico]

I hope we will resolve the problem.

I am confident you. ...I am convinced that manage to solve .

go go Sergey. ..you are the special one

[arsradu]

I hope we will resolve the problem.

You can do it.

 

And we're here to help, if anything.

[rotoyouoio]

so does binary kext patching work only with 0x67 config? that's a question not only for Slice

[calibre™]

Is there such rootless=0 flag in yosemite? Afaik, there is only kext-dev-mode. Correct me if im wrong. Maybe im missing out something in here.

Thanks

[WaldMeister]

so does binary kext patching work only with 0x67 config? that's a question not only for Slice

 

I did not set this flag and binary patching works for the AppleHDA, i gave up on the HD46000 patching.