An EMMC Gives Up Its Secrets

An increasing phenomenon over the years since mobile phones morphed from simply telephones into general purpose pocket computers has been that of the dead device taking with it some treasured digital resource. In most cases this means the device has died, but doesn’t necessarily mean that that the data has completely gone. Inside the device will be an eMMC flash chip, and if that can be read then the data is safe. This applies to some single board computers too, and thus [Jeffmakes]’ adventures in recovering an eMMC from a dead Raspberry Pi CM4 are particularly interesting.

The whole thing relies on the eMMC presenting the same interface as an SD card, so while it comes in a multi-pin BGA package it can be addressed with surprisingly few wires. Using the PCB from another dead CM4 he traced the relevant connections from eMMC to SoC pads, and was thus able with some very fine soldering to construct an interface for an SD card reader. The disk could then be imaged in its entirety.

This work will be of huge use to experimenters who’ve fried their Compute Modules, but of course the information it contains will also be of use to retrieve those photos from the phone that fell in the bath. It’s not the first time we’ve taken a look at someone’s efforts in this area.

32 thoughts on “An EMMC Gives Up Its Secrets

  1. Having been in the audio business for a while I have a old bulk demagnitizer sitting around somewhere. Would passing it over the eMMC a couple of time erase, or at least mess up any data in it. Presumably it would not be useable again?

          1. That was my thought. Takes little effort to shatter the chip. Years back I tried a bulk erasing electromagnet on early flash storage as an experiment with no success, I assume modern emmc would be no different, so physical destruction would be ideal if you wanted to ensure it was unrecoverable..

    1. From my understanding a demagnetizer wouldn’t have any significant effect on flash memory like an EMMC. The magnetic field required to “erase” the data stored would likely have adverse side effects to your health. But don’t quote me on that.

    2. EEPROM and NAND/NOR FLASH all effectively store bits the same way. They move some electrons in between two layers of insulation where they will remain for a long time.
      (ref: https://www.rfwireless-world.com/images/Flash-memory.jpg )

      I guess in a lot of ways you could think of (1-bit in an EEPROM or a Single-Level Cell FLASH) rubbing a balloon on your hair and building up a static charge.
      Would a old bulk demagnitizer cause a static charge on balloon to dissipate ? My guess would be no and therefore it would not work on EEPROM or FLASH.

      There are only 2 ways that I can think of to destroy data on a flash chip.
      Overwrite all data on the chip (which will lower the lifetime of the device).
      SLC 1 binary value per cell (2 voltage levels); lifetime of about ~100k P/E cycles
      MLC 2 binary values (4 voltage levels); lifetime of about ~10k P/E cycles per cell program/erase cycles
      TLC 3 binary values (8 voltage levels); ~3k P/E cycles per cell
      QLC 4 binary values (16 voltage levels); ~1k P/E cycles per cell
      PLC 5 binary values (32 voltage levels); ~300 P/E cycles per cell

      Or if the chip is no longer needed grinding the chips into dust (e.g. https://www.youtube.com/willitblend/videos )

      The second way is the only one I would trust to be 100% sure that all data was gone for good. That none was sitting on a blocks marked as bad.

    3. High voltage, heat, and physical trauma are the methods which work best with solid state storage. All could be easily achieved (by me) in trying to follow in the authors footsteps =)

  2. I think the best attitude is to not trust flash storage for interesting data. I see stories all the time in the newspaper about house fires and people losing all their stuff. This happened to Richard Stallman early in his life and it affected him greatly. Put yourself in these peoples shoes for just a minute and maybe it will motivate you to have a personal backup policy.

    1. Fires: Fireproof safe, check how many minutes or hours it can last. Local fire department will likely put the fire out before 1 hour has passed.
      I have 1 live image + 2 backups in separate places on separate devices, different models, different manufacturers. Yeah, after a drive firmware failure on all models of one drive worldwide I updated my threat model to: Do not trust the vendor.

  3. Stealing the topic here, but I had a lot of problems with dying SD cards in RPi’s and was suggested to use USB sticks instead for storage. What is the difference in (presumably flash) technology between SD cards, USB sticks that make the latter more suitable for SD cards (and while we’re at it, what’s the difference of eMMC to them)?

    I decided to go the “log2ram” route and try to do proper shutdowns with an actual shutdown button and have had no SD cards die on me since:
    https://iivq.net/making-a-nas-out-of-my-raspberry-pi-4/

    1. The biggest problem with dying SD cards (or better: corruption) is that many or all SD cards buffer any writes in some ram first, before actually writing it to flash. So if you write to the SD card and then turn off the power, there is a good chance that some of the data was still hanging around in the ram and was not written to the flash storage. Result: corrupted data.

      Some SD cards have more problems with this than others.

      As there is no way to trigger a commit of ram to flash, on an SD card, all you can do is wait some time after the last write to the SD card and turning off the power. But it will stay a guessing game.

      I think the OS tries to take it into account, but if you switch off the PI just like that, there is no way to prevent corruption from happening.

      1. Thx, that doesn’t resemble what I noticed in my PI’s. I have had about 6 SD cards die, as in they would not mount anymore and a low-level filesystem write with dd would not recover.
        My camera eats SD cards, but there they generally stay readable but become unwriteable.

        It’s a shame SD cards have no SMART data available (afaik) to check how far gone they are.

        1. A magic 8-ball fell out of the sky and landed on my bad place. Once I regained consciousness, I picked up the 8-ball and wiped the blood away with my shirt: “Your power supply is made of poo.” What a strange fortune cookie. I’ll never order the kung pao shrimp again.

    1. Shame on them for not making schematics and board views available. Shame on them for not releasing their Management-Engine-like proprietary VPU firmware. Shame on them for using a proprietary chip that’s blocked for sale on the open market.

      Frankly, the raspi foundation isn’t very open source friendly at all. No product they ship even remotely qualifies as such.

      1. In order to use any chip that is relevant nowadays you need to sign away your company or your soul if you don’t have one. The raspberry pi foundation is obligated to keep the proprietary software and schematic designs ship designs system designs proprietary they are doing a dame good job. If you don’t believe me then try to use 8 pin SPI to write to a micro SD card! talk to me after you’ve talked to the SD association

  4. I suppose this is a reason not to do full disc encryption, as encryption presumably would add a layer of difficulty to getting the data back.
    Of course that only makes sense when it’s more important to you to recover the data than to avoid having it fall into another’s hands, which depends on the nature of the data.

    1. If you backup the header there is no argument against full disk encryption. The header is the only part that causes loss of all data if it corrupts. If a single block corrupts the IV of the next block will allow to resume the decryption process.

      1. «If a single block corrupts the IV of the next block (…)»
        That’s not how disk encryption works.
        One of the core principles of disk encryption is that data retrieval and storage should be fast, no matter where it’s located on the disk. This is typically accomplished by using the sector number, in encrypted form, as IV.

        1. Imagine what you just said and then think very carefully how it would contradict me at all. Anyway, thanks for confirming it is trivial for the owner to know the next IV. Or did you mean to inanely write from an attacker perspective when data recovety by the owner was the subject?

Leave a Reply to IIVQCancel 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.