Jump to content

Lilu — kext and process patcher

vit9696

By vit9696,
in Lilu

 Share
395 posts in this topic

Recommended Posts

lisai9093
lisai9093
Posted
Posted

I have problem when running Big Sur with Lilu with plug in "SMCDellSensors.kext". It will cause kernel panic on startup whenever this plugin is loaded. This problem only apply to Big Sur and working fine on previous macOS.

 

Here is the kernel panic report with latest Lilu and plugins, on final version of Big Sur 11.0.1: 

panic(cpu 4 caller 0xffffff80079efa76): Kernel trap at 0xffffff800b5b7b15, type 14=page fault, registers:
CR0: 0x0000000080010033, CR2: 0xffffff800ae1c100, CR3: 0x000000000c811000, CR4: 0x00000000003626e0
RAX: 0x0000000000000050, RBX: 0xffffff800af8f9c8, RCX: 0x0000000000000051, RDX: 0xffffffa10a913b90
RSP: 0xffffffa10a913a80, RBP: 0xffffffa10a913ac0, RSI: 0xffffff800b6846bd, RDI: 0xffffff800b6846bd
R8:  0x00000000000006fa, R9:  0x0000000000027000, R10: 0x0000000000000001, R11: 0x0000000000000000
R12: 0xffffff800b53cca3, R13: 0xffffff800ae1c110, R14: 0xffffff937fab20c0, R15: 0x0000000000000000
RFL: 0x0000000000010206, RIP: 0xffffff800b5b7b15, CS:  0x0000000000000008, SS:  0x0000000000000010
Fault CR2: 0xffffff800ae1c100, Error code: 0x0000000000000000, Fault CPU: 0x4, PL: 0, VF: 2

Backtrace (CPU 4), Frame : Return Address
0xffffffa10a9134a0 : 0xffffff80078bc66d 
0xffffffa10a9134f0 : 0xffffff80079ff073 
0xffffffa10a913530 : 0xffffff80079ef6aa 
0xffffffa10a913580 : 0xffffff8007861a2f 
0xffffffa10a9135a0 : 0xffffff80078bbf0d 
0xffffffa10a9136c0 : 0xffffff80078bc1f8 
0xffffffa10a913730 : 0xffffff80080bee1a 
0xffffffa10a9137a0 : 0xffffff80079efa76 
0xffffffa10a913920 : 0xffffff80079ef75d 
0xffffffa10a913970 : 0xffffff8007861a2f 
0xffffffa10a913990 : 0xffffff800b5b7b15 
0xffffffa10a913ac0 : 0xffffff800b5a8131 
0xffffffa10a913b30 : 0xffffff800b5a800e 
0xffffffa10a913b60 : 0xffffff800b680b4e 
0xffffffa10a913c60 : 0xffffff800b5ad92d 
0xffffffa10a913ca0 : 0xffffff800b5a67ed 
0xffffffa10a913ce0 : 0xffffff8007f847c2 
0xffffffa10a913d40 : 0xffffff8007f843ff 
0xffffffa10a913da0 : 0xffffff8007f989dd 
0xffffffa10a913df0 : 0xffffff800800eebe 
0xffffffa10a913e40 : 0xffffff8007fee39b 
0xffffffa10a913ef0 : 0xffffff8007feddcf 
0xffffffa10a913f50 : 0xffffff8007ff0b46 
0xffffffa10a913fa0 : 0xffffff800786113e 
      Kernel Extensions in backtrace:
         as.vit9696.Lilu(1.4.9)[6E38576B-9675-3D9E-9763-5B0F9DA1B098]@0xffffff800b5a5000->0xffffff800b5ccfff
         as.lvs1974.SMCDellSensors(1.1.8)[3CF613AD-8611-3E70-9ECB-1F2F7CD87EE3]@0xffffff800b680000->0xffffff800b68bfff
            dependency: as.vit9696.Lilu(1.4.9)[6E38576B-9675-3D9E-9763-5B0F9DA1B098]@0xffffff800b5a5000->0xffffff800b5ccfff
            dependency: as.vit9696.VirtualSMC(1.1.8)[3BC5157C-7E87-31A4-8C61-3770E078BA73]@0xffffff800b5cf000->0xffffff800b5e4fff

Process name corresponding to current thread: kernel_task
Boot args: shikigva=16 brcmfx-country=#a bpr_probedelay=100 bpr_initialdelay=300 bpr_postresetdelay=300 chunklist-security-epoch=0 -chunklist-no-rev2-dev chunklist-security-epoch=0 -chunklist-no-rev2-dev

Mac OS version:
20B29

Kernel version:
Darwin Kernel Version 20.1.0: Sat Oct 31 00:07:11 PDT 2020; root:xnu-7195.50.7~2/RELEASE_X86_64
Kernel UUID: 84C6DC45-6B02-335F-9439-5D2A9BC385A4
KernelCache slide: 0x0000000007600000
KernelCache base:  0xffffff8007800000
Kernel slide:      0x0000000007610000
Kernel text base:  0xffffff8007810000
__HIB  text base: 0xffffff8007700000
System model name: iMac19,1 (Mac-AA95B1DDAB278B95)
System shutdown begun: NO
Panic diags file available: YES (0x0)
Hibernation exit count: 0

System uptime in nanoseconds: 22468738910
Last Sleep:           absolute           base_tsc          base_nano
  Uptime  : 0x000000053b3dc33c
  Sleep   : 0x0000000000000000 0x0000000000000000 0x0000000000000000
  Wake    : 0x0000000000000000 0x0000001635723d55 0x0000000000000000

 

Link to comment
Share on other sites
  • 4 weeks later...
levifig
levifig
Posted
Posted (edited)
On 11/17/2020 at 8:57 AM, lisai9093 said:

I have problem when running Big Sur with Lilu with plug in "SMCDellSensors.kext". It will cause kernel panic on startup whenever this plugin is loaded. This problem only apply to Big Sur and working fine on previous macOS.

 

Here is the kernel panic report with latest Lilu and plugins, on final version of Big Sur 11.0.1: 


panic(cpu 4 caller 0xffffff80079efa76): Kernel trap at 0xffffff800b5b7b15, type 14=page fault, registers:
CR0: 0x0000000080010033, CR2: 0xffffff800ae1c100, CR3: 0x000000000c811000, CR4: 0x00000000003626e0
RAX: 0x0000000000000050, RBX: 0xffffff800af8f9c8, RCX: 0x0000000000000051, RDX: 0xffffffa10a913b90
RSP: 0xffffffa10a913a80, RBP: 0xffffffa10a913ac0, RSI: 0xffffff800b6846bd, RDI: 0xffffff800b6846bd
R8:  0x00000000000006fa, R9:  0x0000000000027000, R10: 0x0000000000000001, R11: 0x0000000000000000
R12: 0xffffff800b53cca3, R13: 0xffffff800ae1c110, R14: 0xffffff937fab20c0, R15: 0x0000000000000000
RFL: 0x0000000000010206, RIP: 0xffffff800b5b7b15, CS:  0x0000000000000008, SS:  0x0000000000000010
Fault CR2: 0xffffff800ae1c100, Error code: 0x0000000000000000, Fault CPU: 0x4, PL: 0, VF: 2

Backtrace (CPU 4), Frame : Return Address
0xffffffa10a9134a0 : 0xffffff80078bc66d 
0xffffffa10a9134f0 : 0xffffff80079ff073 
0xffffffa10a913530 : 0xffffff80079ef6aa 
0xffffffa10a913580 : 0xffffff8007861a2f 
0xffffffa10a9135a0 : 0xffffff80078bbf0d 
0xffffffa10a9136c0 : 0xffffff80078bc1f8 
0xffffffa10a913730 : 0xffffff80080bee1a 
0xffffffa10a9137a0 : 0xffffff80079efa76 
0xffffffa10a913920 : 0xffffff80079ef75d 
0xffffffa10a913970 : 0xffffff8007861a2f 
0xffffffa10a913990 : 0xffffff800b5b7b15 
0xffffffa10a913ac0 : 0xffffff800b5a8131 
0xffffffa10a913b30 : 0xffffff800b5a800e 
0xffffffa10a913b60 : 0xffffff800b680b4e 
0xffffffa10a913c60 : 0xffffff800b5ad92d 
0xffffffa10a913ca0 : 0xffffff800b5a67ed 
0xffffffa10a913ce0 : 0xffffff8007f847c2 
0xffffffa10a913d40 : 0xffffff8007f843ff 
0xffffffa10a913da0 : 0xffffff8007f989dd 
0xffffffa10a913df0 : 0xffffff800800eebe 
0xffffffa10a913e40 : 0xffffff8007fee39b 
0xffffffa10a913ef0 : 0xffffff8007feddcf 
0xffffffa10a913f50 : 0xffffff8007ff0b46 
0xffffffa10a913fa0 : 0xffffff800786113e 
      Kernel Extensions in backtrace:
         as.vit9696.Lilu(1.4.9)[6E38576B-9675-3D9E-9763-5B0F9DA1B098]@0xffffff800b5a5000->0xffffff800b5ccfff
         as.lvs1974.SMCDellSensors(1.1.8)[3CF613AD-8611-3E70-9ECB-1F2F7CD87EE3]@0xffffff800b680000->0xffffff800b68bfff
            dependency: as.vit9696.Lilu(1.4.9)[6E38576B-9675-3D9E-9763-5B0F9DA1B098]@0xffffff800b5a5000->0xffffff800b5ccfff
            dependency: as.vit9696.VirtualSMC(1.1.8)[3BC5157C-7E87-31A4-8C61-3770E078BA73]@0xffffff800b5cf000->0xffffff800b5e4fff

Process name corresponding to current thread: kernel_task
Boot args: shikigva=16 brcmfx-country=#a bpr_probedelay=100 bpr_initialdelay=300 bpr_postresetdelay=300 chunklist-security-epoch=0 -chunklist-no-rev2-dev chunklist-security-epoch=0 -chunklist-no-rev2-dev

Mac OS version:
20B29

Kernel version:
Darwin Kernel Version 20.1.0: Sat Oct 31 00:07:11 PDT 2020; root:xnu-7195.50.7~2/RELEASE_X86_64
Kernel UUID: 84C6DC45-6B02-335F-9439-5D2A9BC385A4
KernelCache slide: 0x0000000007600000
KernelCache base:  0xffffff8007800000
Kernel slide:      0x0000000007610000
Kernel text base:  0xffffff8007810000
__HIB  text base: 0xffffff8007700000
System model name: iMac19,1 (Mac-AA95B1DDAB278B95)
System shutdown begun: NO
Panic diags file available: YES (0x0)
Hibernation exit count: 0

System uptime in nanoseconds: 22468738910
Last Sleep:           absolute           base_tsc          base_nano
  Uptime  : 0x000000053b3dc33c
  Sleep   : 0x0000000000000000 0x0000000000000000 0x0000000000000000
  Wake    : 0x0000000000000000 0x0000001635723d55 0x0000000000000000

 

 

I'm getting an identical KP but with 1.5.0 and VirtualSMC 1.1.9 (both at their latest versions).

Edited by levifig
Link to comment
Share on other sites
grassmudhorse
grassmudhorse
Posted
Posted

I am trying to debug NVMeFix to see why it is not loaded properly for my drive. I am using the debug version of the NVMeFix itself and the debug version of Lilu. I am using the release version of OC 0.63. 

I have added "keepsyms=1 -liludbg -nvmefdbg" to the boot arg. However, there is nothing related to NVMe or Lilu when I examine with: sudo dmesg |grep NVMe or log show --last boot |grep NVMe, there is no information at all. Even grep Lilu gives no debug information. Hackintool has empty log for Lilu as well. I even go to the debug version of OC and still got nothing. 
 

 

This post seem to suggest it is an OC issue. What should be the proper setting for OC to output Lilu and its plugin's debug log?

 

Thanks!

 

Link to comment
Share on other sites
  • 2 weeks later...
shantur
shantur
Posted
Posted (edited)
On 12/13/2020 at 5:41 AM, grassmudhorse said:

I am trying to debug NVMeFix to see why it is not loaded properly for my drive. I am using the debug version of the NVMeFix itself and the debug version of Lilu. I am using the release version of OC 0.63. 

I have added "keepsyms=1 -liludbg -nvmefdbg" to the boot arg. However, there is nothing related to NVMe or Lilu when I examine with: sudo dmesg |grep NVMe or log show --last boot |grep NVMe, there is no information at all. Even grep Lilu gives no debug information. Hackintool has empty log for Lilu as well. I even go to the debug version of OC and still got nothing. 
 

 

This post seem to suggest it is an OC issue. What should be the proper setting for OC to output Lilu and its plugin's debug log?

 

Thanks!

 

 

Same here. Trying to get some Lilu and WhateverGreen logs and I cannot see it in. 

log show --predicate 'process == "kernel"' --style syslog --last boot

I could see it being printed in verbose boot console when with the boot-args "-liludbg -liludbgall -wegdbg" below but it doesn't come to syslog.

 

I am using latest debug versions of Lilu, OC and plugins. OS is BigSur 11.1

Edited by shantur
Link to comment
Share on other sites
  • 6 months later...
  • 1 month later...
startergo
startergo
Posted
Posted (edited)

Trying to install Monterey on x299 pro/se, but installation freezes/panics. When I boot back to Catalina this is the Kernel Panic report: 

panic(cpu 12 caller 0xffffff80009ccff4): Possible memory corruption: pmap_pv_remove(0xffffff86ec370280,0x110601000,0x81a5c1, 0x4500081a5c1798, 0xffffffd09bc1bad4, 0xfffffe9db196d008): null pv_list, priors: 1 @pmap_internal.h:903
Panicked task 0xffffff86ec2773e0: 1 threads: NULL bsd_info pointer
unknown task
Backtrace (CPU 12), panicked thread: 0xffffff86ec94c420, Frame : Return Address
0xffffffd09bc1b690 : 0xffffff80008a34fd mach_kernel : _handle_debugger_trap + 0x41d
0xffffffd09bc1b6e0 : 0xffffff80009fcc35 mach_kernel : _kdp_i386_trap + 0x145
0xffffffd09bc1b720 : 0xffffff80009ec603 mach_kernel : _kernel_trap + 0x533
0xffffffd09bc1b770 : 0xffffff80048118f4 as.vit9696.VirtualSMC : __ZN18VirtualSMCProvider10kernelTrapI22x86_saved_state_1010_tEEvPT_Pm + 0x454
0xffffffd09bc1b7f0 : 0xffffff8000842a60 mach_kernel : _return_from_trap + 0xe0
0xffffffd09bc1b810 : 0xffffff80008a38cd mach_kernel : _DebuggerTrapWithState + 0xad
0xffffffd09bc1b930 : 0xffffff80008a3086 mach_kernel : _panic_trap_to_debugger + 0x2b6
0xffffffd09bc1b990 : 0xffffff8001119aa9 mach_kernel : _panic + 0x54
0xffffffd09bc1ba00 : 0xffffff80009ccff4 mach_kernel : _pmap_remove_range + 0xf24
0xffffffd09bc1bb00 : 0xffffff80009cd226 mach_kernel : _pmap_remove_options + 0x206
0xffffffd09bc1bb60 : 0xffffff80009579ab mach_kernel : _vm_map_remove + 0x7bb
0xffffffd09bc1bca0 : 0xffffff8000957263 mach_kernel : _vm_map_remove + 0x73
0xffffffd09bc1bcd0 : 0xffffff80008dc7fd mach_kernel : _task_terminate_internal + 0x1dd
0xffffffd09bc1bd10 : 0xffffff8000888497 mach_kernel : _ipc_port_release_send_and_unlock + 0x167
0xffffffd09bc1bd70 : 0xffffff80008e128d mach_kernel : _task_deliver_crash_notification + 0x16d
0xffffffd09bc1bdc0 : 0xffffff80008ed8be mach_kernel : _thread_terminate_self + 0x56e
0xffffffd09bc1be50 : 0xffffff80008f1e8a mach_kernel : _thread_apc_ast + 0xaa
0xffffffd09bc1be80 : 0xffffff8000899e53 mach_kernel : _ast_taken_user + 0x153
0xffffffd09bc1beb0 : 0xffffff8000842a2c mach_kernel : _return_from_trap + 0xac
      Kernel Extensions in backtrace:
         as.vit9696.VirtualSMC(1.2.7)[89D16BFE-ED7B-31DA-A7FA-D0659BDAD00F]@0xffffff8004802000->0xffffff8004828fff
            dependency: as.vit9696.Lilu(1.5.6)[D97855FE-5DAA-35F7-B7A3-8545E5BAC894]@0xffffff800474d000->0xffffff80047d2fff
            dependency: com.apple.iokit.IOACPIFamily(1.4)[CC0594E9-8711-315B-A945-71C6051676E1]@0xffffff8002f05000->0xffffff8002f06fff

Process name corresponding to current thread (0xffffff86ec94c420): Unknown
Boot args: -v shikigva=128 watchdog=0 debug=0x144 keepsyms=1 latebloom=125 lb_debug=1 -lilubetaall

Mac OS version:
21A5294g

Kernel version:
Darwin Kernel Version 21.0.0: Thu Jul 22 19:52:31 PDT 2021; root:xnu-8019.0.72.141.3~2/RELEASE_X86_64
Kernel UUID: 43AA07BC-5319-3B90-A977-9050C6C2F8D7
KernelCache slide: 0x0000000000600000
KernelCache base:  0xffffff8000800000
Kernel slide:      0x0000000000610000
Kernel text base:  0xffffff8000810000
__HIB  text base: 0xffffff8000700000
System model name: MacPro7,1 (Mac-27AD2F918AE68F61)
System shutdown begun: NO
Panic diags file unavailable, panic occurred prior to initialization
Hibernation exit count: 0

System uptime in nanoseconds: 60013799398
Last Sleep:           absolute           base_tsc          base_nano
  Uptime  : 0x0000000df919ed32
  Sleep   : 0x0000000000000000 0x0000000000000000 0x0000000000000000
  Wake    : 0x0000000000000000 0x0000fe63a660cff4 0x0000000000000000

 

Edited by startergo
Link to comment
Share on other sites
  • 5 months later...
i0ntempest
i0ntempest
Posted
Posted

Anyone using Lilu with macOS 12.3? I would like to use it and FeatureUnlock kext on mac Mac mini 2018 to enable AirPlay receiver function but Lilu is causing panics as I see in the panic log.

Link to comment
Share on other sites
  • 4 weeks later...
joevt
joevt
Posted
Posted

Lilu user patches

 

I understand Lilu user patches have been disabled since v1.4.6 for Big Sur and later. What is required to get user patches to work? Specifically, a user patch like that controlled by the -cdfon boot-arg?

 

I am using a MacPro3,1 with OCLP which loads Lilu and a handful of Lilu kexts including WhateverGreen. I use a PCIe card for serial port output to get OpenCore, boot.efi, and xnu log messages. https://github.com/acidanthera/bugtracker/issues/1954

 

These are my boot-args:  

keepsyms=1 debug=0x108 -v maxmem=63488 iogdebg=-1 serial=3 msgbuf=1048576 serialbaud=115200 -disable_sidecar_mac -liludbgall liludump=90 -revasset -wegbeta -lilubeta -cdfon

I've already made some fixes in my forks (like properly reading the dyld_shared_cache.map file and fixing vmProtect so it can actually enable write access and work with Monterey (not tested) and other versions of macOS (not tested) that it didn't work with before)

https://github.com/joevt/WhateverGreen/commits/master

https://github.com/joevt/Lilu/commits/master

I made joedwarftohpt.py to help check struct offsets.

 

I've done testing with Big Sur 11.6.4. I believe UserPatcher::injectRestrict succeeds but the WindowServer process does not load. It retries every 10 seconds. Here's the crash log:

Spoiler 
Process:               WindowServer [1648]
Path:                  /System/Library/PrivateFrameworks/SkyLight.framework/Versions/A/Resources/WindowServer
Identifier:            WindowServer
Version:               600.00 (588.9)
Code Type:             X86-64 (Native)
Parent Process:        launchd [1]
Responsible:           WindowServer [1648]
User ID:               0

Date/Time:             2022-03-05 23:54:38.182 -0800
OS Version:            macOS 11.6.4 (20G417)
Report Version:        12
Anonymous UUID:        D5BC5E07-6FAD-FBE5-8D4D-EA7D10DF8E4C


Time Awake Since Boot: 980 seconds

System Integrity Protection: enabled

Crashed Thread:        0

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Reason:    DYLD, [0x1] Library missing

Application Specific Information:
dyld: launch, loading dependent libraries

Dyld Error Message:
  dyld: No shared cache present
Library not loaded: /System/Library/PrivateFrameworks/SkyLight.framework/Versions/A/SkyLight
  Referenced from: /System/Library/PrivateFrameworks/SkyLight.framework/Resources/WindowServer
  Reason: image not found

Binary Images:
       0x10c73c000 -        0x10c73ffff  WindowServer (600.00 - 588.9) <B734AA29-E0EC-348B-A5B1-4859EF720521> /System/Library/PrivateFrameworks/SkyLight.framework/Resources/WindowServer
       0x110589000 -        0x110624fff  dyld (852.2) <2400DF9F-B3B6-3CE0-8877-BC176527BEED> /usr/lib/dyld

 

 

How is the restrict method supposed to work? It seems like it is meant to bypass the dyld_shared_cache and load the actual framework? But Big Sur and later only have the dyld_shared_cache (in /System/Library/dyld) - the frameworks don't contain their code (compare /System/Library/Frameworks/CoreDisplay in Big Sur with Catalina) - so something else is required for Big Sur and later?

 

Is there a different kind of user patch that does work in Big Sur? Should -cdfon be changed to use a different kind of user patch?

https://github.com/joevt/WhateverGreen/blob/master/WhateverGreen/kern_cdf.cpp

 

The cdfon user patch only does search and replace of a small number of bytes. Is there a type of user patch that can insert more code? With a kernel patch, you can make a patch in a kext or the kernel that jumps to code in the Lilu plugin. I would like something similar for a user patch. Is there an example of such a user patch?

 

  • Like 2
Link to comment
Share on other sites
  • 2 weeks later...
joevt
joevt
Posted
Posted (edited)
On 3/8/2022 at 1:32 AM, joevt said:

Lilu user patches

 

I understand Lilu user patches have been disabled since v1.4.6 for Big Sur and later. What is required to get user patches to work? Specifically, a user patch like that controlled by the -cdfon boot-arg?

 

I am using a MacPro3,1 with OCLP which loads Lilu and a handful of Lilu kexts including WhateverGreen. I use a PCIe card for serial port output to get OpenCore, boot.efi, and xnu log messages. https://github.com/acidanthera/bugtracker/issues/1954

 

These are my boot-args:  

keepsyms=1 debug=0x108 -v maxmem=63488 iogdebg=-1 serial=3 msgbuf=1048576 serialbaud=115200 -disable_sidecar_mac -liludbgall liludump=90 -revasset -wegbeta -lilubeta -cdfon

I've already made some fixes in my forks (like properly reading the dyld_shared_cache.map file and fixing vmProtect so it can actually enable write access and work with Monterey (not tested) and other versions of macOS (not tested) that it didn't work with before)

https://github.com/joevt/WhateverGreen/commits/master

https://github.com/joevt/Lilu/commits/master

I made joedwarftohpt.py to help check struct offsets.

 

I've done testing with Big Sur 11.6.4. I believe UserPatcher::injectRestrict succeeds but the WindowServer process does not load. It retries every 10 seconds. Here's the crash log:

  Reveal hidden contents 
Process:               WindowServer [1648]
Path:                  /System/Library/PrivateFrameworks/SkyLight.framework/Versions/A/Resources/WindowServer
Identifier:            WindowServer
Version:               600.00 (588.9)
Code Type:             X86-64 (Native)
Parent Process:        launchd [1]
Responsible:           WindowServer [1648]
User ID:               0

Date/Time:             2022-03-05 23:54:38.182 -0800
OS Version:            macOS 11.6.4 (20G417)
Report Version:        12
Anonymous UUID:        D5BC5E07-6FAD-FBE5-8D4D-EA7D10DF8E4C


Time Awake Since Boot: 980 seconds

System Integrity Protection: enabled

Crashed Thread:        0

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Reason:    DYLD, [0x1] Library missing

Application Specific Information:
dyld: launch, loading dependent libraries

Dyld Error Message:
  dyld: No shared cache present
Library not loaded: /System/Library/PrivateFrameworks/SkyLight.framework/Versions/A/SkyLight
  Referenced from: /System/Library/PrivateFrameworks/SkyLight.framework/Resources/WindowServer
  Reason: image not found

Binary Images:
       0x10c73c000 -        0x10c73ffff  WindowServer (600.00 - 588.9) <B734AA29-E0EC-348B-A5B1-4859EF720521> /System/Library/PrivateFrameworks/SkyLight.framework/Resources/WindowServer
       0x110589000 -        0x110624fff  dyld (852.2) <2400DF9F-B3B6-3CE0-8877-BC176527BEED> /usr/lib/dyld

 

 

How is the restrict method supposed to work? It seems like it is meant to bypass the dyld_shared_cache and load the actual framework? But Big Sur and later only have the dyld_shared_cache (in /System/Library/dyld) - the frameworks don't contain their code (compare /System/Library/Frameworks/CoreDisplay in Big Sur with Catalina) - so something else is required for Big Sur and later?

 

Is there a different kind of user patch that does work in Big Sur? Should -cdfon be changed to use a different kind of user patch?

https://github.com/joevt/WhateverGreen/blob/master/WhateverGreen/kern_cdf.cpp

 

The cdfon user patch only does search and replace of a small number of bytes. Is there a type of user patch that can insert more code? With a kernel patch, you can make a patch in a kext or the kernel that jumps to code in the Lilu plugin. I would like something similar for a user patch. Is there an example of such a user patch?

 

 

Some Lilu plugins use their own cs_validate_page patch to do user patchers instead of using the Lilu process patching method.

- WhateverGreen: for the "unfair" patches which is a replacement for the "shiki" patches? https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.Chart.md

- RestrictEvents https://github.com/acidanthera/RestrictEvents

- FeatureUnlock https://github.com/acidanthera/FeatureUnlock

- maybe some other Lilu plugins?

 

So I modified my Lilu fork to perform process patching for Big Sur and Monterey using Lilu's cs_validate_page patch.

I modified my WhateverGreen fork so the "cdf" patches can work for all macOS versions from Tiger to Monterey but I've only tested Big Sur and Monterey.

 

I can use my AllRez command to get the list of display modes before and after the cdf patch to see that it is working to increase the number of modes:

https://forums.macrumors.com/threads/solved-8k-displays-running-on-mac-pro-any-what-video-cards-would-work-that-support-8k-hdmi-2-1-displayport-1-4-2-0-displays-on-mac-pro-yes-you-can.2309750/post-30760662

 

Edited by joevt
  • Like 2
Link to comment
Share on other sites
  • 1 month later...
joevt
joevt
Posted
Posted
9 hours ago, applehacker said:

Does it work for all versions of Mac, like 10.6 and 10.9?

I updated some WhataverGreen patches to include old macOS versions but I haven't tried Lilu/WhataverGreen with old macOS versions. I think they're supposed to work? Or maybe some other changes will be necessary. I don't think I'll try to test it without someone reporting a problem.

Link to comment
Share on other sites
  • 3 weeks later...
joevt
joevt
Posted
Posted
10 hours ago, kocoman said:

is it possible to use lilu to retn / nop a function/procedure call? for example 

AppleIntelCapriController::FBMemMgr_Init(AppleIntelCapriController *this

 

thx

Lilu has functions to do patching, but you have to write code that uses those functions to do the patch.

The name of the function you specified is "__ZN25AppleIntelCapriController13FBMemMgr_InitEv"

WhateverGreen has many examples of kext patches. If your patch is simple enough, you could just make it an OpenCore kext patch.

 

Link to comment
Share on other sites
kocoman
kocoman
Posted
Posted
On 5/30/2022 at 10:40 AM, joevt said:

Lilu has functions to do patching, but you have to write code that uses those functions to do the patch.

The name of the function you specified is "__ZN25AppleIntelCapriController13FBMemMgr_InitEv"

WhateverGreen has many examples of kext patches. If your patch is simple enough, you could just make it an OpenCore kext patch.

 

can you tell me what example i should use for start.. i downgrade between 10.8.2 and 10.8.3 (where the code that cause the assert panic started) to test it without those console predicates and sip in newer version.. thank you

Link to comment
Share on other sites
joevt
joevt
Posted
Posted
5 hours ago, kocoman said:

can you tell me what example i should use for start.. i downgrade between 10.8.2 and 10.8.3 (where the code that cause the assert panic started) to test it without those console predicates and sip in newer version.. thank you

You can search for AppleIntelCapriController in WhateverGreen for some examples. The occurrences exist in kern_igfx.cpp. In kern_igfx.hpp, you can see that there are many sub modules defining different Intel GPU related patches. I suppose maybe you would add your own PatchSubmodule class.

Link to comment
Share on other sites
joevt
joevt
Posted
Posted
6 hours ago, kocoman said:

hmm I am not sure why the opencore legacy patcher could not do memory patch for capri instead they did on disk patching

https://dortania.github.io/OpenCore-Legacy-Patcher/PATCHEXPLAIN.html#on-disk-patches

I suppose it depends on the number and size of patches? Have you tried comparing the patched and unpatched version?
Are there kexts that read files from disk?

Link to comment
Share on other sites
kocoman
kocoman
Posted
Posted

I am able to use kernel->patch for opencore to bypass on high sierra.. but the same thing with corrected address does not work on big sur.. i am trying catlina but for some reason the cpu is extremely downclocked to the point the machine takes 30 min in the gui

Link to comment
Share on other sites
  • 1 year later...
 Share
Go to topic listing
×
×
  • Create New...