HomePod detection located in High Sierra…

Ok. This is news to me. So the “AudioAccessory” and “HomePod” are not the same things? That is. Not for IMFoundation.framework:

#define NSNotFound    NSIntegerMax

void * +[IMDeviceSupport marketingNameForModel:](void * self, void * _cmd, void * arg2) {
    r15 = arg2;
    if ([r15 rangeOfString:@"iPod"] == NSNotFound) {
            rbx = @"iPad";
            if ([r15 rangeOfString:rbx] == NSNotFound) {
                    rbx = @"iPhone";
                    if ([r15 rangeOfString:rbx] == NSNotFound) {
                            rbx = @"Mac";
                            if ([r15 rangeOfString:rbx] == NSNotFound) {
                                    if ([r15 rangeOfString:@"AppleTV"] == NSNotFound) {
                                            if ([r15 rangeOfString:@"Watch"] == NSNotFound) {
                                                    rbx = @"HomePod";
                                                    if ([r15 rangeOfString:@"AudioAccessory"] == NSNotFound) {
                                                            rbx = @"Mac";
                                                    }
                                            }
                                            else {
                                                    rbx = @"Apple Watch";
                                            }
                                    }
                                    else {
                                            rbx = @"Apple TV";
                                    }
                            }
                    }
            }
    }
    else {
            rbx = @"iPod touch";
    }
    rax = rbx;
    return rax;
}

So basically what happens here is that if it finds an “AudioAccessory” (as product/model identifier) then it returns “HomePod”. So that we, the users, know what it is. Fine. Not a big deal.

The string “HomePod” can also be found in Sharing.framework

Time to get some food. I’m hungry…

Edit: Right. Someone spotted an error – see comments. Fixed. Thank you. Back to my food now.

Cool. I also found some interesting strings. I think that this is for a (future) HomePod setup app on Mac’s.

	<key>MY_HOME</key>
	<string>My Home</string>

	<key>ROOM_BATHROOM</key>
	<string>Bathroom</string>
	<key>ROOM_BEDROOM</key>
	<string>Bedroom</string>
	<key>ROOM_DEFAULT</key>
	<string>Default Room</string>
	<key>ROOM_DINING_ROOM</key>
	<string>Dining Room</string>
	<key>ROOM_GARAGE</key>
	<string>Garage</string>
	<key>ROOM_HALLWAY</key>
	<string>Hallway</string>
	<key>ROOM_KITCHEN</key>
	<string>Kitchen</string>
	<key>ROOM_LIVING_ROOM</key>
	<string>Living Room</string>
	<key>ROOM_MASTER_BEDROOM</key>
	<string>Master Bedroom</string>
	<key>ROOM_OFFICE</key>
	<string>Office</string>
	<key>ROOM_PATIO</key>
	<string>Patio</string>

I can’t remember it, but haven’t we seen this before? For the AppleTV maybe?

Scripts to install High Sierra DP7 (17A352a)…

We have a new handy script (install_1013_DP7_17A352a.sh) to install macOS High Sierra Beta DP-7.

The installer.pkg created by the script will simulate the App Store download and installation method, and all you have to do is:

1.) Run install_1013_DP7_17A352a.sh
2.) Run /Applications/Install macOS High Sierra Beta.app
3.) Reboot

Notes: I have yet to try the scripts myself – I cannot download the files right now (we’re still at sea). Also. You may want to run checkAPFSSettings.sh in single-user mode.

Please note that the App Store.app downloads files to: /Library/Updates but this script will use: /tmp/091-28482 and the downloaded files will be gone after a reboot, so you may want to make a backup of the files!

Note: The preferred way of installing / upgrading High Sierra (DP-7) on a Mac is to use the App Store !!!

Thanks!

Apple to cleanup a BIOS region of your AMI or Phoenix (PC) BIOS…

Ok. So you use Clover with an AMI or Phoenix BIOS. Well. In that case you may be interested in this:
Image of AM and Phoenix BIOS cleanup code
LOL Why would Apple do this? Because you and your hack are such good friends?

Oh yeah. I should add that this can be found in: /usr/libexec/firmwarecheckers/eficheck

usage: eficheck: [ --save -b  ]
                 [ --cleanup -b  ]
                 [ --generate-hashes [ -b  ] [ -p  ] ]
                 [ --integrity-check [ -h  [ -b  ] ] ]
                 [ --show-hashes [ -h  ] | [ -b  ] ]

	Examples:
	  'eficheck --save -b firmware.bin'
		 Save this system's EFI firmware as firmware.bin
	  'eficheck --cleanup -b firmware.bin'
		 Overwrite the EFI variables portion of the firmware, enabling the file to be shared for analysis
	  'eficheck --generate-hashes'
		 Analyze the current system's installed EFI firmware, and store the hashes into hash file(s) in current folder
		 File name(s) will be selected according to image's EFI version(s)
	  'eficheck --generate-hashes -b firmware.bin'
		 Analyze the firmware.bin, and store the hashes into hash file(s) in current folder
	  'eficheck --generate-hashes -p /usr/local/allowlists'
		 Analyze the current system's installed EFI firmware, and store the hashes into hash file(s) in /usr/local/allowlists folder
	  'eficheck --integrity-check'
		 Attempt to automatically determine which firmware you are running, and integrity check against the appropriate file, and report any differences
	  'eficheck --integrity-check -h /usr/libexec/firmwarecheckers/eficheck/EFIAllowListShipping.bundle/allowlists/IM171.88Z.0105.B08.1604111319.0.ealf'
		 Compare the current system's EFI firmware against the Apple-provided expected measurements for an "iMac17,1" at firmware revision B08, and report any differences
	  'eficheck --integrity-check -h hash.ealf -b firmware.bin'
		 Compare the given hash file against against the given firmware image and report any differences
	  'eficheck --show-hashes'
		 Print the hashes for the current system's installed EFI firmware to stdout
	  'eficheck --show-hashes -b firmware.bin'
		 Print the hashes for the given firmware.bin to stdout
	  'eficheck --show-hashes -h allowlist.ealf'
		 Print the hashes for the given allowlist.ealf to stdout

Data is downloaded from: https://validation.isu.apple.com and the initial package (EFIAllowListAll.pkg) can be downloaded here. There’s also EFIAllowListInternal.pkg for Apple engineers, but that is not a public download.

_IsInternalOsBuild calls csr_check(CSR_ALLOW_APPLE_INTERNAL) to differentiate between public and internal OS builds.

It works with /System/Library/Extensions/eficheck.kext which matches via PCI device-id’s with one of the Intel LPC Controller/eSPI Controllers in this list:

				<string>pci8086,1c41</string>
				<string>pci8086,1c42</string>
				<string>pci8086,1c43</string>
				<string>pci8086,1c44</string>
				<string>pci8086,1c46</string>
				<string>pci8086,1c47</string>
				<string>pci8086,1c49</string>
				<string>pci8086,1c4a</string>
				<string>pci8086,1c4b</string>
				<string>pci8086,1c4c</string>
				<string>pci8086,1c4d</string>
				<string>pci8086,1c4e</string>
				<string>pci8086,1c4f</string>
				<string>pci8086,1c50</string>
				<string>pci8086,1c52</string>
				<string>pci8086,1c5c</string>
				<string>pci8086,1d41</string>
				<string>pci8086,1e42</string>
				<string>pci8086,1e44</string>
				<string>pci8086,1e46</string>
				<string>pci8086,1e47</string>
				<string>pci8086,1e48</string>
				<string>pci8086,1e49</string>
				<string>pci8086,1e4a</string>
				<string>pci8086,1e53</string>
				<string>pci8086,1e55</string>
				<string>pci8086,1e56</string>
				<string>pci8086,1e57</string>
				<string>pci8086,1e58</string>
				<string>pci8086,1e59</string>
				<string>pci8086,1e5d</string>
				<string>pci8086,1e5e</string>
				<string>pci8086,1e5f</string>
				<string>pci8086,3b02</string>
				<string>pci8086,3b03</string>
				<string>pci8086,3b06</string>
				<string>pci8086,3b07</string>
				<string>pci8086,3b08</string>
				<string>pci8086,3b09</string>
				<string>pci8086,3b0a</string>
				<string>pci8086,3b0b</string>
				<string>pci8086,3b0f</string>
				<string>pci8086,3b12</string>
				<string>pci8086,3b14</string>
				<string>pci8086,3b16</string>
				<string>pci8086,8c44</string>
				<string>pci8086,8c4b</string>
				<string>pci8086,8cc1</string>
				<string>pci8086,8cc2</string>
				<string>pci8086,8cc3</string>
				<string>pci8086,8cc4</string>
				<string>pci8086,8cc6</string>
				<string>pci8086,8c41</string>
				<string>pci8086,8c42</string>
				<string>pci8086,8c44</string>
				<string>pci8086,8c46</string>
				<string>pci8086,8c49</string>
				<string>pci8086,8c4a</string>
				<string>pci8086,8c4b</string>
				<string>pci8086,8c4c</string>
				<string>pci8086,8c4e</string>
				<string>pci8086,8c4f</string>
				<string>pci8086,8c50</string>
				<string>pci8086,8c52</string>
				<string>pci8086,8c54</string>
				<string>pci8086,8c56</string>
				<string>pci8086,8c5c</string>
				<string>pci8086,8d44</string>
				<string>pci8086,8d47</string>
				<string>pci8086,9cc1</string>
				<string>pci8086,9cc2</string>
				<string>pci8086,9cc3</string>
				<string>pci8086,9cc5</string>
				<string>pci8086,9cc6</string>
				<string>pci8086,9cc7</string>
				<string>pci8086,9cc9</string>
				<string>pci8086,9c41</string>
				<string>pci8086,9c43</string>
				<string>pci8086,9c45</string>
				<string>pci8086,9d41</string>
				<string>pci8086,9d43</string>
				<string>pci8086,9d46</string>
				<string>pci8086,9d48</string>
				<string>pci8086,9d4b</string>
				<string>pci8086,9d4e</string>
				<string>pci8086,a145</string>
				<string>pci8086,a151</string>

So what is this? What does it mean?

Well. Apple is likely using eficheck as an extra layer of security. To verify your EFI ROM checksum against the original one in a EFI ROM database, with the checksum of files that were produced by Apple. Or that you are using some modified copy of their EFI ROM firmware. This may mean that your EFI ROM is either broken or otherwise altered. And then it gets invalidated. So far it sounds good, but what about wiping a BIOS region in a PC BIOS (dump)? Why would Apple want your PC BIOS dump? Sorry but I don’t understand that. Why? Maybe someone else can help me here.

Edit: someone e-mailed me and said that a possible reason could be that Apple wants to know how many people are using a hack. That is possible, but I don’t think so. I’m sure that Apple has all the data they need. Likely for years already.

Update: Don’t you worry. Apple is not going to brick your PC. Apple will never do something like that. This was also not the whole point of this writeup. No. It’s more about the technical aspects and implementation of eficheck and eficheck.kext and what it does. I was just curious. As always.

Also. There appears to be this dialog:
Image of the eficheck dialog
Honestly. I personally had never seen it, but there you have it. Thanks to @stroughtonsmith. Anyway. Just don’t click “Send to Apple” on a hack. Or wait. Let’s just click that button and wait and see if the ROM’s checksum shows up in a next update – this may as well be a fully automated process, like Apple used to add unsigned kexts to OSKextExcludeList (think AppleKextExcludeList.kext).

But seriously. Does eficheck --integrity-check even work with a Clover setup? What is the console output that you get when you run it? And in case that works for you, then my next question would be; Is your personal/identifiable data really removed?

There is one other thing that I’d like to figure out, and that is why Apple reads the PlatformUUID. That should not be required. Not ever.

Xeon Microcode Located In iMac Pro Firmware…

Ok. I said to check the Intel microcode that Apple used in the “accidentally” released firmware for the iMac Pro and here it is;
Snippet of Intel microcode of the iMac Pro
The above image shows you the header of the Intel microcode that I located in the firmware file of the iMac Pro. The data in the red box is the CPUID.

Right. You need to know how to read it, but that 52 06 05 00 is CPUID 0x050652 of the Intel Xeon processor (B-0 stepping) in the iMac Pro.

This CPUID – and the one for the H-0 stepping – can be found in the Intel® Xeon® Processor Scalable Family datasheet (see: xeon-scalable-spec-update.pdf).

Edit: I checked the processor flags in the header (97 00 00 00) and that is exactly the same as what you see on X299 platforms. You can check this with:

sysctl -xn machdep.cpu.processor_flag

With a Skylake processor with CPU signature 0x000506e3 that is 0x00000001. You can check this with:

sysctl -xn machdep.cpu.signature

But perhaps it is better to use the latest version of AppleIntelInfo.kext (v2.7) since it logs all bits from MSR_IA32_PLATFORM_ID/0x17. Or some other tool that can dump the output of MSR_IA32_PLATFORM_ID.

iMac Pro Xeon Processor…

Aha. This is cool. Thanks to Intel lifting a lid in their documentation for developers. The iMac Pro comes with the Intel® Xeon® Processor Scalable Family, based on Skylake microarchitecture. Which is confusing the crap out of me.

The CPUID checks (0x5065X) for it are already there in High Sierra!!!

The Developer Previews of High Sierra supports both Skylake X and new Xeon models!

Apple can use processors from the Scalable Family for a new Mac Pro, without having to change anything in the xcpm_bootstrap and cpuid_set_info routines!

This particular piece of XNU code has changed for High Sierra:

static uint32_t
cpuid_set_cpufamily(i386_cpu_info_t *info_p)
{
	uint32_t cpufamily = CPUFAMILY_UNKNOWN;

	switch (info_p->cpuid_family) {
	case 6:
		switch (info_p->cpuid_model) {
		case 23:
			cpufamily = CPUFAMILY_INTEL_PENRYN;
			break;
		case CPUID_MODEL_NEHALEM:
		case CPUID_MODEL_FIELDS:
		case CPUID_MODEL_DALES:
		case CPUID_MODEL_NEHALEM_EX:
			cpufamily = CPUFAMILY_INTEL_NEHALEM;
			break;
		case CPUID_MODEL_DALES_32NM:
		case CPUID_MODEL_WESTMERE:
		case CPUID_MODEL_WESTMERE_EX:
			cpufamily = CPUFAMILY_INTEL_WESTMERE;
			break;
		case CPUID_MODEL_SANDYBRIDGE:
		case CPUID_MODEL_JAKETOWN:
			cpufamily = CPUFAMILY_INTEL_SANDYBRIDGE;
			break;
		case CPUID_MODEL_IVYBRIDGE:
		case CPUID_MODEL_IVYBRIDGE_EP:
			cpufamily = CPUFAMILY_INTEL_IVYBRIDGE;
			break;
		case CPUID_MODEL_HASWELL:
		case CPUID_MODEL_HASWELL_EP:
		case CPUID_MODEL_HASWELL_ULT:
		case CPUID_MODEL_CRYSTALWELL:
			cpufamily = CPUFAMILY_INTEL_HASWELL;
			break;
		case CPUID_MODEL_BROADWELL:
		case CPUID_MODEL_BRYSTALWELL:
			cpufamily = CPUFAMILY_INTEL_BROADWELL;
			break;
		case CPUID_MODEL_SKYLAKE:
		case CPUID_MODEL_SKYLAKE_DT:
		case CPUID_MODEL_SKYLAKE_X:
			cpufamily = CPUFAMILY_INTEL_SKYLAKE;
			break;
		case CPUID_MODEL_KABYLAKE:
		case CPUID_MODEL_KABYLAKE_DT:
			cpufamily = CPUFAMILY_INTEL_KABYLAKE;
			break;
		}
		break;
	}

	info_p->cpuid_cpufamily = cpufamily;
	DBG("cpuid_set_cpufamily(%p) returning 0x%x\n", info_p, cpufamily);
	return cpufamily;
}

In the currently available source code (for Sierra 10.12.4) the lines for Kabylake are missing, as well, of course, for the line to support the new Skylake processors.

There are currently no CPUID checks (0x5067X) for the Intel® Xeon PhiTM Processor 3200, 5200, 7200 Series in High Sierra, but then again, that may change with a future update!

Warning: My assumption here is that the xcpm_bootstrap and cpuid_set_info routines in the XNU source code for High Sierra aren’t going to change anymore, since the iMac Pro (iMac19,1) is already being used with High Sierra (websites can confirm this by checking their logs) but we still don’t know for sure what Apple will use in the iMac Pro.

Ok. So the CPUID checks are there, and there is (still) no Apple hardware with a Skylake X processor, but the iMac Pro won’t be available before December 2017 so anything can happen. Please keep that in mind!

Edit: For people wondering about what CPUID’s are, here are a few example:

0x506E3 Skylake Desktop
0x50650 Skylake-X
0x50652 Skylake Xeon (stepping B-0)
0x50654 Skylake Xeon (stepping H-0)
0x6066X Cannonlake
0x706EX IceLake

This number is used to identify the processor family, model and stepping. In CPU-Z you would see this next to “Ext. Model”:

5E
55
55
55
66
7E

In the same order as the numbers above.

Scripts to install/upgrade to High Sierra DP6 (17A344b)…

I wrote a new handy script (install_1013_DP6_17A344b.sh) to install macOS High Sierra Beta DP-6 and (update_1013_DP6_17A344b.sh) to upgrade your copy of High Sierra DP5 to DP6.

The installer.pkg created by the script will simulate the App Store download and installation method, and all you have to do is:

1.) Run install_1013_DP6_17A344b.sh
2.) Run /Applications/Install macOS High Sierra Beta.app
3.) Reboot

Notes: I have yet to try the scripts myself – I cannot download the files right now (we’re still at sea). Also. You may want to run checkAPFSSettings.sh in single-user mode.

Please note that the App Store.app downloads files to: /Library/Updates but the script uses either: /tmp/091-28081 or /tmp-28062 and all the downloaded files will be gone after a reboot and thus you may want to make a backup of the files!

Thanks!

Tip: If you are getting this error

installer: The upgrade failed (The Installer could not install the software because there was no software found to install.)

Then rm /tmp/091-2806[1/2]/installer.pkg and run the script again. This should output

Creating installer.pkg ...
productbuild: Wrote product to installer.pkg
Running installer ...
installer: Package name is Install macOS High Sierra Beta
installer: Upgrading at base path /Volumes/HS
installer: The upgrade was successful.
Copying: InstallESDDmg.pkg to the target location ...
Copying: AppleDiagnostics.dmg to the target location ...
Copying: AppleDiagnostics.chunklist to the target location ...
Copying: BaseSystem.dmg to the target location ...
Copying: BaseSystem.chunklist to the target location ...

But you should not see something like:

productbuild: warning: package /tmp/091-28061/InstallAssistantAuto.pkg could not be loaded
productbuild: warning: package /tmp/091-28061/RecoveryHDMetaDmg.pkg could not be loaded

In case you happen to run into this error, then simply remove the broken packages and run the script again.

Update: I finally had fast enough WiFi to run the script myself, and everything went fine. I only updated the SMBIOS data for the iMac Pro and changed the firmware features.