June 4th, 2017, 3:11
June 4th, 2017, 5:09
June 4th, 2017, 7:44
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)
June 4th, 2017, 9:46
June 4th, 2017, 10:29
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..
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.
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?
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.
for n = 0 to maxlba
Translate Sector n
extract chip/block/page data from output
write LBA/chip/block/page to logfile
next n
June 4th, 2017, 19:03
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
June 4th, 2017, 20:20
June 4th, 2017, 20:47
June 4th, 2017, 20:51
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.
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.
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.
June 7th, 2017, 16:14
June 7th, 2017, 16:50
June 7th, 2017, 17:01
June 8th, 2017, 3:50
Powered by phpBB © phpBB Group.