WD MCU - No more...

[fzabkar]

20 Aug 2020
2024
2003
015
1220

There are several others that I can't read (your photo is unclear).

[einstein9]

20 Aug 2020 from the HDD sticker

Now where is the other info from the pcb side? if the image is not clear, just point to the place where you wanted me to focus on and will make a better image 4u


FYI: relying on Dates is not a good idea since the hdd production line produces many on the same date right?

BUT
my findings is certain ...

[fzabkar]

Now where is the other info from the pcb side?

On the component side.

Show me the ROM and MCU, without the thermal pad.

[fzabkar]

Quick for you guys:

Suppose someone replaced the "native usb3 pcb" with another and he wrote native rom to it

Anyone knows how to tell if this pcb is for that drive? (in case if both pcbs have the same native ROM)

:!:

It looks like nobody wants to play your game.

I'm guessing that simply trying each PCB to see which one starts the drive and decrypts the data is not an acceptable solution? Obviously I don't have any experience in this area, but I'll start by identifying security-related objects.

There are these 3 ROM resident ROYL adaptive modules:

Code:

1A2 : SED KEY
1B6 : Digital signature
1B0 : Digital Signature

The ROM boot block is digitally signed at the end of the block.

One of the ROM's PCMBlocks is a compressed 0xDDDD ROYL module. I have attached an example from a SpyGlass3. If I understand correctly, 0xDDDD is required for initialising the drive's crypto-engine.

I expect that the digital signatures may have no relationship to the MCU key. One way to find out would be to compare two drives that have identical firmware and check whether their identical boot blocks have the same signature.

Another test would be to install a donor PCB with identical firmware on a patient HDA, after transferring the ROM adaptives one by one.

Another test might be to execute an ATA 90h Execute Drive Diagnostic command and observe any error code.

Attachments

DDDD.7z

(2.76 KiB) Downloaded 65 times

[fzabkar]

I remembered this old thread:

https://forum.hddguru.com/viewtopic.php?p=264106#p264106

It appears that 0xDDDD is not unique.

[Doomer]

Nobody noticed, what if the MCU is physically damaged or the entire native PCB is missing.

Is there a solution ?

The code that creates the MCU keys (there are 2 keys involved in data encryption) calls for a random generator inside the MCU, so unless there is a security weakness inside the random generator (very unlikely) or the keys are also copied somewhere else on the drive (possible but not likely) it would not be possible to decrypt data without the original MCU

Last edited by Doomer on September 1st, 2026, 23:52, edited 1 time in total.

[Doomer]

Anyone knows how to tell if this pcb is for that drive? (in case if both pcbs have the same native ROM)

Yes, it's possible with about 99% certainty.

[Doomer]

I have to disagree with you here Doomer:

1- Removing the MCU Key will result in encrypted data
2- Moving Key to another MCU PCB works (tested)

I'm not sure with what you are disagreeing.
I've never said removing the keys, I said extracting the keys and writing a software decryptor (would not be easy, because the keys are salted but possible)

Last edited by Doomer on September 2nd, 2026, 0:00, edited 1 time in total.

[Doomer]

I remembered this old thread:

https://forum.hddguru.com/viewtopic.php?p=264106#p264106

It appears that 0xDDDD is not unique.

0xDDDD is a security overlay (digitally signed) that, AFAIR, checks signature of module 0x11 (main code overlay).
It's not unique

[einstein9]

Quick for you guys:

Suppose someone replaced the "native usb3 pcb" with another and he wrote native rom to it

Anyone knows how to tell if this pcb is for that drive? (in case if both pcbs have the same native ROM)

It looks like nobody wants to play your game.

I'm guessing that simply trying each PCB to see which one starts the drive and decrypts the data is not an acceptable solution? Obviously I don't have any experience in this area, but I'll start by identifying security-related objects.

There are these 3 ROM resident ROYL adaptive modules:

Code:

1A2 : SED KEY
1B6 : Digital signature
1B0 : Digital Signature

The ROM boot block is digitally signed at the end of the block.

One of the ROM's PCMBlocks is a compressed 0xDDDD ROYL module. I have attached an example from a SpyGlass3. If I understand correctly, 0xDDDD is required for initialising the drive's crypto-engine.

I expect that the digital signatures may have no relationship to the MCU key. One way to find out would be to compare two drives that have identical firmware and check whether their identical boot blocks have the same signature.

Another test would be to install a donor PCB with identical firmware on a patient HDA, after transferring the ROM adaptives one by one.

Another test might be to execute an ATA 90h Execute Drive Diagnostic command and observe any error code.

This is not a Game fzabkar,, A research and finding thing, you are not in DR (i wish if u were) but what you are telling about changing pcbs and figure out which is booting and so is a time wasting approach. many other easier ways to do the same work.

[einstein9]

Anyone knows how to tell if this pcb is for that drive? (in case if both pcbs have the same native ROM)

Yes, it's possible with about 99% certainty.

Am 100% certain of my finding (PM OTW)

[einstein9]

Nobody noticed, what if the MCU is physically damaged or the entire native PCB is missing.

Is there a solution ?

The code that creates the MCU keys (there are 2 keys involved in data encryption) calls for a random generator inside the MCU, so unless there is a security weakness inside the random generator (very unlikely) or the keys are also copied somewhere else on the drive (possible but not likely) it would not be possible to decrypt data without the original MCU

Sure it is there somewhere (in another form)
Unique KEY which is located inside MCU is also located somewhere on the drive.

When drive powers ON drive reads & compares both if match will carry on booting IF NOT (even if same native ROM) data enc. (compare Enc. data with multiple donor PCBs and figure out the pattern).

[fzabkar]

This is not a Game fzabkar,, A research and finding thing, you are not in DR (i wish if u were) but what you are telling about changing pcbs and figure out which is booting and so is a time wasting approach. many other easier ways to do the same work.

One of the easier ways is to observe the date codes, at least for some cases. I can do that from a photograph.

https://www.hddoracle.com/viewtopic.php?p=495#p495

And thank you for your well wishes. Actually, my first data recovery case was during the 1980s. It was intellectually satisfying, and I do wish that my trajectory had continued on that path in later years. In fact, Ontrack's first case was during that time. Also, Steve Gibson was writing Spinrite during those years (it actually had some relevance then).

[einstein9]

This is not a Game fzabkar,, A research and finding thing, you are not in DR (i wish if u were) but what you are telling about changing pcbs and figure out which is booting and so is a time wasting approach. many other easier ways to do the same work.

One of the easier ways is to observe the date codes, at least for some cases. I can do that from a photograph.

https://www.hddoracle.com/viewtopic.php?p=495#p495

And thank you for your well wishes. Actually, my first data recovery case was during the 1980s. It was intellectually satisfying, and I do wish that my trajectory had continued on that path in later years. In fact, Ontrack's first case was during that time. Also, Steve Gibson was writing Spinrite during those years (it actually had some relevance then).

I did not know this Thnx for the info..

btw, you are doing very well, should think about investing in DR and give it as shot

all the best.

FYI, knowing if the pcb is native or not takes 20sec. only

[pepe]

even without ROM?

[Doomer]

FYI, knowing if the pcb is native or not takes 20sec. only

There are a few drives when PCB is changed on the factory without recertifying the drive, so far I've see only two such drives, that's why I said 99% not 100%.

[unknown]

Nobody noticed, what if the MCU is physically damaged or the entire native PCB is missing.

Is there a solution ?

The code that creates the MCU keys (there are 2 keys involved in data encryption) calls for a random generator inside the MCU, so unless there is a security weakness inside the random generator (very unlikely) or the keys are also copied somewhere else on the drive (possible but not likely) it would not be possible to decrypt data without the original MCU

Thanks for the info.
That means there's no constant keys located in the FW to compare with the one created randomly in MCU?. If I understand well.

even without ROM?

???????

[Doomer]

That means there's no constant keys located in the FW to compare with the one created randomly in MCU?. If I understand well.

If the keys would have been constant there would be no point using original MCU, any MCU would work.

[Doomer]

When drive powers ON drive reads & compares both if match will carry on booting

This is very doubtful.
At least I have never seen any comparison.

[fzabkar]

When drive powers ON drive reads & compares both if match will carry on booting

This is very doubtful.
At least I have never seen any comparison.

Please excuse ignorant me for asking the obvious question, would @einstein9, or his researchers, not have tested this claim by modifying the copy of the key?