Unable to Mount TC Encrypted Volume

OK, I will come up with a procedure that assumes you somehow lost your partition table, then we can test it to see if our assumption is correct.

If our assumption is correct, and if we are able to restore your original partition offsets, then you will probably be able to decrypt your hidden volume.

Too bad you don't have the outer volume's embedded backup header working, as it would be much more helpful, but we can still do it this way. It'll involve a bit more struggle, but it should work.

For starters, what hex editor are you using? Are you good at it? Will you be able to translate my instructions if I write them for WinHex?

The first thing I would do would be to open the physical disk in a hex editor and examine the area around offset 1048576 (decimal) to see if there are any obvious signs of a transition from mostly zeros to a huge, contiguous block of random data that appears to fill most of the disk. This is often what the staring point of an encrypted TC partition looks like.

However, if the disk was originally partitioned using Windows XP or certain older versions of Linux then you should also look at offset 32256 (decimal) for a similar transition.

Start with that and tell me what you find.

 

I'm using WinHex for Windows. I'm not an expert at it, but I feel comfortable with it.

I took a look at both offsets (just to be safe, even though I used Windows 7 to set up the encrypted volume) and there is only garbage (ie. no long strings of 0s) and no visible words either.

Sorry about the delay, I have been busy.

 

I'll respond to your most recent post soon, but first, I just realized something. You mentioned earlier that you used to have the device set up as a TrueCrypt "Favorite volume". Let's hope that your settings are still there, because if so then they can provide us with some valuable information.

Open TrueCrypt, click on "Favorites; Organize Favorite Volumes" and examine your old entries, especially in the "Volume" column. The volume path will indicate whether your original volume was based on a raw hard disk or a partition, and it would be very helpful for us to know that.

 

I don't have Windows on my laptop anymore, I switched to Linux as I needed it for college (ARM stuff). The favourite mount was on the windows install on my laptop. I was, however, able to access the config XML file from the backup I did of my laptop. It looks like this:

Code:

<?xml version="1.0" encoding="utf-8"?>
<TrueCrypt>
    <favorites>
        <volume mountpoint="E:\" removable="1" noHotKeyMount="1" openExplorerWindow="1">\Device\Harddisk1\Partition0</volume>
    </favorites>
</TrueCrypt>

I think you said before that "\Device\Harddisk1\Partition0" means that it was based on raw disk and not partition.

 

Yes, this pretty much confirms that you encrypted an entire raw disk and not a partition. Darn! There are not too many options left now. The headers on fully-encrypted disks are always located relative to the beginning and ending of the physical disk. Since they are not reliant on partition table entries, they don't tend to become "lost".

At this point my best guess is that you may have partially forgotten your outer volume's password. As well as denying access to the volume, this would also prevent you from restoring the outer header to the front of the disk. Another possibility is that the embedded backup header for your outer volume was somehow broken or missing even before the accident occurred, so it could never be relied on. Did you ever test it prior to the accident?

As for your hidden volume, which is still mountable, have you used WinHex to examine the contents of your mounted hidden volume? Have you found any non-random data (i.e. strings of zeros, etc.)? Just to confirm that the volume is decrypting properly? I don't see any mention of this in the thread.

However, the bottom line, from my point of view, is that merely initializing a disk simply does not cause this level of mayhem. To the best of my knowledge, initializing a raw fully-encrypted disk merely overwrites the outer volume header, in which case a full recovery of the volume can usually be performed very easily by merely restoring the damaged header, either from an external backup or from the embedded backup.

Perhaps your unusual disk has played a part here, but I don't know how to determine that. Something out of the ordinary has certainly happened, otherwise your hidden volume (at least) would have made a full recovery.

Sorry, I don't have any more ideas at the moment.

 

I don't recall testing the embedded headers, but I know for certain they worked after I had initialized the disk.

I have an idea, are the headers in plain text when decrypted? If so, then I should be able to open the headers no problem which I have done on the embedded before. Now, if I can do that I should be able to open the outer embedded header too. If I can open the outer header then I should be able to grab the Master Key and unlock my volume, right?

My plan:
1. Decrypt outer header
2. Grab Master Key from header
3. Write a program to decrypt my volume using the algorithm I chose

I know TrueCrypt is designed to prevent breaking in (I wouldn't have used it otherwise), but seeing as I know the header passwords then that changes some security that is in place.

As for my unusual drive, I don't think that's the problem anymore. I had used Western Digital testing tools and everything checked out. No bad sectors or anything. So I don't think it was a result of a NAS drive fault.

 

Before even beginning what could amount to a long, fruitless cracking attempt, the first think I'd try would be to visually inspect the (assumed) outer volume's embedded backup header using WinHex. Mount the physical disk in WinHex, then click on "Navigation: Go to offset: 131071 relative to End (back from)." This puts you at the very beginning of what should be the outer volume's embedded backup header. The first 512 bytes are all that matter. See if they look "normal" (that is, completely random as far as you can tell.) You generally can't tell if a 512 byte block of data is random just by looking at it, as the sample size is way too small, but you can often tell if it's not. For example, any blocks of zeros would be a dead giveaway that the header has been overwritten.

If you think that for some reason your header might be slightly damaged then you can try mounting the volume via TrueCrypt command line and using the switch "/mountoption recovery". This will skip the header's checksum testing, thus possibly allowing you to mount the volume even if the header happens to contain a minor, non-critical error. This won't work if the key is damaged, though.

However, it's pretty unlikely for your header to suddenly become damaged if all you did was initialize your drive and then used it for awhile afterwards via the embedded backup headers. There are very few programs that will write to that portion of an encrypted drive. An accidental format would do it, though. So might the creation of a new partition. Did you do anything like that?

There's an interesting tool named TCHead that can decrypt a TC header and display it as plaintext, allowing you to examine the entire contents of the header, including the decrypted master key, but it requires both the correct password and an intact header, just as TrueCrypt does, so I think you'll get stuck at that point.

A more fruitful approach would be to reconsider your outer volume's password. If you think there's any chance that what you've been typing in could be slightly incorrect then I would suggest trying OTFBrutusGUI, as this is an excellent and very flexible tool for discovering a partially-forgotten password.

TCHead can provide similar brute-force capabilities (by using a wordlist that you provide), but it's not really intended to be a password cracking tool and has not been optimized for that role.

 

Sorry for my delayed response. This past month has been very busy for me while I completed my senior project at college. I took a look at the first 512 bytes at offset 131071 relative the end and saw no long blocks of zeros. It appeared perfectly random (to a human eye anyway).

The mount option "recovery" did not improve my situation either, as you predicted. I'm going to try the TCHead and the OTFBrutusGUI tools you suggested. I read on the TrueCrypt site that TrueCrypt is now insecure. Is this true? The site did recommend using Bitlocker in Windows, which kinda shocked me. I also read that the site may have been hacked and that their main page is a troll.

I'll get back to you with the result of the TCHead and OTFBrutusGUI.

 

You probably won't get much help from TCHead, but it is a neat little tool if you already have access to a TrueCrypt volume. Good luck with OTFBrutusGUI, maybe that's what you need to try. We'll see.

A lot of people were shocked when TrueCrypt suddenly "folded". It appears to be gone for good. Any attempt to reach the TrueCrypt site is redirected to the recently-created web page that you undoubtedly saw.

The general consensus is to disregard the strange recommendations (such as switching to Bitlocker) on that page, and definitely NOT to download or install the new version 7.2, but nobody actually knows what is meant by the phrase "TrueCrypt is not secure as it may contain unfixed security issues", as no further details have been provided. It's quite a mystery, but then again, TrueCrypt has always been surrounded by mystery.

There are some threads about this topic in the Privacy Technology forum. The bottom line is that nobody truly knows what happened, but there are plenty of guesses.

As for myself, TrueCrypt suits my needs perfectly and at this point I intend to keep on using it until (if ever) a genuine real-world vulnerability can been demonstrated by somebody who doesn't have access to vast computing power and/or top-secret backdoor information.

Of course, my threat model merely involves protecting my data against casual burglars, not a major government. I have never recommended using TrueCrypt for storing highly sensitive data that might draw the interest of high-level law enforcement or an intelligence agency.

 

OTFBrutus looks like it's gunna keep my computer toasty for the next few days (to do the brute forcing I want). It sucks that it doesn't support GPU cracking as I have a nice AMD 7990 going to waste, 3 actually (I was mining Litecoin during the winter, now it's too hot).

I did find TrueCrack, but it's Linux only, so I'd have to boot a live CD or a HD with Linux to try that and I probably will when OTFBrutus has finished.

I read here that they plan to fork the development for TrueCrypt again and also perform audits to confirm if the "insecurity" is true. I for one am interested in giving my computer's resources for that.

 

Does oclHashcat-plus support your GPU? I thought they had a Windows version.

 

Due to my password length (23 mixed alpha numeric + specials), most TC cracking utils don't work or will take ages. The ones that do support my GPU don't support my hash algorithm (AES-Twofish-Serpent). I've basically given up hope at this point. I've attempted to scan the only thing I can actually mount (20GB hidden partition) with GetDataBack one last time and it appears to be finding things, but 20GB is far less than all the data I had.

I really appreciate your help dantz! Maybe from here on I'll just keep cutting away at it till I find something. I've also seen the beauty of file containers rather than encrypted devices.

 

Good luck!

 

need help in unlocking a truecrypt volume