yashsingh1/xdaforums huggingface dataset:
[Samsung Epic 4G Touch] squshy 7:
EDIT: just saw you wanted me to post this on here sfhub, I had already decided to post it here anyway lol. Here's what happened. I'm off today, so the experiment continues tomorrow.

-sigh-...Well, I tried all day yesterday to get a brick, but failed. Our engineers I'm in talks with at sprint aren't likely going to take action until I can get one. Given our discussions (which I can't paste here sorry), the feeling is that Samsung has left them largely in the dark about this bug. The one I talked to didn't even know about the France incident.

I performed about 20 hard resets, alternating between doing them in the recovery menu and ##786# hard resets. After about 15 resets, I started flashing back to EL29, then applying the FF18 update.zip, then hard resetting, to get more writes to /system and possibly inducing the bug.

The problem is that I won't be able to use anything third party (ROMs or scripts etc), otherwise they'll likely consider my brick as null, as having been influenced by something non-sprint.

But...play store apps would likely be considered fair game. Download ALOT of them in between hard resets? That'll give a little bit of data to write to /data
[Samsung Epic 4G Touch] garwynn:
will it get into download mode? and have you tried a jig?
[Samsung Epic 4G Touch] sfhub:
squshy 7, we were just having this discussion a little above your post:

Being xda, most of our experience inducing the brick have been with custom ROMs, which I understand is useless given the goal is to prove it happens with totally stock software.

Entropy put together a quick script to try and simulate conditions to trigger the bug. We aren't sure if it will trigger it, but we have to start somewhere. Give it a try and let us know how it goes.

http://xdaforums.com/showpost.php?p=28732307&postcount=703

Also could you get some info from your phone just on the off chance you have a newer EMMC firmware revision (type the BOLD commands in adb shell or terminal):

(root has nothing to do with the EMMC bug and you can remove it after getting your EMMC firmware info if you want)
[Samsung Epic 4G Touch] squshy 7:
I used chainfires "got brickbug?" app and it indeed confirmed it is a known bugged EMMC, I can't remember the numbers, I'll run those commands when I get in tomorrow.

EDIT: can't remember as I'm on CM9, but does FF18 include sprint ID? I have an idea, possibly...
[Samsung Epic 4G Touch] sfhub:
If you already confirmed your EMMC is affected then no need to do it again other than to record for posterity everything about your EMMC device in case we need it for a post-mortem.

I figured before starting the effort of bricking might as well do the basic sanity check, which you've already done.

Not sure if you are just asking whether stock FF18 includes Sprint ID or not. Stock FF18 does include Sprint ID.
[Samsung Epic 4G Touch] sfhub:
I had a chance to read the past few posts more closely.

This is just for discussion and NOT CONFIRMED yet, but based on your testing, the recovery provided by Samsung (on the platforms you've tested) is not doing secure erase operations. It would stand to reason then the update-binary they provided probably isn't doing so either since it is likely linked against the same libext4_utils.a.

This information coupled with the added information from Samsung that they feel only secure erase operations are compromised rather than all erase operations, would mean that Samsung HAS essentially delivered the "userspace" utility variation of the EMMC superbrick workaround. We would still need to verify that our recovery and update-binary do not call secure erase mirroring the behavior on the platforms you tested, which we can do using the logging you provided above on our source tree. We may find in testing our recovery and update-binary do call secure erase, in which case they wouldn't be safe, but if they match your experiences (and Samsung is correct that only secure erase is affected), then the userspace tools they delivered are safe.

So ASSUMING all that holds, they would have delivered a kernel which is exposed to the EMMC lockup issue (which we see from the source code) but userspace utilities which are safe.

Taking that a step further, that would also mean that the software Samsung has delivered will not trigger the EMMC superbrick bug. It is only userspace utilities compiled by 3rd parties like CM9/AOKP (recovery and update-binary) which when paired with the stock kernel will trigger the EMMC lockup.

I also now recall that a lot of the code with the secure erase was ifdef'd during the DISCARD source code merge and E4GT EL29 GB source actually had different #defines than other platforms, essentially disabling the ioctl calls for the secure erase. I need to go back and look at build parameters to see if the discard ioctls were disabled at a higher level than the mmc drivers. If it was, there is still a chance the kernel delivered is safe. Previously I had only looked at the low-level mmc drivers Garwynn provided.

Once again, all this is just for discussion. It is *NOT* a conclusion. There is work that needs to be done to confirm everything is as we understand and any misunderstanding can result in the whole theory being wrong.
[Samsung Epic 4G Touch] Entropy512:
This is pretty much it. Samsung seems to have chosen to "fix" the problem in userspace. The problems with this are:

1) There is mounting evidence that while non-secure erase is significantly safer than secure erase, it is not 100% safe. There have been too many reports across multiple devices of eMMC damage from stock recovery to say that it is safe. However it seems clear that the damage rate is much lower. That said, "lower" and "safer" are not acceptable. Only "100% unambiguously safe" is acceptable, and right now, the only way to guarantee that is to not fire erase commands at the chip.

2) There are too many ways to accidentally cause damage without kernel-level protection. When Samsung proposed to a number of developers that we fix this in userspace, we unanimously responded that anything but kernel-level protection was an unacceptable solution. We've deployed userspace solutions to many devices in addition - however relying on userspace solutions alone is too prone to mistakes, and it also means that Samsung's kernels are just one privilege escalation exploit away from a malware author permanently damaging many devices. While malware authors can already zero out the bootloaders, at least JTAG services and Samsung's service centers can repair that. What worries me is that despite claims that this damage can be repaired without physical modification, Samsung's service centers are still executing motherboard replacements at great cost to the user.

There's also the fact that they're doing a massive trim command (arg=1) and not erase (arg=0). If you read the JEDEC standard (which can be downloaded for free if you register with JEDEC, which is also free), there is language like this for secure trim/erase and trim, but not standard erase:

"Resetting a card (using CMD0, CMD15, or hardware reset for e•MMC) or power failure will terminate any pending or active Secure Erase command. This may leave the data involved in the operation in an unknown state." - While we aren't experiencing a reset or power failure, the process hanging for any reason would have the same result.

There's a possibility the lack of this warning for standard erase is just an omission (the standard erase section also has discussion of the other erase variants in advance of the dedicated sections for other erase types) - but the fact that there's a warning for that for every type of erase that has had problems seen worries me.
[Samsung Epic 4G Touch] sfhub:
IMO though this is the key to getting carriers and/or Samsung to look more closely. If you can demonstrate (which squshy 7 and the other user are trying to do) the EMMC brick using all stock, then they will pay more attention.

Otherwise Samsung's position will be we already fixed it in userspace and the carriers position is it only happens with non-standard software, so not caused by them, not their problem.

If there is mounting evidence someone should investigate, document and get the details assembled in a single location.
[Samsung Epic 4G Touch] Entropy512:
I've already linked to the last 3 reports of bricks in stock recovery that I found to my contacts at Samsung.

It's obviously one of those things that happens rarely, but does happen - making it difficult to reproduce. There's also the fact that many of us simply are not willing to sacrifice our device for an experiment like this.

If there were a robust repair method, it would be a different story - but there isn't and it doesn't look like there ever will be.
[Samsung Epic 4G Touch] sfhub:
Would you mind posting those links here also?

We have 2 people on this thread willing to force the issue of superbrick to prove to Sprint it happens. I believe at least one of them works for Sprint and has access to phones.
[Samsung Epic 4G Touch] Entropy512:
Tab 7.7 - http://xdaforums.com/showthread.php?t=1752468

I777 UCLE5 - http://xdaforums.com/showthread.php?t=1757972

I9100 XWLPM - http://xdaforums.com/showpost.php?p=28462386&postcount=675

Plus way back when N7000 XXLPY went live, user Robotu here and 3-4 others experienced damage from stock recovery.

Unfortunately, it's rare and intermittent enough that no one knows how to force it. My current guess is that it is only likely to happen if the eMMC has had a lot of write cycles since the last erase cycle.
[Samsung Epic 4G Touch] squshy 7:
Yes I do...it was unsuccessful again today, though it was admittedly busy..and I have inventory in the morning so I'll probably only be to commit half the day to it.

If I could take the phone home, I would, but with auditors in full swing, the last thing I need is to have an inventoried phone in my possession. So I'm confined to doing this at work. I tried my own little experiment today, tomorrow if I can I'll be running Entropy's data write script.

EDIT: Just out of curiosity, sfhub or entropy, with this userspace "hack" Samsung seems to have implemented, is it possible that data is not totally erased, I.e, could data be recovered after a wipe? If so...I'll wait for your answer
[Samsung Epic 4G Touch] sfhub:
I believe the regular erase just marks blocks as not having valid data which allows the system to reuse the block in a implementation specific way.

Secure erase actually specifies that a sequence of bytes be used to overwrite the area a few times prior to reuse.

I believe the concept is similar to the triple-write on your hard drive various bit patterns to really erase all traces of your previous data.

This is at the EMMC level. At the filesystem / OS level, I don't believe anything special is being done to ensure erased files are actually erased. I believe Android received some criticism for having your data laying around after a wipe data factory erase, and they chose to add a call to secure discard (followed by regular discard if that failed) whenever you format an ext4 partition.

Samsung appears to have determined the secure discard is problematic in their EMMC firmware and removed the first secure discard leaving just the regular discard.

So I would say the likelihood of your statement being true for Samsung EMMC on our phones is pretty good. The wear-level reordering may make it harder to reassemble complete data, but the fragments are probably still there if a secure discard isn't being performed during the factory reset.

Given the choice of having increased exposure to superbrick or having my data laying around, I'd personally choose the latter.
[Samsung Epic 4G Touch] squshy 7:
Ahh, well then...I obviously would choose the latter as well, but I was going somewhere else with that.

If I can't show my higher-ups that there is any reasonable chance of bricking with Samsung's userspace fixes in place, then the alternative is to show them that those fixes might present a reasonable security issue, whereby one of our customers data could be compromised even after a hard reset.

What I do know is that we have criteria for what a hard reset needs to accomplish, what I don't know is what that criteria is exactly. If this were to fall against that, they might make Samsung fix it at the kernel level.

I'm starting to feel very small in the shadow of all this lol.
[Samsung Epic 4G Touch] sfhub:
The other thing you can try is loading a bunch of data (for example random data above or movies), then enabling encryption in Android. Even though it is OS-level encryption, it'll need to go through and actually encrypt everything which should cause a decent amount of (re)writes. Undo and redo encryption a few times, then do the factory reset.
[Samsung Epic 4G Touch] Entropy512:
The difference between secure erase and standard erase is that secure erase will erase all copies of data, even ones that are no longer referenced. For example, logical block X may map to physical location A. A write to A causes the wear leveller to copy and write that block to B instead. The data is still in A, although it is EXTREMELY difficult to retrieve, but it is possible. Secure erase nukes the copies at both B and A.

That's a good idea, assuming there isn't a wipe cycle when applying/undoing encryption.
[Samsung Epic 4G Touch] garwynn:
We know there is a second bug that wasn't resolved for our eMMCs where the wear leveling process can still insert 24 kb of zeros, meaning that data could be corrupted over time. A manifestation of that in the right spot - such as in the /data folder - could get a tech to suggest a factory reset. Another likely scenario is in an enterprise environment where GApps can do this remotely, such as if a phone was lost or stolen.

For the moment I'll suggest drop the actual situation and go first for proof of concept. Spam the /data partition with a large 1.5 GB file (again, a movie will do this probably the easiest, although scripts to copy & erase data will be good as well.) and just fill/empty the data you put in about 50 times. Then try a factory reset. If that works, try 100 times and keep increasing the count by either 50 or 100 until it fails. Since this is a regression test you're going to want to script this as well, so maybe putting the file either in the UMS or external SD card would be good.

Once you can find out how many iterations it takes to trigger it then a more realistic scenario can be considered IMHO. But even then we know what the odds are and that gets us moving forward.

---------- Post added at 03:11 PM ---------- Previous post was at 03:07 PM ----------

Unfortunately Google is straightforward with that point:

http://support.google.com/ics/nexus/bin/answer.py?hl=en&answer=1663755

So spamming the /data partition by script will probably be the easiest way to perform regression testing. Just specify a number of iterations and let it go while squishy can work on other things (and hopefully keep the boss happy).
[Samsung Epic 4G Touch] Entropy512:
Yeah, that was the idea with the script. Right now, it doesn't do anything on number of iterations - the only argument is the size of the work file in megabytes.

Ideally the loop counts would get altered for larger files, but in general - the idea would be to leave the script running for a few hours to stress the wear leveller. Most likely, you would want to ensure that it has run long enough that the wear leveller has written to every physical block available to it - i.e. no pre-erased blocks remain. I suspect this is when damage will be most likely.
[Samsung Epic 4G Touch] sfhub:
Did Samsung ever tell you the nature of the bug in their EMMC firmware causing the persistent lockup?

Specifically was it being caused by a race condition or was it more deterministic in nature?
[Samsung Epic 4G Touch] Entropy512:
No. Supposedly that's on the agenda for this weekend.

I just had some thoughts. For those who are taking the risk of wiping with stock recovery:

If the /data partition was reasonably full at the time of the wipe, was there any significant difference in the time it took to wipe between a simple format (Gingerbread, or recoveries/kernels that have been rendered safe) and the time required to do a low-level wipe? Per the JEDEC standard, erase/trim are not instantaneous, and interrupting TRIM can lead to internal data being in an "unknown state".

I wonder if damage in stock recovery is due to something like this:

User is accustomed to wiping with Gingerbread or safe non-wipe kernels - In these cases, the format operation is very fast, a matter of seconds

User flashes a kernel/recovery combo that performs a low-level wipe

This configuration needs ???? time to complete a wipe

User sees that the device is taking far longer than it used to in order to wipe, and does a battery pull or long power press before recovery completes the wipe process

Just a guess... As I won't risk even nonsecure erase on my own device, I don't know what the time delta is between the "old" (no MMC ERASE) and "new" (low-level MMC ERASE) methods is, if any. However if the difference is significant, then interruption of the process mid-wipe could be the key.
[Samsung Epic 4G Touch] garwynn:
That's one possibility, but I'm wondering if the time out error could be another. (Don't know if I posted that publicly or not but can sum it up again if needed)
[Samsung Epic 4G Touch] hakaz:
Another guess: I digged a little into stock recovery binary using IDA with standard ARM settings and if disasm was correct we should see a "wipe failed" message in various odd wipe situations (for data/cache/sdcard - there is no fail message for system partition like CWM would need) assuming low level MMC ERASE routine ever returns to the main process anyhow which could probably prove your long time guess. But this gives no idea how long it will take (maybe I will simulate the wipe process in debugger but missing the external low level MMC routines gives an idea what should happen at best). For info: I did the disasm for XWLPG XWLPI XXLQ5 XWLPM. And I bricked my SGS2 under CWM wiping system partition before - a variant the stock kernel would never handle ...
[Samsung Epic 4G Touch] Entropy512:
Reverse engineering the binary won't help much. https://github.com/CyanogenMod/android_system_extras/blob/ics/ext4_utils/wipe.c

It just generates an ioctl to the kernel, which eventually sends a set of MMC commands to the chip (mark the blocks for erase, then do the erase itself). I believe, but am not sure, the ioctl will block until the wipe is complete.

Edit: At least one resource I found indicates that for a very large discard size, the throughput is likely to be on the order of a gigabyte/second... Of course, our MMC might be different.

http://sourceforge.net/projects/test-discard/
[Samsung Epic 4G Touch] squshy 7:
Just as a progress report, not a lot of headway was made today. We had a minor inventory crisis that consumed most of my day.

On a good note though, I did have an opportunity to hard reset two ET4Gs in a real world environment.

Both came in (same customer) running GB, needed hard resets, customer requested I push FF18 OTW. Our firmware flash is a no data wipe, so I made it a point to not wipe until after the update.

The one is neglible, as it was running ok and didn't have a ton of data on it...the other one, though, ran like crap. Bloated full of data, both internal storage and /data partitions were nearly full. Hard resets went through without a hitch.

Off tomorrow, I'll finally have another tech with me on Wednesday, so should be a good day to do some data writes/wipes.
[Samsung Epic 4G Touch] shoey63:
Yep, that's how I superbricked my phone (N7000 Note, not Epic 4G touch, but bricking is bricking right?). I was on stock LQ3 and attempting to root with Temp CWM touch recovery and accidentally hit factory reset. Phone seemed to get stuck doing data wipe so I panicked and pulled the battery (foolishly thinking this might limit the damage I perceived was being done to chip). Result - superbricked phone.:eek:
[Samsung Epic 4G Touch] Entropy512:
Pull or not, you were hosed. I'm primarily concerned with trying to identify the conditions under which non-secure ERASE/TRIM (as used by stock recovery) fails.

We know that secure erase/trim (used by CWM if it hasn't been "rendered safe" using BOARD_SUPPRESS_EMMC_WIPE) will cause the wipe process to hang - once it happens you're hosed no matter what. :(
[Samsung Epic 4G Touch] hakaz:
Just as an idea for another approach:

And maybe nothing for the faint of heart but if there is some hw pro out there willing to prove his or hers luck, have a look at this:

http://www.uchobby.com/index.php/2007/05/05/read-embedded-flash-chips/

... and give us a clue what's inside the eMMC. My own hw skills are not that good ... :p
[Samsung Epic 4G Touch] Entropy512:
That's for legacy NAND. eMMC flash chips have a very different interface, including an internal abstraction layer between the interface the outside world sees and the internals.

You can think of the eMMC as being one of those NAND chips, plus some extra interface glue, all in one package.

And:

PHONE, Y U NO BRICK WHEN I WANT YOU TO?

It seems that even secure erase has a <50% chance of bricking... Although it could be dependent on the device's history, if it's been wiped successfully recently, I think it is less likely to have a problem on the next wipe. So I need to stress out the wear leveller on Sammy's device.
[Samsung Epic 4G Touch] Entropy512:
Does anyone have a link to the thread where E4GT users first hit this issue? Build ID of first leak, what conditions did bricks happen with?

I don't think Samsung was aware that people first observed problems in December or January.
[Samsung Epic 4G Touch] hakaz:
Thanks Entropy512 for your answer, reading the NAND inside goes through what Sammy calls its MMC interface, you are right. But I was interested what can be dumped out of the chip ignoring the firmware sitting in the MMC interface at first. Some people are reporting varying results on the same bricked device (see http://forum.gsmhosting.com/vbb/f634/emmc-firmware-bug-multiple-samsung-exynos-devices-1478679/#post8442882 where this guy used JTAG direct access interface.

Because my current best guess on the bug is a buffer/register overflow resulting in a pointer to the interface memory area itself which results in varying damage to the firmware, so as you stated there can work halfbaken chips out there without knowledge of their owners (as long as the chip has to start the phone only) and they will never brick totally (and this http://xdaforums.com/showthread.php?t=1667886 will work too of cause). Or you have a oneshot success experience during your first wipe and the interface is shattered totally.

As we know the different memory regions and can ask for the action before bricking (respectively the amount of data in each partition) maybe there is a recurrent pattern depending on these factors and detectable in these dumps.

And I really hope it is a firmware bug and not by chip design itself meaning any "bugfree" firmware could be a workaround only. (Please excuse my English, I'm not native).

BTW: Sammy gives following info in their specs:

16GB	VHX	KLMAG2GE4A-A00x	x8	1.7~1.95 V/2.7~3.6 V Max.52MHz DDR	169-ball BGA	12x16	eMMC4.41	MP

and for eMMC4.41: Max. Bandwidth	104MB/s
[Samsung Epic 4G Touch] garwynn:
Entropy,

Will dig through and send a timeline with links tomorrow.
[Samsung Epic 4G Touch] garwynn:
This is the first one that I could find and can easily confirm it's our bug by reading it, based on an stock leak.

FB17 + CWM - a known combination to trigger the bug when used with an "unsafe" kernel:

http://xdaforums.com/showthread.php?t=1506602

Trying to check CM9/AOSP build logs to see if I can find something earlier.
[Samsung Epic 4G Touch] jefbal99:
I bricked in the end of February going from Alpha 3.1 to Alpha 4.

http://xdaforums.com/showpost.php?p=23125325&postcount=2662