|
The iPhone Wiki is no longer updated. Visit this article on The Apple Wiki for current information. |
Difference between revisions of "APTicket"
Staycool72 (talk | contribs) m (→Downgrading) |
m |
||
| (8 intermediate revisions by 5 users not shown) | |||
| Line 1: | Line 1: | ||
| − | APTickets are the new type of [[SHSH|SHSH blobs]], used by iOS 5.0 and newer. The client (iBSS/LLB/iBoot) generates a random string (nonce), then iTunes and the device sends the request for blob signing and the server returns the data, just like the original [[SHSH Protocol|SHSH protocol]]. |
+ | '''APTickets''' (short for '''Application Processor Ticket'''<ref>[https://opensource.apple.com/source/CommonCrypto/CommonCrypto-60027/Source/libDER/Tests/DER_Ticket.c DER_Ticket.c (libDER) at Apple Open Source]</ref>) are the new type of [[SHSH|SHSH blobs]], used by iOS 5.0 and newer. The client (iBSS/LLB/iBoot/BootROM) generates a random string (nonce), then iTunes and the device sends the request for blob signing and the server returns the data, just like the original [[SHSH Protocol|SHSH protocol]]. |
==Restoring== |
==Restoring== |
||
| Line 5: | Line 5: | ||
==Downgrading== |
==Downgrading== |
||
| − | Saurik's original replay attack method of allowing downgrades for any firmware that had been backed up on his server was partially halted for iOS 5 users due to this new system; now it will back up APTickets, but it can't send it directly from his servers; [[Redsn0w]] and [[iFaith]] can stitch a stock or custom firmware to enable downgrading with APTicket, but it only works for devices vulnerable to [[Limera1n Exploit]]. |
+ | Saurik's original replay attack method of allowing downgrades for any [[firmware]] that had been backed up on his server was partially halted for [[iOS]] 5 users due to this new system; now it will back up APTickets, but it can't send it directly from his servers; [[Redsn0w]] and [[iFaith]] can stitch a stock or custom firmware to enable downgrading with APTicket, but it only works for devices vulnerable to [[Limera1n Exploit]]. |
Faking APTickets is complicated because they are signed with a private key that only Apple knows and they are also partly generated from a random string (nonce). |
Faking APTickets is complicated because they are signed with a private key that only Apple knows and they are also partly generated from a random string (nonce). |
||
| − | iOS 4.3.5 and older can still be downgraded if SHSH blobs were saved. |
+ | [[iOS]] 4.3.5 and older can still be downgraded if [[SHSH]] blobs were saved. |
| − | iPad 2 users with iOS 4.3.x SHSH blobs can upload their 4.3.x iBSS via DFU and jump to iOS 5's iBEC. At this point, a signed IPSW can be used to restore to cached iOS 5 blobs. (This method is very effective on WiFi-only models. 3G models require the baseband to be installed/signed... Something like semaphore's TinyCFW can be implemented to get around this). |
+ | [[iPad 2]] users with iOS 4.3.x [[SHSH]] blobs can upload their 4.3.x iBSS via DFU and jump to [[iOS]] 5's iBEC. At this point, a signed [[IPSW]] can be used to restore to cached iOS 5 blobs. (This method is very effective on WiFi-only models. 3G models require the baseband to be installed/signed... Something like semaphore's TinyCFW can be implemented to get around this). |
| − | A vulnerability found independently by [[iH8sn0w]] and the [[iPhone |
+ | A vulnerability found independently by [[iH8sn0w]] and the [[iPhone Dev Team]] allowed downgrading all [[A5]] devices running 5.x with their saved APTickets by restoring the latest [[firmware]]- verifying APTicket with the [[iBSS]] or [[iBoot]] then restoring the hacked [[firmware]] without APTicket- then when the restore ends, the requisite firmware is restored. This method theoretically works with BBTickets, but such a [[baseband]] downgrade was never out. |
| + | |||
| + | A bug existing in several 32-bit versions of iOS, though only exploitable in iOS 9.x, allows users to downgrade using cached iBSS/LLB blobs and APTicket, provided that the APTicket does not contain a nonce. A missing nonce is not treated as a mismatch, allowing the restore to continue and effectively defeating the improved downgrade prevention introduced by APTickets. The first public tool that exploited the bug was [[iDeviceReRestore]] (released on {{date|2017|04|02}}), which, unlike Odysseus, does not require the device to be jailbroken. This brought a way to restore 32-bit devices to jailbreakable firmware, devices that had not seen a jailbreak for signed firmware since the release of Pangu9 for iOS 9.0.x more than 17 months earlier. The method was later incorporated into futurerestore. |
||
| + | |||
| + | ==APTicket structure== |
||
| + | APTicket is a piece DER encoded data. The format of the data is different for 32-bit and 64-bit devices, but these formats have something in common. Each APTicket has a header, signed DER encoded SET, which contains hashes of all signed images and some additional data, PKCS#1 signature and two certificates. The first certificate is an Apple Secure Boot Certificate and the second one is specific for each TSS server and device CPU. |
||
| + | |||
| + | ===Old APTicket format=== |
||
| + | Old APTickets begin with a SEQUENCE which contains a signature type. This signature type shall match one in the first certificate. Next comes a SET with ECID, chip ID, board ID, SHA1 hashes of all signed images and some boolean values indicating true. Seems like tag of each element in the SET describes it's meaning. Old APTickets end with a signature and two certificates. |
||
| + | |||
| + | ===IM4M APTicket/ApImg4Ticket format=== |
||
| + | These begin with an IA5String "IM4M" and an INTEGER which is likely a version number. SET in these APTickets contains data structures of similar format. Each structure is of constructed type with PRIVATE class and contains a SEQUENCE with IA5String and a SET. The string describes the contents of the SET. Lets call these structures ''tags'' and their strings ''types''. Root tag has type MANB and contains all other tags. The first of the MANB tags is MANP. It stores some tags describing the device and some tags which purpose is unknown. Other MANB tags describe each signed image. |
||
==References== |
==References== |
||
*[http://blog.iphone-dev.org/post/6952986620/blob-monster Dev-Team Blog- explanation on APTicket's restrictions] |
*[http://blog.iphone-dev.org/post/6952986620/blob-monster Dev-Team Blog- explanation on APTicket's restrictions] |
||
*[http://blog.iphone-dev.org/post/22834622159/5x-redux Release post for the A5 downgrade] |
*[http://blog.iphone-dev.org/post/22834622159/5x-redux Release post for the A5 downgrade] |
||
| + | <references /> |
||
| − | |||
==See Also== |
==See Also== |
||
Latest revision as of 13:00, 17 September 2021
APTickets (short for Application Processor Ticket[1]) are the new type of SHSH blobs, used by iOS 5.0 and newer. The client (iBSS/LLB/iBoot/BootROM) generates a random string (nonce), then iTunes and the device sends the request for blob signing and the server returns the data, just like the original SHSH protocol.
Contents
Restoring
When iTunes or the on-device firmware upgrader sends a request to Apple's servers to confirm the APTicket, instead of returning the one already stored on the server, a new one is generated. Furthermore, devices with iOS 5 depend on the APTicket being legitimate to be able to boot; the device will enter Recovery Mode if it isn't.
Downgrading
Saurik's original replay attack method of allowing downgrades for any firmware that had been backed up on his server was partially halted for iOS 5 users due to this new system; now it will back up APTickets, but it can't send it directly from his servers; Redsn0w and iFaith can stitch a stock or custom firmware to enable downgrading with APTicket, but it only works for devices vulnerable to Limera1n Exploit.
Faking APTickets is complicated because they are signed with a private key that only Apple knows and they are also partly generated from a random string (nonce).
iOS 4.3.5 and older can still be downgraded if SHSH blobs were saved.
iPad 2 users with iOS 4.3.x SHSH blobs can upload their 4.3.x iBSS via DFU and jump to iOS 5's iBEC. At this point, a signed IPSW can be used to restore to cached iOS 5 blobs. (This method is very effective on WiFi-only models. 3G models require the baseband to be installed/signed... Something like semaphore's TinyCFW can be implemented to get around this).
A vulnerability found independently by iH8sn0w and the iPhone Dev Team allowed downgrading all A5 devices running 5.x with their saved APTickets by restoring the latest firmware- verifying APTicket with the iBSS or iBoot then restoring the hacked firmware without APTicket- then when the restore ends, the requisite firmware is restored. This method theoretically works with BBTickets, but such a baseband downgrade was never out.
A bug existing in several 32-bit versions of iOS, though only exploitable in iOS 9.x, allows users to downgrade using cached iBSS/LLB blobs and APTicket, provided that the APTicket does not contain a nonce. A missing nonce is not treated as a mismatch, allowing the restore to continue and effectively defeating the improved downgrade prevention introduced by APTickets. The first public tool that exploited the bug was iDeviceReRestore (released on 2 April 2017), which, unlike Odysseus, does not require the device to be jailbroken. This brought a way to restore 32-bit devices to jailbreakable firmware, devices that had not seen a jailbreak for signed firmware since the release of Pangu9 for iOS 9.0.x more than 17 months earlier. The method was later incorporated into futurerestore.
APTicket structure
APTicket is a piece DER encoded data. The format of the data is different for 32-bit and 64-bit devices, but these formats have something in common. Each APTicket has a header, signed DER encoded SET, which contains hashes of all signed images and some additional data, PKCS#1 signature and two certificates. The first certificate is an Apple Secure Boot Certificate and the second one is specific for each TSS server and device CPU.
Old APTicket format
Old APTickets begin with a SEQUENCE which contains a signature type. This signature type shall match one in the first certificate. Next comes a SET with ECID, chip ID, board ID, SHA1 hashes of all signed images and some boolean values indicating true. Seems like tag of each element in the SET describes it's meaning. Old APTickets end with a signature and two certificates.
IM4M APTicket/ApImg4Ticket format
These begin with an IA5String "IM4M" and an INTEGER which is likely a version number. SET in these APTickets contains data structures of similar format. Each structure is of constructed type with PRIVATE class and contains a SEQUENCE with IA5String and a SET. The string describes the contents of the SET. Lets call these structures tags and their strings types. Root tag has type MANB and contains all other tags. The first of the MANB tags is MANP. It stores some tags describing the device and some tags which purpose is unknown. Other MANB tags describe each signed image.
References
See Also
- Cydia article on Wikipedia
- redsn0w, which has functionality to backup APTickets on devices exploitable with limera1n
- Details from saurik about the replay attack
