Corrupt Seagate V15 ROM

[ddrecovery]

I have a corrupt V15 ROM that so far I have not been able to correct.
I have tried reassembling it but cannot get it right.
Loading the ROM into PC3000 I get SAP and RAP errors.
Trying to Import SAP, RAP etc from a donor I get a ‘Servo Sym Table not found’ error.
I think it’s that table that may hold the key, however I have never worked with it before.
I have attached the patient and a donor ROM of the same firmware for reference.
Let me know what you think.
https://drive.google.com/drive/folders/ ... sp=sharing

[SWM]

Other adaptives will not help you.
I corrected the CRC (RAP, SAP) in the patient's ROM. But the errors remained.
This can be fatal for the heads...
Maybe Frank can work some magic on the bits...

Attachments

CorrCRC_Patient_V15_ROM.7z

(432.73 KiB) Downloaded 112 times

[ddrecovery]

Other adaptives will not help you.
I corrected the CRC (RAP, SAP) in the patient's ROM. But the errors remained.
This can be fatal for the heads...
Maybe Frank can work some magic on the bits...

Yes that what I was finding as well.
Thanks for looking.

[fzabkar]

There are errors in the RAP and SAP, as well as in the code modules and both BFW containers. My tool, which is based on the assumption that a segment contains only one single-bit error, produces a list of candidates for possible bit flips. Fortunately, there are full or partial copies of the RAP and SAP in the "extra space" at the end of the ROM, so I would look there first.

I have attached the relevant data.

Attachments

00161000_EXTRA SPACE.7z

(131.01 KiB) Downloaded 122 times

RAP_SAP_bad_bits.7z

(1.56 KiB) Downloaded 119 times

RAP_SAP.7z

(117.85 KiB) Downloaded 129 times

[SWM]

Corr. CRC RAP-SAP Patient + DonorSFW

Attachments

CorrCRC_Patient_V15_ROM_DonorSFW.7z

(305.81 KiB) Downloaded 113 times

[fzabkar]

Attached is the SAP I extracted from the extra space. It also has a bad CRC, and it differs wildly from the actual SAP.

These are the possible single-bit error candidates:

Code:

STROMfix_2.exe SAP_from_extra_space.bin

Expected / Actual CRC16 = 0x0000 / 0x2868

Searching for flipped bits in SAP_from_extra_space.bin ...

Possible cold bit #1 at offset 0xE4A  (0x80 -> 0x82)
Possible cold bit #0 at offset 0x1E4A  (0x00 -> 0x01)
Possible cold bit #7 at offset 0x2E4B  (0x00 -> 0x80)
Possible cold bit #6 at offset 0x3E4B  (0x00 -> 0x40)
Possible hot bit #5 at offset 0x4E4B  (0xFD -> 0xDD)
Possible cold bit #4 at offset 0x5E4B  (0x00 -> 0x10)
Possible cold bit #3 at offset 0x6E4B  (0x00 -> 0x08)
Possible cold bit #2 at offset 0x7E4B  (0x00 -> 0x04)

Number of possible bit flips is 8

Of course, these "candidates" are bogus if my SBE assumption is invalid, as appears to be the case.

Attachments

SAP_from_extra_space.7z

(10.38 KiB) Downloaded 107 times

[ddrecovery]

Thanks for the help guys.

[fzabkar]

Both copies of the SAP have the same CRCs, but there are several blocks which are wildly different and several blocks which are identical. This suggests to me that the two copies are meant to be identical, but something or someone has randomly corrupted entire sections of each segment.

[fzabkar]

When I extracted the SAP from the extra space in the donor ROM, it was identical to the main SAP segment.

[ddrecovery]

When I extracted the SAP from the extra space in the donor ROM, it was identical to the main SAP segment.

Yes afaict they are always identical. Same with the RAP segments.

[fzabkar]

Do you think this is a case of sabotage? Amarbir recently had some weird ROM corruption in a Rosewood which I thought was sabotage, but now I'm starting to wonder.

I notice that the NvC section at 0x180000 has been initialised, but I don't think that power loss data protection has touched the copy of the SAP. To me it looks like the structure of the SAP has remained intact, but whole slabs of data have been replaced with stuff that looks like SAP data.

[ddrecovery]

Do you think this is a case of sabotage? Amarbir recently had some weird ROM corruption in a Rosewood which I thought was sabotage, but now I'm starting to wonder.

I notice that the NvC section at 0x180000 has been initialised, but I don't think that power loss data protection has touched the copy of the SAP. To me it looks like the structure of the SAP has remained intact, but whole slabs of data have been replaced with stuff that looks like SAP data.

This came to me from another data recovery company who I trust. The PC had a power surge and took out the PCB and the heads (heads were tested in a donor).

[fzabkar]

I think I may be able to repair the ROM.

Here are two excerpts from the same area in each of the two BFW containers:

Code:

22 90 E0 8E 81 ED 42 00 E0 8E 20 90 E0 8E 20 90

Code:

11 48 70 47 40 F6 A1 00 70 47 10 48 70 47 10 48

Notice that the first line of bytes can be derived from the second line by shifting the entire line by 1 bit to the left. I suspect that your colleague dumped the ROM out of circuit, or with a chip clip. A weak clock pulse then caused one bit to be missed with the result that all the following bits in that block were shifted. Your colleague must then have written this bad dump back to the PCB.

[fzabkar]

I have written a tool to perform bit shifts:

https://web.archive.org/web/20230522150553/http://www.users.on.net/~fzabkar/FreeBasic_W32/Utils/rotshift.bas
https://web.archive.org/web/20230522150553/http://www.users.on.net/~fzabkar/FreeBasic_W32/Utils/rotshift.exe

[fzabkar]

Similar thread:

https://groups.google.com/g/datarecoverycertification/c/0yRWa1khWkA/m/2jNy3wPQAwAJ

Code:

       __     __     __     __
      /  \   /  \   /  \   /  \
     | b0 |-| b1 |-| b2 |-| b3 |-  good data
      \__/   \__/   \__/   \__/

       __     __     __     __
      |  |   |  |   |  |   |  |
      |  |   |  |   |  |   |  |
      |  |   |  |   |  |   |  |
     _|  |___|  |___|  |___|  |_  good clock



       __     _________     __
      /  \   /         \   /  \
     | b0 |-|     b1    |-| b2 |-  shifted and duplicated data
      \__/   \_________/   \__/

       __     __            __
      |  |   |  |          |  |
      |  |   |  |    __    |  |
      |  |   |  |   |  |   |  |
     _|  |___|  |___|  |___|  |_  bad clock

[Doomer]

Do you think this is a case of sabotage?

More likely poor ROM reading/writing tools

[fzabkar]

Do you think this is a case of sabotage?

More likely poor ROM reading/writing tools

If you had read a little bit further, you would have seen that I had already explained exactly how this type of corruption happens. But that thanks for your observation, anyway.

[pepe]

it should look more like this (decent setup time):

Code:

       __     __     __     __
      /  \   /  \   /  \   /  \
     | b0 |-| b1 |-| b2 |-| b3 |-  good data
      \__/   \__/   \__/   \__/

        __     __     __     __
       |  |   |  |   |  |   |  |
       |  |   |  |   |  |   |  |
       |  |   |  |   |  |   |  |
      _|  |___|  |___|  |___|  |_  good clock

[fzabkar]

Here is an example where the ROM misses a clock pulse. The next bit is not shifted out. Instead, the programmer reads the current bit twice.

Code:

0B 00 00 A6 26 3F CA 00 20 57 F6 9A 27 69 D1 CE
             *
0B 00 00 A6 27 1F E5 00 10 2B FB 4D 13 B4 E8 E7

Code:

  2    7    1    F    E    5
0010 0111 0001 1111 1110 0101
       ^
       this bit is duplicated

0010 0110 0011 1111 1100 1010
  2    6    3    F    C    A

In addition to the bit shifts, there are also occasional bit flips.

Code:

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

00000760  6F 07 AF 07 E2 07 0D 08 2A 08 4D 08 64 08 80 08
00000770  B8 08 E3 08 04 09 40 09 88 09 CD 09 FF 09 27 0A
           ^
00000780  5D 0A 94 0A D1 0A 00 00 D9 01 91 01 91 01 91 01

Code:

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

00000760  6F 07 AF 07 E2 07 0D 08 2A 08 4D 08 64 08 80 08
00000770  B9 08 E3 08 04 09 40 09 88 09 CD 09 FF 09 27 0A
           ^
00000780  5D 0A 94 0A D1 0A 00 00 D9 01 91 01 91 01 91 01

[ddrecovery]

Very interesting observations.