Bootloader Chameleon 2.4svn Official PKG Installer

[JahStories]

Hi meklort,

 

As you said, I've noticed importants slowdowns while using your kext without the module on Enoch during boot time, something like 8 seconds without it and 20 seconds with it.

I've even tried using it with the module but it makes the system crash on boot, exactly, stuck on a black screen at login and eventually with the spinning "beach ball"...

 

Btw, it seems that having nvram.kext correctly working could be a backdoor to fool the CSR status and do other stuff, am I right?

 

Not everyone here is a coder, sometimes an easier explanation could be a wiser decision. IMHO

 

[Micky1979]

 

Pike the kext can't be loaded running kextxache:

kxld[com.xZenue.kext.FileNVRAM]: The following symbols are unresolved for this kext:
kxld[com.xZenue.kext.FileNVRAM]:  AppleNVRAM::setPath(OSString*)
kxld[com.xZenue.kext.FileNVRAM]:  _mCtx
Link failed (error code 5).

and also running kextutil:

sudo kextutil /System/Library/Extensions/FileNVRAM.kext 
/System/Library/Extensions/FileNVRAM.kext is invalid; can't resolve dependencies.
/System/Library/Extensions/FileNVRAM.kext is invalid; can't resolve dependencies.
/System/Library/Extensions/FileNVRAM.kext is invalid; can't resolve dependencies.
Diagnostics for /System/Library/Extensions/FileNVRAM.kext:
Validation Failures: 
    Info dictionary missing required property/value: 
        CFBundleIdentifier


Warnings: 
    Personality has no CFBundleIdentifier; the kext's identifier will be inserted when sending to the IOCatalogue: 
        FileNVRAM

the second issue because "com.xZenue.kext.FileNVRAM" is not set as bundle identifier in Info.plist, but I have trouble to fix _mCtx issue in write/read_buffer function (no longer exist). Any advice?

[Micky1979]

 

 

 

Well, instead of including kext as mkext (kernelpatcher hang?), just leave separate files.

Pike, attached FileNVRAM.dylib module that match your FileNVRAM.kext fork(nvram.plist path), however see my last post.

 

Source included with compiler errors fixed.  Can be compiled at same time along with Chameleon/Enoch, just put into /i368/modules and replace the already compiled version.

FileNVRAM source+precompiled module.zip

Edited August 24, 2015 by Micky1979

[meklort]

 

kxld[com.xZenue.kext.FileNVRAM]: The following symbols are unresolved for this kext:
kxld[com.xZenue.kext.FileNVRAM]:  AppleNVRAM::setPath(OSString*)
kxld[com.xZenue.kext.FileNVRAM]:  _mCtx
Link failed (error code 5).

 

 

mCtx is referenced by FileIO.c

 

This is compiled as a C file and cannot access C++ names without having them managed first.

Additionally, mCtx is a member variable of the FileNVRAM class. You cannot access it without the class pointer.

 

If read/write_buffer needs to access it, these functions need to instead be moved into the class as member functions so that they can access the variable.

 

So... the short answer is... revert the changes to that file, and it'll work. Alternatively, move the functions into FileNVRAM.cpp (and set the names properly, and declare them properly in FileNVRAM.h)

 

Hi meklort,

 

As you said, I've noticed important slowdowns while using your kext without the module on Enoch during boot time, something like 8 seconds without it and 20 seconds with it.

I've even tried using it with the module but it makes the system crash on boot, exactly, stuck on a black screen at login and eventually with the spinning "beach ball"...

 

Btw, it seems that having nvram.kext correctly working could be a backdoor to fool the CSR status and do other stuff, am I right?

 

Not everyone here is a coder, sometimes an easier explanation could be a wiser decision. IMHO

 

 

The simple explanations is... OS X blocks until NVRAM is available. The module makes it happen early for FileNVRAM. If you don't use the kext, apple's default one takes over and lets the boot happen quickly.

The other explanations were more for people with a programming background.

 

Yes, FileNVRAM could be use to assist the CSR changes for 10.11, but there are security implications that have to be taken into account properly.

 

As mentioned before... I've never tried the kext or module with 10.11 (or 10.10), so I didn't know there was a problem. Additionally... I received a grand total of 0 bug reports. I also don't think anyone has sent me an email or a pm about it either. If nobody tells me there's an issue, I'll assume there isn't one. 

 

So... please file bug reports if you find them.

[Micky1979]

 

Yes, FileNVRAM could be use to assist the CSR changes for 10.11, but there are security implications that have to be taken into account properly.

 

Thanks for additional explanation. You think I can do something like:

 

if(is_module_loaded("FileNVRAM.dylib", 0)){

    AddNvramVariable(.....);

}

else {

    // use o.c.B.p or default value

}

 

to add what we need?

 

good night to all

[JahStories]

@Meklort

 

Yes, FileNVRAM could be use to assist the CSR changes for 10.11, but there are security implications that have to be taken into account properly.

Can you be more precise?

 

Thanks

[Pike R. Alpha]

Pike the kext can't be loaded running kextxache...

Sorry. I was in a hurry and did run kextutil to verify it. I did commit some (untested) changes. I have no idea why Xcode 7 (Beta) changed the CFBundleIndentifier, because it sure wasn't me. Anyway. It compiled and the error is gone.

 

Edit: Confirmed working (thanks Bry)!

 

@meklort,

 

Yes. It is better to move read_buffer() and write_buffer() to FileNVRAM.cpp as that takes care of the security issues. Now you can only overwrite /Extra/NVRAM/nvram.plist but so can any other process.

[meklort]

Yes. It is better to move read_buffer() and write_buffer() to FileNVRAM.cpp as that takes care of the security issues. Now you can only overwrite /Extra/NVRAM/nvram.plist but so can any other process.

 

Please explain this security issue to me.

 

You've hard coded the kext to now use /Extra/NVRAM/nvram.plist.

If someone previously wanted to modify a file, they could do so as root. Sure, they could tell FileNVRAM to point to a different file path, but they'd have to be root to do so (only root can write nvram variables).

 

So... you're previous options were... be root... or be root. How is that any different from the new option of.... be root?

My understanding is that root is now locked out from modifying certain system files, and so would this kext as it uses the root context.

 

 

Perhaps a *good* fix would be something like the following:

(1) Does the file pointed to exists?

(2) If File does not exists, continue, file path is OK

(3) If file does exist, verify that it's contents are an XML dictionary in the FileNVRMA format.

(4) If contents OK, file path is ok

(5) If contents are bad, yell at the user and don't use the path.

 

 

 

Thanks for additional explanation. You think I can do something like:

 

if(is_module_loaded("FileNVRAM.dylib", 0)){

    AddNvramVariable(.....);

}

else {

    // use o.c.B.p or default value

}

 

to add what we need?

 

good night to all

Something like that yes, although I don't remember the proper usage of is_module_loaded (it might just be "FileNVRAM").

 

Also, if you are calling nay symbols in FileNVRAM directly, you must either

(1) Be running as a module

or

(2) Look up the symbols at runtime using the module system apis. 

 

 

@Meklort

Can you be more precise?

 

Thanks

FileNVRAM is not a signed kext. So, to load it, you have to disable the CSR, or bypass it somehow. Additionally, the nvram file the FileNVRAM uses should use the additional security enhancements that Apple's added to lock out even root from touching it (and still have some way to touch it by itself).

[Pike R. Alpha]

Please explain this security issue to me.

 

You've hard coded the kext to now use /Extra/NVRAM/nvram.plist.

If someone previously wanted to modify a file, they could do so as root. Sure, they could tell FileNVRAM to point to a different file path, but they'd have to be root to do so (only root can write nvram variables).

 

So... you're previous options were... be root... or be root. How is that any different from the new option of.... be root?

My understanding is that root is now locked out from modifying certain system files, and so would this kext as it uses the root context.

 

Perhaps a *good* fix would be something like the following:

(1) Does the file pointed to exists?

(2) If File does not exists, continue, file path is OK

(3) If file does exist, verify that it's contents are an XML dictionary in the FileNVRMA format.

(4) If contents OK, file path is ok

(5) If contents are bad, yell at the user and don't use the path.

Yes. I indeed hardcoded the path. And for good reason. Apps can call functions in kexts without being root. Just look at the Intel Power Gadget. Then look at what kexts Apple blocked, being low level kext because they won't allow everything. I did ask of writing to disk, from a kext, is a good idea and they said nope. Don't do it. Move code to a sandboxed app and let the app handle the writes to disk.

 

I already check the file type (regular file required) and my local tree already checks for a proper XML dictionary.

[meklort]

Yes. I indeed hardcoded the path. And for good reason. Apps can call functions in kexts without being root. Just look at the Intel Power Gadget. Then look at what kexts Apple blocked, being low level kext because they won't allow everything. I did ask of writing to disk, from a kext, is a good idea and they said nope. Don't do it. Move code to a sandboxed app and let the app handle the writes to disk.

 

I already check the file type (regular file required) and my local tree already checks for a proper XML dictionary.

Pike,

 

Apps *cannot* call arbitrary functions in a kext. There are a specific subset of functions that they can call. FileNVRAM validate that the user is root before allowing the write to continue. Read the code, this is *already* taken into account.

 

Yes, It's well know that File IO is strongly discouraged. It's easy to mess up.

[Pike R. Alpha]

Pike,

 

Apps *cannot* call arbitrary functions in a kext. There are a specific subset of functions that they can call. FileNVRAM validate that the user is root before allowing the write to continue. Read the code, this is *already* taken into account.

 

Yes, It's well know that File IO is strongly discouraged. It's easy to mess up.

I wouldn't say otherwise. I wrote the app and BOOM. Nothing is stopping me.

[meklort]

Please submit a bug report that shows a usermode app having the ability to things it shouldn't with FileNVRAM.

Once you do, and I can reproduce the issue, then I can fix it.

 

I'm still not sure how you can call an arbitrary function in kernel mode from usermode... or how you are bypasssing the root check that is explicitly in filenvram, but if you submit a bug report, I'll look into it and fix it properly.

[blackosx]

I find using Chameleon today that device-properties from ioreg fail to be converted to xml by gfxutil with error message:

invalid hex inputfile (filesize dont match or zero)

 

Looking back, I found cparm's commit 2415 made changes to /i386/libsaio/device_inject.c. Reverting these changes allows gfxutil to convert device-properties from ioreg to xml.

 

I know cparm has committed many working solutions to lots of projects so I do not necessarily think his code is wrong, instead think maybe gfxutil cannot correctly convert the optimised device-properties generated by commit 2415?

[Micky1979]

 

 

 

 

Messrs, I must admit I'm lost and I am not sure on what you want to demonstrate. If I understand correctly between user space and kernel space there can be an intermediary? If no, why Apple introduces things like task for pid limitation?

And then if a "rootkit" has root privileges what can stop it to write the nvram.plist directly? (another question should be why do that.. since only exist on a Hack... (ok why not...) )

 

 It seems like is not a big deal to have a configuration file on the file system, which can among other things not be owned by the root user if you played with him (w/o a check at boot time). So you are talking about worry about sophisticated techniques, when files are there ready to be handled? File with newer time stamp is loaded as I see in the module, so can be added to the EFI partition too w/o be root, and loaded at next reboot.

I hope not to be stupid saying this, because I would like to understand better. (why I did not understand anything  )

Thanks

 

I find using Chameleon today that device-properties from ioreg fail to be converted to xml by gfxutil with error message:

invalid hex inputfile (filesize dont match or zero)

 

Looking back, I found cparm's commit 2415 made changes to /i386/libsaio/device_inject.c. Reverting these changes allows gfxutil to convert device-properties from ioreg to xml.

 

I know cparm has committed many working solutions to lots of projects so I do not necessarily think his code is wrong, instead think maybe gfxutil cannot correctly convert the optimised device-properties generated by commit 2415?

 

Hi, I have a newer version of gfxutil:gfxutil.zip if you want to try, but if reverting the changes works..probably is the new code

[Pike R. Alpha]

Please submit a bug report that shows a usermode app having the ability to things it shouldn't with FileNVRAM.

Once you do, and I can reproduce the issue, then I can fix it.

 

I'm still not sure how you can call an arbitrary function in kernel mode from usermode... or how you are bypasssing the root check that is explicitly in filenvram, but if you submit a bug report, I'll look into it and fix it properly.

I was talking about the changes that I made. Not your v1.4 (using cached data, and that was wrong).

 

Anyway. Seems like we shouldn't call vfs_context_current() from kexts:

 

Kexts should not use this function--it is preferred to use vfs_context_create(NULL) and vfs_context_rele(), which ensure proper reference counting of underlying structures.

See vnode.h

[blackosx]

Hi, I have a newer version of gfxutil:gfxutil.zip if you want to try, but if reverting the changes works..probably is the new code

Thanks for this new build Micky1979. Where did you get it? Can you point to McMatrix's source code?

 

Anyway, it has the same 'invalid hex inputfile (filesize dont match or zero)' result using cparm's commit 2415 so yes, I believe the commit maybe does not function correctly.

 

@cparm - Is this something you can fix for your commit or shall we revert to the previous code?

[Micky1979]

Thanks for this new build Micky1979. Where did you get it? Can you point to McMatrix's source code?

Sorry  I get it google'ing until I found a Github repo searching for other stuff (probably was part of a largest project), but this happened some days ago, I dont have a link for you, but the source yes...BTW resolving some compiler warnings (casting).

gfxutil source.zip

[meklort]

Anyway. Seems like we shouldn't call vfs_context_current() from kexts:

 

Kexts should not use this function--it is preferred to use vfs_context_create(NULL) and vfs_context_rele(), which ensure proper reference counting of underlying structures.

See vnode.h

 

 

Using vfs_context_current was done by design. If you use vfs_context_create, it'll use the current tasks permission. This becomes an issue when sandboxing is taken into account. Binaries like blued can no longer cause the nvram plist to be written, and things break. So, if you change it, yes, it'll usually work, but certain cases will break.

 

EDIT: Some further clarification: Using context_create / rele in the *current* location (where mCtx is set) would probably be fine. Using the functions when you call read/write_buffer would not would due to the above issue.

[Slice]

 

I find using Chameleon today that device-properties from ioreg fail to be converted to xml by gfxutil with error message:

invalid hex inputfile (filesize dont match or zero)

 

Looking back, I found cparm's commit 2415 made changes to /i386/libsaio/device_inject.c. Reverting these changes allows gfxutil to convert device-properties from ioreg to xml.

 

I know cparm has committed many working solutions to lots of projects so I do not necessarily think his code is wrong, instead think maybe gfxutil cannot correctly convert the optimised device-properties generated by commit 2415?

 

cparm commit is good. The mistake was in previous code.

Should be

- int len = string->length * 2;
+ int len = string->length * 2 + 1;

because we should allocate an additional space for ascii string zero terminating.

[blackosx]

Thanks for taking the time to look in to it Slice.

It's good to know cparm's commit was good

 

I'll test your recommended fix later.

Sorry  I get it google'ing until I found a Github repo searching for other stuff (probably was part of a largest project), but this happened some days ago, I dont have a link for you, but the source yes...BTW resolving some compiler warnings (casting).

Thanks Micky1979

[ErmaC]

cparm commit is good. The mistake was in previous code.

Should be

- int len = string->length * 2;
+ int len = string->length * 2 + 1;

because we should allocate an additional space for ascii string zero terminating.

 

Commit done 2757

---

New revision on the download section.

Enoch 2758.

- clang compilation fix (3.7 / xcode 7.0) errors on compiling interrupts.c (credits to cmf_)

- fix allocate space for ascii string zero terminating in device_inject.c (thx Slice and BlackOsx)

- Better SIP output in bdmesg

 

output ex:

System Integrity Protection status: disabled (Custom Configuration).
CsrActiveConfig = 0x77 (1110111)

Configuration:
Kext Signing: disabled
Filesystem Protections: disabled
Task for PID: disabled
Debugging Restrictions: enabled
Apple Internal: disabled
DTrace Restrictions: disabled
NVRAM Protections: disabled

ErmaC

[Pike R. Alpha]

Commit done 2757

 

Thanks for fixing cparm's error, with your commit, but may I give you an advise? Why not use this:

int len = (string->length * 2) + 1;

or this instead:

int len = ((string->length * 2) + 1);

Then people would know instantly what it does.

[ErmaC]

 

int len = ((string->length * 2) + 1);

Yep will be done! ;-)

 

- ErmaC

[Micky1979]

hi guys,

 

Chameleon Enoch r2748 works fine with -f to load /Extra/Extensions/kexts with DB4~DB6 as Clover r3259's kernel patch. :thumbsup_anim:

sudo perl -pi -e 's|\xC3\x48\x85\xDB\x74\x70\x48\x8B\x03\x48\x89\xDF\xFF\x50\x28\x48|\xC3\x48\x85\xDB\xEB\x12\x48\x8B\x03\x48\x89\xDF\xFF\x50\x28\x48|g' /System/Library/Kernels/kernel

Is it possible to add to Chameleon code??  .... you know!!

 

crazybirdy

Hi crazybirdy you can do a test with the attached file in 10.10.5 and 10.11 with original kernel ??

This is an unstable version, so please try on USB, and if can boot (for me works) a bdmesg is appreciated. 

Thanks

Edited August 31, 2015 by Micky1979
attachment removed

[crazybirdy]

 

Hi crazybirdy you can do a test with the attached file in 10.10.5 and 10.11 with original kernel ??

This is an unstable version, so please try on USB, and if can boot (for me works) a bdmesg is appreciated. 

Thanks

 

I test it (-v -f, original kernel) with 1095, 10105, 1011DB7, and only 1095 works fine as bdmesg.txt show.

bdmesg-1095.txt

10105, and 1011DB7 get gray screen then reboot....as video below.

https://www.sendspace.com/file/rwy7c6

 

Thx, FYI.

 

BTW, I use boot1h2 from Clover to boot with boot1, boot2,....boot9...so, it's easy to test any boot file, you know!