TrueCrypt Header Corrupt

Discussion in 'encryption problems' started by zombielove, Jan 9, 2014.

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

    zombielove Registered Member

    Joined:
    Jan 9, 2014
    Posts:
    12
    Location:
    United States
    I was able to follow most of the steps listed in this thread: https://www.wilderssecurity.com/showthread.php?t=357357

    I got the backup header to load without an error message. I am now at the point where I need to start the cloning procedure that Dantz gave out in that thread but my hard drive is 931GB not 16GB. Could someone help me with the offsets that I need to copy for the clone to work?

    Thanks!
     
  2. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    1,034
    Location:
    Hawaii
    I'm not sure what you've done up to now. We need to see more details. Are you mounting your volume using the "mount using backup header embedded in volume" command, or did you create a test file by using WinHex to copy the embedded backup header to another file?

    If you've found the embedded backup header then mount the volume or the test file (whatever you've got) and click on Volume Properties, then write down the Size of the volume in bytes. We can use that number, along with ending offset, to find the starting offset of your volume.
     
  3. zombielove

    zombielove Registered Member

    Joined:
    Jan 9, 2014
    Posts:
    12
    Location:
    United States
    First, thank you sooo much for your help DANTZ! Whether this works or not I am happy you are willing to help.

    I created a test file by using WinHex (paid) to copy the embedded backup header to another file.

    size = 1000169275392 bytes

    Starting offset for the embedded backup header block is: 1000170455040
    so, I believe the ending block for the backup header should be: 1000170520575
    This gives me a block that is 65,536 bytes and what I used for the mountable test file

    Let me know if I need to provide anything else.

    My drive doesn't have any unreadable headers. It just stopped showing a directory structure and file finding programs were unable to help after I was able to mount the drive with TC again. Hopefully this copy will help. (fingers crossed)
     
  4. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    1,034
    Location:
    Hawaii
    I need to ask a few questions so I can get clear on your situation. It's possible that your data is not decrypting when you mount the volume, although the same symptoms could also come about from extensive file system damage, so we need to figure out which one it is.

    Did your regular volume header stop working, forcing you to use the embedded backup header?

    Was your volume originally partition-hosted, and did you somehow lose the partition definition?

    If so, in "Select Device", are you selecting the entire disk now instead of the partition?

    In some cases this will result in a volume that can still be mounted, but will not decrypt.

    Try this: Mount the volume, then open the mounted volume in WinHex. To do this, choose "Tools: Open Disk" and select the Logical Volume drive letter that you mounted your TC volume to.

    Then take a look at the hex and text data. Do you see anything recognizable? Are there any words in the text column, or any patterns (such as long strings of zeros) in the hex column? Are there any entries in the Directory Browser (just below the menus)? Scroll down through the data a bit and look there too. (We're just trying to confirm whether or not your data is actually decrypting when you mount the volume.)

    If it's still not clear, you try using WinHex to search for long strings of zeros in the hex column, as these are very common in most filesystems but will almost never show up in encrypted data. "Search: Find Hex Values: "0000000000", Search Down. (That's ten zeros, without the quotes).

    Also, you can take the size of your original volume as reported by TC (you posted 1000169275392 bytes) and add 262,144 to that (to account for the four headers). The result "1000169537536" should be the size of the partition or disk that you are currently selecting when you mount the volume. If not then that would explain the failure to decrypt.
     
  5. zombielove

    zombielove Registered Member

    Joined:
    Jan 9, 2014
    Posts:
    12
    Location:
    United States
    Did your regular volume header stop working, forcing you to use the embedded backup header?
    Yes, I was unable to mount the hard drive. It gave me the error that the file header was bad and then TC tried to do a repair. I was able to mount the drive after the repair but then I was getting an "incorrect parameter" message and the drive was mounted but not accessible (i.e. not explore-able).

    Was your volume originally partition-hosted, and did you somehow lose the partition definition?
    I encrypted the entire external hard drive (not a particular file). I assumed that the partition was damaged and tried a repair using TestDisk on what I thought was the decrypted, mounted device (post TC attempting to "fix" the headers and it being successfully mounted but not explore able). TestDisk was unable to find the partition

    If so, in "Select Device", are you selecting the entire disk now instead of the partition? I believe that is the case. It just shows the device without the "Device\Harddisk0\Partition0" Volume information after it

    Try this: Mount the volume, then open the mounted volume in WinHex. To do this, choose "Tools: Open Disk" and select the Logical Volume drive letter that you mounted your TC volume to.

    Then take a look at the hex and text data. Do you see anything recognizable? Are there any words in the text column, or any patterns (such as long strings of zeros) in the hex column? Are there any entries in the Directory Browser (just below the menus)? Scroll down through the data a bit and look there too. (We're just trying to confirm whether or not your data is actually decrypting when you mount the volume.)
    I did this and I'm not seeing any recognizable data, text or otherwise. I'm not seeing anything that looks like what I know is in the drive

    If it's still not clear, you try using WinHex to search for long strings of zeros in the hex column, as these are very common in most filesystems but will almost never show up in encrypted data. "Search: Find Hex Values: "0000000000", Search Down. (That's ten zeros, without the quotes). Due to the size of the volume, this will take several days. However, I have not seen this when I scroll through the data and I have only seen this when I use WinHex to look at the drive itself and not the mounted volume

    Also, you can take the size of your original volume as reported by TC (you posted 1000169275392 bytes) and add 262,144 to that (to account for the four headers). The result "1000169537536" should be the size of the partition or disk that you are currently selecting when you mount the volume. If not then that would explain the failure to decrypt.The size is still exactly as I reported it "1000169275392". I guess this means it isn't decrypting. I am using 4 key files (they are read only) so shouldn't be causing an issue but I thought I would mention it
     
  6. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    1,034
    Location:
    Hawaii
    I'm kind of busy, so I can't reply properly right now. Sorry. I'll try to get back to you soon.
     
  7. zombielove

    zombielove Registered Member

    Joined:
    Jan 9, 2014
    Posts:
    12
    Location:
    United States
    Take your time, I'm going out of town for business. I appreciate your help very much!
     
  8. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    1,034
    Location:
    Hawaii
    I meant compare "1000169537536" to the actual size of your disk. In WinHex, and with the TC volume dismounted, select Tools: Open Disk and select the Physical Media that your volume resides on. In the side panel, notice the Total Capacity in Bytes. How different is that number from "1000169537536"?

    And while you have the physical disk open, scroll ahead to offset 1,048,576 (decimal) and see if a large block of mostly zeros seems to end there and becomes random data from that point downwards. This might be the starting point of your lost partition, if it's in the default location (for Windows versions higher than XP).
     
  9. zombielove

    zombielove Registered Member

    Joined:
    Jan 9, 2014
    Posts:
    12
    Location:
    United States
    Okay Dantz, I will try that when I get back from my trip (Sunday) and let you know what I find. Thanks!
     
  10. zombielove

    zombielove Registered Member

    Joined:
    Jan 9, 2014
    Posts:
    12
    Location:
    United States
    I meant compare "1000169537536" to the actual size of your disk. In WinHex, and with the TC volume dismounted, select Tools: Open Disk and select the Physical Media that your volume resides on. In the side panel, notice the Total Capacity in Bytes. How different is that number from "1000169537536"?
    Total capacity is 1000170586112 bytes

    And while you have the physical disk open, scroll ahead to offset 1,048,576 (decimal) and see if a large block of mostly zeros seems to end there and becomes random data from that point downwards. This might be the starting point of your lost partition, if it's in the default location (for Windows versions higher than XP).No, the random zeros block starts at 512(decimal) and ends at 4080. Offset 1,048,576 seems to be in the middle of random data, but way after the block of zeros

    I am running Windows 7 if that helps...
     
    Last edited: Jan 19, 2014
  11. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    1,034
    Location:
    Hawaii
    I just did the math. 1000170586112 (the disk's total capacity) minus 1000169537536 (size of lost volume plus its headers) = 1,048,576.

    We can assume that your lost partition began at 1048576, which also happens to be the default location for a partition created by Windows 7 on a data disk.

    Go to offset 1048576 (decimal) and create a test file starting there. Make the file approx 2 MB.

    Then use TC to mount the file. If it mounts, use WinHex to open the mounted volume and examine it.
     
  12. zombielove

    zombielove Registered Member

    Joined:
    Jan 9, 2014
    Posts:
    12
    Location:
    United States
    Now, I can see some non-junk data... looks like there might be issues though. Here is what I see

    http://i.imgur.com/jqqbAgv.jpg

    Towards the end of the file I start seeing unreadable sectors

    http://imgur.com/5b1mRWo

    I'm not sure what to make of the data in-between. A lot of it is just characters, here are some highlights of some of the stuff that looks more like words/files...

    http://imgur.com/hWQxjG6

    http://imgur.com/FhUNPnc

    http://imgur.com/sQF9QJ6

    There are still no file names that stand out. Here are the stats to the left in WinHex (in case this helps you)

    http://imgur.com/mPwbKV2
     
  13. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    1,034
    Location:
    Hawaii
    No, you're doing great! The embedded error messages that you saw in the text column (such as "disk read error occurred"), the "UNREADABLE SECTOR" messages in WinHex, and so on are all normal and expected for this situation. I could explain each one of them and how they got there, but I'd rather not spend the time. At this point all that matters is that you've found some non-random data, which means that your header is working and you've located its exact starting point, and most importantly, the small fragment that you copied from the beginning of your lost volume is decrypting. This is great news.

    All you have to do now is use the same technique to create another "test file" that starts at the exact same location, but this time make it large enough to include your entire lost partition. (I guess in your case it should extend to the very end of the disk). If you do it right it will be fully mountable by TrueCrypt, and if you're lucky (that is, if no damage has occurred to the volume's file system) then you will also be able to browse the mounted volume with Windows Explorer and copy off all of your data.
     
    Last edited: Jan 20, 2014
  14. zombielove

    zombielove Registered Member

    Joined:
    Jan 9, 2014
    Posts:
    12
    Location:
    United States
    Awesome! Thank you soooo much! So, just to be clear, I should start at 1048576 and go to the end of the disk? I know you pretty much said this earlier but I just want to confirm the start point. If this is correct, let me know and I will begin the process (it will take a full day or two due to the size)
     
    Last edited: Jan 20, 2014
  15. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    1,034
    Location:
    Hawaii
    Yes. I hope it works!
     
  16. zombielove

    zombielove Registered Member

    Joined:
    Jan 9, 2014
    Posts:
    12
    Location:
    United States
    Thanks Dantz! I will begin the transfer process this morning and in a few days (when it finishes) I'll let you know the result. I might have a few general questions around TC that I would love to ask you should this be successful. I'll post here in a few days.

    Thanks again Dantz for all your help!
     
  17. zombielove

    zombielove Registered Member

    Joined:
    Jan 9, 2014
    Posts:
    12
    Location:
    United States
    Dantz, you rock! :thumb: Got everything back! You saved another TrueCrypt drive! Thank you sooo much for the work you do! Not that you have ever asked for anything but I wish I could give you something for the help you have been. I appreciate it sooo much!

    I have a few questions, just for my personal edification.
    1. How could the drive have gotten into this state? I remember having to force TC to shutdown one time, while the drive was mounted. I think this happened right before this occurred. Could that have been the cause?
    2. Is the old drive safe to use? Could I move the file over there (temporarily) while I encrypt the current drive it is on? Do I need to throw the other drive away? (it is only 6 months old)
    3. Could I just encrypt the whole new drive (with the encrypted file in place)? Would I be able to do that without damaging the encrypted file I now have?
    4. Does the: [the disk's total capacity] - [the size of lost volume + headers] = [starting location of the data] always?

    Thanks again for all your help!!! :D :D :D :D
     
  18. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    1,034
    Location:
    Hawaii
    Congratulations!

    I'll try to answer your questions when I have time, but things are getting pretty busy for me at the moment.
     
  19. zombielove

    zombielove Registered Member

    Joined:
    Jan 9, 2014
    Posts:
    12
    Location:
    United States
    No problem! Take your time and thank you sooo much for all your help! :D
     
  20. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    1,034
    Location:
    Hawaii
    Forcibly dismounting a TC volume would not do this. More likely it was just another case of Windows trying to "fix" a TrueCrypt-encrypted partition (since Windows doesn't really recognize or understand them), and breaking it in the process. This happens more often than you might think.

    The old drive is probably fine. It just need to be reformatted. If you're unsure of the drive's condition, you could always run the manufacturer's diagnostic tests on it, or at least a full chkdsk.

    There's a chance that the endpoint of the file might not be correct, so you should consider your recovered file to be an emergency backup copy of your data, not a permanent solution. If you want to test it to see if it's complete, try mounting the volume using the embedded backup header (Mount Options: Use backup header embedded in volume if available.)

    But even if the file is ok, I wouldn't store in within an encrypted partition. Double (nested) encryption is not necessary and it will only reduce performance. Plus, it doubles the risk of future problems and would greatly complicate a recovery attempt if it became necessary.

    No. Sometimes the encrypted partition ends before the end of the disk, followed by unpartitioned space.
     
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.