The iPhone Wiki is no longer updated. Visit this article on The Apple Wiki for current information. |
Difference between revisions of "T8012"
Line 147: | Line 147: | ||
=== Identifying the T2 from DFU === |
=== Identifying the T2 from DFU === |
||
− | Once a device is in DFU enumerating the USB device yields the BoardID. Using either Linux's `lsusb -v` or macOS's `ioreg -p IOUSB` the USB serial attribute will contain the same information as any other Apple A core iBoot device. (http://newosxbook.com/bonus/iBoot.pdf). The ChipID will always be 8012. The value for BDID is the BoardID. Full decoding of the version string can be performed using the code at https://github.com/das-iboot/das-iboot/blob/master/das_iboot/device.py |
+ | Once a device is in DFU enumerating the USB device yields the BoardID. Using either Linux's `lsusb -v` or macOS's `ioreg -p IOUSB` the USB serial attribute will contain the same information as any other Apple A core iBoot device. (http://newosxbook.com/bonus/iBoot.pdf). The ChipID will always be 8012. The value for BDID is the BoardID. Full decoding of the version string can be performed using the code at https://github.com/das-iboot/das-iboot/blob/master/das_iboot/device.py. These values for BDID, CPID, CPRV and ECID are in Hex. |
+ | |||
+ | |||
+ | === Identifying the T2 from macOS === |
||
+ | |||
+ | This will provide many of the same values as DFU but in Decimal instead of Hex like above: |
||
+ | |||
+ | <code> |
||
+ | # ECID in decimal instead of Hex |
||
+ | /usr/libexec/remotectl get-property localbridge UniqueChipID |
||
+ | # Chip ID CPID in decimal (32786 == 0x8012) |
||
+ | /usr/libexec/remotectl get-property localbridge ChipID |
||
+ | # Board Revision CPRV |
||
+ | /usr/libexec/remotectl get-property localbridge BoardRevision |
||
+ | # Board ID (BDID) |
||
+ | /usr/libexec/remotectl get-property localbridge BoardId |
||
+ | # Hardware Model is the name of the Board |
||
+ | /usr/libexec/remotectl get-property localbridge HWModel |
||
+ | </code> |
||
Revision as of 05:08, 13 August 2020
T8012, also just known as the T2 is the CPU introduced in the second-generation iBridge processor, the processor found on the iMac Pro, and used on all subsequent T2 enabled Mac products.
Contents
Enabled Mac Products
Devices sourced from [1]
iBridge Product ID | Board ID | Board Minor | Description (Product ID) | checkm8 confirmed |
---|---|---|---|---|
iBridge2,1 | J137AP | 0x0A | Apple T2 iMacPro1,1 (j137) | yes |
iBridge2,3 | J680AP | 0x0B | Apple T2 MacBookPro15,1 (j680) | yes |
iBridge2,4 | J132AP | 0x0C | Apple T2 MacBookPro15,2 (j132) | yes |
iBridge2,5 | J174AP | 0x0E | Apple T2 Macmini8,1 (j174) | yes |
iBridge2,6 | J160AP | 0x0F | Apple T2 MacPro7,1 (j160) | yes |
iBridge2,7 | J780AP | 0x07 | Apple T2 MacBookPro15,3 (j780) | yes |
iBridge2,8 | J140kAP | 0x17 | Apple T2 MacBookAir8,1 (j140k) | yes |
iBridge2,10 | J213AP | 0x18 | Apple T2 MacBookPro15,4 (j213) | yes |
iBridge2,11 | J230AP | 0x1F | ? | ? |
iBridge2,12 | J140aAP | 0x37 | Apple T2 MacBookAir8,2 (j140a) | yes |
iBridge2,13 | J214AP | 0x1E | ? | ? |
iBridge2,14 | J152fAP | 0x3A | Apple T2 MacBookPro16,1 (j152f) | yes |
iBridge2,15 | J230kAP | 0x3F | Apple T2 MacBookAir9,1 (j223k) | yes |
iBridge2,16 | J214kAP | 0x3E | ? | ? |
iBridge2,21 | J223AP | 0x3B | ? | ? |
iBridge2,22 | J215AP | 0x38 | ? | ? |
T2 Recovery USB Device ID
During the restore process, the T2 presents as a Restore Mode com.apple.recoveryd
service, but uses the USB product ID of 0x8086
instead of the iPhone's 0x1290-0x12AF
.[2]
Bootrom Exploits
The T8012 uses Bootrom version Bootrom_3401.0.0.1.16 which is vulnerable to checkm8. A fork of checkm8 with support for the t2 exists at h0m3us3r. The adaption of checkm8 was performed by the t8012 checkm8 group by brute forcing the various locations from ROM. The copyright string reads SecureROM for t8012si, Copyright 2007-2016, Apple Inc
, for version Bootrom_3401.0.0.1.16.
axi0mX T2 support tweet quertyoruiop's early checkra1n previews
Similar to iPhones, iPads, and iPods, iBridge firmware bundles come in IPSW form. Build train codenames are appended with "HWBridge" to distinguish them from normal firmwares, and the disk image files inside have labels that are appended with "UniversalBridgeOS." They can only be restored to if the Mac is in DFU mode.
The T2 SEP
The T2 Secure Enclave is vulnerable to the same exploit Pangu presented at MOSEC named `blackbird`.
Entering DFU Mode
The T2 models can be restored via a Thunderbolt cable using Apple Configurator 2.
Desktop Macs
For example, iMac Pro and Mac mini models from 2018 or later.[1]
- Completely power off the Mac; disconnect it from external power.
- Attach one end of a Thunderbolt cable to the correct Thunderbolt port on the Mac.
- iMac Pro: The Thunderbolt port that is located next to the Ethernet port.
- Mac mini: The Thunderbolt port that is located next to the HDMI port.
- Connect the other end to any Thunderbolt or USB port on the host Mac (the device which will be used for restoring).
- Hold down the power button on the back of the Mac for 3 seconds, while connecting the power cord.
Portable Macs
For example, MacBook models from 2018 or later.[2]
- Completely power off the Mac; disconnect it from external power.
- Attach one end of a Thunderbolt cable to the Thunderbolt port that is located on the left side, closest to the front.
- Connect the other end to any Thunderbolt or USB port on the host Mac (the device which will be used for restoring).
- Hold down the power button, right Shift key, and left Control and Option keys, for 3 seconds.
Identifying the T2 from DFU
Once a device is in DFU enumerating the USB device yields the BoardID. Using either Linux's `lsusb -v` or macOS's `ioreg -p IOUSB` the USB serial attribute will contain the same information as any other Apple A core iBoot device. (http://newosxbook.com/bonus/iBoot.pdf). The ChipID will always be 8012. The value for BDID is the BoardID. Full decoding of the version string can be performed using the code at https://github.com/das-iboot/das-iboot/blob/master/das_iboot/device.py. These values for BDID, CPID, CPRV and ECID are in Hex.
Identifying the T2 from macOS
This will provide many of the same values as DFU but in Decimal instead of Hex like above:
- ECID in decimal instead of Hex
/usr/libexec/remotectl get-property localbridge UniqueChipID
- Chip ID CPID in decimal (32786 == 0x8012)
/usr/libexec/remotectl get-property localbridge ChipID
- Board Revision CPRV
/usr/libexec/remotectl get-property localbridge BoardRevision
- Board ID (BDID)
/usr/libexec/remotectl get-property localbridge BoardId
- Hardware Model is the name of the Board
/usr/libexec/remotectl get-property localbridge HWModel
Mac Configuration Utility
In order to restore a firmware to an iBridge device, technicians must use two Apple Internal tools. The first one, Apple Service Toolkit (AST), is used to initiate a diagnostic session between the host Mac and the Mac in DFU mode. The second tool, which must be installed on the host Mac, is known as the Mac Configuration Utility (MCU). It communicates with AST to provide board information and initiate restores and diagnostics over-the-air. MCU supports macOS 10.13.2 or later.
iBridge devices can still be managed if there is no firmware present by booting a diagnostic image, which is pushed to the device by MCU after a Blank Board Serializer test is initiated on AST. This test will also assign a serial number to a new board.
During a restore, an Apple logo and progress bar will show on the screen, similar to that of a normal device restore. It is unknown if iBridge firmwares are signed, or if they are verified by the host or by iBridge devices.