TrueCrypt Volume Mount yes Open no

I am running a windows xppro 64 bit machine with two internal drives C: and D: Both drives have xp pro os installed. This is not a raid system.

The machine boots in C:. From there I created a Standard Truecrypt volume in D: Using TrueCrypt 6.0a I started by using Create Volume then Create an encrypted file container then Standard TrueCrypt volumn. I then created the volume in a folder on drive D:.

I had no problem mounting and opening the volume until I tried to create a shortcut to the volume file in drive D:. In doing so I somehow damaged the volume header (according to the pop up msg.). The volume file name also changed from text to a numerical
(1705338555).

I used restore volume header in the tools menu following the pop up msg suggestion.

The volume now appears to mount (The Dismount button enables) but it will not open. I have tried to open by right clicking the
volumn and choosing open and through windows explorer but a message opens saying: "the disk in drive Y is not formatted. Do you want to format it now?"

I have clicked the Yes button in that window which leads to the actual format window. But that is where I have stopped.
It asks if I want to Format and has options of quick or normal format.

What should I do at that point? I do not want to lose access to these files. Some of them are not backed up anywhere.

 

It sounds kind of strange. I'm not sure what happened, but something has apparently damaged your volume's filesystem such that Windows can no longer recognize it, hence the offer to reformat (DO NOT format the volume or you'll lose everything!) Since the main header stopped working at the same time, it sounds like a portion of the beginning of your container file was overwritten. However, the end of the file is still intact, otherwise the backup header would not have worked. I wouldn't expect this sort of thing to happen when creating a simple shortcut. Did you do something unusual? It's also very strange that the filename changed on you during shortcut creation. Is the file still the same size as the original? Could this somehow be related to your dual installation of XP?

Anyway, whatever happened, the first thing I would do is immediately make a backup copy of the unmounted container file. Then I would mount the backup copy and explore the volume using a hex editor such as WinHex or a data-recovery tool such as GetDataBack to see what can be recovered.

 

Dantz, Thank You for your reply

I don't think this is related to the dual os. I had accessed the TC container files many times with no problem.

The problem occured when I made the shortcut. This is what I did: Using windows explorer I navigated to the file, right clicked it
and selected 'send to desktop (create shortcut)'. I am sure that is what I did because a shortcut was created and named 'Shortcut to File name' as usual. However, when I clicked it to go to the actual file the name of the original file was changed to numeric. I then tried to mount the file and got the damaged volume header msg. I then used the restore tool and was able to mount the volume but unable to open it.

OK, so when you right click a mounted volume one of the options is 'check file system'. I just tried that on the problem volume and
I think I know what the problem is now. The 2nd line says 'The type of the file system is RAW.' and the next line says CHKDSK is not
available for Raw drives. The check disk stops there.

So, I ran the 'check file system' on a working volume which on line 2 says 'The type of the file system is FAT32.' However, it goes on to read the disk verifying files and folders and reports that there are no problems with the file system.

So it seems I need to restore the file system type to FAT32 somehow. Any Ideas (Why would they use FAT32?)

I am going to try to recreate the scenario on a 'dummy' volume and see if the 'repair file system' (another option when right clicking on a mounted volume) will work. Just have to figure out how to damage the volume header.

I will post the results.

 

"Check file system" merely runs Windows chkdsk on the mounted volume. So does "Repair file system".

In most TrueCrypt versions, FAT is the default filesystem, but you have your choice of several filesystems when you create each volume. Many users choose NTFS, although FAT is more popular among those who create hidden volumes.

Any attempt to restore your filesystem will probably result in severe dataloss. Data-recovery tools are designed to recover data from damaged filesystems and they should be tried first. Of course, all work should be done on a copy of the file.

 

Long story short:

Created small TC test container (FAT12), added test data.
Using a hex editor, deliberately deleted the file allocation tables and a bit more.
Volume mounts, but Windows offers to format during access attempts (declined).
Ran GetDataBack for FAT on the logical drive.
Was able to locate and recover most of the data.
Ran a Quick Format on the volume.
Was still able to locate & recover some data, but not as much.
Ran a Full Format on the volume.
Still able to recover some data. Sorry, I lost count of the files.

Suggest you go to runtime.org and download the demo version of GetDataBack for FAT (or whichever version is appropriate) and try it on a copy of your damaged container. Please report back and let us know your results.

 

Volume mounts, but Windows offers to format during access attempts (declined).
Ran GetDataBack for FAT on the logical drive.
Was able to locate and recover most of the data.
Ran a Quick Format on the volume.
Was still able to locate & recover some data, but not as much.
Ran a Full Format on the volume.
Still able to recover some data. Sorry, I lost count of the files.

Suggest you go to runtime.org and download the demo version of GetDataBack for FAT (or whichever version is appropriate) and try it on a copy of your damaged container. Please report back and let us know your results.

I had the same problem being unable to open the Hidden Partition after changing the password on the the Decoy Partition. I took your advice and copied the file with that drive to an external drive, installed GetDataBack for NTFS on a separate computer, plugged in the external drive, mounted the Hidden Partition without a problem using the correct password, and used GDB to analyze the file and it identified the name of the file which holds my files but not the files within it.

What procedures should I have been following to be able to examine the individual files within the Hidden Directory?

 

I'm a little mixed up by your description, as you seem to be using non-standard terminology. I'm not clear whether you're using a Decoy Operating System or you are merely describing outer and hidden volumes.

If you're trying to recover a hidden volume, I'm guessing that you did not point GetDataBack to the correct drive letter. After you mount your hidden volume to a specific drive letter, start GetDataBack and make sure you tell it to analyze that same letter. (Select "Logical" volume, not physical).

PS: Does the external drive use a USB interface? GetDataBack runs much better when the target is on an internal drive. If possible copy the file back onto your computer, if it will fit, and analyze it there.

Perhaps you can try to describe your situation again in better detail. Anyway, hope this helps.