Decrypting JMS561 (My Book Duo), old thread title - Please update PDF with offsets for 5TB, and 6TB drives

[apassiou]

I am using WD Red 5TB and 6TB drives in my enclosures. need offset to get the key off of them. PDF gives offset up to 4TB.

[themaddoctor]

You'll have to tell us what they are. Use the script in appendix E to find it, if it is one of the four that we recognize. Thanks.

[themaddoctor]

There is a pattern in the keyblock locations. If you tell me the chip number on the USB-SATA board, I can give you a good guess.

[apassiou]

So I find it confusing in documentation for this project. There is a list of supported USB-Sata board chip vendors. Are these in reference of the chip of the WD Enclosure that the drives were in, or is it in reference to a USB-Sata board that we are plugging into in order to hook the drive to our PC and decrypt the drive?

All of my enclosures are fully functioning right now, but I am hesitant in putting irreplaceable data on them unless I know I can decrypt them in case the enclosure goes south. If I decrypt the drives right now and save the key, then re-create RAID 1... will those keys still be viable? Will they make the process easier in the future?

Is there anyway to disable the encryption? Or change it to match something dumb to make it easier to get the data off in case of failure in the future? I know the aim of the project is to recover data, but would be a nice addition to disable encryption (im guessing not possible?) before putting data on the units.

[themaddoctor]

If the drive is encrypted, then you are stuck with it, unless you modify the USB-SATA board or put the drive in a new non-WD enclosure. The reason for this is that if the user changes the password, the disk does not need to be reencrypted; the key simply needs to be rewrapped in the new password. Reencrypting takes much to long.

Once the disk keys are known, they do not change (unless you change the USB-SATA board).

There are only four chips that I can help you with. The chips are found on the USB-SATA card that is inside the WD MyBook enclosure. You literally have to remove the drives from the enclosure to access the encryption information (if any) on them. If you are going to do that, then just tell us which chips you have.

[apassiou]

Where/Which chip on the board are the ones in question? Can this data be pulled off the hard drives? Because in these dual bay units its not easy to access the PCB of the enclosure (it doesnt come out with the drives), would need complete disassembly of the enclosure.

[themaddoctor]

I strongly believe that the dual drives are not encrypted.

If you have the drive removed, and connect it to a linux PC with a non-WD enclosure or with an SATA port, then dump the first 2MB and the last 2MB. From those, I can tell if it is encrypted and if I can recognize which chip is used. The linux commands are

sudo dd if=/dev/sdX count=4096 of=first2mb.bin sudo dd if=/dev/sdX skip=XXXXXXXX of=last2mb.bin

Change "sdX" to match your drive. Changed "XXXXXXXX" to a number that will dump about 2mb. That number is the number of 512-byte blocks to skip before starting to read the disk, so you can calculate approximately what it should be by calling "fdisk -l" to get the total number of blocks.

[apassiou]

Ok, I will dump this data on the three different units I have (EX2, EX2100, and the Duo). Whats the best way to get the dump to you? Also does it matter which USB controller/board I use to connect to the PC?

[themaddoctor]

Upload here as zip files.

2. Probably not, so long as it is not in the WD enclosure.

[themaddoctor]

EX2 and EX2100 are definitely not encrypted. I can even read the names of some files. Like "Andrei iPhone ...". You should be able to mount the other partitions in linux. Try "fdisk -l /dev/sdb" to see their sizes and locations. Then try "sudo mkdir /mnt/wd ; sudo mount -t ntfs-3g /dev/sdbX /mnt/wd" where X is the number of the partition you want to look in.

To my surprise, the Duo does look encrypted. I should have remembered that I read about such drives a couple years ago. The first 2MB look very much like an encrypted partition table (and nothing much else). The last 2MB contain nothing but zeroes. For that drive, I think the next reasonable step is to try to get at the board inside. Since I did not see a keyblock in the last 2MB, I am curious to know which chip it uses. Maybe if it is too hard to remove, you can still look at it with a flashlight and a small mirror. If it is not one of the four that I know about, and if we can't find the keyblock, then the Duo is most likely only readable in the original enclosure. (You can always get a different enclosure and reformat, thereby removing everything including the encryption.)

[themaddoctor]

[to unmount, it's "sudo umount /dev/wd"]

[apassiou]

I dissasembled the Duo, looks like JMicron JMS561

Pic- https://imgur.com/a/5JWQ3Fu

Ill attempt mounting EX2 and EX2100 after I re-assemble this thing.... so it being JM, reallymine should be able to decrypt it?

[apassiou]

Success!!!! mounting EX2100, but its ex4 not ntfs. This is a networked "my cloud" unit, so it does internal filesystem, which is ext4. So command

sudo mount -t ext4 /dev/sdb2 /mnt/wd

And I can access data on it... going to try EX2 now....

Success!!!!. same command for EX2 drive.

This is great!... this means these are fully recoverable if the enclosure dies, you just have to use linux to do it, with a Live Disk and like 5 commands anyone can do it. (For the record I am using Ubuntu 16.04 LTS on a laptop, the drives are attached via a non WD USB3.0 single drive enclosure that uses JMicron JMS567 Chipset (brand name is Vantec NexStar TX - https://imgur.com/a/hszIzPr).

Now, Id like to figure out how to recover from the Duo in case it's enclosure dies.

By the way, thanks for all your guidance 👍

[themaddoctor]

We looked at a JMS561 before, with no luck. Here is the thread: https://github.com/andlabs/reallymine/issues/15

[themaddoctor]

These guys say that they took drives from one enclosure to another (same model), and could read the encrypted disks: https://forum.hddguru.com/viewtopic.php?f=1&t=36609&sid=60a9716472dc090216aa017ae2e4c99f&start=20

That would mean that the keys are hidden on the disks themselves somewhere. In the past, I looked at two of the service modules (stuff on WD disks that is written outside the user's data area), and did not find anything that looked like a keyblock. If you are willing to try to dump ALL of the service modules for me to look at, I am willing to look through them. The tool to use is here: http://www.sdcomputingservice.com/hddsupertool/download

It could be that the keys are kept on a RAM or ROM chip on the disk controller board. In that case, finding them would involve more destructive means.

[apassiou]

Yeah I know that using the same enclosure would potentially give access to the data; however, these things are not produced anymore, and I cant imagine it would be easy to get one lets say 10 or 20 years from now. So thats kind of not an option, and I am unwilling to buy another one right now as it would be an investment into a crap design (due to HW encryption).

Would dumping the entire disk (the same way I dumped first/last 2mb) be helpful? I can pop in a 1 TB drive (dont think I have any smaller), and then compress it, disk would be empty (I can do a full zero wipe), which hopefully means rar or 7z would compress it down pretty good.

I will dump all of service modules tonight.

As far as RAM/ROM, I am willing to solder on some things onto the board if needed. I mean, if we crack this thing I think we would help a lot of people?

PS - I looked up documentation on JMS561 and see no mention of encryption capabilities anywhere. Whats also interesting is that the enclosure I am using uses JMicron JMS567 Chipset (Vantec NexStar TX pic- https://imgur.com/a/hszIzPr)

[themaddoctor]

Dumping the entire disk doesn't help. Maybe the last 50 MB, to look for the keyblock, or the partitions that are not used for user data. Lemme see your partition table ("fdisk -l /dev/sdb") to see where things are.

The JMS567 might block you from seeing the service area modules. I read that it doesn't handle SMART passthrough correctly. We'll see.

Cracking this thing would help at most 2 people each year. I base that number on how many people have asked about it before. It has been so long that I had even forgotten that Duos were encrypted.

[apassiou]

Alright, Ill proceed with the service modules dump, if JMS567 gives me problems Ill do a direct attach SATA to my main PC (currently using a laptop with Ubuntu 16.04 LTS on it for all this). Ill do it when I get home tonight.

[apassiou]

Can confirm that the external enclosure was not passing through SMART data. I ended up hooking up via SATA directly to a mobo (x570 AMD chipset).

Here is fdisk you asked for:

~$ sudo fdisk -l /dev/sdb Disk /dev/sdb: 4.6 TiB, 5000981078016 bytes, 9767541168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes

I first tried the 5TB WD Black drive, but hddsupertool would not dump the modules on it, heres the log: wd_5tb_black_log.txt

I then decided to try a smaller 1TB green drive, and was able to dump the modules successfully.

log: wd_1tb_green_log.txt

And here are the modules from the Green 1TB drive. The drive was configured in RAID1 with another 1TB green drive, and the raid only has 1 file on it (empty text file I created).

Modules: 1TB_WD_Green_MyBookDuo_Raid1_modules_dump_hddSuperTool.zip

[themaddoctor]

Some people on the net believe that the key is in this stuff (module38):

0001e400  49 56 50 30 00 00 00 6c  fb be 18 a3 00 20 00 00  |IVP0...l..... ..|
0001e410  04 ca 36 e7 c8 93 ce 46  5f 07 64 c1 44 31 d2 d9  |..6....F_.d.D1..|
0001e420  c7 87 b7 3e 9c 11 98 f3  63 71 e1 6a 70 fb 4c 34  |...>....cq.jp.L4|
0001e430  7b 82 c8 5e 5b 50 fc 0b  2f 13 3a c7 04 90 1d 92  |{..^[P../.:.....|
0001e440  b4 44 19 9e c1 aa 8a cb  29 d1 38 ce 84 7c ed 2f  |.D......).8..|./|
0001e450  3a a0 99 ff 73 90 5a 52  6f a1 d3 1a 91 c4 0a 54  |:...s.ZRo......T|
0001e460  6a 09 43 75 39 1d 1b ad  d2 c0 df 54 a5 e1 59 66  |j.Cu9......T..Yf|
0001e470  00 00 00 00 74 6f 78 00  00 00 00 00 00 00 00 00  |....tox.........|

To tinker with it, I will need a dump of the first few sectors of the 1TB device. That way, I can see if I ever find the right key by decrypting the MBR.

[apassiou]

attached are the first 60Mb. File is a .7z, I couldnt upload .zip because zip doesnt compress it at all (and github's limit is 10mb), while 7zip compressed it down to 1.7Mb. So change extension to .7z

first50mb_mybookduo_raid1_1tb_green.zip

[themaddoctor]

OK, but I only needed one or two sectors.

I will play around with it later today. I can't promise success. And even if I do succeed, we don't know if you can get the 5 or 6TB drives to work.

What I can say now, comparing the 1TB and the other drive, is that the encryption style looks the same (ECB mode), and the keys are different.

[themaddoctor]

Is the other drive that use use in the Duo the 5TB black one you mentioned above? Just want to know so that I can label the samples and keep everything sorted.

[apassiou]

Sorry I thought dumping more rather than less would be better, I had just a few minutes before leaving for work, so just did a quick ~60Mb dump (you mentioned that first 50Mb would be useful, I thought rather give a bit extra)... but based on how the compression went, I am guessing most of the 60Mb are zeroed out?

If by the other 5TB drive you mean the one that I couldnt read the modules from, then yes, 5TB WD Black, the log I attached previously has the model number in it.

My original drives (6TB ones, are WD Red). My plan is to, if we can figure this out, actually try decrypting the 6TB Red drives with the procedure we come up with (hopefully), to test it.

You should mention module number in https://github.com/andlabs/reallymine/issues/96#issuecomment-535506709 for posterity sake.

I have the following drives that can be tried, Black (4TB), Red (2TB, 4TB, 6TB), Purple (6TB), Green (1TB, 2TB, 3TB), Light Blue Enterprise (not Blue) (4TB, 6TB).

EDIT: Keys being different would mean that the key is seeded every time drives are formatted? Meaning the key has to be dumped for every new drive. Did you have to do that for the other chips that reallymine works for?

[themaddoctor]

So, in talking to a lot of users, it appears that any time someone puts in a new drive, the chip fails to find a keyblock, and creates a new one. There was even one case where someone put a drive in an enclosure with the wrong chip, and a second keyblock was created. Old drives that already have keyblocks keep them.

The WD software has an option to do a "quick erase". That wipes the key and creates a new one; it doesn't actually erase the drive. If you use your OS to reformat, the key stays the same. After all, the key is on the hardware.

You will have to keep track of the key for each drive that you put into the Duo. If you want to assign numbers to them, and tell me the numbers, then I will use the same designations. So far I've been calling them "1TB" and "5TB".

When you put two drives in the Duo, I don't know if the two drives share a key or not. I vaguely remember seeing a pair that had the same encryption.

[apassiou]

I would guess they share the key as you can switch the drives places and the enclosure does not mind.

[themaddoctor]

In module 38 (1TB), there is a block called "WDv2". That made me think we are on the right track. But that block is mostly zeroes. Much later in that modules is the IVP0 block. I tried decrypting that block with the standard key, and using the results to decrypt the MBR, but nothing sensible came out. With the JMS538S chip, the disk key would be clearly marked with DEK1 after the keyblock is decrypted. I could not find such a thing.

Can you take the disk(s) that originally came with the Duo, put them in a new enclosure that does not use JMicron chips (maybe ASMedia instead), and get module 38? I need something to compare this to.

[apassiou]

Hmm, I have no idea which drives came with it originally, Ive had it for 5 years or so. I believe it was Red drives and either 2TB or 4TB. I have Red drives with those capacities, so I can try putting those in. But I do not think I have a non Jmicron enclosure, so I can do direct SATA connection, like I did with the 1TB Green. Would that work?

[themaddoctor]

It should.

[apassiou]

Ok, ill dump all modules, just so that they are available and also the first ~9mb of the drive (to fit within Github's 10mb limit), to have the data available just in case.

Is there anything else you want me to provide?

[themaddoctor]

Nope. But not 9mb. 1mb is enough.

[apassiou]

Ok I couldnt locate 4TB red drives, so instead I used 2TB Red and 4TB Se (enterprise), model numbers are: WDSe: Model= WDC WD4000F9YZ-76N20L1 (light blue label, not yellow) WDRed: Model= WDC WD20EFRX-68EUZN0

Full module dumps from both and first 1.5MB from each are below. Modules are over 10Mb as Zip, so had to use 7z again, rename extension to 7z for the module files. The dump file is actually a zip.

2TB_Red_Modules.zip 4TB_Se_Modules.zip first_megs_WDMyBookDuo_RAID1_WDRed2TB.zip first_megs_WDMyBookDuo_RAID1_WDSe4TB.zip

Side question, does reallymine decrypt Jmicron JMS562? Thats whats in My Book Pro https://imgur.com/a/zFvE26a. Not sure how long getdek should take... but been going over an hour on a 4TB drive.

[apassiou]

@themaddoctor you may know how to solve this. But the drives I used in the Duo, when I put them into the My Book Pro, I get the message that they are locked and its asking for a password. Which was never set... so there is no password... how do I "unlock" the drives? I tried reformatting in both Windows and Linux (fdisk and gparted), I tried dd writing first 2 megabytes with zeroes... yet still My Book Pro says the drives are locked... how do I get rid of that? How does it know that these drives are locked?

https://imgur.com/a/yTNBuNk

[themaddoctor]

I have no idea. Really. I read somewhere that some drives have a locking feature on their controller boards. Are these drives that you can read with a direct SATA connection?

[themaddoctor]

Are you sure about the 4TB modules? They contain a 2TB model number.

[apassiou]

The drives are totally usable on both Linux and Windows as if nothing is locked on them, I can format them to full capacity and use them as normal. There is something written somewhere that My Book looks for to tell if its locked... need to figure out how to wipe it. According to the manual 5 failed password attempts should give an option to erase the drive... this opetion does not show... I tried like 20+ failed attempts.

I guess next thing Im going to try is zero out the entire drive, not just start/end.

As far as 4TB modules, yeah to save time I put it in with a 2TB Red drive as a pair, so it got matched size wise with 2TB drive, since its raid 1 and drive capacities have to match. So not sure if you want to consider that as 2TB or 4TB drive. Even with this formatting it showed up as full 4TB in fdisk.

EDIT: Wow, finally fixed this problem... for posterity sake, here is how to fix it. All WD documentation states to use WD Securty and format the drive through there. The issue is that My Book Pro does not show up in WD Security (Ive tried at least 4 versions from the last 3 years of the app), many posts on official forums about this. So I had to dig out a MacBook and download MacOS version of WD Drive Discovery. Which saw the My Book Pro and allowed me to reformat to RAID1 (exFAT), after which I plugged it back into Windows, where WD Discovery Windows version allowed me to proceed and format as RAID1 NTFS (previously this is the app that was asking for password).

As a side note HDDERASE (dos version), which uses Drive's built in Secure Erase (took a bit over 12 hours for 6TB drive), it erases everything possible... still drives were password locked. I also tried writing zeroes to entire drive from first to last bit via Linux. Still was password protected. This leads me to believe that this info is not stored on user writable part of disc. I also tried to put the drives into a known non encrypting enclosure (EX2100), which formatted the drives just fine and was ready to use them for storage as if nothing happened. When I put those drives back into the My Book Pro it complained about password being out of sync and still did not let me proceed. The Mac version of Discovery app was the only way.

[Zibri]

@apassiou hi! I am interested in how you dumped the modules. It would be great (whatever tool you used) to have a SCSI dump of the commands issued.

[apassiou]

@Zibri, dumping process was outlined in one of the posts above - https://github.com/andlabs/reallymine/issues/96#issuecomment-534275504

[Zibri]

@Zibri, dumping process was outlined in one of the posts above - #96 (comment)

I am talking about modules, not the first and last part of the drive.

Oh.. now I see it.. you used hddsupertool...

[Zibri]

@apassiou P.s. check this out please: https://github.com/andlabs/reallymine/issues/138