Post Reply

eMMC sudden death research

12th February 2013, 01:25 PM   |  #71  
Senior Recognized Developer
Flag Gdańsk
Thanks Meter: 3,426
 
1,339 posts
Join Date:Joined: May 2009
Donate to Me
To give a little sum-up:
Theoretical solution for superbricked devices would cover disabling eMMC for a while to trigger MMC1 boot (tweezers/paperclip/pencil should do with some luck and steady hand)
Then code from external sd would do factory format and eventually permanent patch of eMMC.
For devices where eMMC is capable of booting up to the kernel we'd probably use some kexec.
The Following 2 Users Say Thank You to Rebellos For This Useful Post: [ View ]
13th February 2013, 12:13 PM   |  #72  
OP Member
Thanks Meter: 259
 
52 posts
Join Date:Joined: Oct 2010
More
WARNING: The attached patch is dangerous as it sends low-level commands to your eMMC chip. Please, use it ONLY if you know what you're doing. I'm not responsible for anything!

I've attached a kernel patch which allows you to read the eMMC RAM.

Usage:
Code:
# cat /proc/devices | grep mmcram
248 mmcram
# mknod -m 0444 /dev/mmcram c 248 0
# dd if=/dev/mmcram of=/storage/extSdCard/mmcram.bin bs=4K count=128
128+0 records in
128+0 records out
524288 bytes (512.0KB) copied, 31.813499 seconds, 16.1KB/s
No lseek support if you wondered.
There's a memory hole at 0x20000-0x40000, so you'll get zeroes. Just ignore this part of the dump.

The patch also includes a rewrite of Samsung's patch to properly use the MMC quirks mechanism. I'll submit this part of the patch to CM someday.


* I'd like to get a dump of firmware 0xf7. If someone has a test device, you should be able to dump firmware 0xf7 if you move the "init_mmc_ram(card);" call to the top of the "mmc_movi_sds_add_quirk" function. If someone dumps firmware 0xf7, send it to me please.
Attached Files
File Type: patch mmc.patch - [Click for QR Code] (23.0 KB, 392 views)
Last edited by Oranav; 13th February 2013 at 03:03 PM. Reason: Yeah, I didn't attach anything before. :X
The Following 14 Users Say Thank You to Oranav For This Useful Post: [ View ]
13th February 2013, 08:01 PM   |  #73  
AndreiLux's Avatar
Senior Member
Thanks Meter: 13,688
 
2,786 posts
Join Date:Joined: Jul 2011
Donate to Me
Works here, extracted the 0xf1 firmware without issues. 0xf7 firmwares seem to be mostly prevalent in newer phones and non-white and non-blue models, so not many devs might have access. If somebody with 0xf7 wants to contribute, feel free to PM me for the kernel.

Oranav, mind if I keep the patch as is in the kernel with just the char device disabled for the public?
Last edited by AndreiLux; 13th February 2013 at 08:03 PM.
13th February 2013, 08:40 PM   |  #74  
OP Member
Thanks Meter: 259
 
52 posts
Join Date:Joined: Oct 2010
More
AndreiLux - no problem.
However, note that:
1. I didn't test the "other" part (quirk mechanism) thoroughly. After I test it enough, I'll submit it to CM. There might be some changes, so maybe you'd like to pull it instead of using the one I've attached.
Besides that, I saw that the SGS2 brickbug fix was merged into mainline; maybe I'll submit it to mainline as well.
2. The chardev code is very ugly (no conventions at all) and somewhat buggy (e.g. g_page is not thread-safe). Maybe it's better to fix it before merging it into your kernel, even if the code is disabled...
The Following 3 Users Say Thank You to Oranav For This Useful Post: [ View ]
13th February 2013, 08:57 PM   |  #75  
AndreiLux's Avatar
Senior Member
Thanks Meter: 13,688
 
2,786 posts
Join Date:Joined: Jul 2011
Donate to Me
I'm not releasing anything yet until maybe in a week or two, I'll update with whatever changes you do until then and consider that I'll be running this anyway on my phone till then.
The Following 3 Users Say Thank You to AndreiLux For This Useful Post: [ View ]
13th February 2013, 10:42 PM   |  #76  
Senior Recognized Developer
Flag Owego, NY
Thanks Meter: 24,410
 
13,300 posts
Join Date:Joined: Aug 2007
Donate to Me
More
Quote:
Originally Posted by esat-net

Could there be a connection between the SDS and the Samsung Laptop Bug:
http://mjg59.dreamwidth.org/22855.html

No, no connection at all, other than Samsung doesn't seem to care about breaking interfaces and leaving flaws open that can kill devices.

They will always point the finger at someone else, even though (as Alan Cox mentioned at https://plus.google.com/111104121194...ts/6Fo89YW6zGW ) - Anything that can be triggered by open source software could also be triggered by malware!

Quote:
Originally Posted by Rebellos

To give a little sum-up:
Theoretical solution for superbricked devices would cover disabling eMMC for a while to trigger MMC1 boot (tweezers/paperclip/pencil should do with some luck and steady hand)
Then code from external sd would do factory format and eventually permanent patch of eMMC.
For devices where eMMC is capable of booting up to the kernel we'd probably use some kexec.

To be clear, this would be for devices bricked by SDS. We have no way to boot from MMC1 on Exynos 4210 (aka devices vulnerable to "classic Superbrick")

That said, it's starting to look like there might be a way to JTAG resurrect Superbricked devices.
The Following 2 Users Say Thank You to Entropy512 For This Useful Post: [ View ]
17th February 2013, 02:48 AM   |  #77  
E:V:A's Avatar
Recognized Developer
Flag -∇ϕ
Thanks Meter: 1,801
 
1,347 posts
Join Date:Joined: Dec 2011
As much as it could be useful, I don't think we need to dump the eMMC
firmware, unless you are on a custom ROM or have problems with a non-Samsung
device. The eMMC firmware is available as long HEX structure in a firmware
header file in the GT-I9100, Jelly Bean open source, as part of the eMMC Field
Firmware Update (FFU)
module. You can download these sources from the Samsung
Open Source Release Center. Unzip and extract the Kernel and go to:
./drivers/mmc/ffu/fw.h

I haven't checked the FW from the I9300 sources, but it could be worth
comparing it, since the eMMC chip may be different.

The data structure consists of 0x203E0 (132064 = ~128 KiB) hex bytes and
look like this:
Code:
const unsigned char movinand_fw[] = {
 0x00,0x00,0x08,0x00,0x01,0x04,0x04,0x00,0xd1,0xb3,0x04,0x00,0xd3,0xb3,0x04,0x00,
 ...
 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
};
To convert this to a binary file, just pipe it through xxd like this:
Code:
cat fw.h |xxd -r -p >fw.bin
HERE are fw.h and fw.bin for the GT-I9100 for your convenience.

I was not successful in trying to replicate Oranav's results from Post#12. Not
sure what I did wrong. Also, not clear to where this piece fits in to the
memory map of Post#40, if it does at all.
The Following 3 Users Say Thank You to E:V:A For This Useful Post: [ View ]
17th February 2013, 01:12 PM   |  #78  
Senior Recognized Developer
Flag Gdańsk
Thanks Meter: 3,426
 
1,339 posts
Join Date:Joined: May 2009
Donate to Me
Hex you pasted looks indeed like beginning of samsung eMMC FW. I hate downloading stuff from Samsung OSRC. Could you extract their whole drivers/mmc dir?
17th February 2013, 05:44 PM   |  #79  
OP Member
Thanks Meter: 259
 
52 posts
Join Date:Joined: Oct 2010
More
E:V:A, this is just awesome; this code is rather new I suppose (I haven't seen any JB SGS2 source before).

Samsung actually field upgrades eMMC firmwares. It uses mostly vendor-specific and undocumented MMC commands, but we already knew much of this information thanks to the reversing process.

For those who are interested:
1. They validate that you've got a broken FW by reading a special extended Smart Report (reading address 0x1000 instead of 0 gets you an extended report).
2. If you do have a broken FW, they use CMD62(0xEFAC62EC) CMD62(0x10210001), which enters "SRAM writing mode". When you issue write commands, it just writes them to the SRAM (0x20000000).
3. They now write the whole buffer @ fw.h to the SRAM.
4. They then enter RAM reading mode by using CMD62(0xEFAC62EC) CMD62(0x10210002). Note that this is the exact command I've used to dump the RAM on my device, you can read about it on the old posts on this thread
5. They validate the FW upgrade payload by reading the SRAM.
6. If all is okay, they enter "RAM execute mode" by issuing CMD62(0xEFAC62EC) CMD62(0x10210010). They then jump to 0x20020001, which is just the Thumb2 function @ 0x20020000.

This is why the payload in fw.h has more than 0x20000 bytes (which is the size of the firmware). First 0x20000 bytes are the actual firmware, the extra bytes are the FW upgrade payload.


This is somewhat strange as they do have a built-in vendor specific MMC command to upgrade the FW, but they don't use it. I don't know why they do this. I guess time will tell.

I expect to see a similar FW upgrade for the SGS3 in the near time.
The Following 7 Users Say Thank You to Oranav For This Useful Post: [ View ]
17th February 2013, 06:02 PM   |  #80  
Senior Recognized Developer
Flag Owego, NY
Thanks Meter: 24,410
 
13,300 posts
Join Date:Joined: Aug 2007
Donate to Me
More
Quote:
Originally Posted by Oranav

E:V:A, this is just awesome; this code is rather new I suppose (I haven't seen any JB SGS2 source before).

Samsung actually field upgrades eMMC firmwares. It uses mostly vendor-specific and undocumented MMC commands, but we already knew much of this information thanks to the reversing process.

For those who are interested:
1. They validate that you've got a broken FW by reading a special extended Smart Report (reading address 0x1000 instead of 0 gets you an extended report).
2. If you do have a broken FW, they use CMD62(0xEFAC62EC) CMD62(0x10210001), which enters "SRAM writing mode". When you issue write commands, it just writes them to the SRAM (0x20000000).
3. They now write the whole buffer @ fw.h to the SRAM.
4. They then enter RAM reading mode by using CMD62(0xEFAC62EC) CMD62(0x10210002). Note that this is the exact command I've used to dump the RAM on my device, you can read about it on the old posts on this thread
5. They validate the FW upgrade payload by reading the SRAM.
6. If all is okay, they enter "RAM execute mode" by issuing CMD62(0xEFAC62EC) CMD62(0x10210010). They then jump to 0x20020001, which is just the Thumb2 function @ 0x20020000.

This is why the payload in fw.h has more than 0x20000 bytes (which is the size of the firmware). First 0x20000 bytes are the actual firmware, the extra bytes are the FW upgrade payload.


This is somewhat strange as they do have a built-in vendor specific MMC command to upgrade the FW, but they don't use it. I don't know why they do this. I guess time will tell.

I expect to see a similar FW upgrade for the SGS3 in the near time.

Maybe whomever did it didn't know that command was there. They're pretty disorganized.

It's interesting as that appears to be a "upgrade without reformat". Perhaps the vendor specific command will always fullreset the eMMC?

This is actually the third or fourth I9100 JB source drop - HK got it in December, China a bit later.

Post Reply Subscribe to Thread
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes