I only shared my view on this matter, and used RevoBoot because that makes things easier for me. Something that Clover and Chameleon can do for quite some time already, so please keep using the boot loader of your choice. What you want is a boot loader that can inject the required kext for you. And it does that just like any other booter would do, including boot.efi This way RevoBoot loads that instead of the normal prelinkedkernel. For this to work I added a “Kernel Cache” property in /Library/Preferences/ with a string value pointing to the modified prelinkedkernel. Not yet that it, but adding support for it would have been a lot of work, and that is why I chose to modify the prelinkedkernel instead. I use RevoBoot as my primary boot loader of choice for my Hack, but it can’t inject kexts. I use a self written command line tool called LZVN to unpack and repack the prelinkedkernel, but the current version needs a few small changes to automate the process of unpacking, repacking, calculating the adler32, fixing the offset and size of the (un)compressed file. The former with LZVN – I blogged about changing the compression type and the new, at that time, LZVN compression here OS X 10.10 Yosemite DP1 kernel(cache). The prelinkedkernel replaces the old /System/Library/Caches//Startup/kernelcache and is compressed with LZSS. Not that it really matters for this POC but anyway. The prelinkedkernel is located in /System/Library/prelinkedkernels and is loaded by boot.efi, or in case of a legacy boot loader. A group of Clover users even offered me to pay a 1800 Euro bounty (2000 Dollar), but I declined their offer. This was why I looked into it, to see if I could find a workaround, so that the Clover developers can solve this issue. Clover kext injection used to work, but works differently than what I envision, and now also fails in DP4. That will certainly change now that I have seen the use of it. Some boot loaders can inject kexts, like FakeSMC.kext, but RevoBoot is not one of them. Slice, the Clover project owner and main developer, also recently implemented a Clover option to set the NVRAM key csr-active-config (see nvram -xp).
This is also what I use for the third Developer Preview of El Capitan in RevoBoot and the Enoch branch of Chameleon. #define CSR_VALID_FLAGS (CSR_ALLOW_UNTRUSTED_KEXTS | \ #define CSR_ALLOW_UNRESTRICTED_NVRAM (1 << 6) // 64 #define CSR_ALLOW_UNRESTRICTED_DTRACE (1 << 5) // 32 #define CSR_ALLOW_APPLE_INTERNAL (1 << 4) // 16 #define CSR_ALLOW_KERNEL_DEBUGGER (1 << 3) // 8 #define CSR_ALLOW_TASK_FOR_PID (1 << 2) // 4 #define CSR_ALLOW_UNRESTRICTED_FS (1 << 1) // 2 #define CSR_ALLOW_UNTRUSTED_KEXTS (1 << 0) // 1 Another option is to use the Security Configurator utility to toggle a checkbox, or run csrutil from the Recovery OS.Īpple already said that rootless=0 will be absolute, in due time, and then we have to use the Security Configurator… or use a boot loader that sets boot flag CSR_ALLOW_UNTRUSTED_KEXTS to allow unsigned kexts 😉 OS X won’t load/execute unsigned kexts, unless you use kext-dev-mode=1 in Mavericks and Yosemite for /Library/Extensions, but this setting is obsolete in El Capitan so you either have to use rootless=0 (now also obsolete in El Capitan) or all unsigned kexts will fail to load. We could add another hack to hide kexts in kextstat, and that makes it even worse. Running kextstat does shows all loaded kexts, so it’s not that hidden, but cleaner anyway. This way unsigned kexts won’t show up in System Information/Software/Extensions, which in my view makes it somewhat harder to detect. I use /Extra/Extensions for unsigned kexts, so that the /Library/Extensions and /System/Library/Extensions directories can be kept vanilla/untouched. Extra/Extensions/AppleEmulator.kext (your FakeSMC.kext)
#OSX EDNABLE CSRUTIL AFTER OPENZFS INSTALL CODE#
This means that I run my hack with maximum System Integrity Protection (SIP) activated (no rootless=0 boot argument/runtime/NVRAM variables to bypass the code signing restrictions) with the following unsigned kexts: This time I did it differently, and this blog post is a short and simple POC (proof of concept) to show you that bypassing Apple’s rather strict kext signing restrictions still works. I have found a very simple way to bypass Apple’s kext signing in El Capitan, like I did before in Yosemite and Mavericks before that.
0 kommentar(er)
