bridge type PLX (Oxford Semiconductor) #129
Comments
|
I saw in another post the you requested the person to run dumpfirst so I included it in the attached zip file. Also, here is the output of dumpkeysector if you need it for any reason. |
|
I wonder if something is wrong with your keyblock. It looks suspicious. Can you dump these two sectors? |
|
sudo dd if=/dev/sda count=1 skip=3907029888 of=3907029888.bin |
|
Both report zero bytes I have the drive connected as a physical drve to a Linux guest in VMware. fdisk -l list the /dev/sda but dd gives this message:
|
|
|
Can you attach it to a true linux machine? |
|
Or dump more of the end of the disk? |
|
BTW, using the keyblock that you posted does not give the correct key needed to decrypt the start-of-disk sample you also posted. |
|
Alright. I'm setting up a physical Linux system. I may try the dumpkeysector again on the physical system. Does this look correct to dump the last 4MB? 4MB is 8000 sectors so I subtracted that from the fdisk sector count. sudo dd if=/dev/sda skip=3907021896 of=last4MB.bin |
|
Are you still using the WD enclosure or bridge card? You need to use SATA or a generic enclosure. |
|
The WD enclosure died so I've been putting one of the hard drives in a Startech dock and connecting it via USB. |
|
I was going to use a spare Intel NUC that I have that way. I'll open it up and connect it with the spare SATA port it has. |
|
The dock should work fine. Yes on |
|
Here's the last 4MB of the drive, well, 8K sectors. I'm running dumpkeysector on this physical Linux system again, just in case. It took a few days on the Linux VM though. Also, I noticed that the two sectors you asked me to dump go beyond the sector count of the drive. Are there two other sectors you would like me to dump? |
|
The last 4MB contains only zeroes. It took so long because it kept looking, even when it should have stopped. Please look at the bridge card and verify the chip number. |
|
Alright, I'll take a look at it tonight. I'll post again tomorrow. Thanks! |
|
I have the Duo taken apart but I'm not sure which chip has the information you need? I've attached the pictures of the front and back.
|
|
That's what I was afraid of. You have the JMS561 chip, which we do not yet understand. |
|
BTW, the reason the program ran so long and told you that you had a PLX chip is that it kept going until it found a 4-character string ("SinE") that it recognized. That string was present in your data only by accident. |
|
Is the free version enough or should I purchase the temporary license of the Pro version? |
|
I've only ever used the free one. |
|
I'm looking through the user manual but I'm not sure what command to run? I see the various scripts and hddmenu. Use hddmenu, VSC, 6) WD royl (Marvel) dump all modules? Also, I see a few warnings that commands may not work on USB drives so I should connect the drive to the open SATA port on the NUC? |
|
Yes. |
|
I received an error dumping all modules VSC, option 6. The output is below as well as the output for Identify device and Smart info. Thank you! |
|
Sorry. I don't know. |
|
This page suggests that if you replace the bridge card with an identical one, then the disks are decrypted like they were with the original card. That could mean that the key is stored in the modules somewhere. It could also mean that you could get your data back if you can buy a replacement card. https://forum.hddguru.com/viewtopic.php?f=1&t=36609&sid=086cee23d2cfee3a654ec5b9eeb638be&start=20 |
|
Can you try talking to the creator of HDDSupertool about the error? I am very curious to know where that key is kept. Not only will that information help you, but someone comes along with a WD Duo every few months with the same problem. |
|
I have the same issue and also a platine with the JMS561. Connecting the drive directly to my native Linux gives me which surprises me, because I know there should be multiple partitions. The output of hddsupertools looks disheartening as well I am able to retrieve data like so but it appears to just be a huge blob nonsensical data.
|
|
I'm afraid I can't be of much help at this point. sudo dd if=/dev/sda count=1 | hexdump -C |
|
I have the same device: MyBook 1112 (0XUF943SE) with a 2 TB drive. I have been scanning the raw blocks looking for 'SInE' and so far have found 11 different ones. Strange thing happened with my drive. It was encrypted, I plugged it in, inserted the password, and the drive only decrypted the file structure but not the actual files (except for about 20 of them). So now it thinks it's unlocked, I can see all the folders and the files, but I can't open anything. This was all on a macintosh computer. I've attached photo of the board + all the 'SInE' instances I've found so far. I started scanning backwards, from the end first, so image 0 is the last one. Any help on how I can go about to decrypt my files will be greatly appreciated. Drive still works so I can extract more info if anyone is interested. |
|
That doesn't make any sense. The disk is either completely encrypted or completely open. You probably have an issue with user permissions. |
|
I know it makes little sense, but it's not a permissions issue. I have read/write permissions on all the files that don't open... It gets even weirder when you take into account that only a bunch of files (less than 20) still open but all the others (thousands of photos, videos, work files, etc) don't open. Here's the message I get when trying to open anything: 
|
|
According to everything I have read about these drives, and the fact that the KEK is supposed to be somewhere on the raw drive starting with 'SInE', and the fact that so fat I have found 29 different locations with 'SInE' on the drive (and still counting, since so far I have only scanned 5% of it), I'm thinking maybe, for some strange reason there are multiple KEK instances and the drive somehow used the wrong one to decrypt the files... Is that even possible? |
|
|
Here's an example of what a simple .txt file that was on the drive looks like now.
|
|
The SInE instances that you showed do not look like keyblocks, because the SInE marker is not at a block boundary. There may be other information stored on the disk that is related to the bridge card, for example the WD software that you used to set or enter a password. Everything is read through the bridge card, which means everything goes through the PLX chip. So, it would be expected that everything is encrypted or everything is not. The only other explanation I can think of is that you have an intermittent error. What happens if you try to read the same file a thousand times? Is the result exactly equal? What if you dump a big chunk of the disk and examine the result; can you see readable data in it? |
|
The software used to encrypt the device was the original WD_Utilities app that came with it. I don't think it was on the drive, at least I cannot see it in the directory structure. I am using iBored on a macintosh to read those raw blocks. Also, the drive is connected to the original board. I'm not sure what happens if I try to read a file 1000 times, because I haven't tried that, but I have, however, tried to read the data multiple times in various different computers and systems along the last 8 or 9 months, since it developed this issue. The sg_raw command I used to read the first blocks shows that the returned byte3 means locked state according to the 'got HW crypto? On the (in)security of a Self-Encrypting Drive series' PDF by Gunnar Alendal (00 == no password set, 01 == locked, 02 == unlocked, 06 == locked out ), so my drive thinks it has no password set. Could it be possible that byte3 somehow got switched to 00 due to an error, but the password is actually set? I could (possibly) try to write over byte3 and set it as 01. How would I go about extracting the KEK from the chip? If I could manage to grab that I could try decrypting one of the files manually. Thanks for your answers and your patience. |
|
In normal use, encryption is never removed or changed. When you change the password, all that changes is the wrapped version of the KEK that is stored. In other words, the password is used only to read the KEK, and the KEK is constant. [There is a "quick-erase" feature that replaces the KEK so that all previous data is lost because the old KEK is lost.] If you want to find the KEK, it is either stored on disk in a region blocked by the bridge card or in an EEPROM. If it is the former, then you can find it by removing the disk from the WD enclosure, removing the bridge card, and connecting the drive to the computer with a generic enclosure or directly to the motherboard with an SATA cable. Search the last few megabytes of the drive for another SInE block. |
|
Thank you very much! Just another quick question before I try getting the KEK through a generic enclosure: The PDF I mentioned above says the KEK is normally 256 bits (32 bytes), but the result from the sg_raw output I posted above says the length of the KEK is 20 (bytes?).... |
|
I don't know what iBored is, and I don't want to know. Sorry, I meant to say DEK in the above. The DEK (disk key) is stored in a block whose length is 256 bytes. The DEK is encrypted with the KEK (key-encryption key). The KEK and DEK are both 16 or 32 bytes, but you can't find them exposed on the disk. You have to find the 256-byte block that starts with SInE on a sector boundary. A sector is a 512-byte block. This is what a keyblock looks like: 00000000 53 49 6e 45 01 00 00 00 02 00 64 01 b6 f8 84 00 |SInE......d.....| 00000010 01 00 00 00 f5 ac 78 09 56 cb a1 48 7e 92 f7 43 |......x.V..H~..C| 00000020 98 47 b1 2b 37 dd 2b 57 7c c8 37 4f 4b b5 40 f4 |.G.+7.+W|.7OK.@.| 00000030 f2 c2 ea eb ba 7c 54 7e 58 a7 ff c9 3f fc 0b 55 |.....|T~X...?..U| 00000040 0f 81 66 cf 1a d8 85 74 11 9e 57 52 b0 83 06 0d |..f....t..WR....| 00000050 8f cd 11 f3 ff ff ff ff ff ff ff ff ff ff ff ff |................| 00000060 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| |
|
Strange, when connected to a generic enclosure, I can't find a single SInE block. Scanned the entire drive. |
|
Then your keyblock is probably on the EEPROM. In a generic enclosure, the drive should behave as if unpartitioned and unformatted. If you look at the first few sectors, you should see gibberish. The last few sectors should have mostly zeroes. |
|
Yes, it does not show the partitions when in a generic enclosure. I suppose my next step will be to explore ways to read the KEK from the EEPROM... |
|
Look here: themaddoctor/linux-mybook-tools#89 |
|
Thank you. His very first post is interesting, since I have the exact same 2TB green drive. I'm thinking maybe if I initialize the entire drive, I can grab the blobs from the exact same locations as he posted. (I have a dd backup of the partition that has all my files). |
|
This may be a stupid question, but are the KEKs all the same (when the WD model and drive are the same?)... I mean, will me KEK be exactly the same as his? have you seen this happen on other drives or are they all unique? |
|
If you did not set a password, then the KEK is always the same. |
|
Sorry, I meant to say DEK.... As I understand it, I can generate the KEK like this: Password to KEK = (salt+Password) => (sha256 x 1000) Salt = "WDC" Algorithm 1 KEK generation from password ”abc123”: Counter = 0 |
|
DEK stays the same. |
|
So let's say, if I put a brand new, completely zeroed out hard drive in the WD enclosure and format it, the WD Utilities software will extract the DEK from the EEPROM and place it on the last blocks of the file? |
|
It depends. Some put the encrypted DEK on the last few sectors of the hard drive, and some do not. Most with the PLX chip do not. If it does, it is stored where you cannot see it until you remove the disk and put it into a generic enclosure. From what you have said earlier, your disk does not store the DEK on the disk, only in the EEPROM. I do not know how to extract anything from the EEPROM, but the guy at the END of the thread I pointed you to knows how to do it. He did not tell me how. |
|
Yeah, I read the thread, he said it was a custom tool but didn't want to disclose it here.... I'll have to look elsewhere, surely someone out there knows how to do it. |
|
My question earlier, related to if the DEK is always the same, was about the original one (as it is in the EEPROM). Did all the chips come with the same one: Meaning, if I can get someone else with the same model as me to extract their DEK, would it work do decrypt my drive? |
|
Absolutely not. |
|
Thanks for the answer. I sure hope you're right. Ironically, one of the things I had on the hard drive was precisely the original WD Utilities. This is truly a strange issue, since a handful of files were still good (very few) and all the others were (are) corrupt. What is strange though is that one day the drive was fine, the next it wasn't, and there was no change in system or WD Utilities or even adding/removing apps or updates in between, just a power failure. I will experiment with installing an older version of Mac OS on an external drive and booting from there to see if it makes any difference. |
|
The drive was originally bought when I had a 2010 iMac (running Mavericks), then eventually used on a macbook Air (also 2010), and then on my current machine which is a Retina 5k late 2015 iMac, running Catalina. It worked without issues for almost 11 years. |
|
HFS+ |
|
Thanks. I just registered at macrumours, found your username, but ca't send pm for some reason... Only options I get are to 'ignore' or 'unfollow' (the button 'start a conversation' is missing) versions of WD Utilities I have are: |
I have a WD Duo with two 2TB drives that I configured as RAID 1, naively believing that if something happened to one of the drives that I would be able to recover my data. Well, the device died and I have two mirrored drives that I can't access. I found your tool and found that I have the PLX controller. Would you be able to assist with a decryptor? I ran the dumpkeysector option and saved it to a file. I also ran the dumplast option and have that output saved to a file. Both are included in the attached zip file.
What other information would you need to develop something?
sda.zip
The text was updated successfully, but these errors were encountered: