F3 Kahuna_5400 ROM problem

[Jakiro]

hello,
i get this Hybrid drive with no power or register blinking at all, tried to parse ROM error message pop up saying 

"WARNING!
ROM image contains critical damaged objects
[RAP , SAP]"

Not gonna lie, I'm a bit of a newbie when it comes to ROM repair, so I'm hoping someone out there can lend a hand! Any advice or expertise would be seriously appreciated! 

Validation Key........... : 0x00000020
Fam ID................... : 0x72 (Kahuna_5400)
Fam Member............... : 0x3
Head count............... : 2
Date..................... : 01 Sep 2015
SN....................... : W765X7E2
PCB SN................... : 0000M6090FEZ
PCB PN................... :  100748047
WWN...................... : 5000C5008B625184
MDL1..................... : ST500LM000-1EJ162                      
MDL2..................... : ST500LM000                              
Capacity................. : 976773168

tool i use is Pc3000

[Rames Lopes]

I think fzragvf and people can correct it, yes duild 02, 06 and 07

--
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/248b537a-91d6-409f-bc04-523a3ff45328n%40googlegroups.com.

[ריקברלי - שחזור מידע‎]

How can you fix 2/6/7 modules please?

 

 

 

Recoverli – Data Recovery Lab

רחוב אריה שנקר 3 פתח תקווה

משרד: 077-2050000

וואטסאפ/נייד: 050-7400003

He...@Recoverli.co.il דואר אלקטרוני:

www.Recoverli.co.il אתר אינטרנט:

 

From: datarecovery...@googlegroups.com <datarecovery...@googlegroups.com> On Behalf Of Rames Lopes
Sent: Wednesday, December 20, 2023 2:38 PM
To: datarecovery...@googlegroups.com
Subject: Re: F3 Kahuna_5400 ROM problem

 

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/CAG68MtQe-LTjVzemBDCs%3Dvsnv7oytqRi3oPopPBnowV2w4k%2B8g%40mail.gmail.com.

[t...@desertdatarecovery.com]

Have you looked at this?

https://blog.acelab.eu.com/pc-3000-for-hdd-sshd-drives-what-is-it-and-how-to-work.html

 

Tim Homer - Lead Engineer

Desert Data Recovery

t...@desertdatarecovery.com

www.desertdatarecovery.com

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/AM0P195MB075554019BD2F7BC3588114F9D96A%40AM0P195MB0755.EURP195.PROD.OUTLOOK.COM.

[pbzcbf...@gmail.com]

The RAP and SAP are full of junk. Also, the segments look nothing like another "72 KahunaV" ROM in my collection.

To me, it appears that some idiot or saboteur has trashed the ROM.

[pbzcbf...@gmail.com]

What appears to have happened is that the DL_UDSBFW segment at 0x31000 has overwritten the SAP and RAP at 0x70000. Only the last 0x2000 bytes of the RAP are still present.

[Jakiro]

Thanks for the replies and clarification!

 Franc, i  confirmed with the customer that this HDD wasn't previously in another lab, which eases concerns about intentional manipulation.

However, I did notice an unusual amount of oxidation on the PCB and HDA connector, more than I'd expect for this drive family. This could potentially be the source of the issue.

Despite trying multiple ROM reading attempts with different tools and baud rates, all results indicate the same corrupted ROM with no bit differences.

[pbzcbf...@gmail.com]

This is the real UDSBFW segment (size = 0xE000):

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

00031000  10 55 44 53 FC 37 FB 09 57 56 00 BD FF FF FF FF  .UDSü7û.WV.½ÿÿÿÿ
00031010  0C 52 4C 45 CC B7 06 00 E3 DF 00 00 0A 00 53 54  .RLEÌ·..ãß....ST
00031020  58 A9 CC B7 06 00 5C 03 00 03 0F 00 02 00 00 FA  X©Ì·..\........ú
00031030  57 79 C0 34 82 2A 15 40 08 00 7E 00 00 05 03 00  WyÀ4‚*.@..~.....
00031040  01 00 02 00 00 04 01 00 08 00 00 03 01 00 09 00  ................
00031050  00 03 08 00 57 56 00 BD 00 04 00 02 00 04 01 00  ....WV.½........
00031060  E8 00 00 05 09 00 72 03 53 54 35 30 30 4C 4D 00  è.....r.ST500LM.
00031070  30 03 20 06 2F 00 30 35 32 37 30 39 34 38 44 45  0. ./.05270948DE
00031080  4D 44 43 38 35 37 32 30 31 35 57 37 36 35 58 37  MDC8572015W765X7
00031090  45 32 50 00 C5 00 8B 62 51 84 00 58 79 C0 34 82  E2P.Å.‹bQ„.XyÀ4‚

This is the bogus UDSBFW segment (size = 0xE000):

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

00070000  FF FF FF 10 55 44 53 FC 37 FB 09 70 A6 26 EE FF  ÿÿÿ.UDSü7û.p¦&îÿ
00070010  FF FF FF 0C 52 4C 45 CC B7 06 00 E3 DF 00 00 0A  ÿÿÿ.RLEÌ·..ãß...
00070020  00 53 54 58 A9 CC B7 06 00 5C 03 00 05 0D 00 02  .STX©Ì·..\......
00070030  9A 3B 77 C0 34 82 2A 15 40 08 00 7E 00 00 05 03  š;wÀ4‚*.@..~....
00070040  00 01 00 02 00 00 04 01 00 08 00 00 03 01 00 09  ................
00070050  00 00 03 08 00 70 A6 26 EE 00 04 00 02 00 04 01  .....p¦&î.......
00070060  00 E8 00 00 05 09 00 72 03 53 54 35 30 30 4C 4D  .è.....r.ST500LM
00070070  00 30 03 20 06 2F 00 30 35 32 37 30 39 34 38 44  .0. ./.05270948D
00070080  45 4D 44 43 38 35 37 32 30 31 35 57 37 36 35 58  EMDC8572015W765X

00070090  37 45 32 50 00 C5 00 8B 62 51 84 A0 3B 77 C0 34  7E2P.Å.‹bQ„ ;wÀ4

The bogus segment has overwritten the tail end of BFWCTNR1, all of the SAP and the first 0x8000 bytes of the RAP.

I see "FILE0" in this segment:

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

00031220  00 03 01 00 08 00 00 0A 01 00 01 00 00 04 08 00  ................
00031230  08 00 00 F0 07 00 00 46 00 03 07 00 46 49 4C 45  ...ð...F....FILE
00031240  30 00 03 00 00 09 01 00 00 00 00 03 01 00 03 00  0...............

This makes me wonder whether this area is a data cache ("FILE0" is the signature of an NTFS $MFT record).

[Jakiro]

This MFT header appearing in the ROM image is unexpected and wired. From your experience, Franc, would rebuilding the ROM with a donor image be a viable option?

[pbzcbf...@gmail.com]

No. The SAP and RAP are unique. 

You could ask @pepe at HDD Guru. He has had some success in these cases.

[Jakiro]

 Franc. I truly appreciate your willingness to share your knowledge and guidance.

[pbzcbf...@gmail.com]

ISTM that this drive is a victim of a strange firmware bug. Some drives have a ROM-based NVcache which is intended for power loss data protection. That said, it seems strange that, in this SSHD, the ROM would be used for this purpose rather than the NAND. :-?

FWIW, I notice that there is a firmware update (from Dell DEMD to DEMM/DEMN):

https://www.dell.com/support/home/en-au/drivers/driversdetails?driverid=05f88

Fixes & Enhancements

Fixes:
- Fixes issue encountered in some system where BIOS password fail to security unlock.

Enhancement:
- Improves the NAND cache data recovery to prevent system hang due to NAND wear out.

[Jakiro]

 That's a strong line of thinking, Franc. Since tampering is out of the picture, Your firmware bug theory makes perfect sense, especially considering the NAND usage in SSHDs. I'm curious, how such a bug might manifest like this in the ROM? 

[pbzcbf...@gmail.com]

Some drives will save pending write data to ROM in the event of a power loss. Perhaps the firmware became confused and saved the data to the wrong location?