Difference between revisions of "Brick"

From The iPhone Wiki
Jump to: navigation, search
(some wording clarification; adding link)
(more rewriting for clarity)
Line 1: Line 1:
A '''bricked''' device is a device that does not work -- metaphorically, it's as useful as a brick. Though nominally meaning that the device is permanently damaged, people use the term "bricked" for conditions which range from trivially recoverable (a failed update) to completely unrecoverable (in cases involving damaged baseband memory). A phone may be referred to as "bricked" if it will not boot, will not respond to input, will not make calls, etc. Early unlock solutions frequently resulted in partially-bricked phones after firmware updates were applied. The iPhone is quite difficult to brick permanently via software, and in almost all cases the damage can be reversed.
+
A '''bricked''' device is a device that does not work. The direct metaphorical meaning is that the device is permanently damaged (making it as useless as a brick), but people use the term "bricked" for non-working conditions which range from easy to fix (such as a failed update) to impossible to fix (such as damaged baseband memory). A phone may be called "bricked" if it will not boot, will not respond to input, will not make calls, etc. iOS devices are very difficult to brick permanently via software, and in almost all cases the damage can be reversed.
   
== Irreversible software bricking ==
+
== Difficulty of bricking an iOS device ==
One way to irreversibly brick your device in software is to flash an invalid [[Baseband Bootloader|baseband bootloader]], provided it has a baseband. Most other bad flash scenarios are recoverable some way or another. It is impossible to brick your device simply by [[jailbreak]]ing it and installing normal software via Cydia, since you can use [[DFU Mode]] to restore it.
 
   
  +
Jailbreaking cannot put a device into an unusable state on its own. If something goes wrong with a jailbreak, putting the device into [[DFU Mode]] will allow you to restore it via iTunes. Installing software via Cydia also cannot cause an unrecoverable state; if something goes wrong, DFU mode will still work.
If you purposefully erase / zero out your [[NOR]], then you will even have trouble doing a DFU restore because important information from the SysCfg section will not be available. [http://www.reddit.com/r/jailbreak/comments/1m3jo6/how_much_torture_kernel_user_based_etc_would_it/cc5g8nj See winocm's explanation of one way to brick a device.]
 
   
== Software bricking with wrong baseband version ==
+
== Types of "bricking" that can be easily fixed ==
   
  +
=== Installing stock iOS on a device with a preserved baseband ===
Another recent way to brick the baseband is by installing baseband [[06.15.00]] on an incompatible device. [[redsn0w]] has an option to install this baseband on the [[N82ap|iPhone 3G]] or [[N88ap|iPhone 3GS]] in order to get a baseband version that is unlockable with [[ultrasn0w]]. This is a nice way to get an unlock, because the [[K48ap|iPad]], the [[N82ap|iPhone 3G]] and the [[N88ap|iPhone 3GS]] all share the same [[Baseband Device]], but the [[K48ap|iPad]] has a newer version number in its baseband. That way people can actually downgrade by installing a higher version (there are no [[APTicket]] checks in these devices). This has known side-effects, like losing [[GPS]] functionality (this baseband comes from an iPad which has [[GPS]] not or differently implemented).
 
  +
  +
Early unlock solutions frequently resulted in unusable (but recoverable) phones after installing an iOS update. ''Fill out more detail here.''
  +
  +
== Types of bricking that may be impossible to fix ==
  +
  +
=== Intentionally modifying key parts of iOS ===
  +
  +
If you purposefully erase / zero out your [[NOR]], then you will even have trouble doing a DFU restore because important information from the SysCfg section will not be available.
  +
  +
[http://www.reddit.com/r/jailbreak/comments/1m3jo6/how_much_torture_kernel_user_based_etc_would_it/cc5g8nj See winocm's explanation of one way to brick a device.]
  +
  +
=== Making the wrong modifications to the baseband ===
  +
  +
One way to irreversibly brick a device in software is to flash an invalid [[Baseband Bootloader|baseband bootloader]], provided it has a baseband. Most other bad flash scenarios are recoverable some way or another.
  +
  +
Another way to brick the baseband is by installing baseband [[06.15.00]] on an incompatible device. [[redsn0w]] has an option to install this baseband on the [[N82ap|iPhone 3G]] or [[N88ap|iPhone 3GS]] in order to get a baseband version that is unlockable with [[ultrasn0w]]. This is a nice way to get an unlock, because the [[K48ap|iPad]], the [[N82ap|iPhone 3G]] and the [[N88ap|iPhone 3GS]] all share the same [[Baseband Device]], but the [[K48ap|iPad]] has a newer version number in its baseband. That way people can actually downgrade by installing a higher version (there are no [[APTicket]] checks in these devices). This has known side-effects, like losing [[GPS]] functionality (this baseband comes from an iPad which has [[GPS]] not or differently implemented).
   
 
Now bricking a [[N88ap|iPhone 3GS]] baseband is possible with this method. In fall 2011 Apple replaced the [[NOR]] flash. It is not clear if this was done intentionally to prevent this method. Previous type was 36my1ee and they changed it to 36my1eh, 36my1eg. (Please note that there was '''no''' switch to Toshiba baseband devices as some sources on the Internet still tell.) These new [[NOR]] flash chips seem to work with the newer baseband versions in the [[N88ap|iPhone 3GS]], but are not supported with the old [[06.15.00]] baseband. Therefore installing this version will brick your device if you have a new [[NOR]] flash, as you (currently) cannot go back and install anything else. To check before installation, check the version number, as it reveals the production year/week in the digits 3...5. Week 34/2011 appears safe so far, 35 seems iffy, 36 seems iffy, 37 is not safe. Or open the device and check the chip type.
 
Now bricking a [[N88ap|iPhone 3GS]] baseband is possible with this method. In fall 2011 Apple replaced the [[NOR]] flash. It is not clear if this was done intentionally to prevent this method. Previous type was 36my1ee and they changed it to 36my1eh, 36my1eg. (Please note that there was '''no''' switch to Toshiba baseband devices as some sources on the Internet still tell.) These new [[NOR]] flash chips seem to work with the newer baseband versions in the [[N88ap|iPhone 3GS]], but are not supported with the old [[06.15.00]] baseband. Therefore installing this version will brick your device if you have a new [[NOR]] flash, as you (currently) cannot go back and install anything else. To check before installation, check the version number, as it reveals the production year/week in the digits 3...5. Week 34/2011 appears safe so far, 35 seems iffy, 36 seems iffy, 37 is not safe. Or open the device and check the chip type.

Revision as of 11:10, 2 April 2014

A bricked device is a device that does not work. The direct metaphorical meaning is that the device is permanently damaged (making it as useless as a brick), but people use the term "bricked" for non-working conditions which range from easy to fix (such as a failed update) to impossible to fix (such as damaged baseband memory). A phone may be called "bricked" if it will not boot, will not respond to input, will not make calls, etc. iOS devices are very difficult to brick permanently via software, and in almost all cases the damage can be reversed.

Difficulty of bricking an iOS device

Jailbreaking cannot put a device into an unusable state on its own. If something goes wrong with a jailbreak, putting the device into DFU Mode will allow you to restore it via iTunes. Installing software via Cydia also cannot cause an unrecoverable state; if something goes wrong, DFU mode will still work.

Types of "bricking" that can be easily fixed

Installing stock iOS on a device with a preserved baseband

Early unlock solutions frequently resulted in unusable (but recoverable) phones after installing an iOS update. Fill out more detail here.

Types of bricking that may be impossible to fix

Intentionally modifying key parts of iOS

If you purposefully erase / zero out your NOR, then you will even have trouble doing a DFU restore because important information from the SysCfg section will not be available.

See winocm's explanation of one way to brick a device.

Making the wrong modifications to the baseband

One way to irreversibly brick a device in software is to flash an invalid baseband bootloader, provided it has a baseband. Most other bad flash scenarios are recoverable some way or another.

Another way to brick the baseband is by installing baseband 06.15.00 on an incompatible device. redsn0w has an option to install this baseband on the iPhone 3G or iPhone 3GS in order to get a baseband version that is unlockable with ultrasn0w. This is a nice way to get an unlock, because the iPad, the iPhone 3G and the iPhone 3GS all share the same Baseband Device, but the iPad has a newer version number in its baseband. That way people can actually downgrade by installing a higher version (there are no APTicket checks in these devices). This has known side-effects, like losing GPS functionality (this baseband comes from an iPad which has GPS not or differently implemented).

Now bricking a iPhone 3GS baseband is possible with this method. In fall 2011 Apple replaced the NOR flash. It is not clear if this was done intentionally to prevent this method. Previous type was 36my1ee and they changed it to 36my1eh, 36my1eg. (Please note that there was no switch to Toshiba baseband devices as some sources on the Internet still tell.) These new NOR flash chips seem to work with the newer baseband versions in the iPhone 3GS, but are not supported with the old 06.15.00 baseband. Therefore installing this version will brick your device if you have a new NOR flash, as you (currently) cannot go back and install anything else. To check before installation, check the version number, as it reveals the production year/week in the digits 3...5. Week 34/2011 appears safe so far, 35 seems iffy, 36 seems iffy, 37 is not safe. Or open the device and check the chip type.