If you follow aaronp613's X/Twitter, as I'm sure MacRumors editors do, you may have seen this post from him that quotes a post from Orangera1n. Said post contains a screenshot of a list of numbers that supposedly confirms Apple is working on A-series chips up to the A19 and M-series chips up to the M5. I'm the one who originally made this discovery, and I'm only posting about it now because I'm worried that MacRumors will report on this, like they do many of aaronp613's findings, without giving me credit. This is a writeup on what the pictured list is of and how it was created.
The value of the ApChipID, a 4-digit hexadecimal integer, is what this discovery is mainly concerned with. Each iteration of application processor (the main component of the SoC), as well as certain other processors, is assigned a chip ID. Here is a table of the ApChipIDs that correspond to released APs:
I had the idea to run an experiment where I would make a TSS request for an ApImg4Ticket corresponding to every possible ApChipID. I wrote a script that would make one request for each ApChipID with no letter digits, with the ApBoardID set to 0x1. If the TSS didn't return a status of 94, which it normally would if given an invalid ApChipID, it would output the ApChipID and the current time to a text file. Basically, it's brute forcing ApChipIDs to find out which ones the TSS does not consider invalid. This was the result:
I shared the script and its results on the Apple Wiki Discord server. The results you see in the post from Orangera1n that aaronp613 quoted are from Orangera1n re-running the script two months later.
Shortly after, I began making an updated version of the script that would test every ApBoardID as well as ApChipIDs with letter digits. I also created additional TSS request templates which would create requests that result in the TSS returning success for ApChipIDs between 0x8720 and 0x8955 (older APs) and an ApChipID of 0x8120 (A16). Results from this, as well as results from a script inspired by mine made by Dhinak G, show that TSS requests with ApChipID's corresponding to A11 and later SoCs (except 0x8301) will result in the TSS returning success no matter what the ApBoardID is, while others will only result in success with specific ApBoardIDs, presumably ones that correspond to devices that exist. I've been working on further updating the script to output the results to a property list instead of a text file, but I haven't yet gotten it fully working. If and when I finish it, I will share the script and the results from running it. (Side note: I originally planned to post about this whenever I finish the updated script.)
The listed ApChipID's that don't correspond to released APs cause the TSS to respond with a status of 69 (nice), rather than 94 like it normally would if the ApChipID was invalid. (Both status 69 and 94 are errors that come with the message "This device isn't eligible for the requested build", whereas the status would be 0 if the TSS returned success.) Based on patterns in which ApChipIDs correspond to which released SoCs, we can infer that these ones correspond to these unreleased SoCs:
The ApChipIDs that take the form 0x81n2 would presumably correspond to M-series chips, since 0x8112 corresponds to the M2. One would think that 0x8122 would correspond to the M3. However, I don't believe so. 0x8122 seems like it would be an M-series chip based on the A16, but I don't expect such an SoC to be released. Instead, I believe it's actually 0x8132 that corresponds to the M3, because the M3 will be based on the A17 rather than the A16 since A: the first Macs with the M3 chip are rumored to be coming in October, which is a later timeframe than the September one in which the iPhone 15 Pro is expected to release with the A17, and B: being based on the A17 would mean that the M3 is manufactured on the new 3nm process like the A17 is rumored to be.
0x6033 and 0x6034 are outliers. Based on the ApChipID increasing by one when going from M-series Max to M-series Ultra, 0x6033 would be the rumored M-series Extreme, made up of four M-series Max chiplets (in this case, an M3 Extreme based on the M3 Max), and 0x6034 could be something with even more chiplets.
In conclusion, I'm curious to see if MacRumors reports on this, and if so, how much of the technical details they skip over. Edit: They reported on it.
Background
There are a few terms that need to be defined in order to understand what these numbers mean. The first is the APTicket, which is a bit of ASN.1 encoded data that devices based on Apple silicon require to certify that the firmware files used during the boot process were made by Apple. Each APTicket is unique to:- The device's ECID (Exclusive Chip Identification), an identifier similar to a serial number that's assigned to each individual SoC.
- Nonces (numbers used once) that are randomly generated by certain processors within the device, such as the application processor (AP) and Secure Enclave processor (SEP), during every boot.
- The device's ApChipID, or CPID, and ApBoardID, or BDID, used to determine the device's model.
- The digests, or signatures, of the firmware files.
The value of the ApChipID, a 4-digit hexadecimal integer, is what this discovery is mainly concerned with. Each iteration of application processor (the main component of the SoC), as well as certain other processors, is assigned a chip ID. Here is a table of the ApChipIDs that correspond to released APs:
| ApChipID (hex) | Name | Notes |
| 0x6000 | M1 Pro | |
| 0x6001 | M1 Max | |
| 0x6002 | M1 Ultra | |
| 0x6020 | M2 Pro | |
| 0x6021 | M2 Max | |
| 0x6022 | M2 Ultra | |
| 0x7000 | A8 | |
| 0x7001 | A8X | |
| 0x7002 | S1 | |
| 0x8000 | A9 | Manufactured by Samsung. |
| 0x8001 | A9X | |
| 0x8002 | S1P, S2, T1 | |
| 0x8003 | A9 | Manufactured by TSMC. |
| 0x8004 | S3 | |
| 0x8006 | S4, S5 | |
| 0x8010 | A10 | |
| 0x8011 | A10X | |
| 0x8012 | T2 | |
| 0x8015 | A11 | |
| 0x8020 | A12 | |
| 0x8027 | A12X, A12Z | |
| 0x8030 | A13 | |
| 0x8101 | A14 | |
| 0x8103 | M1 | |
| 0x8110 | A15 | |
| 0x8112 | M2 | |
| 0x8120 | A16 | |
| 0x8301 | S6, S7, S8 | |
| 0x8720 | Found in the 2nd generation iPod touch. | |
| 0x8747 | Found in the Lightning Digital AV Adapter and Lightning to VGA Adapter. | |
| 0x8900 | Found in the original iPhone, 1st generation iPod touch, and iPhone 3G. | |
| 0x8920 | Found in the iPhone 3GS. | |
| 0x8922 | Found in the 3rd generation iPod touch. | |
| 0x8930 | A4 | |
| 0x8940 | A5 | Dual-core CPU, manufactured on the 45 nm process. |
| 0x8942 | A5 | Dual-core CPU, manufactured on the 32 nm process. |
| 0x8945 | A5X | |
| 0x8947 | A5 | Single-core CPU, manufactured on the 32 nm process. |
| 0x8950 | A6 | |
| 0x8955 | A6X | |
| 0x8960 | A7 |
The Experiment
In June, I was inspired by this 2021 tweet from nyan_satan, which lists the chip IDs that the Tatsu Auth Debug (a service whose purpose I do not yet understand that is seemingly related to the APTicket generating service of the TSS) returned success for. Then-unreleased chips whose IDs are listed include the A15 (0x8110), M1 Pro (0x6000), M1 Max (0x6001), M1 Ultra (0x6002), M2 (0x8112), H2 (0x2016), and R1 (0x6500).I had the idea to run an experiment where I would make a TSS request for an ApImg4Ticket corresponding to every possible ApChipID. I wrote a script that would make one request for each ApChipID with no letter digits, with the ApBoardID set to 0x1. If the TSS didn't return a status of 94, which it normally would if given an invalid ApChipID, it would output the ApChipID and the current time to a text file. Basically, it's brute forcing ApChipIDs to find out which ones the TSS does not consider invalid. This was the result:
Code:
[Sun Jun 18 12:36:34 EDT 2023] CPID 0x2475
[Sun Jun 18 12:54:28 EDT 2023] CPID 0x6000
[Sun Jun 18 12:54:28 EDT 2023] CPID 0x6001
[Sun Jun 18 12:54:29 EDT 2023] CPID 0x6002
[Sun Jun 18 12:54:45 EDT 2023] CPID 0x6020
[Sun Jun 18 12:54:45 EDT 2023] CPID 0x6021
[Sun Jun 18 12:54:45 EDT 2023] CPID 0x6022
[Sun Jun 18 12:54:49 EDT 2023] CPID 0x6030
[Sun Jun 18 12:54:49 EDT 2023] CPID 0x6031
[Sun Jun 18 12:54:50 EDT 2023] CPID 0x6032
[Sun Jun 18 12:54:50 EDT 2023] CPID 0x6033
[Sun Jun 18 12:54:51 EDT 2023] CPID 0x6034
[Sun Jun 18 12:54:55 EDT 2023] CPID 0x6040
[Sun Jun 18 12:54:55 EDT 2023] CPID 0x6041
[Sun Jun 18 12:54:56 EDT 2023] CPID 0x6042
[Sun Jun 18 13:11:34 EDT 2023] CPID 0x8015
[Sun Jun 18 13:11:35 EDT 2023] CPID 0x8020
[Sun Jun 18 13:11:38 EDT 2023] CPID 0x8027
[Sun Jun 18 13:11:40 EDT 2023] CPID 0x8030
[Sun Jun 18 13:12:06 EDT 2023] CPID 0x8101
[Sun Jun 18 13:12:06 EDT 2023] CPID 0x8103
[Sun Jun 18 13:12:08 EDT 2023] CPID 0x8110
[Sun Jun 18 13:12:09 EDT 2023] CPID 0x8112
[Sun Jun 18 13:12:11 EDT 2023] CPID 0x8120
[Sun Jun 18 13:12:12 EDT 2023] CPID 0x8122
[Sun Jun 18 13:12:14 EDT 2023] CPID 0x8130
[Sun Jun 18 13:12:15 EDT 2023] CPID 0x8132
[Sun Jun 18 13:12:19 EDT 2023] CPID 0x8140
[Sun Jun 18 13:12:19 EDT 2023] CPID 0x8142Shortly after, I began making an updated version of the script that would test every ApBoardID as well as ApChipIDs with letter digits. I also created additional TSS request templates which would create requests that result in the TSS returning success for ApChipIDs between 0x8720 and 0x8955 (older APs) and an ApChipID of 0x8120 (A16). Results from this, as well as results from a script inspired by mine made by Dhinak G, show that TSS requests with ApChipID's corresponding to A11 and later SoCs (except 0x8301) will result in the TSS returning success no matter what the ApBoardID is, while others will only result in success with specific ApBoardIDs, presumably ones that correspond to devices that exist. I've been working on further updating the script to output the results to a property list instead of a text file, but I haven't yet gotten it fully working. If and when I finish it, I will share the script and the results from running it. (Side note: I originally planned to post about this whenever I finish the updated script.)
Theories
Now for some theorizing as to which unreleased SoCs have their existences hinted at by the results of this experiment. I'll only be looking over the ones that my original script outputs. I'm also going to skip over the ApChipID of 0x2475, as I believe its appearance in my original list may have been an anomaly since it didn't appear in the list Orangera1n got.The listed ApChipID's that don't correspond to released APs cause the TSS to respond with a status of 69 (nice), rather than 94 like it normally would if the ApChipID was invalid. (Both status 69 and 94 are errors that come with the message "This device isn't eligible for the requested build", whereas the status would be 0 if the TSS returned success.) Based on patterns in which ApChipIDs correspond to which released SoCs, we can infer that these ones correspond to these unreleased SoCs:
| ApChipID (hex) | Possible name |
| 0x6030 | M3 Pro |
| 0x6031 | M3 Max |
| 0x6032 | M3 Ultra |
| 0x6040 | M4 Pro |
| 0x6041 | M4 Max |
| 0x6042 | M4 Ultra |
| 0x6050 | M5 Pro |
| 0x6051 | M5 Max |
| 0x6052 | M5 Ultra |
| 0x8130 | A17 |
| 0x8140 | A18 |
| 0x8150 | A19 |
The ApChipIDs that take the form 0x81n2 would presumably correspond to M-series chips, since 0x8112 corresponds to the M2. One would think that 0x8122 would correspond to the M3. However, I don't believe so. 0x8122 seems like it would be an M-series chip based on the A16, but I don't expect such an SoC to be released. Instead, I believe it's actually 0x8132 that corresponds to the M3, because the M3 will be based on the A17 rather than the A16 since A: the first Macs with the M3 chip are rumored to be coming in October, which is a later timeframe than the September one in which the iPhone 15 Pro is expected to release with the A17, and B: being based on the A17 would mean that the M3 is manufactured on the new 3nm process like the A17 is rumored to be.
0x6033 and 0x6034 are outliers. Based on the ApChipID increasing by one when going from M-series Max to M-series Ultra, 0x6033 would be the rumored M-series Extreme, made up of four M-series Max chiplets (in this case, an M3 Extreme based on the M3 Max), and 0x6034 could be something with even more chiplets.
Last edited:
