Need to locate my truecrypt volume header

I have a drive that died. It suffered from a headcrash. The entire drive just had a single partition on it which was encrypted with truecrypt. I sent the drive to a data recovery company and they changed out the hardware and recalibrated the heads and such to start reading data. The problem is, they don't have the ability to see if they're getting real data off the platters or not because the whole thing is encrypted. I'm not sure how to handle this, because I don't have a copy of the volume header. I had them send me a chunk of data from the beginning of the drive, but this chunk isn't able to be mounted as a "file" in truecrypt with the correct password and keyfile. I'm assuming this means that the volume header isn't the very first thing at the beginning of the file, probably because the volume header wasn't stored there or the chunk they sent me wasn't from the beginning. I'm also reading that the header is stored at the end of the first logical track on a drive. Does this mean it's stored at the end of the partition? If so, then where is the backup copy?

What do I do? Is there a way to figure out where the backup header is or the main header is based on the geometry of the drive and where the partition would have been? How do I calculate this? If not, I suppose someone could create a program to scan a file and try every offset assumed as a header, take the input password and keyfile, and attempt to decrypt data in each iteration. If the header is anywhere in there, it could find it and I could use it to decrypt the raw that's on the drive.

If I figure out where the volume header is, and I get them to send me a block that contains it, I should be able to write it to the beginning of my test file and mount it, correct? I seem to be reading that file based containers store it at the beginning.

I was thinking of having them dd the entire drive to another one and just send it to me, but there's no guarantee I'm going to get anything if the data isn't cloned correctly to the new drive or the header is stored somewhere else.

Suggestions or thoughts?


Thanks for your help in advance!

 

The first thing is to be SURE which type of encryption you used (entire device vs partition), as it makes a big difference here.

1) Some users begin with a RAW (unpartitioned, unformatted) disk and encrypt the whole thing. Call it "entire device" encryption. In this case the entire disk will be filled with random-appearing data from start to finish. (When it's mounted to a drive letter and is in use the user will often consider it to be a large partition.) In this case the volume header begins at the very beginning of the physical disk, but it blends right in with the other encrypted data, so you can't identify it merely by looking at it. (There are ways to test for it, though.) If the volume header has been damaged then the embedded backup header can be used instead. In this case it's located a specific distance backwards from the very end of the physical disk.

If you used entire-device encryption then the data-recovery effort should ideally find that the entire disk is filled with encrypted data from start to finish, with no anomalies or plaintext of any sort.

2) Many users begin with a disk which has already been initialized and partitioned, and then they encrypt the existing partition (or partitions, in some cases). Often they begin with a disk that contains a single, very large partition. In this case it is a very common misconception for users to think that they have encrypted their entire disk when in fact they have merely encrypted the one large partition on the disk.

In this case the areas before and after the partition will still be viewable as plaintext, so the MBR, partition table, etc. at the head of the disk, and the unpartitioned space which is usually at the end of the disk, should be easily identifiable. The partition itself will be completely filled with random-appearing (encrypted) data, and the volume header will be located at the very beginning of the partition.

In this case, if the data-recovery effort has succeeded then the unencrypted areas before and (usually) after the partition should be plainly visible.

So - which is it?

No, that information only applies to the setup for an encrypted operating system, not a partition or a disk which merely stores data.

Yes, this could be (and has been) done, but I doubt if it will be necessary. If you encrypted a pre-existing partition that was created in one of the default locations then you should look at those locations first. Older (XP etc.) systems usually begin the first partition at offset 32256 (decimal), whereas newer (Win7 etc.) systems often use 1048576 (decimal). And either way, if the recovery was successful then the partition table would hopefully be intact and it would already be showing this (assuming you used partition encryption, that is).

 

Hi dantz,


Thanks for the response. I am confident I had a partition (probably unformatted when I created it, without a filesystem, or if it did have a filesystem initially, that would have got blown away after crypting the partition). This partition was encrypted itself, not a file on a filesystem, or a partitionless drive that was encrypted from the very beginning. This means that there should be an MBR, partition table, and clear delineation as to where the encrypted data starts at the beginning of the drive.

Thank you for the offsets. I was searching your other posts for them. I actually think it was partitioned with Windows XP, which would mean that the partition should start at 31kB into the drive, or 32256 bytes after the very start. There should be some zeroes right before the data starts if I'm not mistaken.

Right now, I don't have a good dump from the company that shows any zeroed data in the beginning of the drive, so the dump must not be from the beginning.

Couple of questions.

1) If I do find the suspect header, since the header contains fields that are of variable length due to differences in key type, configuration, etc, how much data from the beginning should I copy to get a good snapshot of it? We'll call this X amount of bytes.

2) Since the data is all encrypted in CBC mode, shouldn't I be able to take any random amount of data from the drive, overwrite the first X bytes of the random dump with the header content and then mount this as a file?

3) Does the partition have a backup at the end of the partition minus 128KB or minus 131072? Aside from system encryption, is it always the end of the block device minus those offsets ( disk, partition, or file ) ? I'll need this backup if I can't find the initial copy at the beginning, and it should be easy to see where the partition ends in WinHex where data stops at the end of the drive.

4) What can I use to scan a dump to look for a signature of the partition table or MBR? I tried a couple of off the shelf utilities, but I can't find a good way of doing it. Scanning myself in hex would be easier.

As far as the scanner goes, I was just thinking worst case scenario. It would be nice to scan , try the decrypt with the offsets, and look for that encrypted TRUE string in the iteration of the scan. That would be tell tale of having found the header. The reason I asked was because it would save me a lot of time having to write the program to do it.

At this point, I don't have a clear answer as to where the data they sent me came from. They haven't answered my questions and haven't been straightforward about it. I have a feeling it wasn't from the beginning of the drive though, because there are no zeroes at all in it which is what it would look like if there were no partitions involved at all ( and in which case, truecrypt would be able to at least unlock and mount the file given the correct key information ).


Again, thanks for your time. I appreciate your experience with this platform, your posts have saved me a tremendous amount of time of research in understanding exactly what the code is doing when I click on the mount button.

 

Maybe this could help ?
http://16s.us/TCHead/faq/

 

Interesting program. While it doesn't do what I need, it's a damn good start and could work with some modifications. If you'll look at this code, the program supports changing where the header is if we're doing system encryption or a hidden volume, but assumes the header is at the beginning if not. I added a few comments


if ( system_volume )
{
if ( !hidden )
{
src.seekg( 31744 ); // apparently the header position for system encryption
}

else
{
std::cerr << "--hidden may not be used with --system\n";
return 1;
}
}

if ( hidden )
{
if ( !system_volume )
{
src.seekg( 65536 ); //standard hidden volume header info position, this many bytes from the outer header
}

else
{
std::cerr << "--hidden may not be used with --system\n";
return 1;
}
}

src.read( full_header, full_header_size ); // this is where we just grab the header regardless of where we are in the stream



I could just add a wrapper to loop through the stream, and have it try the password at every location, but this doesn't support keyfiles yet. I'd have to add that first since my drive used a keyfile as well.

 

I'm surprised they didn't tell you exactly where the data was copied from. Anyway, the most important area would be the very beginning of the physical disk, so I'm sure they would focus their efforts there. Make sure they know that there should be a normal, plaintext MBR and partition table, followed by a number of empty sectors, as usual. There won't be any encrypted data until they reach the starting offset of the partition. (If they're not finding plaintext data at the very beginning of the drive then maybe they need to try it with different head alignments or something like that. I'm not sure what sort of techniques they use.)

To test the header alone, all you really need is its first 512 bytes, plus some padding so that the test file will exceed the minimum size of a TC volume, which for our purposes is around 20KB or so (roughly). However, you will probably also want to test for your data, so I'd grab several MB at least, 5 or 10 if convenient. (I've described the entire technique in some other threads on this forum.) If the test file mounts, and if you are able to see some plaintext (with a hex editor) inside the mounted volume, then you're off to a good start.

It's not in CBC mode unless you have a very old version of TrueCrypt. All recent versions use XTS mode, and all encrypted data must be located at the correct distance from the header or it won't decrypt. So no, you can't do it the way you described. But if you are able to find the working header on the disk then you already know where the rest of the data belongs. Just keep it in the order that it's in now. Copy the known good header and a good large chunk of the data that follows it and save the whole thing as a file.

If you don't have a partition table to work with then it can sometimes be hard to find the ending offset of the partition, but you can always poke around for it. Assuming that you had the default "maximally sized" partition defined, look for a large, contiguous block of encrypted data that ends (and is followed by a block of zeros) quite near the end of the disk (sometimes within a few MB, although it varies.) A relatively efficient way to search for the transition point is to place your cursor inside the large block of encrypted data, somewhere near the end, and then use WinHex (or similar) to search forward for a block of zeros. If you find it, then go back 131072 from the end of the encrypted data to place your cursor at the beginning of the embedded backup header. (Actually, you would go back 131071 bytes if you start with your cursor on the last byte of the encrypted data.)

It's easiest merely to look for it visually at the beginning of the physical disk. Do you have reason to think that it might be elsewhere? If so, I suppose you could search for some common MBR or partition table code. Look at some appropriate examples, there are plenty of them online. You could also search for text. Typically the MBR code contains embedded error messages such as "Invalid partition table", "Error loading operating system", "Missing operating system", followed by the partition table. The sector's last two bytes are "55 AA".

You shouldn't have to write a program that walks the drive looking for the header, or at least, not yet. First you need to get your hands on a reasonably-sized chunk of recovered data that starts at the very beginning of the physical disk, or barring that, from the very end of the physical disk. Then you can look in the obvious places for the volume header (at the partition's starting offset) or the embedded backup header (a specified distance back from the partition's ending offset, if you can find that). If there is no valid, recovered data available from either of those locations then you won't have a copy of either of the headers and thus you won't be able to access your encrypted volume anyway.

 

Well, it turns out the dump they went me was from sector 63 and beyond. This is exactly where the header should start if my math is correct. The partition showed up as a FAT32 partition in their diagnostic software and they sent me a screenshot showing the contents of the 63rd sector, which were the same bytes in the beginning of the file.

512 bytes per sector * 63 sectors = 32256 bytes. I'm not sure if this means the first byte of the 63rd sector is the start of it or the first byte of the 64th sector is the start of it, but I tried deleting the first 0x200 bytes off the file and I'm still unable to mount.

I have asked for the first 200 sectors of data to see where that gets me, but I have a feeling it's not looking good. What doesn't make sense, is that if the partition table is still in tact and showing a FAT32 partition, then the data should still be good. Just because it's marked as FAT32 partition in the table probably means it was originally formatted with a FAT32 filesystem starting with sector 63, and then it was overwritten with truecrypt data later.