Hi,

I have a problem which appears to be a little bit beyond me. And I thought I'd buzz you guys for some help.

Here's what the issue is -

I have a 500 GB Seagate Freeagent disk, which I encrypted on Windows XP using TrueCrypt 6.0. A hidden volume (400 GB) was created underneath the outer volume. The filesystem was FAT32.

All of a sudden, for no obvious reason, the hidden volume is not accessible. TrueCrypt (7.0a) does mount it but there's a message which says that Windows XP does not recognize the filesystem. Data in the outer volume is still accessible. The hard disk also appears to be working within normal heating / sound limits.

I then tried to fix this using Testdisk 6.11. I followed instructions and rebuilt the boot sector. However that has not fixed the problem . Now the message that I get on mounting this volume is somewhat different. It says that the filesystem is corrupted and cannot be read. When I run Testdisk, it says that the boot sector is ok but that the first sectors are not identical . A screenshot is attached.



Testdisk's log file shows pretty much all the top-level directories which were present in the volume before. So I'm keeping my fingers crossed and hope the data can be set right.

So how can I fix this thing? I'd really appreciate it if someone could please help. You'd have a fan for life.

PM sent

_________________
Kuwait Data Recovery - UNIX GTC
The only reason for time is so that everything doesn't happen at once. By: Albert Einstein

This is still open. If any one knows what this Testdisk screen shot implies and how the issue can be fixed, please do let me know. Thanks!

Could you upload a hex dump of sector 0 of the TrueCrypt volume? It appears that sector 0 is both a boot sector and a partition table. I suspect that TestDisk is complaining that the partition table data at the end of the sector don't match the BPB data at the beginning of the sector.

_________________
A backup a day keeps DR away.

Thanks for your reply. I really have no clue about WinHex so I hope I've done this right. Here's the Sector 0 dump of the corrupted TrueCrypt volume. Please let me know if you can spot anything.

As I suspected, the partition table is blank. That is, the drive is laid out as a logical volume rather than as a physical disk, hence no partition table is required.

Your TrueCrypt volume has a FAT32 file system with a sector size of 512 bytes, 128 sectors per cluster (64KB), 2 FATs, 1 sector per track, 1 head, and a volume size of 0x320c8000 sectors (= 429916160000 bytes).

The number of "hidden sectors" is 0, which means that the partition begins at LBA 0, not LBA 63 as in the case of physical drives. That is, LBA 0 is both a boot sector and an MBR (including partition table). I believe this is what may be confusing TestDisk, and possibly other software as well. If so, then there is no real problem here. The actual problem appears to be file system corruption further into the volume.

Nevertheless, to circumvent this annoyance, you could create a partition table by adding the required parameters at offsets 0x1BE through 0x1CD, both in sector 0, and in the boot sector copy at sector 6.

The starting and ending C/H/S values would be 0/0/1 and 1023/0/1, respectively (C is limited to 10 bits). The partition ID would be 0x0B, starting LBA is 0, and size is 0x320c8000.

Therefore I would edit the boot sector as follows:



If TestDisk still complains, then use a max C/H/S of 1023/255/63:



Note that you must also change the backup boot sector at LBA 6.

If the above doesn't work, then you can always restore the original boot sectors using your uploaded file.

References:

An Examination of the MSWIN4.1 OS Boot Record:
http://mirror.href.com/thestarman/asm/mbr/MSWIN41.htm

MBR/EBR Partition Tables:
http://mirror.href.com/thestarman/asm/m ... Tables.htm

_________________
A backup a day keeps DR away.

Here's what I did.

I first edited sectors 0 and 6 using Roadkil's Sector Editor based on the first suggestion (C/H/S 0/0/1 and 1023/0/1). TestDisk continues to display the same message and Windows says that the filesystem is corrupted. I'm attaching TestDisk's log just because I noticed something about a couple of invalid arguments. Don't know if it's relevant in any way.

I then edited sectors 0 and 6 based on the second suggestion (C/H/S 1023/255/63). The result was the same.

Please let me know if you have any ideas.

Have you tried selecting "Intel/PC Partition" rather than "Auto", after editing the CHS values?

I notice the following error in your TestDisk log:

"FAT differs, FAT sectors=0-16/51244"

A FAT32 file system maintains two copies of the File Allocation Table. If they are not identical, then the file system is corrupted. I believe the error message is telling you that there are differences in sectors 0-16 of the FATs. If that's the only problem, then that's normally an easy fix.

TestDisk locates the two FATs at the following ranges of sectors:

FAT1 : 32-51275
FAT2 : 51276-102519

Therefore, sectors 32-48 and 51276-51292 would be the ones to examine.

You could copy each group of 17 sectors to a file and File Compare them in a Windows DOS box:

FC /B FAT1_32-51275.bin FAT2_51276-102519.bin

_________________
A backup a day keeps DR away.

I tried selecting "Intel/PC Partition" - the results are the same.

I did a file compare of Sectors 32-48 with Sectors 51276-51292. The data differs. So what should I do now? Should I copy the data in Sectors 32-48 into Sectors 51276-51292? And vice-versa, if this does not work?

I'm assuming Sectors 0 and 6 would still need to be edited like you suggested in the first place.

Sorry, I'm out of ideas. I'm just encountering this problem for the first time.

I don't understand why TestDisk's log is showing that the partition type is automatically detected as None, whereas TestDisk complains that the information in the boot sector and partition table are different.

"First sectors (Boot code and partition information) are not identical."

Perhaps you could contact the author. Apparently he is very interested in feedback.

I would examine the file system a little more before doing anything. Try comparing sectors 49 and 51293. They should be identical. Then compare the appearance of these known good FAT sectors with the problematic ones. This may tell you which FAT is the likely culprit.

If you do decide to patch the FAT sectors, I suggest you leave the partition table empty.

Have you tried any other data recovery software?

One more thing. TestDisk's log states that ...

"A valid FAT Boot sector must be present in order to access
any data; even if the partition is not bootable."

I can't see anything that is invalid about the boot sector. TestDisk also appears happy with it.



The only thing that is different is that the volume name is encrypted, and the first two bytes (EB 32C) don't make sense. Normally these two bytes constitute a JMP instruction which jumps around the data in the Boot Parameter Block and ends up in the code area. However TrueCrypt's JMP instruction points to offset 0x3E which is in the BPB. While this is odd, it has no bearing on your problem (since the volume is not bootable).

_________________
A backup a day keeps DR away.

with only the boot sector is not so easy to diagnose...
what I see is that there are 32 reserved sectors, so perhaps you should shift using that value.

FAT1Start = ResSect x ByteSector
FAT2Start = ResSect x ByteSector + NumSectorFAT x ByteSetcor
DataStart = ResSect x ByteSector + NumFAT x NumSectorFAT x ByteSetcor

From DataStart you should have the cluster 0: moving 2819077 ahead you should find the ROOT directory.

Try with sleuthkit too.

regards,
fpi

@fzakbar: I agree that the file system should be examined more closely. But isn't that what these tools (read TestDisk) are supposed to do Btw, I did check out sectors 49 and 51293. They are identical.

I haven't actually tried any data recovery software. TestDisk itself comes with PhotoRec, which I haven't used. I've just tried to fix the data in situ. I'm out traveling for a week. So I probably won't be do anything else right away. Once I'm back, I'll try to copy Sectors 32-48 into Sectors 51276-51292 and see how that works out.

@fpi: I'm sorry I didn't really get you. Were you suggesting how I could find the Root directory? Actually TestDisk does locate the Root directory. But that obviously does not help in it fixing the problem. I'll give Sleuthkit a try if the copy-paste fix does not work. Thanks.

How did you work that out from the Boot sector ? It was the boot sector that the user put in the dump, unless there is another dump I havent seen. I suppose you could assume that the Partition Table is empty, but it is safer to look at that first if it exists.

This is a strange Boot sector as offset 1Ch shows 00 hidden sectors, I would have expected to see 3Fh in here.

OP: Can you put a dump of sector 63 here ?

Ahhh .. Just seen it is a truecrypt volume ... whoops

_________________
If you can keep your head when all about you are losing theirs, you probably don't fully understand the situation. ... Mr Kipling

https://www.mjm.co.uk/

I always like to examine the file system prior to letting any software loose on the drive, especially when the volume is a non-standard one. If you can understand the nature of the damage, then often a manual fix is possible. IMO, automatic fixes are always dangerous. For example, I have seen cases where something as apparently innocuous as Microsoft's FIXMBR or FIXBOOT has trashed a filesystem.

Before writing to the drive, it may be an idea to run CHKDSK in readonly mode.

You may also like to examine the first sector of the root directory, 360944120 (TestDisk's start_rootdir). Is it encrypted, or can you see the file names in plain text?

_________________
A backup a day keeps DR away.

The fact that there are 00 hidden sectors rather than the usual 63 means that there is zero offset between the boot sector and the MBR, ie they are located in the same sector.

See this thread which examines a similar arrangement for a customised FAT32 file system in an Akai MPC2000 audio sampler:

http://forums.seagate.com/t5/SCSI-drive ... td-p/37618

_________________
A backup a day keeps DR away.

The 32 sector offset is accounted for in TestDisk's log. That's where I obtained the FAT information.

_________________
A backup a day keeps DR away.

Sorry, I was out travelling and was not able to attend to this.

First, I was mistaken earlier. Sectors 49 and 51293 are, in fact, not identical. So I figured there was no point in patching Sectors 32-48 into Sectors 51276-51293. The entire file system is probably messed up

What I did was to run CHKDSK in read-mode. The log was pretty large. So I cut out what I thought were the relevant (and non-repeating) sections. Here's what I noticed (not that I know anything about these things):

1) Files in the root sector are said to have non-valid links
2) Messages about orphans being truncated are repeating throughout the log
3) Only 10,944 KB of data is identified (there was around 250 GB of data in that drive)



So what I'd like to know is:

1) Should I execute CHKDSK in write mode? (I have a feeling this will not lead me anywhere though)
2) Is there a way which will identify clearly which sectors are ok and which are not? If there aren't too many blocks of bad sectors, I could try editing manually.
3) Should I abandon any attempts to fix the file system? If you could suggest an appropriate data recovery freeware, I'll grab whatever I can and just format the drive.

1. the MBR aka Partition Table is not necessary for Windows to recognize the volume if Boot sector located at sector 0
MBR is only needed if you want to boot from this drive
2. True Crypt hidden volume should have its own header. If this header is damage then TrueCrypt won't see the hidden volume. The hidden volume header has to be located at offset 0x10000 (or sector 128) from the beginning of the drive. It is encrypted by hidden volume user password. If it's damaged you can tell TruCrypt to try to use second copy of hidden volume header which located almost at the end of the volume. Passwords for outer volume and hidden volume usually different
If both copies of hidden volume header are damaged - you will not be able to recover data from hidden volume (it's called cryptographic erasure)
3. If you keep running chkdsk then your chances to get your data will be very low
4. Generally you should not run chkdsk or store big files on outer volume because this may overwrite or damage hidden volume (I guess that's what happen) that's why TrueCrypt hides free space of outer volume when you create hidden volume
5. I suggest you to stop experimenting on live copy

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

There are some people here who may look very confident with their suggestions but actually not experienced in what they suggesting and have no moral problems to gamble with your data
You may want to consider that before following their suggestions

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

Well, I do not think TrueCrypt's headers are damaged. From what I understand, if they were, TrueCrypt wouldn't mount the volume in the first place.

I do have an image of the corrupted volume. I do not know what precautions to take beyond that.

The way I see it is this: any suggestions are better than no suggestions. I obviously tried the TrueCrypt forum first, where nobody even replied. That's okay - it's freeware and they don't *have* to support a user. I appreciate that users here are at least giving it a thought. There are many like me who are not IT folks - there's no way we can fix problems of this nature unless you guys help us. So any suggestions are welcome. I'd rather try something than to hope the volume will automagically spring to life.