linux-mybook-tools
linux-mybook-tools copied to clipboard
themaddoctor
Recover My Book Duo (1st Gen) after resetting the RAID 1 configuration
I have a My Book Duo 16TB that was configured RAID 1 and contains about 6TB of data (mostly photographs). I bought another new My Book Duo 16TB and plugged it into my system (Windows 7). I used the WD Drive Utilities to set the RAID configuration of the new drive to RAID 1, but to my utter horror, I picked the wrong drive and reconfigured the older enclosure. Yes, I was utterly stupid for not disconnecting the old drive before I tried to configure the new one. The old drive is now showing as a RAW 8TB drive in my system. Since it was and still is a RAID 1 configuration, can I recover anything off of either of the drives in the enclosure using your method? I was not using password protection.
I don't know. It depend on a lot of things. To start, you should remove one of the disks from the enclosure and dump the first 2MB, so that I can see what's what.
DO NOT DO IT IN WINDOWS. It will only corrupt the MBR. Do it in linux or mac with the dd command.
Sadly, I hooked up disk 1 to my Windows machine and ran TestDisk on it. Luckily I have disk 2 that has been untouched. Should that work?
I am not a Linux person. I have worked in it in the past, but I need to brush up. Will I be fine using a Live CD version? Do you have a suggested version?
I will suggest ubuntu 16.04 live, but only because I have a copy of that one.
Use live, not emulated, because no one I know has gotten disk access to work with an emulator.
Just curios: Did testdisk find anything?
I will go ahead and install ubuntu 16.04 on a second hard drive in my spare computer. The first drive has a dual boot of Windows 7 and XP. I need some time to get up to speed on Linux again. I will try not to ask you noob questions if I am not up to speed. If you want to talk me through the procedures, I would be fine with that, but I bet you would rather have me a little up to speed.
With the drives in the enclosure, Testdisk only saw "MS reserved" and "MS data" partitions. I did not run a full analysis on them because as it was running I searched the internet and realized that the disks were encrypted. I also ran Photorec on the enclosure, but the files it recovered were unreadable junk. When I ran the single disk under Windows 7, Testdisk returned nothing also.
Here are the dumps from the two disks in the My Book Duo. I used Ubuntu 16.04. Here is the command I used.
sudo dd if=/dev/sdX count=4096 of=2mb_my_book_duo_disk_X.bin
Disk 1 was the one that was connected to my computer running Windows 7 at first. Disk 2 has only been hooked up to Ubuntu.
2mb_my_book_duo_disk_1.zip 2mb_my_book_duo_disk_2.zip
Both dumps were identical. Did you change "X" to the right things?
I see that they are encrypted, but I didn't see anything to show that there is a filesystem in the appropriate place.
The next thing you should do is follow the instructions in the PDF until you have the decryption filter set up. Then dump the first 2MB again through the filter, so we can see what it decrypts into.
Since it was a RAID 1, shouldn't they be identical. When I hooked up Disk 1 to the Windows 7 machine, I did no formatting. I only ran Testdisk and Photorec on the drive via a generic, non-encoding USB to SATA enclosure.
Now I am connecting the drives one at a time via the Ubuntu computer's interior SATA connections. I do a full shutdown swap when working with the drives. Just in case I might have made a mistake, I re-made the files for you.
2mb_my_book_duo_disk_1_again.zip 2mb_my_book_duo_disk_2_again.zip
Are they still exact matches?
I will now plow into your PDF. I have a lot to learn, but hopefully I will be able to get back to you in a few days. Thanks for the help. If this doesn't work, I will have lost a lot of great photography.
Sorry I forgot to add...yes, I changed the X correctly when running the script. They were always the 5th drive, sde. I used "ls" under /dev to make sure it was the correct drive designation. They were the only drives not showing a partition.
I tried to find the keyblock on both of the disks using the instructions for the four types of chips. JMicron JMS538S, Symwave SW6316, Initio INIC-1607E and PLX OXUF943SE. Since my disks are 8TB, I had to extrapolate what might be the right number for the end of the disk. Since the difference between 2TB and 3TB (also 3TB and 4TB) was always 1953503232, I multiplied this by 4 and added it to the 4TB number of each chip. Running the command with the new number for each chip on both drives always returned:
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000200
Next I followed the instructions in Appendix E. I copied your text into gedit and saved the file as "kb_bash.sh". I then ran:
sudo chmod +x ./kb_bash.sh sudo ./kb_bash.sh /dev/sde
This always returned: keyblock not found
I guess I need to open the enclosure so I can see the chip. This might prove a little difficult because I can't seem to find out how to get into it. I will give it a try though.
Any ideas while I am trying this?
I would probably have to damage the box if I wanted to get to the board. Instead, I used a dental mirror to take photos of the chips on the board inside. I am enclosing them for you.
I don't know how the JMS or AMS chip does encryption. The WD site says that if you buy a new enclosure, and put your disks in it, then you should be able to access your data. This means that the information needed to do so must be stored on the disk(s).
Can you dump the LAST 4MB of one of the drives? Do that by adding a "skip=..." to the dd command, where .... is the number of 512-byte sectors to skip. You have to play with the number until you get something small enough (but not smaller than 4MB).
If the information isn't there, then the next step is to dump the service-area modules with hddsupertool.
Sorry, but could you give me a command example for finding the 4MB? I will take the time to run it over and over until I narrow down the correct "skip=" value. Thanks.
Found the end of data on both drives. They look to be identical. The last entry was at sector 15628018553 of 15628053168 total on both.
Last_4MB_Disk_1.zip Last_4MB_Disk_2.zip
You should do the smart thing and put one of these disks on a shelf and not touch it again until you get your photos back.
I didn't recognize any encryption info in the dump. So you could try hddsupertool. You can find it on google. It runs in linux. You want to use options like VSC and dump all the modules.
I don't know much about the JMS561 chip, so this may all turn out to be a waste of time. Just want you to be prepared.
WD says that if you buy a new enclosure, then you can recover. So if this doesn't work, you still have that.
I am fully prepared for this to not work out. I will figure out what you want from hddsupertool and get back to you.
As I mentioned originally, my enclosure is working fine. It was running in RAID 1 with no problem. I thought I was setting up a new enclosure for RAID 1, but accidentally re-set the original enclosure to RAID 1. This dropped the formatting of the RAID and set it to RAW. My last step will be to put the drives back in the enclosure and reformat. If I do this, will there be an older copy of my file list? I don't know. That is why I am trying to do this outside of the enclosure first before any more corruption occurs.
This is the log from running hddsupertool, Did I do it right?
I'll dig deeper. If you are not interested in continuing this with me, I am fine with that. It seems we have gone past your area of interest. If you want to continue, I am still up for it.
I would be interested in knowing how to decrypt it, but unless we find the keyblock, there isn't much I can do.
There is a trick that exploits a weakness in the key generation at the factory. It works for the JMS538S, so maybe it will work for your JMS561. To do it, I need the date of manufacture printed on the label of the HDs. Without the keyblock, this is the only thing I can try. So... what is that date?
Both drives are dated "DATE: 19 OCT 2016". I have enclosed detailed photos of both if that will help you.
No luck. I ran it until the end of November and go no hits.
The only thing I can suggest at this point is to keep trying to get hddsupertool to work. The information we need might be in the SA modules.
This seems to contradict WD's advice that a new enclosure will recover: http://forum.acelaboratory.com/viewtopic.php?t=8848
But your enclosure still works. So can you dump the first 5mb of it/them through the enclosure? Let's see if it decrypts, and what it shows.
Any hints on running hddsupertool? It seemed pretty straight forward in the menus. Enclosed is a copy of my terminal commands. Where would the modules be copied in Ubuntu?
You want me to put both drives back into the enclosure, connect via USB to the Ubuntu machine and then dump the first 5mb?
Here is the first 5mb of the RAID as seen from the My Book Duo connected to Ubuntu. It shows as sdb with an sdb1 partition, but it is not formatted.