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.

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.

_________________
SAN, NAS, RAID, Server, and HDD Data Recovery.

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

_________________
SAN, NAS, RAID, Server, and HDD Data Recovery.

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

_________________
SAN, NAS, RAID, Server, and HDD Data Recovery.

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.

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 .

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:


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.