OS X El Capitan DP's builds!

[arsradu]

I ran Toleda’s audio_realtekALC-110_v1.0b.command script on 10.11 DP5, booted using csr 0x65. Works great.

 

For Disk Utility, you can select your volume and click the ‘First Aid’ button. I’m sure that will correct any incorrect permissions.

 

Leaving kexts in EFI/Clover/Kexts/ won’t cause any issues.

Thank you very much for your reply.

 

Unfortunately repair permissions function has been completely removed from El Capitan (at least that's what Wiki says, and also, what my experience with this shows, so far). It's said that it's not necessary anymore since the updates will do it. In other words, Apple removed the ability for the user to repair permissions so that they can do it. And the First Aid button will do a bunch of stuff but repair permissions it will not.

Leaving the kexts at their own location in  EFI/Clover/kexts doesn't cause any issues with either El Capitan, or Yosemite. That's true.

 

However, I could not boot that thing, for the love of God!

 

Kexts are in L/E (copy-pasted there), I set permissions for each individual custom kexts I've got using:

chown root:wheel /Volumes/ElCapitan/Library/Extensions/kext.kext

I also (though I'm not sure that is necessary) removed kext caches so that they can be rebuilt on next startup using this command:

rm -r /Volumes/ElCapitan/System/Library/Caches/com.apple.kext.caches/Startup/*

Also, I added 0x67 to config.plist (though my csrutil was always showing status disabled, even without adding that to the config - anyone else got the same status by default? - ) using this:

<key>CsrActiveConfig</key>
<string>0x67</string>
<key>BooterConfig</key>
<string>0x28</string>

Result is that booting hangs in mid air with El Capitan. And I have no idea what's causing it.

 

Does it make any difference if the kexts are in L/E or S/L/E? At some point, I think Pike R Alpha said that it would be recommended not to touch S/L/E. And since L/E was reported to work just as well, I though I would stick with L/E for now. Problem is I still can't boot the damn thing.

 

Also, any idea if Clover 3253 got the kext injection from EFI figured out? Cause it still doesn't seem to work for me.

[polyzargone]

Kexts are in L/E (copy-pasted there), I set permissions for each individual custom kexts I've got using:

chown root:wheel /Volumes/ElCapitan/Library/Extensions/kext.kext

 

Try this instead :

chown -R root:wheel /Volumes/ElCapitan/Library/Extensions/kext.kext

or

chown -R 0:0 /Volumes/ElCapitan/Library/Extensions/kext.kext

[arsradu]

 

Try this instead :

chown -R root:wheel /Volumes/ElCapitan/Library/Extensions/kext.kext

or

chown -R 0:0 /Volumes/ElCapitan/Library/Extensions/kext.kext

I will try that too, thank you. However, the kexts in L/E seem to have all the same permission level. So....I'm not sure the issue is with the permissions (see below a comparison between a built-in kext and a custom one, in terms of permissions).

 

Also, maybe I'm wrong, but isn't the -R parameter supposed to be used with folders, in order to apply the command recursively? I'm not sure it's making any difference if it's applied to a file.

 

 

[polyzargone]

Well I'm not an expert but -R means that modifications will be applied recursively so the permissions for every single file within the kext will be set. Your kexts may looks OK but actually they're not.

 

Anyway, it's just my guess. Someone will confirm or infirm this but you can give it a try…

[arsradu]

Well I'm not an expert but -R means that modifications will be applied recursively so the permissions for every single file within the kext will be set. Your kexts may looks OK but actually they're not.

 

Anyway, it's just my guess. Someone will confirm or infirm this but you can give it a try…

You are correct. I can give it a try. And I did.

 

Result? I'm typing this message from ElCapitan DP4, which means that you were right. It does make a difference. And I did check before running those commands to see if I had the same permissions on the Contents folder of the FakeSMC kext, compared to the others. And I didn't. After running the commands (I'm not sure the first one did the trick, since I ran it from single user mode, and it did say something about the files being "read-only system file" or something like this). Anyway, I ran the second command from Yosemite, so I can check the result (Contents folder changing permissions) in real time. So, I'm not sure. Maybe the first command works just as well, maybe only the second one works.

 

Bottom line: it works!

 

And apparently you were right about -R. I don't know why kexts are folders, with extensions... Maybe I'm used to Linux and Windows. To me, a file.kext, is a damn file, not a folder! But apparently Apple "thinks different". Quite literally.

 

Anyway, big thank you for your help. I will go ahead and apply the DP5 update now. Fingers crossed. Toes too.

 

Update1: Apparently it wasn't DP5, but PB3. Kinda weird that I get both. And yes, it does work. Now I just need to figure out the sound with toleda's script.

 

Update2: Now with sound, thanks to toleda's script version d (audio_cloverALC-110_v1.0d.command). Awesome job, as usual. I just ran the script (with EFI mounted) and SIP disabled completely (if I got it correctly adding 0x67 will do that for you, even though, as I said, I already had that disabled in DP3, even without adding anything in Clover config, so...I don't know).

 

Now, I've got a question: can we enable SIP (and if so, will "csrutil enable" do that?) and still run these custom kexts? Is there a problem if SIP is permanently disabled? Will enabling it cause the system not to boot anymore after an upgrade?

[wegface]

 I don't know why kexts are folders, with extensions... Maybe I'm used to Linux and Windows. To me, a file.kext, is a damn file, not a folder! But apparently Apple "thinks different". Quite literally.

 

 

Open a kext in finder and you will see it is a folder. Pretty useful method imo.

[arsradu]

Open a kext in finder and you will see it is a folder. Pretty useful method imo.

I did notice that. But I just didn't know that when you apply permissions to a kext, even though it looks like an individual file (.app, .ipa and other Apple proprietary files behave the same way), it's actually a packaged folder and you need to treat it like a folder, meaning applying permissions recursively. Well, now I know. Thank you.

[toleda]

As far as I knoww, toleda audio_realtekALC will modify /S/L/E/AppleHDA.kext, so 0x65 allows this?

Yes.

Suggest patch with 0x3 (UNTRUSTED_KEXTS + UNRESTRICTED_FS), not 0x40, 0x65, 0x57, etc.

Reboot with 0x0. Audio works, SIP enabled.

[arsradu]

Yes.

Suggest patch with 0x3 (UNTRUSTED_KEXTS + UNRESTRICTED_FS), not 0x40, 0x65, 0x57, etc.

Reboot with 0x0. Audio works, SIP enabled.

1. thank you very much for your tremendous work!

2. so, you're suggesting this:

 

     

        <key>CsrActiveConfig</key>
        <string>0x3</string>
        <key>BooterConfig</key>
        <string>0x28</string>

instead of this?

        <key>CsrActiveConfig</key>
        <string>0x67</string>
        <key>BooterConfig</key>
        <string>0x28</string>

Did I get this right? Or should it be 0x03? Or it doesn't matter since it's the same thing?

 

For as far as I could see, the latest versions of Clover will disable SIP even without adding that in RtVariables. Not sure how it's doing it...

 

So, my questions are:

1. is my assumption above correct in order to have working audio and SIP enabled? It's working just fine with 0x67, as well. So it's not a problem of working vs not working audio.

2. how would you even enable SIP after reboot if Clover disables it by default?

3. assuming you will be able to reenable SIP (not sure enabling it form Recovery will actually work, since, as I said, somehow, Clover seems to disable it anyway), will you be able to boot with SIP enabled and kexts (FakeSMC in particular) in Library/Extensions?

 

Also, I'm not sure if I did something wrong or not, but I got endless reboots if I just change 0x67 to 0x0. I saw someone saying 0x00. Haven't tried that yet. But does it even make any difference?

[FredWst]

1. thank you very much for your tremendous work!

2. so, you're suggesting this:

 

     

        <key>CsrActiveConfig</key>
        <string>0x3</string>
        <key>BooterConfig</key>
        <string>0x28</string>

instead of this?

        <key>CsrActiveConfig</key>
        <string>0x67</string>
        <key>BooterConfig</key>
        <string>0x28</string>

Did I get this right? Or should it be 0x03? Or it doesn't matter since it's the same thing?

 

For as far as I could see, the latest versions of Clover will disable SIP even without adding that in RtVariables. Not sure how it's doing it...

 

So, my questions are:

1. is my assumption above correct in order to have working audio and SIP enabled? It's working just fine with 0x67, as well. So it's not a problem of working vs not working audio.

2. how would you even enable SIP after reboot if Clover disables it by default?

3. assuming you will be able to reenable SIP (not sure enabling it form Recovery will actually work, since, as I said, somehow, Clover seems to disable it anyway), will you be able to boot with SIP enabled and kexts (FakeSMC in particular) in Library/Extensions?

 

Also, I'm not sure if I did something wrong or not, but I got endless reboots if I just change 0x67 to 0x0. I saw someone saying 0x00. Haven't tried that yet. But does it even make any difference?

 

Install your kexts and rebuild cache with csr-active-config=0x67 or 0x03 

reboot

you can set csr-active-config=0 to get full protection.

reboot.

Don't rebuild kernel cache with csr-active-config=0

 

BootConfig is relative to Clover not Osx. (Slice Correct me if i'm wrong)

 

As explain on forum most important thing is to put kext in L/E or S/L/E build kernel cache with csr-active-config = 0x67; 

After that you could set car-active-config=0 and don't rebuild cache !

 

Fred

[artur_pt]

hello

 

csr config

0x00 (00000000)0 CSR_ALLOW_UNTRUSTED_KEXTS 
0 CSR_ALLOW_UNRESTRICTED_FS
0 CSR_ALLOW_TASK_FOR_PID
0 CSR_ALLOW_KERNEL_DEBUGGER
0 CSR_ALLOW_APPLE_INTERNA
0 CSR_ALLOW_UNRESTRICTED_DTRACE
0 CSR_ALLOW_UNRESTRICTED_NVRAM

0x67 (01100111)
1 CSR_ALLOW_UNTRUSTED_KEXTS 
1 CSR_ALLOW_UNRESTRICTED_FS
1 CSR_ALLOW_TASK_FOR_PID
0 CSR_ALLOW_KERNEL_DEBUGGER
0 CSR_ALLOW_APPLE_INTERNA
1 CSR_ALLOW_UNRESTRICTED_DTRACE1 CSR_ALLOW_UNRESTRICTED_NVRAM

0x3 (01100000)

1 CSR_ALLOW_UNTRUSTED_KEXTS 
1 CSR_ALLOW_UNRESTRICTED_FS
0 CSR_ALLOW_TASK_FOR_PID
0 CSR_ALLOW_KERNEL_DEBUGGER
0 CSR_ALLOW_APPLE_INTERNA
0 CSR_ALLOW_UNRESTRICTED_DTRACE1 CSR_ALLOW_UNRESTRICTED_NVRAM

good hack

[toleda]

Did I get this right? Or should it be 0x03? Or it doesn't matter since it's the same thing?

 

For as far as I could see, the latest versions of Clover will disable SIP even without adding that in RtVariables. Not sure how it's doing it...

 

So, my questions are:

1. is my assumption above correct in order to have working audio and SIP enabled? It's working just fine with 0x67, as well. So it's not a problem of working vs not working audio.

2. how would you even enable SIP after reboot if Clover disables it by default?

3. assuming you will be able to reenable SIP (not sure enabling it form Recovery will actually work, since, as I said, somehow, Clover seems to disable it anyway), will you be able to boot with SIP enabled and kexts (FakeSMC in particular) in Library/Extensions?

 

got endless reboots if I just change 0x67 to 0x0. I saw someone saying 0x00. Haven't tried that yet. But does it even make any difference?

Yes, the 0x3 property is a string, no difference for 0x03.  It the property was data, the hex values are different. 

Once kernel cache is built with unsigned kexts, SIP (0) can be enabled and restarted.  Audio will work with every boot until something causes a kernel cache rebuild with SIP enabled. 

My opinion, Clover should boot with SIP enabled. User controls when to disable SIP and how long.

Most kexts work from EFI.  FakeSMC can be installed in L/E or S/L/E with 0x3.

Auto reboot with 0x0 is a different problem.

 

csr config

0x67 
1 CSR_ALLOW_UNTRUSTED_KEXTS 
1 CSR_ALLOW_UNRESTRICTED_FS
1 CSR_ALLOW_TASK_FOR_PID
0 CSR_ALLOW_KERNEL_DEBUGGER
0 CSR_ALLOW_APPLE_INTERNA
0 CSR_ALLOW_UNRESTRICTED_DTRACE1 
1 CSR_ALLOW_UNRESTRICTED_NVRAM

0x67 does not look right, last line is 2 lines (edited above) 0x47 (hex) for the bits noted.

[arsradu]

Yes, the 0x3 property is a string, no difference for 0x03.  It the property was data, the hex values are different. 

Once kernel cache is built with unsigned kexts, SIP (0) can be enabled and restarted.  Audio will work with every boot until something causes a kernel cache rebuild with SIP enabled. 

My opinion, Clover should boot with SIP enabled. User controls when to disable SIP and how long.

Most kexts work from EFI.  FakeSMC can be installed in L/E or S/L/E with 0x3.

Auto reboot with 0x0 is a different problem.

Thank you very much, toleda!

 

I think I'm gonna choose to lower access permission to 0x3, rather than enabling full SIP, which, if artur's post is correct, should allow access to:

 

1. UNTRUSTED KEXTS

2. UNRESTRICTED FS (I assume that stands for FileSystem)

3. UNRESTRICTED NVRAM (?) Is this one enabled or disabled? Cause I don't get it. 01100000 suggests it's disabled, but the 1 in front of it suggests it's enabled. So, which one is it?

 

The reason why I wouldn't go for full SIP enabled is that I might forget to turn it off before the next EC update. And, since that update will probably cause a kernel cache rebuild, booting with SIP enabled will cause FakeSMC not to be loaded anymore, and the system not to boot anymore. So...I think I'm gonna stick with 0x3 for now (assuming everything will be ok with that).

 

And I do agree that Clover should have a way for the user to enable/disable SIP and for how long. I think adding such options in Clover pref pane might be a good idea.

[toleda]

I think I'm gonna choose to lower access permission to 0x3,

1. UNTRUSTED KEXTS

2. UNRESTRICTED FS (I assume that stands for FileSystem)

3. UNRESTRICTED NVRAM (?)

 

The reason why I wouldn't go for full SIP enabled is that I might forget to turn it off before the next EC update.

 

0x1 is all the protection you need for the next EC update.  That can be set with the restart initiated by Software Update.

Other choices from the list above:

1&2 = 0x3

1&3 = 0x41

1-3 = 0x43

 

edit: 8/1/15

[arsradu]

0x1 is all the protection you need for the next EC update.  That can be set with the restart initiated by Software Update.

Other choices from the list above:

1&2 = 0x3

1&3 = 0x21

1-3 = 0x23

I'm not an expert by any means in binary or hex ) , but if choices 1&2 from my list are 0x3 (00000011), then for choices 1&3 (untrusted kexts & unrestricted nvram), shouldn't the hex be 0x41 (01000001) and 0x43 (01000011) for 1-3? I'm just curious if I got this right. Please, correct me if I'm wrong. I don't mind it at all. I prefer to learn than stay a noob.

Also, again, big thank you for everything you do on this forum. Very much appreciated.

[toleda]

I'm just curious if I got this right. Please, correct me if I'm wrong.

You are correct, post updated. Tables above combined last 2 lines.

[arsradu]

You are correct, post updated. Tables above combined last 2 lines.

Yep. Noticed that. This is why I thought I would better ask, just to make sure. Thank you, toleda.

[artur_pt]

hello

 

all this is experimental .. is beta stage and dev stage .. what will be important is to just have clover injecting kext in cache ... like is doing in yosemite .. just expect more surprises in next beta or dp.. 

 

only is a trick to foul the system .. 

 

not easy install el capo from start .. without another os x running

 

so .. test and test .. to allow dev have info about what is happening

 

if u have all working and no problems with cache .. no major problems updating .. like my update do dp5 .. only use the trick to foul the system and to have access to the kext .. to test after the update ..  i just enable the SIP always

 

good hack

[DMCrimson]

https://pikeralpha.wordpress.com/2015/07/28/apples-kext-signing-bypassed/

@arsradu, there's some explanation on those.

[a3yu]

Thx All for all your work!

No more rootless and all works With csractiveconfig

[René_]

I'm not an expert by any means in binary or hex ) , but if choices 1&2 from my list are 0x3 (00000011), then for choices 1&3 (untrusted kexts & unrestricted nvram), shouldn't the hex be 0x41 (01000001) and 0x43 (01000011) for 1-3? I'm just curious if I got this right. Please, correct me if I'm wrong. I don't mind it at all. I prefer to learn than stay a noob.

Also, again, big thank you for everything you do on this forum. Very much appreciated.

Maybe this can help.

0x67 (01100111) = 103 dec
1 CSR_ALLOW_UNTRUSTED_KEXTS       // 1 flag set = 1
1 CSR_ALLOW_UNRESTRICTED_FS       // 2 flag set = 2
1 CSR_ALLOW_TASK_FOR_PID          // 4 flag set = 4 
0 CSR_ALLOW_KERNEL_DEBUGGER   // 8 flag not set = 0
0 CSR_ALLOW_APPLE_INTERNAL   // 16 flag not set = 0
1 CSR_ALLOW_UNRESTRICTED_DTRACE // 32 flag set = 32
1 CSR_ALLOW_UNRESTRICTED_NVRAM  // 64 flag set = 64
                                           ————————-
                                          total 103 decimal > 0x67 HEX > 01100111 binary
(01100111) > values from last to first
0 = leading zero
1 1 1 0  0  1  1 > byte = 1 is on, 0 is off.
1 2 4 8 16 32 64 > binary code
result > 1+2+4+0+0+32+64 = 103 decimal = 0x67 hex

[arsradu]

Maybe this can help.

0x67 (01100111) = 103 dec
1 CSR_ALLOW_UNTRUSTED_KEXTS       // 1 flag set = 1
1 CSR_ALLOW_UNRESTRICTED_FS       // 2 flag set = 2
1 CSR_ALLOW_TASK_FOR_PID          // 4 flag set = 4 
0 CSR_ALLOW_KERNEL_DEBUGGER   // 8 flag not set = 0
0 CSR_ALLOW_APPLE_INTERNAL   // 16 flag not set = 0
1 CSR_ALLOW_UNRESTRICTED_DTRACE // 32 flag set = 32
1 CSR_ALLOW_UNRESTRICTED_NVRAM  // 64 flag set = 64
                                           ————————-
                                          total 103 decimal > 0x67 HEX > 01100111 binary
(01100111) > values from last to first
0 = leading zero
1 1 1 0  0  1  1 > byte = 1 is on, 0 is off.
1 2 4 8 16 32 64 > binary code
result > 1+2+4+0+0+32+64 = 103 decimal = 0x67 hex

Even though some of this I already got from previous posts of people over here explaining it, your additions surely did help me understand it better.

 

So, a big thank you for that.

 

Still, one thing is not clear. What exactly do all those things do? I know what some of them do, like "allow untrusted kexts" (it's a pretty obvious one too, lol) or "allow unrestricted fs" or NVRAM. But I gotta say, I'm not 100% sure about the rest of them. Could you help with those as well, please?

[René_]

I'm not an expert too and don't know when to use those other flags. Do not need them at the moment.

For me 0x67 or 0x03 works to rebuild the cache correctly. Just like artur-pt.

After rebuild I put the defaults back 0x00.

Maybe we will need those flags with the next EC update, who knows?

[Micky1979]

Topic cleaned, please Guys stay on Topic.

[Wayang-NT]

new seed ... beta 6 build 15A244d ...