yashsingh1/xdaforums huggingface dataset:
[Galaxy Note II, Galaxy S III Developer Discussion ] Oranav:
Okay, got a RAM dump :)

I won't post it here (or anywhere else for that matter) because I don't want to get sued by Samsung.

I might release a kernel which allows you to dump the RAM yourself if there's enough demand, but I don't want to right now, because:

1. The code is ugly as hell, not implemented as a kernel module, not thread-safe etc.

2. It is highly dangerous (messing with the eMMC chip - I really don't know how much stable this thing is), so if you want to do it on your device, you should be an expert. In that case, you can write the code yourself (with little effort) :)

Anyway, I hope the FTL is Whimory, since I'm familiar with it. Would be easier.

I'll let you know if I find anything interesting.

PS I've attached a little teaser. (Yes, this is the patched function. 0x40300 is red because I've opened a partial RAM dump.)

EDIT - Some initial results:

0. The CPU is a Cortex-M3.

1. No strings at all :( Just some uninteresting release asserts ("REL_ASSERT")

2. Found the Smart Report generator function -> found the MMC command handlers.

3. Most MMC commands handlers are stored in a function table. There are 3 special commands: MMC60, MMC62, MMC64. Depends on the arguments these special commands are provided, they modify the function table (this is the so called "vendor mode").

4. There are a lot of possible arguments for MMC62, not the only ones we know.

5. If you trace back the function they patch all the way up the call stack, you get to MMC24 and MMC25 handler. These commands are MMC_WRITE_BLOCK and MMC_WRITE_MULTIPLE_BLOCK. Since the function they patch is deep down the call stack, it's very likely that it is the wear level.

Anyway, because of the lack of strings I guess it would be very hard to truly understand the SDS bug we're facing :(
[Galaxy Note II, Galaxy S III Developer Discussion ] resore:
Odp: eMMC sudden death research

i cant say i have an idea whats going on inside emmc but usually in this case of mistakes/failures debug or diagnostics code is used for release.

maybe some debug info repeatedly written triggers wear levelling failure

so fix has to simply disable it
[Galaxy Note II, Galaxy S III Developer Discussion ] Rebellos:
Awesome research.

So we're dealing with bug in exactly the same eMMC subsystem as in faulty SGS2 eMMC chips, but in device that was released after proving SGS2 eMMCs to be faulty.

Oranav, for some reason I cannot send you PMs. Could you send me your dump? Does your eMMC come from faulty serie?
[Galaxy Note II, Galaxy S III Developer Discussion ] owl74:
Hi all, after reading this thread, I am now scared....

I have a Note 2 N7100 which is running ARHD V8.0 with Perseus Kernel V31.2 and TWRP recovery 3.2.2.3

The above all include the fix for SDS and Exynos hole.

I have been running the device for nearly 1 week I think. Last night I fully charged my phone, used it for 3 minutes surfing the forum (chrome) via wifi connection. After 3 minutes, I left the phone on the table for 3 hours. The only running app is Viber... when I tried to wake the phone up, it did wake up but it froze... no button worked, I tried for about 2 minutes... nothing worked except the power button which booted the device.

This is weird, never experienced this before... I am now scared the phone will die unexpectedly.
[Galaxy Note II, Galaxy S III Developer Discussion ] thealgorithm:
How long were you using the system before you had updated to the 'fix'? None the less, it does not necessarily mean that the phone is getting near to the SDS. I have had a few android phones which would sometimes reboot or hang for other reasons.
[Galaxy Note II, Galaxy S III Developer Discussion ] Oranav:
I tried to simulate an eMMC freeze (by forcing it to go into an infinite loop). It behaves exactly as you describe - the phone works for a second, then becomes totally unresponsive. Seems like there is no watchdog.

Rebellos, I enabled the private messaging system for me. I do have the faulty chip.
[Galaxy Note II, Galaxy S III Developer Discussion ] Rob2222:
Damn Oranav, nice work! :D

So does it mean you get a total screen freeze? Every time?

BR

Robert
[Galaxy Note II, Galaxy S III Developer Discussion ] owl74:
About 2 weeks. Forgot to mention i reebooted the phone before I charged it. I will return this phone before it dies on me.... I think I will get an S3 but I will check if it has a new chip... otherwise I will return again and stick to my desire hd which is already running S3 rom....

---------- Post added at 02:24 PM ---------- Previous post was at 02:22 PM ----------

So everyone's speculation is right about thw fix causing the freeze...
[Galaxy Note II, Galaxy S III Developer Discussion ] SamsungPisser:
AW: eMMC sudden death research

Suppose this fix addresses wear leveling. If firmwares without this fix wear out the eMMC would then not the device still boot and then crash? As far as I know flash is still readable but not writable any more when worn out. Could it be that the wear leveling algorithm has a problem so that after some time it replaces cells from the bootloader and that causes the death?

In short: I want to know if it had a negative effect using the old firmware for some time because that old software caused extreme aging for the eMMC.
[Galaxy Note II, Galaxy S III Developer Discussion ] Oranav:
As far is it seems right now, it isn't caused by flash wear or anything like that. It seems that it's caused by a bug which is triggered in a very specific case. Then, it causes the device to corrupt its inner structures or its firmware - I'm not sure which one yet.

The specific bug is that they don't check the return value of some function returning a pointer, which may be NULL. It then leads to a NULL pointer dereference which corrupts things.

So, as far as it seems currently, there is no negative effect of using an unpatched kernel (except for the risk of it suddenly dying, of course).

By the way, it's worthy to note that the firmware actually resides on the flash itself. There is a very small boot ROM (which is probably a mask ROM) that loads the firmware out of the NAND device.

Why am I mentioning this? It means that a bug in the firmware may actually corrupt the firmware itself, bricking the device.
[Galaxy Note II, Galaxy S III Developer Discussion ] liamR:
That is awesome research. Assuming that samsung just made a quick "fix" with the new kernels (and it does causing random freezes), Do you think that they can make a proper fix without side effects ?

Assuming they know all about it since SGS2 and it still effects SGS3 this makes samsung a terrible company.
[Galaxy Note II, Galaxy S III Developer Discussion ] Oranav:
Absolutely yes.
[Galaxy Note II, Galaxy S III Developer Discussion ] odoto:
question is, will they be smart enough do actually do it :P

(I'm not talking about their engineers, but their management)
[Galaxy Note II, Galaxy S III Developer Discussion ] Rob2222:
@Oranav:

Do you know, if the fix is applied in download mode, too?

I assume that the download mode does _not_ load a kernel or recovery, so the following assumption would be, that in download mode the eMMC is not protected.

Could that be?

BR

Rob
[Galaxy Note II, Galaxy S III Developer Discussion ] Product F(RED):
You have to have a kernel. I'm sure it shares the recovery kernel since the recovery kernel is basically a backup/fail-safe kernel.
[Galaxy Note II, Galaxy S III Developer Discussion ] Rob2222:
I am not sure about this. From my understanding the (second?) bootloader already has eMMC and display driver. So there are enough parts already initialized to make the eMMC aviable for USB access. No real need to load the kernel for that.

If download mode would need kernel/recovery, it would not be aviable if you flash a wrong kernel/recovery. And if I remember right I've seen wrong kernel and wrong recovery flashs got repaired by just flashing the correct kernel/recovery, so download mode was still working.

BR

Rob
[Galaxy Note II, Galaxy S III Developer Discussion ] Product F(RED):
You could be right but I know that recovery mode has its own separate kernel. That's why I thought maybe download mode shared it.
[Galaxy Note II, Galaxy S III Developer Discussion ] Oranav:
Download mode has nothing in common with the recovery partition. It is implemented in sboot (the device's bootloader).

It has its own implementation of hardware drivers. If it doesn't patch the eMMC RAM, then it isn't safe!

However, I haven't checked it enough yet to conclude whether it's safe or not. Right now, I'd recommend anyone to avoid flashing via download mode. Recovery and Mobile Odin (or just dd) are good enough.
[Galaxy Note II, Galaxy S III Developer Discussion ] AndreiLux:
Makes sense into why they upgraded the bootloader with LLA then, the increased modification detection would be just a side-effect of a newer bootloader version which already had heightened warranty enforcements on the 9305 and the Note 2's.
[Galaxy Note II, Galaxy S III Developer Discussion ] Entropy512:
That alone would be enough to upgrade bootloader...

I don't believe SBOOT is encrypted or compressed - just run strings on it. If you see lots of recognizable strings, but don't see the eMMC model number, you can be fairly certain the BL doesn't contain a fix.
[Galaxy Note II, Galaxy S III Developer Discussion ] drakester09:
I ran strings in the following BL versions:

- My current EMA1

- First changed release ELLA

- ICS BL ALEF

I'm attaching the results and a diff for each version, a lot of the content is gibberish but there are some quite interesting differences, mostly around line 1100.

Maybe it can help us understand a bit more or determine if BL plays a role.
[Galaxy Note II, Galaxy S III Developer Discussion ] AndreiLux:
There are some bootloader MMC changes but if they're related to SDS is to be determined... no VTU00M string in there at least, but that still doesn't rule it out.

They added that mmcdtest into the bootloader utility commands, I wonder what it does.
[Galaxy Note II, Galaxy S III Developer Discussion ] Oranav:
I'm reversing sboot to see what have changed (no "VTU00M" string doesn't mean there's no fix).

It should be very easy since we have kernel sources (we know how to communicate with the eMMC controller - MMIO addresses etc.).

* If someone has a BinDiff license and wants to help, it'd be great! :)

It reads 0xFFC00 bytes from the eMMC boot partition and copies them to 0x50000000 (maybe this is an output buffer? I don't know yet).

I also think 0xFFC00 is the boot partition size, so it just reads it all...
[Galaxy Note II, Galaxy S III Developer Discussion ] AndreiLux:
The U-Boot sources might interesst you, to get the general idea of the bootloader buildup. I don't know what the practical differences between U-Boot and S-Boot will be though, especially since the former will be outdated.
[Galaxy Note II, Galaxy S III Developer Discussion ] Rob2222:
@Oranav/All:

We have some news regarding to the freezes that occur on some S3's with the new firmware...

Someone posted that he waited until the freeze is over and I asked how long. He said after 10-15 minutes the phone was back to normal without reboot.

So as my phone froze with screen on I waited and I really was suprised that after around 23 minutes freeze the phone just continued to work as it had never frozen.

Maybe the eMMC has a watchdog after all.

Maybe it is a interesing point that the phone is able to continue after a long time freeze.

Maybe we can get some infromation out of some log files?

Since 2-3 days my S3 has 5-20 freezes per day. I am on stock, unrooted XXELL5.

BR

Rob
[Galaxy Note II, Galaxy S III Developer Discussion ] Rob2222:
Got a kernel log from just after such a freeze.

I was about to power on the screen but nothing happen. Then I waited around 10 minutes and the screen came finally up and I dumped the log.

Is this interesting? :D

Full log is attached.

U/ 4002.738352 c0 [keys]PWR 1
U/ 4002.983296 c0 [keys]PWR 0
...
U/ 4587.514100 c0 mshci: ===========================================
W/ 4587.514336 c0 mmc0: it occurs a critical error on eMMC it'll try to recover eMMC to normal state
....
V/ 4587.850296 c0 mmc0: recovering eMMC has been done
...
W/ 4587.850849 c0 mmcblk0: unknown error -131 sending read/write command, card status 0x900
W/ 4587.851982 c0 end_request: I/O error, dev mmcblk0, sector 3126872
W/ 4587.852174 c0 end_request: I/O error, dev mmcblk0, sector 3126880
W/ 4587.852330 c0 end_request: I/O error, dev mmcblk0, sector 3126888

EDIT: Added another log. Will add more, if I get more.

BR

Rob
[Galaxy Note II, Galaxy S III Developer Discussion ] sodeknetters:
Yes, so it looks like the freezes have emmc involvement indeed!
[Galaxy Note II, Galaxy S III Developer Discussion ] Entropy512:
Could you perhaps post the RAM dump? I might be able to hand it to someone with a copy of hex-rays decompiler. :)

How big is the RAM?

I'm thinking of maybe dumping VYL00M fwrev 0x19 while I'm at it, and maybe seeing if someone else can dump 0x25. :P
[Galaxy Note II, Galaxy S III Developer Discussion ] Oranav:
I have a Hex-Rays license. I actually reverse most of the time using it; I posted assembly code since it's easier to understand with these short snippets (in my point of view).

I won't post a RAM dump since it contains (probably?) licensed code.

I can however post the memory map:

0x00000000 - 0x00020000 BootROM (I guess it's a mask ROM)

0x00040000 - 0x00060000 Firmware (resides in RAM, the BootROM reads it from the NAND chip itself so it's upgradable!)

0x00060000 - 0x00080000 Data (no dynamic memory there BTW)

0x20000000 - 0x20028000 eMMC interface MMIO

0x20080000 - 0x20080400 I don't know, maybe another eMMC interface MMIO?

0x40000000 - 0x40010000 NAND interface MMIO

I can send you my RAM dump over IRC if you'd like. Besides that, I contemplate posting a .ko which exports the RAM over a character device (this is how I dumped it).

And, yes, dumping the new firmwares to see what has changed is super-cool :p
[Galaxy Note II, Galaxy S III Developer Discussion ] E:V:A:
You can dump all of your "live" RAM with Lime forensic tool:

http://code.google.com/p/lime-forensics/

But it may be overkill...
[Galaxy Note II, Galaxy S III Developer Discussion ] Oranav:
Lime isn't relevant here, since the CPU's RAM and the MoviNAND's RAM aren't shared; they aren't even mapped to the same memory space.

In order to read the MoviNAND's RAM, we have to send vendor-specific eMMC commands and read eMMC data...
[Galaxy Note II, Galaxy S III Developer Discussion ] Entropy512:
A .ko (preferably with source :) ) would be great. It would save me a lot of time implementing the dumper myself. Ideally I'd like to get dumps of VYL00M or MAG4FA 0x19, along with 0x25.

We do know these chips are upgradable, however, Samsung claims that:

1) To upgrade the firmware, you must completely wipe the chip including all bootloaders. (Interestingly enough, this fullwipe will resurrect Superbricked devices) - I believe this

2) The process is so dangerous that it fails frequently in a way that makes the chip 100% unrepairable - I'm a bit skeptical about this one, at least the claims of an absurdly high failure rate.

#2 is why we have no way to repair Superbricked devices.
[Galaxy Note II, Galaxy S III Developer Discussion ] E:V:A:
At first I didn't quite understand what was going on, but now when I see what is happening... Excellent!

I'd love to see some tool to come out of this, to read eMMC RAM. I can see several cross-platform applications for this! Something like "viewmem", but "viewemmc" instead. Would this be feasible?

@ Entropy512: Could this be incorporated into your "Got Brickbug?" app, or something similar?
[Galaxy Note II, Galaxy S III Developer Discussion ] Entropy512:
That's not my app. It also probably couldn't be integrated into any detection app, BUT it would be interesting to see what the differences are between MAG4FA 0x19 (BAD) and MAG4FA 0x25 (good other than a far less nasty "wear leveller randomly inserts 32kb of zeros" bug).

Maybe even if there were a way to write the RAM back to NAND, then the chip could be reset/wiped - we know this is possible but dangerous. It could only be researched by someone who has JTAG access to an affected device, since no affected device has any known way to boot from USB or SDCard.
[Galaxy Note II, Galaxy S III Developer Discussion ] Product F(RED):
What's sad about this is that you guys are probably doing more work than Samsung, trying to get to the bottom of the problem. But I guess that's also a good thing a way; I still have faith in humanity.
[Galaxy Note II, Galaxy S III Developer Discussion ] E:V:A:
Why doesn't someone just email whoever made the patch? Perhaps he/she could at least explain the reasoning behind, without giving out all Samsung "secrets".

I'm thinking the same thing. Just like the "bad sectors" on a good old HD, perhaps the bad "sectors" on an eMMC is getting avoided or tagged as bad by the wear leveling algorithm. These "tags" also have to be written somewhere, so if these function was screwed up somehow, I guess you'd get corruption although most part still functioning. The "patch-fix" then slowly discovers these errors and avoids them, causing us to see a decrease of problems.

There must be something written somewhere about wear-leveling of eMMC's...

Zynamics BinDiff seem very nice...but with(out) a price tag.

(Again, write the guys and ask for an 99% XDA Developer discount. After all, the company has been acquired by Google and we're working for Android!)

But you can also try some free a HEX based ones

VBinDiff

Another BinDiff

DiffNow (for source code/text and web based)

My bad. Sleepy eyes. (Chainfire's app)
[Galaxy Note II, Galaxy S III Developer Discussion ] Oranav:
I think it is possible to update the firmware.

Except for CMD62, there are 2 more vendor specific commands (CMD60 and CMD64). I think I saw somewhere a command which updates the firmware on the NAND; I'm not sure now but I'll check it later. The BootROM is also very small so it's easy to find exactly where the firmware is stored on the NAND.

About the danger with this process, I think it's mostly due to the risk of having no bootloader or no Movi firmware. However, I think the Movi BootROM has a recovery mode, so if we're somehow able to boot the device from the mmc1 bus (SD card), we're okay.

Anyway, later this week I'll write that .ko (currently I just edited the Linux MMC subsystem code :o) and push to Github.
[Galaxy Note II, Galaxy S III Developer Discussion ] E:V:A:
@Oranav: Can you PM me a memory dump?

I'd like to see the Smart Report for a failing device versus a working one...

I have a bad feeling that this problem can be much greater than what Samsung like to admit. At least if this bug have anything to do with wear-leveling...

Also, can "someone" help me "fill in" the following:

a) what exact devices are having problems?

b) What exact eMMC cards do they have? (And size)

c) Is that leaked datasheet in OP, for any of those in (b)?

d) What die size "technology" are these eMMC's using? (25 nm, 34 nm or other?)

e) Do you know anything about how people with eMMC problems use their devices?

f) The Linux kernel version for problematic devices...
​
[Galaxy Note II, Galaxy S III Developer Discussion ] Entropy512:
Not possible, since the patch was excised from a MASSIVE kernel update with thousands of lines of changes. There is zero commit history for the tarball drop. The tagging of Andrei's patch as "Samsung OSRC" was some custom hackery by him - he diffed two kernels, split up the commits, and set authorship to "Samsung OSRC".

How an eMMC does internal wear levelling is up to the manufacturer - eMMC only defines the external interface.

Wear levelling algorithms are typically considered highly proprietary by the manufacturer.

So far, historically every "catastrophic" MMC failure we've dealt with on Samsung eMMCs has had nothing to do with bad/corrupt sectors - it has to do with bad/corrupt internal data. Think of it as a lower-level version of a corrupt ext4 filesystem... The underlying disk is fine, but the filesystem is useless without a reformat. Problem is, there's no documented way outside of a factory to completely reset an eMMC (e.g. "low level format").

In the case of Superbrick, a secure erase command issued to a region that contains sectors in a certain state (associated with a performance optimization, not with failure handling/recovery) would corrupt the wear leveller's internal data. Then, any time you tried to access nearby memory, the wear leveller would simply crash.

SDS seems to be a case of some function potentially returning 0 (maybe due to integer overflow? The statistics of the issue and how it suddenly "spiked" after a number of months of usage screams overflow to me), and that 0 then being treated as data instead of an error, corrupting data structures right and left.

No internal firmware seems to be the risk that Samsung was most concerned about when they decided not to release Superbrick repair code - Supposedly if the firmware update doesn't go perfectly the chip is 100% toast. (However, language barrier and such could have really meant just that the device's bootloaders were hosed...)

There might also be some interface that allows the MMC to be programmed in the factory that isn't exposed once soldered to a board.

Unfortunately, as we don't have a security-dropped IBL that is signed for Exynos 4210, there is no SDCard or USB recovery available for 4210 devices like there is for Exynos3 and for 4412 devices. If you kill the bootloaders, JTAG is it.
[Galaxy Note II, Galaxy S III Developer Discussion ] Oranav:
It doesn't seem like an integer overflow, at least not a straightforward one.

This is the function they patch:

int __fastcall f_to_be_patched_function(_DWORD *out, int val)
{
int ret; // r2@1

ret = 0;
if ( *off_5FC60 == val )
{
*out = off_5FC60;
return 1;
}
if ( *off_5FC64 == val )
{
*out = off_5FC64;
return 1;
}
*out = 0;
return ret;
}

Both off_5FC60 and off_5FC64 point to some FTL related contexts.

This is the wrapper function they write to the RAM:

void __fastcall f_new_function_by_patch(_DWORD *out, int val)
{
if ( !f_to_be_patched_function(out, val) )
{
while ( 1 )
;
}
}

The BL instruction that is being patched used to call the old function (f_to_be_patched_function), without checking its return value, hence the bug.

What's so strange about it is that "f_to_be_patched_function" is called from many other locations in the code, without checking the return value! So the bug exists in other locations as well.

Either the other locations don't cause internal metadata corruption, or they are just so rare that Samsung didn't even bother to patch them.

Wait, so we do have a way to boot Exynos 4412 devices (Galaxy S3) from the mmc1 bus?

If so, why isn't SDS fixable?
[Galaxy Note II, Galaxy S III Developer Discussion ] E:V:A:
There is no CMD64, because CMDs go from 0-63. CMD's 60-63 are

"Reserved for Manufacturers" and belong to the reserved Class-11.

But I agree, there have to be a way to update eMMC firmware. Although Entropy may be right about factory programming, I don't think this "interface" would only be available at that time. I have a strong belief that it should be possible to update. We know all the eMMC pins, and we know the basic interface and the basic technology within, but we don't know the firmware! Samsung's SSD firmwares can certainly be updated!

(We could look for the firmware in there.)

Unless you can somehow provide something more substantial than that reversed pseudo-C stuff, I cannot help much. (Or if you can post that module so that we can look for ourselves!)

We can certainly unbrick anything supported by Adam Outlers/Rebellos/Ralekdevs unbrickable mods. They also have the Boot from SD card mod. In theory we should be able to unbrick I9100 in the same way, but no one want to waste more energy on that PoS device! (I know, because I have one...with the VYL00M brick bug!)