_________________
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.