What is the point of sharing…

What is the point of sharing… if (some) people do not respect the license under which your work is published?

I mean. The license clearly states:

You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use.

And if someone ‘forgets’ the rules and you remind them about the hard work you/your family have put into it, then you get comments like:

I take it that modesty is not your strong suit.:P

Or this one:

If it wasn’t invented by Pike then his father did.

Yeah budhead. You missed the news; Pull the earbuds out of your ears and listen, for once. I know that some of you can’t stand it, but it is a simple fact; my family did – and still does – a crap load of work for the OS X community.

So in short. Me hunting down this kind of issues has absolutely nothing to do with lack of modesty, but the lack of respect for hard work… time put in by someone else, and then you leave me with no other option; I have to remind you about it. Or is paying respect not a word in your vocabulary?

If not, then I would like to suggest that you look somewhere else for help/solutions and not use our work. Oh wait! You won’t be booting OS X today without the solutions we offered in the past. Yeah really…

Thank you for reading this blog post, and respecting our time, energy and hard work we’ve put into it. I presume that, from now on, you won’t forget to read and respect the license. Thanks ;)


Free Intel® i7-6700

I am speechless. I received a gift from Intel

Came with a nice note. Hey. What else can I say other than:

Thank you very much Intel

Time to setup a second Skylake based hack. Who is here to jump in? Asus, Gigabyte or Asrock? Oh wait. That was Gigabyte… yet again. Thank you guys!

Edit: The box from Intel arrived on Monday. The motherboard from Gigabyte on Tuesday, but I am still waiting for the G.Skill TridentZ modules to arrive. Not that it really matters, because I don’t have the time to setup a new Skylake configuration. Hopefully some time soon. Will keep you posted.

How to replace boot.efi with mine

El Capitan now runs on unsupported hardware, but that was only step one. We have a few more hurdles to take. Let’s start with the installation process. Take a look at this snippet from ia.log:

Extracting boot files from /Volumes/OS X Install ESD/BaseSystem.dmg
Extracting Boot Bits from Inner DMG:
Copied prelinkedkernel
Copied Boot.efi
Copied PlatformSupport.plist
Ejecting disk images
Generating the com.apple.Boot.plist file
com.apple.Boot.plist: {
	    "Kernel Cache" = "/.IABootFiles/prelinkedkernel";
	    "Kernel Flags" = "container-dmg=file:///Applications/Install%20OS%20X%2010.11.1.app/Contents/SharedSupport/InstallESD.dmg root-dmg=file:///BaseSystem.dmg";
Done generating the com.apple.Boot.plist file
Blessing /Volumes/MacintoshHD -- /Volumes/MacintoshHD/.IABootFiles

After which the InstallAssistantTool takes over:

Blessing Mount Point:/Volumes/MacintoshHD Folder:/Volumes/MacintoshHD/.IABootFiles plist:com.apple.Boot.plist
***************************** Setting Startup Disk *****************************
******           Path: /Volumes/MacintoshHD
******     Boot Plist: /Volumes/MacintoshHD/.IABootFiles/com.apple.Boot.plist
/usr/sbin/bless -setBoot -folder /Volumes/MacintoshHD/.IABootFiles -bootefi /Volumes/MacintoshHD/.IABootFiles/boot.efi -options config="\.IABootFiles\com.apple.Boot" -label OS X Installer
Bless on /Volumes/MacintoshHD succeeded

Note: The boot drive (ElCapitanSSD) had El Capitan 10.11.1 installed on it and the target drive (MacintoshHD) had Yosemite 10.10.5 installed on it.

But if I install El Capitan straight from the Yosemite drive (MacintoshHD) – after downloading it from the AppStore – then bless looks like this:

/usr/sbin/bless -setBoot -folder /OS X Install Data -bootefi /OS X Install Data/boot.efi -options config="\OS X Install Data\com.apple.Boot" -label OS X Installer

The only difference here is the folder name i.e. OS X Install Data instead of .IABootfiles. And after all required files are extracted from the DMG and are saved in the target folder, then your computer will reboot. The firmware will then load/execute boot.efi which will fail, of course… if that isn’t the 32-bit one!

You can setup the initial OS X Install Data directory by entering the following terminal command:

sudo ./startosinstall --applicationpath "/Applications/Install OS X El Capitan.app" --volume /Volumes/MacintoshHD

This installation phase is called “Boot 1” by Apple and also sets a (visible) NVRAM variable with the name rc_imgsrc_info and the data contains a binary plist with the UUID of the installation target. Other NVRAM variables written by the InstallAssitantTool include:


But I have yet to find its content.

Ok. Fine. So how are we going to solve this problem? Well. I was wondering if anyone had tried using a launch daemon. Something my late sister used for FileGuard:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
		<string>/OS X Install Data/boot.efi</string>
		<string>/OS X Install Data/PlatformSupport.plist</string>
		<string>/System /Library/CoreServices/boot.efi</string>

What this does is actually quite simple. It checks for changes/removal of the files in the above list (see array) and when that happens it triggers the daemon, where we can restore the file(s) that we want to use. This should work for the first two file in the list (array) – so that you don’t have to modify the DMG(?) – but I don’t know if it also works for the other two files. We need to verify this. And if it doesn’t work, then we can boot from the RecoveryHD and replace the files.

Update: The installer extracts bootbase.efi from the DMG and saves it as /.IABootfiles/boot.efi or /OS X Instal Data/boot.efi. This ‘special version’ of boot.efi has System Integrity Protection disabled and that allows Apple’s installer to work. You may lose track of which is which, but you can easily verify the version info. The shortest way is to enter:

grep 'bootbase.efi' boot.efi

That won’t return anything on the ‘normal’ copies of boot.efi. Only the extracted and renamed copies of bootbase.efi includes the name. Another way is to check the “booter-name” property with ioreg.

Note: I also made a similar version of bootbase.efi so that you can replace the one found in the DMG. Just wait for Peter Holbrook to compile it, and Mike to test it ;)

Update: Confirmed to be working by mikeboss!

El Capitan support for unsupported hardware is here!

A little over a month ago I blogged about El Capitan support for macosxbootloader and today, after 80 hours of research and development, I released two versions of boot.efi for El Capitan. One with a black background and a white Apple logo, and another one with a grey background and Apple logo.

You can read more about this project for El Capitan here.

Note: I should have added that using -f (flush caches) is no longer supported, and using it will throw a KP. In short. Please wait for me to add support for it (see development phase 3).

Edit: Great. Mike started a new developer thread over at macrumors.com

Have fun now!

Another one bites the dust…

I found something in the kernel that will likely – with almost 100% certainty – not be released by Apple:

int mac_iokit_check_nvram_delete(kauth_cred_t cred, const char *name);
int mac_iokit_check_nvram_get(kauth_cred_t cred, const char *name);
int mac_iokit_check_nvram_set(kauth_cred_t cred, const char *name, io_object_t value);

The last one is called by AppleEFINVRAM to block access to NVRAM for get/set/remove property functions, and the sandbox kext has hooks to it. The sandbox may have the platform profile, but AppleEFINVRAM acts as last defence. The guardian. So how do we bypass this you ask? For now we have three options on hack:

1.) Use FileNVRAM.kext to override the calls to get/set/remove property, and thus it won’t check for it.

2.) Replace AppleEFINVRAM.kext with an older version that does not call to checks. I used the one from 10.9.5 and it worked.

3.) Patch the AppleEFINVRAM.kext binary with:

perl -pi -e 's|\x0F\x85\x40\x01\x00\x00|\x90\x90\x90\x90\x90\x90|' AppleEFINVRAM

What this does is that it NOPs out the JNE instruction. The call to _mac_iokit_check_nvram_set in the kernel, and thus the check won’t be done. That’s all. Nothing more. Meaning that you can run csrutil disable from the command line, without the need to boot into the Recovery HD, and still get:

Successfully disabled System Integrity Protection. Please restart the machine for the changes to take effect.

But running nvram csr-active-config=%77%00%00%00 will fail due to the missing entitlement (com.apple.private.iokit.nvram-csr).

However. The fourth, and best option in my view, is to boot into the Recovery HD and be able to run csrutil disable from there. One problem. On a hack you still need one of the above workarounds, and on unsupported hardware for El Capitan… we need to get csrutil disable going. The problem is that I seem to be the last person willing to help others with running El Capitan on unsupported hardware. Like I did for Yosemite. And things are taking a lot of time. Tons of time… but we already made a lot of progress so hang in guys!!!

Anyway. Sure. Apple may not release all parts of the kernel, but what is the point of having an open source kernel, when almost everything that is interesting… is never released? Think about LZVN, XCPM and now this. Another one bites the dust. Yeah. Someone should kick Apple in the teeth for their lousy open source policy.

Note: I don’t know if csrutil disable works on Clover, but I will add it when I get a confirmation about it.

Edit: I forgot to mention that there a six more routines in the kernel. Look here: