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!

Improve this question
9
  • 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
    Commented Jul 2, 2019 at 1:59
  • 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
    Commented Jul 2, 2019 at 11:31
  • 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
    Commented Jul 2, 2019 at 12:23
  • 1
    perhaps this could help? sorry this isn't that good: youtube.com/watch?v=uMoVqoVuPns
    – Axiumin_
    Commented Aug 3, 2019 at 2: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
    Commented Aug 4, 2019 at 12:58

1 Answer 1

Reset to default
7
+50

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:

Improve this answer
5
  • 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 ♦
    Commented Aug 22, 2019 at 3: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
    Commented Aug 22, 2019 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
    Commented Aug 22, 2019 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 ♦
    Commented Aug 22, 2019 at 15:29
  • @Firelord yeah that was the actual story behind famous Apple vs. FBI case.
    – Irfan Latif
    Commented Aug 22, 2019 at 18:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .