In-depth technology research: finding new ways to recover data, accessing firmware, writing programs, reading bits off the platter, recovering data from dust.
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...
September 6th, 2016, 20:50
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).
September 7th, 2016, 10:41
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.
September 7th, 2016, 10:48
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.
September 7th, 2016, 10:50
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
September 7th, 2016, 19:52
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 ).
February 19th, 2020, 0:20
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:
- 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).
Powered by phpBB © phpBB Group.