Is the disk permanently decrypted?

reedickulus commented 7 years ago

Thank you for this guide. After a lot of trouble shooting from some of the steps, I was able to see the files on my hard drive in ubuntu. I am wondering, now that it is decrypted, can I plug it into a windows machine and access the files? I didn't want to try until I knew this wouldn't corrupt the MBR or cause other issues. Thanks.

reedickulus commented 7 years ago

Also, I was using an ubuntu Live CD. So after I restarted my system, the directory I made "wd" including dek.hex and rev16.ko are gone. Can I re-create this following the same steps in the original directions, or am I out of luck since the drive was already decrypted once?

themaddoctor commented 7 years ago

For the first one: No, definitely not. Backup your files while you are still in Ubuntu. The disk is still encrypted; you merely have a decryption filter running in Ubuntu.

For the second one: Yeah, you have to do it again. The drive is still encrypted.

Can you send me a copy of your keyblock and tell me the size of your drive (to help refine things)?

reedickulus commented 7 years ago

Thanks for the reply. I put everything back away as I don't have a spare HDD at the movement to move the files. When I get the new HDD and make another attempt I will send you the keyblock. It is a 3TB drive.

reedickulus commented 7 years ago

Also, this may be a point of clarification for your guide. I just wanted to put it here in case someone else is google searching and stumbles upon this and is stuck.

If you are trying to decrypt a drive with the JMS538S chip and get stuck on the part:

In order to extract the disk encryption key (DEK), we have to reverse each block of 16 bytes, decrypt
with AES in ECB mode, and then reverse each block again. These three commands will do it:
for i in `seq 0 31`; do
dd if=kb.bin bs=16 count=1 skip=$i status=none | \
xxd -p | grep -o .. | tac | echo "$(tr -d '\n')" | \
xxd -p -r >> kb1.bin
done
openssl enc -d -aes-256-ecb -K `cat kek1.hex` \
-nopad -in kb1.bin -out kb2.bin
for i in `seq 0 31`; do
dd if=kb2.bin bs=16 count=1 skip=$i status=none | \
xxd -p | grep -o .. | tac | echo "$(tr -d '\n')" | \
xxd -p -r >> kb3.bin
done

I couldn't clearly see what the three codes were. I tried putting in different parts in the terminal command, and nothing happened correctly.

Finally I used terminal and typed 'gedit.' This opened up a text browser. I copied the above code (DELETE THE BACKSLASHES AND PUT THEM ON THE SAME LINE) and name it "script.sh." I left this script in the wd folder. Then I used terminal command chmod +x script.sh

I then ran the script by typing ./script.sh while I was in the wd folder.

This worked for me for creating kb3.bin file.

ALSO, when it came time to build the new encryption module and reverse the order of each 16-byte block, there was code and instructions in Appendix D. It was a bit unclear based on the PDF and a help thread here (https://github.com/andlabs/reallymine/issues/47) on where to place the files, but I somehow got things working OK using this code:

/*
 * Cryptographic API.
 *
 * very simple cipher to reverse each block of 16 bytes
 *
 * Thomas Kaeding, 20160120
 *
 * ---------------------------------------------------------------------------
 */

#include <linux/module.h>
#include <linux/init.h>
#include <linux/types.h>
#include <linux/errno.h>
#include <linux/crypto.h>
#include <asm/byteorder.h>

int rev16_setkey(struct crypto_tfm *tfm, const u8 *in_key, unsigned int key_len)
{
        return 0;
}

/* Why must we use a temp array?
 * Without it, only the first 8 bytes are affected. Why?
 */
static void rev16_encrypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
{
        int i;
        u8 temp[16];
        for (i=0;i<16;i++)
                temp[i] = in[i];
        for (i=0;i<16;i++)
                out[i] = temp[15-i];
        return;
}

static struct crypto_alg rev16_alg = {
        .cra_name               =       "rev16",
        .cra_driver_name        =       "rev16",
        .cra_priority           =       100,
        .cra_flags              =       CRYPTO_ALG_TYPE_CIPHER,
        .cra_blocksize          =       16,
        .cra_ctxsize            =       0,
        .cra_alignmask          =       3,
        .cra_module             =       THIS_MODULE,
        .cra_u                  =       {
                .cipher = {
                        .cia_min_keysize        = 0,
                        .cia_max_keysize        = 32,
                        .cia_setkey             = rev16_setkey,
                        .cia_encrypt            = rev16_encrypt,
                        .cia_decrypt            = rev16_encrypt
                }
        }
};

static int __init rev16_init(void)
{
        return crypto_register_alg(&rev16_alg);
}

static void __exit rev16_fini(void)
{
        crypto_unregister_alg(&rev16_alg);
}

module_init(rev16_init);
module_exit(rev16_fini);

MODULE_DESCRIPTION("reverses the bytes of each 16-byte block");
MODULE_LICENSE("GPL");
MODULE_ALIAS("rev16");

I didn't quite understand the "makefile" command part, but I put the rev16.c file (made with gedit) in the wd folder and then followed the Make file and Build commands in the PDF. rev16.ko ended up in the /usr/src/**ubunt-or-linux-version/crypto

I had plugged my HDD into a windows system before attempting this rescue operation so I had to mount with a loop device.

Unlike the instructions I only got "data" as a response for the second command.

I felt like I got some error message about a Windows file system, but lo and behold, was able to access my files in /mnt/wd.

Hope this helps someone else out there who may be doing their Google research etc trying to fix this common problem that WD won't address.

Also I don't know how much more of a thank you can be given to Thomas Kaeding. He is clearly a brilliant mind and his selflessness and willingness is admirable and inspirational.

themaddoctor commented 7 years ago

Thanks for the praise. I deserve only the smallest part of it.

I don't think that the instructions need to be changed, because if you type them exactly as you see them, they work. Plus, I made scripts that extract the keys and you can download them from this github project.

The rev16.c you have is old, and includes some headers that aren't necessary. But it doesn't matter.

Can you send me the keyblock, and the manufacture date (printed on the disk label)? Like this:

hexdump -vC kb.bin

then post the output into a comment. Thanks.

themaddoctor commented 7 years ago

Still interested in a copy of your keyblock, please.

reedickulus commented 7 years ago

Will absolutely send it to you. Sorry for the delay, please give me just a bit more time. I ordered a new HDD on Cyber Monday and I am awaiting its arrival. Once it arrives I will do the file exchange (likely on a weekend or overnight when I don't need my laptop) and will grab the keyblock at that time. Should be fairly soon - thanks!