yashsingh1/xdaforums huggingface dataset:
[Galaxy Note GT-N7000 General] friedje:
Sigh, deleting large files does not trigger the bug.

Now that ICS is out for the tab 10.1 it is dangerous and vulerable too.

It uses the same chip with x012 fw. Fw hs been fixed in fw x025.

Furthermore it is likely that issuing a data reset without root and being on stock recovery is not a problem.

For now there is no hard evidence that it is...

So the only ppl concerned for now are flashers like us and for those it isn't a big deal to flash a stock rom and unroot your device before wiping and selling it.
[Galaxy Note GT-N7000 General] hagba:
Samsung is asking $350 to replace the motherboard! , it was Superbricked while wiping, will put it on Ebay for a $100, for a phone I payed $770, anyway there won't be another Samsung for me anymore.
[Galaxy Note GT-N7000 General] azzledazzle:
Dont you have warranty ? If so they will repair for free, Unless they can prove its fault lies with you / modified software
[Galaxy Note GT-N7000 General] Chrissssssss:
Thinking of getting a Note towards the end of the year, unless the Note 2 is much better. Is the problem fixed on newer phones? Someone earlier seemed to suggest so.
[Galaxy Note GT-N7000 General] friedje:
We will know once the phone is released won't we ?

For now only a fortuneteller could help you ;)

But in the Nexus the Bug is fixed, dunno for the S3, you might take a look in their forum.
[Galaxy Note GT-N7000 General] Chrissssssss:
Ha, I didn't mean is it fixed on the Note 2 :) I meant newer Notes. If I get a Note 1 now will it have this bug.
[Galaxy Note GT-N7000 General] friedje:
I guess the risk is about 99.99%

Haven't seen one around yet using a newer chip.

Not even the ones that had the motherboard replaced under warranty
[Galaxy Note GT-N7000 General] Entropy512:
How is this new information? We've known for months the chip had a defect. Samsung admits it has a defect.

HOWEVER - Samsung did not sell us an eMMC chip. They sold us a phone. Their belief is that the configuration they sold is does not have issues - because their software, as provided, does not issue secure erase commands, only non-secure erase/TRIM.

The question remains - is nonsecure erase safe? We've seen reports of people claiming that they suffered damage from it, but so far not many, and since those people bricked on what they claimed was "stock", they were able to just send their devices for warranty service.

The other interesting thing I'm pursuing is whether Samsung's storage division notified their direct customers (such as Amazon and Acer) of this defect. Acer A510 and A700 tablets have defective chips - I'm going to try and get info on whether the recovery binaries on these devices use secure or nonsecure erase. If they use secure erase, Samsung's storage division was negligent in notifying Acer of the defect.

It may possibly end when they deploy the kernel patch we've been discussion - whether it ends depends on whether Samsung is right in their belief that nonsecure erase is safe. (The proposed patch will take any attempt at issuing a secure erase command and replace it with nonsecure erase.)

Once there is kernel level protection against secure erase - if any bricks happen with those kernels we'll know once and for all whether Samsung was right.

Problem is that willingly reproducing this bug, even with secure erase, is difficult. With nonsecure erase, it's so rare that you only see it when scaling up to thousands of users. Also, even with secure erase, once you've successfully wiped without damage, you're far less likely to experience damage if you wipe the same partition again. (In fact you almost surely will not experience damage if you wipe a second time without writing to the partition.)

GB team didn't take care of anything - Issuing erase commands when a partition is wiped is a new feature in ICS. Gingerbread recoveries, from any origin I am aware of, do not issue erase commands.

Deletion of large files being potentially dangerous was speculation months ago back when there was far less knowledge and understanding of this bug. In all currently known configurations, it turns out that's safe.

This could change IF both of the following prove true:

Samsung enables the "discard" mount option for their filesystems - this will likely happen as one of their reasons for leaving MMC_CAP_ERASE enabled is so this will work. (They have some serious internal communications problems, since the "discard" mount option is not in use in any shipped configurations...)

Samsung is wrong about the safety of nonsecure erase

So far, some I9100 users have received units with new eMMC chips that seem immune. I have yet to see a report of an N7000 unit with an "unknown" or "safe" eMMC chip - only "defective" chips.
[Galaxy Note GT-N7000 General] azzledazzle:
First of let me start by saying im completely baffled by all the posts in this thread, I have no idea what half (ok, ALL ! ) of it means.

What I struggle to come to terms with is:

Is it possible that Samsung could make this whole situation 'safer' than it is now, With the safe kernels we have and the safe (Chainfire's) CWM recovery ?

I find it hard to believe that Samsung could let this go un-noticed, I always imagined Samsung to be 'Developer Friendly' Considering they release the source code almost immediately (even before release with the SGS3) and dont put much security on their devices (like HTC with their ridiculous Security protected NANDs)

Within weeks of the Notes release this issue was discovered and 'Fixed' by people on XDA, Making it safe to do full wipes ect ect.

It really makes me believe that Samsung have sh!t for brains when its 12 months later and they still havent released a 'safe' stock ICS kernel, Yet XDA devs are finding alternative ways around these issues almost every day.

They really ought to be employing people from these forums as their current staff seem incapable of just about anything.

Oh and also, This issue also affects SGS2 users right ? And that device was released waaaaay before the Note, Surely they would have known NOT to do the same thing with this device ?

Rant over :) Ive seen Samsung in a new light now, That being said, It wont deter me from purchasing the Note 2 or SGS4 :p

It just goes to show how these 'corporate giants' are nothing more than legalised thieves ! Daylight robbery ! Take your money and chuck you in the dirt.
[Galaxy Note GT-N7000 General] indiandroid:
I am ready to buy it. Kindly PM me the details :)
[Galaxy Note GT-N7000 General] dentalguru:
Making sense to a laymen

In the above 3 post finally , whew finally it made sense = to be very safe avoid any form of wipe.
[Galaxy Note GT-N7000 General] FerretAD:
Please tell me you're kidding :(

I've only just got myself the A510, less than a week old, to now find it's also got a defective chip - 2 devices with potential to brick, great :(

EDIT: Just run Got Brickbug? and got this:

eMMC chip

Type: MBG8FA

CID: ...........................

Revision: 0x21
[Galaxy Note GT-N7000 General] PoisonWolf:
In my mind, the way to reproduce this code.....is to run a completely stock phone. Then boot it up, go to the market, and download till phone's 2gb data partition is filled up. Then go to stock recovery and wipe. If your phone is still alive after wiping 2GB of data, boot up the phone, and reconnect to the market...and redownload 2GB worth of apps again, and repeat the process until it bricks.

I'm not sure which is more painful, the bricking, or the time needed to do this experiment. Without root, filling up 2gb of the data partition is a real PITA. Would Google's App backup work in this scenario?

Thoughts? Would this work in getting the phone to "brick"? I mean, if the way the bug is trigged is dependent on the probability...and other conditions, then in my mind, a logical approach would be to wipe with a partition that is almost full.
[Galaxy Note GT-N7000 General] Entropy512:
That's the same as other users - previously unknown chip, but confirmed affected.

Nope... For even the secure erase bug, that wouldn't necessarily put the eMMC into the correct state for damage... I unfortunately have been asked not to reveal the specific details, but I will say it's more consistent with typical long-term data partition usage. It doesn't always require long-term usage (see xplodwild's brick 4 hours after unpacking), but it's more likely.

There's also a good chance that if damage occurs with nonsecure erase, it's a DIFFERENT firmware bug than the one affecting secure erase. (In which case it might even be present in newer chips.)
[Galaxy Note GT-N7000 General] Rukmalranaweera:
I cant understand these electronic terms.

Please Tell me Will Samsung can Fix this eMMC bug without replacing the motherboard ?

Do we have a Hope ?????????? :confused:
[Galaxy Note GT-N7000 General] chasmodo:
Yes, they will fix it at kernel level. And stop shouting.
[Galaxy Note GT-N7000 General] kromosto:
it depends on what you think fix is. if you think preventing manually or automaticly triggering the bug is a fix then again if what samsung claims is true yes they can fix it without changing the motherboard.
[Galaxy Note GT-N7000 General] friedje:
trollmode on/

Yes you need to delete the driver on your pc and reinstall it :)
[Galaxy Note GT-N7000 General] Braxos:
I don't know that girl named Hope. I know a girl called Lace she works on a service center of Samsung. Her name is a shortcut of replace of only if you have warranty.
[Galaxy Note GT-N7000 General] :
@Entropy512

In response to my GB Team vs. ICS team you wrote:

"GB team didn't take care of anything - Issuing erase commands when a partition is wiped is a new feature in ICS. Gingerbread recoveries, from any origin I am aware of, do not issue erase commands."

My question is why this newly introduced erase commnand in ICS hasn't had any ill effects on other phones from the rest of the manufacturers? Am I right to think that is because Samsung has been using defected hardware since SGII which was shipped with GB?

I understand the particular hardware/component/controller is not replaceable hence the motherboard itself has to be replaced as a solution. If so, no wonder Samsung is desperately active in the forums to cause confusions and have avoided an official statement on the matter to save money. As a manufacturer I would be worried too to have my two most popular handsets on the market with hidden defects. It would be a PR disaster for Samsung if that turned out to be true.
[Galaxy Note GT-N7000 General] msedek:
Entrophy512 could you talk to pershoot(cm9 kernel developer) for gtab 10.1? We recently got a 3.1 version of the kernel with the new ics release for gtab I just did the test with emmc software and got this red circle translates chip in danger don't know if you want me to send you the zimage from the kernel or something as it's a new kernel 3.1 you could see if the mmc_cap_erase its still present... I want to help preventing ppl/developers to start bricking their tabs...
[Galaxy Note GT-N7000 General] dsmas:
And simple doubt by a layman. When the emmc, ug is not invoked by gb, why in ics? How about in jb? so is it hardware issue or software thing
[Galaxy Note GT-N7000 General] chasmodo:
It is a hardware thing triggered by a software thing.
[Galaxy Note GT-N7000 General] friedje:
And Google decided that ever since ICS this will be invoked for security reasons.
[Galaxy Note GT-N7000 General] Randomwalker:
Just read Entropy's posts here in this thread. I find them highly educative and easy to understand, even from a non-technical background (w/o dumbing down the issue too much). That in my view is the real value of this thread.
[Galaxy Note GT-N7000 General] :
Its amazing, I guess the risk must be really low for them not to contemplate recall. Risk vs cost etc.

I wonder how random, so under which exact conditions the code is triggered to be send. Or is it send always? Also if its send always what triggers tue corruption why so random.

There are other device threads on this as wel btw.

Gues the emmc chip was wrongly tested.
[Galaxy Note GT-N7000 General] lhbalesjr:
It hurts when I do this

I don't know anything about any of this from a tech point of view, but if I'm understanding this correctly, it looks like Samsung's is playing the part of the doctor in this old joke:

"A man goes to see his doctor and says ‘Doc, it hurts when I do this” and the doctor says “Then don’t do that”

My question is this: After a fix is released, it will most likely be that the erase method that is causing the problem will be disabled. Is that method necessary for the proper operation of the phone? For example, lets say you are ready to upgrade and want to sell your phone, but want to make sure that any sensitive data is completely erased. Assuming that you were using stock ICS ROM as provided by the manufacturer, would you be unable to perform this secure wipe? I do understand that you can revert back to GB to do this, but to do this would require that you do something to your phone that could result in denial of a warranty claim if anything went wrong. In other words, when all is said and done, will it be possible for a typical non-technical user to do a secure wipe without doing something that could also void the warranty?
[Galaxy Note GT-N7000 General] foxmeister:
My understanding is that the risks are extremely low (if not zero) if you are running stock ROM, kernel, and recovery.

Assuming this is the case, Samsung has no need to contemplate a recall since running a non-stock ROM, kernel, or recovery, would mean that you've effectively voided your warranty.

Regards,

Dave
[Galaxy Note GT-N7000 General] Entropy512:
It requires:

1) A defective eMMC chip. Initial Galaxy Nexus prototypes apparently had the same chip we do, and they were blowing up right and left when Google added the wipe code. Google had Samsung put updated chips without this defect in the GNex. I'm not sure if Google was aware that Samsung was already shipping these defective chips on a massive scale (all of their current phones, and also to other manufacturers like Acer and Amazon.) You can throw erase commands (even secure erase) at newer Samsung chips all you want - same for chips from other manufacturers.

2) A recovery that issues secure erase commands - By default, recovery in ICS and later will do this. It is still questionable as to whether nonsecure erase causes problems. Samsung insists that nonsecure erase is safe - we've seen some conflicting evidence to this claim but not enough to convince them. Plus if it comes out that nonsecure erase is dangerous, Samsung will then likely have to issue a recall because that will indicate that they shipped a defective configuration. (As opposed to "a configuration with a defect that will never be triggered unless modifications are made")

3) A kernel that allows secure erase commands through. This is default behavior, Samsung removed it from the I9100 kernels but not N7000. After my meeting with them, Samsung is working on a kernel patch that will replace secure erase (undoubtably dangerous) with nonsecure erase (questionable safety).

You are correct - While it is possible to update the eMMC firmware, it has a very high failure rate, and update failure = completely and totally toasted chip. As a result, even damaged chips are treated as a lost cause by Samsung and the whole mobo gets replaced.

Pershoot is aware of this fact, he removed MMC_CAP_ERASE as a safety measure from his kernels a while ago. Also, the nice thing about the Tab 10.1 (along with the T989 and I727) is that they use separate recovery and operational kernel images - so you can have a stock ICS kernel installed, but still have a source-built custom recovery.

Correct. Just formatting a partition can leave personal data in a recoverable state. Secure erase deletes the data and any copies left by the wear leveller.

This is Samsung's current position - We know that nonsecure erase is MUCH safer than secure erase, and Samsung believes that it's 100% safe. It's very rare for it to cause damage, however we've seen some reports of it doing so. Unfortunately, until the patch mentioned above gets deployed, it'll always be questionable. If any bricks happen with kernels that replace secure with nonsecure erase, then we'll know that nonsecure erase is dangerous, and Samsung is going to have a ****storm to deal with.
[Galaxy Note GT-N7000 General] :
Thank you very much for your time answering my questions, as well as others.

In my opinion your excellent explanation in above is something Samsung should be very worried about now. I also have a new concern that would like everyone to be aware of as its magnitude hasn't been realised yet even though the information has always been there but lost in detailed technical discussions.

Obviously it is Google's intention to make sure Android OS can be adapted and used at Enterprise level. To do so increasing security is an assurance for the adaptation for instance. As it was stated before, by members, a secure wipe [problem] ensures no data can be recovered at later time. This is important for any Android users, not just Enterprise users, as at one point the device is either sold out or given away when no longer is needed. As you can guess by now the secure wipe is very important feature to have.

Samsung knowingly carried on manufacturing and selling GNotes when they knew eMMC chip they use is not capable of secure wipe command signalled by Android Recovery program. I have bought my GNote only two months ago and every eMMC checker reported it as containing the unsafe chip. A clear indication Samsung has decided not to change anything in, at least in N7000 model, Gnotes.

In my opinion there has been enough discussions on the technicality of the problem and now this is the time to hold Samsung accountable on two grounds; these are:

1. Knowingly carried on shipping a device that would be less secure on Android ICS version

2. GNote ICS based devices are less secure than other devices from Samsung and other manufacturers that did not use the same eMMC chip.

Given the lack of prior knowledge, to the security issue, at the time of my purchase I would have either skipped signing up a 24 months contract or may have chosen a more secure device.

I would contact my carrier to see if I can terminate my contract based on all the information given by XDA members.
[Galaxy Note GT-N7000 General] friedje:
Although i can understand your point of view,

you bought your note 2 months ago running GB,

and it was just as unsecure as it will be with a patched ICS kernel.

So frankly, you have no case...
[Galaxy Note GT-N7000 General] :
As long as Android version is used in the argument then it would be a little bit more difficult to argue. I purchased my GNote with pure intention and promise of Samsung's ICS ROM which was delivered within a couple of weeks after I purchased it. However, my main point is the handset is less secure due to defective eMMC chip than all equivalent handsets in the same price range and performance. If Samsung disclosed that information to the public I would not have purchased it. I don't mind to go through some stress to make my point and even going through dispute so I can legally stop the payments.

I'm fed up with the level of service I've been given as an Android user. I'm even amazed how many of XDA members think it is acceptable to be given defective devices that costs more than a powerful laptop. I paid less than £300 for my Acer laptop in early 2010, dirt cheap. I can't fault a single thing about this laptop and everything is working perfectly after constant heavy use. I have spent four times that money on Android devices and yet to be happy once.

5.3" screen size that was supposed to be amazing can't even be used to watch movies with for the banding problems. In fact the screen quality would be another point to discuss with my carrier. I waited for ICS update 4.0.4 to see if Samsung would correct the problem and they didn't so they can have it back as far as I'm concerned.
[Galaxy Note GT-N7000 General] friedje:
Yes you are frustrated and feel ripped off. However your post still doesn't make sense.

You had no idea that all android devices on GB were not safe, yet you bought those. You have no idea whether other manufacturers issue secure erase from their stock recovery, you are just assuming it...

Then you go completely off topic with the black clipping issue, which was

well known 2 months ago, yet you bought the note knowing the problem.

Samsung never promised they would fix that in ICS, again you assumed ??

Furthermore most ppl watch movies on the note without a hitch.

There are just some ppl that like to set their brightness at minimal level and then go and watch a movie in a darkroom just so they can yell at Samsung.

How perverted can the human mind get ?
[Galaxy Note GT-N7000 General] uwdus:
Bought mine last week with ICS pre-installed (4.0.3) and have a defective chip...
[Galaxy Note GT-N7000 General] Entropy512:
Note has never been marketed as having a full secure erase feature.

The addition of secure erase was done quietly in ICS, so Google hasn't really marketed it either. That's part of how this problem took so long to get resolved - it wasn't until Ken Sumrall mentioned that addition Google made to recovery (when asked why Gingerbread seemed safe despite the presence of MMC_CAP_ERASE) that anyone knew where in the source tree to look for changes beyond the kernel.

One thing: Nonsecure erase gets you 95%+ of the benefits of secure erase. Secure erase only makes a difference when you're up against an attacker who can bypass the wear leveller and read raw memory cells that have old copies of data the WL doesn't use any more - which either needs nonpublic documentation from Samsung that they are VERY careful about protecting, or decapping the chip in a lab.
[Galaxy Note GT-N7000 General] msedek:
Lol so what's the point on not disabling MMC_CAP_ERASE on kernels... If the info its more than secure it doesn't need a "secure" (bricking fking bastard command) erase.. Guess it's only money the reason of why they won't do it...
[Galaxy Note GT-N7000 General] Entropy512:
MMC_CAP_ERASE also disables non-secure erase.

That's the problem - If nonsecure erase is safe, MMC_CAP_ERASE will render it inoperable and potentially have performance impacts. (Specifically, write performance) - However, these performance benefits aren't too great and also, Samsung is not using the "discard" mount option that would cause nonsecure erase of files as they are deleted (this is done for performance reasons - flash write performance is faster if the wear leveller has pre-erased blocks to work with). The thing is that in this regard there seems to be some internal communications issues within Samsung - some of their engineers are positive that they are using discard (they're not), other engineers swear that all shipped I9100 kernels ship with MMC_CAP_ERASE enabled (they did not until July).

The problem is that enabling MMC_CAP_ERASE to allow nonsecure erase through also allows secure erase through if a binary that issues it is added to the configuration. (Binaries that issue secure erase commands are not part of any known Samsung configuration.)

Right now, and I need to follow up with my contacts on this, Samsung is working on a patch that leaves MMC_CAP_ERASE enabled, but goes down to a deeper level within the MMC driver and blocks secure erase while allowing nonsecure erase. It may also take secure erase attempts and replace them with nonsecure erase... I have mixed feelings on this, it's better to know that secure erase failed due to being not supported than to have it arbitarily replaced with a less secure form... In fact I should email my contact about this.

Once this improvement is deployed we'll find out if nonsecure erase is safe or not - if bricks completely disappear with these kernels, Samsung was right and nonsecure erase is safe. If bricks don't appear, we're right and it's not and Samsung has a huge problem on their hands.