Trying to recover truecrypt container on USB drive

Discussion in 'encryption problems' started by FBKSan, Jun 23, 2014.

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

    FBKSan Registered Member

    Joined:
    Jun 23, 2014
    Posts:
    2
    All,

    First time poster, but I've found a lot of great information on the forum, and I'm hoping someone can help me out with my situation.

    I had a truecrypt container on a 16GB USB drive, formatted at exFAT (seemed like a good idea at the time--less sure about that now). Yesterday I did a restart, must not have unloaded the container, and on reboot chkdsk ran. I've had chkdsk run before without issue (I now realize I should have disabled it), but this time chkdsk found some error and completed running. When I opened the USB drive I saw all of my files except the truecrypt container.

    The container was 14GB (exactly, I believe), and it still shows 14+GB used (530MB) free. So it appears the container space is still 'allocated,' but the file doesn't show up. Obviously I couldn't mount the container, either. The other piece of information is that there's now a FOUND.000 folder on the USB drive that contains a ~2GB FILE000.CHK file.

    I started reading about lost truecrypt containers and found myself here on the forum. I have tried recovering the container file, which was (seemingly) successful. The recovery program (Yodot - the one I found that would do exFAT) found the 14GB file and recovered it onto my hard drive. I can mount the file using truecrypt (it asks for and accepts the password), but windows can't open the mounted drive ('corrupted or unreadable'). I also tried restoring the embedded volume header, but when I enter my password truecrypt doesn't recognize the volume (off the recovered file).

    I'm worried the container was fragmented, which is why the recovered file won't mount correctly, even though it looks like it was recovered fine. I haven't made any (intentional) changes to the USB drive. I'm willing to go the WinHex route, but it looks like one needs a fairly advanced version of WinHex to handle exFAT, so I'd love to hear if that's worth trying before I go down that road. Obviously any other ideas are welcome. I do have a 3-month old backup of the files in the container, so all is not lost, but I'd love to get these files back if at all possible.

    Thanks in advance for any advice.
     
  2. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    991
    Location:
    Hawaii
    Yes, it's possible that the recovery was incomplete. It's unusual to be able to use recovery software to recover a lost TC file-hosted container in the first place, as container files have no identifiable signatures. The software must have been working from a backup copy of the extended file allocation table, or something of the sort. (My knowledge of exFAT is limited, sorry.)

    It's also possible that the recovery was complete but that a portion of your TrueCrypt volume's internal file system was damaged by the same event that forced chkdsk to run (i.e. a partial disk failure of some sort).

    But things are not that bad, as you have successfully recovered what appears to be the first fragment of the container, and maybe more. If your password is being accepted and the volume mounts to a drive letter then the TrueCrypt header is fine, as that's all it is used for. It has nothing to do with the actual condition of the volume's file system or the data stored within. All the header does is allow you to decrypt the contents, whatever they are.

    At this point I would mount the volume and then use appropriate data-recovery software to explore the mounted volume. Did you format the mounted TrueCrypt volume as exFAT also? If so then you will obviously need to use data-recovery software that can work with that file system. Try both conventional file-recovery software and data-carving software such as PhotoRec.

    You could also check to see if your recovered file is the correct size. Mount the recovered volume in TrueCrypt and click on Volume Properties. Note the Size of the volume in bytes. This information is stored in the header and never changes, even if the volume becomes "chopped up" for some reason.

    Compare that number (plus 262,144 to include the four headers which surround the data) to the actual size in bytes of the file that you recovered. If the recovered file is significantly smaller than the volume size plus 262144 then there's most likely a piece missing.
     
    Last edited: Jun 24, 2014
  3. FBKSan

    FBKSan Registered Member

    Joined:
    Jun 23, 2014
    Posts:
    2
    Hi dantz,

    Thanks very much for the detailed response and apologies for the slow reply. I followed your advice, but so far haven't had much luck:

    I was using Yodot to recover the volume, and oddly when I mounted the recovered container using TrueCrypt, Yodot couldn't even see the drive. So I abandoned that and moved on to PhotoRec. (I believe the mounted volume was FAT32, but I'm not 100% sure of that.) PhotoRec sees the mounted drive, and I followed the instructions to recover files--without success. I may be doing something wrong, since the recovery process only takes a couple minutes to scan, which seems quick given the volume is 15GB. But in any case, after the scan runs it finds zero files. Again, perhaps I'm selecting options incorrectly.

    I did this check, and the numbers match exactly, which makes me think there may not be any pieces missing. Which is all the more frustrating. It feels like the file name was just somehow erased from my USB drive, with all the underlying contents intact.
     
  4. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    991
    Location:
    Hawaii
    Have you tried any other data-recovery software such as GetDataBack? (Try the Fat32 or NTFS evaluation version, not GetDataBack Free). If you are unable to recover or identify any data whatsoever then you should examine the mounted volume using WinHex (a hex editor) to look for plaintext data of any sort, just to confirm that the volume is decrypting properly. Look for known words, abbreviations, recognizable patterns, blocks of zeros, or basically anything that appears to be non-random.

    PS: Sorry for the late reply.
     
Loading...
Thread Status:
Not open for further replies.