Deleted truecrypt partition via Disk Manager, used dantz method.. garbage data now

A week ago, I purposefully deleted the partitions of both of my fully encrypted 1.5tb drives via the Win7 Disk Management application.
Later I realized that I still needed some data off them. So after much searching I came to this page where Dantz helped this guy recover all his data. Using the below quotes I adapted it to my situation (my encrypted data started at offset "32256"), however after following the instructions my drive mounted, it didn't yield a usable drive.

In short this is what I did:
I used full copy of winhex to view the un-allocated drive. I paged down in the hex view until I saw random characters. This was at 32256. Defined a block from 32256-3145727, saved it as 32256-3145727.tc and attempted to load it via TrueCrypt. It loaded up but was not viewable in windows. In WinHex I was able to view it all the way down to the name of the unencrypted drive and even one of the files until some more file data and unreadable sector came up. This means everything is there.
Then following the quoted instructions, I, using trucrypt, did a backup of the header from the 32256-3145727.tc, created an unformatted partition on the drive I was trying to recover, and restored the header.
The problem is the drive can be mounted, but again not viewable in windows, but the scary part is that it shows up random letters in winhex.

I still think the data is not ruined though because after looking at the modified drive again, it seems that new "data" was put in the very first block(?) 0-496, but I can create another workable ".tc" file from 32256-3145727. This can also be mounted and viewed with 1111111, drive name, and a file name in winhex.

I couldn't do a sector-to-sector copy because I couldn't find out how to do one.

I also haven't touched my second drive, but I do have a 3rd identical spare drive that I can use.

Please help me?

 

The most delicate part of the operation is trying to create the partition in exactly the same spot that it used to be in. If you get that wrong then the volume will probably still mount, but the data will not decrypt.

I think I know what's happened to you, though. Your previous partitions were apparently created using Windows XP, which typically places the starting offset of its default partition at 32256 (decimal). However, you tried to create your new partitions using Windows 7, which typically creates its default partitions at 1048576 (decimal).

Use WinHex to view the location of the partition. At the top of the screen where Partition 1 is listed, what number is shown for the "1st sector"? [Likely it's either 63 or 2048, if you see anything at all, that is].

Another potential problem is that it sounds as though you might have restored the TC header to the very beginning of the drive, instead of the beginning of the first partition. This would overwrite the MBR and the partition table. Is Partition 1 visible in WinHex? If not, then that's probably what happened.

If you created Partition1 at 1048576 then you likely overwrote 512 bytes of data (which isn't really that much) near the beginning of your volume, so one of your files may have been damaged.

If you wrote the TC header to the front of the disk then you likely overwrote the MBR and destroyed the partition table, but did no further damage to your lost volume.

I suggest you stop trying to follow the method I outlined in the previous thread, as it's too dangerous and you are being too careless. There are other ways to accomplish the task. I'd suggest using WinHex to make a copy of the entire partition (starting at 32256 in your case) and saving it as a file on another disk. If done properly, it should be mountable by TC and your files (or most of them) should be present.

I could add more details, but I have to go out for awhile. I'll check back later.

 

Sorry, I just re-read your post and I see that I misunderstood some things.

Here are some further thoughts:
In WinHex, open the physical drive and go to 1048576 (decimal). Is there some non-random data there? (Embedded error messages, etc.?) If so, it's probably a partition boot sector that you created there by accident.

WinHex can do a sector-by-sector copy. It can also copy the exact information you select and save it as a file. The "Clone disk" command is flexible enough to do this if you set it up right.

 

Okay so upon second viewing I noticed that after 32256 is decrypted (And viewed in winhex) I can see a the volume name, and the first folder, and the first file, but afterwards there are a bunch of 000s and it becomes familiar encrypted information. This happens at 184384, and from then on there aren't any recognizable patterns. Could the thing be encrypted in another spot instead? Or does truecrypt cease to encrypt after a certain length?

This is all the test file. I did a copy clone but after when I reread your instructions I realized you meant to make a .tc file instead

Also I believe I understand why sometimes it take a while for the .tc file to load up.. the hard drive is making it up to around 3gb; somehow it seems to get confused about the embedded "length."

Thank you very much for your time,

Alan

 

If you are able to mount the test file and you can see some decrypted content (hopefully starting with the very first sector) then the entire test file is almost certainly decrypting. It's "all or nothing" with TrueCrypt.

If you see a lot of zeros in a row then you are looking at decrypted content. And just because you aren't able to recognize a certain chunk of data doesn't necessarily mean that it is not decrypting. Many types of files are visually unrecognizable for the most part unless you are able to spot the common elements in their file headers.

If you are interested, you can test the areas that you are in doubt of by using WinHex's "Analyze Block" feature to view a chart of that block's byte distribution. Random data generally produces a very smooth-looking bar graph. However, you have to select a large enough block, otherwise it will look very choppy. The larger the block the smoother the graph (assuming you are looking at random data, that is). It's not a perfect test, but it usually gives you an indication of what you're looking at. Try comparing a 20KB or larger block of random data to a similar-sized block of unencrypted data to get an idea of what to expect. The difference between the two is often quite striking.

My guess is, your data is decrypting properly.

Your test file is so small that it doesn't include the lost partition's file system, which is why you can't browse it using Windows Explorer. I think you ought to try saving a much larger test file, or just go ahead and save your entire lost partition (which in your case apparently begins at 32256 decimal) to another disk as a file. Have you figured out how to use the Clone Disk feature? I recently walked somebody through this in another thread, here: https://www.wilderssecurity.com/showthread.php?t=351819&page=3 (See Post #54 and onwards)

However, be aware that your settings will need to be different. I don't have time right now to calculate everything out for you. I'm getting ready to leave on a huge trip and will be gone for almost a month. Do you think you can figure it out on your own? Or wait until I return?

PS: It doesn't matter if the file has a .tc extension or not, as that's just for convenience. And if your TC file doesn't mount quite rapidly (or fail to mount due to an incorrect password etc.) then there is quite possibly something wrong with your system.

 

copying it over, it says insufficient space, but it's doing it anyways..
I'm going on leave for a month myself
thank you for your thoughtful advice

 

So, I've started the procedure to copy the segment over into a new file, however Winhex hangs before it can finish. I think the farthest I've gotten was to 75GB, and I need to copy over the full 1.3TB! Is there any way to continue where I left off?

-Alan

 

I searched google for "copy hex block into file" and found FlexHex. It's a lot more stable than Winhex but has fewer features (but still has the ones I need!). I started off with a "copy into new file," but then my hard drives hung (I'm using drivepool to expand the drive size so I have more room, but drivepool doesn't work flawlessly). Anyways, FlexHex makes it really easy to continue where I left off. I opened the .tc file in FlexHex, scrolled down to the bottom and copied the ascii text keeping note of around what offset, opened up the drive to recover and scrolled down approximately around the same offset location before or after the same sector of the .tc file, pasting the ascii into the box, choosing down or up accordingly to the previous variables "before" or "after," and hitting find/search. after which I confirmed more hexs before to be the same in the .tc file. then selected immediately after the end, to way down further in the drive, right clicked to copy, went into .tc file and pasted it, and then saved it.

Looking into the file in "my computer" and refreshing the window, I can see the size increasing fairly quickly.

If you're wondering why I scrolled to the approximate location of where I plausibly left off, its because searching for anscii in 1.36 tb of data can take a very very long time, so this way I speed it up to about 2-3 minutes max.

I will post more as I go, and I'm considering making a tutorial. So far, things are looking good.