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.
Good work!
Maybe a fellow could rig this up with pogo pins and start a recovery service in his apartment.
Such adaptes are already available for ~100EUR from company allsocket (I am not related to that company in any way)
Thanks!
Was it hard getting the pin-out for the eMMC?
It’s in a JEDEC standard.
JEDEC standard means that you have to pay to see it, from what I understand.
But do you think that different manufacturers will have the same pinouts for the same eMMC model? I am not sure,
Anyone knows?
Thanks for the reply. Is there any a chance I can get a datasheet/pinouts for the most often used eMMC model?
NAND pinouts are also standardized. It’s the timing and geometry that are hard to get ahold of.
I thought I read something similar (not necessarily same problem) on Hackaday last year and found the article: http://hackaday.com/2016/11/18/roll-your-own-64gb-sd-card-from-an-emmc-chip/
>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
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…
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.
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.
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)
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.
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.
Or, back it up to your own system and skip ‘the cloud’.
No thanks. I don’t trust cloud services to hold my personal data.
I run nextcloud on my own server, great for photos etc.
Nice job ! Some notes about data recovery from Android devices.
Since Android is based on Linux, I strongly recommend using a Linux-based OS for Android data recovery. Data can be easily read off of eMMC dump using standard Linux tools. Partition table will most likely be GPT. User data partition will be formatted as either ext4 or f2fs file systems. Read-only /system partition is usually formatted as ext4. There are a lot of other internal system partitions like kernel/initrd, modem, etc which are only useful if you want to replace or upgrade your device’s storage. For basic data recovery, you only need the User data partition.
Or save everything on external SD card and make copies from it every week, in case it fails…
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.
Too trusting he is for the training.
“The Cloud” is nothing but someone else’s computer that you don’t control.
I’ll back up my own phone data.
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.
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.
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
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.
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.
That isn’t the issue..he prob sent the dump out to a real data recovery shop.
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.
Inversion and Scrambling of (XOR) and or encryption?
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.
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)
*Tablet PC:
The T key didn’t register
Table PCs sounds awesome though…
Or he read the datasheet, which quite clearly states that 3.3v is supported. Such a miracle.
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
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.
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?”
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..
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.
It is 2017 and there are still people who don’t backup their data.
You say that like it’s a surprise. The first person who solves the “lazy” problem will make millions.
No; billions. He already has, quite a while ago. The name is William H. Gates, III.
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?
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.
@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.
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^)
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.
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…?
@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!
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.
Many, many thanks.
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.
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!
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?