WD encryption board failed, help really needed

[Meine1]

After researching a lot, seems like I'm yet another victim of shoddy WD encryption boards failing and obliterating my important family photos and videos. I'm literally crying, this was supposed to be the backup drive! If I knew that stupid HDD had hardware encryption I would have never bought it. Reallymine is my last hope to recover that data.
I have Ubuntu and the latest version of reallymine ready, can someone walk me step by step how to rescue my data? I have the 2TB WD drive and a spare 4TB Hitachi HDD to rescue all the data in the former.

But what exactly what do I need to type in the terminal?
I don't know anything about coding and despite reading all the guides I just can't wrap my brain around how is this supposed to work, it's all so confusing and frustrating, I've already tried for several hours but the instructions are not clear and I keep getting all sorts of errors, I don't even known where to start once Ubuntu is running and the terminal open. Please someone help...

[themaddoctor]

Which guides? linux-mybook-tools?

[andlabs]

You'll need to open a command prompt in Linux; this is usually called a "terminal" for historical reasons.

First you will need to figure out how Linux presents the drives. On Linux, all devices inside the computer and connected to the computer are presented in the folder /dev. What you will need to do is figure out which of these files corresponds to your encrypted drive.

Typically, these files have a filename of the form /dev/sdX, where X is a lowercase letter starting with a. For example, by convention, /dev/sda is your internal hard drive. For each of these, there will also be at least one version of the same file iwth a number at the end; each of these map to the partitions of the drive. So /dev/sda0 is the first partition of /dev/sda. Your encrypted drive is not going to have a partition table that Linux can read, so you won't see any of those for that.

If you have both your internal hard drive and your Hitachi drive mounted on Linux (such that you can view them in the graphical file browser you're using), you can use the command

sudo mount

to get a list of what partition maps to what folder. Also be sure to note which folder the Hitachi drive is mounted on; if Linux doesn't give it an obvious name, you can use

ls -a -F "folder"

to see what files are already there.

You can use this information to figure out which /dev/sdX files can be (or equivalently, are definitely NOT) your encrypted drive. To verify that your drive truly is on /dev/sdX, run the command

sudo blockdev --getsize64 /dev/sdX

This will print the number of bytes; divide repeatedly by 1024 to get kilobytes, megabytes, gigabytes, terabytes, etc. The number you get won't be precise for a variety of reasons, but it will be close enough that you should be able to tell what the size on the sticker on the drive itself says.

Once you have both the /dev/sdX file of your encrypted drive and the folder where your Hitachi drive is mounted,, you're ready to go. Use

cd "folder"

to go to your Hitachi drive in the terminal. Now put the reallymine executable here in the graphical file manager you are using as well. Type

chmod +x reallymine

to be able to run reallymine, and then you can finally get to work.

First, find out if reallymine can even decrypt your drive as it stands. run

sudo ./reallymine getdek /dev/sdX

You should, after a brief amount of time, see information about your drive's encryption. If you do, you can decrypt:

sudo ./reallymine decrypt /dev/sdX sdX.img

This will take a while, depending on which binary you use (the one in Releases is slow but works; the one in #38 is faster but needs more testing). At present, reallymine doesn't print any progress reports; sorry. If you want an estimate of the process, open another terminal (or a new window or tab if the terminal program you're using supports that), make sure it's in the Hitachi folder, and type

du -s -h sdX.img

to see how big the output file is so far.

Hope all this helps, and good luck!

[athomic1]

BIG question, first: have you removed the drive from the case yet?

If in fact it's a board failure, as opposed to the drive itself, you're going to need to get the drive out of the case, and connect it directly to the computer. There's a few ways to do that, but you'll likely need either SATA cables, or a suitable external enclosure. I don't have time at the moment to explain the different options, but you should be able to find instructions through a web search, if someone else doesn't step up here.

BIG recommendation, here: Do NOT do ANYTHING with ReallyMine until you've extracted a full image of the drive in its current state. There's a couple of steps involved here, too, and again, I don't have time to dive into details right now. Until you've got the drive out and onto another connection, there's not much you can do yet, but here's what I can give you for future reference:

Let's assume your drive is detected on /dev/sdb. Since you've got a 4TB drive on hand, you can make a 2TB image easily. The customary tool is dd, which you'd invoke something like this:

dd if=/dev/sdb of=/path/to/4tb/image.img

dd supports quite a few other options, which you can learn about either with 'man dd', or again, a web search. For the most part, though, you probably don't need to worry about them. There's also a simpler way to go about it that I've grown to prefer of late. Just use the cp (copy) command:

cp /dev/sdb /path/to/4tb/image.img

cp is clever enough to recognize the block device, and just start ripping its data from beginning to end. Either way, this gives you at least ONE backup to work with, should things go pear-shaped in process. As long as you've got a copy of the original image, you've got hope. I wound up sitting on a bunged-up drive for three years until someone figured out the decryption process, but it finally got back about 300 gigs of data. (That's all I had on there ;)

Note that you MUST have at least 2TB free on the 4TB drive for this to work, so if you've already been putting stuff there, you might want to see about moving some elsewhere, or getting Yet Another Drive to work with. Anyway, that's about as much as I can give you right now. I'll try and check back.

Best of luck!

[themaddoctor]

There is a variant called dd_rescue, which tells you how it's doing while the dump is being made. That way, you know how long it will take.

[andlabs]

Use GNU ddrescue (gddrescue), not dd_rescue. dd_rescue is super-old and doesn't have special optimizations or algorithms. I'm not even sure if it has pausing and continuing where you left off either...

[themaddoctor]

@andlabs Thank you. I've been using dd_rescue out of habit, even though gddrescue is also on my system. But now I know.

[Meine1]

@athomic1 Yes, I ruled out pretty much everything else, the HDD was never mishandled, doesn't makes any weird noises and it's still detected both in the BIOS and Ubuntu (unmounted). I did connect it directly via SATA then tried to check it in Windows, I hope that didn't corrupt anything...
Thanks for the tip about making a .img copy, I'll better do that first just in case.

@andlabs Thanks, just what I needed. I'll try your instructions after making a img copy of the disk and post if I run into any roadblocks. Also, is there a notification when reallymine finishes decrypting the drive or is checking the size of the decrypted .img the only way to know?

[themaddoctor]

Since you connected it to Windows, the MBR is likely corrupted. You could start the dd process at sector 2048, and end up with an image of the partition instead of the entire disk.

[Meine1]

@themaddoctor in that case, how do I confirm if the MBR has been corrupted?

[themaddoctor]

sudo dd if=/dev/sdX count=1 | file -
Where X is the appropriate letter for the WD drive.
If the result is "DOS/MBR boot sector" then Windows overwrote the encrypted MBR with a nonencrypted one.
If the result is "data" then you are probably not corrupted.

[andlabs]

reallymine will just exit when finished, so you're done when you see the command prompt come back. If you want a more explicit alert of sorts (for instance, some audio alarm), there are a number of ways to do so using other programs and the command-line shell in tandem. What Linux are you using and how are you running it?

[Meine1]

@athomic1 I tried the cp command as "~$ cp /dev/sda /media/ubuntu/4TB/hdd.img" to make the dump but it gives me this error: "cp: cannot open '/dev/sda' for reading: Permission denied"

@andlabs the healthy 4TB is mounted automatically, the encrypted 2TB isn't and it's only detected as "dev/sda" in the disks thingie. Should I mount the 2TB too? And if so how? I read somewhere else that the encrypted disk shouldn't be mounted but now I'm not even sure.

[Meine1]

@athomic1 Also, trying to dump the encrypted disk with dd gives me this error: "dd: failed to open '/dev/sda': Permission denied"

@themaddoctor Typing the "sudo dd if=/dev/sda count=1 | file -" command hives me this error:
"dd: error reading '/dev/sda': Input/output error
0+0 records in
0+0 records out
0 bytes copied, 0.000398643 s, 0.0 kB/s
/dev/stdin: empty"

[themaddoctor]

man sudo

[andlabs]

No, the 2TB disk shouldn't be mounted. How are you connecting the drive to the computer?

[Meine1]

@andlabs both drives are connected via SATA

@themaddoctor that gives me this error:

"man: dd-if=/dev/sda: No such file or directory
man: dd_if=/dev/sda: No such file or directory
man: if=/dev/sda-count=1: No such file or directory
man: if=/dev/sda_count=1: No such file or directory
man: if=/dev/sda: No such file or directory
No manual entry for if=/dev/sda
No manual entry for count=1
/dev/stdin: UTF-8 Unicode text"

[Meine1]

@andlabs Also, while checking if the drive can be decrypted, it gives me this error:
"sudo ./reallymine-concurrent-decryption-linux64 getdek /dev/sda
error running getdek: read /dev/sda: input/output error"

What am I doing wrong?

[Meine1]

Typing " sudo man cp /dev/sda /media/ubuntu/Volume/hdd.img" gives me this message:
"

NAME
       cp - copy files and directories

SYNOPSIS
       cp [OPTION]... [-T] SOURCE DEST
       cp [OPTION]... SOURCE... DIRECTORY
       cp [OPTION]... -t DIRECTORY SOURCE...

DESCRIPTION
       Copy SOURCE to DEST, or multiple SOURCE(s) to DIRECTORY.

       Mandatory  arguments  to  long  options are mandatory for short options
       too.

       -a, --archive
              same as -dR --preserve=all

       --attributes-only
              don't copy the file data, just the attributes

       --backup[=CONTROL]
 Manual page cp(1) line 1 (press h for help or q to quit)

What exactly do I need to type in that screen to copy an img of the encrypted drive (sda) into the backup one (Volume)?

[andlabs]

The man command opens a "manual page". You only pass the name of the command you want to see the manual page for, so you have to type

man dd

only.

As for the I/O error, I'm not sure...

[Meine1]

I'm using a live USB of Ubuntu, would that explain all the reading and permission denied errors or is it irrelevant?

[Meine1]

@athomic1 OK, I used dd if=/dev/sda of=/media/ubuntu/4tb/hdd.img conv=noerror,sync and it seems to be working. It still says "error reading /dev/sda input/output error" as it copies but the .img file now exists and it's increasing in size. How can I verify that the resulting .img file is a good clone of the encrypted drive and not an empty file with nothing but garbage corrupted data?

[themaddoctor]

If this is a PLX or JMicron drive, I would like a copy of the keyblock.
Otherwise, I'm out. I said "man sudo" and you/he typed "man dd-if=/dev/sda-count=1".
I can't communicate this way. Good luck, guys.

[Meine1]

I let the computer clone the encrypted drive for an entire day and it is not done yet, but when the .img is complete what do I type to make reallymine decrypt it?

[athomic1]

If you're getting input/output errors, that's not a good sign. Could be the drive itself failing, which is definitely not a good thing. If it's not at least half through by now... I'm not sure you should let the copy keep running, but I'd hate to tell you to cancel, either.

Okay, here's what I'm gonna say: If you're getting a whole screenful of "error reading" lines that keep repeating, you've GOT to stop the job NOW, if you haven't already. You've probably got a damaged drive, and keeping it working now is just going to make it worse. I'm not sure what to recommend going forward, but it's possible you might have to look into professional recovery services. I wish I could say something more hopeful, but at the moment, I'm not sure what else there is to suggest. I'll try and check in again tomorrow, not that I can be much more help...

[Meine1]

@athomic1 Oh lord, every single line contains the "error reading" thing. And I allowed it to run for several hours so it says it has copied 950GB by now, should I let it finish to at least have the .img clone in case the drive dies for good or will it just be an useless defective copy?

[themaddoctor]

I'm just going to remind everyone that the *rescue varieties fill in unreadable parts with zeroes, so that the data that is recovered is in the proper place.

[Adriana-decora]

@Meine1, I understand your feelings as I faced a similar situation a couple of months ago and fortunatelly got valuable help from a patient and generous member of this community, to decrypt and recover ALL THE DATA from a WD My Book Essentials 3TB (encryption chip JMicron JMS538S) with another procedure - following the guide "Mounting encrypted WD disks in linux 0.2.pdf" using Ubuntu exclusively (not virtual machine)
Let me suggest you to take some time to read my case carefully (issue #47).
You may find an option. Unfortunatelly I don't have the knowledge to guide anyone else (only followed the indications that I've been given), just recommend you not to panic, don't proceed hurriedly or anxiously, as a bad step may be irreparable. Good luck!

[athomic1]

I'm nervous to tell you one way or the other, honestly, but if it were me, I would probably cancel the job and disconnect the drive, making sure it was safely dismounted first, if possible. It sounds like after more than a day, you still have just under half the image made, which would mean at least another twenty-four hours to finish, IF it finished at all. If the drive really is failing, it could simply stop working/responding at any moment, and there's really no way to know for sure if/when that's likely to happen.

If you do go ahead and cancel, it might still be possible to get some info, most importanltly the key sector, from the drive. What you would need to do in that case is try to read just a (relatively) small section, and for that you WILL need 'dd'. I can't take the time to fully explain the process right now, but if you check the documentation (enter 'man dd' at the command line), you may get some idea on your own. Specifically, you'll want to use the 'skip' option to jump to a particular block, 'count' to limit the number of blocks you retrieve, and 'bs=512' to indicate the block size, which is almost always 512 bytes. Also, pay close attention to the 'if' and 'of' parameters. You use them to specify input and output files, or devices, respectively. You can probably guess the consequences of getting those backwards.

In addition, I would recommend you run 'sudo fdisk -l /dev/sdX', and copy the results into a text file. There will be at least one (BIG!) number you'll want from that: the total number of blocks on your drive. WARNING: fdisk WILL mess up your drive if you use it wrong, so pay close attention to the options. That '-l' is a lowercase L, which means just list the drive layout information, including any partitions. Since your drive is encrypted, it should report no partitions, but still give you the number of available blocks. While you don't absolutely HAVE to have it, it can be handy to have for reference. If you're running your command line in a windowed environment, you should be able to select the output text with your mouse, then middle-click in a text editor to paste it. That's the way every Linux distro I've used does it, anyway.

If your key sector is on the drive, there are a few possible locations it might be found. The list is up here somewhere on the site, if you look around. Someone else might have to point it out. Your best bet is to check the numbers associated with your drive size. I'd recommend grabbing a block starting a few sectors below the target number, and spanning several past it.

I know this is a lot to throw at you, and I'm not doing a very good job of it. Just read this over, check the docs I recommended, and I'll try and check back in later. Here's hoping, eh?