Apple’s kext signing bypassed…

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. 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. Even in El Capitan DP5. 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:

/Extra/Extensions/AppleHDA892.kext
/Extra/Extensions/AppleIntelE1000e.kext
/Extra/Extensions/AppleEmulator.kext (your FakeSMC.kext)

I use /Extra/Extensions for unsigned kexts, so that the /Library/Extensions and /System/Library/Extensions directories can be kept vanilla/untouched. This way unsigned kexts won’t show up in System Information/Software/Extensions, which in my view makes it somewhat harder to detect. Sure. Running kextstat does shows all loaded kexts, so it’s not that hidden, but cleaner anyway. We could add another hack to hide kexts in kextstat, and that makes it even worse.

A Little Background Info
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. Another option is to use the Security Configurator utility to toggle a checkbox, or run csrutil [enable/disable] from the Recovery OS.

Screenshot of the SecurityConfiguration App

Apple 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 😉

#ifndef CSR_VALID_FLAGS
	/* Rootless configuration flags */
	#define CSR_ALLOW_UNTRUSTED_KEXTS		(1 << 0)	// 1
	#define CSR_ALLOW_UNRESTRICTED_FS		(1 << 1)	// 2
	#define CSR_ALLOW_TASK_FOR_PID			(1 << 2)	// 4
	#define CSR_ALLOW_KERNEL_DEBUGGER		(1 << 3)	// 8
	#define CSR_ALLOW_APPLE_INTERNAL		(1 << 4)	// 16
	#define CSR_ALLOW_UNRESTRICTED_DTRACE	(1 << 5)	// 32
	#define CSR_ALLOW_UNRESTRICTED_NVRAM	(1 << 6)	// 64

	#define CSR_VALID_FLAGS (CSR_ALLOW_UNTRUSTED_KEXTS | \
			CSR_ALLOW_UNRESTRICTED_FS | \
			CSR_ALLOW_TASK_FOR_PID | \
			CSR_ALLOW_KERNEL_DEBUGGER | \
			CSR_ALLOW_APPLE_INTERNAL | \
			CSR_ALLOW_UNRESTRICTED_DTRACE | \
			CSR_ALLOW_UNRESTRICTED_NVRAM)
#endif

This is also what I use for the third Developer Preview of El Capitan in RevoBoot and the Enoch branch of Chameleon. 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).

Kext Injection
Some boot loaders can inject kexts, like FakeSMC.kext, but RevoBoot is not one of them. That will certainly change now that I have seen the use of it. Anyway. Clover kext injection used to work, but works differently than what I envision, and now also fails in DP4. This was why I looked into it, to see if I could find a workaround, so that the Clover developers can solve this issue. A group of Clover users even offered me to pay a 1800 Euro bounty (2000 Dollar), but I declined their offer.

Prelinkedkernel
The prelinkedkernel is located in /System/Library/prelinkedkernels and is loaded by boot.efi, or in case of a legacy boot loader.. the boot loader. Not that it really matters for this POC but anyway. The prelinkedkernel replaces the old /System/Library/Caches/com.apple.kext.caches/Startup/kernelcache and is compressed with LZSS. 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).

Tools
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.

Bootloader
I use RevoBoot as my primary boot loader of choice for my Hack, but it can’t inject kexts. 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. For this to work I added a “Kernel Cache” property in /Library/Preferences/com.apple.Boot.plist with a string value pointing to the modified prelinkedkernel. This way RevoBoot loads that instead of the normal prelinkedkernel. And it does that just like any other booter would do, including boot.efi

Sure. What you want is a boot loader that can inject the required kext for you. Something that Clover and Chameleon can do for quite some time already, so please keep using the boot loader of your choice. I don’t care. Really. I only shared my view on this matter, and used RevoBoot because that makes things easier for me. Thing is. Since this works with a modified copy of a prelinkedkernel, then it will work with my type of kext injection. Someone just need to write/patch the code for it.

Kext Injection
Like I said earlier; RevoBoot cannot inject kext and the main reason for this is twofold.
1) I had no need for it.
2) I like to write my own code.

Nope. Nobody learns anything from a simple copy/paste action, and thus that won’t happen. I also want to do things differently. The reason for this is simple. I found out – the hard way for the macosxbootloader project – that boot.efi was changed in Yosemite, and it is likely going to be changed in the near future as well, so we need to do things a bit differently, so please note that we are not going to create a prelinkedkernel from scratch. I can, but it takes too much time to explain/write it all up!

Ok. Let’s get cracking (still a work-in-progress) but only start doing this when you know what you are doing. Be aware that mistakes can render your Mac/Hack unbootable!

1) cp /System/Library/Prelinkedkernels/prelinkedkernel ~/prelinkedkernel_el_capitan

Note: The unsigned kexts must already be included in your prelinkedkernel, for this POC, but only to make things simpler and easier to understand.

2) Move all unsigned kexts out of /Library/Extensions and /System/Library/Extensions into /Extra/Extensions

Note: Don’t skip this step, or it won’t work!

3) Run ./lzvn -d [path]prelinkedkernel_el_capitan [path]prelinkedkernel_el_capitan_unpacked

4) Change the _PrelinkBundlePath of all unsigned kexts into /Extra/Extensions/[kext-name].kext

Note: Don’t skip this step, or it won’t work!

5) Run ./lzvn [path]prelinkedkernel_el_capitan_unpacked [path]prelinkedkernel_el_capitan_repacked

6) Load prelinkedkernel_el_capitan in a hex editor and copy the first 412/0x19c bytes. It looks like this:

CA FE BA BE 00 00 00 01 01 00 00 07 00 00 00 03
00 00 00 1C 01 19 15 09 00 00 00 00 63 6F 6D 70
6C 7A 76 6E D1 E2 8A C2 02 EF 40 00 01 19 13 89
00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00

The red value 01 19 15 09 is the file size minus 28/0x1c. The purple value D1 E2 8A C2 is the checksum (adler32). The brown value 02 EF 40 00 is the size of the uncompressed file. The blue value 01 19 13 89 is the size of the compressed file. Nothing new, and the required values can be found in the output of LZVN. I myself kept the length the same (added a couple of zero’s).

Note: Please wait for me to update my LZVN repository if you don’t want to mess with this.

7) Fix the coloured values and insert the 412/0x19c bytes at the top of [path]prelinkedkernel_el_capitan_repacked

8) Save the file and copy it to: /Extra/Prelinkedkernels/Prelinked_El_Capitan_Patched, or use any other location that allows you to write the file to.

Edit: Oops. I changed the path from /System/Library/Prelinkedkernels to /Extra/Prelinkedkernels because that is what I use.

9) Open /Library/Preferences/SystemC*/com.apple.Boot.plist with nano (example) and add a “Kernel Cache” key property. Below that you add a string property with the value pointing to your copy of the prelinkedkernel. In my case: /Extra/Prelinkedkernels/Prelinked_El_Capitan_Patched

Edit: Path to El_Capitan_Patched added.

10) Reboot and run cat /var/log/system.log | grep kext to see if everything is OK.

Why patch a prelinkedkernel?
Well. For starters. The idea was to simply demonstrate a weakness in Apple’s kext signing protection in El Capitan. I also want it to work on my Mac as well. Yes. I could have added code to the macosxbootloader project, and compiled a new version of boot.efi to inject the (unsigned) kexts into the prelinkedkernel, but like I said earlier… that would have taken too much time. Not to mention that this is only a simple POC.

And sure. OS X recreates prelinkedkernel files automatically, so normally there is no need to do this manually, but this route opens the door of loading unsigned kexts on a system with SIP in place. And with El Capitan being the first version of OS X full SIP in place, which should make it way more restrictive than all previous versions of OS X… this hack is definitely new(s) – though Apple may close the door before the El Capitan GM is released.

The fact that you can set kext-dev-mode=1 in Mavericks and Yosemite, and let it update the kernel cache and prelinkedkernel with unsigned kexts, and then remove the setting afterwards, not only makes me wonder why nobody implemented proper kext injection – as in injecting kexts in the prelinkedkernel – in Clover and/or Chameleon. To me this shows us that this weakness wasn’t so well known as some people want you to believe. I mean saying something like that after a POC is published for El Capitan, is dead easy, but also a bit unfair. Why else is kext injection still broken? Nobody told slice this, or any of the other Clover developers? Really? Not to mention that I do all this with SIP fully enabled in El Capitan, without the need of kext-dev-mode, rootless=0 or any of the CSR flags… and that makes it a totally different.

Note: RevoBoot was the first boot loader to add the following CSR boot flags:

	#define CSR_ALLOW_UNTRUSTED_KEXTS	(1 << 0)	// 1
	#define CSR_ALLOW_UNRESTRICTED_FS	(1 << 1)	// 2
	#define CSR_ALLOW_TASK_FOR_PID		(1 << 2)	// 4
	#define CSR_ALLOW_KERNEL_DEBUGGER	(1 << 3)	// 8
	#define CSR_ALLOW_APPLE_INTERNAL	(1 << 4)	// 16
	#define CSR_ALLOW_UNRESTRICTED_DTRACE	(1 << 5)	// 32
	#define CSR_ALLOW_UNRESTRICTED_NVRAM	(1 << 6)	// 64

This was picked up a little later by the Enoch branch of Chameleon, with my help, and now Clover can also configure the CSR settings (runtime variable). And adding CSR_ALLOW_UNTRUSTED_KEXTS is similar to kext-dev-mode and thus enables you to add unsigned kexts to the prelinkedkernel in El Capitan. Just like using kext-dev-mode in Mavericks and Yosemite, but my POC is about injection kexts in the prelinkedkernel with SIP already fully enabled. A different kind of story.

The Problem
The main issue for me is that Apple told us that:

Valid code signatures will eventually be mandatory for all kexts

And that since Mavericks already. Now the release note of El Capitan add this:

A new security policy that applies to every running process, including privileged code and code that runs out of the sandbox. The policy extends additional protections to components on disk and at run-time, only allowing system binaries to be modified by the system installer and software updates. Code injection and runtime attachments to system binaries are no longer permitted.

But I can still inject code in the prelinkedkernel. That is not OK. I don’t like that. Another thing is that /Library/Preferences/com.apple.Boot.plist is (still) was unprotected up untill DP8, and thus anyone who liked to use a patched prelinkedkernel with unsigned kexts in it… could do that. Easily. You just need to know how.

A more serious problem is that Apple allows unsigned kext to execute from anywhere. In this POC we load them from /Extra/Extensions but other locations can be used as well. Plus. If you hide the directory including the unsigned kexts, then the average joe user won’t even notice it, since it won’t show up the finder. Plus that it will be undetectable in System Information/Software/Extensions so you won’t even know what kext is loaded from where. To me this is due to some lazy coding.

A possible oversight on Apple’s side, and that is why I expect this to change in a next Developer Preview. Well. So I hope, otherwise the first security exploit can take over your Mac/Hack. Like Hackinteam et all. Shrug.

Kext Whitelisting
If all you need is kext whitelisting, with SIP in place, then you can change/add one or more entries under OSKextSigExceptionHashList (see AppleKextExcludeList.kext/Content/Info.plist) in the prelinkedkernel, like we have been doing in Mavericks and Yosemite.

Update: Woohoo. I found another more serious way to bypass Apple’s kext signing restrictions, but this time I go for the bounty money (have a meeting tomorrow evening).

Note: Hang in tight folks. Sure. I am still very busy with my – non hack related – work, and I still suffer pain from my accident, but I will do my utmost best to finish this work. Promised!

Update-2: LZVN with support to extract the kernel, dictionary and kexts from the prelinkedkernel, is now available from my LZVN Github repository. See also LZVN command line tool updated and LZVN with kexts/dictionary extraction.

Update-3: I don’t know when, but something changed recently, as in: /L*/P*/SystemC*/com.apple.Boot.plist is now protected by SIP. How did I miss this change?

Edit: Apple fixed this bug in DP8. Fabulous!

Advertisements

82 thoughts on “Apple’s kext signing bypassed…

  1. Pingback: La signature obligatoire des kexts d’El Capitan a été contournée | W4Society

  2. This is silly. It’s not injecting kexts at boot time. You just create a new prelinked kernel. But OSX does that automatically. No need to move any kexts from Library/Extension to somewhere else. I don’t get the point for doing this.

      • This appear to be cool also for real Mac Devs that want someone else to try their kexts w/o spending a cent 🙂

      • Sorry to hear that you are not wasting your time to explain that. But modding the prelinked kernel is as old as we used preboot cds. I bet you remeber that 😛

      • No offence, but I rather use my time to finish up the POC, and sure. Modding the kextcache is old news, but now we talk about a SIP countermeasure that enables you to load unsigned kext. And doing it this simple is nowhere on the net to be found. I know as Googler 🙂

      • That’s still not true. You can load fakesmc.kext from where you want and prelinkedkernel will pick it up. So, that’s very old news what you do.

    • No, OSX does not do that “automatically”, ie does not include unsigned kext in the prelinked without specific flag. Consider in the near future these flag disappear…then oops…
      Only unsigned (or bad-signed) kexts need to be moved, of course if any.

      • Just to get it right: What you are trying to ‘proof’ is that unsigned kexts load at highest SIP level so long as they are already present in the prelinkedkernel?

      • Hi DF.

        Not already, but as long as they are part of the prelinkedkernel. I also injected a kext (manually) that was not there before, and it works. I’m stumped as well.

    • pikeralpha | July 28, 2015 at 8:24 pm

      How is that going to work for unsigned kexts with maximum SIP in place? I mean for kext not already in the hash list.

      I don’t get why you are trying to promote a feature of OSX that is present for years as a hack. Fakesmc loads fine from prelinkedkernel. I has done for many years now. It has nothing to do with SIP. That is user space. And I think you know it.

      • Many years one could use unsigned kexts, but the code signing in El Capitan is meant to be much more restrictive than Mavericks and Yosemite, so unsigned kexts should no longer be executed. Remember that it was Apple who said: “Valid code signatures will eventually be mandatory for all kexts” so when someone (like me) finds a way to bypass this protection, then I think that Apple should fix it.

        See also: “System Integrity Protection” in the release notes of OS X 10.11.

        A new security policy that applies to every running process, including privileged code and code that runs out of the sandbox. The policy extends additional protections to components on disk and at run-time, only allowing system binaries to be modified by the system installer and software updates. Code injection and runtime attachments to system binaries are no longer permitted

        About SIP being user space or not. Take a look at the bits. Like CSR_ALLOW_UNTRUSTED_KEXTS which is set when you disable SIP.

  3. Hello, how to change “_PrelinkBundlePath” of unsigned kexts?
    info.plist of the kexts (Fakesms.kext, AppleIntelE1000e.kext …) were not key “_PrelinkBundlePath”.
    Thank you for your informed answers.

  4. /usr/local/ appear to be a good place to store the patched prelinked since is still writable. The bootloader can override the path in the o.c.B.p….

    • You can put it anywhere you want, where it is writable, but keep in mind that this prelinkedkernel POC is just to show you how it works. What you really want is a boot loader that injects (unsigned) kexts from say /Extra/Extension.

      • Yes, you’re right, and for that I’m dreaming. I follow closely the developments on your repo.

  5. Why so complicated? Vmware is injecting its kexts in the prelinked kernel for years. Without the need to touch SIP setting or the need for rootless/kext-dev-mode bootargs. And even better, without touching the HFS Partition at all!

    • Sure. With previous versions of OS X, but it is not supposed to work like that with El Capitan. At least not with unsigned kexts. Otherwise SIP is pretty much useless soon.

  6. Do you really think I would write that if it wouldn’t work with 10.11 latest beta? Using the prelinked kernel to inject kexts is really old news. Email DFE if you don’t trust his work for vmware.

    • That vmware, and others, inject kext in the prelinkedkernel in older versions of OS X doesn’t really matter, since El Capitan is meant to be more secure and not load unsigned kexts. Again. Otherwise the new SIP is doomed.

      Then fact that it works doesn’t mean that it is right. Not to mention that A Virtual Machine is a totally different story – it’s not the host that gets compromised.

    • Please read what I wrote as in: older versions of OS X would allow you to do this, but not in El Capitan. Now SIP should block you from injecting code and unsigned kexts.

      • Again. That doesn’t make it right. Security holes are there to be patched, and they will I assure you!

        Note: Please stop repeating what I wrote in my blog (see: “bypassing Apple’s rather strict kext signing restrictions still works. Even in El Capitan DP5)”. Thank you.

  7. “pikeralpha | August 2, 2015 at 9:40 pm

    Again. That doesn’t make it right. Security holes are there to be patched, and they will I assure you!

    Note: Please stop repeating what I wrote in my blog (see: “bypassing Apple’s rather strict kext signing restrictions still works. Even in El Capitan DP5)”. Thank you.

    Again! Read what I posted! Your POC with moving all! Extension from S/L/E folder is a high security risk. Modding the prelinked kernel on disk is unrecommended as it will bypass the security of OS X. If you look at the xnu source code you will notice it. I hope you notice that your recommendation is just a piece of cake.

    • First. Where do you read that I moved all kext out of /System/Library/Extensions? I only moved a couple of third party kext, that don’t belong there anyway, and I only did that to demonstrate that loading/injecting kext can be done from anywhere by anyone, and that the system profiler won’t even show them. Remember. I also said that I don’t like this.

      Not to mention that I clearly stated that I mod the prelinkedkernel only because writing kext injection from scratch would have been too much work, and that I want it to work on my Mac as well. So it does. And no sane person, but attackers, is going to mod the prelinkedkernel for anything else than this POC. That much is clear to anyone else already.

      Also. Since modding a prelinkedkernel can be done by anyone, with the right set of tools, and that anyone can place that file on your computer and activate it for the next reboot, even with full SIP in place, that is something Apple should fix.

      I’m also known for disassembling unreleased (XNU) source code and thus I know what Apple does, and recently changed. You may have missed it in DP6, but I certainly didn’t.

      Do you know why didn’t I release my tool? Is that perhaps I was asked to wait… and Apple is going to change even more?

  8. Pike it doesn’t really matter how often you change your blog to fulfill your statements. It was clearly stated that vmware does inject kexts to the prelinked kernel for years. It was not invented by you! But since you wrote that you disassemble xnu source code I would really like to know how you do that? Is there a special source code disassembler? I always thought that source code doesn’t need to be disassembled since it is already C/C++ source code. Enlighten me please!

    • I did not change my blog post, but you keep twisting your comments just to make a statement. One that does not hold ground by the way but anyway.

      You also missed the whole point, and keep misreading/misinterpreting things. Like the fact that I wrote: “unreleased (XNU) source code” – and since unreleased means that the source code isn’t there… yet, you have to disassemble it yourself, or you have absolutely nothing to work with.

      Next you write this: “It was not invented by you!” but nowhere did I say that it was invented by me. Not that anyone cares, really, because this POC is about the lack of security in El Capitan – with SIP enabled. Not about who “invented it” or the fact that VMWare inject kexts. That is old news.

      Anyway. At least now people know who is who, which was the only reason for me to accept your comments here. Now visit that forum again – you know where – and have a nice day.

  9. Pingback: SIP about to change once more? | Pike's Universum

    • Wasn’t that step 4? Ok. Yeah that was a bit mythical. Well. Let’s try again.

      1.) Open the LZVN unpacked prelinkedkernel in a HexEditor.

      2.) Search for the PrelinkBundlePath aka /System/Library/Extensions/kextname.kext

      3.) Change the path into whatever you are using.
      – I myself used /Extra/Extensions/kextname.kext

      4.) Added zero’s (00) at the end as string terminator.

      Note: Do NOT insert any new characters i.e. the length should stay the same!

  10. Note: If you’re copy pasted commands here, step 1 has a typo! It reads “pERlinked” instead of “pRElinked”:
    cp /System/Library/Prelinkedkernels/perlinkedkernel ~/prelinkedkernel_el_capitan

  11. Actually I have modified the kernel cache according to your guide. Modified _PrelinkBundlePath of all unsigned kexts to /Extra/Extensions/ and repacked it again. I have noticed that my repacked kernel cache is of slightly different size than original kernel cache. When I tried to boot with this kernel cache, kernel panic occurred with describing it as ACPI Platform error. It is also reported that kext dictionary is not present.
    How to avoid kernel panics with modified kernel?

    I have forgot to mention that I used iHex as editor and used over-right method to modify kernel.

    • Ah ok so the size has changed. Well. That is a problem – the length of the path/filename should be unchanged. That is. You can add one or more NULL (0x00) characters, when the new string is shorter, but you cannot make it any longer.

  12. The size of unpacked kernel cache is same as unmodified one. But after repacking it with lzvn the size is changed. (I haven’t inserted or removed any character. Just changed some and replaced some with 0s)

    • Interesting. The size should not have changed. Please unpack and repack the pre-linked kernel, without changing anything in it, and let me know if the size has changed or not.

  13. I have done that and this time size didn’t change. But when I modify anything in unpacked kernel cache then size change. But I have changed it in overright mode in Hex editor and added 0s to keep length the same. But even after that the length change when I repack it.

  14. I have tried to extract kexts from my patched kernel and received ERROR: Can’t unserialize _PrelinkInfoDictionary! The same error message I get while booting with it also.

  15. Thanks piker but I have found a solution myself. If I keep the path to the same length as /System /Library/Extensions eg. /Extra1/Library/Extensions then that works. But inserting 0s in hex portion do not work. Thank you.

  16. Hi Pike.
    It seems that your idea is to use a kernelcache that contains unsigned kexts. But this may cause problems after system updating?

    • At that time, for this particular POC, yes. However, this POC should no longer work, in later revisions of OS X.

      I also added kext injection to RevoBoot and thus I have no use for it anymore.

      • Yup. Apple set restrictions for com.apple.Boot.plist and now it’s not convenient for us to do so. But it seems that Clover’s kext injection – to patch kernel and then load extra kexts is unstable. And had no try about your RevoBoot…

      • The main purpose of RevoBoot is that it is my test vehicle, but it should not be used by other people. It is too complicated when you compare it to Clover, lacking the setup tools and kind of support that Clover offers.

  17. Hello. I ended up reading your post when researching on how to get my M-Audio Fast Track Pro audio interface to work. It was always a buggy soundcard, but now it’s behaving way buggier, even with the latest signed driver. I wonder if I could enable previous drivers without messing with OSX security.

    Specifically, my problem is that the OSX’s bundled driver only allows audio recording at 44100Hz/16bit, which subutilizes the capabilities of the interface (which can do 96Khz/24bit). The only option is disabling driver signing checking?

    • Yes. That is currently the easiest way. But relax. Don’t be afraid. You can allow unsigned kexts without fear, for as long as you won’t change the file and ownership rights of /Library/Extensions and /System/Library/Extensions You’ll still better protected than anything the past decade did for you.

  18. Piker I am facing issues in High Sierra (10.13) with your method. I use a patched version of AppleHDA.kext (patched with applehda patcher from insanelymac) as my chip is not supported by the same. But 10.13 refuse to load this kext with SIP fully enabled as usual. So I have moved it to /Extra/Extensions/ and change its path to /Extra/Extensions in cache and changed _PrelinkBundlePath of AppleHDA.kext and all kext inside it to /Extra/Extensions/AppleHDA.kext but it still AppleHDA.kext and others inside it did not loaded. Although all other kexts from there were loaded.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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