Jump to content
InsanelyMac Forum

Lilu — kext and process patcher

Recommended Posts


I installed Lilu 1.21 and intelgraphicsfixup to clover/oem/vendor/kext/othe. If I activated intel hd4600 next to my nvidia 1050ti i bios settings and then added "-igfxoff" to boot args, the intel gfx still is listed as cuda device in luxmark in 10.13.2. So disabling does not work. I see that the kext is loaded in kextstat.




EDIT: If I put lilu and intelgrpahicsfixup into /L/E instead, same result.


EDIT: Do I have to use -liluforce for 10.13.2?  Why is the github page not hosting lilu v1.2.2?


EDIT: Sorry, had the wrong ig-platform-id in my dsdt, thought that clover would overwrite it. That was not the case.

Share this post

Link to post
Share on other sites

So.... latest Lilu give fatal CPU fault on 10.12.3 beta 4, anyone running into this issue?

Latest Lilu (1.2.1 & 1.2.2), AppleALC (1.2.2), & WhateverGreen (1.1.4) worked perfectly at either DP or HDMI port at 10.13.1, 10.13.2, & 10.13.3.

But it got blank screen of AMD R9 290X GPU at DP port at previously working 10.10.5, 10.11.6, & 10.12.6 in my P6TSE hackintosh.

Rolling back to previous versions of Lilu/AppleALC/WEG can not fix it yet by CLOVER r.4359 or r.4369.

Thanks for vit9696 again !


[solved by myself]

1. AMD R9 290X GPU only working at HDMI port at 10.10.5, 10.11.6, & 10.12.6 in my P6TSE hackintosh, not working at DP port.

2. HDMI audio working again at 10.12.6, but not working at 10.10.5 or 10.11.6.

Edited by jsl

Share this post

Link to post
Share on other sites

The crash is caused by a memory corruption in Intel GPU acceleration DRM key/certificate handling code. Therefore, only Ivy+ GPUs are affected.


Are you 100% sure it is only affecting Ivy and Sandy? Because if I use my haswell igpu hd4600 with connector-full next to nvidia gpu, there will be a hard crash/reset in Final Cut. I have seen these patches do not match for haswell igpu... Or is this problem unrelated?

Share this post

Link to post
Share on other sites



I am having trouble  with Kernel Panics after updating macOS Sierra 10.12.6 to the latest security update patch from the app store today.


So, Cyberdev told me that there was a new version of Lilu availaible. I also updated NvidiaGraphicsFixup.kext since I use a GTX 560 TI. ALC and FakeSMC were up to date already.

But I still got kernel panics. So I removed nvidiagraphicsfixup.kext and booted without nvidia drivers. That worked, So then I could update to the latest webdrivers (Version 378.05.05.25f06). 



Now I have the latest webdrivers installed but I cannot use NvidiaGraphicsFixup.kext because it results in kernel panics:




Next, I tried using NVWebDriverLibValFix.kext again instead, which I used before, but that fix/kext doesn't work any more... the GPU just turns off after boot.


These are the Kexts I currently use:




I don't know what to do, can you see what the problem is? Do I need that whatevergreen.kext?


Any help would be highly appreciated!

Share this post

Link to post
Share on other sites

Hi @vit9696,

With Xcode 8.2.1 uder OS X 10.11.6 I got this warning:

Unused Entity Issue:
~/Projects/XCode/Lilu-master/Lilu/Headers/kern_iokit.hpp:187:9: Unused variable 'name'

(Refers to this):
#187: auto name = service->getName(); //Unused variable 'name'

But Lilu.kext built succeeded. Thanks  :)


#EDIT: a same warning with AppleALC build, but I could ignore it.

Share this post

Link to post
Share on other sites

Is it possible to use Lilu for code injection? Ala CydiaSubstrate for iOS? It'd be enough to be able to provide a dynamic library that can be loaded into all processes and have its __attribute__((constructor)) called

Share this post

Link to post
Share on other sites

Hi, what do you need this functionality for?

In brief, it is possible and the code for this exists, yet primarily in private as a part of the project Lilu codebase is based on. Some parts were published with Shiki, some others found its way to the latest Lilu release. You in fact do not even need a dylib with Lilu, since everything could be done entirely in memory.

As I said, a reasonably large codebase (userspace sdk) remains private for several reasons. It is a discussible question whether it should be published or not, so I would like to hear the reasons you need this in detail.

Share this post

Link to post
Share on other sites
Posted (edited)


Thanks for replying so quickly. I think the use cases for such an SDK are wide. You can find precedent of it if you search for the large community which formed around the Unsanity Haxie tools for 10.4 which provided code injection and an API to replace functions at runtime.

Personally, I have a number of projects which are in great need of a platform to handle injection and code replacement. You may refer to AutumnBoard (https://github.com/alexzielenski/AutumnBoard) - a tool to replace system app, extension, etc. icon files at runtime allowing for a rich packaged theming API. Unfortunately, development was dropped as the tools being used for code injection became outdated. Additionally there is dockify (https://github.com/alexzielenski/dockify_library) - a library which if developed fully could allow customization of dock appearance.

A system-wide runtime theming library could easily be achievable with your system. Note that many tweaks would require injection into processes filterable by bundle identifier, frameworks loaded, process name, or a wildcard.

Many other possibilities exist for patches of OS X user space functionality large and small. For instance, one might opt to remove the feature of OS X which lower's system audio during a FaceTime call; and can easily do so with a patch like this: https://github.com/ParasiteTeam/crucible/blob/master/examples/com.apple.audio.CoreAudio/SpeakerTime.plist if there was a stable code injection platform. The addition of this SDK would create a community of tweak developers not too different from that which formed around the iOS jailbreak scene.

Extensions which could probably be ported immediately include and any SIMBL bundle that was created for OS X. You may ask what benefit this product could offer over SIMBL bundles?

1. SIMBL does not allow you to filter by library/framework. (though; admittedly this could be added to its injection process)

2. SIMBL requires an agent which receives late notifications of process events (in many applications of code injection tweaks it is crucial to inject early into process lifetime)

3. SIMBL can only filter against Cocoa UI applications - (headless or terminal applications are not able to be injected into)

4. SIMBL does not include a standardized code replacement SDK


You mentioned that a dylib is not required since patches could be done in memory with a Lilu plugin, but I think it would be best load dylibs and keep the 3rd party code running in userland which does not need kernel privileges.

The best way to implement a system like this would be as a separate Lilu plugin, which would act as a trampoline for a dynamically loaded plugin system retrieving filters from user space or the filesystem.

Edited by jivhg

Share this post

Link to post
Share on other sites

Thanks for the links and notes. Just as you said, the use cases for such functionality could broadly vary.

4 years ago, when AppleALC was not even planned, Lilu prototype was actually a modern replacement to SIMBL. However, when it comes to software modification there are two points to think about:

  1. Security
  2. Target audience

SIMBL was pretty impressive several years ago, where numerous developers created their extensions to patch different things. Later on their enthusiasm disappeared, and even though SIMBL still works on modern macOS versions (with some hacks and SIP workarounds), its userbase is largely dead. Basically the same with Cydia Substrate and Jailbreak itself, which no longer belong to the common sense.

More than that, SIMBL or a working Lilu-based solution with a SDK opens a possibility for malware writers and similar shady people to write harmful software at no effort. And that's if we forget about other possible bugs.

Regarding the "kernel privileges and stuff". We followed the exact model you described during the creation of an initial prototype of MiniSubstrate with 07151129. And it was badly wrong. Making it possible to let the user to dynamically load an extension during the system runtime causes an extreme security risk, having a plugin management system injected in every process is an additional risk to system stability, and a possibility to swap one dylib with another is another great security risk. The only way it could actually appear (and is actually implemented in Lilu) is to have a kext that is bundled with all the extensions with a defined process list, which is only loaded at boot time. If you think of it, this is similar to how Cydia Substrate works with a 'respring'. Do not take me wrong though, obviously nobody executes any code with kernel privileges, it uses app privileges and is no different from any other dylib. As a bonus this approach is in fact more performant.

All in all, while I still consider a possibility of this project going live, I remain unconvinced about the existence of an audience, which would actually write useful plugins. Perhaps, more actual projects and demand could work better here, but such a revival will take time.

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.