Corrupted TrueCrypt Partition

Discussion in 'encryption problems' started by Rakoen, Jul 10, 2012.

Thread Status:
Not open for further replies.
  1. Rakoen

    Rakoen Registered Member

    Joined:
    Jul 10, 2012
    Posts:
    14
    Hello all

    This is my first post here. I found this forum using Google, while I was searching for a solution for my problem. However, it seems like this forum is full of professionals, so I'm going to explain my situation.

    I am someone who has lots of important files, but I mean really important files, in an encrypted TrueCrypt partition. Of course, as these files are so important for me, I have a backup of them. However, because of multiple reasons I've decided to DBAN my backup drives while thinking "okay, for a few days my data is safe without a backup". Now just in these days, the following happened.

    I have been using TrueCrypt for a long time, without any problems. That's why I thought it was very reliable. However, two days ago, when I mounted my partition, it showed up as "RAW" and so I couldn't open it nor check it using any OS. Then I tried dismounting it and mounting it again, which said "corrupt volume header". Okay, I thought, no problem, let's just restore it. I did that and it still lists my drive as a RAW partition. Then, after dismounting it again, I realized that I mounted \Device\Harddisk4\Partition0. I saw a \Device\Harddisk4\Partition1 and tried that one, which let me successfully mount the whole partition again and yes, I could access all of my files again, without any corruption.

    Now, yesterday, my TrueCrypt drive suddenly auto-dismounted to prevent corruption. Again, I thought "no problem". I wanted to mount it again and realized that \Device\Harddisk4\Partition1 disappeared (probably 'again'). Here I started to think "has it ever been there, or was it just an illusion". So I just mounted \Device\Harddisk4\Partition0, which again gave me that RAW partition. So I did over again what I did before: I restored the volume header and searched for a \Device\Harddisk4\Partition1, but it didn't appear.

    From Google'ing, I've tried some methods like this one: http://forums.truecrypt.org/viewtopic.php?t=18335
    But nothing really worked. So that's why I've contacted Christophe Grenier, the creator of TestDisk. He guided me through some things and this are the results:
    - TestDisk lists my disk correctly (altough the label is 'Local Disk' and still lists as 'RAW'), but it can't find any trace of NTFS MFT copies. So the rebuilding of bootsectors resulted in a failure.
    https://dl.dropbox.com/u/3062101/Bad%20Boot%20Sectors%20%5B10-07-12%5D.png
    - PhotoRec finds very weird files that have nothing to do with my personal files.
    https://dl.dropbox.com/u/3062101/PhotoRec%20-%20Success%20%5B10-07-12%5D.png
    https://dl.dropbox.com/u/3062101/Wierd%20Big%20Files%20%5B10-07-12%5D.png
    - When I open the Logical Disk Manager in Windows, it gives me this screen.
    https://dl.dropbox.com/u/3062101/Disk%20Management%20%5B10-07-12%5D.png

    Again, losing any of the information stored there is almost like dying for me. So, any suggestions here?
    All of my current harddisks are formatted as NTFS.

    Thank you very much
    Appreciated
    Rakoen

    PS: I have also posted this on the official TrueCrypt forum, which didn't give me any help. http://forums.truecrypt.org/viewtopic.php?t=26754
     

    Attached Files:

    Last edited: Jul 10, 2012
  2. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    991
    Location:
    Hawaii
    OK, I'll look into it. At first glance it looks as though you have lost your partition table, in which case you will need to restore it exactly as it was and then restore the correct TC header (if we can find it) to the beginning of the partition. There may also be some other issues such as bad hardware.

    A few questions, please answer what you can:
    What is your OS?

    Is this an external disk? What interface? SATA? USB?

    Does it use the MBR partitioning style (as opposed to GPT)?

    Did you partition it yourself, and if so using what program?

    If so, did you use the default settings to create a single partition that filled the entire drive?

    Did you ever (previously) encrypt the entire raw device rather than just Partition1? I ask this because you wouldn't normally be able to restore your TC header by selecting the raw device (Partition0) unless you had previously encrypted it that way, as this would leave a 64KB embedded backup header at the very end of the drive, beyond the endpoint of the partition that has now gone missing.

    If you did the above, did you use the same password? (Be aware that just because two separately-created headers share the same password does NOT mean that they can decrypt the same container. They can't.)

    How much help did Christophe Grenier provide? Did he ask you similar questions, and did he try to recreate your partition table to what he deduced would be its original configuration? Because that's what we're going to have to try, and I'm sure that he would be much better at it than I would. Anyway, if indicated we'll try doing this using the standard location, based on the answers that you provide above. I just hope that we can find the correct TC header. That's going to be the tricky part, I'm afraid. I don't trust the embedded backup header that you recovered from the end of your drive, as the partition's embedded backup header would not normally be found in that location. So try to answer the questions as correctly as you can so we won't waste time on false assumptions. I can't tell just by looking; I have to know the correct history before I can figure out the correct actions to take.
    That was a big mistake. Your problem appears to be self-inflicted. However, there's also a bit of a discrepancy that we need to figure out. Are you sure that you performed this procedure more than once? I don't think you'd be able to, so either I misunderstand the situation or your accounting is partially incorrect. The thing is, when you restore the embedded backup header of a raw device TrueCrypt writes a new volume header at the very front of the drive, and this would overwrite the MBR and partition table. You wouldn't be able to select a partition ever again until the MBR/partition table was restored.
     
  3. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    991
    Location:
    Hawaii
    A few more questions: Do you have any manually-created header backup files? Or an image, even an old one, of the now-missing partition? And were the other disks partitioned in the same manner as this one? Same tools, same (default) settings?

    We will be using WinHex, so please download an evaluation copy. You might need to purchase it and learn how to use it, but not yet. Let's see how everything goes first.

    I would strongly recommend that you perform a sector-by-sector (raw) clone or image of your entire disk, for backup purposes. Actually, you should have done this right from the start, definitely before using TestDisk or any other program that writes to the disk.

    Also, I don't have unlimited time or availablity, so you can expect some pauses in our conversation.
     
  4. Rakoen

    Rakoen Registered Member

    Joined:
    Jul 10, 2012
    Posts:
    14
    Hello Dantz

    First of all. Thank you very much. I really appreciate your posts.
    The moment I am writing, I am creating an image using TestDisk (the reason I haven't done that before is because of all of the imaging softwares I use don't support hidden TrueCrypt drives).

    I am currently using Windows 7 Ultimate x64 with Service Pack 1 and latest updates. However, I am multibooting with OpenSUSE and SlackWare.

    It is an internal disk, using SATA-300.
    It does use the MBR partitioning style.

    Normally I partition my drives using GParted, however, this was a special occasion, I followed this tutorial: http://support.seagate.com/rightnow/flash/discWizard/CloneDisc_3TB_P2/CloneDisc_3TB_Part_2.htm because my Phoenix BIOS doesn't support 3TB disks out of the box.

    So yes, I kind of used the default settings and that made the partition fill the entire drive (or however you call it, the new drive DiscWizard created).

    I've always used the 'encrypt a full non-system partition/drive' option to format the whole disk. However, I repeat that I may be seriously mistaking here about the \Partition1, as I can't verify it anymore now that it's gone. The weird thing I have to add it, TrueCrypt itselfs says that it successfully mounts using the password I always use and it shows the exact (correct) size of my hidden partition too.
    (I should have said this before: I am using an outer volume, which had the corrupt volume header, and a hidden volume, which now also shows up as RAW. The tests I did were all on the hidden volume, as my important data is on there.)

    I have always used the same password (or yes, except for a different password for the hidden one of course) and when I restore the embedded backup header (which was successful), it still works with that password (as I never have changed it).

    Well, Christophe Grenier didn't help me very much (yet) because he's a bit slow in answering and didn't say anything anymore since PhotoRec failed. He also didn't ask me much more questions. I think you've asked more than him. However, that's understandable as I was surprised I didn't end up in his spam filter.

    I don't see why this was a big mistake (restoring the volume header). As far as I know it doesn't corrupt any data and it did seem to fix the problem previous time. Further it is very difficult to specifically explain if I have performed this procedure more than one. I was in a kind of a panic and am currently kind of hallucinating, so I can't say things about the \Partition1 for sure. However, currently I am looking at my laptop which I did exactly the same kind of encryption, passwords and options. It doesn't show a \Partition1 there either, just mounting \Harddisk2 works perfectly there, so maybe this was indeed just an illusion I was getting.

    I don't have any manually-created header backup files. I just never thought of that as I never had a problem with it. Going to do that from now on for sure however. I have no image from that disk at all.

    A positive point, I already have WinHex installed, the full version. Great program, but I didn't really use it myself. So it would actually be a good thing if I learn from it now, as it is a point I don't have a lot of experience in and it seems to be interesting.

    As far as I know, I've never written anything to the disk so far. The TestDisk thing was only an analyzation and the backup header was just restoring with the right one. The Windows Logical Disk Manager did write a new MBR to the disk, that's a true thing. That's as I realize know they meant 'write' with 'initialize'.

    That the answers are with some pauses, no problem. Really, I am happy someone is answering with valuable information, so take your time!
     
    Last edited: Jul 11, 2012
  5. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    991
    Location:
    Hawaii
    Hmm, the scenario has changed quite a bit. Now we're apparently dealing with a hidden volume in a fully-encrypted device? And Seagate DiscWizard has apparently performed some sort of trickery on it (perhaps an overlay) because your bios doesn't support that size drive? Oh, great. Looks like we need to start over.

    I need to know whether you encryped an entire raw device (that is, an entire raw, unpartitioned disk from beginning to end) or a pre-existing MBR-style partition such as would be created by DiscWizard or GParted. You sound unsure and have suggested both. Here's one way we might be able to find out:

    Are you able to mount the outer volume? (At this point it doesn't matter whether or not you can view its contents.) If so, bring up the TrueCrypt Volume Properties screen and write down the volume's size in bytes. Then dismount the volume and close TC. Open WinHex, Tools, Open Disk, and select the correct disk under the Physical Media heading. The information panel (on the left side in my version) lists the drive's total capacity in bytes. Write this number down as well.

    Take the outer volume's size in bytes as shown by TrueCrypt and add 262,144 to that number to account for the space taken up by the TrueCrypt headers. Does the result equal the total capacity of the drive as shown by WinHex? If so then you have encrypted an entire (raw) device, and not a partition. If the TC number + adjustments is less than the size of the entire drive then you probably encrypted a partition.

    Another way to think about it: You mentioned that you recently allowed Windows to initialize the drive. If you did this to a fully-encrypted raw device then it would destroy the TC Volume Header which, for a fully-encrypted device, is located in the very first sector of the drive. You would have to restore the volume header from the embedded backup header, and doing this would destroy the initialization data and the MBR/partition table, which also sits in the first sector. Fully-encrypted devices shouldn't be initialized, ever. But this question normally doesn't even come up for partition-hosted volumes.

    Back when your TrueCrypt volume was working properly, did Windows ever offer to initialize the disk that it was stored on? If so then it was a raw, unpartitioned disk, which is how a fully-encrypted drive appears to Windows. Alternatively, did Windows ever state that your (unmounted) partition needed to be formatted? If so then it was an encrypted partition located on an initialized disk that had an ordinary MBR and a partition table. So which was it? (And please don't answer "both". It's one or the other).

    For that matter, does Windows ever offer to initialize the drive on your laptop computer? If so, don't do it.

    Another way to find out: Did you encrypt your existing data "in place"? You can only do that to an existing partition. Sorry to continue hammering on this theme, but I really need to know which it is before we go any farther.
    You didn't mention at the time that you were restoring a hidden header. It makes a big difference. An outer header would overwrite the MBR, if there was one. An inner header is located further in and would cause different damage, or possibly none at all. And restoring a header to the wrong location (e.g. to the beginning of a disk rather than the beginning of a partition) is just as bad. I thought that was what you did.
     
  6. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    991
    Location:
    Hawaii
    Oh great. I just read up on the Seagate (Acronis) extended capacity manager and discovered that it uses a virtual driver that runs under the OS. I have no idea how to deal with that or whether it will screw up our methodology. I guess we can try to work around it, but it definitely adds a big unknown factor.
     
  7. Rakoen

    Rakoen Registered Member

    Joined:
    Jul 10, 2012
    Posts:
    14
    The virtual driver lets Windows think that I have two physical disks (2TB + 1TB), so if we thread them as seperate disk there shoudn't be a problem (no need to worry about the other 2TB). It looks like this in TrueCrypt: https://dl.dropbox.com/u/3062101/Harddisk 0+5 [12-07-12].png

    I am actually very sure what I did with the encryption part. Firstly, I've created the default (MBR) partition using DiscWizard. Afterwards, I've selected the partition in TrueCrypt and chose "encrypt full partition". Afterwards I formatted it in TrueCrypted, as it was suggested.

    Still, a check can't hurt. So yes, I am able to mount the outer volume (I already said it had the corrupt volume header). At the moment I can't really unmount the partition to do that check you've suggested, as I'm still creating a image of it, so I'll skip (or postpone) this step for now.

    I indeed allowed Windows to initialize the drive. As stupid as I was, I did it two times (GPT and MBR), now tell me that this doesn't corrupt any data or I'll just panic even more. After I did that, TrueCrypt indeed asked me to restore the embedded backup, because the header was corrupt. However, as far as I can remember, it only asked that on the outer volume and not on the hidden volume. Again, not sure here, it could have asked to restore it on the hidden volume either but however, I've restored it to both (that wasn't a bad idea, was it?).

    I have never ever been asked to initialize the disk before. I have never ever been asked to format the partition. However, I also never assigned a drive letter to the unencrypted partition or never opened Logical Disk Manager before (as I normally use GParted).

    I'm kind of happy here, because I just saw that Logical Disk Manager also asks to initialize the disk on my Laptop. However, I now understand that I encrypted the whole physical disk there (Laptop) and not a partition (as on my desktop).

    It's no problem that you continue hammering on this theme, I understand it. Now I realized the answer: I have encrypted an existing partition on my desktop, yes. And as far as I know, it has always been listed as \Device\Harddisk5\Partition1.

    Well, I've restored both headers. I think that I even restored the outer header multiple times. Does it make any difference? Beside that, how can I restore a header to a wrong place? I mean, it's all automatic by TrueCrypt, why would it restore the header to a bad place?

    There is still something I really would like to investigate: how is it possible that I had this before, that it all showed up as RAW, and then it got fixed? While I now have the same problem, while it still isn't working?

    Thanks again
    Rakoen

    EDIT: It looks like I was correct. Just did the extra check you've suggested.
    TrueCrypt Outer Volume = 801.565.835.264 bytes
    TrueCrypt Outer + Header = 801.566.097.408 bytes
    WinHex Total Capacity = 801.567.145.984 bytes

    EDIT2: I found another interesting thing. When I open the unmounted disk in TestDisk, it detects an EFI GPT partition table. https://dl.dropbox.com/u/3062101/Partition Table [12-07-12].png

    EDIT3: In the meantime I did a "Rebuild BS" with TestDisk on the Outer volume (while Hidden Volume encrypted) and it just gives the same results as the Hidden Volume.
     
    Last edited: Jul 12, 2012
  8. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    991
    Location:
    Hawaii
    No, you're probably ok. Doing this only affects the first few sectors of the drive, as long as you didn't format anything. When you restored the headers it caused similar damage, but they probably just overwrote the disk's first sector and a portion of your old headers. Your volume's file system and data are farther in and should be ok.
    TrueCrypt makes no attempt to verify whether you are restoring a header to the correct location. For example, you can take a manually-saved backup header and restore it onto a completely unrelated file, partition or disk, and the header will go there and will overwrite the first sector of whatever you selected, seriously damaging the object. In the case of the disk it will overwrite the MBR and partition table, causing all of your partitions to 'vanish' (although the data is still there).

    You can also accomplish this using an embedded backup header, but only under special circumstances. If your encrypted partition happens to extend to the very end of your disk (which I believe to be uncommon) then TrueCrypt will be able to find the same embedded backup headers whether you select the partition or the disk, and it will restore the headers to whichever location you specified. One choice is correct, and the other choice will wipe out your partition table. I assume this is what happened to you, possibly because of the way your drive was set up and partitioned. Most users wouldn't be able to make this mistake.

    In all of the above examples you would still be able to mount the so-called volume to a drive letter, but the mounted volume would not contain any organized contents. It would look just like a solid block of random data until you dismounted it.
    I don't know, but I can guess. When you boot up, your partition layout is loaded into memory. Maybe you have to reboot before the loss of your partition table goes into effect, if that makes sense. I'd have to play with it for awhile to see how to do that, but I'd rather put the effort towards fixing your current situation.

    So we're back to the initial scenario, but I did notice one other thing. Your numbers indicate that your partition consumed all but 1MB of your disk. This is probably because your partition's starting offset was at 1MB, which is typical for Windows 7. This assumes that your partition did in fact extend to the very end of the disk, which is how we are trying to explain the fact that this unexpected situation could even happen in the first place. I don't really know, though, I'm just guessing. Anyhow, let's go with that assumption and try to fix it, as follows.

    1. Back it all up. Sounds like you're doing that.
    2. Manually back up both headers (outer and hidden), saving them as files. Don't skip this step, and don't mix them up!
    3. Choose one:
    a) At this point we can follow a shorter but riskier approach by recreating what we hope is the old partition (but NOT formatting it) so it begins at decimal offset 1048576 (the default for Win7) and extends to the very end of the drive (if possible), then restoring the TC headers to that partition, then mounting the volumes and testing to see if their data is present and decrypting.

    b) Alternatively, we can choose the longer, more careful approach by first using WinHex to non-destructively test the data at that location to see if the starting offset is correct. It will involve copying blocks of data, saving them as files to another disk, restoring TC headers to the files and then using WinHex to search the mounted volume for decrypted data.

    Because I'm uncertain of what's going on and I'm naturally cautious, I would pick "b", but if you feel confident that your backup is complete and you just want to get on with things, we can try "a" and see what happens. Writing a fresh MBR and partition table probably won't cause much harm, as you have already overwritten this area several times anyway.

    Is there any crucial data on the outer volume? Because I don't expect the new partition to extend to the very end of the drive, so we might lose a little bit of the end of the volume.
     
  9. Rakoen

    Rakoen Registered Member

    Joined:
    Jul 10, 2012
    Posts:
    14
    Dantz, thank you for your post, again. I owe you a beer (I'm from Belgium, so that's no problem). Really, it's great to read such a great posts. This not only works sedative for my problem, it also is very educative. It's good to know that you also will learn something from this situation (so that it isn't lost time).

    As for the backups: I made three images with TestDisk (Full Disk - Outer Volume - Hidden Volume). I made a backup of the volume headers using TrueCrypt, but it seems like it stores both headers in the same file. Also, you said "manually", so for me it's quite unclear if you are referring to the TrueCrypt function or something more complicated.

    For 3. I definitely choose for 'b'. While I need the data as fast as possible, I can't risk to loose anything so no matter how long it takes, I'll do everything to get it back. So yes, I'm ready for it. WinHex is open and the backups are made. Beside that, I have nothing to lose from the outer volume. The files on there have a backup (no image).
     
  10. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    991
    Location:
    Hawaii
    OK, I'll work up a set of procedures and will post them soon. I've already done a practice run and it worked fine at my end, hopefully it will work for you as well.

    Yes, when I said to back up the headers I meant to use the TC feature, and it sounds like that's what you did. Sorry, I forgot that both headers are stored in the same 128KB file.

    Do you have a licensed copy of WinHex or just the evaluation version? It makes a difference in how much data you can paste into a new file.

    My monitor is failing. I loaned out my backup and will have to buy another one, so this might slow things down a bit.

    Here's something you can do to get started, assuming you have the evaluation version of WinHex:

    Open WinHex
    Tools
    Open Disk
    Physical Media (select the correct hard disk)
    Edit; Define Block; start 1048576, end 1248575 (the block is small because you can't save more than 200KB using the evaluation version)
    Edit; Copy Block; Into New File, name it "Test Outer.tc" & save it on a different disk.
    Close WinHex
    Open TC

    As a test, see if you can mount the volume fragment within "Test Outer.tc". If your outer volume password is accepted it means that we've selected the correct location for your partition's starting offset, and it also means that your original outer volume header is still good. This would be great news. Don't bother trying to browse the volume using Windows Explorer, as it won't contain a filesystem. If you want to you can examine it using WinHex (select the logical volume that corresponds to the mount letter) and you will probably see some non-random (decrypted) data.

    Try mounting the hidden volume as well. If that works (e.g. if your password is accepted) then we're in great shape. All we'll have to do is recreate the partition using the same starting offset. Very easy to do using DiskPart, but you have to be very careful, as DiskPart can cause a lot of destruction if you screw up. I'll post steps if you get this far.

    If the volume can't be mounted (incorrect password prompt) then select the file in TC and then restore its outer volume header. Volume Tools: Restore header from external backup file. Then select the file and mount it. Open the mounted volume in WinHex and look for decrypted data. One "cheat" method is to search for 00 00 00 00 00, as follows: Search; Find Hex Values; 0000000000 (down) OK.

    If all appears to be random and there's no plaintext, no big blocks full of zeros or any other obvious patterns then we probably picked the wrong offset and will have to reassess things.
     
  11. Rakoen

    Rakoen Registered Member

    Joined:
    Jul 10, 2012
    Posts:
    14
    I just have been called for an urgent meeting. It's going to be a business trip of a week. The bad thing is that I actually need my data for this, however, I won't be able to take my harddrive with me. So expect me back here by thursday.

    I've quickly read your post however. The good thing is: I have a registered version of WinHex. As for the rest, take your time and if you feel like doing so, post a few things for when I get back. As soon as I'm back in Belgium, I'll re-read everything you've posted and complete/answer it properly.

    Thanks again.
    Rakoen

    PS: In the meantime you can get yourself a working monitor. Which one have you been using if I may ask? Or which one are you looking at now? As I have some experience in that area. I've had like dozens of monitors failing in the past (Philips for low quality builds and Samsung for bad shipping methods).
     
  12. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    991
    Location:
    Hawaii
    OK. I'll wait until you get back. Meanwhile, a bit more info for you:

    If you have a registered version of WinHex then you can save larger blocks to files. You can even save the entire partition as a file if you want to, and this is actually one of the recovery techniques. But for now, just make the blocks a bit larger, say 4MB or so, as this will include more actual data (probably just fragments, but still useful) to look at.

    If the 1048576 starting point doesn't work (password not accepted) then try starting a block at 32256, selecting about 4MB and saving that as a file, then see if it will mount without needing to restore the external backup headers. If it won't mount then restore the backup headers to the file, mount it and then use WinHex to look for decrypted data in the outer volume.

    I should have mentioned that the above numbers are decimal offsets, not hex. In WinHex, click once in the offset column to toggle between decimal and hex.

    We're trying to find the beginning of your previous partition by trial and error by testing for the presence of the TC headers, which are normally located at the very beginning of an encrypted partition. We're looking at the two most likely locations. Since there's a chance that the headers might be damaged, we're also testing to see if the data in the outer volume will decrypt when you restore your external header backups onto the file. If the data decrypts to non-random values (and you can usually see this by looking at the mounted volume in WinHex) then we've succeeded and can go on to the next step.
     
  13. Rakoen

    Rakoen Registered Member

    Joined:
    Jul 10, 2012
    Posts:
    14
    Alright, I'm back to business.

    I did exactly what you said. I also changed the ending block to "5048575" (as you suggested in your last post, 4MB). Happy to say that I have great news: I am able to mount both outer and hidden volume! Both passwords are accepted. Ready for the next step.

    Thanks.
     
    Last edited: Jul 19, 2012
  14. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    991
    Location:
    Hawaii
    Are you able to mount the test file's outer and hidden 'volumes', using either password, without first needing to restore the external backup headers to the file? This would be very good news.

    And just to confirm: Which starting offset did you use for this? 1048576 decimal?
     
  15. Rakoen

    Rakoen Registered Member

    Joined:
    Jul 10, 2012
    Posts:
    14
    As I said, yes, I am able to do that. Without restoring the backup headers, I am able to mount the "Test Outer.tc" file. That's why I called it great news too.

    I've indeed used 1048576 as starting offset. Decimal value.
     
  16. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    991
    Location:
    Hawaii
    You will find that the following instructions are overly cautious. I could just skip ahead directly to the partitioning operation, but it takes only a few extra minutes to proceed with a bit of extra caution, and you will also learn some new tricks. And just because the instructions are cautious doesn't mean that they aren't dangerous. They are.

    The next step is to perform a quick test to make sure the outer test volume (which is actually just a fragment of the outer volume, but it should be enough) is actually being decrypted, as this will confirm that the headers are in the right location:

    1) Select the test file in the TrueCrypt interface (Select File, etc.)

    2) Mount the volume to a free drive letter using the outer volume's password

    3) Open the mounted volume in WinHex (Tools; Open Disk; Select the same logical drive letter that you mounted the outer volume to in TrueCrypt)

    4) Visually examine the contents of the mounted volume. Are you seeing any non-random data such as recognizable words or patterns in the Text column, or any long strings of zeros (00 00 00 etc.) in the hex column? You should be, and if so this shows us that the volume is decrypting. If so then proceed to the next section. (Don't bother checking the hidden volume yet, as its data is most likely not included in the small test file.)

    Next we recreate your original partition layout, or as close to it as we can manage. We might lose a little off the end, and this will break your embedded backup headers, so make sure you still have your file containing the external TC header backups.

    This operation would normally be quite easy to perform using DiskPart (a component of Windows 7), but I'm not sure whether or not your Seagate virtual disk driver is going cause problems, so there is an unknown risk involved. I have no idea which program will take precedence, and if it's DiskPart then bad things will probably happen. The safest approach would be to make a sector-by-sector clone or image of the entire drive before proceeding, as a fallback.

    If you feel that you're properly backed up and are ready to proceed, here are the next steps, and be very careful, as DiskPart is capable of causing incredible and irreversible damage if you enter the wrong information:

    As far as I know, this procedure will only write to the first sector of the selected disk, which in your case has already been overwritten numerous times, but I can make no guarantees. The following instructions were written for Windows 7, so if you are using a different version of Windows then please let me know:

    1) To play it safe and to reduce possible confusion, disconnect any external drives that can be disconnected. It's OK to disconnect unwanted internal drives too if you like. Fewer drives = fewer chances to select the wrong one.

    2) Bring up the Run window and type DiskPart so we can run DiskPart at the command line inside a window. Approve any UAC messages that may appear.

    3) At the DISKPART prompt, type the following command:
    List disk

    4) Carefully look over the list of disks. Examine the size of each drive and identify the disk that we need to modify, then note down its listed drive number (in your case it will probably be Disk 2,3 or 4)

    5) Type the following:
    Select Disk <number> (For example, "Select Disk 4")
    Be very careful to enter the correct disk number or you'll be very sorry later! Diskpart will confirm that you have selected Disk <number>.

    6) Detail disk
    (review the displayed information to ensure you've selected the correct disk)

    7) List partition
    Are any partitions listed? There shouldn't be. I expect your disk to be completely raw unless you've recently altered it. If there are any partitions present, stop here, type Exit and let me know.

    Here comes the command that creates your new partition:
    8. Create partition primary offset=1024
    (the above offset is in KB, so this should result in offset 1048576 dec) Wait for the DiskPart prompt indicating success. Since we didn't indicate a Size, the partition should extend to the end of the disk, or as close as Windows will allow.

    9) List Partition
    (Oh, why not. We want to confirm that your new partition was created and has an offset of 1024 KB.)

    10) Select Partition 1
    (probably not necessary, but it doesn't hurt)

    11) Detail Partition
    More information. Look it over. Fun! The displayed offset in bytes should be 1048576.

    12) Exit
    That's enough fun with DiskPart.

    Now open TrueCrypt; Select Device; select Partition1 under the appropriate harddisk; assign a drive letter, choose Mount, provide the password for the outer volume, browse the volume using Windows Explorer and see if there is a functional file system. Browse your data if possible.

    Dismount the volume and then follow the same procedure for the hidden volume. Any luck? I certainly hope so. If so, you'd better back up that data right away! We still don't know why your disk failed in the first place, and it might happen again.

    If you aren't seeing any file system or data using Windows Explorer then examine the contents of each mounted volume using WinHex, as described above, and see if you can spot any decrypted data, especially in the first few sectors.

    I have to warn you that your embedded backup headers might be broken at this point, as the endpoint of the partition might not be exactly the same as it used to be. Until we fix this, make extra sure you keep some backup copies of your external header backup file.

    I'll wait to see how this all works for you. If you get stuck or don't understand something then back out of the procedure and let me know.

    Note to others reading this post: Don't follow these instructions verbatim! These instructions are specific to the OP's situation. Your situation might be different, and DiskPart is far too powerful and merciless to mess around with.
     
  17. Rakoen

    Rakoen Registered Member

    Joined:
    Jul 10, 2012
    Posts:
    14
    Interesting situation. Firstly, I mounted the file in TrueCrypt and opened the volume in WinHex to check if the data is decrypted. Yes, it was. I was able to see the name of a file I've stored on the outer volume. I also had long strings of zeros in the Text column. However, maybe I should mention this, but I guess it is normal: when I open the mounted volume in WinHex I get these errors:
    https://dl.dropbox.com/u/3062101/WinHex%20Error%201%20%5B20-07-12%5D.png
    https://dl.dropbox.com/u/3062101/WinHex%20Error%202%20%5B20-07-12%5D.png
    https://dl.dropbox.com/u/3062101/WinHex%20Error%203%20%5B20-07-12%5D.png
    https://dl.dropbox.com/u/3062101/WinHex%20Error%204%20%5B20-07-12%5D.png
    An explenation for this might be that I only had one file of a few KB's (if it even was that large) stored on the outer volume, nothing else.

    However, as I saw that file decrypted in WinHex, I went to the next steps. I've used DiskPart before (multiple times actually, but not on this disk) so I actually know how it works. An interesting detail is that I got the "DiskPart.exe has stopped working..." error when I performed "detail disk". However, after creating the partition, I was able to do it. I've included both detail disk and detail partition as an attachment.

    Everything went fine, except for the last things. I've created the partition with the correct offset, but however, TrueCrypt doesn't accept my password on the partition.
    https://dl.dropbox.com/u/3062101/TrueCrypt%20Error%20%5B20-07-12%5D.png

    So here I am. I didn't take any further actions as I don't want to mess it up.

    EDIT: If I'm right, I will just have to restore the backup headers to that partition now?
     

    Attached Files:

    Last edited: Jul 20, 2012
  18. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    991
    Location:
    Hawaii
    The error messages etc. are expected and are not a concern. They're caused by the fact that TrueCrypt's header indicates that the virtual volume is much larger than is actually present, so TC is feeding WinHex incorrect information. You can disregard all that. As long as it is decrypting we are fine.

    Yikes, I would have stopped right there. Some sort of conflict is occurring.

    You shouldn't have to, and I suggest holding off on that until we figure out what's going on. DiskPart shouldn't normally write to the partition unless you performed other actions, so the original header should still be good. If your password isn't being accepted, it could be because the partition definition is incorrect, in which case restoring the backup header might overwrite some of your data.

    In WinHex, I suggest you do another "copy block into new file" operation, using the same starting point as last time, and see if your saved file's outer volume and hidden volume can still be mounted in TC without needing to restore the external backup headers. This will show that the original headers are still intact.

    You're sure the partition is placed correctly? Since DiskPart might be having problems, I suggest you check it in WinHex. Open the Physical disk, then click once on Partiton 1 and note the offset it takes you to. Also, in the WinHex directory browser (near top of window), check Partition 1's entry, confirm that the 1st sector is at 2048 (LBA, x 512 = 1048576).

    If we can't figure out what went wrong with our current method then there's another whole approach we can try, although I'm not sure how it will work for such a large file. You can actually block/save the entire partition as one enormous file, which can then be mounted by TrueCrypt. Did the "copy block into new file" operation that I mentioned previously work as expected? If so, you merely do a much larger version of the same thing. Start your block at the same location (so that your TC header will be at the very beginning of the block), select the very large block of data that extends from that point to the end of the disk, and save it to another disk as a very large file. It'll take quite awhile, of course, and your system will need to have enough resources to perform this operation. I've never done one quite that large, so I'm not sure what the limitations will be.
     
  19. Rakoen

    Rakoen Registered Member

    Joined:
    Jul 10, 2012
    Posts:
    14
    Alright, this is what I've done. I've made a new "Test Outer [2].tc" file, using exactly the same method as before. I tried to mount it in TrueCrypt, but it gives me exactly the same error as when I mount the partition ("incorrect password or not a TrueCrypt volume"). To experiment a bit I've restored the external backup headers to the file "Test Outer [2].tc" and tried to mount it afterwards: it successfully did. To confirm that the data decrypts I checked it with WinHex and yes, I could still see the decrypted filename on my outer volume.

    If I'm correct, then this means the headers aren't intact anymore. Would restoring the external backup file hurt my data? However, the partition has been placed perfectly. I've checked exactly as you suggested: the offset for partition one is 00001048576 (decimal) and the first sector is 2048.
     
    Last edited: Jul 20, 2012
  20. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    991
    Location:
    Hawaii
    You could do that and it would probably work, but I'm still unsure why it's not working already, so if you're not in a hurry I'd rather try a little more testing. We're seeing too many weirdnesses and unexpected results to just leap ahead and try new things without understanding what went wrong.

    Using the newly created test file, did you try mounting the hidden volume as well, to see if that password is being accepted? (It doesn't matter if you don't see any decrypted data this time, as we just want to know if the password works.) The hidden header is much deeper into the file and should not have been affected unless you mistakenly formatted the partition or something like that.

    And I assume that you also tried the hidden volume password on the actual partition, with the same results?

    If both passwords are no longer being accepted in the test file then either your block selection was a little off when you created the second test file, or the partition definition is incorrect, or something wrote to the partition and screwed up the headers.

    I suggest you compare the second test file to the previous one that worked, especially the first sector, to see if there are any differences in the first sector (which is the TC outer volume header). Merely open both unmounted files in WinHex and flip back and forth between them, looking at the first sector.

    The first sector of your original test file should be identical to the first sector of the new partition (at 1048576 dec), so check that too.
     
  21. Rakoen

    Rakoen Registered Member

    Joined:
    Jul 10, 2012
    Posts:
    14
    ---currently in a rage of happiness---
    Unbelieveble. I just tried the hidden password on partition 1 and it just worked -> I was not only able to mount it, I am able to access all of my files ... undamaged! So I indeed didn't try the hidden password before.

    As this is interesting, I've compared the two files. Here I made a screenshot of both.
    https://dl.dropbox.com/u/3062101/Test%20Outer%20%5B21-07-12%5D.png [Working outer volume.]
    https://dl.dropbox.com/u/3062101/Test%20Outer%20%5Bafter%20partition%5D%20%5B21-07-12%5D.png [Unmountable outer volume.]
     
  22. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    991
    Location:
    Hawaii
    Well, that's just great news, and congratulations on regaining access to your data! I'm a bit surprised that the partition's first sector got zeroed out. What happened? Diskpart I guess, but I sure wasn't expecting that. Good thing we made header backups first. Anyway, I suppose you can just restore the outer volume's backup header and get that one back.

    However, don't do that yet. First you should back up your data onto another disk. Afterwards you can try mounting both volumes using their embedded backup headers, just to see if they still work. In TC it's "Mount Options; Use backup header embedded in volume if available." Possibly the embedded backup headers won't accept your passwords because the partition endpoint is different and TC can't find the backup headers in their usual location, which is relative to the end of the partition. We didn't try to set a specific endpoint, we merely allowed diskpart to go as far as it could.

    Then restore the outer volume's header from the backup file. I think at this point the embedded backup header will start working as well, but I'm not sure if this is the ideal solution. I'll have to perform a few tests to see.
     
  23. Rakoen

    Rakoen Registered Member

    Joined:
    Jul 10, 2012
    Posts:
    14
    Dantz, it's actually me that has to congratulate you for regaining access to the data. Really, I want to thank you. Do you have a "donate" button somewhere?

    The first thing I thought was "backup - immediately", so that's what I'm doing at the moment. It will take some time, but when it's done I'll try restoring the headers from the embedded backup.

    I've learned a lot from this interesting situation. It's good to know that others might have good use of this thread too. So to the readers, success on fixing your issue. This situation has been [solved].
     
  24. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    991
    Location:
    Hawaii
    I suggest you hold off on restoring the headers from your backup file unless you need to. I'm going to run a couple of tests to see what happens if you restore a backup header to a volume that has changed in size. TC might be able to rewrite the new header to match the new volume size, but if it doesn't then this step might cause problems. I'll post back soon with results.

    No donation is needed, but thanks for offering.
     
  25. mirimir

    mirimir Registered Member

    Joined:
    Oct 1, 2011
    Posts:
    6,028
    You are a hero, dantz! You too, Rakoen!
     
Loading...
Thread Status:
Not open for further replies.