A very common question with iOS users (both jailbreak-ers and stock users) is whether or not they can downgrade or restore to a specific iOS that is not the latest/currently signed iOS, whether it be an iPhone, an iPad, or an iPod Touch. Before proceeding, I would like to denote some of the usage of terms in the following to avoid confusion: .X or .Y refers to an arbitrary set of valid numbers that follows that of an iOS threshold. For example, iOS 5.X can be denoted as iOS 5.0, iOS 5.0.1, iOS 5.1, iOS 5.1.1, or iOS 5.1.1 r1. IPSW is the extension for Apple's firmware file. It is similar to that of a .zip, .rar or .deb file in that it's an archive extension. IPSW extension files are only iOS firmware files. Here, we’ll go a little in-depth with regards to why this feat is not possible, as well as Apple’s reasoning behind this. SHSH Blobs: There is a beautiful sticky here that explains what SHSH blobs are and their basic use. A more in-depth explanation of what SHSH blobs are is the breaking down of the functionality and how they’re used in the practical sense. SHSH stands Signature HaSH, and is shortly referenced as SHSH or blobs for the full term “ECID SHSH” or Exclusive Chip ID. The ECID refers to a specific identifier for each chipset. No 2 ECID are the same. In some cases, you can enter your ECID for your device into utilities such as TinyUmbrella or RedSn0w to retrieve your blobs from either Apple or Cydia, which is dependent on whether you’re saving blobs from Apple’s signature server, or, from Cydia’s server which already has your blobs. Note that you DO NOT have to be jailbroken to save SHSH blobs. TinyUmbrella, RedSn0w, iFaith, and computer utilities alike, does not require your device to be jailbroken as they only use your ECID to match blobs on either Apple's server or Cydia's server depending on where you point the utility. As the name SHSH already presents, it’s a signature unique to your specific device from Apple. Much like a request form from a corporation, without the signature of someone in the hierarchy that has the privilege to, you may not install a firmware on your iOS without Apple’s say so. And because each SHSH blob is unique to a specific device on a specific iOS, you may not share SHSH blobs. A lot of users believe that SHSH blobs are universal based on device type rather than specific device, which is not true. With SHSH blobs, when restoring to a custom firmware, a user must stitch the SHSH blob with the firmware that matches the same device build (device identifier must match; iOS and build must also match). The SHSH blobs act as keys. If the “key” on the user-end, does not match that of the “lock” on the Apple end, you cannot unlock the gate that allows you to restore, or much like a password to a password field. If the password does not match, you cannot sign in as the user. Because Apple has a set of lock that is specific to each device, there is no way share SHSH blobs, and unfortunately, there are no master keys that will universally unlock each of these locks. Stitching the SHSH blobs to a firmware file (IPSW) is the only way to utilize them. On iOS 4.X and older firmwares, to restore to a copy of iOS 4 or below firmware, you would first have to contact the TSS or Tatsu Signing Server on Apple’s end. TSS will partly verify your blobs, and, as the name suggests, sign your “request form” to install a custom IPSW. Again, without SHSH blobs, you cannot provide the key to the lock that opens the gate that allows for you to restore to a custom firmware, and to connect to TSS, a common utility used on computer terminals on the user-end is TinyUmbrella or TU for short. By connecting to TSS, you can openly use iTunes to restore to an iOS 4.X or below custom IPSW, and utilizing the bootrom level exploit on some devices, users are able to install custom firmware despite Apple’s block. Why this is only for iOS 4.X and below will be explained in the iOS 5 and 6 section below the Bootrom section. Bootrom/Boot Sequence The iOS, like any OS (operating system) has a sequence in which it follows to start up from the moment you power on to the device, until you are presented with the Springboard (in the case of iOS) or the desktop (in the case of a computer). The sequence in which the iOS boots is the following: Bootrom > LLB > iBoot > Kernel > Firmware The bootrom is the first in the sequence and is read-only, meaning changes cannot be made to it unless you upgrade the hardware component, meaning bootrom exploits cannot be patched unless there is a physical upgrade to the device (as presented with the iPhone 4S and iPad 2 and later devices). An exploit at this level unlocks many possibilities for running unsigned code and modifications. The LLB checks for signatures for iBoot upon startup, verifying that iBoot is as it should be. This will be explained a little more in the iOS 5 and 6 section below, but in the general sense on iOS 4.X and below, this checks to see whether iBoot is “functional” and legitimate. iBoot is in charge of Recovery Mode, or the “Connect to iTunes” screen as a lot of users are used to calling it. In a simpler sense, it allows for extremely basic interaction via USB to a terminal, and in the boot sequence, it enables the boot process to continue to the kernel and software. If the kernel or software does not pass the iBoot “check”, your device will enter Recovery Mode. The kernel accepts commands from iBoot, including arguments, and is in charge of handling inputs and outputs from software components of an OS. The kernel in iOS devices is the XNU Darwin kernel, which is also present in Mac OSX. Firmware is pretty self-explanatory. A bootrom level exploit is an exploit that many hackers dream of, as it is retained despite the firmware/iOS upgrade. A bootrom exploit is the best way to run unsigned codes/commands on a device as it is the barest of exploits and is the first thing that is “ran” when a device is powered up. With regards to install a custom IPSW, a bootrom exploit is necessary to “skip” or patch the LLB that follows to cancel an ECID check, an SHSH/APTicket check, and the firmware is not given a thorough check to ensure integrity of the firmware. Because the firmware is not “officially” signed by Apple, without a bootrom exploit, the LLB sequence will check and see that this is not a legitimate copy of iOS (in the sense that Apple has not actually authorized/signed it), and your device will proceed to the iBoot stage and default your device into Recovery Mode. In the case of the iPhone 3G, iPhone 3G, iPhone 4, iPod Touch 3rd Generation, iPod Touch 4th Generation and the iPad 1st Generation, the bootrom exploit is coined the LimeRa1n exploit, which is used for installing custom firmwares (IPSW) as well as tethered jailbreaking a device. There is a level of specificity in the LimeRa1n exploit and these listed devices, in that the listed devices all have one thing in common: their age pre-dates that of the A5 dual-core processor introduced in the iPhone 4S and iPad 2, therefore, LimeRa1n has been coined a pre-A5 chipset exploit, meaning all devices pre-dating the A5 processor devices of the iPhone 4S and iPad 2, and thus, we associate the LimeRa1n exploit with pre-A5 devices, meaning the iPhone 4 and below, the iPod Touch 4th generation and below, and the iPad 1. If you see the term LimeRa1n or pre-A5, that is limited to devices pre-dating the iPhone 4S and iPad 2. The bootrom will be explained slightly more in several of the sections below as they may be situation specific. iOS 5 and above With the release of iOS 5.0 alongside the iPhone 4S, Apple has introduced APTickets alongside SHSH Blobs, which is considered “separate” from the iOS 4.X and below SHSH blob though they are saved as one file, but partitioned in a way. The difference between SHSH blobs and APTickets is that SHSH Blobs are static, and can be re-used because it’s always constant. APTickets, on the other hand, generates a new and random string every time the client-end requests for a signature or verification from Apple, so Apple will return a new APTicket is essentially “generated” every time you request for a signature from Apple. An analogy would be how a target changes its password every time their security is breached. To ensure that the hacker does not have simple access again by using the old password, a new one is generated after every hack attempt or success hack to enforce security. APTickets are a means for Apple damper the ability to downgrade or install a custom firmware onto any iOS device. But for many experienced or well-read users are aware of older devices being able to freely upgrade and downgrade to any iOS as they please (with SHSH blobs of course) at any given time without limitations (again, only with SHSH blobs); and these devices include the iPod Touch 1[SUP]st[/SUP], 2[SUP]nd[/SUP], 3[SUP]rd[/SUP] and 4[SUP]th[/SUP] generation, the iPhone 2G, 3G, 3G, 4, and the iPad 1[SUP]st[/SUP] generation. These 9 device generations have the ability to restore or install a custom firmware (IPSW), and the reason for that would be because of a bootrom exploit as discussed briefly above. As fore mentioned in the bootrom section, a bootrom exploit is absolutely necessary in modifying the LLB portion of the boot sequence, and without a bootrom exploit in the: iPhone 4S iPhone 5 iPhone 5C iPhone 5S iPad 2 iPad 3 iPad 4 iPad Mini iPad Air iPad Mini 2 (iPad Mini Retina) users are not able to install or run unsigned code necessary to install a custom IPSW, and also to tethered jailbreak a device. A5+ devices (devices listed directly above) are NOT susceptible to the LimeRa1n exploit, and therefore, these devices cannot restore to a custom IPSW of your choosing. Without a modified LLB to “look the other way”, users cannot install custom IPSW as with every boot of the device, you will be confronted with Recovery Mode. APTickets and their NONCE (randomly generated string) cannot be forged, so the LLB is modified to look the other way. And again, because of the lack of LimeRa1n on A5 devices, A5 and above devices are unable to install custom firmwares. Core Importance of a Bootrom Exploit and Pwned DFU So bootrom, bootrom, bootrom, bootrom. Why must a bootrom exploit be present? A bootrom exploit (again) allows you to run unsigned code at the beginning of your boot sequence. That said, for those that have selectively restored on pre-A5 devices before, there's a step in the restoration process prior to using iTunes is placing the device into Pwned DFU mode. In essence, Pwned DFU mode is the sole reason you're allowed to restore to custom IPSWs. If your device is not in Pwned DFU mode, you will not be able to selectively restore your device. Can Pwned DFU be achieved using other types of exploits in the boot sequence such as LLB or iBoot? Yes of course. As long as it's prior to the firmware booting portion of the chain, it's possible to place the device into Pwned DFU mode. Will it be slightly more difficult to achieve? Yes since a bootrom exploit will always be open until new hardware is released, but iBoot exploits (such as the one that @ih8sn0w is holding) can be patched through software updates (iOS updates) assuming Apple finds them and patches them. Exceptions/Special cases Of course, to every rule, there are almost always exceptions. Apple has left a lot of the older firmwares opened, particularly for the legacy devices because it is known that the devices are exploitable, but more importantly, because not many users still use these legacy devices as primary devices. Case 1: With respect to the iPad 2, iPad 3, and the iPhone 4S, users are able to restore from iOS 5.X back to iOS 5.X assuming users have valid iOS 5.X SHSH blobs and APTickets. Note the importance of both SHSH blobs and APTickets. As we've mentioned earlier, iOS 5 introduced APTickets as a partition of SHSH blobs. The re-restoring of iOS 5.X to iOS 5.X is outlined here for the iPad 2 and 3, and here for the iPhone 4S (same instructions really). What does it mean to have valid SHSH blobs and APTickets? Cydia has had the ability to automatically cache/save SHSH blobs for quite some time now, but with the introduction of iOS 5, APTickets were introduced but Cydia was not updated to check and save APTickets as well, leaving many users with invalid iOS 5 blobs because the APTicket portion was missing, and was later corrected by @Saurik. Users that did not rely on Cydia to auto-cache, and used TinyUmbrella, iFaith, RedSn0w, iSHSHit, or other utilities alike, will have valid SHSH blobs as well as APTickets. The same issue was presented with iOS 6. The algorithm was slightly corrected on Apple’s end, and it was not noticed until iOS 6.1.3, meaning all SHSH blobs automatically saved through Cydia are unfortunately invalid because of the lack of APTickets like that of the iOS 5 scenario. The best way to save your SHSH blobs and APTickets (though now it is almost exclusively APTickets with the introduction of iOS 7) is to use a utility on your computer terminal to do so such as TinyUmbrella or TU for short. In the off-chance that your blobs were saved after the correction in Cydia, you will have valid SHSH blobs and APTickets on the Cydia server. Or, if you manually saved them (through a computer terminal), you can host them onto Cydia’s server for remote access anywhere. (Excuse the slight tangent) To continue, the iPad 2, iPad 3 and iPhone 4S are able to restore from iOS 5.X back to iOS 5.X with the help of valid SHSH blobs and APTickets using RedSn0w. Devices do not have to be jailbroken to do this, nor do devices have to be jailbroken (as mentioned before) to save SHSH blobs, which a lot of users would like to do when forced to stay on iOS 5.X, or upgrade to the latest iOS and losing a jailbreak or losing the old UI/GUI. Case 2: The iPad 2 Wifi is capable of downgrading to iOS 5.Y with the aid of iOS 4.X and iOS 5.Y blobs. Meaning yes, you can downgrade from iOS 6 back to iOS 5, or iOS 7 back to iOS 5, but only if you have blobs for any iOS 4.X firmware, and valid SHSH blobs and APTickets for any iOS 5.Y firmware. This particular guide is outlined here for the iPad 2 Wifi. RedSn0w will be able to differentiate the iPad 2 Wifi upon selecting iOS 5 blobs, and will ask you to present it with iOS 4 blobs and the IPSW that matches the blobs as well as the iOS 5 IPSW that matches the iOS 5 blobs as well. Note that this is not present in any other device generation as of yet, or, this may be the only scenario in which this is present. This is, however, not present in the iPad 2 Wifi Revised model (iPad 2-Rev A, iPad2,4 or model MC954/MC988/MC989) and the iPad 2 3G. The iPad 2 Rev-A model was introduced with iOS 5.1, meaning iOS 4.X was never presented to this model of iPad 2, and without iOS 4.X blobs, you cannot undergo the feat presented directly above for the iPad 2 Wifi (Original). With respect to the iPad 2 3G model, because of a baseband constraint and the inability to modify the iPad’s baseband on top of the fact that there is no bootrom exploit to modify the LLB to look the other way when checking the baseband, you cannot re-restore using the above method on the iPad 2 3G models. Case 3: For some of the legacy devices, the iOS is openly being signed despite them not being the latest iOS. To give a complete list: iPhone 2G: iOS 1.0 to 3.1.3 iPhone 3G: iOS 2.0 to 3.1.3, iOS 4.1 iPhone 3G: iOS 4.1 [*]iPod Touch 1st Gen: iOS 1.1 to 1.1.5 [*]iPod Touch 2nd Gen: iOS 2.1.1 to 2.2.1, iOS 4.1 [*]iPod Touch 3rd Gen: iOS 4.1 You can restore to these iOS on these devices without the need of SHSH blobs. You will have to point iTunes to the specific firmware file (IPSW) to do so. Why Apple does not allow for custom firmware by default (Theory) A possibility of Apple's main concern for custom firmware installation would mainly be because of the fact that hackers can manipulate the firmware files for malicious intents, and can inject spyware, malware, etc, into the IPSW, which in turn another user may download off the internet and install, which can jeopardize not only their privacy but possibly their device as well. A lot of sci-fi or fictional shows or movies displays the act of a device heating up and either simmer with smoke or explode, and it may be possible for hackers to do so as well, or, hackers may be able to bug your device and listen in to your conversations while simultaneously off-loading your messages, voicemails, data traffic, etc without your notice. Another reason may be the fact that piracy is a huge issue in the mobile community. If custom firmwares were openly allowed, hackers would be able to modify the firmware to allow for the installation of cracked applications, which is not only immoral but also illegal (Don't pirate!!!) Among other possible concerns, these would be the most highlighted ones. As of now, the methods, discussions and explanations are those that are presently used. If newer methods, terminology, or explanations are discovered or coined, it will be updated. And of course, feel free to chime in on syntax errors, typos and any errors as it was briefly glimpsed over for very basic issues a handful of times, so some of the points may have been missed or something else may have been explained instead of what was being discussed. Credits to information sources where deemed proper.