So TrueCrypt does accept the password for hidden volume?
in this case you may want to use utilities like R-Studio or GetDataBack to extract data from hidden volume in full scan mode

The hidden volume is not located at the beginning of the drive, so utilities which try to fix file system may not recognize it however if it mounts to a drive letter then it makes your life easier
Again, use file system extraction tools to get your data off the damaged volume

_________________
SAN, NAS, RAID, Server, and HDD Data Recovery.

TestDisk is complaining about a partition table, not Windows. Without seeing TestDisk's log, my idea was to create a partition table that would make TestDisk happy, to allow it proceed to analyse the file system.

If TestDisk can see the unencrypted Boot Parameter Block in the FAT32 boot sector, then doesn't this mean that the volume has been recognised and mounted by TrueCrypt? Or are these structures normally unencrypted?

I suggested that the OP run CHKDSK in readonly mode, not repair mode. It was purely an investigatory measure, as were all my other suggestions.

_________________
A backup a day keeps DR away.

I would first examine the fundamental components of the file system with a disc editor. These include the boot sector (logical sector 0), backup boot sector (sector 6), first sector of FAT#1, first sector of FAT#2, and first sector of root directory. I would not automatically throw all manner of data recovery software at the problem. I suggest you take your time, get an understanding of the problem if possible, and then decide on the best approach.

Could you take snapshots of the abovementioned sectors, excluding those you have already uploaded?

As for CHKDSK, I wouldn't allow it to "fix" anything.

One other thing to try would be to create a small Truecrypt volume for test purposes and examine its structure. Then see how CHKDSK and TestDisk behave with this known good volume.

_________________
A backup a day keeps DR away.

If you are referring to me, I have not suggested that the OP write anything to the volume other than a dummy partition table.

As for morality, I have only the OP's best interests at heart. I have no financial interest in his data. To this end I offer DIY solutions wherever possible.

Furthermore, before offering suggestions, I suggest that people pay attention to what the OP has written. ;-)

_________________
A backup a day keeps DR away.

I did try GetDataBack for good measure. While I did not go through the entire recovery process, I reached a point where the product identified some FAT clusters and asked for the quality of recovered files to be checked. I observed two things -

1) Only part of the data was identified (perhaps 25% of it)
2) From many hundreds of "recovered" files, not one was readable (including ones from FAT clusters highlighted in green)

This run was done under default settings. I might try again after enabling all RAW / FAT options available in the product. Given that not one recovered file was readable, I really don't know if this will be useful in any way.

I'm also uploading dumps of sectors 6, 32, 51276 and 360944120, if they can help in any way. Thanks for the help.

FAT tables are corrupted or not decrypted
Sector 360944120 has part of FAT directory
So we back to the point where your volume is either corrupted or not properly mounted because of hidden volume header damage

Those sectors you provided their number calculated from the beginning of what? Outer volume, hidden volume or physical drive?

_________________
SAN, NAS, RAID, Server, and HDD Data Recovery.

I notice that Sec360944120.bin has a size of 513 bytes rather than 512. The directory structure appears to have a one-byte offset somewhere before 0x140. I suspect that there is a bug in your disc editor involving the handling of <CRLF> characters, ie 0x0D and 0x0A. It appears that your editor software adds an LF character whenever it sees a CR, or vice versa.



Furthermore, although the sector contains a directory structure, it looks like it is the middle section of a directory, not a root. I say this because there are incomplete long filenames at both top and bottom. IMO it is definitely not a root directory.

Here is a snapshot of the root directory of my Win98SE FAT32 volume:



Notice that the first entry is the volume name, "FUJ_WIN98SE".

_________________
A backup a day keeps DR away.

I notice that there is difference between your boot sector and backup, at byte offset 0x41.

D:\Temp>FC /B sector0.bin sec6.bin
Comparing files Sector0.bin and sec6.bin
00000041: 01 00


In my case, offset 0x41 has a value of 0 in both the boot sector and backup. It appears that TrueCrypt may use this byte for its own purposes.

FWIW, Starman's web site refers to this byte as "Reserved for NT":
http://mirror.href.com/thestarman/asm/mbr/MSWIN41.htm

My Win98SE boot sector looks like this:


I notice that the volume name in your case appears to be encrypted, yet the text strings and Boot Parameter Block are not. That's why I suggested that you examine a known good TrueCrypt volume for comparison purposes.

_________________
A backup a day keeps DR away.

According to the BPB, sectors 32 and 51276 should be the first sectors of FAT #1 and FAT #2, respectively.

In your case, sectors 32 and 51276 are identical, but the following sectors are completely different.

Here is the beginning of sector 32:


IMO, the above does not look like a FAT structure, unless it is encrypted.

Sector 32 of my Win98SE FAT32 file system is as follows:

_________________
A backup a day keeps DR away.

TrueCrypt mounts the hidden volume. It is Windows that cannot recognize the file system. Is this scenario possible if the header is damaged?

These sectors belong to the logical drive created by TrueCrypt for the hidden volume.



I started with WinHex. It wouldn't let me write without a licence. So I switched to Roadkil's Sector Editor.



Well, TestDisk says it is. Possibly the product has only damaged the volume further.



The dump for Sector 0 is from WinHex. Maybe that's why you see a difference. I compared the two sectors - they are identical.



Here's a dump of Sector 0 from a working volume. The offset 0x41 is 00. Does it mean the boot sector of the damaged volume is actually not ok (although TestDisk may say otherwise).

So far FAT tables look either filled with the same pattern (zeros, for example) or not decrypted (because they identical)

I can suggest you to try one thing to test the hidden volume header but it may be dangerous, so make sure you have full copy of the physical drive before trying

If passwords for outer volume and hidden volume are the same - stop right here and do not proceed

In TrueCrypt choose you drive, press Volume Tools and select Restore Volume header. Choose - restore from backup embedded in volume. Provide password for hidden volume (make sure you providing password for hidden volume and not for outer volume)
This should grab backup copy of hidden volume header, decrypt it, encrypt it with new salt and write to working copy of hidden volume header

Try to mount hidden volume again

_________________
SAN, NAS, RAID, Server, and HDD Data Recovery.

Your test volume has a standard looking FAT32 boot sector, although it has a different signature (MSDOS5.0). I don't know if this difference is significant.


There is no partition table, as is to be expected.

The number of heads is 1, and there are 8 sectors per cluster and 1 sector per track as before.

The backup boot sector is at sector 6.

There are two FATs, each consisting of 10240 sectors. FAT #1 begins at sector 32.

The root directory begins at the end of FAT #2, ie at sector 20512.

The volume has no name, but this time it is in plain text.

I believe byte offset 0x41 is probably a red herring, ie it probably has a genuine function that we are unaware of. I'm betting that its value changes while the volume is in use. I merely mentioned the difference because it was there.

You may like to examine sectors 32 and 20512 of your test volume just to verify that they are not encrypted.

As for the patient, if the real root directory is located at the end of FAT #2, then it should be at sector 102520 (= 0xc82c x 2 + 0x20). You may like to examine this as well.

_________________
A backup a day keeps DR away.

Well, I can try this out. It might take a while since I'll need to find 500 GB of free space first. I only have the logical drive imaged as of now.



Sectors 32 and 20512 of the test volume are not encrypted. Sector 102520 of the damaged volume again appears to be encrypted.