HDD GURU FORUMS

Hi,

I would like some opinions about diagnosing an phyically undetected 120 GB mSATA Intel SSD coming from an Acer tower.
Intel model: SSDMCEAC120B3A

As adapters for mSATA, I currently only have an mSata to USB 3.0 adapter, as well as 3.3V to 1.8V IDE adapter that can go into an IBM ThinkPad X40/X41.

When attached in USB, the SSD is not detected at all (fdisk -l nor lsblk, a.s.o.) ; I have not test the other option yet.

There is visible damage at the upper black stratum of the component located at L3, like it had been cracked (see photo)
We see below the grey substrate.
However, I have a very similar drive, but in 30 GB capacity (Intel 525 series, SSDMCEAC030B3)
which also has such damage to the same component (but in another corner) and is working perfectly.
So, I assume the black upper stratum could be kind of lacquer insulation coating and is maybe not so important.

The defective 120 GB SSD has controller SF-2281V81-SDC
The working 30 GB SSD has controller SF-2281V81-S0D ; I'm not sure however if the two last chars are 0D, 00 or else.

I wonder if the 30 GB can serve as donnor and if swapping the memory chips from the 120 GB SSD to the 30 GB would work as the problem could come from the memory chips too.

Many components on the PCB are very small, making voltage tests probably harder than for other drives.

Thank you for your help.

Hmm, you appear to be saying that voltage tests are too difficult for you (as seems to be the case in your other recent thread), yet you are entertaining the prospect of a BGA (?) chip swap?

What exactly do you propose to do, even if swapping memory chips is an option?

BTW, if you cannot see any chip markings in your photo/scan, then neither can anyone else.

there is 0 chance this swap would work. and 0 chance even if boards were identical. controller firmware is configured after memory chips are in place. Being Sandforce, you are pushing fresh cattle dung uphill with a sharp stick. If you don't want the data, then replace it. otherwise some people advertise they can recover from Sandforce because they have either researched it or have some special relationship with them... maybe you can pay their upfront fees and see if their word is true.

I had the same issue and used Sandforce and did help me recovering my data. I suggest you to try and it will help

Johnsmith wrote:I had the same issue and used Sandforce and did help me recovering my data. I suggest you to try and it will help

This makes no sense to me. are you saying you swapped memory chips to a different board? exactly what are you saying, it isn't coming through very well in the translation. sorry, but this post seems a little off.

I would NOT be swapping chips.

HaQue wrote:This makes no sense to me.

oh ye, it makes sense to me
a guy who felt a strong urge to register to the forum just to reply 10 min. later his first post...

Feel free to join in and have a thought experiment on SandForce.

Assumptions..
SandForce firmware is signed.
SandForce creates a linear address map of some sort across CE..
SandForce burns the AES key into a controller register using a one time write.
SandForce doesn't have a Safe Mode ROM w/ Unencrypted NAND access.
SandForce uses standard ATA commands for Firmware updates which don't reveal hidden commands.

I'm guessing SandForce probably encrypts their FW and signs it with a SF key.
Then issues an OEM key to each vendor for their mass production tool which adds some metadata and signs it with the OEM key..

So the FW is signed twice meaning, if I try and inject my own "Safe Mode" FW to read the NAND w/ Unencrypted access over SATA i'll need a SandForce key and the OEM's key.
That will be a challenge..

How about I acid etch the controller and use an electron microscope to locate the burned in register value and pull the AES key off that way..
We'd need to know how the controller creates a linear address map, handles compression, etc but it's a start.

Under those assumptions any data recovery company claiming to be able to recover SandForce would need a signed "Safe Mode" firmware from SandForce and the OEM's Key (which they're unlikely to get). SandForce has that "compressed write" feature so I'm guessing the drive relies HEAVILY on metadata (not block numbers) to make sense of that shit.
I'm guessing because the metadata would be spaghetti the recovery would need to be done in two parts, find and reconstruct the metadata, read the image per linear address map.

Because of the compression, firmware, metadata and encryption I think an engineer at SandForce would need to be personally involved in the recovery..
To be more blunt, SandForce is owned by LSI, I doubt ANY of their original engineers from ~2009 are there. Without direct assistance from an engineer that worked on that specific product I don't see ANY way it is recoverable. Sounds like companies with large marketing budgets and high fee's promising results they can't deliver.

On that note:
I can recover ALL SandForce drives, $1000 up front evaluation/attempt charge, bank check only, no refunds.
PM me for details.

The compressed write stuff is one of the reasons I have decided to not research SF. It would be throwing out 1/2 of what I know about regular flash recovery and spending a great deal of time on it.

I did read at least one company saying they had some kind of deal or partnership or something with Sandforce, but trying to see what that meant did not pan out.

I think it would take chipworks to do any sort of analysis, most companies that produce these "show-off" over-the-top IC's at the very least use some security features to slow down reverse engineering such as layers of intertwined webbing that detects if it is cut.

I think assumptions are probably right. in all the years of SF being out there, NOTHING has dribbled down to us mere mortals, which tends to happen no matter what if there is some kind of access to the system.

just reading this page: https://en.wikipedia.org/wiki/SandForce

SandForce controllers also use a proprietary compression system to minimize the amount of data actually written to non-volatile memory (the "write amplification") which increases speed and lifetime for most data (known as "DuraWrite").[6] SandForce claims to have reduced write amplification to 0.5 on a typical workload.[14] As a byproduct, data that cannot readily be compressed (for example random data, encrypted files or partitions, compressed files, or many common audio and video file formats) is slower to write. Other features include error detection and correction technology known as "RAISE" (Redundant Array of Independent Silicon Elements)[8] which improves the disk failure rates,[9] and AES encryption [6] which works in the background and is completely automatic. It is linked to the BIOS password and encrypts the user data at the full speed of the data as it passes through the controller.[14] Data is encrypted even if there is no password which makes data recovery problematic.

is enough to turn me off SF Recoveries and stick to some that are actually possible