TrueCrypt Container Recovery
Everything started from an encrypted container on a flash drive, which couldn’t be opened for some reason. The examination confirmed, that the container didn’t accept the password provided. The first thought was the customer forgot the right one. But we decided to try to find a solution to open it.
We started from checking NTFS file system. Analysis revealed the file system was not damaged. Then we checked the cluster map of the file. We found out that this file was non-fragmented. More detailed analysis revealed untypical fragments for encrypted container – the presence of zero areas. The point is, encrypted file is similar to an archive, because it doesn’t have to contain “uniform” sections, but the combination of adjacent bytes has to have a high level of uniqueness. The difference can be seen on figures 1 and 2.
Figure 1. TrueCrypt
Figure 2. No TrueCrypt
We assumed the file card isn’t correct based on the information received. TrueCrypt container doesn’t have neither BOF (beginning of the file), no EOF (end of the file). There’s no typical header (signature). The file size and structure are not described. So the task of file search isn’t trivial. Unfortunately, it couldn’t be solved automatically with the help of software. The decision of file location can be made only by a person and based on circumstantial assumptions.
In this case, the search of the BOF was not successful. We decided to make a search of the EOF looking through the content of flash drive. We’ve found the relevant code. It’s known that the password is stored in the first 512 bytes of the file (header). Copy of this area is at the EOF. The copy is also stored in an encrypted form and areas’ comparison won’t yield any result. Offset from the EOF is important.
Assuming that we have found the right EOF, we stored the area with a key. Then we determined the file size from file system (it’s a conditional assumption) and recede on specified interval. We pasted the area with a password into this field. The file got mounted but the logical partition is damaged. Analysis of the partition revealed the MFT zone is correct and a part of files is good. But files that were located in the beginning of logical partition didn’t have proper headers (signatures).
It’s a good result of course but there are many things to work with. Let’s assume we haven’t gotten to the correct BOF. It’s possible only when the file is fragmented. We determined the size analyzing atypical areas of an encrypted file. We made an offset from the beginning of the wrong area to desired interval and mounted the file again. The partition got mounted. So BOF is found. Knowing BOF and EOF we removed some excess data and got a correct container. Data is recovered. But there’s a question, how such situation became possible? A customer’s inquiry was unclear and didn’t lead us to the right answer. Maybe the readers will give us some ideas.
Last but not least, if encrypted container doesn’t open, don’t hurry to assume the damage of the container. Try to check all possible options. For TrueCrypt users we recommend to make copy of the header, moreover TrueCrypt permits it.