Requirements
- Hex editor such as WinHex
- A hard disk that has been encrypted with TrueCrypt full disk encryption
In a previous post I mentioned that TrueCrypt leaves behind a string in its boot loader (that identifies it as a TrueCrypt boot loader) when using the full disk encryption feature. As you can see in the screenshot below I have modified the original “TrueCrypt Boot Loader” string to read “Windows Boot Loader.”
This quick edit takes about ten second to complete. Just open the boot disk with a hex editor and modify the string.
If you don’t understand what I’ve done then here are the steps:
- Open the TrueCrypt encrypted hard disk (physical disk) with a hex editor
- Locate the TrueCrypt boot loader at the “start” of the hard drive (in sector 0)
- Use a hex editor to overwrite the “TrueCrypt Boot Loader” string
- Save changes
- Boot from the disk to make sure you haven’t messed up the boot loader
So what does this mean?
Many computer forensic examiners will probably not realize what they’re looking at if they actually do take a look at the boot loader. Removing this string ensures that they’re kept in the dark. That is unless they do their own digging around and can figure out that the instructions in sector 0 are in fact part of a TrueCrypt boot loader.
There is plenty of other code in the boot loader. I’m sure patterns in this data can giveaway the fact that the disk has been encrypted with TrueCrypt. I have not researched it and I have not attempted to figure out what this other data actually means, is or does. You should be fine modifying the strings in the boot loader though.
You will want to keep the strings at their original length so as not to mess up code/instructions in other parts of the loader as well. If you start over-writing other code in the boot loader that is not a string, you are probably modifying instructions which will most likely cause boot failure or the loader to crash.
This is another one of those anti-forensic methods that’s not real strong but it gets rid of the word “TrueCrypt” from the drive which would be a dead giveaway to most examiners that TrueCrypt could have been used to encrypt the hard drive (I would hope so anyways). I’ve ran a keyword search in EnCase forensic software as well as other software to verify that there is no other reference to the name TrueCrypt on the fully encrypted disk. There were no other hits.
If there are any papers written on the construction of the TrueCrypt loader or if you’ve done your own research on this then please share what you’ve found. I as well as others will be very interested.




Nice idea. I like that there’s someone else out there looking at the boot sector of a TrueCrypt Windows system encryption drive. I’m currently trying to develop an proof-of-concept exploit to bypass TrueCrypt system encryption, if you’re interested in helping at all. Check out my first post about it at my blog: http://blog.banditdefense.com/2009/03/02/attacking-truecrypt-part-1-the-vulnerability/
isnt TrueCrypt open source? – yes it is.
technically, nuf said :p
you could just modify the name/boot procedures abit by source, if you got the compiler/libs
much easier, and much safer (as you pointed out, messing with it in hex is likely to mess with every single jmp/cmp instructions..)
I’m looking forward seeing more of your work on bypassing/exploiting the truecrypt header Micah.
Great idea Hans!
I may do something like that for each version that comes out and re-upload the binary here as well as the sourcecode. If that’s allowed in the license anyways.
If anyone else does this or something similar, please share here in the comments section.
[...] Modify TrueCrypt Encryption Boot Loader Strings [...]
[...] Modify TrueCrypt Encryption Boot Loader Strings [...]
[...] with your first and last name or any other name you’re known to use. You should also be using full disk encryption properly to help frustrate an examination that gets to that [...]
[...] TrueCrypt and modify the boot loader with a hex editor to remove the string "truecrypt" Modify TrueCrypt Encryption Boot Loader Strings | Anti-Forensics This way you’ve a disk full of data, it’s just [...]
I have done extensive research on the Truecrypt boot loader.
From your screenshot of the HEXs editor I can tell that you were running truecrypt 6.1a. Changing that 1 line of text fools no one.
You have to realise that the truecrypt boot loader takes up sectors 1 to 63 of the harddisk – and it is not encrypted.
The only way you can really hide truecrypt is to delete your first 63 sectors and use the rescue disk to boot your PC every time you boot up.
The strings for the main loggin screen aren’t encrypted. They are simple compressed. If you copy from 0xA00 to about 0×3700 into a file, you can open it, as its a zip file, then all the truecrypt strings that you see on the login screen are available for everyone to see.
Great information Myforwik!
I currently cannot confirm or deny your claims but if you could point the readers to some documentation on that it would be great.
It would make a great addition to the article or a secondary article, with props to you of course.
Myfor how is it you are extracting or uncompressing the data?
Here it is uncompressed, I setup a test environment with the latest TrueCrypt version and a Windows XP system in VMWare. It is the last 460 bytes after uncompressing the offsets that Myforwik provided. Bravo Myforwik, I had stopped all research on Truecrypt so this is some exciting information for me, even if it might be public or widely known now. I don’t know if it is but props to Myforwik for the info.
C’mon TrueCrypt, this isn’t cool
I guess what probably needs to happen to do anything serious is to just start going through the TrueCrypt source code as Hans had suggested.
I’m currently in the process of “modernizing” the site with a new theme and I’ve a ton of other projects ongoing so I’ve no time to come up with a way to get rid of these strings.
I mean the simple option would probably be to modify the source and rebuild (truecrypt binary) but it would be cool to have some process of editing this data, compressing it all again and then adding it back to the boot loader.
Also, Lars, here is the process I went through. There are probably better methods but this is what worked for me:
Its not exactally to 0×3700,
If you go to address 0x1B0 there is a two byte integer that is the size of the file.
So if you read those two bytes (in version 6.3a it is usually 0×97 0x2D = 0x2D97 = 11671 bytes. And the bytes start at 0xA00.
The file format is actually gzip, which is openable by most zip programs including windows zip folders etc.
Unfortuently if you edit the strings and re-zip, and save it back to 0xA00 it won’t work, because there is a checksum at 434d. Thats why I wrote a program.
Hi!
1. Create Truecrypt rescue disc.
2. Use Winhex application to erase sector 1 to 63.
3. Then, you are required to use Truecrypt Rescue Disc each PC start.
Question:
1. Erasing sector 1 to 63 once is enough?
2. Anything to erase/remove/modify aside from Truecrypt boot loader, disregarding network/server tracks?
3. Is there anyone can verified that this is 100% false-positive, even from new/updated forensic application?
4. How about Truecrypt volume tracks?
Thanks for reply.
-am
Truecrypt is great and stable.
Truecrypt drived by the features and marketing strategies.
Then People and IT Pros like it.
They just don’t care if it is 100% safe.
But any security product which is not 100% open sourced is very dangerous for keeping very sensitive data on your expensive laptop or your super tiny usb flash disk.
We can’t prove that it is really safe if we do not have the complete source code and a certification.
Imagine have sex with someone you don’t really know.
Then 1 week later you are positive.
Forum is not also open to anyone.
I believe any security free/open source products should be certified (not recognized) as 100% safe (certified (not by anyone but by a legit institution like NIST)
If i am working on the goverment.
Should I tell anyone that the conspired product gave us backdoor on it.
If i am one of the developer.
Should i tell anyone that i created a personal backdoor on it.
LAR
If an expert hacker access my drive whether in person or over the net, could he modify the boot loader (or extend the size if need be) to insert a keylogger (still keeping the TC boot screen intact) that would load a NIC driver then transmit the password over the net, therefore, compromising the use of TC encryption? or would the checksum defeat the extension and modification of the boot loader?