Unable to Mount TC Encrypted Volume

Discussion in 'encryption problems' started by chucklz1515, Mar 16, 2014.

Thread Status:
Not open for further replies.
  1. chucklz1515

    chucklz1515 Registered Member

    Joined:
    Mar 16, 2014
    Posts:
    20
    Location:
    Canada
    Hello all,

    This is my first time posting here (actually I just registered today), but I've found this forum useful in a number of occasions. Unfortunately, it appears that most TC problems are specific so sifting through other posts would trend useless.

    Here's the background:

    I purchased a 1TB 2.5" hard drive a few months back in order to have a large encrypted volume for sensitive data. I made the entire raw device encrypted using TC and began moving my files over.

    Recently (2 months ago), I tried connecting it to one of my other computers (I have only used it with one PC) and it did not prompt to format drive as it always does in Windows. I went into Disk Management and saw my 1TB drive NOT initialized. So I have the bright idea to initialize it. BAD IDEA as I forgot it writes over the first chunk of the disk. Now of course mounting it in TC fails, and I read somewhere that I can use the embedded backup headers to mount until I can fix the regular headers. This worked until the embedded headers broke too. Now I'm left with an unmountable drive.

    The only thing that happens when I try to mount the device is it give me an error here (yes, it's an image):
    https://drive.google.com/file/d/0ByWbGjoNdbUCbGZ0QXlzX1ZSRmc/edit?usp=sharing

    It looks like the only thing that can be mounted is the hidden volume (20GB). But then again, I'm not toooo familiar with TC.

    Any help is greatly appreciated!
     
  2. Palancar

    Palancar Registered Member

    Joined:
    Oct 26, 2011
    Posts:
    2,402
    Did you create a volume header backup? Its a small 128K file that would save your bacon about now.
     
  3. chucklz1515

    chucklz1515 Registered Member

    Joined:
    Mar 16, 2014
    Posts:
    20
    Location:
    Canada
    Unfortunaly no. I have been able to use an embedded backup header for a while to mount it, but that broke too. I'm wondering if I can grab it somehow and restore it.
     
  4. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    1,034
    Location:
    Hawaii
    What do you mean, "this worked until the embedded headers broke too"? There's no reason for them to suddenly break. What happened, and what are the symptoms? Are you sure this was a fully encrypted raw disk and not an encrypted partition? The headers on fully-encrypted disks don't suddenly "break".

    Incidentally, the embedded backup headers can also be used to restore the volume headers, not merely to mount the volumes. Did you try that? Initializing a fully-encrypted disk is merely a one-time overwrite, so restoring both volume headers would fix that right away. Although from the sound of it, it may be too late for you to do that now. I still don't understand why both of your embedded backup headers broke, though. Is there something more going on that we don't know about? Is the disk failing?

    There's no point in trying to manually extract any of the headers in order to recover them, as the headers don't tend to get lost on unpartitioned, wholly-encrypted (raw) disks. The location of the headers on a fully-encrypted disk is relative to the very beginning or the very end of the physical disk, and these locations don't change (unlike the headers on encrypted partitions, which are at the whim of the partition table). Attempting to extract the headers using WinHex or similar won't do anything that TrueCrypt isn't already doing, as it looks for the headers in the exact same locations.

    Are you certain that you're selecting the entire disk, and not a partition, when you try to mount the volumes? And you've always done it that way? Was there ever a partition listed under this disk in the TrueCrypt "Select Device" screen?
     
  5. chucklz1515

    chucklz1515 Registered Member

    Joined:
    Mar 16, 2014
    Posts:
    20
    Location:
    Canada
    You're right, I'm sorry I should be more clear. I have a new 1TB fully encrypted hard drive. By fully encrypted I mean I didnt use container files.

    One day I had accidentially initialized the drive in Windows which will, as far as I know, overwrite the beginning portion of the drive. Unfortuately This took out my header (I looked at the TC partition layout on their site).

    It is at this point that I cannot mount the TC partition on the drive. I read online that I can still mount the partition by selecting the option that will use the embedded headers at the end of the disk. This worked!... for a while.

    I'm not sure exactly how it happened, and I'm not sure I did anything bad to the device other than continue to mount it with the embedded headers (until I was going to find a solution online).

    So to answer your questions in short:
    I think I remember encrypting the ENTIRE drive when I started, but whenever I mount it it always used \Device\Harddisk#\Partition0 so that leads me to believe that I made an encrypted partition. And no, the drive is not failing, its barely 5 months old and the problems happened IMMEDIATLY after I initialized the drive with Windows.

    I grabbed the 2 embedded headers from the drive using WinHex anyway (I just wanted to have them incase). And I noticed that when I mount and get the error (in the picture in my first post), the size of the "mounted" partition is 20GB and is the Hidden partition. That is what is really baffling me more.
     
  6. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    1,034
    Location:
    Hawaii
    I am unable to view that picture. Can you repost it another way?
     
  7. chucklz1515

    chucklz1515 Registered Member

    Joined:
    Mar 16, 2014
    Posts:
    20
    Location:
    Canada
  8. chucklz1515

    chucklz1515 Registered Member

    Joined:
    Mar 16, 2014
    Posts:
    20
    Location:
    Canada
    I'm curious; if i grab a dd image of the drive, can i decrypt it manually. Meaning, if i know the passphrase and encryption algorithm, I should be able to decrypt it myself, no?
     
  9. chucklz1515

    chucklz1515 Registered Member

    Joined:
    Mar 16, 2014
    Posts:
    20
    Location:
    Canada
  10. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    1,034
    Location:
    Hawaii
    Well, at least you can mount the hidden volume using its embedded backup header. Hopefully there is some data in there that you can recover. Are you able to browse the hidden volume using Windows Explorer? You should be able to. The act of initializing a drive shouldn't even come close to damaging the hidden volume's file system, so it should be working normally. If it isn't then you did more than merely initializing your drive. (In this case you may want to examine the mounted volume using data recovery software such as GetDataBack or Photorec to see how much of your volume's contents are recoverable).

    In fact, initializing a drive shouldn't damage the outer volume's embedded backup header either. Did you create or format a partition, or something like that?
     
  11. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    1,034
    Location:
    Hawaii
    No, there's no convenient way to do that, nor is there any advantage in doing so. A skilled programmer or cryptographer might be able to come up with an alternate method for decrypting a TrueCrypt volume, but they would still need to find and use the intact volume headers. And if you can find those then you might as well just use TrueCrypt, as it's much easier than putting together a whole new application that does essentially the same thing.
     
  12. chucklz1515

    chucklz1515 Registered Member

    Joined:
    Mar 16, 2014
    Posts:
    20
    Location:
    Canada
    I did not try to reformat, or create any partitions. I'm just as baffled as you are. I usually post to forums as a last resort if googling and logic are unable to solve my problems.

    I am going to try the 2 tools you reccomended, but the hidden drive that was mounted is only 20GB in size, and not 1TB. I'm worried that all of my data is gone.

    As for the manual decryption; good point lol. I thought it would be like decrypting a hash or something. What's weird is that I dumped the embedded headers from the drive, but they change when I unplug amd replug in the drive. Is that suppose to happen? (comparing dumped 128kB file with raw hex on disk using wxHexEditor (linux equiv of winhex))
     
  13. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    1,034
    Location:
    Hawaii
    The outer volume will be very close to the size of the entire disk, but the hidden volume must by definition be smaller, and sometimes it can be considerably smaller, as it is a user-selected subset of the outer volume. The size will be whatever size you chose when you created it. It sounds like you don't recall setting it up to be only 20GB.

    Among other things, the volume header stores the original size of the volume. If the header accepts your password then the header is undamaged, so one would assume that the volume size information that it contains is also correct. So try this: With the hidden volume mounted, click on Volume Properties in the TrueCrypt interface. The "size" in bytes (coming directly from the header) should match the size that you obtained through Windows.

    Good luck with the data-recovery software.

    I would probably try this as well, just to figure out what happened: take a spare unpartitioned disk (or use a virtual disk), encrypt it by setting up both an outer volume and a hidden volume, ensure that the embedded backup headers for both volumes are working normally (by using the "mount using emebedded backup headers if available" command), then "mistakenly" initialize the drive and see if the either of the embedded backup headers are affected. I was not aware that initializing a disk would write to the end of the disk, and I would be especially surprised to find that the hidden volume's embedded backup header was spared while the outer volume's embedded backup header was damaged, as the outer volume's header is located farther into the disk.

    You could also do a "shortcut" version of the above by merely taking a raw disk, filling the last 128KB (plus a few more bytes for padding) with a single non-zero character, initializing the disk, and then seeing if the disk's final 128KB was overwritten in any way. This would be easy to do with a hex editor.

    Alternatively, use a hex editor to examine your current disk. Focus on the two 64KB embedded backup headers that are located near the end of the disk, especially the first 512 bytes of each one, to see if they show any signs of being overwritten. They can be found at "Total size of disk in bytes minus 65536 bytes" (hidden volume) and "Total size of disk in bytes minus 131072 bytes" (outer volume). The headers should be completely random from beginning to end and should not contain any long strings of zeros or anything else recognizable.

    (You might have to make a 1-byte adjustment if you do this manually by moving backwards from the end of the disk, as you will be starting on the last byte and you can't count that one.)

    PS: "\Device\Harddisk#\Partition0" refers to a fully-encrypted disk, not an encrypted partition. If the partition number were 1 or higher then we would be discussing partition encryption, and the recovery effort would be a bit different.
     
  14. chucklz1515

    chucklz1515 Registered Member

    Joined:
    Mar 16, 2014
    Posts:
    20
    Location:
    Canada
    I've tried using both tools for data recovery, but they couldn't find any files.

    However, after looking again at the drive using a hex editor, I noticed that the beginning 512 bytes are still displaying values as if the disk was initialized by windows:
    http://www.dtidata.com/resourcecenter/wp-content/uploads/2008/10/mbr-in-win-hex-thumb.jpg (not my device, but same hex values)

    Which leads me to believe that the embedded header restore was not successful.

    I'm curious if I can do a manual restore of the headers by copying the hex values of the embedded headers that are at the end of the device to the beginning of the device.

    Would that work?
     
  15. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    1,034
    Location:
    Hawaii
    Yes, it would probably work, but it shouldn't be necessary to do it that way. And you have to be very careful to copy and paste the correct 512 bytes or your password will not be accepted.

    If, when restoring the TC header, you selected the hard disk itself (i.e. HardDisk 2) in TrueCrypt's device selection screen then the 512-byte restored header should have replaced the first 512 bytes of the disk. Obviously this did not happen, as your 1st sector contains a disk signature, an empty partition table and the boot sector signature (55 AA). I suggest you try again.

    (Sorry, I've been very busy lately. I have some free time now.)
     
  16. chucklz1515

    chucklz1515 Registered Member

    Joined:
    Mar 16, 2014
    Posts:
    20
    Location:
    Canada
    I've tried restoring the headers from the embedded headers about 4 times. The only thing it has done was allow me to mount the 20GB partition (picture in previous post). As of now, I am doing a dd backup of the entire drive.

    I also believe I have some insight as to why the volume failed. The first mistake was when I initialized the disk with windows. This messed up the beginning 512 bytes of the disk. I was able to mount the partition in TC using the embedded backup headers, and this worked for a while until one day it wouldn't mount. I think I know why. While watching my dad configure his 5 new Western Digital NAS 4TB drives in a FreeNAS server, I asked him what made the NAS drives so special. He said the simple answer is that they did not have error checking on the device as it conflicts with the error checking that the NAS software in the OS runs. He also said that they should NOT be used for file storage.

    Guess which kind of hard drive my little 1TB encrypted storage is? Yep, its a Western Digital NAS drive. I believe that during one of my USB disconnects, it may have caused an error which resulted in the embedded headers not working, though I'm not 100% on the diagnosis. I'm going to try and manually replace the headers with the embedded ones after I do a surface error check on the drive and fix them if possible.

    Thanks dantz for your help, it's really appreciated! And I will post with my results when completed (~5 days to backup 1TB with dd lol)
     
  17. chucklz1515

    chucklz1515 Registered Member

    Joined:
    Mar 16, 2014
    Posts:
    20
    Location:
    Canada
    Alright, I've backed up my drive and tried to copy the embedded headers from the end of the device to the beginning of the device. It didn't work (ie. I got a "password incorrect or not Truecrypt" message). I'm at a loss. I have one more idea in theory, but I seriously doubt it will work.

    I think that the standard header is defiantly broken (both in the beginning of the device and the embedded), so maybe I can use the header of the hidden volume. Now hear me out, if I crack open the hidden volume header and change the values to reflect that of the standard volume location, size, etc. Using this as a resource.

    It's quite a stretch I know, but I'm getting desperate. This information is irreplaceable. I guess my last resort is the manual decryption I talked about earlier. I really hope it doesn't come to that.
     
  18. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    1,034
    Location:
    Hawaii
    Your idea is creative, but it won't work because the hidden volume header does not contain a master key that can be used to decrypt the outer volume. It only contains the master key for the hidden volume.

    I think it's time to try to figure out why your outer volume's embedded backup header suddenly stopped working. It used to work. Are you selecting the volume differently than you used to? Are you somehow mistyping the password? Did you overwrite the header somehow? Or move it? The headers don't just break like that. There has to be some sort of an explanation.

    I'm sorry to say this, but if you can't come up with at least one intact header that can decrypt the outer volume then you will be unable to proceed. Manual decryption without having the correct master key is not really an option.
     
  19. chucklz1515

    chucklz1515 Registered Member

    Joined:
    Mar 16, 2014
    Posts:
    20
    Location:
    Canada
    Ah I see. And I used to have the device as a "Favourite Volume" so I could easily mount it. I doubt that I am mistyping the password because I verified in plain text and tried numerous times. I don't believe I overwrote the header, but then again I don't know what would cause that, same goes for moving it.

    I think they broke because I had purchased a USB 3.0 PCMCIA card for my laptop so I could use the USB 3.0 functionality of the SATA to USB enclosure for the drive. The 3.0 adapter was garbage and left my Windows hanging many times. I returned it, but after which the device wouldn't mount using the embedded headers (this was after I had initialized the drive in Windows). I had also switched the SATA to USB enclosure I was using for the device. Should I try to use the old SATA to USB enclosure again?

    Also, can I attempt to decrypt the headers using the salt of the headers and the algorithm?
     
  20. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    1,034
    Location:
    Hawaii
    I think it's strange that the hidden volume's embedded backup header still works whereas the outer volume's embedded backup header used to work, but now it doesn't. The two headers are stored side-by-side near the end of the disk or partition. Usually it's the hidden header that fails, as it is closer to the end of the disk.

    In a case like this I would usually suspect an incorrect password or a missing keyfile (if used). However, your situation seems to involve a lot of strange hardware issues. I'm not sure what to suggest.
    I honestly don't know.
    Those types of attacks are infeasible, as TrueCrypt was specifically designed to resist them. It could take millions or trillions of years to try to bust in that way. It would be more efficient to try to figure out exactly what it is that has gone wrong and to see if it can be made right.
     
  21. chucklz1515

    chucklz1515 Registered Member

    Joined:
    Mar 16, 2014
    Posts:
    20
    Location:
    Canada
    Ah I see. I attempted the old SATA to USB enclosure, no change. I've tried every permutation of passwords I would have used on that device. Still no dice. The weird part is that I don't get a "Incorrect password..." message, but rather it tries to mount the hidden partition even when I don't select to mount it. Is that normal?

    Also, I extracted the embedded headers at the end (two 64KB files) and tried to mount them in TC. The hidden mounted, the outer does not.
     
  22. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    1,034
    Location:
    Hawaii
    I don't see how you would even know this, as TC does not provide that information. How can you tell that TC was attempting to mount the hidden partition, and what message (aside from "incorrect password etc.") are you seeing?

    FYI, there is no way to specifically 'select' either an outer or a hidden volume for mounting, aside from entering the appropriate password. You merely select the desired disk, partition or file that contains your outer TrueCrypt volume (irregardless of whether or not it also contains a hidden volume) and then enter the appropriate password.

    During the process of mounting a volume TrueCrypt first attempts to validate your password against the outer header. If that doesn't work then TrueCrypt automatically make the same attempt against the hidden header (even if it's not there). The volume that gets mounted is determined by which password you enter. If neither attempt validates then you will see the "incorrect password etc." prompt.

    Throughout this thread I have assumed that we've been talking about a typical "outer volume containing a hidden volume" arrangement. If your setup is different then perhaps I have misunderstood.

    Do the headers appear to be overwritten in any way? Do they seem to contain any non-random data such as strings of zeros ("00 00 00 00")? Focus especially on the first 512 bytes of the outer volume's header.
     
  23. chucklz1515

    chucklz1515 Registered Member

    Joined:
    Mar 16, 2014
    Posts:
    20
    Location:
    Canada
    The image I posted earlier describes what I am seeing when I try to mount. Note the 20GB size.

    The embedded headers do not appear to be overwritten, but the first 512 bytes of the drive (first header) is overwritten with MBR garbage.

    This is how I assume the TC formatting to work:

    1: Header #1 outer (64KB)
    2: Header #2 hidden (64KB)
    3: Outer Volume (majority of device ~960GB)
    4: Hidden Volume (20GB in my case)
    5: Embedded Header #1 outer (64KB)
    6: Embedded Header #1 hidden (64KB)

    Is this correct?
     
  24. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    1,034
    Location:
    Hawaii
    Almost correct. The header placements are correct, but the hidden volume is completely encased within the outer volume, so if you want to be totally accurate then it would actually look more like this:

    1: 64KB outer volume header
    2: 64KB hidden volume header
    3: starting offset of outer volume
    4: most of the outer volume data
    5: starting offset of hidden volume
    6: all hidden volume data
    7: ending offset of hidden volume
    8: remainder of outer volume data (probably no user data)
    9: ending offset of outer volume
    10: 64KB embedded backup header for outer volume
    11: 64KB embedded backup header for hidden volume

    Not that it matters very much. Your less-detailed version is perfectly acceptable for our purposes.

    Anyway, I just re-read the thread to see if I'm missing anything, as it's not quite making sense. There are a few inconsistencies that are preventing me from fully understanding the situation. Let's try to clear them up, and maybe then I will be able to give you better advice:

    If Windows always prompted you to format the drive then you may have encrypted a partition, not an entire raw disk. If you had encrypted an entire raw (unpartitioned) disk then Windows would be offering to initialize the drive, not format the partition.

    Hmmm. If you used partition encryption then maybe the drive's boot sector somehow became overwritten. This would wipe the mbr and partition table and also make the drive appear uninitialized to Windows. Then you reinitialized it. Just thinking out loud here.

    By "this worked", do you mean that you were able to mount both volumes and view and access their contents? Or was it merely possible to mount the volumes but not actually access their contents? (i.e. did Windows offer to format the volumes when you tried to view their contents).

    If you always selected the device as \Device\Harddisk#\Partition0 then this would confirm that you had a fully-encrypted raw drive, not an encrypted partition. An encrypted partition will always be listed as Partition1 or higher, never Partition0. This is an important distinction that may make or break our understanding of the situation, so please think back and try to be as accurate as possible: Did you always select the volume by selecting the entire hard disk, not a partition, and was it always listed as "Partition0"?

    You say that TrueCrypt "tries to mount the hidden partition", but the image that you referred to in Post #9 shows that your hidden volume is mounted. TC is not just trying, it's succeeding. However, just because a volume mounts doesn't guarantee that it also contains a working file system.

    The "no file system" error message that is included in the image implies one of two things: Either the hidden volume has been partially overwritten such that its file system is damaged, or TrueCrypt is not able to find the correct starting offset of the volume.

    That's you, I'm afraid. TrueCrypt does not forget the original size of a volume. The data that specifies the volume size, its starting offset, etc. is encrypted and is stored within the header. There's no way you could alter it without breaking the header (the checksums would fail), in which case you would not be able to mount the volume at all.

    It's also interesting that you have been unable to restore the embedded backup headers to the front of the drive. This could happen if you selected a partition instead of the entire disk, as in that case the header would go to the beginning of the partition. Could that be what's been happening? Has the drive changed since you posted that image? Does it now contain a partition?

    Let's do a quick test: Use TrueCrypt to mount your hidden volume to an available drive letter, then open the mounted volume in a hex editor. (In WinHex you would click on "Tools: Open Disk" and then select the exact same drive letter under "Logical Volumes").

    Do you see anything recognizable in either the hex or the text column? Any blocks of zeros ("00 00 00 00" etc.)? Any known words or abbreviations? Scroll down a few screens and look some more. We're trying to find out whether or not your hidden volume contains any decrypted data whatsoever.

    Sorry about the long post. I'm just trying to understand what's going on here, as things are still a bit unclear.
     
  25. chucklz1515

    chucklz1515 Registered Member

    Joined:
    Mar 16, 2014
    Posts:
    20
    Location:
    Canada
    Thanks for the clarification on the formatting.

    Let me start from the beginning again as I may have used incorrect terminology and thus created confusion.

    I bought a 1TB drive from the store and plugged it into my laptop (Windows). When I set it up with TC, I believe I decided to have an encrypted drive over an encrpyted partition (I read somewhere about better performance with file transfer). At this point I've only ever used the drive with my laptop and have ALWAYS had the "Format Disk?" message from windows pop up. I always ignore it and mount with TC.

    One day I plug the drive into my desktop for the first time and I don't see the "Format Disk?" message. I went to TC to try and mount the volume and noticed that the device didn't show up in the list. I went to Disk Management and noticed that the drive was not initialized, so I initialized it with MBR.

    I now couldn't mount it at all. In panic, I hit Google to find help and read that I should try to mount with embedded headers. This worked as I was able to browse the outer volume and could transfer files back and forth.

    I used this "work around" for a couple months until I bought this PCMCIA USB 3.0 card for my laptop so that I had the nice speed. The card was CRAP as it caused many hangs and other problems on my laptop. I returned it but not before using it with my encrypted drive. After which the volume wouldn't mount with the embedded headers with my current error (no file system).

    Now, I MAY have created an encrypted partition INSTEAD of an encrypted device. So I'd like to look into both scenarios.

    I have also tried exploring the mounted 20GB partition, as you suggested, in WinHex and noticed no 0's or other full words or any suggestion of anything else - just garbage.

    I hope this helps and sorry for my long post.

    P.S. My ISP is doing construction on my street to I have no internet, so I appologize that I have not made any quotes to make it easier to read as I cannot do that from my iPhone. Even writing this was hell lol.
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.