[05.09.2012] Got Brickbug ? v1.2

Search This thread

andreww88

Senior Member
Aug 6, 2011
1,301
297
Mobile, AL
www.andrewsthoughts.net
So flash last GB, wipe data, flash ics? Cool.


Excellent tip Chainfire ;)
Thx

Or just flash last GB and stay on it and don't worry about flashing ICS.

---------- Post added at 04:08 PM ---------- Previous post was at 04:07 PM ----------

Is this only effecting Samsung ROMs or CM9 source as well?

Should I stop flashing Nightlys until the day or 2 later to make sure everything is okay?

CM9 ROMs and kernels are SAFE. You do not have to stop flashing the nightlies. The Samsung official and leaked ROMs and kernels are the faulty ones. Franco and Speedmod kernels are safe as well.

---------- Post added at 04:10 PM ---------- Previous post was at 04:08 PM ----------

my SII is 0x19 so I've tried to read abot this issue but i didn't understand anything actually :( could anyone explain the issue and how to avoid it ? :confused:

The emmc bug is on the official and leaked Samsung ROMs and kernels. On the Note, CM9 is safe. I'm not sure which ROMs are safe for SII but I'm sure CM9 is one of them. Avoid wiping data on the Samsung ROMs, or in my opinion, avoid Samsung ROMs entirely.
 

KennyLegend

Senior Member
Jan 13, 2011
5,785
1,193
Cork
cfdb4591-6eec-1400.jpg


+1 I heard the only way to find out is by reading the bad sectors which in turn would then brick it.

Sent from my GT-N7000 using Tapatalk 2

This is interesting..... if u flash a stock GB rom, do u then, in theory, make the corrupted sectors if any good again? A question for Chainfire me thinks ...

Sent from my GT-I9100 using xda premium
 

Namida

New member
Jul 5, 2010
2
10
A method called JTAG bit blasting, which is supposed to bypass all but hardware issues, is known not to work.

Flashing a rom probably won't fix any sectors. I'm sure people have tried it and if it worked XDA would be awash with posts jumping for joy over the relatively simple fix. My understanding is hazy, but the eMMC chip seems to get corrupted internally because its wear leveling code is bugged. Wear leveling is low level stuff independent of write methods used during a flash. It can be recovered, but the code to do so is only known to developers who aren't permitted to share it.

Source: http://xdaforums.com/showpost.php?p=26255080&postcount=159

Incidently, chainfire had already provided a link with tons of background on this issue including a link to this very post that says:

As I mention above, the revision 0x19 firmware had a bug that after an emmc erase command, it could leave the internal data structures of the emmc chip in a bad state that cause the chip to lock up when a particular sector was accessed. The only fix was to wipe the chip, and update the firmware. I have code to do that, but I don't know if I can share it. I'll ask.
 
Last edited:

andreww88

Senior Member
Aug 6, 2011
1,301
297
Mobile, AL
www.andrewsthoughts.net
A method called JTAG bit blasting, which is supposed to bypass all but hardware issues, is known not to work.

Flashing a rom probably won't fix any sectors. I'm sure people have tried it and it it worked XDA would be awash with posts jumping for joy over the relatively simple fix. My understanding is hazy, but the eMMC chip seems to get corrupted internally because its wear leveling code is bugged. Wear leveling is low level stuff independent of write methods used during a flash. It can be recovered, but the code to do so is only known to developers who aren't permitted to share it.

Source: http://xdaforums.com/showpost.php?p=26255080&postcount=159

Incidently, chainfire had already provided a link with tons of background on this issue including a link to this very post that says:

Yeah, the Android Developers, like Mr. Sumrall, have the means of fixing the emmc chip by basically reformatting it (bad terminology) but Samsung hasn't given permission to release it yet.
 

BrandoHD

Senior Member
Aug 28, 2009
1,560
433
Arima
CM9 ROMs and kernels are SAFE. You do not have to stop flashing the nightlies. The Samsung official and leaked ROMs and kernels are the faulty ones. Franco and Speedmod kernels are safe as well.

The emmc bug is on the official and leaked Samsung ROMs and kernels. On the Note, CM9 is safe. I'm not sure which ROMs are safe for SII but I'm sure CM9 is one of them. Avoid wiping data on the Samsung ROMs, or in my opinion, avoid Samsung ROMs entirely.

You are advising people to stay away from Samsung ROMS, are you sure this is correct?

Is this issue not a Kernel issue, therefore the ROM is of no consequence, but the kernel/recovery is what is really responsible for the issue

As far as my understanding goes, and from reading in the relevant thread that is dealing with this issue, ROMS were never discussed, Kernels were, you can use any ROM you like, the fix is at a kernel level

On another note, since Chainfire was able to release this tool that can check if your hardware is the one affected, is it at all possible to release a tool that can check to see if the kernel you are running has the dangerous code disabled???
 
Last edited:
  • Like
Reactions: royskeyz

stephencwl

Senior Member
Apr 25, 2006
382
33
Bingo! I got the bug! ha ha. Thanks for letting me know.

Sent from my GT-N7000 using xda premium
 

Namida

New member
Jul 5, 2010
2
10
It's important to understand that the source of this problem is bad firmware in the eMMC chip. There is nothing technically wrong with the kernel itself. The eMMC claims to support a method of erasure that causes it to write bad data when it's used.

To achieve safety, you either fix the chip so that it supports the method it claims to properly or avoid using that method of erasure.

Cyanogenmod 9 is safe because it doesn't erase using that method. They use their own kernel built from their own source code.

Samsung ICS kernels are not safe because they call the best method the eMMC claims to support when erasing, which is bugged within the chip's firmware.

Anyone who uses the official Samsung ICS kernel or the ICS leaks of Samsung's kernel are at risk. Chainfire's kernel is risky because Chainfire uses Samsung's official kernels and adds Clockwork Mod to them at the binary level. He doesn't have source to modify to make his kernels safe. Samsung must make their kernel safe before Chainfire can release a safe one himself. What Chainfire has done is modify the recovery so that it won't ask the kernel to erase the eMMC in a potentially dangerous way, but it won't stop sources other than that recovery from asking for a potentially bricking erase operation because the kernel hasn't been modified and will still do it if asked to.

Because we know something of which versions of the eMMC chip are affected by this flaw, we can determine if a user is at risk simply by asking the chip to identify itself.

Decompiling a kernel is a completely different ball of wax. I wouldn't hold my breath for a tool that can do that and identify if your kernel is patched or not. Besides that, the source of the problem is now known with certainty and can be avoided by not flashing Samsung kernels until Samsung gets off their lazy butt and fixes theirs, or provides the code that can be used to fix the eMMC chip that is the source of all our troubles.
 
Last edited:

nipuna

Senior Member
Aug 24, 2010
209
53
@CF: i know this prolly is asking too much, but is there a way u could scan for bad sectors? Could u possibly have such a tool?

@others, just coz u hv this firmware doesnt mean u r bricked, if u been using a safe kernel. My device got fried, n it only came evident whild trying to go back tl gb via odin.

Replacement i got under warrenty has been running happily under CM9 and official ICS with Speedmod.

Sent from my GT-N7000 using XDA
 

aneeqkhan

Senior Member
Nov 23, 2011
534
92
Karachi
74473913-c27f-ac60.jpg


I have an unknown chip see the screenshot. Now dont know should b happy or not... :confused:
Sent from my GT-I9300 using Tapatalk 2
 

andreww88

Senior Member
Aug 6, 2011
1,301
297
Mobile, AL
www.andrewsthoughts.net
You are advising people to stay away from Samsung ROMS, are you sure this is correct?

Is this issue not a Kernel issue, therefore the ROM is of no consequence, but the kernel/recovery is what is really responsible for the issue

As far as my understanding goes, and from reading in the relevant thread that is dealing with this issue, ROMS were never discussed, Kernels were, you can use any ROM you like, the fix is at a kernel level

On another note, since Chainfire was able to release this tool that can check if your hardware is the one affected, is it at all possible to release a tool that can check to see if the kernel you are running has the dangerous code disabled???

I'm saying avoid Samsung roms, absolutely. Yes, it is only the Samsung kernel. But, it is easier to just avoid the entire Samsung official ROMs for noobs.

The franco and speedmod kernels are stock (kinda) and they just disabled the MMC_Cap_erase code. So, they are pretty safe. If you HAVE to run a Samsung rom, you can flash one of these kernels. I was just making it easier on users.

---------- Post added at 10:38 PM ---------- Previous post was at 10:37 PM ----------

I have an unknown chip see the screenshot. Now dont know should b happy or not... :confused:
Sent from my GT-I9300 using Tapatalk 2

That's odd. Probably a good thing. You might have a Note that is a rare bird without the faulty emmc chip firmware.
 
  • Like
Reactions: k!DDa

jon3sh

Senior Member
Sep 17, 2009
2,426
588
Damn my Note shows VYL00M brickbug too:(

Sent from my GT-N7000 using xda premium
 

rebista

Member
Nov 26, 2011
46
9
And the next thing we would need is an app that shows if parts of the chip are already corrupted

+1 I heard the only way to find out is by reading the bad sectors which in turn would then brick it.

Sent from my GT-N7000 using Tapatalk 2

Why would it brick it? IMHO you would get an IO error.
Of course it depends on how the access function works, what it does when reading. I am by no means an expert here.
But as far as I know the bricks happen because something at the beginning of the chip gets corrupted (where the toc of the chip sits), which makes any other future operation fail. When accessing the chip sector by sector, reading it, nothing should be written. Therefore no brick.
But maybe that's a too simplistic view :) maybe something is written.
But this would increase the danger even more because that would mean as soon as a sector is bad by erasing something on it every future operation on it could cause a brick. That'S the point where everyone turns to CM9 ...
 
Last edited:

KennyLegend

Senior Member
Jan 13, 2011
5,785
1,193
Cork
Or just flash last GB and stay on it and don't worry about flashing ICS.

---------- Post added at 04:08 PM ---------- Previous post was at 04:07 PM ----------



CM9 ROMs and kernels are SAFE. You do not have to stop flashing the nightlies. The Samsung official and leaked ROMs and kernels are the faulty ones. Franco and Speedmod kernels are safe as well.

---------- Post added at 04:10 PM ---------- Previous post was at 04:08 PM ----------



The emmc bug is on the official and leaked Samsung ROMs and kernels. On the Note, CM9 is safe. I'm not sure which ROMs are safe for SII but I'm sure CM9 is one of them. Avoid wiping data on the Samsung ROMs, or in my opinion, avoid Samsung ROMs entirely.

You forgot to mention Siyah kernel is now safe as well on the S2..
On Siyah MMC_cap_erase = 0.

Sent from my GT-I9100 using xda premium
 
Last edited:

rev.pragon

Senior Member
Feb 9, 2010
82
9
Silly question maybe but: if the chip is the same or not the problem isn't it possible to overwrite the x19 firmware with a safe firmware?

Sent from my GT-N7000 using xda premium
 

KennyLegend

Senior Member
Jan 13, 2011
5,785
1,193
Cork
Silly question maybe but: if the chip is the same or not the problem isn't it possible to overwrite the x19 firmware with a safe firmware?

Sent from my GT-N7000 using xda premium

It has already been mentioned that it IS possible but Samsung haven't released the permission yet.

Sent from my GT-I9100 using xda premium
 
Last edited:

Top Liked Posts

  • There are no posts matching your filters.
  • 424
    As you are all probably aware, the SGS2 and SGNote variants suffer from a bug that may brick your device when a certain erase method is used.

    A thread with a lot of background about this issue can be found here:
    http://xdaforums.com/showthread.php?t=1644364

    Attached is a simple APK that reads out your chip's type and CID, and lets you know if we know that chip is dangerous or safe.

    Just uninstall again after using.

    Most SGS2's and Note's have "bad" chips (its actually the firmware that's bad). This is only dangerous if your kernel is dangerous as well. Gingerbread kernels are usually OK, Samsung ICS kernels are usually (bad on Note, good on SGS2 if released before July), custom ICS kernels: look in the kernel's thread. This is a simplification. See Entropy512's excellent post with some further details about which kernels are what.

    Obviously, this comes "as-is", we're not responsible what you do with your device, etc. No rights can be derived from the output of the program!

    Internal data used:
    MAG4FA, VYL00M, or KYL00M fwrev 0x12 || 0x19 --> known bad
    MAG4FA, VYL00M, or KYL00M fwrev >= 0x25 --> probably safe
    MAG4FA, VYL00M, or KYL00M fwrev != 0x12 && != 0x19 && < 0x25 --> probably bad
    M8G2FA, MBG8FA, MCGAFA, VAL00M, VZL00M --> probably bad (mentioned in patch code)
    Everything else: unknown chip

    News - 08.06.2012
    Samsung: "Patches will be out in form of new official ROMs and also sourcecode releases after testing, which might take some time."

    Changelog
    05-09-2012 - v1.2
    - Added chips mentioned in patch code ( http://xdaforums.com/showpost.php?p=31124285&postcount=785 )

    08.06.2012 - v1.1
    - fwrev 0x12 is also known bad

    (v1.0: 6750; v1.1: 34315)
    134
    It would be beneficial to provide more information on the brick bug to avoid some people getting unnecessarily scared (such as most I9100 users).

    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 0x11 (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

    As of June 6, 2012, this is what I know as far as kernels that meet condition 3:
    • All GT-I9100 ICS leaks and official releases prior to July 2012 are SAFE (MMC_CAP_ERASE not present)
    • New GT-I9100 ICS leaks and official releases (starting in July 2012) are UNSAFE - That's right, Samsung ADDED the trigger conditions for this bug to newer releases such as XXLQ5. So much for "we're working on a fix"...
    • 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.
    • SGH-I727 and SGH-T989 ICS leaks are UNSAFE - However as these two devices use separate recovery and operational kernels, if you have a Gingerbread recovery/kernel, you should be safe regardless of what you are booting for normal operation.

    It's hard to get ALL of the cases and evaluate them, but in general in terms of levels of danger (As of June 6, 2012 - this could change with time):
    SPH-D710 users are in the most danger - They have no official ICS releases AND the I9100 Update4 source base can't be used to build a usable kernel for their device without major developer work
    GT-N7000 users are second on the list - They are the only ones outside of Korea to receive official ICS updates that trigger the eMMC firmware defect. However, I9100 Update4 sources required only minor work to create "safe" kernels, and developers know the proper procedure for rendering the official N7000 Update3 source drop "safe"
    SGH-I777 users are next - I777 leaks proved to be dangerous a month or so ago. However, the SGH-I777 required the least amount of work to be able to use the GT-I9100 Update4 source base, and as a result, with the exception of the leaks themselves, nearly all I777 ICS kernels are based off of safe source code bases.
    GT-I9100 users are in the least danger - No leak, official binary release, or source code release for this device has been dangerous. Only one I9100 kernel has ever proven dangerous and that was quickly pulled by its developer.

    I am not evaluating the SHW-M250S/K/L in the above list, as while I know their source and binaries are dangerous, the language/culture barrier means we have very little information on how this fiasco is panning out for those users.

    UPDATE:
    We have at least one confirmed report of this bug occurring with KYL00M fwrev 0x12 on a Samsung Skyrocket (SGH-I727) with their ICS leak kernels
    In addition, Samsung Hercules (SGH-T989) has the same fwrev and I've been told that they have observed bricks of this type with their ICS leaks

    UPDATE 2:
    I've received an email from a contact at Samsung who has indicated they are working on some sort of fix to be deployed to devices with an "UNSAFE" configuration listed above. I have requested that I receive an explicit list of which binary builds contain this fix, as without that I cannot know for sure which builds are fixed and which are not. Fixes are not yet deployed to affected devices.

    UPDATE 3:
    So much for the claims of working on a fix above... Not only have fixes not been deployed to any kernel for any device I am aware of, but Samsung added the trigger conditions to the XXLQ5 build for GT-I9100. Yes, that is correct - a device previously unaffected by this bug is now UNSAFE.
    23
    Hi fellow Androidians, how about a worldwide petition letter to Samsung. Below I've made a draft, feel free to amend accordingly.

    Yeah, because *that* is going to help :rolleyes:

    We already know Samsung is working on this. We know how to fix the problem in custom kernels. We know Samsung replaces devices that are bricked this way.

    Also, technically the chip isn't faulty, the chip's firmware is faulty. The problem is that updating the firmware on those chips is a really nasty affair you really don't want end-users to be doing, unless it has gone through some very rigorous testing.

    What possible use would it be to exchange all the Note's out there with new models with fixed firmwares, if they can just as well release a software update (that we know they are working on) that accomplishes the same thing ?

    What exactly do you want to happen here, aside from wasting a metric ****ton of Samsung's money, which we'll all have to pay extra on the next device to recuperate these funds ?

    This problem is something us "tweakers" need to be aware of for now, until it is fixed. Normal users will rarely if ever even run into this issue, and if they do, Samsung will replace the unit under warranty. Us tweakers have been warned, we know how to work around it, and we know a fix is coming - what could you possibly want beyond that ?
    18
    is this something you want us to run to collect the results or is it for our own information? :)

    It is for your own information... there's no testing involved or anything, it just pulls some info from the device, and shows it on screen for you.
    10
    It's important to understand that the source of this problem is bad firmware in the eMMC chip. There is nothing technically wrong with the kernel itself. The eMMC claims to support a method of erasure that causes it to write bad data when it's used.

    To achieve safety, you either fix the chip so that it supports the method it claims to properly or avoid using that method of erasure.

    Cyanogenmod 9 is safe because it doesn't erase using that method. They use their own kernel built from their own source code.

    Samsung ICS kernels are not safe because they call the best method the eMMC claims to support when erasing, which is bugged within the chip's firmware.

    Anyone who uses the official Samsung ICS kernel or the ICS leaks of Samsung's kernel are at risk. Chainfire's kernel is risky because Chainfire uses Samsung's official kernels and adds Clockwork Mod to them at the binary level. He doesn't have source to modify to make his kernels safe. Samsung must make their kernel safe before Chainfire can release a safe one himself. What Chainfire has done is modify the recovery so that it won't ask the kernel to erase the eMMC in a potentially dangerous way, but it won't stop sources other than that recovery from asking for a potentially bricking erase operation because the kernel hasn't been modified and will still do it if asked to.

    Because we know something of which versions of the eMMC chip are affected by this flaw, we can determine if a user is at risk simply by asking the chip to identify itself.

    Decompiling a kernel is a completely different ball of wax. I wouldn't hold my breath for a tool that can do that and identify if your kernel is patched or not. Besides that, the source of the problem is now known with certainty and can be avoided by not flashing Samsung kernels until Samsung gets off their lazy butt and fixes theirs, or provides the code that can be used to fix the eMMC chip that is the source of all our troubles.