Jump to content

Chameleon 2.4svn Official PKG Installer


ErmaC
4,261 posts in this topic

Recommended Posts

yep find a kext and installing it somewhere  is not far to do a transformation in "data" ready for the bootloader. You mean this as already done by some firmware?

 

Pike you need only the info.plist and the /MacOS/binary, right? 

or you need only some segment of the mach-o binary?...like creating then a .bin file?

 

...maybe I can help with an app

Link to comment
Share on other sites

update #3285 and 2737-Hervé, all work fine. :thumbsup_anim: :thumbsup_anim: :blush:

THX the CSR config is ok, then the problem is elsewhere.

Guys I'v just made an app to save the NVRAM to the file system... If I've to do not pay for a certificate for the helper tool the game is over!

Link to comment
Share on other sites

My new kext injection is huge. A lot of code is required to strip off the code signature/symbols of the kext(s) and to fix up the addresses and sizes so I was thinking of having a (command line) tool/app to prepare the kext for injection, with just the data and binary, so that the source code can be smaller and faster. What do you think?

I think there is a way to create kernelcache ab ovo at bootloader time including custom kernel and all kexts from le, sle and ee.

Just make the result to be correct.

Link to comment
Share on other sites

Hey guys,

 

Can someone help me with this kernel panic? Running 10.11 DB5. Tried the last 3 Enoch's revisions but no luck. I've upgraded from 10.10.4 with success. Got the DB2 update, worked fine, then the DB3, same thing, then after DB4 kernel panic. Since I had the boot loader on usb stick, I've plugged the hd to my iMac (27-late 2013). Removed the kexts for my Hac (from S/L/E), which basically where just 3, FakeSMC, VoodooHDA and AppleIntelE1000e (all the most recent versions), and booted from this hd on iMac. Updated to DB5 (I thought maybe will fix the error this way), installed the kexts again, used Kext Utility 2.6.4 to rebuild cache and hooked the hd back to my Hac (PC). Same kernel panic like in DB4. My specs - signature.

 

Thanks to anyone who could help, point me in the right direction, to fix it.

post-159649-0-26629300-1438894838_thumb.jpg

Link to comment
Share on other sites

Hey guys,

 

Can someone help me with this kernel panic? Running 10.11 DB5. Tried the last 3 Enoch's revisions but no luck. I've upgraded from 10.10.4 with success. Got the DB2 update, worked fine, then the DB3, same thing, then after DB4 kernel panic. Since I had the boot loader on usb stick, I've plugged the hd to my iMac (27-late 2013). Removed the kexts for my Hac (from S/L/E), which basically where just 3, FakeSMC, VoodooHDA and AppleIntelE1000e (all the most recent versions), and booted from this hd on iMac. Updated to DB5 (I thought maybe will fix the error this way), installed the kexts again, used Kext Utility 2.6.4 to rebuild cache and hooked the hd back to my Hac (PC). Same kernel panic like in DB4. My specs - signature.

 

Thanks to anyone who could help, point me in the right direction, to fix it.

No idea. This also happened to me with dp1 on the first/second attempt, then gone by itself...

anyway appear to be USB 2 related

Link to comment
Share on other sites

That's the"annoying" thing! I've never had any errors (kernel panics) like this before. And I've run successfully OS X from 10.6 to 10.10 (and I might add 10.11 DB1-DB3) on this Hac (PC) (just one hardware change, new graphics card; old was 9800 GT). (It's as close to a Mac Pro 4,1 as it can be.)

 

Anyway, thanks for taking the time to read my post. :)


It's not related to the boot loader but the USB kext (possibly modified? DSDT EHCx patch required?). Best to move the posts in the relevant 10.11 section...

Didn't modify any kext. All are stock. Unless Apple modified/changed something from DB3 to DB4 (which probably happened). Tried with/without dsdt in Extra. Same thing. dsdt was created in Yosemite with MaciASL (no errors/warnings).

 

Anyway, if you say is not a boot loader thing, I'll look in other more appropriate threads. Thanks.

Link to comment
Share on other sites

Hey guys,

 

Can someone help me with this kernel panic? Running 10.11 DB5. Tried the last 3 Enoch's revisions but no luck. I've upgraded from 10.10.4 with success. Got the DB2 update, worked fine, then the DB3, same thing, then after DB4 kernel panic. Since I had the boot loader on usb stick, I've plugged the hd to my iMac (27-late 2013). Removed the kexts for my Hac (from S/L/E), which basically where just 3, FakeSMC, VoodooHDA and AppleIntelE1000e (all the most recent versions), and booted from this hd on iMac. Updated to DB5 (I thought maybe will fix the error this way), installed the kexts again, used Kext Utility 2.6.4 to rebuild cache and hooked the hd back to my Hac (PC). Same kernel panic like in DB4. My specs - signature.

 

Thanks to anyone who could help, point me in the right direction, to fix it.

 

You can remove /System/Library/Extensions/IOUSBHostFamily.kext/Contents/PlugIns/AppleUSBUHCIPCI.kext, but usb may not work.

Or, fix it follow this.. http://www.insanelymac.com/forum/topic/306777-guide-usb-fix-el-capitan-1011/

  • Like 1
Link to comment
Share on other sites

Looks like for El Capitan DP4/DP5 and PB3 Enoch not work anymore....

 

Until now the CSR (Code Signing Restrictions) was set to 0x01 (00000001) (Thx Pike)

so only untrusted kext was allowed...

 

Pls try this UNTESTED versions:

Let me know...

 

ErmaC

 

 

Hi ErmaC,

 

Do they set BooterConfig=0x28 too, like Clover?

 

crazybirdy

Link to comment
Share on other sites

Looks like for El Capitan DP4/DP5 and PB3 Enoch not work anymore....

 

Until now the CSR (Code Signing Restrictions) was set to 0x01 (00000001) (Thx Pike)

so only untrusted kext was allowed...

 

Pls try this UNTESTED versions:

Let me know...

 

ErmaC

 

I can confirm that Chameleon v.2732 still works for DP6 and PB3/PB4 in my Hackintoshs.

However v.2749 testing versions listed here can NOT login to Desktop and freezes with a lots of sandbox errors.

Just for your reference.

Thanks to those who contributed for this excellent bootloader for us !

  • Like 2
Link to comment
Share on other sites

I have made some changes to DarwinDumper to show a notification to the user with regard to which dumps will fail to complete based on the current SIP settings of OS X 10.11. This works fine on a real Mac and with Clover but not yet with Enoch or Ozmosis. I have yet to test Revoboot.

 
On a real Mac, El Capitan DP6 boots with SIP enabled by default. Booting in to the recovery HD, loading the security configuration app and disabling security writes an nvram variable named csr-active-config with value %g%00%00%00 which is 67000000.
 
Booting El Capitan with the csr-active-config nvram variable present means the value ends up populated as a property in ioreg IODeviceTree:/options
 
Using a script, it’s easy to detect the SIP settings of the Mac by reading this value from ioreg using ioreg -lx -p IODeviceTree | grep csr-active-config. If that returns nothing then SIP is enabled as no csr-active-config nvram variable existed at boot.
 
I know there is csrutil status but that just returns either enabled for 00000000 or disabled for any other value and doesn’t give further details on which settings are on or off.
 
On a hack, I believe all methods used to boot should also behave the same way. So if we boot El Capitan DP6 without a csr-active-config nvram variable then SIP should be enabled.
 
Booting Clover 3251 without the CsrActiveConfig key in RtVariables section of the config.plist causes csr-active-config with a value of 00000000 to be written to nvram which enables El Capitan’s security. In turn, ioreg IODeviceTree:/options also ends up populated with 00000000.
 
EDIT: The above was incorrect and Clover does not write csr-active-config nvram var.
EDIT2: Yes it does.
 
I have not yet tested revoboot, and AFAIR, Ozmosis 1479 came out before these csr settings became knowledge so I don’t think that will work.
 
With Enoch 2748 though, booting El Capitan DP6 populates ioreg IODeviceTree:/chosen/nvram with the csr-active-config property of 3030303030303030. I believe this is an attempt to write 00000000 but written as ascii and not a series of nulls (00). Never the less, this value should reflect whatever state Enoch 2748 sets the system to. I think it’s 00000001 as I cannot modify say /System/Library/Extensions/ALF.kext/Contents/Info.plist, sudo dtrace -l | grep fbt returns nothing but I can load unsigned kexts.
 
Would it be possible to populate ioreg csr-active-config property with correct value? or have I missed something?
 
ps. It's late here and I'm turning in for the night but I'll reply to any queries tomorrow.
Edited by blackosx
Link to comment
Share on other sites

 

I have made some changes to DarwinDumper to show a notification to the user with regard to which dumps will fail to complete based on the current SIP settings of OS X 10.11. This works fine on a real Mac and with Clover but not yet with Enoch or Ozmosis. I have yet to test Revoboot.

 

 

Try to enable nvram support in Chameleon: FileNVRAM 1.1.4 (81).zip, as in past just use dedicated module. Only diff the kext is no longer embedded as before, so must installed in /S/L/E, and it's should be enough for Clover too, as told me by someone (ok with corrections..look at the source code)

Link to comment
Share on other sites

Nice, guys, I switched to Enoch, long time i no use chameleon, but nice to come back! :D

 

I've been having a couple of troubles, firsts of all, I don't know why but I can't load the edited AppleHda i've been using before, it just doesn't work :/ it just automagically worked, don't ask me how! i had the dsdt in the wrong folder  :P

and then i've tried, with the help of micky, thx a lot! to figure a way to properly enable sip, i've tried using the FileNVRAM.kext with the module, but i got stuck on a black screen with the beach ball at login, and without the module, with a successful boot, but without any nvram.plist file written after a sudo nvram boot-args="Arancino" on Extra so it seems that its not working...

 

Any tip?

 

thanks!

Link to comment
Share on other sites

That variable is an OS-owned variable, so it should indeed work with that Ozmosis version in my opinion. ;)

Okay. Thanks Download-Fritz. I'll run some tests when I get time.

Try to enable nvram support in Chameleon: FileNVRAM 1.1.4 (81).zip, as in past just use dedicated module. Only diff the kext is no longer embedded as before, so must installed in /S/L/E, and it's should be enough for Clover too, as told me by someone (ok with corrections..look at the source code)

I’d previously been using an older version of FileNVRAM.dylib in /Extra/modules and did have an nvram plist file in /Extra. I think that’s why I was seeing 3030303030303030 for csr-active-config in ioreg.?
 
Anyway, as suggested, I download FileNVRAM v1.4, added FileNVRAM.kext to S/L/E using Kext_Utility.app.v2.6.4, then added FileNVRAM.dylib to /Extra/modules. Rebooted in to El Capitan DP6 using Enoch 2748.
 
Running kextstat shows FileNVRAM.kext is not loaded.
 
Console shows:
15/08/2015 12:26:12.753 com.apple.kextd[43]: kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext "/System/Library/Extensions/FileNVRAM.kext"
15/08/2015 12:26:12.773 com.apple.kextd[43]: /System/Library/Extensions/FileNVRAM.kext - no compatible dependency found for com.apple.iokit.IOStorageFamily.
15/08/2015 12:26:12.773 com.apple.kextd[43]: Can't load /System/Library/Extensions/FileNVRAM.kext - failed to resolve dependencies.
15/08/2015 12:26:12.774 com.apple.kextd[43]: Load com.xZenue.kext.FileNVRAM failed; removing personalities from kernel.
$ sudo kextload -v /System/Library/Extensions/FileNVRAM.kext
Requesting load of /System/Library/Extensions/FileNVRAM.kext.
/System/Library/Extensions/FileNVRAM.kext failed to load - (libkern/kext) dependency resolution failure; check the system/kernel logs for errors or try kextutil(8).
Console shows:
15/08/2015 12:39:23.813 sudo[947]: blackosx : TTY=ttys002 ; PWD=/Users/blackosx ; USER=root ; COMMAND=/sbin/kextload -v /System/Library/Extensions/FileNVRAM.kext
15/08/2015 12:39:23.963 com.apple.kextd[43]: kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext "/System/Library/Extensions/FileNVRAM.kext"
15/08/2015 12:39:24.072 com.apple.kextd[43]: /System/Library/Extensions/FileNVRAM.kext - no compatible dependency found for com.apple.iokit.IOStorageFamily.
15/08/2015 12:39:24.088 com.apple.kextd[43]: Can't load /System/Library/Extensions/FileNVRAM.kext - failed to resolve dependencies.

Does it work for others?

I see JahStories has a similar report. JahStories can you check kextstat and console to see if you see the same errors?

Link to comment
Share on other sites

compiled yesterday by mickey, this one loads.

FileNVRAM.kext-2.zip

//  FileNVRAM
//
//  Created by Evan Lojewski on 1/13/13.
//  Copyright (c) 2013-2014 xZenue LLC. All rights reserved.
//
// This work is licensed under the
//  Creative Commons Attribution-NonCommercial 3.0 Unported License.
//  To view a copy of this license, visit http://creativecommons.org/licenses/by-nc/3.0/.
//
Link to comment
Share on other sites

So back to my original question. How to get Enoch to show it's actual SIP settings in ioreg IODeviceTree:/options ?

I understand that this would not normally be populated unless a csr-active-config nvram var exists. But with Enoch, a csr-active-config nvram variable doesn't mean much as I believe the internal settings control the SIP state, which I believe is 00000001

 

EDIT: Yes, I've just seen it confirmed by EmaC in this post

 

I've just manually added an nvram var csr-active-config with value of 00000000 and on next boot, nvram -p shows:

csr-active-config %00%00%00%00

ioreg IODeviceTree shows:

 

post-331032-0-90610000-1439644018_thumb.png

 

Yet I can still load unsigned kexts.

 

EDIT: Comparing Clover to Enoch

 

Clover

csr-active-config = 00000000

$ nvram -p
csr-active-config %00%00%00%00
$ ioreg -lx -p IODeviceTree | grep csr-active-config
          "csr-active-config" = <00000000>
DarwinDumper Audio and BIOS - System dumps.
15/08/2015 15:22:57.821 com.apple.kextd[43]: Untrusted kexts are not allowed
15/08/2015 15:22:57.821 com.apple.kextd[43]: ERROR: invalid signature for com.coresystems.driver.DirectHW, will not load
15/08/2015 15:22:59.624 com.apple.kextd[43]: Untrusted kexts are not allowed
15/08/2015 15:22:59.624 com.apple.kextd[43]: ERROR: invalid signature for org.voodoo.driver.VoodooHDA, will not load
Enoch with FileNVRAM
csr-active-config = 00000000
$ nvram -p
csr-active-config %00%00%00%00
$ ioreg -lx -p IODeviceTree | grep csr-active-config
          "csr-active-config" = <00000000>

DarwinDumper Audio and BIOS - System dumps.

15/08/2015 15:28:14.146 com.apple.kextd[43]: kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext "/tmp/DirectHW.kext"
15/08/2015 15:28:23.817 com.apple.kextd[43]: kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext "/tmp/VoodooHDA.kext"

 

So would it be possible to enoch to populate ioreg IODeviceTree:/options to show the actual state of SIP on the currently booted system? as that value on a real Mac correctly represents the system state.


Is that loading even with the module?

Not sure as I don't see any reference to the module in bdmesg.

Lemme try to move it to a different /Extra/modules dir.

 

EDIT: Nope. With the module the boot process looks like it's completed but I don't get to desktop.

Link to comment
Share on other sites

×
×
  • Create New...