Another one bites the dust…

I found something in the kernel that will likely – with almost 100% certainty – not be released by Apple:

int mac_iokit_check_nvram_delete(kauth_cred_t cred, const char *name);
int mac_iokit_check_nvram_get(kauth_cred_t cred, const char *name);
int mac_iokit_check_nvram_set(kauth_cred_t cred, const char *name, io_object_t value);

The last one is called by AppleEFINVRAM to block access to NVRAM for get/set/remove property functions, and the sandbox kext has hooks to it. The sandbox may have the platform profile, but AppleEFINVRAM acts as last defence. The guardian. So how do we bypass this you ask? For now we have three options on hack:

1.) Use FileNVRAM.kext to override the calls to get/set/remove property, and thus it won’t check for it.

2.) Replace AppleEFINVRAM.kext with an older version that does not call to checks. I used the one from 10.9.5 and it worked.

3.) Patch the AppleEFINVRAM.kext binary with:

perl -pi -e 's|\x0F\x85\x40\x01\x00\x00|\x90\x90\x90\x90\x90\x90|' AppleEFINVRAM

What this does is that it NOPs out the JNE instruction. The call to _mac_iokit_check_nvram_set in the kernel, and thus the check won’t be done. That’s all. Nothing more. Meaning that you can run csrutil disable from the command line, without the need to boot into the Recovery HD, and still get:

Successfully disabled System Integrity Protection. Please restart the machine for the changes to take effect.

But running nvram csr-active-config=%77%00%00%00 will fail due to the missing entitlement (

However. The fourth, and best option in my view, is to boot into the Recovery HD and be able to run csrutil disable from there. One problem. On a hack you still need one of the above workarounds, and on unsupported hardware for El Capitan… we need to get csrutil disable going. The problem is that I seem to be the last person willing to help others with running El Capitan on unsupported hardware. Like I did for Yosemite. And things are taking a lot of time. Tons of time… but we already made a lot of progress so hang in guys!!!

Anyway. Sure. Apple may not release all parts of the kernel, but what is the point of having an open source kernel, when almost everything that is interesting… is never released? Think about LZVN, XCPM and now this. Another one bites the dust. Yeah. Someone should kick Apple in the teeth for their lousy open source policy.

Note: I don’t know if csrutil disable works on Clover, but I will add it when I get a confirmation about it.

Edit: I forgot to mention that there a six more routines in the kernel. Look here:


6 thoughts on “Another one bites the dust…

  1. Simply, Wow! So that explains the problem we’ve been experiencing with the macosxbootloader. Do let us know when/how to proceed.

  2. Pike, according to , “[f]or Hackintosh, boot loader[s] like Chameleon and Clover already support setting CSR valid flags to turn off protections for the hack”.

    On the other hand, there seems to be some conflicting and/or confirming evidence in

    In someone says the system announces success, but, after rebooting, SIP is still in place.

    • I know. RevoBoot was the first boot loader to support SIP. Then came Chameleon, with my help, and then Clover. Like I did for Yosemite. Pretty sure that nobody did more research on El Capitan and SIP than me, and I haven’t published everything I know. I also won’t support a runtime configuration file, because that not safe. We want it to work like it was supposed to work on a (supported) Mac.

  3. Pingback: csrutil (SIP) disable(d) from the command prompt | Pike's Universum

  4. Pingback: OS X NVRAM Restriction Bypassed | Delta's Lair

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s