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.

_________________
A backup a day keeps DR away.

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

_________________
Regards
Amarbir S Dhillon , Chandigarh Data Recovery Labs [India]
Logical,Semi Physical And Physical Data Recovery
Website-> http://www.chandigarhdatarecovery.com

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.

_________________
Luke
Recovery Force Donor Inventory: 5,000+ Fully Cataloged HDDs & Growing

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.

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, 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?

_________________
A backup a day keeps DR away.

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.

_________________
Data Medics - Hard Drive, SSD, and RAID Data Recovery Service Company

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

_________________
Regards
Amarbir S Dhillon , Chandigarh Data Recovery Labs [India]
Logical,Semi Physical And Physical Data Recovery
Website-> http://www.chandigarhdatarecovery.com

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.

_________________
http://www.hddsuperclone.com
Home of HDDSuperClone

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:


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.

_________________
A backup a day keeps DR away.

Some taskfiles to try ...

_________________
A backup a day keeps DR away.

@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.

_________________
http://www.hddsuperclone.com
Home of HDDSuperClone

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.

Read Long appears to be a dummy command.

_________________
A backup a day keeps DR away.

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...

_________________
http://www.hddsuperclone.com
Home of HDDSuperClone

+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.

_________________
http://www.hddsuperclone.com
Home of HDDSuperClone

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.

_________________
A backup a day keeps DR away.

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".

_________________
A backup a day keeps DR away.

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.

_________________
A backup a day keeps DR away.

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