Attend XDA's Second Annual Developer Conference, XDA:DevCon 2014!
5,806,560 Members 54,089 Now Online
XDA Developers Android and Mobile Development Forum

eMMC sudden death research

Tip us?
 
Rebellos
Old
#71  
Senior Recognized Developer
Thanks Meter 3,425
Posts: 1,339
Join Date: May 2009
Location: Gdańsk

 
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.
Feedback on my development is highly appreciated, but first you should read this GUIDE and watch this MOVIE.

If you like my work - you can help me getting various cool stuff by clicking donation link in my profile. It's not required while pressing is, just appreciated.

Pretty owsom Android/Kernel dev tips&tricks: http://omappedia.org/wiki/Android_How-tos

Git HOW-TO by eagleeyetom: http://forum.xda-developers.com/show...php?p=31304826
15-minutes GIT introduction: http://try.github.com
If you want to submit patches to my git projects - use the guides above and make a pull request.
The Following 2 Users Say Thank You to Rebellos For This Useful Post: [ Click to Expand ]
 
Oranav
Old
(Last edited by Oranav; 13th February 2013 at 03:03 PM.) Reason: Yeah, I didn't attach anything before. :X
#72  
Member - OP
Thanks Meter 259
Posts: 52
Join Date: Oct 2010
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, 386 views)
The Following 14 Users Say Thank You to Oranav For This Useful Post: [ Click to Expand ]
 
AndreiLux
Old
(Last edited by AndreiLux; 13th February 2013 at 08:03 PM.)
#73  
AndreiLux's Avatar
Senior Member
Thanks Meter 13,673
Posts: 2,778
Join Date: 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?
 
Oranav
Old
#74  
Member - OP
Thanks Meter 259
Posts: 52
Join Date: Oct 2010
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: [ Click to Expand ]
 
AndreiLux
Old
#75  
AndreiLux's Avatar
Senior Member
Thanks Meter 13,673
Posts: 2,778
Join Date: 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: [ Click to Expand ]
 
Entropy512
Old
#76  
Senior Recognized Developer
Thanks Meter 24,349
Posts: 13,256
Join Date: Aug 2007
Location: Owego, NY

 
DONATE TO ME
Quote:
Originally Posted by esat-net View Post
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 View Post
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.
*so much sig updating needed*

My Github profile - Some Android stuff, some AVR stuff

An excellent post on "noobs vs. developers"

A few opinions on kernel development "good practices"

Note: I have chosen not to use XDA's "friends" feature - I will reject all incoming "friend" requests.

Code:
<MikeyMike01> Smali is a spawn of hell
<shoman94> ^^^ +!
Code:
<Entropy512> gotta be careful not to step on each other's work.  :)
<Bumble-Bee> thats true
<jerdog> compeete for donations
The Following 2 Users Say Thank You to Entropy512 For This Useful Post: [ Click to Expand ]
 
E:V:A
Old
#77  
E:V:A's Avatar
Recognized Developer
Thanks Meter 1,787
Posts: 1,341
Join Date: Dec 2011
Location: -∇ϕ
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.
MSM8960 Info, Architecture and Bootloader(s)
El Grande Partition Table Reference
How to talk to the Modem with AT commands

[REF][ServiceMode] How to make your Samsung perform dog tricks
[REF|R&D|RF] RF/Radio properties of Samsung ServiceMode

Want to know when your phone is getting tracked or tapped?

Help us develop the IMSI Catcher / Spy Detector!
(To be part of the EFF & The Guardian Project toolsets.)
_______________________________
If you like what I do, just click THANKS!
Everything I do is free, altruism is the way!
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ
I do not answer support related PM's.

The Following 3 Users Say Thank You to E:V:A For This Useful Post: [ Click to Expand ]
 
Rebellos
Old
#78  
Senior Recognized Developer
Thanks Meter 3,425
Posts: 1,339
Join Date: May 2009
Location: Gdańsk

 
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?
Feedback on my development is highly appreciated, but first you should read this GUIDE and watch this MOVIE.

If you like my work - you can help me getting various cool stuff by clicking donation link in my profile. It's not required while pressing is, just appreciated.

Pretty owsom Android/Kernel dev tips&tricks: http://omappedia.org/wiki/Android_How-tos

Git HOW-TO by eagleeyetom: http://forum.xda-developers.com/show...php?p=31304826
15-minutes GIT introduction: http://try.github.com
If you want to submit patches to my git projects - use the guides above and make a pull request.
 
Oranav
Old
#79  
Member - OP
Thanks Meter 259
Posts: 52
Join Date: Oct 2010
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: [ Click to Expand ]
 
Entropy512
Old
#80  
Senior Recognized Developer
Thanks Meter 24,349
Posts: 13,256
Join Date: Aug 2007
Location: Owego, NY

 
DONATE TO ME
Quote:
Originally Posted by Oranav View Post
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.
*so much sig updating needed*

My Github profile - Some Android stuff, some AVR stuff

An excellent post on "noobs vs. developers"

A few opinions on kernel development "good practices"

Note: I have chosen not to use XDA's "friends" feature - I will reject all incoming "friend" requests.

Code:
<MikeyMike01> Smali is a spawn of hell
<shoman94> ^^^ +!
Code:
<Entropy512> gotta be careful not to step on each other's work.  :)
<Bumble-Bee> thats true
<jerdog> compeete for donations

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes