Help me! Erase my truecrypt container

Hello Friends.

Last month I delete my Truecrypt container in 500GB HD, My file has 200GB.

I already read all posts, specially from "DANTZ" member.

I studied winhex and bought the program.

My current status

I see my trucrypt container with 0kb

I found 139,30 GB no "0000000000" - Begin sector 704.690.552 End 976.751.935 inside my file 0kb

More I not find 200GB no "0000000000"

I have Small sector with 3gb, 10gb no Sequential

I think my file is fragmented, I do not know what to do.

Sorry i Live in Brazil, my English is google.

Thank you

 

Recovering a deleted TrueCrypt container file is one of the hardest things to do, mainly because it's so hard to find the file's exact starting point. If the file is fragmented then the situation is even worse, because then you have to find all of the fragments and assemble them in perfect order. I sympathize with your situation, but I can't hold out a lot of hope here. Maybe you will be able to recover the first fragment, and some of your data, if you are lucky.

It sounds like you have found a large chunk of encrypted data that might belong to your missing file. Have you decided which starting point you want to try, and then used WinHex to save a small block of it as a test file, and then tried mounting the test file using TrueCrypt?

 

Hello Dantz,

Thanks for helping me

I created small files of 20k from sector 704.690.552.

Open in truecrypt but error "Incorrect password or not a TrueCrypt volume"

Close all, separate new 20k more begin 704.690.551 with less 512bytes new test and error again

Several tests always decreasing 512bytes unsuccessfully

If I recover part of the file I'll be happy

I read on a website that truecrypt header has ASCII string "TRUE" in offset 64

I found several "TRUE" in ascii but I got lost

I hope you can help me.

Happy 2017

 

Hi All,

Using the tool Analyze Block from winwex together with Excel I check similar graphics for files truecrypt very different from other files.

Zip for example is similar but has different curves in the excel chart



In any space of the file the graph is similar

Encrypt file has a symmetric curve at the beginning and at the end

Anybody know something about this?

 

Hmm, interesting graphs. Is the zip file encrypted? I do know that the TrueCrypt team put a lot of effort into ensuring that their RNG produced the best possible random-looking output.

RE your previous post: You don't need to look for the "TRUE" string. If the test file mounts in TrueCrypt after you have provided your password then this is confirmation enough that you have found the header and (probably) the beginning of your lost file.

Manually searching a disk for the beginning of a lost TrueCrypt container file can be an extremely tedious job, even when you know approximately where to look. I've successfully done it a few times, but it always involved the ability to drastically narrow down the search area, plus a bit of luck.

To speed things up, some users have written scripts that walk the drive (or selected portions of it) sector by sector, testing for the TrueCrypt header on each sector. Basically, they automate what you are trying to do manually. I wish I could tell you where to find such a script, but I don't currently have any notes about that. I suggest you do an online search. I will look as well, and if I come up with anything I'll let you know.

If you do look for it online, you will probably come across tools such as TCHunt which are designed to identify potential TrueCrypt containers by testing existing files one by one, but that's not what you need. Since you are looking for a deleted file that now resides in free space, you need something that is designed to work within free space, not within the file system.

Update: I did a quick search and I noticed this post:
https://www.wilderssecurity.com/threads/truecrypt-volume-how-to-identify-the-header.300293/
Awhile back this Wilders member wrote a python script that pretty much did what you need. However, it sounds like he didn't realize that he only needed to select blocks that begin on sector boundaries, not at every single byte. He could have made his script run much faster if he had done that.

He did not post his script and he hasn't been heard from since, but I'm sure there are other scripts out there. In fact, I have decided to try writing one myself, but I'm going to cheat by using AutoIt in combination with WinHex and TrueCrypt. I'm sure there are better ways and they would probably run much faster, but I don't have the time to put in a major effort. I'll let you know how it's going.

 

Hello Dantz,

How are you?

The zip file no encrypt is normal zip.

Following your tips I always use 20k bytes for testing

A script would be great for reducing the work.

The graphs excel the lines are more detailed with minimum files of 100kb

I have hope, study a lot winhex and help from friends like you.

 

Very difficult to find this file

I found that zip file has a signature "504B0304" Hex, this way I can decrease the size of the test file.

I am separating files without "0000000000" and without "504B0304"

But I still have a lot of data to search, it's very tiring and time-consuming

I do not want to stop the search, but I need more tips.

Dantz friend any magic tip?

 

For testing I created a new truecrypt file on a 16GB pendrive.

The new file has 1gb

I know exactly where the file starts and ends.

But doing random search on pendrive I can find parts without "0000000000" and without "504B0304" which I'm sure is not the truecrypt file.

If I was in a real situation I would lose a lot of time with something that is sure not to be the file you are looking for.

How to make sure the file is a true part of truecrypt

I am sure that searching blocks without "0000000000" is almost impossible success.

I continue in the fight

 

It's possible to modify all of your existing files such that they will stand out, thus showing you which areas of the drive are already in use and thus don't need to be searched. You merely replace the contents of every single file with a repeating byte pattern of your choice, such as AA. (I suggest you don't use 00 for this purpose, as that is obviously already in use.)

WinHex can do this. Of course, doing so will completely destroy all of your files, so I suggest you do it only on an exact (forensic) clone of your drive. I haven't done this in a long time and I will have to confirm the details, but basically you use the Wipe Files command. First, though, you use Edit: Fill Block and set the wipe pattern to be a constant value (such as AA). Please test this before you commit to it, as I have forgotten the details and don't have time to play with it right now.

WinHex also has a "highlight free space" command that might be useful in a similar way, but it is only available if you have a higher license.

Keep in mind that since your lost container file resides in free space, it is at great risk of being overwritten, even by automatic processes that you can't control, so you should be doing all of your data-recovery work on an exact clone of your drive. The original drive should be disconnected and set aside. You can use your original drive to create another clone if you happen to mess up the first clone, and ideally that is all you will be doing with your original drive.

 

Incidentally, the reason it's so damn hard to find a lost TrueCrypt container file is because the developers intentionally designed them that way. All TrueCrypt volumes, including container files, have fully random headers in order to make them harder to identify. So you are essentially struggling to overcome one of the program's main design features. It can be done, but it's not fun.

 

Thanks Dantz

I'm going to buy an HD that I can clone the original and use its information.

Previously I had moved all the files to another disk, But with winhex I can see all the files in HD.

I will make the clone of the drive and send new information.

Thank you again

 

Hello Dantz,

I am having a question with the HD partitions.
If I use Logical Volume the offset number is different from Physical Volume

Example: Test.jpg file
Open Disk Logical Volumes.
The test.jpg file starts at offset 38.601.784 - HEX 25 50 44 46 2D 31 2E 34

If I open Physical Volume
The test.jpg file starts at offset 9.351.232 - at the same hex address

I do not know why this happens.

I have one more question

When I double click on the file test.jpg the file opens a new tab and I can see the beginning and end of the file, hexadecimal and Asci, in the new tab "test.jpg".

When I am in the "Hardisk" tab and click on the test.jpg file the hexadecimal sequence is not the same it is not continuous as in the "test.jpg" tab.
The start of the file has the same hexa, more after 300kb I do not have the same hexa sequence that only appears in another part of the hardisk, getting a space with hexa values different from what is in the "test.jpg" tab.

If I am putting FF as you suggested, it is likely to be modifying data from other files.

I do not know if I could explain.

 

WinHex's position offsets are relative to the object that you open. If you open a physical media (an entire drive) then the offset of very beginning of the disk will be zero. If you open a logical volume (a partition, usually) then the offset of the beginning of the partition will also be zero, no matter where the partition is located on the physical disk. If you open a file, the beginning of that file will also have an offset of zero.

If I am looking for something within a partition then I will open the logical volume/partition and work from there. If I am looking for something that might be anywhere on the disk (i.e. on a disk that has either lost its partition table or is unformatted) then I will open the entire physical media. And if I decide to open both at once then I do not expect the offsets to be identical, but if I need to compare them then I will look at the information panel on the right side of the screen, as it shows both the Logical sector No. and the Physical sector no. for the current location of the cursor. (Note: The information display will be different based on whether you have opened a Physical or a Logical volume.)

I am a little surprised to see that test.jpg's starting offset seems to be higher in the Logical volume than in the Physical volume. I would expect just the opposite. Perhaps I don't quite understand you, or perhaps you wrote down the offset numbers incorrectly.

RE your second question: The likely reason that your test.jpg file appears to have different contents when you view it within a partition, rather than opening the file all by itself (that is, under its own tab) is that the file is most likely fragmented. The partition view shows the file's clusters as they are actually laid out on the disk, whereas if you open the file directly then for display purposes WinHex will assemble all of the file's sectors and clusters into one contiguous view.

There are a couple of ways you can observe this:

1) (This only works if you have opened a Logical Volume): Watch the filename, as displayed in the information panel on the right side of the display. If you place your cursor within a sector that contains a fragment from a different file then the displayed filename will change. If you scroll down a little then you might see the name change back to the original file.

2) In the directory browser (in the top half of the window), right-click on a file that you want to examine, then choose Navigation, List Clusters. Every cluster that contains a piece of the file will be listed, and you will notice that many of the clusters are listed in numeric order. If they are not then the file is fragmented, and in fact at the bottom of the list WinHex will tell you how many fragments there are. (Note: a cluster usually consists of 8 sectors if you accepted the default cluster size when you formatted the disk.)

PS: I am leaving tomorrow for a short trip, and I won't be checking the forum (or going online at all, actually) until I return about 9 days later.