Samsung SSD Failed Processor - Options?

[mattsbsmith]

Hi,

I have a Samsung SSD (Model: PM 851) that has recently failed. I have had it looked at by 2 data recovery companies who have independently confirmed that the processor/controller (which from my research I've discovered to be a 4th-generation 3-Core Cortex-R4 Samsung MDX Controller [S4LN045X01-8030]) has failed. I have been advised by the companies that the data is likely still residing on the NAND chips and that technically the data could be retrieved using 'chip off' techniques. They have further advised that this would be a futile exercise however as the processor/controller uses a unique XOR pattern which obfuscates the data, rendering the data, should it be recovered successfully, unreadable.

I have two questions that I am hoping someone may be able to help answer:

1. Is there any way of emulating the controller/processor programatically i.e. decoding and reassembling the data by finding the XOR key? Has anyone had success doing this?

2. Is there any way of repairing the controller or replacing it with another (set to use the same XOR key)? Again, if anyone has done this I'd like to know if it was successful.

Please understand that my knowledge of all this is very limited.

Many thanks in advance,
Matt

[45Overload]

Interesting problem.  Here is a great example of why people might be reluctant to use SSD's.  They just don't give you any warning.  Is it possible to contact anybody at Samsung about this?  A photo of your SSD would be helpful here.  Perhaps the fastest way might be to purchase another SSD with the same control processing chip and try to make use of the new working parts.

45O

[sync]

1. Is there any way of emulating the controller/processor programatically i.e. decoding and reassembling the data by finding the XOR key? Has anyone had success doing this?

It's a self-encrypting drive (SED). It doesn't use a simple XOR key but strong AES encryption. You will need the key and IFAIK the key is stored in the controller chip itself. With a dead controller I don't think data recovery will be possible.

Interesting problem.  Here is a great example of why people might be reluctant to use SSD's.  They just don't give you any warning.

Like mechanical hard drives when the controller dies.

[45Overload]

It's a self-encrypting drive (SED). It doesn't use a simple XOR key but strong AES encryption. You will need the key and IFAIK the key is stored in the controller chip itself. With a dead controller I don't think data recovery will be possible.

Thank you.  Very instructive.  While not being a SSD manufacturer or designer, it seems possible that a new drive of the same type might yield a new working chip that could be substituted to read off the old data.  No, I haven't tried it, but I'm just thinking about possibilities.

It is possible that each and every controller chip contains a totally different key?  However, I can't see why that would be necessary, since it is up to the user if he wants to encrypt his data and it is up to the hardware to implement the best practice method for storing data.  With the latter in mind, it would be to the manufacturer's advantage to produce drives that would be data recoverable, instead of manufacturing an expensive product that instantly turns itself and all stored data into a brick.

It might sound intelligent to point out that all controller failures yield a dead unrecoverable drive, but that is incorrect.  Yes, the failure of an SSD is comparable to the failure of the controller on a hard disk - to some degree.  But a HD with a failed controller can be recovered.  In any case, HD controller failures account for only a small percentage of total drive failures.  The majority of failures are mechanical and the majority of those mechanical failures give the user some warning such as increasing read/write errors, increased drive noise and ...these failing drives can easily be checked with programs such as Spinrite to confirm the health of the drive. 

[Halcyon]

The dead controlled itself isn't such a big deal. Data can be quite easily recovered off media even when the controlled ceases to operate. The AES-256 encryption is your biggest issue.

[Monkeh]

It is possible that each and every controller chip contains a totally different key?  However, I can't see why that would be necessary

What is the point of encryption if the key is known to all? Of course it's necessary.

That said, I'm not convinced they waste cycles encrypting if you don't enable encryption.. but that doesn't mean a controller swap would work - the information required to correctly reassemble the contents of the flash may well be stored in the controller.

But a HD with a failed controller can be recovered.

Might be recoverable. Very different.

Quite frankly, if you rely on a single device to retain your data, your data does not exist.

[wraper]

It might sound intelligent to point out that all controller failures yield a dead unrecoverable drive, but that is incorrect.  Yes, the failure of an SSD is comparable to the failure of the controller on a hard disk - to some degree.  But a HD with a failed controller can be recovered.  In any case, HD controller failures account for only a small percentage of total drive failures.  The majority of failures are mechanical and the majority of those mechanical failures give the user some warning such as increasing read/write errors, increased drive noise and ...these failing drives can easily be checked with programs such as Spinrite to confirm the health of the drive.

If HDD is a SED, you are still screwed if controller is dead. And if SSD is not a SED, you can still recover the data if controller is dead.

[CJay]

More to the point, are you sure the controller is dead, ave you examined the drive and ensured all the required voltages, clocks etc. are present and correct?

Was the SSD even encrypted?

[RGB255_0_0]

From http://www.samsung.com/global/business/semiconductor/minisite/SSD/M2M/html/support/faqs_03.html

it seems you must enable the BIOS HDD password for SED to be enabled - at least on the consumer drives. I imagine it'd be the same for PMxxx and SMxxx devices, which are normally OEM. This is just a standard ATA command.

YMMV but I think you have somewhat a chance by moving the NAND to an identical device, assuming you didn't enable the HDD password. What have you got to lose except a few hundred in your wallet?

[wraper]

Was the SSD even encrypted?

It is always encrypted/decrypted on the fly. So unless you have a working controller IC with a matching encryption key inside it, your data is gone. For example, there is such a thing as instant secure erase. Encryption key get changed in in the controller and your data is gone in instant even without erasing it first.
http://www.hgst.com/sites/default/files/resources/Instant-Secure-Erase-Overview-TB.pdf

[CJay]

Was the SSD even encrypted?

It is always encrypted/decrypted on the fly. So unless you have a working controller IC with a matching encryption key inside it, your data is gone. For example, there is such a thing as instant secure erase. Encryption key get changed in in the controller and your data is gone in instant even without erasing it first.
http://www.hgst.com/sites/default/files/resources/Instant-Secure-Erase-Overview-TB.pdf

Mhmm, as you say, always encrypted but ot necessarily locked.

Not a nice technology if you don't know you have it and you've been lax in backing up, I can see a lot of buyers of second hand corporate laptops ending up with these drives and getting burned.

[sync]

Mhmm, as you say, always encrypted but ot necessarily locked.

Not a nice technology if you don't know you have it and you've been lax in backing up, I can see a lot of buyers of second hand corporate laptops ending up with these drives and getting burned.

It's a good technology! It's a easy and secure way to encrypt the drives and it comes without a performance penalty.

Also some non-SED SSDs encrypting or compressing the data. Even when the drives doesn't then the data is scattered all across the flash memory. There is no linear relationship between the logical LBA sectors the computer sees and the data location in the flash memory. You will need to know how the drive maps the data. And this is a highly dynamic process. Every write to the SSD will change the mapping.

The very slim change to recover data directly from the flash memory is simply no substitute for backups.

[CJay]

Absolutely agree, there is no substitute for a good backup routine, that applies to *any* electronic data storage medium and includes regular restores with sanity checks of the data.

But, are you saying even non SED SSD 'drives' encrypt data or did you mean they just obfuscate it by spreading it around the storage space?

[Rasz]

That said, I'm not convinced they waste cycles encrypting if you don't enable encryption.. but that doesn't mean a controller swap would work - the information required to correctly reassemble the contents of the flash may well be stored in the controller.

1 they dont waste cycles, its a hardware block
2 this block is dual purpose, and is also used for error correction
3 unique key is stored in the controller
4 even with unique key you wont know the details of particular ECC implementation (LDPC), there is no data in cleartext inside flash cells
5 even with particular ECC implementation you wont know the details of particular FTL implementation

did I mention compression(sandforce)?

[sync]

But, are you saying even non SED SSD 'drives' encrypt data or did you mean they just obfuscate it by spreading it around the storage space?

Yes there are non-SED labeled SSD with encrypt data, e.g. Sandforce controller. And I would not be surprised if drives (SSD and magnetic) which exists in in SED and non-SED versions always encrypt.

[Psi]

Are you sure the CPU is fried. Might just need reballing?

Also, sometimes heating or cooling can get a dead chip working again, for a short time.
Assuming its an internal signalling issue and not actually burnt out.

[CJay]

But, are you saying even non SED SSD 'drives' encrypt data or did you mean they just obfuscate it by spreading it around the storage space?

Yes there are non-SED labeled SSD with encrypt data, e.g. Sandforce controller. And I would not be surprised if drives (SSD and magnetic) which exists in in SED and non-SED versions always encrypt.

Ugh, that has potential to make life extremely awkward for data recovery.

Despite all the advice and attempts to back up, mobile users regularly get caught out because there are few options for secure backup for users who rarely visit offices so two or three times a year I become involved in sending drives to data recovery companies.

At least Bitlocker and other, slower, software/hardware schemes are recoverable if it's not on one of those drives.