so in my previous post (http://forums.anandtech.com/showthread.php?p=33200628),
I explained how I ran the Diskpart clean command in the wrong drive. About 2 weeks ago I managed to recover the truecrypt volume so I though I'd help out someone else who has gone through the same problem. ()
this method relies on
1) your file not being fragmented
2) the start OR the end of the file being next to a group of zeroes.
3) you know the password to the container
the first thing you need to do is get a copy of the full version of WinHex somehow (I'm 17 so I couldn't exactly buy it ) I didn't have a backup copy of the container nor did I have a backup of the header. And truecrypt volumes do not have any kind of signature that can be used to identify them
It took me some time to figure it out. so,
1) The file I was looking for was not fragmented.
2) It was 150 GB.
3) It was an encrypted truecrypt container.
4) And my HDD capacity was 1TB.
Encrypted truecrypt containers are completely filled with pseudo random data. so considering that the file was continuous, other than my container, how many data streams could contain 150 GB worth of pseudo random bytes without a few bytes of 0's in a 1 TB HDD?
*****************
even if you haven't used WinHex before, it has an intuitive interface and doesn't take a genius to figure it out. But,
To define blocks, right click the byte and select "beginning of block" to set the starting point and go to another byte and select "end of block" to set the ending point.
To search a block for hex values check the "search in block only" in the "find hex values" dialog.
You can move to another offset using the "Go to offset" option. You'll have to enter the offset in bytes converted to hexadecimal (For eg: to move 1 GB forward from the offset you are in, enter "40000000" (1024 * 1024 * 1024 converted to hex) and select "relative to current position".
To move back from the current position, select "current position (back from)".
And you can easily move to the start and end of a block using [alt+ctrl+home] and [alt+ctrl+end] respectively.
*****************
so I decided to look for 150 GB continuous file that didn't have 5 bytes of zeros. (0x0000000000 - a single hexadecimal digit is 4 bits; ie. half a byte. but you already know that) you can define a block by setting it's starting point and ending point. When you're defining a block, your first instinct would be to define blocks that have the same size as the file. but this is not very productive. here's why:
My file is 150 GB. so lets say i defined a block of size 150 GB. and lets say that i found 0x0000000000 within this block. most probably you'll find a lot more zeros trailing after the ones you found. so you'll have to find the end of this bunch of zeros to define the start of the next block because clearly, the file's starting point isn't in this block. this can be cumbersome because there might be megabytes worth of zeros and even page-down can increase the speed of scrolling so much. even if you DO manage to find the end, there might be another bunch of zeros about 500 megabytes from that point. so you can see why defining blocks of that size isn't very efficient.
so the best size for a block is a size somewhat lower than half the size of your file. here lets say i defined a block 60 GB. now if i find zeros in this block, i can easily start the next block from the end of the current block and set the end 60 GB from there. now i can move to the next block and search in that. if i find zeros there too, then i know for sure that my 150 GB file isn't inside those 2 blocks because any non fragmented file inside them would be equal to or less than 120 GB (60 GB * 2) so all I had to do was keep searching 60 GB at a time until I found a block that didn't contain zeros, effectively covering 60 GB of my HDD each search.
so any block size larger than half the size of the file is also not appropriate. considering two 100 GB blocks, i can find zeros in both blocks but a 150 GB file could still be there. there's enough space for 25 GB of zeros in the beginning of the first block and 25 GB of zeros in the end of the second block.
so once I found a block that didn't contain zeros, I went to the start of the block and searched *up* for zeros. you can choose "up" instead of "down" and "all" in the hex search dialog (uncheck "search in block only" before searching). I set the first byte after the zeros as the start of the block. next I searched *down* for zeros. then i set the last byte before the zeros as the end of the block. now I had a block larger than the size of my file, with both the start AND the end adjacent to a bunch of zeros. I saved this block as a file and tried to mount it using truecrypt. It said incorrect password. this meant that i didn't get the starting point correctly. then i tried restoring the volume header from the backup embedded in the volume. since this worked, i knew i had the ending offset pinpointed correctly. so all I had to do was, go to the end byte of the file, set it as the end of the block, and then go 150 GB backwards. since I was in the last byte of the file, when I went 150 GB backwards, I went to the byte before the start of my file. so I went forward ONE byte (2 hex values) and then selected that byte as the start of the file. saved the block and it worked perfectly! All my files were intact!
In my case I couldn't mount it but could restore the volume header from the backup embedded in the volume. You might be able to mount it but when you open it, windows says that the disk structure is corrupt and unreadable, you have nothing to worry. you just haven't got the ending offset correct. Go to the start of the previously defined block, set it as the block start, go 150 GB forward, and then ONE byte back, and set it as the end of the file and save the block as a file. Then try to mount it. This should work. Hope this helps
Perhaps there are better ways out there but I posted my method because it helped me and I hope that it helps someone else too. I know that I over explained a few simple things but I did it so that even a person who hasn't used WinHex before can follow.
I explained how I ran the Diskpart clean command in the wrong drive. About 2 weeks ago I managed to recover the truecrypt volume so I though I'd help out someone else who has gone through the same problem. ()
this method relies on
1) your file not being fragmented
2) the start OR the end of the file being next to a group of zeroes.
3) you know the password to the container
the first thing you need to do is get a copy of the full version of WinHex somehow (I'm 17 so I couldn't exactly buy it ) I didn't have a backup copy of the container nor did I have a backup of the header. And truecrypt volumes do not have any kind of signature that can be used to identify them
It took me some time to figure it out. so,
1) The file I was looking for was not fragmented.
2) It was 150 GB.
3) It was an encrypted truecrypt container.
4) And my HDD capacity was 1TB.
Encrypted truecrypt containers are completely filled with pseudo random data. so considering that the file was continuous, other than my container, how many data streams could contain 150 GB worth of pseudo random bytes without a few bytes of 0's in a 1 TB HDD?
*****************
even if you haven't used WinHex before, it has an intuitive interface and doesn't take a genius to figure it out. But,
To define blocks, right click the byte and select "beginning of block" to set the starting point and go to another byte and select "end of block" to set the ending point.
To search a block for hex values check the "search in block only" in the "find hex values" dialog.
You can move to another offset using the "Go to offset" option. You'll have to enter the offset in bytes converted to hexadecimal (For eg: to move 1 GB forward from the offset you are in, enter "40000000" (1024 * 1024 * 1024 converted to hex) and select "relative to current position".
To move back from the current position, select "current position (back from)".
And you can easily move to the start and end of a block using [alt+ctrl+home] and [alt+ctrl+end] respectively.
*****************
so I decided to look for 150 GB continuous file that didn't have 5 bytes of zeros. (0x0000000000 - a single hexadecimal digit is 4 bits; ie. half a byte. but you already know that) you can define a block by setting it's starting point and ending point. When you're defining a block, your first instinct would be to define blocks that have the same size as the file. but this is not very productive. here's why:
My file is 150 GB. so lets say i defined a block of size 150 GB. and lets say that i found 0x0000000000 within this block. most probably you'll find a lot more zeros trailing after the ones you found. so you'll have to find the end of this bunch of zeros to define the start of the next block because clearly, the file's starting point isn't in this block. this can be cumbersome because there might be megabytes worth of zeros and even page-down can increase the speed of scrolling so much. even if you DO manage to find the end, there might be another bunch of zeros about 500 megabytes from that point. so you can see why defining blocks of that size isn't very efficient.
so the best size for a block is a size somewhat lower than half the size of your file. here lets say i defined a block 60 GB. now if i find zeros in this block, i can easily start the next block from the end of the current block and set the end 60 GB from there. now i can move to the next block and search in that. if i find zeros there too, then i know for sure that my 150 GB file isn't inside those 2 blocks because any non fragmented file inside them would be equal to or less than 120 GB (60 GB * 2) so all I had to do was keep searching 60 GB at a time until I found a block that didn't contain zeros, effectively covering 60 GB of my HDD each search.
so any block size larger than half the size of the file is also not appropriate. considering two 100 GB blocks, i can find zeros in both blocks but a 150 GB file could still be there. there's enough space for 25 GB of zeros in the beginning of the first block and 25 GB of zeros in the end of the second block.
so once I found a block that didn't contain zeros, I went to the start of the block and searched *up* for zeros. you can choose "up" instead of "down" and "all" in the hex search dialog (uncheck "search in block only" before searching). I set the first byte after the zeros as the start of the block. next I searched *down* for zeros. then i set the last byte before the zeros as the end of the block. now I had a block larger than the size of my file, with both the start AND the end adjacent to a bunch of zeros. I saved this block as a file and tried to mount it using truecrypt. It said incorrect password. this meant that i didn't get the starting point correctly. then i tried restoring the volume header from the backup embedded in the volume. since this worked, i knew i had the ending offset pinpointed correctly. so all I had to do was, go to the end byte of the file, set it as the end of the block, and then go 150 GB backwards. since I was in the last byte of the file, when I went 150 GB backwards, I went to the byte before the start of my file. so I went forward ONE byte (2 hex values) and then selected that byte as the start of the file. saved the block and it worked perfectly! All my files were intact!
In my case I couldn't mount it but could restore the volume header from the backup embedded in the volume. You might be able to mount it but when you open it, windows says that the disk structure is corrupt and unreadable, you have nothing to worry. you just haven't got the ending offset correct. Go to the start of the previously defined block, set it as the block start, go 150 GB forward, and then ONE byte back, and set it as the end of the file and save the block as a file. Then try to mount it. This should work. Hope this helps
Perhaps there are better ways out there but I posted my method because it helped me and I hope that it helps someone else too. I know that I over explained a few simple things but I did it so that even a person who hasn't used WinHex before can follow.
Last edited:
Facebook
Twitter