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.

Advertisements

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 😉

High Sierra DP/Beta 10.13.1 Build(17B46a) seeded…

Apple today seeded the fifth beta of an upcoming macOS High Sierra update to developers. Three days after seeding the fourth macOS High Sierra 10.13.1 beta.

Build Information

The seeded build is: 17B46a

SMC versions

All the same. Nothing updated.

EFI versions

There’s a new firmware update for one of the Mac mini’s – see snippet below from EFIVer.py.

—————————————————————————
EFIver.py v2.6 Copyright (c) 2017 by Dr. Pike R. Alpha
—————————————————————————
Mac-35C5E08120C7EEAF | Macmini7,1 | MM71.88Z.0226.B00.1709290808
—————————————————————————

Apple SSD Firmware

There are new firmware updates for the SSD in three Mac models:

Mac-4B682C642B45593E / iMac18,1
Mac-77F17D7DA9285301 / iMac18,2
Mac-BE088AF8C5EB4FA2 / iMac18,3

USBC Firmware Updates

Mac-473D31EABEB93F9B / MacBookPro13,1
Mac-4B682C642B45593E / iMac18,1
Mac-551B86E5744E2388 / MacBookPro14,3
Mac-66E35819EE2D0D05 / MacBookPro13,2
Mac-77F17D7DA9285301 / iMac18,2
Mac-9AE82516C7C6B903 / MacBook9,1
Mac-A5C67F76ED83108C / MacBookPro13,3
Mac-B4831CEBD52A0C4C / MacBookPro14,1
Mac-BE088AF8C5EB4FA2 / iMac18,3
Mac-BE0E8AC46FE800CC / MacBook8,1
Mac-CAD6701F7CEA0921 / MacBookPro14,2
Mac-EE2EBD4B90B839A8 / MacBook10,1

Nothing really exiting. Looks more like the GM.

Unused Bits in Processor Model Check…

I blogged about checks for two unused processor models when Sierra DP-4 was released and there are still a couple of unused bits – in High Sierra as well – that Apple could use for two Coffee Lake processors and the new Mac Pro. Here’s the data:

bit-10 (0x0400) possibly reserved for Coffee Lake Mobile
bit-11 (0x0800) possibly reserved for Coffee Lake DT
bit-15 (0x8000) possibly reserved for Scalable Xeon

Currently there is no processor model check that selects 0x400, 0x800 or 0x8000 in _xcpm_bootstrap, but they are checked in two other routines. Being _xcpm_init_complete and _xcpm_monitor_init. The bits corresponding to 0x400, 0x800 and 0x8000 are also set in most of the programmed MSR’s (Model Specific Registers).

We know what Apple did in the past for Skylake and Kaby Lake processors, and this combined with the two new Coffee Lake CPUID’s, that makes it the third piece of evidence pointing to refreshed hardware.

Please note that Apple may choose to update certain Mac models, silently. Like they do more often. Or at a later date, but I don’t believe that Apple will skip Coffee Lake processors altogether. To me it’s the most obvious processor for the next MacBook Pro, iMac and Mac mini.

That leaves us with bit-15 (0x8000). This value can also only be used for an Intel processor with a CPUID that isn’t already supported by the XNU kernel. And since there is only one bit reserved, this could mean that it won’t be used for a combination of desktop and mobile processors. Like Skylake, Kaby Lake and Coffee Lake processors.

It is also highly unlikely that it will be used for another processor in the Xeon W serie. Leaving one processor serie that isn’t used yet. And in case you didn’t know this already. I found references to the Intel® Xeon® Scalable Processors in the leaked firmware for the iMac Pro. This processor serie uses the FCLGA3647 socket, and could be used in the new Mac Pro. That is. If Intel isn’t releasing yet another new Xeon processor serie. Anyway. For now. Two possible candidates for the new Mac Pro are:

– dual Intel® Xeon® Gold 6144 Processor (3.5GHz/4.2GHz Max Turbo, with 16 cores and 32 threads.
– dual Intel® Xeon® Gold 6146 Processor (3.2GHz/4.5GHz Max Turbo) with 24 cores and 48 threads.

Note that I used these two, specifically, because of its high base frequency and maximum turbo frequency. Next to that. There is still a thread limit. Even in High Sierra, so either that has to change – which is pretty easy for Apple to fix – or the next Mac Pro won’t support more than 24 cores (and 48 threads).

The only problem that I see right now is that the processors cost an arm and a leg, and that would limit it to a much smaller group. The so called ‘pro-users’. Or people with deep pockets. For the rest of us. Ordinary people. It’s just too expensive.

But hold on. The iMac Pro might be too expensive for some of us, but it will also be good enough for the majority of pro users, and that is probably also the main reason why we are still waiting for a new Mac Pro. I think that Apple isn’t buying the complaints of the small pro-user group.

Historically we had two possible desktop Macs that could fit the need for pro-users:

1.) Mac mini
2.) Mac Pro

But that could change to this:

1.) Mac mini
2.) iMac Pro
2.) Mac Pro

But without a new Mac mini and Mac Pro update, we’re pretty much toast…

What do you think?