Seagate ROM reconstruction using extremely identical donor

[Paulo Braga]

Hello friends, good morning.

I know that rebuilding the ROM on a Seagate hard drive is something complex, I confess that I've actually tried some things in some cases and I've never been successful.

But I wouldn't ask for help if I didn't have an IDENTICAL working donor.
These two hard drives (attached) were in a QNAP RAID and are now in RAID 0. One disk has been fully cloned and the second has a corrupted ROM.
The HDD with problems does not turn on and when transferring the ROM to another PCB, the PCB stops working. I read the ROM with an EPROM reader and the PC3000 says that the ROM is corrupted and that there is no valid information (no sap, no id, s/n, nothing).
I have a good donor here, with EVERYTHING IDENTICAL even the serial number is close (because they were on the same RAID equipment).
Would any help be possible?

Thanks!

[pbzcbf...@gmail.com]

This is what happens when you only read half the ROM.

Can you upload your ROM dumps?

[Alandata Recovery]

I have the same issue

I read half the rom and rewrote it... boo...

I need a solution for a

st4000lm016

hope theres a way...

--
Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/88a64833-ae1b-47fd-a6f7-954b238f4768n%40googlegroups.com.

--

Alandata Data Recovery -  (949)287-3282  
"Cleanroom Data Recovery of RAID, VMware, NAS, Linux, Tape, Disk, Forensics"

www.alandata.com   www.alandataRecovery.com

[Fraser Corrance]

although I have not had great luck with Grenada family, it may be possible to cut and paste parts of the donor ROM into your patient ROM. In the event that the RAP file is damaged, it might be possible to recreate some of the RAP settings using a few terminal commands. 

Upload your patient and donor ROMs. That would be a good starting point. 

[Paulo Braga]

Good day friends!

Thanks for all the replies, and sorry for the delay. 

I now send the 2 ROMs, good and bad. 

Thank you for your help and attention!

Paulo Braga 

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/fcc3f169-5202-478a-9963-ea7c70851434n%40googlegroups.com.

[jol qwerr]

Just thinking

Maybe you used the wrong woltage while trying to read the (bad) ROM?!

[pbzcbf...@gmail.com]

Good ROM header

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

00000000  AB 0C 00 00 60 07 00 00 00 00 00 00 EF BB 04 00  «...`.......ï»..
00000010  63 73 69 44 00 00 CF E9 48 8F 00 00 20 FF FF FF  csiD..ÏéH... ÿÿÿ
00000020  1D 00 00 00 22 00 01 00 1E 00 00 03 17 00 F0 03  ....".........ð.
00000030  1D 00 00 04 23 00 01 04 05 00 00 07 06 00 50 07  ....#.........P.
00000040  04 00 F0 07 00 10 F2 07 83 E5 00 00 FF FF FF FF  ..ð...ò.ƒå..ÿÿÿÿ


Bad ROM header

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

00000000  AB 0C 00 00 60 07 00 00 00 00 00 00 EF BB 04 00  «...`.......ï»..
00000010  63 73 69 46 00 00 67 F4 A4 47 80 00 10 7F FF FF  csiF..gô¤G€...ÿÿ
00000020  8F 40 00 00 08 80 00 40 07 C0 00 00 63 70 0F 00  .@...€.@.À..cp..
00000030  31 D0 00 00 42 30 00 10 40 50 00 00 70 60 05 00  1Ð..B0..@P..p`..
00000040  70 40 0F 00 70 01 0F 20 78 3E 50 00 0F FF FF FF  p@..p.. x>P..ÿÿÿ


The headers begin to differ at offset 0x13.

44 00 00 CF E9 48 8F 00 00 20 FF FF FF --> 0100000000000000000011001111111010010100100010001111000000000000000000100000111111111111111111111111
 *************************************

If we shift 1 bit to the right, we get ...

                                           0010000000000000000001100111111101001010010001000111100000000000000000010000011111111111111111111111
02 00 00 67 F4 A4 47 80 00 10 7F FF FF        2   0   0   0   0   6   7   F   4   A   4   4   7   8   0   0   0   1   0   7   F   F   F   F   F
 *************************************

This matches the bad stuff in the bad header.

Therefore, it appears that the corruption is the result of a bit shift in the stream of bits that is being read by the reader. If worse comes to worse, it may be possible to painstakingly reconstruct the ROM with appropriate left shifts. I have written a tool for this purpose, but I don't envy the person who will have to do this job (not me).

[pbzcbf...@gmail.com]

If you dump the bad ROM twice, are the two dumps identical? If so, then this would suggest that someone rewrote the ROM with a bad dump.

[t...@desertdatarecovery.com]

Good spot Franc.

 

Tim Homer - Lead Engineer

Desert Data Recovery

t...@desertdatarecovery.com

www.desertdatarecovery.com

--

Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/84a0530a-d535-4d1a-a79e-3e45c04edb35n%40googlegroups.com.

[Alandata Recovery]

I read the rom twice to verify

and use a lower baud rate like 460800

then check other roms in the family for size

if other roms are 1k and you read 512 then thats bad....

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/072201d8fe98%249f1e0b20%24dd5a2160%24%40desertdatarecovery.com.

[Luke Coughey]

I've been in the habit of reading the patient ROM and writing it back to a donor board, just to play it safe. While we do have the habit of verifying whether we got the full ROM, this practice is a failsafe.

Luke Coughey

CEO

Recovery Force Inc

866-750-3169

http://www.recoveryforce.com

This e-mail is intended solely for the person or entity it is sent to and may contain confidential and/or privileged information.  Any review, dissemination, reproduction or other use of this e-mail by persons or entities other than the intended addressee is prohibited.  If you have received this e-mail in error, please contact the sender immediately and delete and destroy this message, all attached material and all electronic reference from all computing based devices.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/CAH-%2BjWQwCDJZsdYbFZ2MjJU790CK9BOh7Tut_kNRJQbbPfNG4g%40mail.gmail.com.

[pbzcbf...@gmail.com]

http://users.on.net/~fzabkar/FreeBasic_W32/Utils/rotshift.bas

http://users.on.net/~fzabkar/FreeBasic_W32/Utils/rotshift.exe

On Wednesday, November 23, 2022 at 4:24:52 AM UTC+11 pbzcbf...@gmail.com wrote:

I have written a tool for this purpose ...

[jol qwerr]

@Frank

I'm not so sure about the shift you are referring to

[pbzcbf...@gmail.com]

The CAP segment is located between offsets 0x70000 - 0x7020F. The bad segment has numerous bit shifts. You can see this if you apply my tool and rotate or shift the bad segment through 1 to 7 bits.

The first offset appears to involve 3 bits, then there is an additional 2-bit offset, then an extra 1-bit offset, and so on.

The offsets accumulate and don't appear to follow any regular pattern. By the time you reach the end of the CAP, the total offset is around 40 bits. Therefore, I don't believe it would be feasible to write a tool to reverse the damage.

To me, this corruption is weird. Normally when there is transmission problem in a serial data line, one would expect that bits would be dropped rather than added, as is the case here. My feeling is that 1 bits are sometimes being counted twice.

[pbzcbf...@gmail.com]

That should have been 0x7F000 - 0x7F20F.

[pbzcbf...@gmail.com]

I'm thinking that there is/was a problem with the Clock signal. The SPI flash chip outputs each data bit on the falling edge of the clock. If the clock is weak, then the chip doesn't see it, and the host then retrieves whatever indeterminate "data" is sitting on the chip's Data Out pin. On the falling edge of the next good clock signal, the chip then serves up the data bit that should have been served up during the previous bad clock.

The missing clocks would explain the bit shifts. The extra data bits could be repeats of the previous good bits, assuming that bits remain at their previous states until the next clock cycle.

[jol qwerr]

@the OP

Do you have a reading made externally too (external programmer)?

[pbzcbf...@gmail.com]

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

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



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

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

[Paulo Braga]

Hello all. 

Thanks for the information! 

Yes, these drives came from another lab and the problem ROM has been resoldered. I understand the problem, but for me and for the case budget, I think I won't be able to help. 

Thanks for everything! 

Paulo  

--

Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/dead1697-2224-4121-b13c-aa3b4208557en%40googlegroups.com.

[pbzcbf...@gmail.com]

"Lab"? I think not.

On Thursday, November 24, 2022 at 5:13:12 AM UTC+11 pauloa...@gmail.com wrote:

Yes, these drives came from another lab ...

[Fraser Corrance]

Franc, 

Thanks for the awesome explanation, as always. :-)

Is there a way to test the clock signal or is just a matter of knowing that the symptom (the shifted and duplicated data) is caused by that? Are there any good methods of identifying the location of those shifts that you are aware of?

Fraser

[pbzcbf...@gmail.com]

I would think that the only way to check the clock would be to watch it on an oscilloscope. I'm also wondering if the clock rate may have been too high.