iMac Pro Theft Protection…

I found some interesting data, used for soem form of mobile connectivity, in the firmware for the iMac Pro. Something that may lead to advanced theft protection. Read on…

Even the cheapest iMac Pro costs $4999 and is thus far more expensive than any other iMac model that is now available, let alone the top of the line one with a price tag north of $10K, and it is ‘relatively easy’ to walk away with a 27-inch computer, and that may be why Apple is going to introduce a new kind of “Find my iMac Pro” type of theft protection. One that phones home to report the exact GPS location. And there’s no way of switching it off…

It’s either this, or the iMac Pro will introduce a new feature that will use a SIM card to make phone calls. Or perhaps the data that I found has to be a leftover from iOS for the iPhone.

For now. We will have to wait and see what happens when the iMac Pro arrives.

Edit: Oops. The estimated price tag of the the top model – the one with the Xeon W-2192, 4TB SSD Storage and 128GB Memory – was set to $15K, but that should have read $10K.

Sorry folks. I was unable to correct this earlier due to a hardware failure – Internet modem issue.

Apple EFI firmware not using the latest version of ME

You can now run software like EFIgy or my EFIver.py to see if you are using the latest EFI update from Apple, but that doesn’t necessarily mean that you are using the latest and greatest from Intel. Not for the following models:

File      : IM144_0183_B00.scap (iMac14,4)
ME version: 9.5.3.1526
Latest    : No

File      : IM151_0211_B00.scap (iMac15,1)
ME version: 9.0.6.1492
Latest    : No

File      : IM162_0212_B00.fd (iMac16,2)
ME version: 9.1.21.1000
Latest    : No

File      : IM171_0110_B00.fd (iMac17,1)
ME version: 11.0.0.1180
Latest    : No

File      : IM181_0151_B00.fd (iMac18,1)
ME version: 11.6.14.1219
Latest    : No

File      : IM183_0151_B00.fd (iMac18,x)
ME version: 11.6.14.1219
Latest    : No

File      : MBP114_0177_B00.fd (MacBookPro11,4)
ME version: 9.1.20.1035
Latest    : No

File      : MP61_0120_B00.scap (MacPro6,1)
ME version: 8.1.51.1471
Latest    : No

This shows us a limitation of EFIgy and my very own EFIver.py script. One that I would like to address soon. Speaking of which, the latest beta (v3.2) now also runs with Python3 – required for Windows and Linux – but you’ll need PyObjc.

And while I don’t really know if this opens un-patched attack vectors, or if this is Apple’s fault (but Intel?) but I like to keep my Mac safe. As much as I can, and then something like this isn’t really helping me.

Thanks to Plato Mavropoulos for his ME Analyzer!

Portable version of EFIver.py

I am working on a portable version of EFiver.py and v3.0 Beta is the first major update for this. It is committed a few minutes ago. You can grab it from the new Github beta branch.

This Beta version should work on macOS Sierra+ already, but I also want it to run on Windows and Linux. Eventually.

The next step is to solve all /tmp paths, which should be easy, and then we need to replace cpio with WinRar or 7-Zip. Or whatever. No idea what to use – I don’t even have a Windows PC.

Let me know if you have tips or ideas for me. Or other improvements.

Want to help or test this version? Great! Let me finish downloadSeed.py – a stripped down, download only version of installSeed.py – and I’ll commit it as soon as I am done with it.

iMac Pro Audio

The Tech Specs page where Apple shares stuff with us only mentions this:

Stereo speakers
Four microphones
3.5 mm headphone jack

Next to this:

“iMac Pro is as epic to your ears as it is to your eyes. Its enhanced stereo speakers deliver broad frequency response, rich bass, and more volume. So you’ll be able to hear that crashing cymbal, multilayered effect, or sample-based sound, all with remarkable fidelity.”

That may be anywhere between 15 and 25 Watt.

Perhaps that is all you need to know, but the number of microphones, coupled with the board-id of the iMac Pro (Mac-7BA5B2D9E42DDD94) leads to data for the Cirrus Logic CS42L83 and Texas Instruments TAS5764 chips. Here’s an XML snippet from BridgeAudioSP.driver

	<key>Underlying Devices</key>
	<dict>
		<key>Bridge Loopback</key>
		<dict>
			<key>Properties</key>
			<dict>
				<key>canBeDefaultSystemDevice</key>
				<true/>
				<key>canBeDefaultDevice</key>
				<true/>
				<key>transportType</key>
				<real>1651274862</real>
			</dict>
		</dict>
		<key>Digital Mic</key>
		<dict>
			<key>Properties</key>
			<dict>
				<key>canBeDefaultSystemDevice</key>
				<true/>
				<key>canBeDefaultDevice</key>
				<true/>
				<key>transportType</key>
				<real>1651274862</real>
			</dict>
		</dict>
		<key>CS42L83</key>
		<dict>
			<key>Properties</key>
			<dict>
				<key>canBeDefaultSystemDevice</key>
				<true/>
				<key>canBeDefaultDevice</key>
				<true/>
				<key>transportType</key>
				<real>1651274862</real>
			</dict>
		</dict>
		<key>TAS5764</key>
		<dict>
			<key>Properties</key>
			<dict>
				<key>canBeDefaultSystemDevice</key>
				<true/>
				<key>canBeDefaultDevice</key>
				<true/>
				<key>transportType</key>
				<real>1651274862</real>
			</dict>
			<key>Parameters</key>
			<dict>
				<key>OutputVolumeScalarMin</key>
				<real>0.1</real>
				<key>OutputVolumeScalarMax</key>
				<integer>1</integer>
			</dict>
		</dict>
	</dict>

Additionally. There is one more board-id that Apple is prepping up for release and that is Mac-CF21D135A7D34AA6. This one comes with only one microphone, and also links to the Maxim MAX98706.

		<key>MAX98706</key>
		<dict>
			<key>Parameters</key>
			<dict>
				<key>OutputVolumeScalarMin</key>
				<real>0.1</real>
				<key>OutputVolumeScalarMax</key>
				<real>1</real>
			</dict>
			<key>Properties</key>
			<dict>
				<key>canBeDefaultSystemDevice</key>
				<true/>
				<key>canBeDefaultDevice</key>
				<true/>
				<key>transportType</key>
				<real>1651274862</real>
			</dict>
		</dict>

The data itself is not so important, for most people, but why is Apple preparing/sharing data for another product, with board-id Mac-CF21D135A7D34AA6, at a time that we only expect the new iMac Pro in December?

Note: The HomePod isn’t running on macOS High Sierra so that’s not it.

Supported Mac models for Night Shift in High Sierra 10.13.2

I blogged about the Supported Mac models for Night Shift in Sierra 10.12.4+ and today I’d like to share an update on it.

Night Shift in macOS High Sierra 10.13.2 (Build 17C60c) has change a little. It’s still controlled by the CoreBrightness.framework and you need at least one of the following – or later – Mac models:

MacBookPro9,x
iMacPro1,x
iMac13,x
Macmini6,x
MacBookAir5,x
MacPro6,x
MacBook8,x

But as you can see here the iMac Pro is now also added and the CoreBrightness.framework now checks for the following Mac model names:

MacBookPro
iMac Pro
iMac
Macmini
MacBookAir
MacPro
MacBook

Night Shift is not supported on older Mac models, but you can change the data so that the check will pass instead of fail. Enabling Nigh Shift on older Mac models.

You can find the offset to the used data with help of:

nm /S*/L*/PrivateFrameworks/CoreBrightness.framework/CoreBrightness|grep _ModelMinVersion

0000000000021bc0 S _ModelMinVersion

Now you know the offset. Let’s dump the data:

xxd -s 0x21bc0 -l 28 /S*/L*/PrivateFrameworks/CoreBrightness.framework/CoreBrightness

00021bc0: 0900 0000 0100 0000 0d00 0000 0600 0000
00021bd0: 0500 0000 0600 0000 0800 0000

The marked bytes match with the following models:

MacBookPro9,x
iMacPro1,x
iMac13,x
Macmini6,x
MacBookAir5,x
MacPro6,x
MacBook8,x

1.) Disable SIP.
2.) Backup the CoreBrightness.framework
3.) Open the CoreBrightness.framework binary in a hex editor (app).
4.) Change the matching byte for your model.
5.) Save the file.

The next step is to re-sign the patched framework binary with:

sudo codesign -f -s - /S*/L*/PrivateFrameworks/CoreBrightness.framework/Versions/Current/CoreBrightness

Enjoy Nigh Shift on your no-longer-supported Mac 😉