Intel_Hades_AR_HR_4C_C0_rev33_W_TI_20180109_SEC1_sign.binindicates that the firmware is signed. I can confirm that the name is not a lie, because any modification of the file will result in the firmware update failing. Even if you force the firmware to be flashed via an external flasher, the next boot will see the controller in "safe mode" and it will refuse to enumerate any PCIe device unless the firmware is updated. At offset
0x39010is an RSA public key and at offset
0x3A010is a signature. Both the public key and the signature are stored in raw little endian bytes. After converting it to big endian, the signature decrypts successfully with the public key and it is a PKCS#1 encoded signature.
pkgutil --expand-full, we can dump the package and we find
Script/Tools/USBCUpdaterwhere there is a sub-directory for each Mac's board id along with
ThorUtil.efi, the firmware update utility. No, it's not a secret EFI malware no matter what the FBI says.
Mac-BE088AF8C5EB4FA2is a good choice because it has the same Alpine Ridge controller and the system itself is also Kabylake.
Mac-BE088AF8C5EB4FA2-C0_5.56.0-C0_33.1.binfrom the 10.14 installer has the closest firmware version to the v33 one from Intel.
TPS65983 HW FW0005.56.00 ZACE2D3while the NUC's firmware has the string
TPS65982 HW FW0001.12.06 ZTBT1. They are different hardware!
0x3B010. This is where the TI firmware resides in the NUC's binary. The TI firmware is at
0x6A000in the Mac's binary. Note that TI's firmware update manual says that at offset
0xFFC, there is a pointer to the start of the firmware and this matches up.
0x0, we find a pointer to the start of the firmware at
0x4000. However, after flashing it through the updater and dumping the SPI, we see that
0xFFFFFFFFsometimes gets written to
0x4000is written to
0x1000. It appears that the notion of an active/inactive region from the TI manual applies to the Alpine Ridge as well. We can deduce that the update process will load the image to the inactive region, then swap the pointers if validation succeeds.