Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

TheShadowXX

macrumors regular
Original poster
Sep 29, 2012
172
1
Quick questions

When people talk about Apple "signing" a firmware version. What does that mean exactly? I know that when you restore your phone you have to get the latest firmware (6.1.3) because Apple is only "signing" that version.

Also how come A4 devices are able to downgrade to previous firmware versions (if you have SHSH blobs saved) whereas A5, and A6 can't?
 
Quick questions

When people talk about Apple "signing" a firmware version. What does that mean exactly? I know that when you restore your phone you have to get the latest firmware (6.1.3) because Apple is only "signing" that version.

Also how come A4 devices are able to downgrade to previous firmware versions (if you have SHSH blobs saved) whereas A5, and A6 can't?

It basically means when apple is allowing the installation of a firmware without going through hoops and such.

A4 devices are able to restore to any firmware versions as long as they have valid shsh blobs saved because of the bootrom exploit that exists for those devices
 
Quick questions

When people talk about Apple "signing" a firmware version. What does that mean exactly? I know that when you restore your phone you have to get the latest firmware (6.1.3) because Apple is only "signing" that version.

Also how come A4 devices are able to downgrade to previous firmware versions (if you have SHSH blobs saved) whereas A5, and A6 can't?

Signing basically means "apple approves that firmware for installation". The reason A4 devices can install non-signed firmwares (assuming you have valid blobs which means you saved "apple's approval" while the window was open) is because those devices have a bootrom-level exploit. This exploit kicks in before the firmware approval process. Therefore the hackers can create their tools to allow devices to install firmware with saved blobs. But the newer devices are not susceptible to this exploit, therefore they can't use it in order to install older firmwares.

I am prolly off on the details a little but this is the general idea. I'm sure others will have much better info for you.
 
It basically means when apple is allowing the installation of a firmware without going through hoops and such.

A4 devices are able to restore to any firmware versions as long as they have valid shsh blobs saved because of the bootrom exploit that exists for those devices


I get that, that apple is allowing the installation of a firmware, but my question is when restoring my device, what actually happens? the phone gets .IPSW file for the new firmware from Apple.com and then it has to checkout through apples servers and then install on my device? or am I totally wrong lol

Also what is the difference between a bootrom and a bootloader?

I read this site

http://stackoverflow.com/questions/...etween-a-bootrom-vs-bootloader-on-arm-systems

but i'm still having a bit of trouble understanding. It seems like the bootloader is superior to the bootrom because its can be modified? (and is not write-protected)
 
I get that, that apple is allowing the installation of a firmware, but my question is when restoring my device, what actually happens? the phone gets .IPSW file for the new firmware from Apple.com and then it has to checkout through apples servers and then install on my device? or am I totally wrong lol

Also what is the difference between a bootrom and a bootloader?

I read this site

http://stackoverflow.com/questions/...etween-a-bootrom-vs-bootloader-on-arm-systems

but i'm still having a bit of trouble understanding. It seems like the bootloader is superior to the bootrom because its can be modified? (and is not write-protected)

Yes, iTunes has to check with apple's server and it has to be verified in order to continue with the installation of the firmware

Not sure about bootrom vs bootloader
 
For iOS 3 and 4, SHSH blobs were made of static keys (such as the device type, iOS version, and ECID), which meant that the SHSH blobs for a specific iOS version and device would be the same upon every restore. To subvert that system using a man-in-the-middle attack, server requests the unique SHSH blobs from Apple for the jailbroken device and caches those SHSH blobs on servers, so that if a user changes the hosts file on a computer to redirect the SHSH blobs check to cache instead of Apple's servers, iTunes would be tricked into checking those cached SHSH blobs and allowing the device to be restored to that version.

iOS 5 and later versions of iOS implement an addition to this system, a random number (a cryptographic nonce) in the "APTicket", making that simple replay attack no longer effective. Versions of redsn0w after 0.9.9b9 include a way to bypass the nonce requirement, allowing the SHSH blobs and APTicket to both be replayed by "stitching" them into custom firmware.

First released in 2009 (as TinyTSS and Umbrella), TinyUmbrella is a tool for finding out information about SHSH blobs saved on third party servers, saving SHSH blobs locally, and running a local server to replay SHSH blobs to trick iTunes into restoring older devices to iOS 3 and 4. In June 2011, iH8sn0w released iFaith, a tool that can grab partial SHSH blobs from a device for its currently-installed iOS version (limited to iPhone 4 and older devices). In late 2011, the iPhone Dev Team added comprehensive SHSH blob management features to redsn0w, including the ability to save SHSH blobs with APTickets and stitch them into custom firmware in order to restore a device to iOS 5 or later.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.