linux-mybook-tools icon indicating copy to clipboard operation
linux-mybook-tools copied to clipboard

1.5TB WD MyBook Studio PLX OXUF943SE keyblock not found

Open mechcalvin opened this issue 5 years ago • 41 comments

Hello Thomas, not sure you are already too fed up with all the help request, but i try to send and request anyway

basically i tried your method to mount an encrypted WD drive in linux yet i have difficulty finding the keyblock and i was told by the professional wd datarecovery center ontrack, they say this model, the hdd cannot contains any DEK, and i have carelessly throw away the pcb, with some hope i found your pdf and want to give it a try. my hdd details

Name: WD MyBook Studio HDD S/N: WDBAAJ0015HSL-00 Size: 1.5TB
Vender ID: Device ID: 1058:1112 Control Board: 4060-705066-003 REV. P1 Chipset: PLX OXUF943SE no password protected

if i understand correctly, your script (appendix E) try to scan a block contains ^53496e45 starting from the end of the hdd, i have scanned over 80MB but the keyblock is not found, i am pretty scared by the fact this specific model do not follow other model that actually stored the DEK in the HDD, and my USB-to-SATA board is lost forever.

is there anything i can try? the data is extremely precious

thanks in advance Calvin

mechcalvin avatar May 10 '19 15:05 mechcalvin

You can try a tool called HDDSuperTool (google it). It only runs in linux, but it can dump the service-area modules. The keyblock might be in one of them, If not, then it was probably in an EEPROM chip on the PCB.

themaddoctor avatar May 10 '19 15:05 themaddoctor

So far, I have only seen two disks with that chip that stored the keyblock on the disk, and they were 3TB disks. It's the least common chip.

themaddoctor avatar May 10 '19 15:05 themaddoctor

thanks, the key is definitely on EEPROM, but i threw away the PCB... T_T will try the service-area, just want to confirm it is true not all model of that chipset stored the keyblock on disk

mechcalvin avatar May 10 '19 15:05 mechcalvin

If you find it, please send me a copy of the module that contains it. Thanks.

themaddoctor avatar May 12 '19 16:05 themaddoctor

i only got the direct block to block copy of the original hdd because i fear i might to cause dmg to the original if i read on it too much, so i need to get back the original hdd to dump the SA from the data center, the recovery center also stated there is nothing in SA, but i will give it a shot anyway. because it seems quite impossible for me to believe there is no trace of WD DEK on the HDD, that's the only (quite stupid) reason i threw away the pcb. will let you know. thanks for your reply

mechcalvin avatar May 12 '19 17:05 mechcalvin

i finally got my original hdd back and plugin into sata, however i don't know how to dump SA from HDDsupertool, actually i don't even know which version i should download first

http://www.sdcomputingservice.com/hddsupertool/download

i am running intel cpu with Ubuntu, is it possible for me to get any assist?

themaddoctor [email protected] 於 2019年5月13日週一 上午12:21寫道:

If you find it, please send me a copy of the module that it contains. Thanks.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/themaddoctor/linux-mybook-tools/issues/33#issuecomment-491609241, or mute the thread https://github.com/notifications/unsubscribe-auth/AFPET6BOMXL2BJGELGWNEXTPVA7ZHANCNFSM4HMEAKTQ .

-- "And now these three remain: faith, hope and love. But the greatest of these is love.**” - Bible

mechcalvin avatar May 25 '19 17:05 mechcalvin

I used the x64 tar.gz package once, because I have a 64-bit CPU.

themaddoctor avatar May 25 '19 21:05 themaddoctor

dumpmodules.zip

done after running hddsupertool -> "VSC" -> "dump all modules". it ends with

prepare to read Command failed! sense_key=0x5 asc=0x21 ascq=0x4 error=0x0 count=0x0 lba=0x0 device=0x0 status=0x0 altstatus=0x0 command_status= 0x0 data_transferred= 0x200

Script reached END command at line 91, exiting normally... Total program run time = 78 seconds

i think i have encountered similar situation to this: https://github.com/andlabs/reallymine/issues/49

how can i check which module is service area and possible key?

mechcalvin avatar May 26 '19 06:05 mechcalvin

I'm sorry, but I don't see a keyblock in your dumps.

themaddoctor avatar May 26 '19 17:05 themaddoctor

Thanks anyway. So maybe for this model. The key only exist in the board rom... Is there anything i can try?

mechcalvin avatar May 27 '19 01:05 mechcalvin

You could find another data-recovery company and ask if they can read the chips on the controller board (attached directly to the drive), to see if they can find anything. If necessary, you can send me their dumps of the chips and I will look at them. Other than that, I have no ideas.

themaddoctor avatar May 27 '19 02:05 themaddoctor

that controller board is forever lost.... i guess the only chance of getting those data back is waiting for the arrival of quantum computer. sob

mechcalvin avatar May 27 '19 03:05 mechcalvin

I mean the board on the disk itself. It has some memory chips as well.

themaddoctor avatar May 27 '19 03:05 themaddoctor

were there any cases the key is stored there?

mechcalvin avatar May 27 '19 04:05 mechcalvin

I don't know. Sorry. When I help people, it is always over the net, and I never have a chance to examine the physical drives. I may have mentioned above that I have only seen maybe two with the PLX chip that have the keyblock on the user's data area of the disk (near the end). In all other cases, no one has told me that they found it elsewhere. Look at https://eprint.iacr.org/2015/1002.pdf On page 10 they seem to be saying that the EEPROM is on the USB bridge card. But then on page 11 they say that they have been able to find the keyblock on the harddrive itself.

I'm sorry, but it doesn't look good.

If you want to send me a dump of the last 5 MB of the disk, I will look for the keyblock personally, in case the script missed it by mistake.

themaddoctor avatar May 27 '19 19:05 themaddoctor

I've been trying to decrypt a friend's drive that is similar:

Name: WD MyBook Studio HDD S/N: WDBAAJ0020HSL-01 Size: 2TB Control Board: 4060-705066-007 REV. P1 Chipset: PLX OXUF943SE-LQAG no password protected

I modified the findkeyblock.sh file to search the last 40MB for the key and it wasn't able to find it. After looking through all the related threads it seems that the keyblock might not be located on the disk.

FWIW, the size variable of the script printed "3907029168" for this drive. Looks like in your PDF it was set with a *.

I'll probably have the drive around for a while if there's anything you're interested in testing out for curiosity's sake.

dereekb avatar Sep 27 '19 00:09 dereekb

If you could dump the service modules, there is a chance that the keyblock is in one of them. The tool I would use to dump them is here: http://www.sdcomputingservice.com/hddsupertool/download Then if you send them to me, I am willing to look.

If it's not there, then it must be on one of the memory chips on the USB-SATA card.

themaddoctor avatar Sep 27 '19 00:09 themaddoctor

Here is the dump. Seems to be similar to the one posted in the issue below, except has a couple less dumped files.

https://github.com/andlabs/reallymine/issues/49#issuecomment-334214164

2TBModulesDump.zip

Good news though, apparently the microUSB port on the USB-SATA card still worked so we were able to recover all the data off of the drive without having to decrypt it.

dereekb avatar Sep 28 '19 15:09 dereekb

That's good, because a quick grep of the modules didn't turn up the keyblock.

themaddoctor avatar Sep 28 '19 15:09 themaddoctor

Thanks, I appreciate your help.

Looks like the only way for someone to get their data recovered with this chip/size is to have the pcb and send it in to get it professionally recovered, unless they can read the EEPROM themselves.

dereekb avatar Sep 28 '19 16:09 dereekb

Not always. I have seen one with the keyblock on the drive, at the end, in the area blocked by the PLX chip but seen with a generic enclosure. I'm leaving this comment here in case anyone comes looking for info about this chip in the future.

Glad you got your data back.

themaddoctor avatar Sep 28 '19 16:09 themaddoctor

Hello sir. I've a similar problem in that I have the 1.5TB with a JM538S chip. After running "sudo dd if=/dev/sdc bs=512 skip=2930272288 count=1 of=kb.bin" AND "hexdump -C kb.bin" I find the WDv1 (a couple of times, see photo), however after the next four commands, DEK1 is not found at all in the following hex dump. I'm at a loss as to what to do now. Can you help?

PXL_20210204_142250384

slashinpdx avatar Feb 04 '21 14:02 slashinpdx

I don't work from screenshots.

themaddoctor avatar Feb 04 '21 15:02 themaddoctor

My apologies and thank you for responding. I was only providing it as an indication that it seemed to find the correct information using the offset provided for the 1.5TB (you'd suggested to contact you if I have this drive size, which indicated to me I might need some other offset than skip=2930272288). I'm providing both the kb.bin and the kek1.hex in zipped format, if you are able to provide some assistance in how I wasn't able to find DEK1 in the 17th line of the kb3.bin. Thank you very much! kek1.hex.zip

kb.bin.zip

slashinpdx avatar Feb 04 '21 15:02 slashinpdx

What is your password?

themaddoctor avatar Feb 04 '21 16:02 themaddoctor

thanh4$$

slashinpdx avatar Feb 04 '21 16:02 slashinpdx

That password does not agree with the kek1.hex that you sent, and also does not work to extract the DEK.

themaddoctor avatar Feb 04 '21 16:02 themaddoctor

You have to escape the $'s. "thanh4$$"

themaddoctor avatar Feb 04 '21 16:02 themaddoctor

Thank you!!!

slashinpdx avatar Feb 04 '21 16:02 slashinpdx

Before you go, what is the date of manufacture from the label on the disk?

themaddoctor avatar Feb 04 '21 16:02 themaddoctor