SSD repair

[karamba]

Someone brought me an eSATA SSD from Dell XPS laptop that stopped being recognized by BIOS. They replaced it with a new SSD but want to save the data. It is mainly family photos so do not grant $2000+ fee  that a business that specializes in data retrieval wants.  I myself do not have the experience and equipment to try to move the chips to another board.  What are the options ? Maybe someone knows a shop  that does not charge a hand and a leg for this ?

[Jeroen3]

Impossible. For $2000 you can't even buy the software required. NAND recovery is very difficult.

[kripton2035]

and everything almost inside is encrypted. even if you move the chips, you won't be able to read anything but garbage.

[rmel]

and everything almost inside is encrypted. even if you move the chips, you won't be able to read anything but garbage.

Theoretically speaking, would it be possible to transplant the chips to a drive of the same model and be able to access the data?  Just thinking out loud, if all the data needed to decrypt the data (encryption keys, etc) on the chips is located on the chips themselves and nothing is left on the old drive (in the controller perhaps or some kind of support ram/eeprom), it might be possible to extract that data?

[Rasz]

Sure, if all the chips, including controller, are fully operational. This would happen if:
- drive failed mechanically, bad connector, cracked solder balls
- fuse, and only the fuse blew (haha)
- one of the caps on the drive shorted

[Mr. Scram]

and everything almost inside is encrypted. even if you move the chips, you won't be able to read anything but garbage.

As far as I'm aware, most models don't encrypt data unless instructed to do so. That being said, desoldering chips and such is an absolute last resort.

[Mr. Scram]

Does it being an eSATA SSD mean it's an external SSD? Does it respond to other systems at all? Did you try removing it from its case?

[Syntax Error]

Do you have the original SSD that was - I assume - inside the external eSATA case? If so, what is the make and model? A photo of the SSD to help answer your question?

[rmel]

- fuse, and only the fuse blew (haha)

With my luck, I would only discover this after I transplanted the chips...

[karamba]

and everything almost inside is encrypted. even if you move the chips, you won't be able to read anything but garbage.

Theoretically speaking, would it be possible to transplant the chips to a drive of the same model and be able to access the data?  Just thinking out loud, if all the data needed to decrypt the data (encryption keys, etc) on the chips is located on the chips themselves and nothing is left on the old drive (in the controller perhaps or some kind of support ram/eeprom), it might be possible to extract that data?

As far as I know the encryption keys are stored in the controller. So of course if I tried to move the chips that would involve moving the controller too.

[karamba]

Do you have the original SSD that was - I assume - inside the external eSATA case? If so, what is the make and model? A photo of the SSD to help answer your question?

Why would you assume that a laptop ssd would be store in an external storage, See the OP

[fzabkar]

and everything almost inside is encrypted. even if you move the chips, you won't be able to read anything but garbage.

As far as I'm aware, most models don't encrypt data unless instructed to do so.

AIUI most models now encrypt the data by default. The encryption key is stored within the controller. The data are decrypted transparently on the fly without the user realising that this is happening. The only time the user gets involved is when they set a password. This password encrypts the key. The SSD can be cryptographically erased in an instant by throwing away the original key and creating a new one.

[fzabkar]

Someone brought me an eSATA SSD from Dell XPS laptop that stopped being recognized by BIOS. They replaced it with a new SSD but want to save the data. It is mainly family photos so do not grant $2000+ fee  that a business that specializes in data retrieval wants.  I myself do not have the experience and equipment to try to move the chips to another board.

You need to determine whether the problem is at the hardware or firmware level. Most SSDs become unresponsive as a result of firmware corruption (Flash Translation Layer), or a bad NAND chip. Since the FTL is stored in NAND, there is no point in transferring chips to another board. The best you can hope for is that the SSD has an easily solvable power fault, either in the protection circuitry or in the DC-DC converters or load switches.

If you can upload detailed photos of each side of the PCB, I can help you to measure the voltage test points.

I have compiled a database of ICs:

http://www.users.on.net/~fzabkar/Datasheets/DATAURLS.HTM

[Syntax Error]

I thought by eSATA the disk was connected via an external SATA port?

So it's just the SSD drive. What kind? M2.5 / M2 drive?

Anyway, good luck hot-air desoldering those chips. What ever they are.

[rmel]

and everything almost inside is encrypted. even if you move the chips, you won't be able to read anything but garbage.

As far as I'm aware, most models don't encrypt data unless instructed to do so.

AIUI most models now encrypt the data by default. The encryption key is stored within the controller. The data are decrypted transparently on the fly without the user realising that this is happening. The only time the user gets involved is when they set a password. This password encrypts the key. The SSD can be cryptographically erased in an instant by throwing away the original key and creating a new one.

Seems that's not a reliable assumption:  https://www.stationx.net/think-your-ssd-offers-rock-solid-encryption-heres-why-its-time-to-think-again/

Here's a quote from the article:

The researchers were able to successfully attack the following SSD models:

Crucial MX100, MX200 and MX300
Samsung Samsung 840 EVO, 850 EVO, T3 Portable and T5 Portable

No proper link between the DEK and the AK.
The researchers said they were able to connect to the drive’s debug interface on its circuit board. This gave them direct access to the drive’s firmware, enabling them to modify the password-checking routine to accept any passphrase.

A blank master password by default.
With the Crucial MX 300 SSD, the researchers found that the device’s master password was set as an empty string by default. If this remained unaltered, it meant that the data could be unlocked simply by submitting an empty field!

[Rasz]

The researchers were able to successfully attack the following SSD models:
Crucial MX100, MX200 and MX300
Samsung Samsung 840 EVO, 850 EVO, T3 Portable and T5 Portable

No proper link between the DEK and the AK.
The researchers said they were able to connect to the drive’s debug interface on its circuit board. This gave them direct access to the drive’s firmware, enabling them to modify the password-checking routine to accept any passphrase.

A blank master password by default.
With the Crucial MX 300 SSD, the researchers found that the device’s master password was set as an empty string by default. If this remained unaltered, it meant that the data could be unlocked simply by submitting an empty field!

NAND management involves data whitening, scrambling to get rid of bad patterns (like in Ethernet, or PCIE). Nowadays maybe to cut costs [you already have AES block in silicon] most controllers simply encrypt all data all the time to ensure fully random distribution.
https://joshuawise.com/projects/ndfrecovery
https://superuser.com/questions/986387/why-does-my-ssd-internally-encrypt-data-even-without-a-password-set

[rmel]

Thanks for the link.  I've added that to my reading list.