Hubbry Logo
search
logo

SHSH blob

logo
Community Hub0 Subscribers
Write something...
Be the first to start a discussion here.
Be the first to start a discussion here.
See all
SHSH blob

In computing, a SHSH blob, short for Signature HaSH blob, is a digital signature that Apple generates and uses to control the iOS versions that users can install on their iOS devices generally only allowing the newest iOS version to be installable. Apple's public name for this process is System Software Authorization (before iOS 7, System Software Personalization). The term “SHSH blob” is unofficial and based on abbreviations for signed hash and binary large object. An alternative term, ECID SHSH, refers to the device's ECID, a unique identification number embedded in its hardware.

This process is controlled by the TATSU ("TSS") Signing Server (gs.apple.com) where updates and restores can only be completed by iTunes if the version of iOS is being signed. Developers interested in iOS jailbreaking have made tools for working around this signature system in order to install jailbreakable older iOS versions that are no longer being signed by Apple.

SHSH blobs are created by a hashing formula that has multiple keys, including the device type, the iOS version being signed, and the device's ECID.[non-primary source needed] When Apple wishes to restrict users' ability to restore their devices to a particular iOS version, Apple can refuse to generate this hash during the restore attempt, and the restore will not be successful (or at least will require bypassing the intended function of the system).

This protocol is part of iPhone 3GS and later devices.

When iTunes restores or updates an iOS firmware, Apple has added many checkpoints before the iOS version is installed and on-device consolidation begins. At the first "Verifying iPhone software" iTunes communicates with "gs.apple.com" to verify that the IPSW file provided is still being signed. The TATSU server will give back a list of versions being signed. If the version is not being signed, then iBEC and iBoot will decline the image, giving an error of "error 3194" or "declined to authorize the image".

iTunes will communicate with iBoot throughout the process of an update or restore ensuring the firmware has not been modified to a Custom Firmware ("CFW"). iTunes will not update or restore a device when it suspects the file has been modified.

This is a chain process, before installing the firmware, the installed iBoot has to verify the to-be-installed iBoot, and so on. You cannot install unsigned iOS versions, unless 1) you possess SHSH2 blobs and have set nonces (requiring exploits) or 2) you exploit the chain process.

The requirement of SHSH Blobs in order to install to unsigned iOS versions can be bypassed using a replay attack, by saving blobs while an iOS firmware is still signed and later using them when installing the firmware. Newer iOS versions require more elements, such as a valid nonce, when saving SHSH blobs. Saving blobs for devices using the A12 SoC or newer also requires getting a matching nonce for a generator from a device to save valid blobs that can be used later in a restore. Even with SHSH blobs saved correctly, it is still sometimes not possible to jump to certain iOS versions due to incompatibility of the SEP (Secure Enclave) between versions.

See all
User Avatar
No comments yet.