WD5000BMVW 771814 Decryption Error

[Josh256]

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.

Attachments

[michael chiklis]

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

[fzabkar]

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

[Josh256]

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

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.

Attachments

edek.txt

(2.5 KiB) Downloaded 40 times

38.txt

(128.5 KiB) Downloaded 39 times

25.txt

(128.5 KiB) Downloaded 43 times

[Josh256]

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

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

Attachments

[michael chiklis]

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.

EDEK.txt

(512 Bytes) Downloaded 48 times

[Josh256]

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.

The attachment EDEK.txt is no longer available

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

Attachments

[michael chiklis]

Try this

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

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

[Josh256]

Try this

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

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

In UFS it asks for password...

Attachments

[Josh256]

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

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?

[fzabkar]

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

[Josh256]

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

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.

[michael chiklis]

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?

[Josh256]

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?

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.

[michael chiklis]

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?

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.

[pepe]

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

[michael chiklis]

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.

[pepe]

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

[michael chiklis]

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.

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

[Josh256]

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.

Attachments