ddru_diskutility not behaving as expected

[Ben Wellborn]

I'm trying to parse the output of ddru_diskutility and I'm not sure I
understand how it works.
When I run "ddru_diskutility -L0 /dev/sdc" and compare it to the hex
data from "dd if=/dev/sdc of=testfile.dd bs=512 count=1"
the outputs are different. I was expecting the same thing from both
methods. is sector 0 in ddru_diskutliity somewhere else besides user data?
perhaps the firmware modules?

my ultimate goal is to have a perl script that goes through the whole
hard drive and dumps it to a dd file, similar to dd or ddrescue, but
take advantage of the ddru_diskutility read long function.

Thanks, and keep up the good work!

B

[maximus57]

The following is from the ddrutility documentation, read the part about the data being encoded:

‘-L sector’\ ‘-readlong48 sector’
: Performs an ATA SCT Read Long command on the specified sector. Also
influenced by –inputoffset. Note that this command was made obsolete
years ago, but some drives still support it. Also note that in the
ATA specification it states that the data returned may be encoded.
To test it, read a known good sector with a regular or passthrough
read, and then again with readlong. If the results are different,
then the data is encoded and the readlong command on that drive is
totally useless to you. There are two parts of the output: 512 bytes
of data and then likely 52 bytes of ecc. Your results may vary.

When I first created the SCT Read Long command, I though I did something wrong. But then I found one of the disks also supported the old 28 bit read long command, and it showed the same data as the SCT command. So in your case the unfortunate answer to your question is: The data being returned by the SCT Read Long command is encoded, which makes it useless for data recovery. Unless someone can figure out how the data is encoded...

[Ben Wellborn]

OK I thought I was going crazy too. Thanks so much for clarifying that.