EMMC To SD Hack Rescues Data From A Waterlogged Phone

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.

59 thoughts on “EMMC To SD Hack Rescues Data From A Waterlogged Phone

  1. >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

      1. 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.

      2. 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.

    1. 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)

      1. 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.

  2. 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.

      1. 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.

    1. 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.

    1. 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.

    1. 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.

  3. 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.

    1. 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.

    1. 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)

    1. 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.

      1. 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?”

    1. 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.

  4. 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?

    1. 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.

      1. @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.

        1. 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.

        2. 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…?

  5. 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.

      1. 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.

  6. 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!

  7. 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?

Leave a Reply to Alan McCormickCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.