Truecrypt container problem

Discussion in 'encryption problems' started by miserify, Apr 16, 2013.

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

    miserify Registered Member

    Joined:
    Apr 16, 2013
    Posts:
    5
    Hi everybody,

    I have been searching a solution for this issue for last couple of weeks and it seems like this is the right place to ask a question.

    I have a 30 GB truecrypt file container. I was moving to another computer and after I copied my container to a usb disk, it won't mount the disk anymore.
    I think when i was copying the disk it might have been mounted.
    I tried the internal backup header but no success.

    I have seen dantz provide guidance to others about the fully encrypted HDs, but I am not sure if this works for file containers. I tried to extract the header from sector 62, but it didn't work.

    I would really appreciate if you can help me.

    Thanks,
     
  2. dogbite

    dogbite Registered Member

    Joined:
    Dec 13, 2012
    Posts:
    1,166
    Location:
    EU
    I would proceed as follows (please mind that I am not an expert on this, others more experienced might give you better info):

    1. Mount your TC container on the HDD.
    2. Create a 30GB new TC container on the USB
    3. Copy all files from the TC mounted container on HDD to the mounted container on the USB.
    4. Clean/wipe all with Privazer or another cleaning software.

    This is also the way of backing up files according to TC:
    http://www.truecrypt.org/docs/how-to-back-up-securely

    This should prevent problems of copying the container when unmounted.
     
  3. miserify

    miserify Registered Member

    Joined:
    Apr 16, 2013
    Posts:
    5
    Hi dogbite,

    Thank you for the advice. I wish I knew that before.
    I just copied and pasted the whole container already and it is not mounting any more.

    When I try to mount, it is telling me the password is wrong. Most probably the header part is either miss-placed or corrupted. I know dantz was suggesting to get the header from sector 62 for encrypted drives, but I don't think it is the case for the containers.

    Is there any other method to extract the header from the container?
    Or should I try another approach?

    Please advise.
    Thanks.
     
  4. dogbite

    dogbite Registered Member

    Joined:
    Dec 13, 2012
    Posts:
    1,166
    Location:
    EU
    is the original container also corrupted? Or the USB only?
     
  5. miserify

    miserify Registered Member

    Joined:
    Apr 16, 2013
    Posts:
    5
    I am sorry, I wasn't clear before. :)
    Two copies as well as the original one are corrupted.
     
  6. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    993
    Location:
    Hawaii
    Partition-hosted volumes are a special case because TC uses the partition boundaries to locate its headers, and users will sometimes accidentally alter the partition boundaries or delete them entirely, thus "losing" the headers as far as TrueCrypt is concerned.

    Container files are much simpler. The headers are stored inside the file, and when these files (or any other files) are copied, Windows normally ensures that they remain intact without any changes to their contents, their size or anything else.

    Hence, the headers on file-hosted containers don't tend to become lost. The volume header is located at the very beginning of the file, and its first 512 bytes (which normally appear to be entirely random) are crucial. If any of those bytes becomes altered then your password will not be accepted. Likewise, the embedded backup header begins 131072 bytes back from the end of the file, and its first 512 bytes must also remain intact or it will reject your password. If you have a hex editor, look at those locations and see if there is any non-random data that would indicate damage to the headers.

    You state that both the volume header and the embedded backup header stopped working. Did the file size change as well?

    PS: Copying a container file while its volume is mounted is a known way to corrupt the volume, but I haven't personally tested that scenario and I don't have any specific details on what will happen. I do know that Windows will normally prevent you from copying a mounted volume, but I have also heard that certain third-party tools are able to circumvent Windows and can still perform the copy, thus damaging the volume.
     
  7. miserify

    miserify Registered Member

    Joined:
    Apr 16, 2013
    Posts:
    5
    Hi dantz,

    Thank you for your reply.
    The container size was set to 30 GB initially. I opened the file in a hex editor and checked the bytes. There were 32212254720 bytes ( 30 GB). So size-wise nothing was lost.

    I went back 131072 bytes from the end, which was 32212123648th byte of the file and looked at the back up header. Here is the screen shot.

    http://i36.tinypic.com/2la6mnm.png

    Also here is the first 512 bytes of the file.

    http://i33.tinypic.com/23a89h.png

    Either they don't really match each other, or I am doing something wrong.

    I have really important documents in the container. Is there any thing that I can do to save this file? Thank you for your time dantz.
     
  8. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    993
    Location:
    Hawaii
    The headers aren't supposed to match. Thanks to TrueCrypt's major focus on deniability, every header is unique and is designed to look totally random.

    Upon casual inspection your headers appear to be ok. (The first 512 bytes are the only part that matters). That doesn't prove that they are ok, it merely means that I can't see what (if anything) is wrong with them. A single wrong byte is all it would take to break the header, and there's no way I could spot such a small error, if it even exists. For that matter, the headers are also indistinguishable from the data, so you can't even tell what you're looking at. All you can do is assume those are the headers based on their location.

    I guess some testing is in order to see if large files are being corrupted when they're copied to your USB drive. (But don't use the drive that has the TC volume on it for testing, as this might reduce your chances of recovery.) Maybe we should test that scenario to see exactly what happens. They don't have to be TrueCrypt files. Try zip files. Or any type of files, while comparing hashes of the source and the target.

    However, it would be weird and unexpected for the source file to be corrupted along with the target, unless that is you copied the file while the TC volume was mounted.

    Are you certain that your password is correct? Have you changed keyboards or keyboard layouts?

    Was the volume mounted when you copied the file? (If you used Windows to perform the copy then it probably wasn't).

    Do you have any other copies of the container file, even an old copy?
     
  9. miserify

    miserify Registered Member

    Joined:
    Apr 16, 2013
    Posts:
    5
    Hi dantz,

    Sorry I couldn't answer quickly.

    This is a container that I was using daily basis. There is no way I can forget the password. And the keyboard configuration is the same, and I used the show the password option to see if I am entering correctly.

    Recently I moved to a mac, and I was trying to transfer everything in the container to mac. I was using a third party explorer replacement to copy the container. I need to go back and see if I can mount and copy at the same time with that software. Unfortunately I don't have a back up of it.

    What do you recommend to test? I will first try to create another test container, mount it and try to copy at the same time. And see if it changes after the copy-paste process is completed.
     
  10. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    993
    Location:
    Hawaii
    That sounds good. And I'm really not sure what else to recommend, aside from testing similar scenarios in an attempt to figure out what exactly happened.
     
Loading...
Thread Status:
Not open for further replies.