HDD GURU FORUMS

Hi guys, i'm new here.
I'm trying to recover data from my dead drive. It just stopped do work after a bluescreen.
The drive remains not recognized by the BIOS until ROM mode is forced.
The controller gets hot more than usual while in normal mode, so it probably get stuck in a loop caused by bad firmware.

The drive was checked in one of the professional recovery lab, but they can't recover data from it.
So i'm trying to deal with it by myself. I'm not in recovery business, just an IT guy.
There are many versions of so called "Easy Tools" around, but they are for a DRAM-less SM2258XT version of the controller chip.
I tried each one of them with no success.
I get some kind of success with SMI Mass production tool. It has "debug mode", allowed me to load MPISP and get a kind of physical access to the NANDs.
But i got stuck here. Does anybody know how to figure out where the translator is?
This tool has some buttons like DBS, DPS, DDS. I saw that abbreviations in the EasyTools as well, but don't know what this stands for.
It probably shows some infos about the Block and page type, but again what are the types of particular pages?
For example there are:
Pages with 0xA0 type, looks like user data (visible NTFS strings)
Pages with 0xE4 type, looks like firmware
Pages with 0xE5 type with header 'SmiIndex'
Pages with 0xE8 type with visible strings like 'AC70202' or so.

What im planning to do is to write some app to read the pages out of the device and try to rebuild the drive image.
But don't know how to find the translator.
Is there someone who can shed some light on this?
Thank you guys.

The translator is located in pages with codes 0x64, 0x66, 0x68. But you should know that the translator is made up of many pieces, each with a version. And to assemble a translator that was up-to-date at the time of the death of the drive is still a hell of a job.

But even assembling the translator itself is only half the work. Still need to read the data. And here there is a problem, the solution of which, if known, is to a very small circle of people. MPISP for this controller can only read pages written in the pSLC format. And this is only 20-30% of all data (SLC cache). Garbage is read instead of other user data (MLC or TLC format).

If you find a solution, write. It will be interesting to read.

majonez wrote:The drive was checked in one of the professional recovery lab, but they can't recover data from it.

No to dismiss your efforts but there's nothing stopping you trying a different service - did they give you any documentation regarding their evaluation?

First of all - thank you guys for such a quick response. Really appreciate it.

Agrail wrote:The translator is located in pages with codes 0x64, 0x66, 0x68. But you should know that the translator is made up of many pieces, each with a version. And to assemble a translator that was up-to-date at the time of the death of the drive is still a hell of a job.

But even assembling the translator itself is only half the work. Still need to read the data. And here there is a problem, the solution of which, if known, is to a very small circle of people. MPISP for this controller can only read pages written in the pSLC format. And this is only 20-30% of all data (SLC cache). Garbage is read instead of other user data (MLC or TLC format).

If you find a solution, write. It will be interesting to read.

Thanks a lot. I can find many pages with 0x64 and 0x68 ID.
After loading MPISP the program reports that drive has 1000215216 of total LBA. It makes sense, because it's 512GB drive.
In the dumped page of the 0x64 type i see a lot of 32bit LE-organized blocks of data. But how to translate them from LBA to Physical Block->page->channel and so on?
Is the 4-byte number an LBA number? The incrementation is 1 unit of something, so it probably makes no sense to be an LBA number, since page size is 0x4000 bytes and LBA is only 512 bytes.
So each page can contain 32 LBA-512 sectors. Can you tell something more about that pieces and it's versions? Is there any documentation of this stuff?

About the SLC and TLC stuff - there is a screen to set it up, but i don't know if that works actually.

Lardman wrote:

majonez wrote:The drive was checked in one of the professional recovery lab, but they can't recover data from it.

No to dismiss your efforts but there's nothing stopping you trying a different service - did they give you any documentation regarding their evaluation?

Well, nothing is stopping me from doing so and i'll do it probably. But first i want to give it a try by myself. I have no documentation from the DR guys work. But they told me that PC-3000 was not able to see all the NAND-s on the drive, therefore many parts of the resulting image was missing.

There is no documentation and it is unlikely to be. I can’t give a lot of advice, because it's kind of a trade secret. Therefore, you will have to deal with most things on your own. Although sometimes I exchange information. But only in exchange for other information of interest to me...

The SSD does not operate directly with channel, chip, block, and page addresses. There are superblocks, which consist of pages of one or more blocks of one or more channels. These superblocks are composed according to a certain law.

The translator addresses the space within these superblocks. The addressing unit is not a page or a sector, but an area, 0x1000 bytes in size. Thus, one 4-byte record in the translator addresses 8 LBA sectors.

Perhaps that's all. Further yourself.

Agrail wrote:MPISP for this controller can only read pages written in the pSLC format. And this is only 20-30% of all data (SLC cache). Garbage is read instead of other user data (MLC or TLC format).

this appears correct. however, if u select checkbox to dump 16.5K data, then everything is saved in another folder (DataBlock) but this folder have no LBA info. no idea if there is a way or tool to build image from this kind of backup

also even it is sm2259xt2 and they say using easy tools version for sm2258xt won't work, it actually does work (except for full TLC image dump)
the disk size also doesnt matter. in ROM mode is 1024MB with loaded MPISP 2048MB. it's just the app doesn't support everything properly (MPtool still reported actual disk size after loading MPISP)

there are versions for 2259xt, easily found 2.3.8, but can't dump, on csdn they have 2.4.4 but i doubt it would work either. because 2258xt version 2.4.8 also doesn't work, ver 2.5.1 was able to dump contents

there is also one more ver 2.5.5 but it's swptest.dll appears infected with malware and the app doesn't start as they used some kind of verification against machine ID. maybe someone can crack it

how to get this debug mode is MPtool, i tried many things but it doesn't show up. need specific MPtool version?

someone also claimed he was able to reflash firmware with MPtool without losing data on disk, but i did not understand it entirely, something about checking a setting to keep something - anyone here tried this with success?

reflashing and keeping data did not work. maybe i should've use default files and config. it erased first block and wrote fw somewhere else. and it kept booting in rom mode even without pin short, some data was still visible. well, fuck it, i have no time for this. so checked to erase all blocks. but he remains dumb and auto setting in mptool swears at parameter.

i banged a couple more times on it, and at some point the whole reflash/reinit procedure was taken. after confirming it works, i tried to switch it to SLC mode, and need to set 80GB disk size. quick test with sata2 port shows r/w speed of 250-270 MB/s. so these can be used as SLC disks.

i returned it to TLC mode because 80GB is nothing, easily eaten by OS install and game