Apple has stopped code signing iOS 9.1, build 13B143. (Code name: Boulder)
What this means, is that unless you are on iOS 9.1 you won’t ever be on 9.1…unless we find a way to spoof code signing servers again.
From an objective point of view, I understand why Apple does it. Each progressive version of the iOS firmware is more secure than the last. Apple patches security vulnerabilities and exploits that it finds or that users find and report to them. This is a good thing. And the mechanism that Cupertino uses is quite, ‘encouraging’ to say the least.
Code signing…Barney Style
How does code signing work?
Since Apple distributes the .ipsw, which is a package that contains everything you need to boot and run an iDevice, from numerous places like the Developer portal, the ipsw library and through iTunes on a desktop computer, those packages are out in the open. If you update your device via iTunes on a computer, then each progressively newer ipsw package is resident on that computer. The ipsw looks like this:
Because the package is distributed, Apple needs a way to control its deployment…or installation. Users can choose which iOS version to install by pressing the option key while clicking on ‘restore’ in iTunes. This will open a window that allows the user to choose the file with which the restore will use to complete the install. Because of this, Apple uses a code signing method that check the package with a code signing server to ensure the ipsw that the user is attempting to install is copacetic with the current deployment restrictions. This is why Apple has such a high rate of compliance on the latest iOS release when you analyze the install base.
For example if your iPhone is currently on iOS 9.1, (or any version of iOS prior to that), and for whatever reason you need to do a restore, once that system restore is complete you will automatically be pushed to the next highest firmware version that your handset is qualified for and that is currently code signed by Apple. By doing this, Apple prevents its users from being vulnerable to exploits they have already patched. For most this is good. For others…not so much.
If you consider the alternative operating systems available for mobile computing, Android for example…you will not see this kind of compliance. Google and its OEM partners don’t push their users to the next version of AndroidOS. It is as if they treat upward migration as a lottery, and you are lucky to get one. Most don’t even know if they will get an update until they are notified one is available by the device because the upgrade roadmap information is vague and sometimes even reneged upon. This is why Android has so many challenges with security.
The Jailbreak Community
The one demographic that is negatively impacted by the code signing policy, are jail breakers. These are 1%’ers who rely on an exploit in order to modify the iOS security policy to deploy code that Apple does not want executed on the handset. This code isn’t necessarily malicious or even a threat. Usually, they are changes in the user interface that better suits the individual user, or applications that have been rejected by the AppStore qualification process…which can be arbitrary.
With the current jailbreak state existing on iOS versions that are at iOS 9.0.2 (build 13A452 Code name: Monarch) or below, any work that has been done for an iOS 9.1 jailbreak is now fragmented and exists as an opportunity only for those in the install base that are currently on iOS 9.1. This means that the focus will be shifted to an iOS 9.2 based exploit, so that the efficacy of that resulting process will reach the most users.