All times are UTC - 5 hours [ DST ]


Forum rules


Please do not post questions about data recovery cases here (use this forum instead). This forum is for topics on finding new ways to recover data. Accessing firmware, writing programs, reading bits off the platter, recovering data from dust...



Post new topic Reply to topic  [ 6 posts ] 
Author Message
 Post subject: ECC/CRC algorithm on F3 drive (ST2000DL003)
PostPosted: September 6th, 2016, 20:50 
Offline

Joined: August 15th, 2016, 6:05
Posts: 15
Location: Czech Republic
While using STUart for recovering files I sometimes got bit errors. I thought about using ECC/CRC field for a correct data transmission, but I don't know which algorithm does it use.

Does someone know how this field (8 bytes after every 512 bytes sector) is computed?

If no one knows is someone with working ST F3 driver wiling to generate the testing data?

All I know know is (from recovering my half dead drive):
  • Zeroed sector has these 8 bytes zeroed too
  • It seems that last 6 bytes are just copy of data of the last bytes of the sector
  • Tried all polynoms and initial data values for CRC16 and for three sectors there was no match
  • If there are only 2 bytes valid (and last 6 is copypaste), it seems to be too few for ECC, for example 24 bit golay codes have only 12 bits for data (rest 12 bits are correction information) and can only correct errors of 3 bits

For someone who is willing to help: try to write sectors of single bit = "1" on different positions (ideally all positions in first 32bits of a sector, within last 6 bytes of a sector) and read it back by using F3 terminal commands and check for that ECC/CRC field. With enough samples it should be possible to reconstruct the ECC/CRC algorithm. Sectors can be written from an OS (OS LBA can be converted for F3 terminal commands).

_________________
Support opensource code reverse engineering tool radare2.


Top
 Profile  
 
 Post subject: Re: ECC/CRC algorithm on F3 drive (ST2000DL003)
PostPosted: September 7th, 2016, 10:41 
Offline
User avatar

Joined: September 29th, 2005, 12:02
Posts: 3347
Location: Chicago
ECC is calculated for a 4K sector and vendor fields size(including ECC) is 32 bytes, however they are not in one place, some fields located after each 512-byte block and some located at the end of a 4K sector. I think ECC fileds are at the end on the 4K sector.
ECC on modern drives is calculated using LDPC algorithm.

_________________
https://www.linkedin.com/in/artemrubtsov/


Top
 Profile  
 
 Post subject: Re: ECC/CRC algorithm on F3 drive (ST2000DL003)
PostPosted: September 7th, 2016, 10:48 
Offline
User avatar

Joined: September 29th, 2005, 12:02
Posts: 3347
Location: Chicago
pc2005 wrote:
[*] It seems that last 6 bytes are just copy of data of the last bytes of the sector

It's because there is a bug in Seagate firmware(most of them anyway) and you are not getting correct fields.

_________________
https://www.linkedin.com/in/artemrubtsov/


Top
 Profile  
 
 Post subject: Re: ECC/CRC algorithm on F3 drive (ST2000DL003)
PostPosted: September 7th, 2016, 10:50 
Offline
User avatar

Joined: September 29th, 2005, 12:02
Posts: 3347
Location: Chicago
pc2005 wrote:
[*] If there are only 2 bytes valid

Those two bytes encode part of a sector number, they are not ECC and not related to ECC. Moreover they can only be used after correctly applying the ECC

_________________
https://www.linkedin.com/in/artemrubtsov/


Top
 Profile  
 
 Post subject: Re: ECC/CRC algorithm on F3 drive (ST2000DL003)
PostPosted: September 7th, 2016, 19:52 
Offline

Joined: August 15th, 2016, 6:05
Posts: 15
Location: Czech Republic
Thanks for quick info. I was hoping it could make sector over UART transmission more secure :-( . So best thing now is to send it triple times then (as "/2r" seems to spit only garbage for me ).

_________________
Support opensource code reverse engineering tool radare2.


Top
 Profile  
 
 Post subject: Re: ECC/CRC algorithm on F3 drive (ST2000DL003)
PostPosted: February 19th, 2020, 0:20 
Offline

Joined: August 15th, 2016, 6:05
Posts: 15
Location: Czech Republic
OK ...

lately I've had time to screw around the drive, so I've scaned many sectors and I've found these 2 of 8 bytes don't change for the same data but in different sectors (LBA). Also zeroed sectors will have these 2 bytes zeroed too. Clearly some kind of a checksum.

I've managed to find ideal sectors which were filled with zeroes up to few last bytes. And with a few of these I was able to manually decode the algorithm.

It is just a CRC-16 subtype, but the catch is it doesn't "hash" just one byte, but with a short sized word (16bit). Funny, back in 2016 I was doing a brutalforce search for all seeds and polynoms with opencl/GPU, but I didn't try to hash two bytes at the same time :-D.

The polynom is 0x2d (101101b), which is XORed with the new 16bit sample when the previous hash (which is Lshifted and xored too) contained "1" in the MSb. The init value is 0 (unless you compute the hash in multiple stages).

Example code:

Code:
unsigned short seagate_crc16(
   unsigned short *d,
   unsigned int len,
   unsigned short pol,
   unsigned short init)
{
        unsigned int i;
        unsigned short sum = init;
        unsigned short pol_xor;

        for (i = 0; i < len; i++) {
                pol_xor = (sum & 0x8000) ? pol : 0;

                sum = (sum << 1) ^ d[i] ^ pol_xor;
        }
        return sum;
}

Used for "/FD" command on F3 drives (works at least with my st2000dl003). The rest 6 bytes seems to be really just a copy of the bytes from 507 to 512 (end of an LBA sector).

_________________
Support opensource code reverse engineering tool radare2.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 

All times are UTC - 5 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group