SHSH blobs is a Hash signature system (Signature HaSH blobs) made by Apple Inc. to control manual software downgrades on iPhones, iPads, and iPod touches (a typical prelude to Jailbreaking). An SHSH is created by an SHSH formula (CLI Application) with 3 or 4 TSS keys: 1) the device (e.g. iPhone 4 CDMA), 2) the firmware version being signed (e.g. 4.2.8) and 3) the device’s ECID, a unique ID contained within every device. The SHSH is a Plist, built with blobs, with each blob intended for a different part of the software (like kernel and Apple logo). These blobs control which firmware is restorable and which is not. When Apple wishes to restrict users’ ability to “downgrade” their devices to a prior firmware version, Apple can simply refuse to generate this hash during the downgrade attempt, and the downgrade will not be successful (or at the very least, will require significant technical intervention).
Pre-SHSH signing and the LLB
From the beginning, iOS devices with a baseband processor were always signed with a random number, (With addition of baseband TSS key) from iOS 1.0 on. When Jailbreak started to be developed, Apple has changed the LLB (Low Level Bootloader) to check the signature on iBoot before jumping to it, which checks the signature of the kernel. As a combat, hackers have used Boot-ROM exploits (Pwnage and 24kpwn) to patch the LLB to cancel the signature checks, achieving an untethered jailbreak. All devices released after iPhone 3G check if a patched LLB is submitted and will enter hardware DFU, a DFU mode that a device can’t quit unless it is restored. Patched LLBs can only be submitted on pre-A4 processor devices and the old-bootrom iPhone 3GS. But with SHSH, users can downgrade and jailbreak older versions, or even jailbreak with software upgrade from an old firmware to a newer one if an exploit is found in restore mode.
The ECID (Unique device ID) is a unique 13-numeral number attached to the hardware of every device, and is not in use for devices that don’t require SHSH blobs. Each device has its own ECID and it is not changeable. The ECID is the third TSS key when the SHSH is created and SHSH files for different ECID from the restored device will not be accepted by the device. From iOS 4.0 on, also devices which do not have their ECID coded for SHSH blobs, that support iOS 4 and on, get SHSH blobs, but are never required for a restore.
Between iOS 3.0-4.3.5, SHSHs for the main firmwares were made of 3 TSS keys- Device, Firmware version, and ECID which means the SHSH file for a certain firmware and device would be the same with every restore. As a combat from the jailbreak side, Cydia would save SHSH files on it servers, cached from Apple, so when the Hosts files on the computers are set on Cydia’s servers, iTunes would take the cached SHSH and restore it. Another method was to save the SHSH locally on the computer. At the beginning George Hotz saved just the iBSS/iBEC specific SHSH, then The Firmware Umbrella was released to save the SHSH in a better way and TInyTSS to send the SHSH to the iTunes restore, finally TinyUmbrella to do both and to fix iTunes errors or manage recovery mode, then iFaith to take the Signed SHSH blobs from device and finally an update to Redsn0w to verify SHSH, query blobs from Cydia, Fetch SHSH blobs from the device, Submit blobs to Cydia and stitch SHSH blobs to a firmware. Because of this behavior from the side of hackers, Apple has randomized the SHSH for each restore to be different. this is referred to as aTicket. This random number is saved on Apple’s servers, so if iTunes checks if the blobs are okay with Apple, it will know that the blobs have been requested before, and the restore wouldn’t work. As of October 27, 2011, The static SHSH blobs which are given are for 4.1 for iPhone 3G, iPhone 3GS, iPod touch 2G, and iPod touch 3G and 4.2.1 for iPhone 3G and iPod touch 2G. The random SHSH blobs which are given currently are for 5.0 for iPhone 3GS, iPhone 4, iPhone 4S, iPad, iPad 2, iPod touch from 4th generation and higher.
SHSH blobs are built from 19 blobs, each one for another place on the firmware (like AppleLogo, RestoreRamdisk, Device tree etc.). The blobs are encrypted and are organized in a Plist under the key “blob”.