The iPhone Wiki is no longer updated. Visit this article on The Apple Wiki for current information. |
Difference between revisions of "Brick"
(noting nvram variable bricking method more explicitly) |
(quoting ways) |
||
Line 27: | Line 27: | ||
If you purposefully erase / zero out your [[NOR]], then you will have trouble doing a DFU restore because important information from the SysCfg section will not be available. |
If you purposefully erase / zero out your [[NOR]], then you will 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 several |
+ | [http://www.reddit.com/r/jailbreak/comments/1m3jo6/how_much_torture_kernel_user_based_etc_would_it/cc5g8nj See winocm's explanation of several related ways to brick a device]: |
+ | |||
+ | <blockquote> |
||
+ | * Erase SysCfg/replace it with 0xFFs. |
||
+ | * Destroy the 'SrNm' tag in the SysCfg, it won't activate then. |
||
+ | * Set all clock gates enabled and set PLL frequencies to mad numbers, THIS WILL DAMAGE THE HARDWARE. |
||
+ | * Run constant NAND stress tests to wear out NAND pages. |
||
+ | * Set the 'display-timing' nvram variable to some other garbage. iPod touch 2G/3G does weird things with that. |
||
+ | |||
+ | If you know how the hardware works, this can be done from an iBoot/kernel level. |
||
+ | </blockquote> |
||
=== Making the wrong modifications to the baseband === |
=== Making the wrong modifications to the baseband === |
Revision as of 00:17, 18 February 2015
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.
Contents
Difficulty of bricking an iOS device
Jailbreaking cannot put a device into an unusable state on its own. If something goes wrong while jailbreaking, putting the device into DFU Mode will allow you to restore it via iTunes. Installing software via Cydia also cannot cause an unrecoverable state (unless very specifically designed to do so by a malicious person, which has not been seen "in the wild"). Other than that specific exception, if something goes wrong, DFU mode will still work.
Types of "bricking" that can be easily fixed (not really "bricking")
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 hard to fix
Changing MAC address to invalid address
If you change your device's MAC address to something invalid (for example if you're attempting to change your UDID), your internet won't work again until you fix the MAC address (using MobileTerminal or similar). This persists even if you restore -- so you can make this really really hard to fix if you restore and there's no jailbreak available, if the available jailbreaks don't include afc2 and other workarounds aren't working, etc. Here's a JailbreakQA thread about this and another one.
Types of bricking that are (or may be) impossible to fix
Intentionally modifying key parts of iOS: changing NVRAM variables to invalid values
In February 2015, researchers released information about how to change an nvram variable called DClr_override
. If this is changed to an invalid value for the device (valid values are not the same on all devices), and the device is rebooted, the device will permanently not be able to boot. This cannot be fixed with a DFU restore or any other method.
Intentionally modifying key parts of iOS: other ways
If you purposefully erase / zero out your NOR, then you will have trouble doing a DFU restore because important information from the SysCfg section will not be available.
See winocm's explanation of several related ways to brick a device:
- Erase SysCfg/replace it with 0xFFs.
- Destroy the 'SrNm' tag in the SysCfg, it won't activate then.
- Set all clock gates enabled and set PLL frequencies to mad numbers, THIS WILL DAMAGE THE HARDWARE.
- Run constant NAND stress tests to wear out NAND pages.
- Set the 'display-timing' nvram variable to some other garbage. iPod touch 2G/3G does weird things with that.
If you know how the hardware works, this can be done from an iBoot/kernel level.
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).
It was possible to brick an iPhone 3GS with this method. In fall 2011 Apple replaced the NOR flash. It is not clear if this was done intentionally to prevent this method. The previous type of baseband was 36my1ee and they changed it to 36my1eh, 36my1eg. (There was no switch to Toshiba baseband devices.) 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, 35 seems iffy, 36 seems iffy, 37 is not safe. Or open the device and check the chip type.