Corrupted TrueCrypt Partition

Thank you for the compliment! While most of the credit goes to dantz, I am happy to help. I assume you had a similar problem? Be free to explain.

 

No, I've never had such a problem. But it's a fear, and so it's good to know how to proceed. Few of the TrueCrypt problems posted here have turned out well.

 

Rakoen, once your data is safely backed up I suggest you try mounting both volumes using the embedded backup headers (TC Mount Options: Use backup header embedded in volume if available). If the headers fail, as seen by the "Incorrect password or not a TC volume" prompt, it's probably because the ending offset of the new partition is not exactly the same as the original (lost) partition. TC finds its embedded backup headers by looking backwards a specific distance from the partition's end.

You don't actually need the embedded backup headers, especially if you've already made an external backup copy of your headers (saved in a file), but it never hurts to build greater redundancy into the system. The easiest way to get them working again is merely to restore the headers from your external backup file. You can even save a fresh set of external backup headers into a file and then restore those backups right back into your volumes. This is probably the safest way to do it, as this guarantees that you are restoring the correct headers.

However, there is one remaining issue that won't be fixed unless you start completely over: The size of the outer volume, as listed in the TC Properties screen, will be incorrect. I'm not sure just how serious this is, or whether it will cause any problems, as I haven't played with that scenario much. You saw a little bit of what could happen when you opened the test file in WinHex and saw several error messages because TC was passing the wrong virtual volume size to WinHex. I also suspect that a little bit of the outer volume was chopped off at the end when we created the new partition, which means that certain filesystem backup features might not be there anymore. To avoid these unknown potential problems I'd suggest re-doing the entire setup by wiping the disk, creating a new partition, encrypting it from scratch and then copying your data back in.

 

[SOLVED] Corrupted TrueCrypt Partition

Both embedded headers give a "incorrect password or not a TC volume" prompt. However, I've restored the headers from my external backup file and everything is working again as before (the file on the outer volume isn't even damaged). So, thanks again. Seems like everything is fixed. My backup is done and I'm going to format my entire physical disk now. A possible cause of this issue is the combination of TrueCrypt, the virtual driver and Comodo Firewall. They probably had some interference while working together.

EDIT: As of july 26th of 2012, I still didn't have any issues. It seems like this is completely solved. Thanks again.

 

Hello. First I would like to apologize for hijacking/digging up this thread and I would also like to compliment you on some great posts. Now to my problem...

Almost the same thing has happened for me. i.e. I can mount the disk but it shows up unformatted. The troublemaker is an internal ATA disk that's gotten quite old but has worked flawlessly until now.
I followed your step-by-step advices (with eval. winhex) and managed to mount the test file when using 32256 as start block. Using winhex, I tried to find any plaintext or zeroes but failed. At first there's only lots of random data (decrypted?) but after a while (offset 68608 ) all I get is UNREADABLESECTOR. Do I get this because of the encryption or is my disk dying at last? What should I do next?

Thanks in advance, any help is greatly appreciated!

 

You're seeing this when you look at the mounted volume that's based on the test file, not just the test file itself, correct? In WinHex, you have selected the logical drive letter of the mounted volume? (I assume you have, otherwise you probably wouldn't be seeing those 'unreadable sector' messages, which are artifacts of the test methodology and as such can be ignored. (TC merely passes the wrong volume size to WinHex, and as a result WinHex expects to find more data beyond the actual end of the truncated volume.)

I guess I'd have to ask whether or not you restored a backup header onto the test file after you created it, or anything like that. If not, if you merely selected a block from 32256 through xxxxx, saved it as a file and then used TrueCrypt to select the file and mount the volume within it, then you have obviously copied your intact original header from the disk, and thus your nearby data would also be expected to be intact (although you never know). You should be seeing some decrypted data, especially near the front of the volume. However, sometimes plaintext looks a lot like encrypted data, depending on which particular data you're looking at. Did you try doing the WinHex search for short strings of zeros (00 hex) that I described in one of my previous posts? And did you also try that same test on an ordinary (non-encrypted) area of your drive to make sure you're doing it correctly?

If you tried that and the data within your mounted volume still appears to be completely random then I guess you'll have to provide more details so we can figure things out.

 

Sorry to hijack back my hijacked thread, but something very interesting just happened.

I was at a LAN some days ago and suddenly my computer had a blue-screen. I tried to reboot and it failed at the point where the bios scans for SATA-drives. When trying some things my computer suddenly booted again after messing around with the SATA-cables.

Now I thought it was a good moment to investigate the problem. I checked what changed and noticed that SATA1 is unplugged, the cable that I used for my 3TB disk before which had the corrupted TrueCrypt partition.

The first thing I've checked was if my TrueCrypt partition still worked and no, it didn't anymore. So I thought, no problem, I'll just follow the same steps from dantz again. I started diskpart and did exactly the same as I did before again without any fear, as I have a updated backup now. After doing that and trying to mount the partition, I was only able to mount the hidden volume and not the outer volume. At that point I realized what mistake I made: I've made a partition with an offset. However, this time I didn't encrypt the partition, but the whole drive. So I opened diskpart again and removed the partition, then restored the external backup header on it and yes, it worked. Even after creating a partition on a drive that never had a partition, I am still able to access all of my data uncorrupted, even in the outer volume, while it seemed like it was overwritten.

And then, after all, I found out what caused all of the problems. What caused the weird crashes I had some times, what caused diskpart to crash when I did detail disk and what caused a corrupted TrueCrypt partition. It sound very stupid now, but it is true: my SATA1-cable wasn't plugged in correctly on my motherboard. Now I pushed it in again and everything is working as it has to be: no more crashes, no more corrupted partitions and my main disk on SATA1. This solves another question for me. My previous disk had bad sectors on it, so I abandoned it. However, it was plugged in with that exact same SATA1 cable. It seems like the half-plugged-in cable caused bad sectors to that drive.

It's interesting how cleaning a PC, accidentally pushing a cable without knowing it, can cause so many problems. So I've learned another thing, check the cables, even if you're sure they're correctly plugged in.

 

"because of multiple reasons I've decided to DBAN my backup drives"

I lol'ed.

well that was a great story. congratulations to you having your data restored.

**** like that happened to me once but I had a good backup old of 24 hours so it was quickly solved.

I stopped using truecrypt because gaming performance sucked and it randomly bsod'ed.

 

Good find!

 

That's because, in creating the partition, you didn't overwrite anything outside the Truecrypt header, right?

 

Thank you for the answer! I'll try to clarify things a bit.

I created a test file from offset 32256 up to the maximum allowed size of the eval version of winhex. I managed to mount it in TC without restoring the backup header. I then open the mounted test file by opening the logical drive letter (in my case H: ) in winhex. In this I see lots of garbled plaintext (ie. something like m>”MÂÔ4Ep¬£NÎÎMÆ!æ and lots of small black boxes) from the beginning to offset 68608. Everything below says unreadable sector.

A search for zeros results in a popup message that says that the program cannot read from any sectors with a higher offset than 68608. No zeros are found in any of the earlier offsets.

I also opened a working non-encrypted drive and found some similar looking plaintext but also readable words. On this drive it was also possible to find
lots of zeros.

I hope this information is enough to give you a clue to what is going on because I'm pretty lost right now.

 

Hello again!

I've now played around a bit in diskpart and found that my problematic disk has a partition on it. Attached are screenshots of detail disk, list partition, detail partition, list volume and detail volume. How should I proceed?

http://i.imgur.com/nUobM.jpg
http://i.imgur.com/kBupr.jpg

 

Slow down, you're digging too deep and have skipped right past the basics. If you already have a partition with a TrueCrypt header at the beginning and you can mount the volume as usual in the TrueCrypt interface (by selecting and then mounting the partition) then you don't need to be making test files using WinHex. You need to be trying to recover data from your mounted volume, probably with standard data-recovery tools such as GetDataBack, PhotoRec, R-Studio, Recuva, etc. Start with GetDataBack, and if it can't find any files then your filesystem is probably shot, in which case try PhotoRec, which does not require a working filesystem.

You can also browse the mounted volume using WinHex, just to see if you can find any familiar data. If nothing at all turns up then you can use the WinHex Search menu to search for zeros (hex) or common plaintext, just to see if the volume contains any decrypted data whatsoever.

 

Hi

I calculated the difference in drive size to be 32256, so I started the block there and grabbed 200kb (eval version of Winhex). I could mount the file with no trouble in Truecrypt, it accepted my password fine with no errors. I then went to load the mounted file in Winhex, but it gives me the error messages:

"The disk structure is corrupted and unreadable"
"Cannot open "$MFT". Unexpected data at offset 3221225472 and offset 8192, Res=9, Res2=8"
"Cannot read from Sector 6,291,440...6,291,503 of Drive G:."

Is this a sign that my data is gone?
Or is there something I could try?


Cheers

 

No, the procedure you quoted does not indicate the condition of your data at all. It's only using a 200KB sample, after all. It's merely a test to see if you've found the TC header. The WinHex error messages can be ignored. They are explained earlier in the thread.

edit: You could click past the error messages and still view the raw data in WinHex, right? That was my assumption when I wrote this post. However, if you were able to mount the volume using TC but could not bring up anything in WinHex then that would be unexpected.

 

thank you for your reply

I couldn't open the error message pictures that were previously posted unfortunately, so wasn't sure if those were the same

I click through the error messages and it doesn't load anything at all, I just end up with an empty Winhex
I have attached some screenshots of Truecrypt and Winhex, please let me know if there's anything further you would like shots of

 

I should note that I can open the test file unmounted fine

 

You need to run WinHex as administrator (right-click, run as).

 

I opened the mounted volume in winhex and found some plaintext and some strings of zeroes. GetDataBack did not work since it couldn't find a filesystem so I tried PhotoRec. It managed to find some files but they have strange names and file extensions (.jsp, .gpg mostly). Is there any way to recover my original data from these files or should I try something completely different now?

Thanks again for the help, much appreciated!

 

This shows that your TrueCrypt volume is accessible and is decrypting. I'm sorry that I can't be of more help, but I'm more of a TrueCrypt specialist than a data-recovery specialist. At this point I believe you have full access to whatever remains of your TrueCrypt volume, so the job is now one of data-recovery.

Data-recovery can be quite difficult sometimes. Every case is different. Partial success is more common than full success. Based on the circumstances, sometimes nothing at all can be recovered. The presence of encrypted data usually makes the job much more difficult, but since you are still able to mount (and thus fully decrypt) your volume without difficulty, TrueCrypt is not really a part of your problem. Your volume's broken filesystem and/or missing data can be treated just like any other volume that has been partially damaged or overwritten. Thus, you need to seek help from data-recovery experts. Also, try some different data-recovery programs, and dig deeper into each one to see what it can do. Be prepared to work hard and learn a lot of new things, as there's usually no easy solution.

Be aware that there are several settings in GetDataBack that might make a difference, so make sure you read the instructions.

It would be smart to make a full sector-by-sector (raw) backup of your drive before attempting to write anything to disk, as you can easily make things worse by attempting various potential solutions without knowing what you're doing. Most data-recovery programs are read-only and thus are relatively safe, but certain repair utilities such as chkdsk, testdisk, etc. will write to the disk and could potentially worsen the situation. Also, if your drive is failing and that's the cause of your problems then you really ought to image the whole thing right away while you still can.

 

Unfortunately that made no difference at all, just the blank white Winhex window as per the screenshot above.
Is there anything else I should be doing or checking?
I'm wondering if maybe the 200kb file is too small for any decryption to be happening in Truecrypt properly, and it ends up mucking up the file when mounted causing Winhex to have issues. I didn't really want to spend money on Winhex just on a hunch that the eval version is causing the issue

maybe I could just carry on with the Diskpart instructions since I believe I have found the correct location?

 

It might be, although for some reason this had never been an issue for me. Technically 200KB is smaller than the current minimum container size, but I think TC still mounts smaller volumes in order to maintain backwards compatibility with earlier versions, which used to have much smaller headers.

HxD is an excellent freeware hex editor which can easily perform the same operation without the file size limitations of the WinHex eval version. I'm not going to post the steps, but it's not that hard to figure out.

It might work, but if I cared about my data I wouldn't do that unless I had a good sector-by-sector backup image of the entire hard drive. Your choice, of course.

 

Hi

The data file was showing signs of decryption in HxD
I have a sector by sector backup on standby just in case
I think I'm ready to get into the diskpart section now

This part, my offset in dec was 32256, when divided by 1024 I get 31.5
should I be using that as my offset in KB?

 

I don't think diskpart works with fractions. What's your OS? Windows XP defaults to 32256 if you create a fresh partition using disk manager. Make sure you DON'T format it or specify a file system. Just skip that part. And make sure you have a backup. (Sorry, I have to say that so you won't blame me if the whole thing blows up on you. )

The real question is, how large should the partition be? Are there other partitions beyond it, or is it just one drive-filling partition that you lost? If you don't change the default size then the new partition will fill the remainder of the contiguous unpartitioned space in the drive, or nearly so. There may be a small 'unpartitionable' space at the end. How large was your missing partition? You can get an idea by mounting the test file, opening the TC interface and viewing the volume properties. The volume size in bytes, plus 262,144 to account for the four headers, will equal the size of the original partition in bytes.

 

Dantz,

I just want to let you know that I was able to get my data back thanks to this thread. My problem was partially the same as Rakoen. I'm a very happy men now! I hope u like Dutch beer too