New MacPro model/board-ids

Here is a quick update:

model-id: MacPro6,1
board-id: Mac-F60DEB81FF30ACF6

Just so that you know what to use 😉

Edit: More new board-id’s…

Mac-35C1E88140C3E6CF – MacBookAir6,1
Mac-7DF21CB3ED6977E5 – MacBookAir6,2
Mac-031B6874CF7F642A – IGPU (Macmini7,N)
Mac-189A3D4F975D5FFC – IGPU (MacBookPro11,N)
Mac-3CBD00234E554E41 – IGPU (MacBookPro11,N)
Mac-27ADBB7B4CEE8E61 – IGPU + NVIDIA (iMac14,N)

Edit 2: I found two more in ApplePlatformEnabler.kext

Mac-6F01109E16C71B86 – IGPU

Edit 3: The Mac model identifiers in red are what I believe the next model identifiers. This based on the (absence) of the PublishBatteryFactors property and the power management data where the iMac traditionally has little to no PM feature support.



I checked AppleIntelHD5000Graphics.kext and found the following device-id’s:

0x0090 8086 ?
0x0091 8086 ?
0x0092 8086 ?
0x0c26 8086 Intel Haswell SDV Mobile (GT3)
0x0c16 8086 Intel Haswell SDV Mobile (GT2)
0x0c06 8086 Intel Haswell SDV Mobile (GT1)
0x0c22 8086 Intel Haswell SDV Desktop (GT3)
0x0d26 8086 Intel Haswell CRW Mobile (GT3)
0x0a26 8086 Intel Haswell ULT Mobile (GT3) (MacBook Air Mid 2013)
0x0a16 8086 Intel Haswell ULT Mobile (GT2)
0x0426 8086 Intel Haswell Mobile (GT3)
0x0416 8086 Intel Haswell Mobile (GT2)
0x0406 8086 Intel Haswell Mobile (GT1)
0x0d22 8086 Intel Haswell CRW Desktop (GT3)
0x0412 8086 Intel Haswell Desktop (GT2)
0x0a2e 8086 Intel Haswell ULT Mobile (GT3)

Which I matched with help of intel_driver.h Seems like Desktop GT2 is supported. Interesting isn’t it.

Edit: Link to intel_driver.h added

Kext Requirements for OS X 10.9 Mavericks

The following information is a developer must read – bad news for hackintosh users – and good news for (future) Mac users. Keeping the bad guys out… to help protect you and your hardware. The side effect is that it might stop people, eventually, from using the latest and greatest aka OS X 10.9 Mavericks on a hack (didn’t happen in the 10.9 GM but it may still happen in 10.10). Well. Until someone comes up with another great hack of course.

Protecting the kernel

  • OS X 10.9 code signing verification for kexts
    • OS X 10.9 all kexts signatures are verified
    • OS X 10.9 unsigned or invalid signatures are non fatal (with one* exception)
    • OS X 10.9 Signed kexts will not load on releases prior to OS X 10.8
    • Valid  code signatures will eventually be mandatory for all kexts
    • Use kextutil -tn to verify your kext

Kext loading

  • OS X 10.9 auto-load, on-demand load by CFBundleIdentifier, and kernel cache build
    • Searches in /System/Library/Extensions and /Library/Extensions
    • Must code sign* kexts in /Library/Extensions

Where we want your kexts installed

  • Auto-load kexts required for rooting, or auto-searching ofkexts
    • OS X 10.9, /Library/Extensions MUST be signed!
    • OS X 10.9, /Systems/Library/Extensions (for compatibility)
    • OS X 10.9 and earlier, install unsigned kexts in /System/Library/Extensions
  • All other kexts
    • Signed kexts CAN go into: /Library/Extensions
    • Do not install anywhere in /System (locked in the near future).
    • Other common locations still OK

Kext signing

  • New with OS X 10.9, certificate for signing applications and kexts

In OS X 10.9

  • Kexts in /Library/Extensions will NOT load if they are unsigned or have a signature verification error
  • Users will see the “no load” alert dialog (need to OK it)
  • Kexts outside /Library/Extensions will load if they are unsigned or have a signature verification error
  • But users will see this – rather annoying – dialog
    Example of UnidentifiedKernelExtensions dialog
  • Code signature verification warnings and error messages
  • Most common code signature verification error codes
    • -67030: something in kext bundle was modified
    • -67062: kext is not signed
    • Code signing error codes are in Security.framework:
      • #include <Security/CSCommon.h>

Example after modified Info.plist:[40]: WARNING – Invalid signature -67030 for kext URL = “file:///Users/local/AppleSamplePCI.kext/”, ID – “”

All kernel extensions in: /Library/Extensions must be signed and unsigned or otherwise invalid kexts in: /System/Library/Extensions will trigger an annoying dialog.

Apple also said that the /System directory will be locked in the future, but didn’t mention when or in which version of OS X that would be done. We just have to wait and see when it happens, but if this is introduced (in whatever OS version that may be) then we are locked out and that means that editing plists and/or patching bin (executable) files of signed kexts will be impossible, and since there are plenty kexts that need a binary and/or plist patch… you soon get the picture.

Source: Apple WWDC session video (707) and PDF.

Edit: Example of “Kernel extensions are not from identified developers” added.

Edit 2: Source added. Part about the locking of the /System directory reworded, this because it is unclear in which version of OS X it will be locked down.

Edit 3: Reworded a sentence that stated that people would be unable to use OS X 10.9 Mavericks on their hack. Sorry folks. I had no idea that this was still there. Should have been changed a long time ago, but I forgot about it.

Thanks to joe75 for the heads up!

RevoBoot is ready for OS X 10.9 aka Mavericks

Some of you may know that I lost work due to an accidental rm by Jeroen, and thus we had to redo the work for OS X 10.9 Mavericks and Haswell processor support

Not that I had a clue about the name Apple was going to use, but I guessed that it wouldn’t take long before Apple pushed DP1 out of the door. And since we here like to be prepared… RevoBoot is ready for Mavericks and Haswell processors. Yah.

Edit: Added Haswell compatibility info.

XNU 10.8.3 Haswell Compatibility

The mach_kernel for OS X 10.9 Mavericks has built-in support for Haswell and Haswell ULT processors, but since that is not released yet. Not for a long time, you may as well want to patch the XNU (10.8.3) source code. And here is what you need to add:




+			break;
+			break;


	switch (cpuid_cpufamily()) {



Note: If you don’t know what to do with it, forget it. No support here.

Edit: Filename error corrected. Thanks to necrophagous for the tip.

New MacBook Air

Good news!

Apple introduced a new 13-inch MacBook Air today. One with a Intel® Haswell i5-4250U (ULT) processor and a faster one with the Intel® Haswell i7-4650U processor. Both with a max TDP of just 15 W. This surely helps to improve battery life – should run all day long now, but I have yet to see if this is true or not.

The max Turbo frequency of the i5-4250U is 200 MHz lower as the previous generation, but it is just as fast. Want to see the GeekBench results? Here they are:
GeekBench 32-bit (MacBookAir6,2)
GeekBench 64-bit (MacBookAir6,1)

More interesting data:

model identifier: MacBookAir6,2
board-id: Mac-7DF21CB3ED6977E5
OS X version: 10.8.4 (Build 12E3067)
iGPU version: Intel® HD graphics 5000

All compiled into RevoBoot and ssdtPRGen. This along with all other Haswell processor data (soon to be pushed into the Githib repository).

p.s. You can pull this version of OS X of off the Apple servers, but I cannot tell you how. Just use the data and… well you know. Recovery mode anyone?


Edit 1: Links to processor specs added.
Edit 2: MacBookAir6,1 data added.

model identifier: MacBookAir6,1
board-id: Mac-35C1E88140C3E6CF

Update: The SMC version info is 2.13f5 (smc-huronriver) and I also noticed a new SMC key BFCL(6) but I have yet to figure out where and what it is used for. Mavericks also reads F0AC and F0Mx.

Haswell mach_kernel patch

Here is a quick and dirty patch for the mach_kernel to let it run IvyBridge code on Haswell CPUs. This is the original assembler code:

ffffff80002a85e1 83f83a cmpl $58, %ex
ffffff80002a85e4 7505 jne 0xffffff80002a85eb
ffffff80002a85e6 bb35e8651f movl $526772277, %ebx // CPUFAMILY_INTEL_IVYBRIDGE

Which you want to patch by searching for eb0a83f83a and replace it with eb0a83f83c