0

Here's the specific issue in short topics I think might be relevant:

  1. I have a Western Digital (my book Studio) external drive. (the old version, bought somewhere around 2009 that has both USB and FIREWIRE ports)

  2. In that drive I had a load of important backups.

  3. The drive was encrypted.

  4. Somehow things went wrong during an unplugging of the drive and I lost access.

  5. the drive is still good, no bad sectors.

  6. I managed to recover the files with various tools and even have a complete image of it made with dd command.

  7. The issue is that the recovered files are still encrypted.

  8. From the investigation I've done, I've managed to figure out that these WD drives use a hard-coded encryption key that is stored in the last sectors of the drive, and the password I chose when encrypting is just used to create a sha256 hash that in turn is used to access the actual decryption key.

  9. From this (very good) writeup about these drives: https://eprint.iacr.org/2015/1002.pdf I have figured out that for my specific chipset, the encryption key starts with 'SInE' somewhere in the last blocks of the hard drive.

  10. My question is how can I read the hard drives blocks in order to grab the complete key? Can dd do this? It's a 2 Tera byte drive, has no bad sectors. According to the writeup posted above, the WD hardware blocks access to thee sectors, but if I take the drive out of the WD case and plug it in directly to a SATA port, I should be able to access them.

  11. Things I have tried: because I already have a disk image of the drive for 'safety', I tried recovering the files directly from the drive, but the recovery software, while performing deep scans, also searches for older (deleted) files and seems to recover less stuff. So I wrote zeros to the entire drive using dd (to make sure there would be no recoverable 'deleted' files), then I put the drive back into the original Western Digital case and formatted again, and created the same encrypted drive (with the same password) as I had originally, then used dd to 'restore' the image I had made... Then I ran a mac diskutil first aid (these were all mac files and the original format was HFS+). My hope was that the drive would somehow recognise that the files within were still encrypted. Didn't work.

I have the recovered files on a separate disk, but can't find any software that can decode/repair them. If I try to decode manually, it always tells me the decryption key is wrong. This is because of what I said previously: My password is not the actual key, it's just used to access the hard-coded key on the drive.

DD is terribly slow for 'experimenting' with a 2 Terabyte drive, any test I want to try takes over 32 hours, so I need a way to 'skip' to the last sectors of the drive, except I don't know how many sectors there are or what number I should skip to, or even if DD is the right tool for reading the raw ascii blocks I need.

Any help appreciated, I've been at this for almost 20 days now.

Thank you very much.

P.S. I have both Linux (Ubuntu 20.04) and Mac computers, so I'm looking for a non-windows solution. thanks

2 Answers 2

1

tail -c 512000 /dev/sdX will read the last 512000 bytes of the drive and write them to stdout.

Pipe to perl -0777 -ne 'print $& if /SInE.*/s' to extract the part starting with the first occurrence of SInE in there.

Or get perl to seek to the end by itself:

perl -e '
  seek STDIN, -512000, 2 or die "seek: $!";
  $/ = undef;
  $_ = <STDIN>;
  print $& if /SInE.*/s' < /dev/sdX
3
  • Thanks for the answer. I'm trying the first option (tail) as we speak, but it's taking an awful lot of time, as if it's reading the whole drive trying to find the end.... Is this normal? Been running for almost 30 minutes now. I would have imagined it would be 'smart enough' to start from the end and count backwards.
    – ProtonSnow
    Commented Dec 2, 2022 at 13:21
  • Is that on Ubuntu? On Debian, sudo strace -e lseek tail -c 512000 /dev/sda > /dev/null is instantaneous and shows lseek(3, -512000, SEEK_END) being called. Commented Dec 2, 2022 at 13:24
  • no, I'm currently trying on the mac, but thanks, if this doesn't work, I'll try in Ubuntu.
    – ProtonSnow
    Commented Dec 2, 2022 at 13:26
0

Sure, dd skip={Number of 1kB input blocks to skip} bs=1024 if=yourdiskimage of=imageofendofdrive skips forward by the specified amount of kilobytes in the input.

But: your drive image isn't encrypted at all. You're trying to solve something that's not in need of a solution!

As you say yourself:

Things I have tried: because I already have a disk image of the drive for 'safety', I tried recovering the files directly from the drive, but the recovery software, while performing deep scans, also searches for older (deleted) files and seems to recover less stuff. So I wrote zeros to the entire drive using dd (to make sure there would be no recoverable 'deleted' files), then I put the drive back into the original Western Digital case and formatted again, and created the same encrypted drive (with the same password) as I had originally, then used dd to 'restore' the image I had made... Then I ran a mac diskutil first aid (these were all mac files and the original format was HFS+). My hope was that the drive would somehow recognise that the files within were still encrypted. Didn't work.

The data pertaining existence of files is not encrypted at all, otherwise your recovery software couldn't find any files. The drive doesn't "understand" the file system you're using - it works directly on the bytes you write to disk.

If you can recover files but their contents are actually encrypted, you must have had another layer of encryption on top of that. Something that sits in your filesystem driver layer and encrypts the individual files, not the whole disk.

17
  • Thanks for the answer. I'm quite sure it's encrypted, it decrypts automatically when I connect to my mac (from where I ran the recovery software) password is stored in my keychain. About 20% of them were good, 80% didn't decrypt. I assume this happened during the unplugging where everything went wrong... In any case, I've exhausted all options to decrypt the files (some are text files, so easy to see they're encrypted) except trying the hard-coded key that's supposed to be on the drive, hence my question. But if you know another way I can get these files working again, I'd appreciate it.
    – ProtonSnow
    Commented Dec 2, 2022 at 12:42
  • the hardware contained inside the WD box decrypts on-the-fly when accessing the drive (through the USB bridge chip). So I assume any software that's trying to access/recover also goes through the same chip and the same process.
    – ProtonSnow
    Commented Dec 2, 2022 at 12:46
  • as said, the drive encrypts the whole data, not the contents of files. If you were able to recover 20%, that means what you've read was not encrypted. if 20% of files were recoverable, we can be 100% sure that they were not encrypted. Commented Dec 2, 2022 at 12:52
  • 1
    yes, you can repeat that. But it simply still does not apply to you; you have unencrypted filesystem data, which we both agree on, and (probably) encrypted file contents, so this cannot be full-disk encryption. There's really no reason for doubt! Commented Dec 2, 2022 at 14:15
  • 1
    100% guarantee there was no other layer of encryption, there never has been. Been using the same drive with the same password for over 12 years with no issues, and it's the only encrypted drive I have ever had, never encrypted anything else, that's why I'm baffled at this issue.... And this was a drive where I stored all my projects... Literally 20 years of logo designs, websites etc... I've been telling myself for over a year its time to get a new drive because this drive was getting old... None of the files are 'important' for my current work, but it breaks my heart to lose 20 years of work.
    – ProtonSnow
    Commented Dec 2, 2022 at 19:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .