Any way to decode encoded read long data?

[maximus]

I have a WDC WD1600BEVT-22ZCT0 in which the data returned from a read long command appears to be encoded. And by encoded I mean that a good sector that is all zeros with a normal read returns anything but zeros from a read long. Can anyone point me in the proper direction on how to possibly decode the data?

[Tomset]

in no way.
usually there mussoorie buffer.
Read a few sectors and make sure.

[maximus]

I am slightly confused by your response. Do you mean there is no way to decode it? Or do you mean that I should not be seeing the results that I am?

I have read several sectors of this disk using read long (22h) and read long (SCT), and both provide the same results (except the SCT provides extra ECC bytes). The data part is not even close to what is seen with a regular read. Other drives that I have will show the same data as a regular read, although I only have a few drives at my disposal.

[guru]

first 512 bytes should be all ZEROS's as you say; the rest of the bytes are for ECC. You may not be reading the correct amount of bytes or some strange circular buffer is happening

[Tomset]

disk with LBA48 team long reading rarely supported.
More precisely, its behavior can be controlled via technological passport.
A description of tech. passport - no.

[butchie3980]

Out of curiosity, how did you get the command to work? I'm trying to figure out how to do it.

[butchie3980]

Thanks! I'll start working on it ASAP, and let you know how it goes.

[butchie3980]

OK, I ran into a snag. I'm confused on the regs. What I want to do is modify your example to hunt for different LBA sectors.
Which reg value do I change?
I'm pretty sure the first word ($00 $01) is the Action code, and the $e0 field is the log page that you write to for SCT, and the $23 is the read long command.
but which parts are the function code and the LBA address?

[fzabkar]

The script is for a READ LONG, not an SCT READ LONG.

See the ATA-3 standard.

Tutorial: Using MHDD to send ATA commands to a HDD:
http://www.hddoracle.com/viewtopic.php? ... 987&p=4307

The following example reads 1 long sector at LBA 0x543210.

regs = $00 $01 $10 $32 $54 $e0 $23

[butchie3980]

ok I did some more reading. sorry about my earlier confustion. Here's what I understand so far on the regs:
$00 Feature
$01 Count
$01 LBA 00-07
$00 LBA 08-15
$00 LBA 16-24
$e0 Device (log page is E0)
$23 Command (SCT command)

so I think i can go forward with testing. I wonder what would happen if I increasted the count to 255? would I get 255 sectors with a checksum at the end? or 255 sectors with 255 ecc checksums?
I'll poke at it and see what happens. Thanks again for your help.

[butchie3980]

Thanks so much to fzabkar and spildit! I'll let you know how it goes.

[fzabkar]

The "E0" register is actually the Drive/Head register.

Here is the 8-bit layout:

Code:

1   LBA/CHS   1   Master/Slave   4 x Head/LBA bits

The LBA/CHS bit is a 1 in LBA mode and a 0 in CHS mode.

The Master/Slave (Drive) bit is a 0 for IDE Master and a 1 for IDE slave.

For non-data commands the head bits are ignored. Otherwise, for read/write commands the head bits are interpreted as head select bits in CHS mode (heads 0 - 15), or LBA bits 27 - 24 in 28-bit LBA mode.

For SATA drives, bits 7, 5, and 4 are ignored, AIUI.

CHS mode was superseded by LBA mode in the early 1990s. The state of the LBA/CHS bit doesn't matter for non-data commands.

The Command register (23h) corresponds to the READ LONG WITHOUT RETRIES command. SCT READ LONG is a different command.

[fzabkar]

The following script uses the SCT READ LONG command to retrieve the max LBA (0x1D1C596F) from my WD2500BB drive.

sctrdlng.bin = key sector
longsec.bin = data sector + ECC sector
sctstat.bin = SCT status

Code:

; SCT READ LONG

regs = $d6 $01 $e0 $4f $c2 $a0 $b0
waitnbsy
checkdrq
sectorsfrom = sctrdlng.bin

waitnbsy
regs = $d5 $02 $e1 $4f $c2 $a0 $b0
waitnbsy
checkdrq
sectorsto = longsec.bin

waitnbsy
regs = $d5 $01 $e0 $4f $c2 $a0 $b0
waitnbsy
checkdrq
sectorsto = sctstat.bin

; end of script

sctrdlng.bin - read max LBA 488397167 / 0x1D1C596F (WD2500BB)

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  01 00 01 00 6F 59 1C 1D 00 00 00 00 00 00 00 00
00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
........
000001F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

longsec.bin

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
........
000001F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000200  1D 24 62 9B D8 F4 71 A4 80 99 F4 C6 60 A9 5E 3D
00000210  6F 01 C4 78 DA 26 9F F8 47 80 3E 0A BD D8 9D 4D
00000220  FC 65 C8 4D 56 71 F0 79 87 5F 48 DF DE 20 77 A2
00000230  EC 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000240  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
........
000003F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

sctstat.bin

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  02 00 02 01 01 00 00 00 00 00 04 00 00 00 00 00
00000010  01 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00
00000020  00 00 00 00 00 00 00 00 D6 F3 D8 0D 00 00 00 00
00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
........
000000B0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000000C0  00 00 00 00 00 00 00 00 12 00 12 00 34 00 00 00
000000D0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
........
000001F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Working T13 Draft 1701DT-N - SMART Command Transport (SCT):
http://www.t13.org/Documents/UploadedDo ... r5-SCT.pdf

[maximus]

FYI the SCT READ LONG was also rendered obsolete shortly after it was proposed. Also, in the ATA specification that does list it, it states that the data may be "encoded", which is what I am seeing. I only have a few drives that support the SCT READ LONG command, but they return useless data. Some of those drives actually also support the old readlong command, but that also returns the same useless data.

I have created a couple Linux utilities that can perform both read long commands. In my ddrutility suit (can be found on sourceforge), there is the program ddru_diskutility. It will only display the data on the screen and not save it to file though. I also recently released a testing version of a new tool I am working on, HDDScriptTool (link can be found in software section on this forum). It can do both read long commands and it does save to a file.

[butchie3980]

btw, it's good to see you jump in on this one maximus. I found your ddru_diskutility and wrote a perl script that parses the hex output and can dump it to a raw data file. This allows for a full disk dump from ddru_diskutility long reads.

Unfortunately, my trouble drive is a WD drive that returns encoded data. I wonder how the WD encoding works? does it XOR with a key stored in the firmware modules or something like that?

Another idea I was thinking, is to modify the ddru_diskutility to issue vendor specific command. I know there is a vendor specific long read in the TREX manual (action code 26, function code 1) , but I dunno how to send the vendor specific command yet. I found idle3-tools, which says it can do VSC's, so I'm trying to figure out how that works. Maybe I can mix the VSC abilities of idle3-tools with ddru_diskutility, then I can feed the output to my perl script that dumps the hex data to a dd file. maybe? I'm hoping the vendor specific command decodes the data to the real values. Still need to learn C programming too. It's kinda like perl, but not.

[maximus]

Another idea I was thinking, is to modify the ddru_diskutility to issue vendor specific command. I know there is a vendor specific long read in the TREX manual (action code 26, function code 1) , but I dunno how to send the vendor specific command yet. I found idle3-tools, which says it can do VSC's, so I'm trying to figure out how that works. Maybe I can mix the VSC abilities of idle3-tools with ddru_diskutility, then I can feed the output to my perl script that dumps the hex data to a dd file. maybe? I'm hoping the vendor specific command decodes the data to the real values. Still need to learn C programming too. It's kinda like perl, but not.

Check out my HDDScriptTool http://www.hddoracle.com/viewtopic.php?f=22&t=1162
If you are running ddru_diskutility you are already in Linux so should not be too hard. It is capable of sending VSC as long as you know the command and how it works, and it can save to a file. Read the documentation and look through the sample scripts. The scripting might take a little bit of getting used to though, but should be easier than learning C

[butchie3980]

Yeah I guess we've come full circle, eh? I'm trying to recover data. Previous scans have shown the drive was having corruption everywhere, which I don't believe. I don't have experience in determining the cause, so I'm afraid of making things worse if I try regenerating defect lists or modules. I figure the safest thing to try with my limited knowledge is to do long reads of the whold disk and try to carve out files from the image.

[maximus]

Yeah I guess we've come full circle, eh? I'm trying to recover data. Previous scans have shown the drive was having corruption everywhere, which I don't believe. I don't have experience in determining the cause, so I'm afraid of making things worse if I try regenerating defect lists or modules. I figure the safest thing to try with my limited knowledge is to do long reads of the whold disk and try to carve out files from the image.

That sounds like it could be a bad/weak head(s). If the data is important enough to pay for, then I would suggest that you stop messing with it and have a professional look at it. If you insist on trying it yourself, just understand that you may not have as much luck as you like. And a failing drive will only get worse. So the more you try, the less likely a professional would be able to recover it.

[butchie3980]

Another idea I was thinking, is to modify the ddru_diskutility to issue vendor specific command. I know there is a vendor specific long read in the TREX manual (action code 26, function code 1) , but I dunno how to send the vendor specific command yet. I found idle3-tools, which says it can do VSC's, so I'm trying to figure out how that works. Maybe I can mix the VSC abilities of idle3-tools with ddru_diskutility, then I can feed the output to my perl script that dumps the hex data to a dd file. maybe? I'm hoping the vendor specific command decodes the data to the real values. Still need to learn C programming too. It's kinda like perl, but not.

Check out my HDDScriptTool http://www.hddoracle.com/viewtopic.php?f=22&t=1162
If you are running ddru_diskutility you are already in Linux so should not be too hard. It is capable of sending VSC as long as you know the command and how it works, and it can save to a file. Read the documentation and look through the sample scripts. The scripting might take a little bit of getting used to though, but should be easier than learning C

OK I'll take a crack at it. I'm so happy I found this forum and that I found your sourceforge projects. I'll let you know you it goes.

[Leo]

It is not "encoded", the drive just returns some "garbage" from its buffer without actual reading from disk sectors. As it was already said, most of modern drives do not support read long command, they just have a "plug" for compatibility with older software/hardware.
I used read long for data carving in the age of early ATA drives (less than 10GB), it worked and allowed to get some raw data that sometimes was of some use (for example to reconstruct FAT or DIR fragments etc.). But it was more than 15 years ago, and never worked with newer drives.