Switch to full style
Data recovery and disk repair questions and discussions related to old-fashioned SATA, SAS, SCSI, IDE, MFM hard drives - any type of storage device that has moving parts
Post a reply

Re: Cloning Tool

June 4th, 2017, 3:11

Those commands are ATA commands. I believe PC3K should have an ATA terminal (not serial). Otherwise HDDSuperTool is probably a much better option.

I'm having difficulty understanding how an inaccessible block of LBAs from 0 to 0xFFFFF could be due to a hardware failure. The numbers are just too neat. In any case I believe that wear levelling would have distributed these LBAs over several chips, especially as the FATs would fall within this range, and these FATs would be updated each time a file is written.

Re: Cloning Tool

June 4th, 2017, 5:09

Hello ,
In my recent experience i had a similar CF card .That card also i was able to image but could not find data .I did a chipoff with PC3K and recovered 100% data of the customer they were pictures .The main controller was SM Brand and There Were Two NAND Chips in That .It Could Be A Failed Controller Giving Out Garbage

PS : You said when controller fails it shows wrong size n all,This is not true in These CF Cards

Re: Cloning Tool

June 4th, 2017, 7:44

I frequently get flash devices where you are really just reading a buffer and not the actual stored data. The cases are usually recoverable via direct access to the NAND and the typical chip off recovery procedures.

Re: Cloning Tool

June 4th, 2017, 7:57

bunty wrote:Hi HaQue

I have attached snap of card , I have already given description of card in first post itself , besides in hddsuperclone snaps it is mentioned source as sandisk 64GB CF card and target 120 GB SAMSUNG EVO SSD
I disagree with you. Card may not have firmware issue as it can be imaged upto 99% , if some issue is there with MCU or any other code generally card shows less size and does not give access to sectors at all. Here we can check any sector in hex.
Only sectors where nand has defects cannot be read (first 600MB)


ok, "Currently I am working on a 64GB memory card." is not a description. could have been sd, microsd, CF or anything. Sorry I didnt read the snaps.

When controller fails, one symptom is false size, but there are many other symptoms as well. One is not being able to access all NAND, or "believing" a NAND is bad. a single bad solder on a leg of a NAND or controller could make imaging fail, there is anything and everything and all in between. sometimes the card is showing data but it is all 00's or just replaying the same block, not what you think.

most NAND flash issues requiring recovery are never attributed to a cause with 100% accuracy.

Re: Cloning Tool

June 4th, 2017, 9:46

A big Thanks to all contributors .
I learned a lot from this work. I have informed customer that the only option to recover data is by accessing Nand flash directly.
I am skeptical about approval though.
Thanks again.

Re: Cloning Tool

June 4th, 2017, 10:29

@bunty, AISI you haven't even begun to explore all the possibilities available to you before you start tearing the card apart.

IMHO you should start with an Identify Device command. This will return a 512-byte block of data that will have an 8-bit checksum of 0x00.

I would then test the Translate Sector (87h) command on a few LBAs, both inside and outside the "bad" range. If it produces plausible output, then I would write a HDDSuperTool script to build a Flash Translation Layer by matching each LBA with its chip/block/page location. This will hopefully obviate the need to build an FTL by mucking about with raw "chip-off" dumps.

To test the possibility that "you are really just reading a buffer and not the actual stored data", you could take a few random LBAs in your cloned image and then search the next few hundred megabytes for repetitions of these data. I would expect that a RAM buffer would not exceed 64MB.

ISTM the statement that "a single bad solder on a leg of a NAND or controller could make imaging fail" is not consistent with the symptoms. For a start, I would think that ECC would find these types of errors. Moreover, wear levelling would distribute such errors over random LBAs rather than a neat block. If there were a problem with the controller, then wouldn't it have trouble booting its firmware -- presumably this firmware is at least partially stored in NAND?

Re: Cloning Tool

June 4th, 2017, 11:31

bunty wrote:Jared
You have loaded guns too early . I have nothing to do with softwares mentioned in thread . By looking at the thread its clear I am not sales representative of any software. like You I own a DR company. I am wondering how you conclude so much early. A DR pro. needs patience . Ha Ha Ha..


My apologies for misunderstanding your post. It seemed from the wording that it was almost comparing it to the other software and saying why it's so much better. That's why I prefaced my remark with the question: "Am I mistaken?" I couldn't tell what you were trying to say.

Re: Cloning Tool

June 4th, 2017, 13:10

bunty wrote:A big Thanks to all contributors .
I learned a lot from this work. I have informed customer that the only option to recover data is by accessing Nand flash directly.
I am skeptical about approval though.
Thanks again.


Bunty ,
100% its a chipoff case ,Just leave the possibility of getting data by the no of solutions suggested ,I have had many many cases now like this specifically for CF Cards

Re: Cloning Tool

June 4th, 2017, 14:37

fzabkar wrote:@bunty, AISI you haven't even begun to explore all the possibilities available to you before you start tearing the card apart.

IMHO you should start with an Identify Device command. This will return a 512-byte block of data that will have an 8-bit checksum of 0x00.

I would then test the Translate Sector (87h) command on a few LBAs, both inside and outside the "bad" range. If it produces plausible output, then I would write a HDDSuperTool script to build a Flash Translation Layer by matching each LBA with its chip/block/page location. This will hopefully obviate the need to build an FTL by mucking about with raw "chip-off" dumps.

To test the possibility that "you are really just reading a buffer and not the actual stored data", you could take a few random LBAs in your cloned image and then search the next few hundred megabytes for repetitions of these data. I would expect that a RAM buffer would not exceed 64MB.

ISTM the statement that "a single bad solder on a leg of a NAND or controller could make imaging fail" is not consistent with the symptoms. For a start, I would think that ECC would find these types of errors. Moreover, wear levelling would distribute such errors over random LBAs rather than a neat block. If there were a problem with the controller, then wouldn't it have trouble booting its firmware -- presumably this firmware is at least partially stored in NAND?

While all of this is technically true, there are replies from 3 reputable and experienced members that indicate that this will require a chip off recovery. While I am always as helpful as I can be when someone wishes to attempt further things with my tools, I do not think it is worth the effort in this case. My opinion is to consider it a chip off recovery, and not to try any of the complicated steps required to continue with software only recovery. But that is only my opinion.

If it was me, I would of course try everything possible before giving up. But that requires a very technical approach close to the programming level, being able to understand the results, and also being able to know when to give up.

Re: Cloning Tool

June 4th, 2017, 16:11

maximus wrote:If it was me, I would of course try everything possible before giving up. But that requires a very technical approach close to the programming level, being able to understand the results, and also being able to know when to give up.

I don't see it that way. If the OP cannot obtain Identify Device data, then he is unlikely to be able to do anything remotely complicated.

A chip-off recovery requires physical-to-logical sector translation. Here is my pseudocode for HDDSuperTool:

Code:
for n = 0 to maxlba
  Translate Sector n
  extract chip/block/page data from output
  write LBA/chip/block/page to logfile
next n

The logfile is effectively the "translator". IIUC, it would be very useful for chip-off work, should that become necessary.

Examining the extended error codes for failed reads is mandatory, IMO. At the very least, one should do as much as possible to understand the problem before jumping to conclusions.

I have other ideas, but they depend on the OP's feedback.

Re: Cloning Tool

June 4th, 2017, 19:03

Some taskfiles to try ...

Code:
00 00 00 00 00 E0 EC  Identify Device
00 00 00 00 00 E0 03  Request Sense

00 00 00 00 00 E0 90  Execute Drive Diagnostic
00 00 00 00 00 E0 03  Request Sense

00 01 00 00 00 E0 20  Read Sector 0
00 00 00 00 00 E0 03  Request Sense

00 01 FF FF 0F E0 20  Read Sector 0xfffff
00 00 00 00 00 E0 03  Request Sense

00 01 00 00 10 E0 20  Read Sector 0x100000
00 00 00 00 00 E0 03  Request Sense

00 00 00 00 00 E0 87  Translate Sector 0
00 00 00 00 00 E0 03  Request Sense

00 00 FF FF 0F E0 87  Translate Sector 0xfffff
00 00 00 00 00 E0 03  Request Sense

00 00 00 00 10 E0 87  Translate Sector 0x100000
00 00 00 00 00 E0 03  Request Sense

Re: Cloning Tool

June 4th, 2017, 20:20

@fzabkar, if the OP wishes to try further, then it will be up to you to direct him. I may be willing to help some with the hddsupertool script coding, but I don't have the time to spend on it in detail.

In theory, since compact flash is ATA compliant, hddsupertool should be able to send ATA passthrough commands to it. To test this, the OP would need to open hddsupertool from the command line (terminal) on the live CD by typing "sudo hddsupertool". That will start it in a menu driven mode. Things such as identify device and read sectors can be done. And not to get any hopes up, but it looks like CF supports the read long command, which is an included script command. But the request sense and translate commands are not available options, without modifying/writing scripts.

Re: Cloning Tool

June 4th, 2017, 20:47

The advice for a hard disk where the problem is not known would never be to continually power it on and try different things out of hope. I just hope whatever the issue is, is non-destructive.

It would be better to get a similar card, hone the skills required to get these commands working, then perform on patient.

If bunty is a DR Pro, or PC Shop, estimate around 5 hours and the revenue from the recovery will be less than time spent /$.

skills gained may be useful in future, no doubt. But usually the customer will not allow enough time for hobbyist type of exploration, and cancels recovery. I never understand that line of thinking though as the recovery will never happen with card put in a drawer after cancelling.

Re: Cloning Tool

June 4th, 2017, 20:51

Read Long appears to be a dummy command.

5.1.12 Read Long Sector -- 22H, 23H

The Read Long command performs similarly to the Read Sector(s) command except that it returns 516 bytes of data instead of 512 bytes. During a Read Long command, the card does not check the ECC bytes to determine if there has been a data error.Only single sector read long operations are supported. The transfer consists of 512 bytes of data transferred in word mode followed by 4 bytes of random data transferred in byte mode. Random data is returned instead of ECC bytes because of the nature of the ECC system used. This command has the same protocol as the Read Sector(s) command.

Re: Cloning Tool

June 4th, 2017, 21:05

fzabkar wrote:Read Long appears to be a dummy command.

5.1.12 Read Long Sector -- 22H, 23H

The Read Long command performs similarly to the Read Sector(s) command except that it returns 516 bytes of data instead of 512 bytes. During a Read Long command, the card does not check the ECC bytes to determine if there has been a data error.Only single sector read long operations are supported. The transfer consists of 512 bytes of data transferred in word mode followed by 4 bytes of random data transferred in byte mode. Random data is returned instead of ECC bytes because of the nature of the ECC system used. This command has the same protocol as the Read Sector(s) command.

That states only the ECC data is random, so technically the main 512 bytes of data should be what is read. But that does not mean that it will return any usable data even on a good sector, only with testing can that be known...

Re: Cloning Tool

June 4th, 2017, 21:21

HaQue wrote:The advice for a hard disk where the problem is not known would never be to continually power it on and try different things out of hope. I just hope whatever the issue is, is non-destructive.

It would be better to get a similar card, hone the skills required to get these commands working, then perform on patient.

If bunty is a DR Pro, or PC Shop, estimate around 5 hours and the revenue from the recovery will be less than time spent /$.

skills gained may be useful in future, no doubt. But usually the customer will not allow enough time for hobbyist type of exploration, and cancels recovery. I never understand that line of thinking though as the recovery will never happen with card put in a drawer after cancelling.

+1
This is getting too technical, and involves playing with a users data in attempts that are unknown. It is easy to suggest trying things, but all things must be considered.Trying to help someone else to do these things is difficult, if not impossible, and the result could be disaster. I will support any desired attempts, but do not recommend it with someones data at risk.

Re: Cloning Tool

June 7th, 2017, 16:14

The OP has already attempted to clone the drive at least once, plus his colleague has done the same thing in a Windows environment. That's 128GB of reads. I'm asking the OP to read 3 sectors. Will these sectors be the straw that breaks the camel's back?

Moreover, I'm asking the OP to ask the drive for a sense code. That should be standard practice for any competent diagnostician. In fact that's normal practice for any good OS. SCSI drives, for example, always return such error codes via the Request Sense command. The OP is blessed with an ATA/ATAPI device that provides similar feedback, so why not take advantage of it? AISI, reducing the drive to a pile of bits without even asking for an error code would be like a mechanic disassembling an engine without asking the computer what is wrong with it.

The Execute Drive Diagnostic command dates back to the earliest implementations of the ATA standard. A similar, if not identical, test would be performed by the drive during its POST, so no risk there.

Identify Device would be the first command sent to the drive by the BIOS or the diagnostic tool. A checksum test of the data would be a simple way to check the IDE interface for stuck bits. Such a fault is not uncommon and could explain why no data have been found during a sector scan.

The Translate Sector command is a huge bonus. Essentially it tells you exactly where each piece of the jigsaw fits into the puzzle, assuming the drive supports the command, and assuming the output is still valid. Ignoring this valuable command would be akin to reducing an engine to its component parts and then attempting to reassemble it after discarding the workshop manual. Moreover, the translator would be in RAM, so presumably there would be no NAND access during the execution of the command.

See the following thread:

Barefoot logical to virtual mapping details (M225):
viewtopic.php?t=35428

The OP in that thread has the advantage of being able to access the entire raw contents of the NAND array without reducing his SSD to a pile of bits. Moreover, the flash controller is serving up error corrected data. That's a much better approach than "chip-off" (see HaQue's "how we would do it" comments in that thread), but he is still at an impasse because he cannot find a unique correspondence between logical and physical pages.

Re: Cloning Tool

June 7th, 2017, 16:50

I should add that most commercial tools have a GUI based ATA terminal, so there is no need to wrestle with a command line. Just enter the register values into their appropriate boxes and click "go".

Re: Cloning Tool

June 7th, 2017, 17:01

One other thing to do would be to compare the two cloned images. If there are any differences, then these might illuminate the nature of the problem.

Re: Cloning Tool

June 8th, 2017, 3:50

Hi fzabkar
Thanks for keeping this thread alive
I have calculated 160Bit SHA1 for both images , both signatures are different. I think I have stopped cloning for different intervals after bad sectors were started appearing . Thank is the reason SHA1 is different.
If I have taken SHA1 for only good part probabaly it would been same.
I can give remote access to both files ,in case if someone wants to experiment . Pls. PM me for the same so that we can schedule it.

Thank you
Attachments
SHA1 compariosn.PNG
Post a reply