Some Basic Options When Dealing with TrueCrypt (aka Finally a Forensics Post)

I’ve recently been working on a presentation I’ll be giving in a few weeks on the topic of memory forensics. I’ve learned a ton while working on it and the old adage of “The best way to understand something is to teach in to others” has proven extremely beneficial to me.

One of the topics that required me to do some digging was on the subject of memory analysis as it relates to TrueCrypt. A few years ago I was asked to examine a system within an extremely short time frame. I looked at the software installed on the system and saw TrueCrypt. I didn’t know a ton back then but I knew enough to know that there was nothing quick about dealing with TrueCrypt.

I’m writing the post that I wish I would have had on that day a few years back. If you see TrueCrypt installed on a system and aren’t quite sure what to do with that bit of information, hopefully this quick overview and some of the resources I’ll mention help. I’m not going to cover using artifacts like prefetch files to determine if TrueCrypt is installed and how frequently it’s been used, we’ll just cover hunting for and dealing with the containers.

Locating TrueCrypt:

One of the things that makes locating TrueCrypt files difficult is their lack of a standard file signature that one would normally use to locate all of a particular file format. There is a free tool called “TCHunt” that will scan a drive or directory and look for files that may be TrueCrypt containers. TCHunt looks for miles that meet specific size requirements (file size divisible by 512 and at least a minimum size), doesn’t have the file header of a known common type and appears to contain a higher than average randomness of data which is a key indicator that the contents may be encrypted.

tchunt

 

 

 

For everything that TCHunt does it’s also amazingly quick. I ran it against a 750GB Hard drive which had over 500GB of data and the complete scan took around three minutes. The tool correctly identified all four TrueCrypt containers on the drive.

Cracking TrueCrypt:

Using Memory:

Ideally you have a memory dump which was acquired while the TrueCrypt container was mounted. In lieu of that the hiberfil.sys may have been written while the container was mounted. TrueCrypt no longer stores it’s password in memory but it does store encryption keys in memory while the container is mounted so the password doesn’t need to be re-entered every time a file is accessed. These keys can be located using tools like bulk extractor and are the key to unlocking the container.

Michael Hale Ligh wrote a great blog post on Volatility Labs earlier this year discussing identifying and acquiring these keys. In the post he references a 2011 blog post by Michael Weissbacher  where he outlines patching TrueCrypt to allow an examiner to use acquired AES keys to mount a TrueCrypt container without knowing the password. There are commercial tools such as passware and elcomsoft which will also allow an examiner to access a TrueCrypt container using keys acquired from a memory dump.

Without Memory:

If no useable memory dump is available and you still want to access a locked TrueCrypt container you’re hoping for quite a few things.

• The user used a short password
• The user stuck to the default settings (RIPEMD-160 and AES) when creating the TrueCrypt container
• You have access to a system with a powerful graphics card

Modern graphics cards (GPUs) can crack passwords at a MUCH faster rate than a computer processor (CPU) can. I recently upgraded to an ATI 7950 3GB model ($230 at Newegg) and I’m able to crack passwords on a TrueCrypt container created with default settings at a rate of 77,000 guesses per second. That sounds like a lot and it’s great for wordlists (I can go through the entire 14,000,000 word rockyou list in under three minutes) but when you start crunching the numbers on a brute forcing attempt you’ll quickly become discouraged.

If standard wordlists don’t crack the password there could be multiple causes. The user could have changed the default settings when creating the container or could have used a password not in your word lists. You could try generating custom wordlists or using your wordlists with different encryption options.

I threw one of the TrueCrypt containers TCHunt found at oclHashcat to try to crack the password. oclHashcat has multiple TrueCrypt encryption options but I tried the default RipeMD160 and AES option first.

hashcat1

It turns out that the password (123mango) was in the rockyou wordlist I was using so the password was cracked in under a minute.

hashcat2

 

 

 

 

 

 

I can’t overstate the value of having some good wordlists for times like these. Brute forcing a password 8 characters or longer is a road nobody wants to go down.

I’ve been using john the ripper for a few years but am just now starting to seriously delve into GPU password cracking so I’d love to hear any tips, techniques or stories you have on these topics.

Python Tool for Parsing Data from Rand McNally GPS units

I recently encountered a Rand McNally Intelliroute TND 720 GPS unit and none of the commercial forensic tools had the ability to acquire data from the device so I imaged the device and poked around for any interesting data files.

I found a file called DestHistory.txt which obviously peaked my interested. I opened the file in notepad and while it contained a lot of unusual characters it also contained multiple recent destinations sandwiched in between those characters.

I wrote a small python script which takes the contents of the DestHistory.txt and parses it into both a HTML report and a KML file which can be opened in Google Earth. The tool is called rmparse and can be download here.

The project was fairly straight forward. The only hiccup was that the DestHistory.txt is in Unicode format so when my script parsed the file there was a null between every character. I tried a standard B = A.replace( “ “, “”) command but had no luck. I ended up using a B = A.replace(“\x00”, “”) command and it worked like a champ.

The rest of the script was just parsing out the relevant portions, sticking them back together and then wrapping them in HTML and XML.

A few notes about this script:

The script has only been tested with the listed model. If it does or does not work with any other model feel free to post that in the comments.

The source file name of DestHistory.txt has been hard-coded in so the tool can be run from a GUI. Copy the DestHistory.txt to a directory, place the script in the same directory and run the script. It will generate the HTML report and KML file in that directory.

The script takes the lat/long coordinates from the source file, splits them, adds a period in the proper location and sticks them back together. The function that performs this assumes that the coordinates are in North America. It would be a simple modification to adjust that function to another region.