_________________
Kuwait Data Recovery - UNIX GTC
The only reason for time is so that everything doesn't happen at once. By: Albert Einstein

I tested it
0x8003 and 0x8028 have no effect on drive's encryption

I took a Spyglass2UL and wrote the modules from a Charger - no effect on drive's encryption or capacity (not a surprise).

_________________
SAN, NAS, RAID, Server, and HDD Data Recovery.

Hi,
Tested on WD50NDZW-11A8JS1

>ROM version............................. : 00.0AA
>ROM F/W version......................... : 0000000A
>Overlay F/W version..................... : 00.0BA
>Servo F/W version....................... : 03.7B

Mikippp

It's at offset 0x46 in section 3. That was one of my candidates.

_________________
A backup a day keeps DR away.

without research, merely supposition: when a true SED drive is locked by pw using the wd sw, the bridge must present something to the host for the user to be able to unlock it, and that's the vcd partition. It is likely read from the 'missing' area by the bridge in some way. But this area does not contain any info related to decryption keys, only the sw, most probably. Basically the 'who cares' type of info for me, there are lot more interesting things about these drives...

_________________
Adatmentés - Data recovery

I now realise that this area is not important for data recovery purposes, but I'm still interested to see what's there. The interesting thing, at least for me, is that the VCD area that is hidden by the bridge is actually larger than the 65536 sectors that are hidden by the SATA HDD.

_________________
A backup a day keeps DR away.

how do you know the size of the VCD area?

_________________
Adatmentés - Data recovery

See my other thread.

_________________
A backup a day keeps DR away.

@einstein9

I suppose you say it is not 1,2,3 because it is required to solder some micro tin wire to some of the MCU I/O pins

and the second part could be setting up the R/W operations

would you like to share the difficulties?

Just in case, thank you in advance

R.

I doubled checked the firmware that generates the CPU keys.
The drives makes a request to hardware entropy generation registers to generate random keys, each key is created separately.
The are 256 bytes of random data, creating 8 keys in total. All 8 are written to the CPU.
Only two keys are used for the encryption, these 2 are selected from the 8 based on CPU hardware state.
The keys don't leave the secure CPU ROM or SRAM (unless they are read through JTAG externally).

Conclusions
1. I find it hard to believe that module 0x8003 has any security information
2. If the keys are stored on the drive they should have been read through JTAG and written somewhere thus creating an intentional backdoor
3. The keys can be written to either system area or even to servo, to hide them

_________________
SAN, NAS, RAID, Server, and HDD Data Recovery.

Sorry for the late reply here to your point here Doomer, i was busy with other issues..

Anyway, am sure some of all of you still have some doubts about this post and after thinking about i came up with following proposal [b]which is limited only for "Doomer" here[/b]
i respect his knowledge and am sure all members here respect his opinion and decisions.

Doomer, Am willing to send you one of those MCU locked drives but to make it even better here for you and everybody i could say now that:
Am able to turn off encryption from MCU itself and you can use any SATA compatible pcb to access the data, found the trigger finally which is even better for my proof of concept.

I will send you one or multiple drives as you prefer here (i cover the shipping to you anywhere), and all what you need to do is one thing (will PM you the details only)
and you will have One Week to test and make your research and verification and send me back my drive(s) healthy as you took it (you cover shipping back).

Once you verify, and here is my Request to you: You will acknowledge here on this forum + Acelab Forum that my research or whatever you will find is true.
I don`t need anything else except your word here in public and am ready whenever you are.

btw I will post here the Tracking of shipment in public for everyone to follow up.

_________________
Kuwait Data Recovery - UNIX GTC
The only reason for time is so that everything doesn't happen at once. By: Albert Einstein

I don't understand what you proposing, need some clarification.
First there are MCU locked drives (access to vendor commands is locked by checking MCU fuses), and there are MCU encrypted drives (keys from MCU encrypt ROM modules which encrypt SA modules which encrypt user data).
The MCU lock is currently bypassable by either unlocked MCUs or by firmware stack injection (there is nothing new here).
The MCU encrypted drives are more interesting, because this where the main problem of accessing user data is (currently we need original MCU, your method is to clone original MCU by ether soldering some wires or by writing some parts of SA to another MCU, correct me here if I'm wrong).
As for drives that don't use MCU for encryption (so we can use SATA PCB for decryption), there is nothing interesting in them, the are plenty of such drives including first generation of Spyglass, and early FW versions of Charger and Palmer drives. Disabling decryption through MCU does not solve the problem of accessing user data on the drives where MCU keys are used for encryption.
If you'd like to show a proof of concept I propose the following. I can take an MCU encrypted drive and write some data to it. Then I'll disable the encryption on the drive and read the encrypted data then I can post the encrypted data from this drive somewhere on the Internet. I'll email you drive's system area (or whatever you want me to email). You'll decrypt the data and post the results for everybody to see.
Also my goal is not to doubt your work, I'm really interested in this and I might even have some work coming your way. I'm sure many DR companies would be interested too.

_________________
SAN, NAS, RAID, Server, and HDD Data Recovery.

Ok Doomer, i will try to make it more clear and simple here:

New drives wich unique MCU locked that i mean is those new families such as SpyG3 for example that comes with USB3 unique MCU which means if i use SATA compatible pcb data will be encrypted.

Now, the same example here Am saying that i managed to find the trigger On/Off to disable MCU encryption, which means after i disable the enc. trigger you will be able to access the data with the compatible SATA pcb.

the example here am proposing is SpyG3 2023

you got my point here?

_________________
Kuwait Data Recovery - UNIX GTC
The only reason for time is so that everything doesn't happen at once. By: Albert Einstein

Yes, I understand that you can disable encryption in Spyglass3 drives. What I don't understand is how it's going to help decrypt the drives where this encryption is enabled.
Also what about my proposal?

_________________
SAN, NAS, RAID, Server, and HDD Data Recovery.

i think he's trying to say that he can get the drive to decrypt the encryption key using the MCU key, from there the decryption can be done using any compatible pcb, since DEK is not crypted with mcu key. That's what i figured...

_________________
Adatmentés - Data recovery

Could be so, but my question remains. How can it help in decypting drives that use MCU for encryption. Where it the proof of concept here?

_________________
SAN, NAS, RAID, Server, and HDD Data Recovery.

pepe is right here..

As for your proposal:

"I can take an MCU encrypted drive and write some data to it. Then I'll disable the encryption on the drive and read the encrypted data then I can post the encrypted data from this drive somewhere on the Internet. I'll email you drive's system area (or whatever you want me to email). You'll decrypt the data and post the results for everybody to see.
Also my goal is not to doubt your work, I'm really interested in this and I might even have some work coming your way. I'm sure many DR companies would be interested too."

l have to repeat again as in my PM, the hdd must be with me, not just decrypt any random selection.
My point is crystal clear, Those PCB MCU`s are unique, and i figured a way to Clone it (clone the pcb) as i explained in my PM.

If your PCB is dead/beyond repair access to MCU unique key is possible (if mcu not damaged, never saw one yet) and by having the unique key i can write it back to any other pcb (clone) and you can use it.

OR

As i said, i can send you from those new Gen. 2023 2025 SpyG2 Ultra or SpyG3 which are 100% MCU locked without Native PCB, i`ll send you only the drive (without pcb)
and will upload here Native ROM where you can write it to ANY USB3/SATA and will work. PnP

_________________
Kuwait Data Recovery - UNIX GTC
The only reason for time is so that everything doesn't happen at once. By: Albert Einstein

I see the confusion here
They are not 100% locked, some drives just don't encrypt the data.
That's why it cannot be a proof of concept.


Ok, this is less interesting to me but for the sake of other people who might be interested in using this technology we can do the following test.
I can take a drive, write some data to it and ship the drive to you (I assume you'd be willing to cover the shipping) without the orignal PCB (I'll PM/email you the ROM of course).
You decrypt the data and post the decrypted results (I'll think how to make the results publicly verifiable), if the result is correct I'll aknowledge it here.

_________________
SAN, NAS, RAID, Server, and HDD Data Recovery.

What do you mean by not 100% locked here? MCU Locked are Locked, have you ever seen drives with MCU Locked not locked here? (or anyone else?)

i offered you in prev. post "I will send you one or multiple drives as you prefer here"

Can you tell me what is the diff. between my drives and yours if both are new? both are 2023 at least (some are 2025)

_________________
Kuwait Data Recovery - UNIX GTC
The only reason for time is so that everything doesn't happen at once. By: Albert Einstein

i have seen some Sg2 ultra drives having SED off, but as such, these were not encrypted at all, not just 'not MCU locked'.
btw, we should agree on some terminology for these drives, coz 'MCU locked' is misleading, as Doomer has already draw attention to this. What we mean here is not really a lock, coz we can access anything, ... just encrypted...
We used to use 'MCU locked' for drives you cannot access the fw at all without first unlocking the fw or using an unlocked MCU.
I suggest using something like 'MCU-tied' encryption.
pepe

_________________
Adatmentés - Data recovery