eMMC To SD Hack Rescues Data From A Waterlogged Phone - Hackaday

3/10/2019 eMMC to SD Hack Rescues Data from a Waterlogged Phone | Hackaday
EMMC TO SD HACK RESCUES DATA FROM A

WATERLOGGED PHONE
by: Adam Fabio 57 Comments
July 12, 2017
How do I get the data off this destroyed phone? It’s a question many of us have had to ponder – either ourselves or for friends or
family. The easy answer is either spend a mint for a recovery service or consider it lost forever. [Trochilidae] didn’t accept either
of those options, so he broke out the soldering iron and rescued his own data.
A moment’s inattention with a child near a paddling pool left [Trochilidae’s] coworker’s wife with a waterlogged, dead phone. She
immediately took apart the phone and attempted to dry it out, but it was too late. The phone was a goner. It also had four months
of photos and other priceless data on it. [Trochilidae] was brought in to try to recover the data.
The phone was dead, but chances are the data stored within it was fine. Most devices built in the last few years use eMMC flash
devices as their secondary storage. eMMC stands for Embedded Multimedia Card. What it means is that the device not only
holds the flash memory array, it also contains a flash controller which handles wear leveling, flash writing, and host interface. The
controller can be configured to respond exactly like a standard SD card.
The hard part is getting a tiny 153 ball BGA package to fit into an SD card slot. [Trochilidae] accomplished that by cutting open a
microSD to SD adapter. He then carefully soldered the balls from the eMMC to the pins of the adapter. Thin gauge wire, a fine tip
iron, and a microscope are essentials here. Once the physical connections were made, [Trochilidae] plugged the card into his
Linux machine. The card was recognized, and he managed to pull all the data off with a single dd command.
[Trochilidae] doesn’t say what happened after the data was copied, but we’re guessing he analyzed the dump to determine the
filesystem, then mounted it as a drive. The end result was a ton of recovered photos and a very happy coworker.
If you like crazy soldering exploits, check out this PSP reverse engineering hack, where every pin of a BGA was soldered to
magnet wire.
Posted in Cellphone Hacks

Tagged data recovery, emmc, flash, recovery, rescue, smartphone
← HACKADAY PRIZE ENTRY: ONE-HANDED, NO-LOOK KEYING
LASER CUTTING ORRERIES →
https://hackaday.com/2017/07/12/emmc-to-sd-hack-rescues-data-from-a-waterlogged-phone/ 1/10
57 THOUGHTS ON “EMMC TO SD HACK RESCUES DATA

FROM A WATERLOGGED PHONE”
Ren says:
July 12, 2017 at 1:04 pm
Good work!
Reply Report comment
Ren says:
July 12, 2017 at 1:12 pm
Maybe a fellow could rig this up with pogo pins and start a recovery service in his apartment.
jimmy says:
July 13, 2017 at 12:20 am
Such adaptes are already available for ~100EUR from company allsocket (I am not related to that company in any way)
Ren says:
July 13, 2017 at 6:26 am
Thanks!
Ostracus says:
July 12, 2017 at 1:11 pm
Was it hard getting the pin-out for the eMMC?
vtec says:
July 12, 2017 at 2:11 pm
It’s in a JEDEC standard.
Kevin Harrelson says:

July 12, 2017 at 4:07 pm
JEDEC standard means that you have to pay to see it, from what I understand.
L says:
July 13, 2017 at 12:52 pm
But do you think that different manufacturers will have the same pinouts for the same eMMC model? I am not sure,
Anyone knows?
L says:
July 13, 2017 at 10:56 pm
Thanks for the reply. Is there any a chance I can get a datasheet/pinouts for the most often used eMMC model?
chango says:
July 12, 2017 at 6:13 pm
NAND pinouts are also standardized. It’s the timing and geometry that are hard to get ahold of.
toby says:
July 12, 2017 at 1:40 pm
I thought I read something similar (not necessarily same problem) on Hackaday last year and found the article: https://hackaday.com/2016/11/18/roll-
your-own-64gb-sd-card-from-an-emmc-chip/
rasz_pl says:
July 12, 2017 at 1:42 pm
>doesn’t say what happened after the data was copied, but we’re guessing he analyzed the dump to determine the filesystem, then mounted it as a
drive
more likely he discovered modern phones encrypt EVERYTHING
Adam Fabio says:

July 12, 2017 at 1:51 pm
Since his coworkers wife is thanking him for recovering her data in the blog comments, I’m betting the data on this phone was not encrypted…
vtec says:
July 12, 2017 at 2:15 pm
Unless there is a security chip or the MPU’s crypto unit is used, there is not so much entropy in a swipe pattern, or a 4-digit PIN.
Would any mainstream Android phone maker bother to use any of the above?
Apple is a different beast.
Jeff NME says:

July 13, 2017 at 9:31 pm
Considering that phones which use micro SD cards don’t seem to encrypt data saved to them (multiple times I’ve removed an SD card
and copied photos across onto a computer using a bog-standard card reader), I’m guessing that these internal eMMC chips are used in
exactly the same way and just store data unencrypted in a FAT32 file system.
You’re relying more on the physical obscurity of the flash memory chip being soldered onto the phone logic board and sealed inside its
casing, requiring quite a bit of lateral thinking and nifty soldering skills to connect it to an SD card reader, not a 120gazillion-bit encryption
key to keep it secure.
Unferium says:
July 12, 2017 at 2:38 pm
I would of skipped the dumping… especially because of risking corrupting the mmcblk#boot# partitions.
I’d first try and mount mmcblk#p# to a /mnt location and then perform a CTRL+C CTRL+V recovery, unless some oddball partition table was
used (Looking back to the Archos hidden ext3 partition days, their OMAP based players)
jaja says:
July 13, 2017 at 2:11 am
Dumping is read-only. Mounting is read-write (mounting also *writes* some counters/stats to the disk). Dumping is way safer as it does
not write to the disk at all, so it won’t mess anything up.
Dan-O-Tek says:
July 12, 2017 at 1:46 pm
Always set contacts, photos, app data etc. to back up to Google (assuming Android) then your phone is nothing but a fancy internet gateway. I
routinely pop my SIM in and out of several phones based on what I’m doing, sports, travel etc.
No excuse to not have everything backed up to the cloud immediately.
notarealemail says:
July 12, 2017 at 2:26 pm
Or, back it up to your own system and skip ‘the cloud’.
Darren says:
July 12, 2017 at 3:54 pm
No thanks. I don’t trust cloud services to hold my personal data.
denis says:
July 13, 2017 at 2:24 am
I run nextcloud on my own server, great for photos etc.
Moryc says:
July 12, 2017 at 11:33 pm
Or save everything on external SD card and make copies from it every week, in case it fails…
Martin says:
July 13, 2017 at 1:05 am
I can only support the call for backups.

But: Do not transfer any personal (or of similar personal value) data to a cloud service. Keep your own data on your own machines. Or at least
use very strongly encrypted archives.
m_a_s says:
July 13, 2017 at 3:39 am
Too trusting he is for the training.
mime says:
July 12, 2017 at 1:46 pm
Nice work!
I once ‘jumpstarted’ a drowned phone by applying voltages to strategic points in a phone:
https://hackaday.io/project/5122-jumpstarting-a-drowned-phone
But that requires a bit of luck.
NiHaoMike says:
July 12, 2017 at 7:29 pm
I did something similar with a Kindle Fire, not because it fell in water, but because one of the voltage regulators in it wasn’t designed for a
constant high load and failed after a few months of using the tablet as an altcoin miner. (I also had it overclocked at one point, which might have
been a contributor to the failure.) For what it’s worth, that was a month or two ago and it’s still happily mining. The way things are going, there’s
a very high chance the tablet would outlast the altcoin I’m currently mining with it.
David says:
July 12, 2017 at 2:24 pm
ha an simple dd command i don’t think so! I think we would of seen this an dozen times and would be well documented
Night says:
July 12, 2017 at 2:34 pm
If you can access device via SD interface then dd is enough to retrieve the 1:1 image of the card. After that you can mount image, run recovery
programs on it or do whatever you can do with normal disk. In this case I guess card/flash didn’t get corrupted after it was flooded, it just
couldn’t be accessed anymore by phone as other interface features was damaged, but not eMMC chip itself.
Night says:
July 12, 2017 at 2:26 pm
Nice work indeed, but better writeup wouldn’t hurt. There are few videos on youtube (just search “emmc sd”) that describe process of accessing
eMMC chip via SDcard interface, for those interested in replicating the recovery.
David says:
July 12, 2017 at 2:30 pm
That isn’t the issue..he prob sent the dump out to a real data recovery shop.
jaja says:
July 13, 2017 at 2:18 am
If there’s no encryption the data is either a FAT filesystem or an ext2/ext3/ext4 filesystem. You can just mount the dump on any linux computer,
no need for expensive ‘data recovery’ services. If the data is encrypted there’s probably nothing a data recovery service can do either.
David says:
July 12, 2017 at 2:41 pm
Inversion and Scrambling of (XOR) and or encryption?
bobby staples says:

July 12, 2017 at 2:44 pm
https://www.exploitee.rs/index.php/Exploitee.rs_Low_Voltage_e-MMC_Adapter How to do it with correct voltage level shifting. Its a miracle he didn’t
destroy it immediately with the SD voltage.
Unferium says:
July 12, 2017 at 2:56 pm
My laptop and table PCs contains MMC on the SDcard bus (sdio bus / MMC-1, but no SD-host on the MMC-0 bus for the tablet),
there are many low voltage capable SDcards that switch mode to the lower voltage.
So it should work, also, as has been done before with cheap brand new 64GB eMMC modules: (a post on HaD has been and buried in time)
Unferium says:
July 12, 2017 at 2:57 pm
*Tablet PC:
The T key didn’t register
notarealemail says:
July 12, 2017 at 3:12 pm
Table PCs sounds awesome though…
pelrun says:
July 12, 2017 at 2:57 pm
Or he read the datasheet, which quite clearly states that 3.3v is supported. Such a miracle.
Alan McCormick says:
July 12, 2017 at 6:57 pm
Laughed just because when they do this kind of thing on Law & Order/CSI/etc they basically wave their hands over the phone and PRESTO! No
soldering, no hacking – just the usual “then a miracle occurs” BS.
The aforementioned miracle reference explained https://s-media-cache-ak0.pinimg.com/736x/d6/e7/54/d6e754d24aaef324c1595e68583ace7a.jpg
JDX says:
July 13, 2017 at 8:57 am
Cut the TV shows some slack–they have precious little time to tell the story between commercials, and the details of how data gets recovered
from a phone are of no interest to the majority of viewers.
Ostracus says:
July 13, 2017 at 9:26 am
Except it creates false expectations when it comes time to do the real thing. “Why does this take so long?” “Why does this cost so much
to do?” “Why can’t you do it?”
Sjaak says:
July 12, 2017 at 10:21 pm
Wouldn’t it be easier to find the right resistors on the main board? After power the board while keeping the cpu in reset state..
I like soldering but this looks very hard..
Martin says:
July 13, 2017 at 1:11 am
Do you mean “connection points” when you say “resistors”?

No, definitely not. You know you have a partially destroyed board, otherwise the phone would function normally. So you can not rely on anything
behaving normal and not destroying the data you want to recover, when you try to power it and “keep the CPU in RESET state”.
The safest way is to physically separate the chip from this board.
Mike Aberle says:

July 13, 2017 at 3:24 am
It is 2017 and there are still people who don’t backup their data.
Ostracus says:
July 13, 2017 at 5:27 am
You say that like it’s a surprise. The first person who solves the “lazy” problem will make millions.
jawnhenry says:
July 13, 2017 at 7:49 am
No; billions. He already has, quite a while ago. The name is William H. Gates, III.
jawnhenry says:
July 13, 2017 at 8:01 am
Disclaimer: this is an absolute eMMC/flash memory and phone neophyte asking this, so here goes–
It seems as if this an awfully labor (labour for your grammar-Nazi spell-checker) intensive recovery process. Would this work?: buy an exact (or very
close) copy of the ruined phone and with some deft soldering work, transfer the OLD memory device into the NEW phone? At the very least, you’d end
up with a new phone if you were careful.
So, what do you think? Does this stand a chance of working, and saving a ton of LABOUR in the process?
jaydcarlson says:
July 13, 2017 at 8:34 am
You’d have to re-ball the BGA after removing from the old phone to be able to “transfer” it over. Then you’d have to reflow the chip, which doesn’t
sound particularly fun (large pin-count 0.5mm pitch BGA, with no visible PCB alignment marks). To me, this seems like substantially more work
than soldering a half dozen wires onto the chip, which is quite commonly done by electronics engineers during board bring-up debugging.
jawnhenry says:
July 13, 2017 at 11:09 am
@Annie–
Are you saying that, using a socket, this technique of “eMMC-from-wet-phone” →”new-phone”. would work, with substantially less effort
than utilized in this article? ([jaydcarlson] totally lost me with “…soldering a half dozen wires…”)
Thanks.
Ren says:
July 13, 2017 at 11:40 am
See her link in a comment above showing a BGA socket, you may have to connect as many wires, you just won’t need 10,000x
microscope to do it! B^)
jaydcarlson says:
July 13, 2017 at 2:34 pm
Annie is right that the socket is great, and, honestly, for $100, I’d probably just buy one of those sockets with an integrated USB-to-
MMC controller, so you can unsolder the eMMC, remove the balls from it (just so you get good contact with the socket), and you’re
good to go. That’s how the pros would do it.
My only point is that green-wiring a few pins of a 0.5mm pitch BGA isn’t the end of the world; you certainly don’t need a 10,000x
microscope (I don’t use any microscope when doing that work). Just use pre-tinned tiny-gauge wire, tape the package down, and
use plenty of flux. It’s just tedious, so if I had the choice of green-wiring to an SD card reader (which has pretty coarse pitch), or
another 0.5mm BGA landing pattern on another phone, I’d pick the SD card reader (as the person in this post did).
I have no idea why you would think it’s easier to re-solder the chip onto another phone. You have a high probability of not aligning
the chip properly, which would cause open connects and shorts. You’d probably have to redo it a dozen times to get it working, and
by that time, your hot air gun would have blown off most of the 0201 passives on the board, and completely destroyed the eMMC
flash to begin with. I’m assuming you don’t have a professional BGA rework station, which would obviously make this whole
process much simpler.
jawnhenry says:
July 13, 2017 at 3:29 pm
OK, OK.
“…@Annie–
Are you saying that, using a socket, this technique of “eMMC-from-wet-phone” →”new-phone”. would work, with substantially less
effort than utilized in this article? ”
So which/what technique would you recommend to a neophyte, who found himself in the same position as [Trochilidae], but whose
only assets include a lifetime of soldering ham-fisted components and a passable use of Linux?
Or, as a friend of mine would ask, which technique would YOU use, if you didn’t want ‘…to make a career out of this…?
Fred says:
July 18, 2017 at 11:11 pm
@Annie : Just had a skim of that cookbook and I’m definitely going to give it a proper read when I get a chance. Excellent link!
Thanks!
Dan says:
July 13, 2017 at 3:54 pm
Co-worker here – I took over once the image had been extracted. Certainly not the type of thing I’ve done before but figured with a Linux box and
Google I’d stand a chance at getting something out.
Started by running parted against the dumped image which showed a promising list of partitions, but failed to identify the file system type of the crucial
userdata partition:
> sudo parted /dev/loop0 print

Model: Loopback device (loop)
Disk /dev/loop0: 7818MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags

1 131kB 67.2MB 67.1MB ext4 modem msftdata
2 67.2MB 67.8MB 524kB sbl1
3 67.8MB 67.8MB 32.8kB DDR
4 67.9MB 68.9MB 1036kB aboot legacy_boot
5 69.4MB 69.6MB 205kB rpm legacy_boot
6 69.9MB 70.4MB 410kB tz legacy_boot
7 70.5MB 70.5MB 32.8kB sdi
8 70.5MB 71.0MB 524kB utags
9 71.0MB 73.1MB 2097kB logs
10 73.1MB 75.5MB 2388kB padA msftdata
11 75.5MB 76.5MB 1036kB abootBackup
12 77.0MB 77.2MB 205kB rpmBackup
13 77.5MB 78.0MB 410kB tzBackup
14 78.1MB 78.1MB 32.8kB sdiBackup msftdata
15 78.1MB 78.6MB 524kB utagsBackup
16 78.6MB 79.7MB 1077kB padB msftdata
17 79.7MB 81.3MB 1573kB modemst1
18 81.3MB 82.8MB 1573kB modemst2
19 82.8MB 83.3MB 500kB hob
20 83.3MB 83.4MB 32.8kB dhob
21 83.5MB 85.1MB 1573kB ext4 fsg
22 85.1MB 85.1MB 1024B fsc
23 85.1MB 85.1MB 8192B ssd
24 85.1MB 86.1MB 1049kB sp
25 86.1MB 86.3MB 131kB cid
26 86.3MB 89.4MB 3146kB ext3 pds
27 89.4MB 93.6MB 4194kB logo
28 93.6MB 97.8MB 4194kB clogo
29 97.9MB 106MB 8389kB ext4 persist msftdata
30 106MB 107MB 524kB misc
31 107MB 117MB 10.4MB boot
32 117MB 128MB 10.5MB recovery
33 128MB 129MB 1049kB deviceinfo msftdata
34 129MB 146MB 16.8MB ext4 ftmlog msftdata
35 146MB 706MB 560MB ext4 cache msftdata
36 706MB 1863MB 1158MB ext4 system msftdata
37 1863MB 1872MB 8389kB kpan
38 1872MB 7784MB 5913MB userdata msftdata
Spent a lot of time investigating various recovery tools which all seemed to know nothing about the partition in question. I dd’d out the userdata partition
out then spent even more time googling and hitting dead ends, but eventually discovered it was F2FS. While my Ubuntu box claimed to support F2FS,
it kept hanging when I tried to mount it. Installed f2fs-tools which allowed me to successfully fsck the partition and dump the directory structure (and
prove I was finally on the right track!). Another tool allowed me to dump a single file from the file system. A bit of hacking the 2 tools together resulted
in a program that extracted the whole file system with directories.
At that point finding the photos was trivial. Notes recovered from a nightly backup. Contacts and SMS extracted with a few SQL queries. Wife very
happy.
jawnhenry says:
July 13, 2017 at 6:56 pm
Many, many thanks.
Unlockdtdd says:
September 30, 2017 at 5:53 am
Hi, I have an I9305 dead phone. I read user data partition already but dont know which tool can read this file then I am able to rescue data
from it. Pls help me this software for windows. Thank you.
prashant says:
August 11, 2017 at 4:32 am
Great work indeed! Until now I used to know that Data recovery software is one and the all of recovering lost data, but now seeing this new facet of
recovering yesteryears photos from a dead and damaged the phone. Last time I used the photo recovery software from Stellar Phoenix, but it isn’t for
a destroyed device! Thanks bro for this unique piece of info!
Alex says:
July 26, 2018 at 5:12 pm
I have a Blu pure XL running Android 5.1 that was stuck in bootloop about a year ago. It wouldn’t get past this point so I gave up and tried to recover the
files with ADV, to no avail. It also did not respond to being powered on probably 49 times of 50. My question is, would it be cheaper to try and have the
phone serviced to a point where I can turn it on and recover the data, or would it be cheaper to have the data recovered directly from the emmc?

eMMC To SD Hack Rescues Data From A Waterlogged Phone - Hackaday

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

eMMC To SD Hack Rescues Data From A Waterlogged Phone - Hackaday

Uploaded by

Copyright:

Available Formats

3/10/2019 eMMC to SD Hack Rescues Data from a Waterlogged Phone | Hackaday

EMMC TO SD HACK RESCUES DATA FROM A

July 12, 2017

Posted in Cellphone Hacks

← HACKADAY PRIZE ENTRY: ONE-HANDED, NO-LOOK KEYING

LASER CUTTING ORRERIES →

57 THOUGHTS ON “EMMC TO SD HACK RESCUES DATA

Reply Report comment

Reply Report comment

Reply Report comment

Reply Report comment

Was it hard getting the pin-out for the eMMC?

Reply Report comment

It’s in a JEDEC standard.

Reply Report comment

Kevin Harrelson says:

Reply Report comment

Reply Report comment

Reply Report comment

Reply Report comment

Reply Report comment

more likely he discovered modern phones encrypt EVERYTHING

Reply Report comment

Adam Fabio says:

Reply Report comment

Reply Report comment

Jeff NME says:

Reply Report comment

Reply Report comment

Reply Report comment

Reply Report comment

Or, back it up to your own system and skip ‘the cloud’.

Reply Report comment

No thanks. I don’t trust cloud services to hold my personal data.

Reply Report comment

I run nextcloud on my own server, great for photos etc.

Reply Report comment

Reply Report comment

I can only support the call for backups.

Reply Report comment

Too trusting he is for the training.

Reply Report comment

But that requires a bit of luck.

Reply Report comment

Reply Report comment

Reply Report comment

Reply Report comment

Reply Report comment

Reply Report comment

Reply Report comment

Inversion and Scrambling of (XOR) and or encryption?

Reply Report comment

bobby staples says:

Reply Report comment

Reply Report comment

Reply Report comment

Table PCs sounds awesome though…

Reply Report comment

Reply Report comment

Alan McCormick says:

The aforementioned miracle reference explained https://s-media-cache-ak0.pinimg.com/736x/d6/e7/54/d6e754d24aaef324c1595e68583ace7a.jpg

Reply Report comment