truecrypt volume error

Discussion in 'encryption problems' started by zorkling, Jan 12, 2014.

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

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    1,034
    Location:
    Hawaii
    I've read through everything and considered it all, and I think that we ought to try to create another test file, a larger one. Then we'll mount it in TrueCrypt, we'll examine the mounted volume in WinHex and we'll look at it very carefully for any signs of decrypted data. I know that we've failed at this already, but it really ought to work, since your numbers from the beginning of the thread indicated that you almost certainly used to have an encrypted partition that began at offset 32256. So I want to give this one more try, if you don't mind.

    I will try to be ultra-precise with my WinHex instructions so we will be sure to get this part right. Please follow along and bear with me:

    1. Open WinHex (you may need right-click on the WinHex icon and choose "Run as Administrator").

    2. For safety, ensure that you are still in Read-only mode. ("Options: Edit Mode: Read-only").

    3. Close any other files or disks that WinHex might already have open. Merely right-click on each tab and choose Close.

    4. Open the physical disk that we've been working on. ("Tools: Open Disk" and select your disk under "Physical Media").

    5. Make sure you can see both the hex and the text display. That is, click on the "View" menu and uncheck the "Text display only" checkbox if you still have it selected.

    6. Make sure your offsets are still displaying in Decimal mode. In Decimal mode your Offset column headings should begin with column 0 and end with column 15. (If you are in hexadecimal mode then the columns will instead display as 0 through F.) You can click in the Offset column to toggle back and forth between the modes, but end up in Decimal mode.

    7. OK, let's do this! We'll create a 20 MB test file, very carefully. Just use my numbers:

    "Edit: Define Block"
    fill in the numbers and settings as specified below:

    Beginning: 32256 (beginning of block)
    End: 21003775 (end of block)

    Click "OK"

    8. Look in the bottom right corner of screen. The "Size:" should be exactly 20971520, which just happens to be exactly 20MB. We don't require the block to be that exact size, but this is a good cross-check to ensure that you're entering the numbers correctly.

    9. "Edit: Copy Block: Into New File"
    Give it a good descriptive name such as "20MB Testfile.tc" and specify a location on a different physical drive, then click "Save".

    10. WinHex automatically opens the new file in a separate tab, but we don't really need to see it here. Please close the unneeded tab by right-clicking on it and selecting "Close". Then close the current disk by right-clicking on its tab. Then close WinHex entirely.

    11. Navigate to the newly created file "20MB TestFile.tc" and double-click on it to open the TrueCrypt interface, with that file already selected.

    12. Click on a free drive letter. How about "X"? If X is available, let's use it. Otherwise pick whichever one you like, but I will call it "X".

    13. Enter the password and click OK. This had better work!

    14. OK, assuming that your password was accepted and the volume has mounted to drive letter X, open WinHex.

    15. In WinHex, "Tools: Open Disk", then choose "X" under "Logical Volumes".
    Ignore any error messages WinHex displays about invalid file systems, unreadable sectors, etc., as these messages are expected in this situation. The test file is just a small fragment of the lost volume, so we can't expect it to have a complete file system. All that we are trying to do right now is to find some decrypted data so we will know we are on the right track and can move forward to the full recovery attempt.

    Now comes the fun part. We want to see some non-random data in order to prove that the volume is decrypting. It can be anything, and it doesn't have to be much. A recognizable word or two, or a single large block of zeros, will be sufficient.

    16. Look in the Text column first: Look for recognizable words such as "NTFS", "disk", "read", "error", "partition", "FAT", or groups of sequential numbers "1234567 etc." or sequential letters "ABCDEF etc.", or anything else that has a pattern or looks like it might actually mean something.

    17. Also look in the Hex columns: What we want to see here is large groups of zeros such as "00 00 00 00 00 00 00 etc.".

    Do you see any of those things? If not then you are probably looking at a big block of random data, but don't lose hope, maybe there will be some decrypted data farther down.

    18. Scroll down a ways if you haven't found anything yet. I suggest you do this by clicking once in the data, and then hitting the PgDn key repeatedly. (The scroll bar is less useful in this situation, since it goes so fast that it will shoot you right out of your 20MB test file and into the imaginary portion of the volume that is filled with "UNREADABLE SECTOR" entries. If you do go too far, just back up to get back into the real data again. We don't care about that part of the volume at all, as it's only there because TrueCrypt has basically lied to WinHex about how large the actual mounted volume is. WinHex can tell that it's not genuine, but it's still willing to display it.

    19. Have you found anything yet? If not, try this:
    "Navigation: Go to offset:"
    enter 20840448 into the new position box (this should put your cursor right near the end of the actual data, where it changes into the "UNREADABLE SECTOR" zone.)

    Make sure "relative to" says "beginning"
    Click "OK"

    "Search: Find Hex Values"
    "Type "0000000000" into the search box (that's 10 zeros in a row, without the quotes)
    Set the search direction as "Up"
    Press "OK"

    20. Let it run for awhile. It will either find a large block of zeros, or it will hit the beginning and stop.

    I'll wait for your results. If you have any problems along the way then let me know which parts didn't work as expected.

    Oh and by the way, don't delete all of your old test files yet. Keep at least one of them (as long as it can be mounted, that is). It will be a good source for a header backup, in case we need it later.
     
  2. zorkling

    zorkling Registered Member

    Joined:
    Jan 11, 2014
    Posts:
    40
    Location:
    U.S.
    Neither testfile (I made two) brings up zeroes when I search, but in the more recently discussed physical media I immediately see legible words and zeroes when I view it in WinHex. Here's a screencap:
    http://imgur.com/mMerdzF
    The zeroes end at offset 32556 and the letters refer to the missing partition or something. The other drive you helped me with from the start of the thread doesn't behave this way.
    I hope this is some kind of good sign.


    Also there's zeroes at the bottom of the physical media but I can't pinpoint the exact start of them.

    never mind, those aren't in a row. but the words mean something I hope.
     
    Last edited: May 5, 2014
  3. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    1,034
    Location:
    Hawaii
    Your screenshot shows the boot sector, which doesn't really help us much. That portion of the disk is never encrypted when you encrypt a partition, so it always looks like that. Please examine the disk farther in, past 32,256 (decimal) and beyond. Are there any legible words and/or zeros visible in that area? This would imply a possible overwrite of the volume.

    An encrypted (and unmounted) volume normally looks like totally random data from start to finish. If it was overwritten (i.e. formatted, or something like that) then it will contain many blocks of zeros, plus various other recognizable patterns.
     
  4. zorkling

    zorkling Registered Member

    Joined:
    Jan 11, 2014
    Posts:
    40
    Location:
    U.S.
    It ended at 32556, along with any legibility. It doesn't seem to be behaving in an expected way, even for a malfunctioning volume.
    At least this one has a boot sector, the other one doesn't have anything. Does that mean there never was a partition on that one?
     
  5. wd4418

    wd4418 Registered Member

    Joined:
    May 21, 2014
    Posts:
    2
    Hi DANTZ I think I have the same problem, but without solution yet, please help me. As other complaints I lost my data. Several pictures from years.

    Is there another tool instead WinHex that is free and we can use?

    My problem: In April, 2010 I was using the truecrypt. I used this in a pocket HD of 1Tb. I criated just 10 Gb of a virtual disk. Not all disk was encrypted, but just 10 Gb, enough to put my pictures and movies. Once I was cleaning the disk and removing doubled files. I did not touched the file created by truecrypt. Tested and everything was ok. So, I decide to change the file from the 1 TB disk and move to another one with 1.5 Tb. I moved and deleted the file from the first disk.
    After that I tried to access the files, but appeared on screen just strange characters and was not possible to access and see nothing. Since now I can the folders but strange names and files. It seems that the size of files are kept, but when i click above to see the file, the message "the way specified does not exist" appears. And when i try to access a folder, appears a message with name file syntax wrong.

    So, yesterday I was looking for some news about my problem, and a possible solution and saw your post above.
    I tried to follow all steps, but I have just a trial version of winhex and this is limited to save just 200 kb files.
    If I have sure, the problem will be solved with this winhex I will purchase the full version, but I'm not confident yet.

    Please, could you help me?

    As additional information, the problem happened in a desk top computer with windows XP. I turned off that computer and still waiting for a solution, since 2010. I copied the file encrypted to my notebook and I am trying to recover here. Using the truecrypt, I may recover the strange files, using the original password without problem.
     
  6. zorkling

    zorkling Registered Member

    Joined:
    Jan 11, 2014
    Posts:
    40
    Location:
    U.S.
    Something else I've noticed is this "island" of variation on the volume:

    http://i.imgur.com/0UXm8hX.png?1

    does this imply anything about the volume? I know it's not legible, but I thought it might mean something.
     
  7. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    1,034
    Location:
    Hawaii
    I don't know. I'm fairly baffled by your situation, sorry to say. The test files mount, but the data does not seem to decrypt. Using the wrong headers could do this. Doubly-encrypted data could do this. A complete overwrite of the encrypted volume while it was dismounted could do this. But none of your explanations point to those things. I'm sorry, I don't know what to suggest next. Let me know if you figure anything new out.
     
  8. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    1,034
    Location:
    Hawaii
    There is a decent freeware hex editor named HxD. Here are some links:
    http://mh-nexus.de/en/hxd/
    http://mh-nexus.de/en/hxd/StarManSaveSectors.htm

    However, a hex editor might not be all that useful in this situation. There's no point in using WinHex or any other hex editor in an attempt to recover your volume's headers, as your problem does not sound like it is related to the TrueCrypt headers at all. (I suppose you could use the hex editor to try to examine your damaged files, but that particular task requires a lot of experience, much more than I can convey in a short post).

    It sounds like the data that was stored within your volume has become damaged. TrueCrypt itself is working, right? You are able to select a drive letter, enter your password, and mount the volume? If so then the TrueCrypt headers are intact and they are working fine.

    I think the problem is that your volume's actual contents have been damaged, probably due to some sort of corruption that occurred during the file transfer. This is not really a TrueCrypt problem, it's a data or a file-system problem.

    As I recommend in many cases like this, you should use several different data-recovery programs to explore the mounted volume to see what can be recovered.

    I'm sorry I can't spend very much time helping you with your problem at the moment. I am trying to keep up with the forum requests, but I am actually falling behind and I am also quite busy with my work. A lot of people want my time right now.
     
  9. wd4418

    wd4418 Registered Member

    Joined:
    May 21, 2014
    Posts:
    2
    Thanks Dantz. I appreciated your help.
     
  10. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    1,034
    Location:
    Hawaii
    You're welcome. Sorry we didn't solve your problem, but there's still hope. Post back if you have any new insights.
     
  11. zorkling

    zorkling Registered Member

    Joined:
    Jan 11, 2014
    Posts:
    40
    Location:
    U.S.

    I agree it's perplexing. These volumes never behaved in an expected way, and they didn't decrypt according the methods you posted here. It seems to indicate that they were made differently, or else suffered some kind of catastrophic failure which totally messed up everything.
    My only other idea was that maybe they were wholly encrypted and RAW from the start, and should be treated as such, but the 32256 offsets contradicts this.
    What's even more astounding is that this happened not once, but twice to two separate volumes, and whatever happened was unknown and irreversible. For all I know, I made it worse because I don't really know what I'm doing.
    Nevertheless, thanks for your assistance.
     
  12. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    1,034
    Location:
    Hawaii
    Yes, and that's the strangest part. We're probably missing something obvious, and we ought to be able to solve it. I'll think about it some more.
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.