Another Way to Detect the Infamous Brick Bug
We’ve been bringing ongoing coverage of the Samsung hard brick bug that’s affecting a large number of users. For those unfamiliar, the hard brick bug causes complete and irreparable damage to the eMMC storage device. It came about when the first leaks to ICS on a variety of Samsung devices were released, and they’ve been a problem ever since.
One way users have been keeping track of if they’ve got the brick bug is Chainfire’s Got Brickbug application, which determines if you have good or bad hardware. There has been another way to determine if you have the brick bug if you have the Samsung Galaxy S II. XDA Senior Member Tungstwenty has released a script that helps further determine whether or not users have the brick bug. According to XDA Elite Recognized Developer Entropy512, who continues to be on the forefront of the battle versus brick bug, it functions differently than Chainfire’s app. Entropy512 states:
It detects a different component of the brickbug – Chainfire’s detects bad chips, this will detect some kernels that allow dangerous commands through to chops.
However, all is not well. Due to the way it detects, there’s a very decent likelihood that that it can deliver false positives and false negatives. Again, Entropy512 explains:
It will likely deliver some false positives and false negatives as it’s checking compiled binaries and not source. If anything near the place where MMC_CAP_ERASE is set changes, it may lead to false negatives for example.
So while it is a very helpful tool, it is unwise to declare your device safe or dangerous strictly on what this application says. Given that it has the capacity to deliver false positives and false negatives, it could come up clean even if you have the brick bug. It is used best along with Chainfire’s application (linked above) to double check. If you are still unsure after both tests—and with a bug this dangerous you likely should be—then it’s much better to simply act as though you do have the brick bug. Better safe than sorry.
The second part of Tungstwenty’s thread explains how to patch the issue if you do appear to have it. While this has the capacity to work, once again Entropy512 drops words of wisdom:
If the patch fails, it could lead to users thinking they are safe when they are not. Instead of patching the code segment to render a kernel safe, it may instead just patch some other part of the kernel introducing a bug without rendering the kernel safe. Also, since the modification will trigger the flash counter/modification detection mechanisms, there is not much point in doing this as opposed to just building a kernel from source.
So, once again, if you do decide to try this out, do so with the utmost caution. Both the test and the patch could fail, and if that happens, you could end up bricked. This should not be mistaken as bad development. It is absolutely not bad development, and the script could very well be used to help determine if the brick bug is present. However, using the utmost caution is never a bad idea. Currently, Entrop512 and others are in direct contact with Samsung to get the problem permanently fixed.
For more info, check out the original thread.
[Photo was jacked from egzthunder1’s fantastic article on the brick bug. Also, big thanks to Entropy512 for the consultation.]