PSA: Samsung Exynos Family Of Phones (SII And Note) Brick Bug

There has been a brick bug going around some Samsung phones that you should be aware of. Many Exynos-based Samsung phones (international I9100, Sprint D710, AT&T I777, Note N7000) were shipped with a vulnerable flash storage controller firmware. If improperly called on, some partitions of the storage chip would lock up and will be unable to be used. Often, this is the /data partition, but the /cache, /system, and even kernel are vulnerable too. This will brick your phone, to the point where even the famed JTAG (device that will unbrick the deadest of phones) will not work. It will be unrecoverable.

First of all, how do you know if your device is vulnerable. Chainfire created a simple app to tell you. Download the free APK here. If it says you’re safe, great. If it says you aren’t, keep reading. You can make sure you’re safe.

So the app told you that you are, like me, vulnerable to the brick bug. What’s next? Well, this section deals with rooted users. This bug may and DOES affect unrooted users, but there is little they can do besides avoid factory resetting their phone (this is known to brick). So, for rooted users, proceed at your own risk. Here is what causes the brick bug, straight from prestigious developer Entropy:

“This bug requires three things for you to be in danger, and ALL of these conditions must be met for danger:
1) A defective eMMC chip/fwrev that is unable to handle eMMC ERASE commands (command 38) properly. (I’ll provide a link with more detail on the nature of the bug later) – This condition is the one Chainfire’s new app checks for. By the way, M8G2FA fwrev 0×11 (seen on some Kindle Fires) is also suspected of being defective.
2) A recovery binary that attempts to erase partitions when formatting them. Most ICS recovery binaries fit in this category, most Gingerbread recoveries do not attempt to perform an erase operation so are safe. Note that also, an affected update-binary in a ZIP could be a cause of problems too. (e.g. flashing a firmware that has an ICS update-binary and formats the partition could cause a problem even with a “safe” recovery.) So a kernel can be repacked with a “safe” CWM (such as the most recent CF-Root releases) but it will still only be partially safe.
3) A kernel that allows attempts to erase a partition to actually happen. (as opposed to reporting “not supported” and doing nothing.) – A common way of rendering a kernel safe is to remove MMC_CAP_ERASE from the capability flags in drivers/mmc/mshci.c”

So for those who met #1 and are still reading, what do the others mean? #2 talks about recovery. If you are running Gingerbread, your recovery won’t be able to cause a brick by itself. However, if you’re running ICS, ICS recoveries do allow it (a nandroid restore or a factory reset may brick). So if you are running any ICS build, you may be in danger. But even if you are running a safe recovery, an unsafe ROM installer script may call on the unsafe actions and brick your phone. So make sure the ROM zip itself is safe. Before flashing anything, ask the dev if it is safe. And devs, address this issue in the first post please.

#3 refers to the kernel. Even if you flash an unsafe ROM on a Gingerbread kernel, the kernel won’t allow the actions to run. So if you’re running a Gingerbread kernel, rest easy. However, most ICS kernels do allow these actions. Again from Entropy, here is a list of kernels and kernel sources that are safe and unsafe:

  • All GT-I9100 ICS leaks and official releases are SAFE (MMC_CAP_ERASE not present)
  • All kernels based on GT-I9100 ICS Update4 sources are SAFE (MMC_CAP_ERASE not present) – This includes all CM9 nightlies for SGH-I777, GT-I9100, and GT-N7000, all GT-I9100 custom kernels I am aware of, and all SGH-I777 custom kernels I am aware of
  • All GT-N7000 ICS leaks are UNSAFE
  • All GT-N7000 ICS official kernels are UNSAFE
  • All kernels built from the GT-N7000 sources are UNSAFE unless the following condition is met:
  • MMC_CAP_ERASE is removed from the capability flags in drivers/mmc/host/mshci.c – check the kernel features for this. Franco.kernel R3 and later and all Speedmod ICS releases are SAFE due to this.
  • All SHW-M250S/K/L ICS kernels are suspected to be UNSAFE
  • All SHW-M250S/K/L ICS source releases as of this date are UNSAFE (SHW-M250L Update4 was the cause of the SiyahKernel 3.1rc6 incident. Other Siyah releases are SAFE)
  • All SPH-D710 ICS releases as of this date are UNSAFE – Rumor has it that the official OTA may have a fixed kernel, but it is recommended to consider this kernel UNSAFE until source code is released and can be reviewed.
  • The SGH-I777 UCLD3 leak is UNSAFE, as is most likely every other leak for that device. Fortunately nearly everyone is using I9100 Update4-based custom kernels.

I9100 users are safe, as their source code and ROMs are completely safe and their kernels do not allow the conditions for the brick bug to be met. They do not have MMC_CAP_ERASE, so they are safe. Many others are not. Most custom kernels for the AT&T Galaxy SII I777 are based on I9100 source code, so they should all be safe. Still, be careful. So if you’re running a safe kernel, no unsafe recovery or ROM can brick your phone. Note users have a lot to be worried about, and need to be very careful. Make sure to ALWAYS run a safe kernel, I’m sure you can find one. And Sprint SII D710 users are the most unsafe, as they can’t do anything to stop it. Tread carefully, and you may have to give up ROM flashing for the time being.

If you’re worried (as you should be), hit all the source links for some both detailed and easy reading. Keep yourself safe, and always make sure what you’re flashing is safe. As an I777 user, I immediately brought this up to our devs, and they (including Entropy) have confirmed that our development is currently safe, for the most part. Please do the same with yours. Just don’t flood any threads, search and make sure it has been brought up. Good luck.

Entropy’s Analysis On Different Phone Models, Less Technical Writeup Of The Brick Bug By sfhub, Technical And Detailed Explanation And Discussion Of Brick Bug By sfhub

Tags: , , , , , , , , , , , , , , , , ,