It’s been a busy period for tihmstar’s suite of tools since the release of Prometheus during the 33c3 convention. Both TSSChecker and Prometheus have seen some problems, as well as updates in the intervening period, and this article will bring you up to date with their current statuses.
Prometheus
Soon after its release, various problems began to be reported with the “futurerestore” section of the Prometheus tool, which handles the actual upgrading/downgrading process.
Server errors
The most common of these were reports of server errors when attempting to use the tool. This led some to claim (incorrectly) that Apple had taken its TSS servers completely offline. Whilst it is not completely clear whether there was some concurrent server maintenance or whether it was something to do with the coding of tihmstar’s tool which caused the error to be thrown, this seems to have been fixed in the most recent builds.
Segfault errors
A second common occurrence was “segfault” errors, caused by macOS lacking the requisite OpenSSL support. This has also been fixed in the most recent builds of Prometheus, clearing up the majority of the failed usages of the tool which users had experienced. Reports are now being seen of successful usages of the “futurerestore” tool, however, with this broader testing has come the discovery of an even worse problem…
Touch ID on iOS 10.1.1
Because “futurerestore” does not downgrade the SEP + baseband as part of its restore (this isn’t possible without a SEP exploit), it instead replaces them with a currently signed version instead. At present, that means iOS 10.2 SEP + baseband are used when restoring to iOS 10.1.1. It was thought that the two versions were close enough that this wouldn’t cause problems, however it has become clear as more people have tried it out that while the downgrade/upgrade to iOS 10.1.1 does complete with “futurerestore”, it leaves the Touch ID services non-functional.
This will no doubt be a deal-breaker for most would-be users of the tool, as Touch ID (and possibly other related services too such as Apple Pay, not yet confirmed) are essential features for most.
Interestingly, Luca Todesco has commented that a workaround for this issue should be possible, but there is no further information beyond that. Whether it is truly possible, whether he has begun working on it, or whether he even intends to at all are unknown for the time being. For his part, tihmstar has said that he will not be working on the issue.
Overall, a bumpy start for Prometheus, but it can now be said that the tool does definitely work in principle, having had its fatal errors corrected. However, with the Touch ID situation as it is (not a bug but an inherent limitation of the downgrade method), it is unclear how many users will be willing to use it.
TSSChecker
Tihmstar’s other tool TSSChecker, used for saving APTickets into his proprietary .shsh2 format for use with Prometheus, has also had two serious hurdles come up in recent days.
Problem 1: iPhone 7 / Plus incompatibility
The discovery was made this week that the iPhone 7 and iPhone 7 Plus use a different method to other 64-bit devices when creating generators for its nonces. Whilst this problem does not affect any other devices, it does mean that all blobs saved with generators for these two devices are unfortunately invalid. Until tihmstar can figure out the different relationship Apple is using between its nonces and generators, TSSChecker will not be able to save blobs with generators on iP7(+).
Blobs saved with a specific nonce, and therefore with no generator, may not be affected, however since the iP7(+) is not susceptible to Prometheus’ nonce collision method anyway, it is doubtful what use this kind of blob will be in terms of downgrades. For now, iP7(+) blobs can be saved with TSSChecker by using a nonce composed of a random set of 32 bytes, so long as you use the newest version of the tool. It is unlikely that these blobs will be usable with Prometheus, though tihmstar has said that they may still come in handy with different methods at a later date.
Problem 2: BuildIdentities and invalid blobs
This issue is slightly more complicated to explain, and will not affect everyone equally. It turns out that a change to IPSW files in iOS 10 means that many devices use the same IPSW. This means that information pertaining to all the devices (BuildIdentities) is saved in the Build Manifest inside a single IPSW. As this never used to be the case, TSSChecker used to simply take the first BuildIdentity it found and request an APTicket for that. However, now that there are many BuildIdentities in the IPSW, the first entry may not in fact have been the correct one for your device. This means, sadly, that if the wrong BuildIdentity was selected, the APTicket which was generated by TSSChecker was invalid.
The most recent version of TSSChecker has fixed this error, and these changes are also incorporated into 1Conan’s online version of the tool, TSSSaver. However, what should you do about the .shsh2 files you already have saved? Are they valid?
If you have iOS 10.2 blobs, the best thing to do is just trash them and request new ones with the newest version of TSSChecker or TSSSaver, as 10.2 is still signed and you can get them easily. This will be faster and simpler than verifying the ones you already saved for that particular firmware.
With blobs for 10.1.1 and older, you obviously cannot request new .shsh2 files now as the firmwares are unsigned. In this case, your only option is to hope your blobs were some of the lucky ones which got the correct BuildIdentity first time round, and consequently a valid APTicket. This can be tested using tihmstar’s “img4tool”. The instructions for how to do so are on his blog, but I will put up a how-to soon as the process is fairly involved.
For now, I recommend that anyone who had previously saved .shsh2 blobs for iOS 10.2 re-save them with the newest TSSChecker/TSSSaver. For older blobs, do not delete them until you know for sure that they are bad. As a hopeful story, I checked mine and found that both my iPhone 6 and my iPhone SE blobs were correct, however my iPhone 5s blobs were invalid.
Good luck with your re-saving and verifying! If you do decide to verify your existing blobs with “img4tool”, please let me know which devices had good/bad blobs. It will be important to see if it is always specific devices, or whether it is more complicated than that. Make sure that in all cases you are downloading the most recent versions of tihmstar’s tools to ensure the same problems do not continue to occur.