All times are UTC - 5 hours [ DST ]

Post new topic Reply to topic  [ 2 posts ] 
Author Message
 Post subject: Newbie Q, truecrypt cock up
PostPosted: May 9th, 2017, 7:13 

Joined: May 9th, 2017, 6:46
Posts: 1
Location: United Kingdome
So I had (have?) a load of audio and video on a 2TB USB HD which was whole drive encrypted with truecrypt. It became full and I decided to reorganise the material, moving some of it to another drive of the same size. I mounted the original drive and then put a new single partition on what I thought was the new destination drive. I proceeded to copy 500GB of data into this partition. Only problem was I had actually copied it onto the original drive. Windows didn't complain (at all). Things became apparent when I tried to copy some other stuff on to the source drive at which point some windows process went full CPU and sat there for ages. I mirrored the drive with dd when I realised I'd made the mistake. I successfully mounted the corrupted volume (I guess truecrypt automatically picked up the backup keys at the end of the drive) and was faced with an unformatted drive. I used Wondershare to scan the drive in two different modes, a partition scan which found 250GB worth of files with filenames, and a raw scan which found 1500GB worth of material but no filenames and questionable boundries. The files on the disk will be a limited set of types (w64,h264,avi (with h264),avi (with mjpeg),flac,mov(with h264),mp4) and all files either very large or huge. How good is Wondershare ? I've used its predecessor (GetBackData) before, with success, but in much simpler scenarios. Is there something with a little more control that would allow me to inspect directory information and enter custom file headers ? As an archive drive, it is very likely that there will be zero fragmentation, can I use this to my advantage ?
Many thanks in advance,

 Post subject: Re: Newbie Q, truecrypt cock up
PostPosted: September 17th, 2018, 4:16 

Joined: September 17th, 2018, 3:54
Posts: 1
Location: Texas, USA

When you created the TrueCrypt volume, you were presented with two options - using a container, which appears as a file on a volume readable by the host system, or using a partition, which only appears when you search the physical volume with the correct passphrase/key files.

From what you are saying, you chose the latter option - and at some point created a partition on that drive, thinking it was blank, and copied data onto that new partition, while the TC partition was mounted, and now you can mount the disk via TrueCrypt but either cannot read some or all files, or can read some but not all.

I am going to assume you're using Windows, and the mangled TC disk now has a MBR partition table with one NTFS partition created.

The data that is stored in sectors that previously were part of the Truecrypt volume image and are now overwritten with data that was written to the new NTFS partition is gone, and since you overwrote the TC-encrypted data, trying to decrypt those sectors will not work because the data was changed.

The reason you can see the TC volume when you mount it is because Truecrypt sees the header signature on the data region, you have provided the keys, so the filesystem driver decrypts the volume metadata and presents the volume to the storage driver, which reads the MFT for the volume and voila, you have file listings, but when it tries to read those sectors, the TC driver hangs (ergo CPU usage, wait time, hanging, etc) because it cannot return valid data, e.g., decrypt fails, spectacularly.

Aside from the fact that development for TrueCrypt was discontinued in 2014 amid much speculation and astonishment, if you don't have a reason to use software-based FDE, and especially software-based FDE that permits hidden and/or multiple-depth volumes with plausible deniability as a selling point, I strongly suggest not doing so. If you do, then I suggest being much more careful next time, and maintaining your source vs destination much more meticulously in the future.

... In re-reading, you mentioned that the keys were on the drive. Did you mean that the key data for decrypting the TC region image were stored on another partition on the disk? e.g., it was more like:

( [ partition1 ] [ tc region ] )

and is now:

( [ partition1 ] [ tc region ] { new partition } )

and the keys were on partition1 ?

If that is the case, then may I strongly suggest you re-evaluate your understanding of full-disk encryption, as well as your use-case requirements for it.

Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 2 posts ] 

All times are UTC - 5 hours [ DST ]

Who is online

Users browsing this forum: No registered users and 3 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group