2nd attempt - recovering Truecrypt hidden volume on external 3tb HDD

Hello! This is my second attempt at posting a request for assistance.

Details of the Drive

I dropped and damaged a 3 terabyte external USB non-system Seagate hard drive containing outer and hidden truecrypt volumes and want to recover as much of the data as possible.

The truecrypt volumes were formatted either as (i) an entire partition or (ii) as a drive. I believe they were formatted as a partition because when I connect the drive to my computer, Windows shows me both a physical 3tb drive and a 3tb raw partition. The partition normally comes up as a drive letter "I" and Windows then asks if I want to format it (this used to happen even before the drive was damaged).

All the key data is in the hidden volume and my only backups are (carelessly) 18 months old.

I suspect there is both (i) limited damage to the platter and (ii) some kind of damage to the external usb circuitry, because the drive crashes if you move the connecting usb cable even slightly.

Initial Data Recovery Attempt

(i) Truecrypt Backup Header: I have created back ups of both the outer and hidden volumes of the true crypt drive, and these are safely stored away.

(ii) Grab of the critical data: Initially I could mount the hidden volume and access files, but Windows kept crashing. So I switched to Linux Mint, mounted the hidden volume and copied as much data as I could from the key parts of the drive. I recovered about 150GB this way, but then the drive crashed and now I cannot mount the hidden volume in Linux any more (it gives me an error message about an "input/output error" and tells me to run fdisk/k on the drive using Windows, which I do not want to do in case it damages the drive further). However, I can still mount the hidden volume in Windows, but the PC hangs when I access files.

(iii) Image using GNU DDRescue: I am now in the process of imaging as much of the drive as possible using GNU DD Rescue in Linux Mint, copying onto a new blank 3tb drive. The command I am using is: sudo ddrescue /dev/sdd /media/mint/backuphdd/IMAGE/image.img /media/mint/2ndHDD/IMAGE/log (with SDD being the damaged drive, backuphdd being the backup drive and 2ndHDD being my computers built in hard drive)

I am imaging the drive (and not the partition) because I wanted to be sure I had all possibly relevant data although I am not sure this was the best choice. Once the backup is complete (which will take at least several days) I will attempt to restore the image. I will then learn how to use Winhex, and am hopeful that using a combination of winhex, the backup truecrypt header file, a lot of effort and learning on my part and with the help of this forum, that I will be able to recover my data.

So far the image file contains about 300GB of rescued data. The drive crashes from time to time (I think because the usb circuitry and the usb cable are dodgy) and so I have had to restart DD Rescue a few times, but I am hopeful I will be able to get much of the data back. Currently the transfer rate from the damaged drive to the image is 18 megabytes / second, and the error rate is pretty low (although there are a few hundred errors, so some data will be lost).

My Questions

At this stage I have only really two questions:

(i) Am I going about this recovery process the right way or is there a better/quicker way?

(ii) Will I be able to rescue my data from the hidden truecrypt volume using the recovered DD Rescue Image file, and if so how? Using Winhex?

Thanks!!

 

Another new question; I paused and resumed ddrescue using the --try-again command, but the number of errors reduced by about 20. Should I be concerned?

 

It sounds like you definitely have an encrypted partition, not a fully-encrypted disk. An unmounted fully-encrypted disk would not display (or contain) any partitions, nor would Windows offer to format it. (It would want to initialize it).

My advice is, carry on! Your drive sounds very touchy at the moment, so try to get a complete image before things get any worse.

Another approach would be to remove the drive from its USB enclosure and plug it directly into a SATA port. Maybe you should try that if you can't get a good image using the current setup. (Of course, check first to make sure that the external drive can be removed from its enclosure and that the drive itself has standard SATA and power connectors.)

In your case I would have tried to image the partition rather than the entire disk. The reason for this is that I think the resulting image file would have been directly mountable by TrueCrypt. Since you are imaging the entire disk, you will need to either restore the image to another disk, or mount the image in some other manner before TrueCrypt will be able to access the partition-hosted volume.

After you have restored the entire image to a blank disk, Windows should be able to see the partition and TrueCrypt should be able to mount it. If not then post back and we'll try to figure it out, but from what you've described so far, it probably won't be necessary to use WinHex.

I have helped many users recover their encrypted partitions by using WinHex to copy the entire partition onto another disk, saving it as a file which is then directly mountable by TrueCrypt. The resulting file is basically just an image file. DD can also create the file, but I haven't dared to suggest this to most users, as they might somehow mix up the source with the target and end up overwriting their source (and then of course they would kill me). WinHex has a sensibly designed user interface, so it's much harder to confuse the source with the target.

Sorry I can't offer any advanced tips on using ddrescue, but I am not particularly skilled with that tool. I've played with it a few times and have gotten it to work, but that's about it.

 

Dantz - thank you very much for the detailed response which is hugely appreciated

I note your comment that I should have copied the partition rather than the drive. This is a shame but it sounds like the consequence of this poor choice is that I will just need to take the extra step of copying the image to a new drive which is OK by me. I was always planning to copy the image to a second drive anyway since then if I mess up the original image would still be available.

I am still copying the drive with ddrescue and have managed to save 1.7 TB of the 2.7TB so far. Annoyingly the drive keeps crashing once ever 1 to 5 hours and linux stops seeing it at which point I have to power-cycle the drive and it works fine again. I assume this is a symptom of a failing control board (either in the drive or in the usb connection hardware). I don't want to dismantle the drive yet and connect it to a SATA port in case I damage something (or in case there is no SATA connection on the drive). The drive is at home so I can only check it occasionally, which means progress is much slower than if I could restart it immediately every time it crashed.

DDRescue is currently showing in the order of 50 megabytes worth of errors (made up of 1,300 errors). Only about 5% of the data on the drive is irreplaceable (recent documents and family photos from the past 2 years) so if I am lucky I will get 90% - 100% of the important stuff back which would be a great result.

I'll post further once I've got as much of the drive copied as possible. Thanks again!!!!

 

I do have one further question if that's OK which is this: Where on the drive are located the most vital files needed to decrypt and read the drive directory/file structure? Are they likely to be located inside the first 4GB of the drive (which I have recovered apparently without errors)?

The vital files I am worried about are the truecrypt headers for both the outer and hidden volumes (which are already backed up on a different disk) and the unencrypted and encrypted partition table, master boot record and GPT files (and anything else vital to read the disk file structure including the encrypted and unencrypted file structures - I am not sure if I need anything else).

The reason I ask because I want to make sure I have targeted the most vital files first in case of total drive failure, and it seems like if the directory structure files are not recovered, I will be totally screwed unless I manually go through the millions of files looking for the ones I want using something like "photorec" (which would take months ).

Anyway, based on this: https://www.wilderssecurity.com/threads/truecrypt-bootloader-footprint-on-disk.260151/ it seems the most vital files are in the first few megabytes of the drive and also at the start of each Truecrypt volume. In my case I have an "outer" volume and a "hidden" volume so I presume I need to as a priority recover the start of both volumes and the start of the disk.

I think the outer volume was only 1GB or less, so I hope this means that by getting the first 4GB of the drive rescued and error free, everything vital needed for the file structure is now safe but I would be immensely grateful for any further guidance on this. Thanks again (x 100!!)

PS I did read that some backups of the directory structure files are stored at the end of the drive, so I also recovered the last 100 GB but annoyingly there is a 250kb error very close to the end (maybe not quite at the end though - I'm not sure how to check this).

 

Just try to get it all. You already have the encryption headers, which is great. You also need the beginning of each volume and each volume's FAT (near the front of the volume, if FAT formatted) or MFT (near the middle of each volume, if NTFS formatted) However, the reality is that you need everything. All data needs to be located at its original distance from the header or the data won't decrypt, so you can't just recover a small piece of the volume and then try to decrypt it all by itself. Well, you can, but it's a considerable chore and you'd have to be an expert to make it usable. I won't go into any details on this because you're already busy enough.

I think the best approach would be to disassemble the drive and work directly through the SATA interface, as you are getting far too many crashes etc. and the connections and/or USB interface are suspect. It shouldn't be too hard. All you have to do is check with the manufacturer to confirm that its possible and that the drive uses standard connectors.