8

Phone worked perfectly. Then one day completely dead, nothing at all. It may have been that "one day" was after some time of laying around, cannot recall.

Model: Android AT&T Samsung Galaxy S3 (SGH-i747 SKU S9255)

Already tried;

  • Charging phone: no visual output at all, no leds
  • Removing battery while charging: no visual output at all, no leds
  • Removing SIM and SD card: no visual output at all, no leds
  • Attempt to turn on: no visual output at all, no leds

I need to get our family photo's off this phone (stored on internal memory). I care less about the hardware/phone itself.

Thank you for any help you can offer!

Roel Van de Paar
  • 133
  • 1
  • 9
  • 2
    Have you looked at your battery state of charge? If its relatively high, then you could just try to charge it up with test probes (very carefully) with a TP4056 module up to 3.7 or 3.8V. That may get you into a position where you can turn the phone on. – TestDeviant Jul 02 '19 at 12:23
  • 2
    Try this: Take off the back of the phone, then look for the chip that holds all your data. If that doesn't work I don't know what will. – Jeffrey Jul 02 '19 at 01:59
  • If you are talking about the SD card, it was already removed, and it does not hold the data. – Roel Van de Paar Jul 02 '19 at 05:22
  • 1
    I assume Jeffrey was talking about soldering out the flash memory chip. In detail the Samsung KMVTU000LM in the S3 teardown. Once you have the chip it can be theoretically be connected to a flash memory reader that can handle such chips for reading out the content. – Robert Jul 02 '19 at 11:31
  • You mean if the battery charge is relatively low? The battery in this model is just a replaceable one. – Roel Van de Paar Jul 29 '19 at 09:31
  • @Robert thank you for that reference. Do you have detail about 1) how to get the chip off, 2) how to connect it to a flash memory reader, 3) how to read the data? (Please provide full answer below to go in the run for the bounty...) – Roel Van de Paar Jul 29 '19 at 09:36
  • 1
    perhaps this could help? sorry this isn't that good: https://www.youtube.com/watch?v=uMoVqoVuPns – Axiumin_ Aug 03 '19 at 02:39
  • 1
    the chip off method is pretty useless when userdata is encrypted. what if just the usb connector is broken? did you try another battery or did you charge the battery outside of phone (universal external charger)? – alecxs Aug 04 '19 at 12:58
  • @alecxs the userdata is not encrypted. USB connector + other battery - great ideas. Will test more. Thank you – Roel Van de Paar Aug 04 '19 at 23:49

1 Answers1

7

It seems like a hardware issue (not directly related to storage), better try to get fixed. Unless the device boots at least to some bootloader stage (like fastboot or odin or edl) you can't access its memory. Or if the data is extremely important, contact some professional data recovery service which usually do one of the two:

  • Access eMMC directly using some low level protocol like JTAG. Special equipment - usually called some kind of box e.g EasyJtag - is used to make communication with eMMC.

  • Or using a chip-off method i.e. by removing eMMC chip from board.

    Most devices built in the last few years use eMMC flash devices as their persistent storage. Usually eMMC and RAM are bundled in a single package; eMCP. So a compatible eMMC/eMCP reader can be used to recover data by connecting it to PC. A range of such readers/sockets is available on online stores from a number of chinese manufacturers - e.g. Allsocket and KZT - to match with different sizes and shapes of BGA packages.

Please note that there are other factors as well which may define the destiny of data recovery through JTAG or a chip-off method. Data recovery is very less probable or impossible if:

  • eMMC is dead i.e. it has reached the limit of E/P cycles it was designed for.
  • You were using encryption (FDE/FBE) on your device. Starting with Android 5.0 encryption is hardware-backed. Quoted from here:

    By default, the decryption key is stored in the hardware-backed storage
    ...
    bear in mind that extracting the decryption key via chip-off or any other low-level method is not possible, so if you do a chip-off you won’t get the decryption key and won’t be able to decrypt the data.

RELATED:

Irfan Latif
  • 20,353
  • 3
  • 70
  • 213
  • 2
    Hypothetical: would it be worth it for a person to somehow manage to get data out of emmc (encrypted it is), wait for a couple of years or probably a decade to have serious advancements in affordable parallel processing hardware (like gpu), and then brute force the way out of that encrypted data? I see bruteforce the only method (unless social engineering gives us the result) if decryption key cannot be chipped off. – Firelord Aug 22 '19 at 03:39
  • 2
    @Firelord interesting. To decrypt the whole partition (FDE) or whole filesystem (FBE), master key is required which is encrypted with another middle key, and stored at crypto footer or in /data/misc/vold/user_keys/[ce|de]/<User_ID>/. An encrypted private RSA key is also stored along with master key, which is provided to KeyMaster, which decrypts RSA key and then uses it to sign the middle key. Middle key in turn is derived from user credentials and a random salt also stored along with master key. So we need two things: user credentials and unencrypted RSA key; later only known to KeyMaster. – Irfan Latif Aug 22 '19 at 14:00
  • 2
    KeyMaster module runs in a secure environment, e.g. TEE, which uses main CPU but is completely isolated from main OS. ARM's TZ is an implementation of TEE. Qcomm's implementation of TZ is QSEE in which KeyMaster runs. Ideally KeyMaster should not leak any cryptographic information, but it's been hacked, though only useful if device is working. For off the device attacks user password as well as RSA key is to be brute forced. And the later seems impossible. So this approach doesn't look like a matter of time. That's what my understanding is. – Irfan Latif Aug 22 '19 at 14:06
  • 1
    I see. I didn't know about RSA key. I only thought that user credentials with a random salt were processed into a key for encryption, hence asked about brute force. Now it all makes sense that if the device is encrypted and dead all hope is lost to recover data from it. – Firelord Aug 22 '19 at 15:29
  • @Firelord yeah that was the actual story behind famous Apple vs. FBI case. – Irfan Latif Aug 22 '19 at 18:03