Recover truecrypt container after chkdsk

Hi all

Here is my problem:
I have created a truecrypt container file on a USB Flash Drive (FAT32). The container has a size of 3 Gb and protected with a password. I don't remember which encryption I've choosen. The USB Flash Drive has a size of 32 Gb.

A day, last week, when connecting my USB Flash Drive to my PC (under Win7), it says that my USB Flash Drive is not lisible and I have not any access.

I process a "chkdsk /f" which found 10000 chk files of 32Kb and nothing else.
The USB flash drive seems empty

I tried recover softwares such as GetDataBack. It recovers many files, even those deleted many months ago ! But not the container one.

I used TestDisk but the only partition it sees is the one with the chk files.

I don'k know what to do to recover my truecrypt container.

Please help me !

Many thanks.

 

Any help?

 

That's a tough one. Lost TrueCrypt container files can be difficult to recover, especially if they're fragmented (which is likelier on a flash drive). I don't have time to go into any detail right now, so I'll post some ideas later. It's going to be fairly technical.

 

Thank you for your reply.

I've tried R-Studio and created an image. This image has the size of USB Flash Drive, 28.86 Gb.
When I extract (with 7Zip) the content of this image, it creates a folder with 10 000 chk files of 32Kb size and nothing else.

I've tried Recuva and many files are found, even some deleted ones, but not the container file.

With TestDisk, after choosing "Analyse", it says:
- warning: number of heads/cylinder mismatches 128 (FAT) !=255 (HD)
- Bad relative sector
So I came back and choose "Geometry" and "Heads" and enter "128".
Then I went to "Analyse", the warning disappears but I still have Bad relative sector.
I select "Quick Search" and "Deeper Search". Structure: Ok. When I continue (enter) then I can write or quit. I quit because because I'm afraid making things worse.

I select "Advanced" then "Boot". it says "Boot Sector ok" "Backup Boot sector bad".
First sectors are not identical
Second and third sectors idem

I select "Org.BS" but it says it can't overwrite FAT32 boot sector.

What can I do to recover my container?

I'm not confortable with WinHex. I don't know how to find the 1st sector of my container file and what to do and how to recover it.

As the container file is protected by a password, is it possible to recover some files hosted in this container?

Thanks for your help.

 

With WinHex, I tried to find the header but I don't know which string to search.
I tried de repair the partition but no success to recover the container

Any idea to help recovering my truecrypt container file ?

many thanks.

 

I haven't found a good automated solution for you yet. You can try doing it manually, but it will involve following a fairly lengthy WinHex/TrueCrypt procedure, and there can be no guarantee of success.

It's much harder to recover a lost TrueCrypt container file than a lost TC partition, as it can be located practically anywhere on the drive and it's not easy to identify. It might also be fragmented (especially on a flash drive), which makes matters much worse, as it's often hard to find the endpoints, and the reassembly of the file needs to be exactly right or it won't work.

You said earlier that you weren't comfortable with WinHex, so I have been somewhat hesitant to spend several hours (and that's really how long it will take me) to assemble and post a detailed procedure, much of which will involve showing you how to use WinHex and what to look for, just on the admittedly slim chance that it might actually work. I can post the steps, but there's a lot of decision-making involved, so you can't just follow them blindly. You'll need to become an experienced user. Do you have the time and the inclination to learn how to use WinHex?

Also, be aware that the evaluation copy is ok to get you started, but if we do manage to find your lost file and you want to recover it (by copying it, or some of it, to another disk) then you'll need to have a licensed copy, as the eval copy can't copy large blocks of data.

Still interested? If so, give me awhile to get through my current backlog of projects. We can stay in touch via Wilders' private message. When I get some free time I will post the steps in this thread. In the meantime, I suggest you start learning how to use WinHex. Specifically, play with "Navigation: Go to Offset: Relative to current position", try manually selecting blocks up to about 20KB in size, "Tools: Analyze Block" (and see if you can notice the difference between encrypted data and plaintext data), "Edit: Copy Block: Into new file", "Search: Find Hex Values: 0000000000" (both up and down) and more. I suggest you practice on a non-essential drive, and to play it safe, make sure "Option: Edit Mode" is set to "Read Only mode".

 

Hello Dantz

Thank you very much for your reply.
Many thanks for offering your help ! I don't want to annoy you though.

I understood that the only way to hope recovering my container file is to use WinHex.
Since, I've learned a little bit more about WinHex. I'm still not comfortable but I can do some actions.

The flash drive size is 32 Gb and my container file has 3 Gb. So I think the file would be fragmented. I read that it was one of the characteristics of TrueCrypt. I did an image of the entire flash drive and and I worked into it.

Anyway, I assume that the container file is continuous (it's easier to find )
because, I read that there is a big chance to have the beginning of the container file just after a huge amount of 00. I tried to define the start block from there and I define the end of the file just before the next huge amout of 00.
I save the block on a file but until now I have not the right size of the file. I keep trying but I think with this method it will take me a long time since I don't know exactly what to looking for. This is why I have posted again here.

I will follow your tips and find the difference between encrypted data and plaintext data.
Thank you.

 

Some news:

I found a large block, having the same size as the container file. In this block there is no adjacent zeros.
I'm pretty sure about the end of the block. But the beginning is an another story.

I tried with 2 different beginnings and each time, Truecrypt mounted it with "use backup header embedded.." option selected.

But when I access it, Windows says that I have to format it (there is no known file system).

How do I know the right beginning of the container file?

 

Sounds very promising! You're already getting pretty good at WinHex. I assume you've been reading some of my other posts that describe some of the necessary techniques?

As per the situation you just described, it's possible to mount a "rescued" volume using the embedded backup header even if the volume size is incorrect (e.g. wrong starting offset), but unfortunately none of the data will decrypt if you do it that way. You have to find the exact starting point of the volume. But you're very close to succeeding!

Mount the rescued volume again and then (in the TC interface) choose "Volume Properties". Note the exact size of the volume in bytes. This represents the size of your original volume without the four headers that normally surround it, so add 64KB x 4 (that is, 262,144 bytes) to that number to get the exact size of the block that you need to copy onto another disk. Start from the end of the block, of course, because that's the part you've correctly located, and watch the Size indicator in the lower right corner to ensure that your block size is identical.

Actually, I would test it first, before doing the actual copy procedure. I'd go to the location indicated, then grab a small (maybe 20KB) block from that location and save it as a file, then see if it can be mounted in TC using the expected password, just to confirm that the location is correct.

But even if the test file doesn't mount when you test the starting location, save the entire block anyway and try it again, because you should still be able to mount it using the embedded backup header, and this time (if the size is correct) I think it will decrypt. You can examine the mounted volume in WinHex to ensure that it contains decrypted data, even if Window complains (for whatever reasons) and wants to format it.

Incidentally, you can expect the starting offset of your lost file to be the first byte of a sector, that is, it will be located directly after a sector boundary, not in the middle of a sector or anything like that.

 

Re: Recover truecrypt container after chkdsk (solved)

Many thanks Dantz!

I follow your instructions :
- I mounted the volume and I noted the exact size, shown in its properties.
- I added to it 262,144 bytes.
- With WinHex, from the end of the file, I went up until I find the exact size, as you said.
- I saved this new block into a file and mounted it.

It works!!!! I found all my data intact. All my files are here !!!

Many many thanks, Dantz.

 

Congratulations! You're very lucky to have such a good outcome. Hope you're going to back it all up now!

 

Hi all,
I have almost the same Problem as Lelio:
I created with TrueCrypt a hidden file container on a IDE Drive. The size of the container was about 1.77 TB "and protected with a password. I don't remember which encryption I've choosen." (quote Lelio) Now Windows displayed that the container has the size of 0KB.

This is the "history".
My PC with Windows 7 did a sudden reboot while I was working with the opened container. I want to open the container again but TrueCrypt dont:"Volume is damaged or not readable." So I can't even get to the point to tell TC the password. I could read the file size ~1.77 TB but it was late so I decided to solve the problem the other day. The next boot sequence was followed by an automated "Chckdsk". I forgot to disable this task. I dared not to switch off the PC instantly as the task was already at 50% done. so I waited till it was complete.
I saw the file container with 0KB. I want to open it and I could enter my password but there was the TC Error msg:" Volume size incorrect."

I disconnect this drive and got a small SSD drive to install Windows 7, also. I downloaded a program on the small SSD to mirror the "bad" drive not to make bad worse. I mirrorred the 2 TB "bad" IDE drive to a 2nd 2TB USB drive. I payed attention to mirror even the "empty" areas. So i have now a 1:1 clone drive.

I got stuck after installing WinHex. May I ask for your help, please?

Shell I "undo" the changes of Chckdsk, and how? Thanks for any suggestion.
== Updates ==
1. instant e-mail notification
2. Testdisk_win on mirrorred disk with non partition, advancend, NTFS, *.BS
"Disk /dev/sdb - 2000 GB / 1863 GiB - CHS 243201 255 63
Partition P NTFS
Start 0 0 1 243201
End 80 59
Size in sectors 3907029164
Boot sector Status: Bad
Backup boot sector Status Bad
Sectors are not identical
A valid NTFS Boot sector mus be present in order to access any data; even if the partition is not bootable."
=> Rebuild BS

 

I analyse now with getdataback. Yet no Container found...Is there a possibility, that the clonedrive don't have exact the sectors 1:1...
= update =
I found something:
With getdataback i have searched the clonedrive "exessive for systemdata", without reparing it automatically. After some hours (2 TB) i have some results. First the program displayed me only recommended datasystems, but i clicked at "all"; and there are besides four green dots, ten red and one yellow.
Within the red dots there is a filesize 920GB. This could be the files within the TC Container.

NTFS at sector 2.048, Cluster-Size 8 (1,82 TB)
secors total: 3.907.019.264
1. Mft Cluster: 786.432
1. MftMirr-Cluster: 2
Mft-Entry-Size: 4096
Cluster total:488.377.408
Min. Cluster used: 488.378.389
Max. Cluster used: 488.377.408
Mft-Source: inconclusive
cross dating... 50073
Debug-Info: M2
----------
1. red
NTFS at sector 6.293.488, Cluster-Size 8 (1,82 TB)
sectors total: 3.907.735.676
1. Mft Cluster: 786.432
1. MftMirr-Cluster: 2
Mft-Entry-Size: 1024
Index-Cache-Size: 4096
Cluster total:487.591.959
Min. Cluster used: 487.591.959
Max. Cluster used: 487.591.959
Mft-Source: MftMirr
Cross dating... 866
Debug-Info: M1

2. red
NTFS at sector 1.977.667.424, Cluster-Size 8 (920 GB)
sectors total: 1.929.361.740
1. Mft Cluster: 786.432
1. MftMirr-Cluster: 2
Mft-Entry-Size: 1024
Index-Cache-Size: 4096
Cluster total: 241.170.217
Min. Cluster benutzt: 241.170.217
Max. Cluster benutzt: 241.170.217
Mft-Source: MftMirr
Cross dating... 2
Debug-Info: M1

(then 4 green followed with the rest red ones)
3. red
NTFS at sector 31.398.184, Cluster Size 1 (3,03 MB)
sectors total: 6.208
1. Mft Cluster: 2.058
1. MftMirr-Cluster: 5.162
Mft-Entry-Size: 1024
Index-Cache-Size: 4096
Cluster total: 6.208
Min. Cluster used: 6.208
Max. Cluster used: 6.208
Mft-Source: inconclusive
Cross dating... 1
Debug-Info: M2

4. red

NTFS at sector 31.404.376, Cluster Size 1 (3,03 MB)
sectors total: 6.208
1. Mft Cluster: 2.058
1. MftMirr-Cluster: 5.162
Mft-Entry-Size: 1024
Index-Cache-Size: 4096
Cluster total: 6.208
Min. Cluster used: 6.208
Max. Cluster used: 6.208
Mft-Ursprung: inconclusive
Cross dating... 1
Debug-Info: M2

5. red
as 4. red with Cluster0: 31.410.568

6. red
as 4. red with Cluster0: 31.672.968

7. red
as 4. red with Cluster0: 31.395.080 and
Mft-Source: MftMirr
Cross dating... 0
Debug-Info: M1

8. red
as 7. red with Cluster0: 31.401.272

9. red
as 7. red with Cluster0: 31.407.646

10. red
as 7. red with Cluster0: 31.669.864

 

I don't know of any way to undo the changes that chkdsk wrote to your drive.

Is this really a 1.77TB file we're talking about? That's a damn big file. Why are you calling it a "hidden" container? Typically a hidden volume is stored within an outer volume, and it sounds as though you've lost the entire outer volume and its container.

I also don't understand the problem you're having with your cloned copy. Why are you running TestDisk on it? Is it not readable by Windows? I don't know what software you used to make your mirrored clone, so I can't speak to the problems you're having. However, I would suggest using any imaging software that is capable of performing "sector by sector" cloning. Was the program that you used able to exactly duplicate the contents of unallocated space? Because that's where your lost file is.

Anyway, here's the general approach: All container files begin with a TrueCrypt header. You need to locate the starting offset of the lost outer volume, and then test it to see if the outer volume's header is present and intact. If it is then you can use WinHex to block/copy/save the relevant data as another file. If there is a hidden volume within the outer volume then at this point it should work as well.

Try this for starters: In WinHex, open either the physical disk or the logical partition where the file used to be stored, then locate the 0 KB file by name using the WinHex "directory browser". Click once on the filename to move your cursor to that location, then examine the hex and text data from that point onward. (We don't know if the location of the 0 KB file happens to coincide with the starting location of your lost file, but it might, so you might as well look there first.)

Your lost TrueCrypt file should consist of a very large block of completely random data. There should not be any patterns or recognizable text. If it looks ok then grab a 20KB sample using WinHex, and see if it works. (I've written how to do this in previous posts, but I can post it again if you need me to.)

Sometimes (depending on luck) a lost Truecrypt container file will be preceded on the disk by non-random data such as a bunch of zeros or other obviously non-random stuff, which makes it easier to identify the transition point between the other data and the starting point of your file.

If WinHex doesn't take you to the right location when you click on the 0-byte filename then you will have to do it the hard way by visually "probing" for the beginning of the file. Another approach would be to programmatically search for the lost header.

Have to warn you that I'm pretty busy at the moment and I won't be able to provide much in the way of step-by-step instructions.

 

Hi dantz,
i appreciate any time and idea you spend on my problem. I thank you very very very much. I wish you a happy new year and that yours starts a bit "friendlier" than mine.

So i will disable the auto-chckdsk task, since you can do that task manually, too.

It is a 2TB IDE bootable drive with Win 7. I changed my equipment and made the TC file container with almost the rest (besides Win 7 and some minor space) of the drive to have a kind of a backup. Just in case my main drive is broken by chance, i can immediately switch and catch some help via internet. Last time i looked at the drive, it was 1.77TB or 1.78TB sized but the container was not full. With TC you can do a encrypted container, and a hidden encrypted container. Then you have two passwords instead of "only" one. When you use one of the two passwords you either get the encrypted container or the "hidden" container within. It depends which password you use when you mount the TC Container. It is only one container to mount with TC. If you use password A you get "fake" files and if you use password B you get the correct file container (e.g.).

Jepp, i can't mount the TC Container with non of the passwords. It is the same error msg:" Volumesize is incorrect."

Orignal drive and Clone drive is readable by Windows. Last time after the chckdsk task was finished on the orignal drive Win 7 was running perfect. There is nothing i have to repair. Well there is no file i would miss, even when win 7 would not run. It is only the data (my backup) within the TC file container i miss. I was running TestDisk because I wasn't sure where to begin with. I thought, I can get a clue to get a starting point.

Jepp it was a sector by sector cloning. And I'm sorry, i can't remember which program it was. I downloaded several on my main drive, but they weren't that handy for me and i wasn't sure if they would do what i need. So i used something on a ubunto USB stick. If it is important for my help, i will make a research about it.

I did as discribed. Either i did sth wrong or there is no hex and text data. I clicked at File, Open and browsed manually to the name of the file container with 0KB and clicked at it. WinHex opend the 0KB filename and showed "Offset 00000000 and 0 1 2 3". It was empty, no entry on the white background. The greyed backgound was kind of "metadata": Name, Size, Creation time...

I read it. But i'm not that far to grab something.

I hope I have done something wrong. This sounds like a challenge to my luck. I have no clue what you mean with hard way and visually "probing". The only thing i could see was with getdataback. There was something huge 920GB. And that size isn't Win 7 only.

I wish I can help you with sth. Best I can do is to help other ppl instead.

 

You used WinHex to open the actual file. That's not what I meant. It's only a 0 KB file, so opening the file itself won't get you very far.

Instead, start with "Tools: Open Disk", then select the appropriate disk or partition and click "OK".

Now click once on the filename of the lost file (in the WinHex "Directory Browser" window that's just below the menus), and WinHex should take you to the portion of the disk where the file resides.

We're hoping that the 0 KB file starts at the same place as your lost file, but there's no guarantee here, we're just being hopeful.

Examine the data from that point downwards. Look in both the hex and the text columns. If our guess was correct then it should all look like totally random data, with no words or recognizable patterns anywhere.

Also, click the scroll "up" arrow a few times to bring some of the higher rows into view. See if you can spot any sort of an obvious transition point between your lost file's fully-random data and the data above it, just in case your file is preceded by something recognizable such as a bunch of zeros "00 00 00 00 00". (Get used to looking for transitions like this, because if this isn't the right one then you might have to hunt through a large portion of your drive looking for it.)

If everything looks good then you can try block copying the appropriate data (about 20KB total), saving it as a test file, and then seeing if it can be mounted in TrueCrypt.

 

I hope it was not wrong to click 2 times at the drive and WinHex started to "traversing". Only after that procedure there was another window to browse to the file container 0KB. In that Folder there were two Icons with same filename of my container. One Icon was white (like an unwritten paper/texticon without lanes aso) and the other was white with a question mark on it "?". The metadata differ only in Creation Time of about 30min. The "?" Icon was earlier built. Down below they also have differences in the cluster/physical/logical sector numbers.

When I hopp between the two Icons with my Arrow Keys almost all figures/chars change but some don't. When I select the numbers with my cousor the text on the right hand in that browser window is also selected. I only can read "File" and the name of my file container. The rest is kind of tohobohu. In both Icons the same but other huddle.

I see that bunch of zeros right above that position you described. There are 18 lanes and 15 columns of zeros. In the 14th/15th column there are sometimes no such zeros. The bunch (not the lane) "starts" and "ends" like this: 11 01 or 05 00 or 10 01...

When i save that block (from 00 to last 00 of that bunch) to a new file the size is 1KB. Up to now there is no such huge bunch of zeros to match 20KB.

Thanks for the help, the prompt reply and your time and patience.

 

You need to select a 20KB block that begins at the very beginning of your file (that is, the spot where WinHex places your cursor when you click on the filename). The data that we want begins there and goes lower. It should all look completely random, and thus it should not contain any large bunches of zeros.

In the WinHex Directory Browser, click once on the filename (do the one with the "?" first, as that most likely represents your deleted file), and notice where your cursor lands in the data. We're goint to select the data from that point downwards (assuming it's not all full of zeroes, that is. If it is then let me know.)

If your cursor is in the correct position then do the following:

Edit: Define Block

under "Beginning", select "Current Position" from the dropdown box

Note the offset number that appears directly under the word "Beginning"

Copy that number into the box under the word "End"

Edit the number by adding 20000 to it.

Click OK. WinHex should now be highlighting the entire block.

Look at the "Size" indicator in the lower right corner of the screen. It should say 20001, but anything close to that is fine. (If you're way off then press Escape to cancel the block selection, then start over.)

Ok so far? then proceed to save the test file, as follows:

Edit: Copy Block: Into new file

Use the file save dialog box to save the file. Give it a descriptive name (such as HeaderTest1.tc) and choose a different location for the file. Make sure you save it to a different partition or an entirely different disk so you won't risk overwriting your lost file. Even a USB flash drive would be fine, just make sure you don't save it in the partition that you are currently working in. Nothing should be written to that partition until you have recovered your data.

Click Save to save the file.

The file will automatically open in WinHex, but we don't need to see it. Close the tab by right-clicking on it.

Close WinHex

Open TrueCrypt

Click on Select File, choose the test file, assign a drive letter and try to mount it using your usual password. If the password is accepted then you've found the correct starting location, which means that now we can go on to save a much larger piece of your lost file.

However, if you see the "Incorrect password or not a TC volume" message then we've most likely picked the wrong starting point.

 

Jepp, that is my status quo. Although I have two diffrent passwords, one for the fake container and one for the true file container, but both didn't work. I did the password setting "display password" at TC so there is no error with the input of these passwords. And i did the same procedure with the white icon, without the "?" in it:"Incorrect password or not a TC volume".

The filesize at WinHex is 20001. Windows Explorer said it is 19.5KB after saving with WinHex named "HeaderTest1.tc" and "HeaderTest2.tc" (for the one without the "?") And I saved it at my main drive and not at the drive i want to "restore".

 

Looks like things are going to get tougher, but before we get in too deep I suggest you try this:

For practice, create a small container file (in a different partition, please, so you won't risk overwriting your lost file).

It can be quite small. 300KB will be large enough. Make sure you can mount it and that it works normally.

Then dismount the volume and try using WinHex to try to recover its header, following basically the same techniques that I described in my previous posts. Make sure you aren't making any mistakes and you can do it easily. Notice what the header looks like (random), and compare it to the data that is just before the header (probably not random, but it might be). See if you can visually spot the transition point.

Then try it again with your lost container file, just in case you somehow got it wrong the first time you tried it.

The above will be good practice for you, because you might have to do this sort of thing a number of times while you try to locate the actual starting point of your file. Of course, there are some tricks that I can suggest that might make things a little easier, but first perform the above practice session to ensure that you are very familiar with the procedure.

PS: If you want to test both the hidden password and the outer password then you will need to create a larger test file, as 20KB is too small to include the hidden volume header. I think the test file would need to be at least 65KB for that to work, and making it 128KB (131,072 bytes) would probably be better. Testing both passwords might be useful if only the volume header was damaged. I haven't really played around with that idea so much, but now that you know the general techniques you can try it yourself and see what works. Please let me know how it goes.

 

Ok. I got a little more practice now. It was quite easy at the end. I could mount the defined and copied block "Into a new file" with TC. At start of the practice there was same error msg:"Volume password incorrect..." and i suppose the failure was, i didn't dismount the small TC in TC progam before examining it with WinHex.

My main drive is a SSD. I practiced with data on that drive. The clone drive is a USB 3.0 non SSD.
Perhaps i noticed something while comparing the opened TC container with WinHex. The 300KB container has a bunch of zeros (10 lanes) before the "current positioin" and they all are zeros even column 14 and 15.
The big container has also a bunch of zeros but sometimes they are "framed", in column 14th or 15th there are non zeros at the start and at the end of a block of zeros...sometimes...in that columnes there are other numbers like 05 00 followed by a bunch of zeros and at the end of 10 to 15 lanes in columnes 14/15 there are the same numbers again e.g. 05 00. It looks like a frame.

Somehow i hoped i did wrong first time. Well, after the practice i tried again with the lost container file and can't mount it with TC. I even clicked at "dismount all" even there wasn't any container mounted, shown in the TC box. And again the error msg:"Incorrect password or not a TC volume".

Well, the container is 1,77 TB...i think i would like any hint to make the procedures easier. May I ask you to tell me at least one of them, please?

My password is long...perhaps 20KB was to small, also. In a PC Calculator I added with copy and paste 131,072 to that "current position" with the icon + "?" on it but same error msg:"Incorrect password or not a TC volume". Same to that pure white icon file.

 

The lost, unmounted file consists of totally random data from beginning to end. You need to find the endpoints, which are sometimes (but not always) visible in WinHex as a transition point between a very large block of random data and some plaintext (non-random) data. However, since your 1.7GB file fills most of the 2TB partition, the file is probably fragmented because it is forced to span the MFT, in which case there will be more than two endpoints. Your file might look something like this:

[Plaintext preceding file] [Huge block of random data, probably larger than 1TB] [MFT] [Smaller block of random data] [Plaintext past end of file]

Be aware that what I'm calling "plaintext" can look like anything. In many cases you can't visually tell it apart from random data. By "plaintext" I merely mean that it is not encrypted (for the most part, anyway).

The most important location you need to find is the starting offset of the lost file. That's where the volume header is stored, and it's also necessary to know where the starting point of the file is in case we need to restore the backup header (if we can find it).

I would start looking for it by opening WinHex, opening the partition, placing my cursor somewhere within the huge block of random data, and using the WinHex "Search" command to search backwards for 00 00 00 00 00 (hex). This sequence is very common within most file systems but is almost never found in random data. When WinHex finds the zeros, your cursor will probably be very close to (and prior to, that is, above) the beginning of the lost file.

Set up the WinHex Search like this:

Open the partition

Place your cursor somewhere within the large block of random data, but still fairly close to the front of your disk (otherwise it will take too long).

"Search: Find Hex Values"

Type ten zeros in a row (with no spaces) into the search box: 0000000000

Set the search direction as "Up"

Click "OK"

The search should run for awhile, indicating that it is searching (and traveling upwards) through a large, solid block of random data.

Eventually it should stop on a block of zeros. At this point you can look around (down, that is, since the search went up) and see if you can find an obvious transition point between the plaintext that you are in now, and the huge block of random data that follows it. Sometimes you can spot it, sometimes you can't. If you think you're close then you can test each likely spot by creating a test file that begins at that location. It will almost always begin on a sector boundary, so don't waste your time selecting inappropriate blocks.

If this doesn't work then you might want to look into obtaining a program that will "walk" through the drive while it runs a similar testing procedure on each sector. You can start it at a likely location and then let it run. I've heard of one in the past, but I've forgotten what it was called or how to obtain it. You'll have to search for it. (Meanwhile, I'll try to see if I can remember what it was.)

It's also possible that your volume header was damaged during the accident, in which case no amount of searching will find it. In that case you will have to look for the embedded backup header and try to use it to recover the volume. If the file isn't fragmented then it should be doable, but if the file is fragmented then there will be gaps of unknown size between the blocks of encrypted data, and things will get very tricky.

Anyway, start with the backwards search and see how you do. I'm curious to know if it will take you anywhere near the location that WinHex took you when you clicked on the file with "?" in the name.

 

Thanks for the hint, the good describtion and and and...my pc is working on that task looking for 0000000000 (hex) "upward" and this will take some time. I just came in to tell...i will edit the end of the search...i think it will last some hours. The pc started at 53%...i thought wow that will be a good speeeed at first glance, but now (1% = 20min and more if it runs in the background)...and manually looking at 1.7 TB downward, i tried for 10min...even when i do "ctrl"+mouswheel to zoom in and out...for my eyes and the concentration...this is kind of torture. Since i have no clue to continue in case i have to shut down the pc...

== update ==
70% done....since you have to click "ok" for the WinHex evaluation copy; otherwise it doesn't continue to search until you do confirm the popup window.

 

You started too far down. Your 1.7TB file fills most of your 2TB disk, so the "leading edge" of the giant block of random data can't be any farther in than approximately .3 TB, which would be somewhere around the 15% mark, and it's probably a even closer to the start than that. You can add a few percentage points for good luck, but you don't have to go all the way to 50%.

 

ok...i did start over again at 84%...i was a little bit worried about that - kind of loosing the "results" if i quit at 78%. But i remembered that the first search startet with 53% that was really the point i set and not that the pc/program was so fast to do 53% in no time and the others in snail speed. 16% will last about 1d after all since noone will click ok to continue the search when WinHex pops out with its evaluation notice.

== update ==
No time to sleep, when sth has to be done.
WinHex Search got to an end (97%) and found something at
beginning point 61337200160 starting with 5 lanes of zeros downward and 15 columnes in a row.
The "small" zero block ends at 61337200239 with 0...C8
I did as you described here:
https://www.wilderssecurity.com/showpost.php?p=2326760&postcount=18
defined the block from 2 lines above the zeros lanes (where the block has a small dark/grey line...+20000...copy into a new file. Closed WinHex, opened TC mounted...incorrect passwort or not a tc file...i did it again with the exact position (instead of "2lines above) when the zeros started...same result.

I started search again 97+
= update =
and again some results quite after starting with no success:
61026907744 with 26 lanes of zeros
60889737136 with 2 lanes of zeros
60800299344 with only 00 00 00 00 00 (and no other)
...