WD Charger ROM fault / Encrypted data with donor ROM.

Hello all - Merry Christmas!

I've reached a dead-end on this Charger. Before anyone suggests it, I have already considered that the PCB on this charger is not the original. According to the owner and the PC Shop it went into first, it has not been changed. I am inclined to believe them given the type of failure shown.

The problem:

HDD when powered on with native USB PCB spins up. There are no clicking noises. The HDD is not detected.

The ROM chip was read by an external reader (see attached). Then ROM was reprogrammed to an unlocked SATA PCB to work on SA. When HDD is powered on the HDD enters RDY, but in Kernel mode. Launching Utility shows an error with ROM. See below:

HDD Info reading........................ : Ok
Heads number............................ : 4
Cyl Count............................... : 384
ROM:
Read ROM................................ : Ok
ROM Data size........................... : 1024 Kb
Flash ROM dir reading................... : Ok (Active)
Flash ROM dir reading (Ext)............. : Ok
Modules directory address............... : 212 461
SA regions address...................... : by default
Module 02 access........................ : Granted

SA SPT.................................. : 0

ROM Modules:
ROM version............................. : 06.8JE
ROM F/W version......................... : Module ID 4F reading error Device Error Detected: "FM ERR HEADER II SIGNATURE INVALID"
Overlay F/W version..................... : 06.8JE
Servo F/W version....................... : 03.6I

Head Map Reading Error.................. : Module ID 0A reading error Device Error Detected: "FM ERR HEADER II SIGNATURE INVALID"

Relocations............................. : 0 (0)

Read ROM modules
Into file............................... : <HDD Profile>\Data\ROM
Module : 0A............................. : Module ID 0A reading error Device Error Detected: "FM ERR HEADER II SIGNATURE INVALID"
Module : 0B............................. : Ok
Module : 20B............................ : Ok
Module : 30............................. : Module ID 30 reading error Device Error Detected: "FM ERR HEADER II SIGNATURE INVALID"
Module : 47............................. : Module ID 47 reading error Device Error Detected: "FM ERR HEADER II SIGNATURE INVALID"
Module : 0D............................. : Module ID 0D reading error Device Error Detected: "FM ERR HEADER II SIGNATURE INVALID"
Module : 4F............................. : Module ID 4F reading error Device Error Detected: "FM ERR HEADER II SIGNATURE INVALID"
Module : 181............................ : Ok
Module : 1A2............................ : Module ID 1A2 reading error Device Error Detected: "FM ERR HEADER II SIGNATURE INVALID"
Module : 1B6............................ : Module ID 1B6 reading error Device Error Detected: "FM ERR HEADER II SIGNATURE INVALID"
Module : 1B0............................ : Ok

====

Using a donor 06.8JE ROM from another Charger HDD it is possible to calibrate the HDD to RDY, read ID, and read all firmware modules OK. Also, all LBA values are readable (obviously encrypted with SATA PCB). Please note that the donor ROM version was a matching in 06.8JE, but the donor Overlay F/W Revision was 06.8KE.

A ROM chip with the donor ROM was physically transferred to the patient PCB. The patient HDD spins up, is correctly detected with ID and 2TB capacity. It is possible to read all LBA via USB. However, all data is encrypted.

As far as I am aware encryption is controlled by the MCU. The ROMs on Charger are not unique, and matching the same ROM F/W Revision is enough. ROM rebuilding from the SA data on Charger is not possible (at least in PC3000).

Any suggestions?

Best regards,
John

Attachments

6343 ROM IS25WP080D Read by External.zip: Original ROM; (661.2 KiB) Downloaded 1088 times

Only thing I can think of is finding the same overlay FW - I've had a quick look and it's not one I've got.

Indeed, trying to find a match on the FW Overlay and the ROM revision is proving difficult. If anyone has got one then it would helpful to rule out the Overlay FW revision making a difference.

Thanks,
John.

PC3000 is producing errors because it is detecting 0x20B as the directory module whereas in fact it should be 0x0B.

Code:: Analysing 6343 ROM IS25WP080D Read by External.bin ... Searching for LDSCs and verifying PCMBlocks ... LDSC LDSC Att PCMBlock RAM size PCMBlk CS Start ID CS Start - End address RAM / ROM Exp/Act ----- -- -- -- ----- ----- -------- ------ ----- --------- 0 5A ED 04 20 - 1B47 1000 1B24 1B24 000AA627 000AA627 OK (digitally signed) 2000 01 49 04 2180 - 4AA0 49688 2820 2820 BA BA OK 2020 02 07 11 4AA1 - 8B05 30080000 c 5580 4064 18 18 OK 2040 03 66 0C 8B06 - 8EFA 24000000 3F4 3F4 D3 D3 OK 2060 04 AC 40 8EFB - DCD3 FFE00200 4DD8 4DD8 19 19 OK 2080 05 D3 01 DCD4 - E7E0 38268800 c D48 B0C 2D 2D OK 20A0 06 C4 04 E7E1 - EC81 38269800 4A0 4A0 79 79 OK 20C0 07 12 01 EC82 - 14B12 0 c 7894 5E90 F6 F6 OK 20E0 08 B6 01 14B13 - 14F33 DE84 c 4EC 420 C8 C8 OK 2100 09 98 03 14F34 - 175CC 40340 c 3160 2698 00 00 OK 2120 0A AD 03 175CD - 179A5 6026A800 c 9BC 3D8 2B 2B OK 2140 0B 4B 01 179A6 - 2FEAE 38352800 c 208B0 18508 F6 F6 OK 2160 0C 4E 01 2FEAF - 556CF 38008230 c 32DCC 25820 88 88 OK 82000 01 49 04 82180 - 84AA0 49688 2820 2820 BA BA OK 82020 02 07 11 84AA1 - 88B05 30080000 c 5580 4064 18 18 OK 82040 03 66 0C 88B06 - 88EFA 24000000 3F4 3F4 D3 D3 OK 82060 04 AC 40 88EFB - 8DCD3 FFE00200 4DD8 4DD8 19 19 OK 82080 05 D3 01 8DCD4 - 8E7E0 38268800 c D48 B0C 2D 2D OK 820A0 06 C4 04 8E7E1 - 8EC81 38269800 4A0 4A0 79 79 OK 820C0 07 12 01 8EC82 - 94B12 0 c 7894 5E90 F6 F6 OK 820E0 08 B6 01 94B13 - 94F33 DE84 c 4EC 420 C8 C8 OK 82100 09 98 03 94F34 - 975CC 40340 c 3160 2698 00 00 OK 82120 0A AD 03 975CD - 979A5 6026A800 c 9BC 3D8 2B 2B OK 82140 0B 4B 01 979A6 - AFEAE 38352800 c 208B0 18508 F6 F6 OK 82160 0C 4E 01 AFEAF - D56CF 38008230 c 32DCC 25820 88 88 OK LDSC = PM Loader Config String (32 bytes) ID = ID byte of LDSC (byte #0) CS = Checksum byte or word Att = Attributes PCMBlk = Program Code Memory Block Exp = Expected checksum for PCMBLock Act = Actual checksum for PCMBLock c = compressed PCMBlock size = size of decompressed (in RAM) and compressed (in ROM) PCMBlock in bytes ROYL directory module 0x000B found at 0x7F43E Active directory flag = 0x03 Identifying SA regions ... Reg# Reg size Reg loc ---- ---------- ---------- 0x00 0x000A6338 0x00000000 0x01 0x000A6338 0x000AA49C Verifying ROYL modules ... ID Size (bytes) Address Checksum dir hdr dir hdr ---- ---- -------- -------- -------- -------- 0001 N/A 00004000 N/A 00033DED N/A 000A OK 0000004E 00000200 0007E000 00000000 OK 000B OK 0000013D 00000200 0007F43E 00000000 OK 020B OK 0000013D 00000200 0007D43E 00000000 OK 0030 OK 00000400 OK 000FE000 00000000 OK 0047 OK 000006A4 00000800 0007E556 00000000 OK 000D OK 00000108 00000200 0007E04E 00000000 OK 004F OK 00000400 OK 0007E156 00000000 OK 0181 OK 00000C00 OK 000FE400 00000000 OK 01A2 OK 0000007E 00000200 0007EBFA 00000000 OK 01B6 OK 0000069E 00000800 0007EC78 00000000 OK 01B0 OK 00000128 00000200 0007F316 00000000 OK ROYL directory module 0x020B found at 0x7D43E Active directory flag = 0x04 Identifying SA regions ... Reg# Reg size Reg loc ---- ---------- ---------- 0x00 0x000A6338 0x00000000 0x01 0x000A6338 0x000AA49C Verifying ROYL modules ... ID Size (bytes) Address Checksum dir hdr dir hdr ---- ---- -------- -------- -------- -------- 0001 N/A 00004000 N/A 00000000 N/A 000A FFFF 0000004E 01FFFE00 0007C000 0000FFEC BAD 000B OK 0000013D 00000200 0007F43E 00000000 OK 020B OK 0000013D 00000200 0007D43E 00000000 OK 0181 OK 00000C00 OK 000FE400 00000000 OK 0030 OK 00000400 OK 000FE000 00000000 OK 0047 FFFF 000006A4 01FFFE00 0007C556 FFFFFE57 BAD 000D FFFF 00000108 01FFFE00 0007C04E FFFFFFBE BAD 004F FFFF 00000400 01FFFE00 0007C156 FFFFFF00 BAD 01A2 FFFF 0000007E 01FFFE00 0007CBFA 0000FFE0 BAD 01B6 FFFF 0000069E 01FFFE00 0007CC78 2643F628 BAD 01B0 OK 00000128 00000200 0007D316 00000000 OK dir - Module ID/Size as reported in directory module (0x20B or 0x0B) hdr - Module ID/Size as reported in module's header N/A - Not Applicable BAD - Module has invalid checksum. This may be due to non-existent module. ROM modules saved to Flash_00\000Bmods and Flash_00\020Bmods Active directory is 0x20B Analysing active 0x0A module ... Module has bad checksum -- processing aborted Analysing active 0x0D module ... Module has bad checksum -- processing aborted Analysing active 0x4F module ... Module has bad checksum -- processing aborted Analysing active 0x47 module ... Module has bad checksum -- processing aborted

The active directory flags in modules 0x0B and 0x20B don't appear to follow the usual format.

module 0x20B

Code:: Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00000000 52 4F 59 4C 04 80 1E 00 0B 02 01 00 68 50 D6 BD ROYL.€......hPÖ½ 00000010 30 30 30 33 30 30 30 30 00 00 00 04 03 00 0C 12 00030000........ ^^^^^

module 0x0B

Code:: Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00000000 52 4F 59 4C 04 80 1E 00 0B 00 01 00 E8 9A FB 94 ROYL.€......èšû” 00000010 30 30 30 33 30 30 30 30 00 00 00 03 02 00 0C 12 00030000........ ^^^^^

Could we see the donor ROM? I could swap the active flags in the patient ROM, if PC3000 can't do it.

FWIW, the warranty expiration date is 14-Mar-2023. If you suspect that the ROM is not original, you could examine the YYWW/YWW date codes on the ICs and see how they compare against the warranty date. You could do the same for both the patient and donor so that you know what to expect.

I copied the mods in 0x0B to the locations specified in 0x20B.

Attachments

ROM_mods_copied.7z: (329.01 KiB) Downloaded 985 times

Thanks for the responses. I've been working on this with some help extracting the contents of 129 and creating a repaired version of the patient ROM. This repaired version of the patient ROM now calibrates the HDD to RDY normally with access to the SA. However, when using the repaired ROM, with imported ROM modules from 129, the HDD is unstable and makes clicking sounds and reads slowly. Using the repaired ROM on both on SATA unlocked and patient USB it is still possible to read LBA and shows as encrypted. However, the data shown is the same as when using the donor ROM.

What I did not notice before, is that the encrypted data shown in LBA is the same regardless of when the unlocked SATA or the patient USB PCB is used. See screenshot attached.

To me, this leaves the possibilities:
1) Some failure of the patient USB PCB and that the MCU is no longer decrypting data.
2) The USB PCB is not the original PCB, and that it was swapped with another Charger PCB which does not use MCU based encryption (as per the earlier models of Charger).

Whilst I am aware of the possibility of of disabling SED Lock by comparing 1A2 in the ROM, and 1A2 from with 129.rpm, I am not aware that MCU based SED encryption can be turned on or off. As far as I am aware it cannot.

For reference this is a WD20SDRW-11VUUS1
DOM: 19 JAN 2021

Best regards,
John

Attachments

Do you photograph drives on intake - if so any clues from the screw heads regarding the pcb state.

If you take a working donor drive and perform the same ROM "repair" procedure, do you still have access to your data? That should tell you if there is anything wrong with your methodology.

Could we see your repaired ROM? Did you try my repaired version?

A long shot . . .

Have you tried WD's SMART tools on the drive when connected to a USB port? I'm wondering if the drive has a user-defined password.

cheadledatarecovery wrote:For reference this is a WD20SDRW-11VUUS1
DOM: 19 JAN 2021

If you can provide good photos of both sides of the PCB, I'll be able to tell you whether the PCB is likely to be original.

cheadledatarecovery wrote:Flash ROM dir reading................... : Ok (Active)
Flash ROM dir reading (Ext)............. : Ok

Head Map Reading Error.................. : Module ID 0A reading error Device Error Detected: "FM ERR HEADER II SIGNATURE INVALID"

Read ROM modules
Into file............................... : <HDD Profile>\Data\ROM
Module : 0A............................. : Module ID 0A reading error Device Error Detected: "FM ERR HEADER II SIGNATURE INVALID"
Module : 0B............................. : Ok
Module : 20B............................ : Ok
Module : 30............................. : Module ID 30 reading error Device Error Detected: "FM ERR HEADER II SIGNATURE INVALID"
Module : 47............................. : Module ID 47 reading error Device Error Detected: "FM ERR HEADER II SIGNATURE INVALID"
Module : 0D............................. : Module ID 0D reading error Device Error Detected: "FM ERR HEADER II SIGNATURE INVALID"
Module : 4F............................. : Module ID 4F reading error Device Error Detected: "FM ERR HEADER II SIGNATURE INVALID"
Module : 181............................ : Ok
Module : 1A2............................ : Module ID 1A2 reading error Device Error Detected: "FM ERR HEADER II SIGNATURE INVALID"
Module : 1B6............................ : Module ID 1B6 reading error Device Error Detected: "FM ERR HEADER II SIGNATURE INVALID"
Module : 1B0............................ : Ok

Can people not see that the active directory has a problem? Compare the modules in the 000Bmods and 020Bmods (active directory) in my attachment. The bad modules are filled with 0xFF.

My patched ROM simply copies the modules in the 000B directory over the top of the corresponding uninitialised modules in the 020B directory.

I can't offer any insight into how a ROM can get into this state, but at least this patch should make PC3000 happy.

The .dec files in my attachment are decompressed versions of the corresponding PCMBlock. The "rev" files are dword-reversed versions of the compressed PCMBlocks.

Attachments

Flash_00.7z: (330.92 KiB) Downloaded 815 times

I'm sorry for the delay in my reply, I was away for Christmas and New Year.

I tried using the 000Bmods provided in the 7z file in two ways:
1) Writing these to the original patient ROM.
2) Writing these to the donor ROM.

The result is the same in each case - PC3000 reports the ROM checksums as OK, but HDD does not calibrate normally. No drive ID, or capacity. Writing back the full donor ROM still allows for correct ID, full capacity and access to all LBA. The data remains encrypted with the same hexadecimal values showing whether the SATA PCB is used or the USB.

Given that the patient USB PCB is not decrypting the data, and given the date of manufacture I would expect it is SEDv2 CPU based, is there any feasibility that method in which controls the encryption (the key) is somehow reset or non-functioning? Clearly, the obvious reason for these results is that the USB PCB provided is not the original, and is an earlier revision that does not use CPU based SEDv2. However, the customer is adamant that it is the original PCB.

Best regards and a happy new year,
John

Finally, to add - when the patient USB PCB is used on the patient HDD, with donor ROM, the HDD calibrates normally in Windows. Using the WD Discovery software, the HDD reports as "WD Elements". As a consequence of being an Elements series, it does not have the option to set a user password in WD Security.

J

--

cheadledatarecovery wrote:Clearly, the obvious reason for these results is that the USB PCB provided is not the original, and is an earlier revision that does not use CPU based SEDv2.

And how would you know that?

https://forum.hddguru.com/search.php?keywords=YWW+YYWW&terms=any&author=&sc=1&sf=all&sk=t&sd=d&sr=posts&st=0&ch=300&t=0&submit=Search

I've been analysing a Charger ROM and associated SA modules (109, 11, 129) in another thread. If you can upload these modules, I can tell you if they are likely to be compatible.

YYWW code on MCU is 2050.

Attached are selected modules from the patient HDD.

Regards,
J

--

Attachments

6343 rpm..zip: (1.03 MiB) Downloaded 722 times

The manufacture date of the MCU (week 50 of 2020) predates the date on the label by 1 month.

109.rpm (ver 06.8J)

Code:: Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00004900 00 F0 83 62 53 4D 42 45 47 56 45 52 30 36 2E 38 .ðƒbSMBEGVER06.8 00004910 4A 45 00 00 53 4D 45 4E 44 56 45 52 45 44 33 33 JE..SMENDVERED33

ROM (ver 06.8J in both halves of ROM)

Code:: Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00004700 00 F0 83 62 53 4D 42 45 47 56 45 52 30 36 2E 38 .ðƒbSMBEGVER06.8 00004710 4A 45 00 00 53 4D 45 4E 44 56 45 52 45 44 33 33 JE..SMENDVERED33 ........ 00084700 00 F0 83 62 53 4D 42 45 47 56 45 52 30 36 2E 38 .ðƒbSMBEGVER06.8 00084710 4A 45 00 00 53 4D 45 4E 44 56 45 52 45 44 33 33 JE..SMENDVERED33

11.rpm (ver 06.8K, 0006008K)

Code:: Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00000000 52 4F 59 4C 03 80 30 00 11 00 D1 07 36 42 02 B9 ROYL.€0...Ñ.6B.¹ 00000010 30 30 30 36 30 30 38 4B 07 07 07 00 00 00 55 AA 0006008K......Uª ........ 000D4B80 00 53 4D 42 45 47 56 45 52 30 36 2E 38 4B 45 00 .SMBEGVER06.8KE. 000D4B90 30 30 30 36 30 30 38 4B 30 33 2E 36 49 00 30 36 0006008K03.6I.06

129.RPM (ver 0006008J in ROYL mod 0x4F)

Code:: Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00006A90 52 4F 59 4C 04 80 1E 00 4F 00 02 00 3D 18 CA 04 ROYL.€..O...=.Ê. 00006AA0 30 30 30 36 30 30 38 4A 00 00 00 00 00 00 00 00 0006008J........

0x1A2 and 0x129 have the same 96-byte signature

Code:: Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00007AA0 11 FC 00007AB0 FC C7 64 37 2B AD 77 BD 78 3B D5 AE CB 14 95 CE 00007AC0 DE 3A 95 A6 0A F4 B5 B6 F3 72 32 BE DB 1F 55 10 00007AD0 47 FF CC 31 54 3D 6F 3D BF BD 4B 5B 7D 58 A0 EB 00007AE0 A9 DF 4A 49 E6 CC 9A E7 A7 29 AF 16 85 72 DD 53 00007AF0 0D 5C 6A F9 CB 85 32 28 3D AD 80 0C 36 9C 8A C1 00007B00 8A 73 0B E4 78 73 91 69 A9 DC 13 E3 DC D7

Thanks.

Given the DOM of the MCU is a month before the DOM of the HDA then it seems to be in the range of it being native.

Regardless, of what has happened to this ROM, at this point in time there does not seem to be a method to allow for decryption or to resolve what has caused the failure of decryption. It has been necessary to call time on this job.

May I thank those who have assisted in the forum.

Best regards,
John

WD Charger ROM fault / Encrypted data with donor ROM.

WD Charger ROM fault / Encrypted data with donor ROM.

Re: WD Charger ROM fault / Encrypted data with donor ROM.

Re: WD Charger ROM fault / Encrypted data with donor ROM.

Re: WD Charger ROM fault / Encrypted data with donor ROM.

Re: WD Charger ROM fault / Encrypted data with donor ROM.

Re: WD Charger ROM fault / Encrypted data with donor ROM.

Re: WD Charger ROM fault / Encrypted data with donor ROM.

Re: WD Charger ROM fault / Encrypted data with donor ROM.

Re: WD Charger ROM fault / Encrypted data with donor ROM.

Re: WD Charger ROM fault / Encrypted data with donor ROM.

Re: WD Charger ROM fault / Encrypted data with donor ROM.

Re: WD Charger ROM fault / Encrypted data with donor ROM.

Re: WD Charger ROM fault / Encrypted data with donor ROM.

Re: WD Charger ROM fault / Encrypted data with donor ROM.

Re: WD Charger ROM fault / Encrypted data with donor ROM.

Re: WD Charger ROM fault / Encrypted data with donor ROM.

Re: WD Charger ROM fault / Encrypted data with donor ROM.

Re: WD Charger ROM fault / Encrypted data with donor ROM.

Re: WD Charger ROM fault / Encrypted data with donor ROM.

Re: WD Charger ROM fault / Encrypted data with donor ROM.