Truecrypt Disk Corruption

hi!

I have a 3 Tb disk encryptes with truecrypt. no partition, whole disk. I was coping files (800GB) and some stranges errors ocurres (Windows 7) at the middle of the copy. I restart the computer and i could not access to the truecrypt anymore. I had read that maby it was the header... corrupt... I dont have a header backup...

I try mounts option-> restore the backup header from the backup embebbed in the volume and when it ask to put the password, i put it, but it say me again that the password is wrong and the volume may be not a truecrypt volume...

I am really very unhappy because i had lot of data in that disk that i cant recover...

Anyone can help me??

 

In this case (entire device encryption) the embedded backup header would be located at the very end of the disk, wheras the volume header would be located at the very beginning. It's quite uncommon for both headers to become damaged at once, especially during a mere copy operation. Of course, a hardware failure could be to blame. Other possibilities would include allowing Windows to perform a full format, plus various other unspecified software-related blunders. (Are you sure you haven't forgotten your password? I've seen users misremember their exact passwords during moments of panic.)

I suggest you try to access the volume again, but this time don't try to restore the volume header from the embedded backup, merely try to use the embedded backup header to mount your volume. (Mount: Mount Options: "Use backup header embedded in volume if available").

If that fails then the next step would be to examine the disk with a hex editor (using both the hex and text views) while paying particular attention to the disk's first and last 64KB. Both ends of the disk should look completely random. You should NOT see any strings of zeros, recognizable words or other obvious patterns.

 

Hi Dantz!!! Thank you ery much for your answer... I Am very very sure of the password. ( I now realice that maybe i lost everithing in that disk, and i am stil sure that the password is that, The password that i was using a year ago.)

But i want stil fight! Something strange has happend. the volume of 3 TB when i search with the truecrypt "select device" button it show me HARDDISK1 746 GB. (Not 3 TB).
and when I select that it put me to mount this:

\Device\Harddisk1\Partition1


I remember that i encrypted the whole disk (but is say PArtition 1... :/) I dont know what could happend....


I try what you said... "(Mount: Mount Options: "Use backup header embedded in volume if available"). " and it stil give me the "incorrect password..." message...



before i do the HEX work that you mentioned... i ask you... the disk aparrently show me 746 GB of size... I stil work with that to extract the hex data?? (It's something like if windows dont recognice the size of disk animore... I try to mopunt it in linux and stil fail... ) What you sugest i do? I search for the HEX data to the disk like it is now? Or i do something for windows to recognice the WHOLE disk and then extract the hex data? I that case... what should I do?


Trank you again for answering my question... I have a lot of information in that disk


EDIT1: Upload of image: I open the disk with the winhex and this is what i see...

http://imageshack.us/photo/my-images/826/6b96.png/
http://imageshack.us/photo/my-images/27/esh7.png/
http://imageshack.us/photo/my-images/819/azy3.png/

EDIT2: I try what you mention here:https://www.wilderssecurity.com/showpost.php?p=2149896&postcount=7 But i can0t mount the file "wrong password.. :/"

 

Your images aren't of good enough quality for me to read the WinHex screens, even when I enlarge each image. Please try again, and make it more readable.

But so far there are two things that I can comment on:
1) Your entire hard drive has apparently "changed size"(?) It's very hard for me to explain that one. You're absolutely sure it's the same drive? I don't have much else to add on that topic.

2) A fully-encrypted disk would not have any partitions. However, your drive does. Perhaps this was done by mistake? (Or maybe this is a different disk than you think it is?)

Anyway, the first thing to do is to try mounting the entire disk, not the partition, to see if your password will be accepted, because even if a partition was accidentally created, the original embedded backup header at the end of the disk might still be there. Try mounting the disk using the embedded backup header, as before, but first make sure you select the Hard Disk, not the partition.

Note: Be careful not to replace the header with the embedded backup header. As described earlier, merely use it. (Mount options: Use backup header embedded in volume if available).

 

"Try mounting the disk using the embedded backup header, as before, but first make sure you select the Hard Disk, not the partition. "

I Try it and still get the wrong password message... grrrr

I don't know whats happend. but if you see the images it's strange... the partition and the disk have the same content... :/

6 files. start, line 10000 and end of the disk. start , line 10000 and end of the partition...


https://mega.co.nz/#!9sEQ3Q7Q!CtkFMwiaru_SSSQrEH2UVnAtAqxYQ_WC0sq7ADQ8Tss
https://mega.co.nz/#!FwkzRTSQ!ZR-o8nlq7RJDx5WVkBaZsAe4YGwvrfO6WtfCteYF5tk
https://mega.co.nz/#!Mlc0XIxS!B6P2VGBYzNBKLt0yg7DpjiXg_KsR4ptLS8i7VM7CoNA
https://mega.co.nz/#!Y4UgjaZK!dLmHHVo2NxSRWcoAfsC88CDigHUmc5F63qkCWmWXGgU
https://mega.co.nz/#!V8UHBCLY!PHbOsi2mLlfheJPs_2T20kqRTVhMWTJ_tAzDlsBqEaU
https://mega.co.nz/#!Iw8CARZB!UGxitnAtawNdu3NaAVShPBQZaZQwelcDaWVdciIr9fg


ALL TOGETHER: https://mega.co.nz/#!E5l1hITb!DqqM_CSfOdmV4GtahGA_s1xM1ABMnNE01BI1a-hUTP0




EDIT1: These are the 64 start and end of the disk...
https://mega.co.nz/#!R1shxR5Q!BUxDkS8cyR9k4ShGOITDZ09hLxFEPXdnTj018CV7Qh0
https://mega.co.nz/#!o1MhBDZa!Yc-XuV_YOFRkyruwcvwMGWvAFFhjjJ8SSr-TClfkngE


Edit2: I read that you put 64 Kb of start and end are the header... is that correct or i understand wrong? Because i create a header buckup of other volume and it created a 128KB file...
I would like to try to restore the header of the las portion of the disk (if it is any) to the start of the disk to see if it works... But i am not sure of how to do it... Can you tell me how to do this or if it hasn't any sanse?

 

Some one?

 

Sorry, I've been quite busy. Also, I choose not to visit mega.co.nz due to security and other concerns, so I still haven't been able to view your winhex screens properly. Can't you just post some better images to imageshack? Or post them directly to Wilders? Either method usually works fine; just make sure they're readable.

 

How can i upload files directly to this forum in the image button it open a link for the image...

any way to upload files directly here?

 

Use the "Manage Attachments" button below you posting box...

 

Thanks! now i have the button!!

5 first images

 

one more image, and the first and last 64 of the disk...

 

Thanks for posting the images! I'll look them over soon.

 

OK, I've looked over your images. I see what you mean about the lost drive capacity. Your Western Digital is a four-platter drive, but it seems as though you are currently only able to access one of the platters. Something weird is certainly going on. Plus, now it's been partitioned. Obviously this drive hasn't just been sitting on the shelf.

Did you update the firmware, or alter any of the firmware settings? I did a quick online search and found that it's possible to mistakenly change the capacity by running certain firmware-related programs. Also, different computers might not be able to access the full capacity. Was the drive originally used on a different PC?

The reviewer at storagereview.com also had a problem with the drive unexpectedly reporting a different capacity. Here's a quote from the review: "No matter what we did the drive would only recognize as a 746GB drive."

http://www.storagereview.com/western_digital_caviar_green_3tb_review_wd30ezrsdtl

I suggest getting in touch with Western Digital to see how to proceed. I'm not sure if your data can be recovered or not, but before we can even begin to try to recover your data you need to get your full drive capacity back, hopefully in a non-destructive manner.

I can see some of what might be your encrypted data on the drive, but we're going to need a lot more than that. We need the very beginning and possibly the very end of the drive, not just a 25% chunk of it, otherwise we will be unable to recover your TrueCrypt headers or decrypt your data. Good luck!

 

Thank you very much for answer dantz! It's very importan for my that information and to know if i can continue using truecrypt with my data or no. Other case i wouldn't bother you so much

I didn't use any firmware-related program. I didn't update or alter a firmware of the disk. That day i do the following: (originally i had TWO DISK, a 1TB disk with two partition. One with the SO Windows 7, and other with one big file container of TC, AND a 3TB disk full encrypted with TC, this is the disk that screw up) That was the situation at the start of the day. But that day, I buy a new 3TB disk, give it to a work partner, and he put some files in it (800GB more or less). So here is the thing: i shutdown the pc, connect that NEW 3TB to the pc. Start the pc. I mount the old 3TB full disk encripted, and i started passing all the data of the NEW 3 TB disk (without encryption) to the OLD disk with full truecrypt encryption. (the disk that finnally screw up). In that ocasion the disk mount good. No problem detected. In the copy of files (hours after) the disk give some error of reading of destiny. (something weird). So, it was very late, I shutdown the PC and go sleep. Next day it won't mount anymore...
Resuming the situation: I didn't use a firmware tool. I didnt use that DISK on any other PC. I Connect a new disk. That time it work OK with the new disk (until the copy fail). And it did not work anymore latter.

If i access from linux (I try it with KALI) i can access to the full disk. (it figure in the /dev/sdb that the device has 3TB ... 2xxx GB) So i think that maybe its a problem with the SO... and maybe we can resolve this problem from linux. What you think of this? you think that we could access to the full disk from KALI? (I think this because when i buy the disk i remember that it detected some or less the same size like now from WIN 7, i partition with GPT (i think, not sure) and it start detecting me the full 3TB disk...).
I can send you some print of some commands/gparted GUI if you want (if you need some specific command tell me)

if you think that from linux we will be able to do this (because we can see the full disk)... how many data do you think that we need to extract to do this? if you tell me this (and if you know some program that do this, i think that with the wxHexEditor i could try) I can try to extract and post it here to see if this has sense.


One more time. Thank you so much for your time.

 

I'm sorry, but I'm not familiar enough with Linux to know the best way to deal with this situation. I do know that you might be able to mount the volume by using the Linux version of TrueCrypt, but you probably won't be able to browse the contents of your mounted volume (assuming it has an NTFS filesystem). However, I wouldn't bother with any of that, as you won't be able to see anything, and I certainly wouldn't risk it until you have at least made a copy of the volume header.

Another option,of course, would be to check with Western Digital to find out what it is that you need to do to in order to get your Windows system to recognize the disk. But don't do anything that might alter the disk, as all of your data is at risk.

If you are positive that you encrypted the entire RAW, unpartitioned disk (and not merely an existing partition on the disk) then I would suggest copying at least the first 512 bytes of the disk, as this area holds the vital portion of the TrueCrypt header that allows you to decrypt the entire disk.

However, it will be more useful to copy the first few MB or so and save it as a file, as this will allow you to easily test to see if the header is intact and functional. After you save the file, merely attempt to mount the file in TrueCrypt (via "Select File"). If your password is accepted then your header is still good. I discussed this whole technique in another recent thread in this forum, but in your case you would need to use different offset numbers because there is not a partition involved.

Whatever you do, take great care not to alter the first 512 bytes of the disk. It wouldn't hurt to image the disk, just in case.

Of course, if you want to decrypt your data then you're going to have to copy that, too. How much data is stored on the drive? Merely copy (or dd) everything that you can starting at the very beginning of the disk, as far as you need to go to include all of your data, plus the internal file system structures of your encrypted volume. Is it formatted NTFS?

I would start with the small operation listed above, then try to mount the small 2MB test file in a Windows version of TrueCrypt. If your password isn't accepted then you will need to attempt recovery of the embedded backup header instead.

But don't expect me to know all the answers on your relatively unique situation. I can help you with the Windows version of TrueCrypt, but my skillset is fairly limited when it comes to unusual hardware issues and the use of Linux.

 

The described failure and the fact that the disk is now recognized with the wrong size very much sounds like a LBA address overflow: a 32-bit LBA can address up to 2048 GB and therefore it is not sufficient for 3 TB disks. Unfortunately old AHCI drivers and firmware from almost all vendors (at least Intel, AMD and nVidia) only supported 32-bit LBA: you should check now whether this is also the case for your system. The easiest way to check wrong LBA addressing is the tool HD-Sentinel: a warning message that the drive size is not correct should be printed if the bug is present. Another way to check the issue is the tool HD Tune (as the free version cannot handle more than 2 TB, the demo version has to be used): benchmarking the read speed of the disk should result in a curve starting at the highest speed and constantly decreasing in speed (like shown on the linked homepage of the tool): if the 32-bit LBA overflow is present, the read speed will jump back to its initial speed after 2048 GB.

After you have verified that the bug is present, you have to fix the bug: normally it is sufficient to update the AHCI driver of your system: on Intel chipset based systems the Intel RST driver has to be updated and on AMD chipset based systems the AMD Chipset Drivers have to be updated. After updating the driver you should recheck with the tools above that the bug is no longer present. To mount the TrueCrypt volume afterwards, you can try a scan with TestCrypt at the end of the volume: if the backup header is still there, it should be found by TestCrypt.

Now to the bad news: a LBA overflow is one of the worst things that can happen to your data (I have also managed to get it once still with the old 28-bit LBA of Windows XP w/o SP at 128 GB): due to the overflow the data which should be written to the end of the disk is overwriting the data at the beginning of the disk. As the NTFS MFT (Master File Table) is stored there, the data required to recover fragmented files, path- and file-names usually is gone. Without this information, only files which are not fragmented and have a unique file header can be recovered by tools like R-Studio (supports both MFT and file header based recovery) or Photorec (supports only file header based recovery) with generic file-names. As your volume is encrypted, the volume mounted in TestCrypt has to be selected in these tools in order to find any data.

 

Something I find interesting about your situation is the fact your MBR (Sector 0; Offset 0-511) appears to not have the expected partition label of 0xEE at offset 0x1c2, for a GPT partition, rather it has 0x0F, which classifies it as a Windows Extended LBA partition. Not too weird.

Now the weirdness: The partition table for this LBA Partition tells the OS there is a partition starting at sector 915052383 (offset 0x01c6-9: 5F978A36 in little endian). This is 468GB into your disk! Then the value for how large this partition is 3955871682 sectors (2025GB), which is, if I'm correct, slicing the end off of your TrueCrypt volume.

This is what my partition table entry looks like for my GPT disk. It should only ever look like this as in essence all it needs to do is tell the OS that there is an unactive partition and it takes up the whole disk:

000001be: 00 00 02 00 EE FF FF FF 01 00 00 00 FF FF FF FF

Yours looks like

000001be: 00 FE FF FF 0F FE FF FF 5F 97 8A 36 C2 CF C9 EB


I don't know how this editing of the MBR would have happened but I suspect if you were to change your partition entry in the MBR to how my one looks, you would be able to gain access to your TrueCrypt'ed GPT partition.

Remember, caution is advised. If you do carry this out, make a backup of the disk you have or at the very least your current MBR (although you have already provided this ^.^).

More information about the MBR's relationship to GPT partitioning can be found here: http://thestarman.narod.ru/asm/mbr/GPT.htm

 

Thanks for all the reply!!! I am glad that people try to give suggestion about my problem. ! thanks!

I Try to mount in linux and i can't mount the disk... (wrong pass...) I Will make a copy of the header. Cna you tell me how much i must copy to a file? ( with the method that you explain in other post with winHex? How Much MB must i copy at the begginning and at the end?

I Try this but i could not get this working with the first 200KB and the last... I read that you said that the header is located at the begining of the disk. And a copy in the end of the disk. (i think that for a secuity reason). I can try to do more times that procedure... but... witch offset must i try? how much size must i take from the begining and from the end?? (hoy much KB or MB must i try, wich ofsett must i take from-to? i could try to upload that file if you tell me that)

its stored more that 2TB... I think that image that is not posible... I dont remember if i formated with ntfs when I create the truecrypt volume some time ago or not...

I tryed this some times (with diferent size, and i could not get truecrypt to mount the new file, but i am not sure of teh exactly size that i must use, like i told you before)

I know that you can't andswer all my questions, but I ask because maybe you think something that i don't know...

I Try with HD Sentinell and it give me not warning... But i notice something strange... That the disk of 3 TB encripted with the truecrypt... it figure out like if this disk have 7XX GB of size. And the other (of 3TB not encrypted) figures with the SAME size... But in windows, if i go to explorer and see how much space left it have and how much space has the disk it figure like it's a 3 TB fisk... (2.70TB more or less) It's like the bug is not present i think...
(But i am not very sure..)

I try what you sigest and a caos to my disk happend... If i change that bytes in that sector of the disk it figures like if i have a lot of partitions... (many)... I try to mount that volume equal (after do that edit) and it give me the "wrong password" message. So I put it back like it was... I think that that is not going to work...






I would like to try to rescue the header that is at the end of the disk. And try to mount that... but i dont know how to do this... because i dont know wich offset and wich size use... If someone can figure out for me or have some otre ideas i can try and if someone have some dudes i can send some pics of information of anything...

One more time thanks a lot for yout time.

 

The wrong size detected could also indicate the bug - can you try to make the benchmark with HD Tune?

Be careful with this disk, too. Do not copy any further data to it until you are 100% sure that the bug is not present.

 

Important: When you tried to mount the volume in Linux, did you
1) select the entire physical disk (not the partition), and
2) use the Mount Option: "Use backup header embedded in volume if available"?

If that doesn't work then we may not be able to get very far, but here's how you can make a copy (or try to make a copy) of the embedded backup header. Since you will be working in Linux and I am unfamiliar with how things are done there, in some cases I can only give you general information rather than specific commands:

The entire embedded backup header is exactly 65,536 bytes in size, although the first 512 bytes are the only portion that really matters. The remainder of the header doesn't actually do anything, but you might as well copy the whole thing.

The embedded backup header is located exactly 131,072 bytes back from the very end of the physical disk. You could express it like this: Size of disk in bytes minus 131,072 = Starting offset of embedded backup header.

Here's how I would proceed:

1. Note the total capacity of the drive in bytes

2. Subtract 131,072 from that number

3. The resulting number is the starting offset for the embedded backup header.

4. The entire header is exactly 65,536 bytes in size, so select a block of data (beginning with the starting offset that was calculated above) of exactly 65,536 bytes and save it as a file. (The exact size is not actually that crucial as long as it exceeds the minimum size for a TrueCrypt volume, so if it's off by a little it's no big deal, as long as the beginning of the file is correct).

5. Copy the file to portable media, then plug it into a Windows computer. (Or do the following in Linux if you like. I'm just listing the Windows commands because I'm not familiar enough with the Linux version)

6. Open TrueCrypt, select a free drive letter, click on Select File, browse to the recently created file and click Open

7. Click on Mount, then supply the password that you would normally use for the lost volume.

8. If your password is accepted and the test volume mounts to a drive letter then you have found the intact embedded backup header. Hooray! Dismount the test volume.

From this point onwards there are several different approaches, but before we try to go any further let's see if we can get this far.

PS: Have you checked with Western Digital yet? I'm sure this is a known problem and they will probably have some advice to offer. (Perhaps a bios update, a firmware update or an OS driver update, I don't know.) But whatever they suggest, make sure you don't write anything to the drive or you might end up overwriting some of your encrypted data or worse, your encryption header.

I suggest you don't try to rush things, as you can definitely make the situation much worse than it already is if you screw up. Ideally you should make a clone of the entire disk before going any further.

 

Once again Thanks for ansswer me!

I will do what you said dantz. First I will try to mount in linux the disk, and there i will extract the lasts MB and the firsts and I will mark where the header I think that it is so you can check it....

In linux i dont have the option of "Use backup header embedded in volume if available"... And yes, I tryed to mount the entire disk...

I totally agree... But I can't...


I create a WD Online account and create something like a tiket. I am waiting the answer.


I append 2 pics of: 1 the result of the HD tune benchmark, and the other is something strange... Look at the sized detected in each drive

The benchmark dont sayed anything about any bug but the size of the drive with the HD Sentinell are both wrong... What's your oppinnion abbout that?

 

It really seems that the LBA overflow is the root cause why you lost your data as the size of your disk is detected wrong in all tools. Did you try to select either the encrypted disk or the other 3TB disk in HD-Sentinel? The warning should be displayed in the green box on the right if the disk is selected. Nevertheless you should try to update you AHCI driver in Windows and check whether the disks are detected with the correct size afterwards.

 

Te overview tab it's in the image... and the state is "Perfect" Or is any other tab that you refeer?

EDIT: I add the report

 

I'm unable to help with any of the disk capacity stuff.

However, if you are already able to view the entire drive at its full capacity using Linux then I would get somebody to help you set up the appropriate "dd" command in order to save a copy of the embedded backup header as a file, which you can then test (that is, try to mount it) using TrueCrypt to see whether or not you've actually managed to recover the intact header.

I described the details of the embedded backup header's exact location and size in a previous post.

I do have one important question, though. You have said more than once that you encrypted the entire disk, not merely a partition on the disk. And yet, I see that there is a partition present on the disk. A fully encrypted disk would NOT have any partitions visible. It would consist of fully random data from beginning to end. Why is that partition present? Did you create it by mistake?

Or, were you perhaps mistaken when you said you encrypted the entire disk?

It's important to get this part right, because the headers would be in an entirely different location if you encrypted a partition.

 

I really have to search for another tool which is able to detect the LBA overflow: in your case, HD-Sentinel does report anything despite the disk is detected with the wrong size

According to HD-Sentinel the driver which has to be updated should be the Intel RST driver. As long as the disks are not detected with there correct size, you should not write any data to the still working drive: otherwise the same thing will happen as with the TrueCrypt encrypted drive.