I have a WD5000BMVW-11AMCS4 (PCB: 2060-771814) with an initial head issue.
After a head swap the drive spins up, IDs correctly, and SA reads, but it cannot read real data. In the sector editor the MBR signature 55 AA is missing (data appears encrypted).

I attempted decryption using MRT’s USB HDD Decryption tool:

“Ignore Self-Encryption” checked → MRT shows the error:
“DEK is invalid, please confirm whether the wrong password is input.”

“Ignore Self-Encryption” unchecked → MRT enters User sector viewer successfully, but the data remains encrypted and 55 AA is still missing.

Get the key manually from mod 25 or 38.
https://www.youtube.com/watch?v=_qrs7PgStGU

_________________
My firmware database:
https://mega.nz/folder/O01DkBRI

Can you dump the last 66000 sectors from the drive? That's where the key and password hint would be stored.

_________________
A backup a day keeps DR away.

I checked the tutorial, and my results don’t look correct.
The EDEK and module 25 do not contain the same key, and module 38 is almost empty (mostly 00h).

I’ve uploaded the dumps here in case anyone can take a look.
They are uploaded as .txt for the forum—please rename them to .rpm (for modules) and .bin (for EDEK) and then open them in a hex editor.

I imaged the last 66000 but not sure how to dump it as MRT only allows to save one sector at a time...

your EDEK is incorrect, i'm not sure why (i think it's the MRT bug that occasionally appears on some drives, which i identified since older versions of MRT and reported on youtube). This is likely why MRT DE isn't decrypting your HDD data.

I manually extracted the EDEK from your mod 25, it should be ok.

_________________
My firmware database:
https://mega.nz/folder/O01DkBRI

Thanks for taking the time to extract the EDEK manually. I tested the modified file, but unfortunately I’m still getting the same error.

Try this


also, you can try to decrypt it in UFS Explorer (in TOOLS - Drives/Bridges Security)

_________________
My firmware database:
https://mega.nz/folder/O01DkBRI

In UFS it asks for password...

I imaged the last 66,000 sectors and opened the image file in WinHex, so I can view all the sectors. What should I be looking for in there?

A password hint would be in plain text, if it exists. But surely your client would know the password?

_________________
A backup a day keeps DR away.

The issue is that the client was asked twice, and both times they confirmed that they never set a password for the drive. So not sure whether this is a user-set password or something related to WD’s encryption.

Sometimes when you swap heads but you get them from donors which is not similar enought with patient, it can read as garbage.
I have found in the past this issue on WD when donor heads are able to read all surface but not able to write on SA.
Are your donor heads able to modify SA modules?

_________________
My firmware database:
https://mega.nz/folder/O01DkBRI

Yes, you’re 100% right! It must be the heads. When I try to modify/write SA modules, MRT reports success, but after refreshing the module the changes revert back, so it’s clearly not writing to the SA. The heads must be unable to write/modify the modules. Really appreciate it — no one would’ve guessed this issue. I’ll order a new donor and test.

yep, that's the exact symptom what i was referring to.
Let us know about after proper donors heads swap.

_________________
My firmware database:
https://mega.nz/folder/O01DkBRI

decryption has nothing to do with writing, in fact you don't need to write anything to a working drive. If you managed to back up SA, and the drive inits, don't try to modify it unless you are absolutely sure it is necessary. Alternatively you can use hotswap. But decryption problem won't be solved by finding correctly writing heads.
ECU makes sure the data you get is ok, it won't give you garbage. If head is weak you get UNC, IDNF or ABRT. There is a chance to get wrong data if translation is corrupt.
Also, if you find that the data is unchanged by writing, that's because it is written at wrong place, as in, it corrupts something else in many cases. So be careful with that.

pepe

_________________
Adatmentés - Data recovery

I had years ago a WD5000AAKS drive (Tahoe LT family if i remember well) with faulty heads, i swapped with donor heads but i've got garbage reading (high speed reading, only few bad sectors).
Then i swapped heads again, this time a choose a donor much closer as possible to the patient and it read perfectly.

I've noticed that 1st donor heads were not able to write on SA (or maybe they were writing at the wrong place).
2nd donor heads were writing good on SA.

_________________
My firmware database:
https://mega.nz/folder/O01DkBRI

Whatever happened to that TahoeLT, it wasn't related to SA writing. I stay confident until somebody explains how exactly it would affect reading like that. The fact that once something like that happened does not mean there is a causal relation between the two.
I did a few thousand WDs, never cared about sa writing (at least not as you wrote) and had no issue with garbage data.
Problem in translation, on the other hand, can cause shifts, which can occur as garbage data...
These drives use Symwave bridge encryption, but OP's tool shows JMS538, isn't that causing an issue?
although Zephyr supports SED, i never saw it being turned on. On this model it is surely off, so SED is out of question here.

pepe

_________________
Adatmentés - Data recovery

I didn't express myself well !
I didn't mean that the failure of the heads to write on SA (or to write incorrectly) caused the misreading problem, but simply that the failure of the donor heads to write meant that the read elements on the heads were also not suitable for the patient disk. So, simply put, i believe the first set of donor heads i had installed on that TahoeLT were not suitable for reading (because of the read element). Normally, this translates into a complete inability to read any sector on user area (or very instable reading) or even the inability to access the SA, but in certain cases like mine and probably also in Josh256's case, the heads (the read element of the heads) which are not well compatible with the donor are still able to access the SA but exhibit the misread symptom in the user area (they read in the wrong position, causing the shift).

_________________
My firmware database:
https://mega.nz/folder/O01DkBRI

Thanks guys for all your help.

The donor drive was delivered today and I've swapped the heads. The drive can now read and write on SA; however, the same issue persists. I contacted the client for the third time, and they have confirmed that no password was set. At this point, I am not sure what further can be done.