Corrupted TrueCrypt boot loader - quick help needed

To touch on the subject of WinHex; the reason I acquired it in the first place was to see how much identifying data was in the truecrypt boot loader, and how much of that data I could actually change without corrupting the boot loader (obviously that didn't go quite as I had planned ).

I am doing some testing in a VM now. And for anyone who's interested: you can delete the "TrueCrypt boot loader" text at the top (or substitute it for anything else), and you can delete / substitute the text that is programmed to appear if the boot loader is corrupted (the one that says "Disk Error. Loader damaged! Use Rescue disk: Repair Options > Restore").

Obviously this won't stop a specialist from determining that this is a truecrypt loader even if you do change these things, however in case the analyst is incompetent or lacks appropriate knowledge to compare the loader to a TrueCrypt loader, this could add a tiny bit of extra security. More for fun though than anything else.

WARNING: I do not advise anyone to edit anything in the bootloader. Do it at your own risk, and make sure to backup all your important data before proceeding if you decide to do so.

 

Exactly what i use WinHex for, to make an attempt at troubleshooting the code malware writes to the MBR section and partition tables that drop a system flat on it's knees without remedy if no useful backup is available.

In my researching deep into this critical & sensitive area with WinHex i been working to on some sort of instant fix to overwrite the values of the MBR malware code with the default normal code, i didn't realize it at the time but WinHex cleared well more then i intended it to, and so Boom! I can still access all the data & files on that system from a WinCommander Disk and others, but don't have the time right now to troubleshoot where things went wrong.

 

http://www.anti-forensics.com/modify-truecrypt-encryption-boot-loader-strings

I keep my Boot Loader on an SD Card and secure it when not in use.

PD

 

Interesting, could you explain how you did this in simple steps? I have never used SD cards with anything other than a cellphone.

As for the link you provided - quote:

Something I don't understand, however, is that when the bootloader asks for the password upon booting, at the very top it says "TrueCrypt Boot Loader 7.1" or something like that (of course this won't show if you disable it in Truecrypt's Settings/System Encryption). After changing the "TrueCrypt boot loader" reference at the top of the boot sector, the header I mentioned above STILL shows when entering the boot password. Where does it get it from?

 

The procedure I gave you when you were trying to recover from your problem...was how to put the boot loader on a USB or SD Card. That's what I thought you were trying to do. You format the drive with the one tool and then put the two files from the other tool, along with your rescue.iso, on the now bootable device. Then you can boot to the new boot loader and overwrite the TC boot loader with the original Windows one.

https://www.wilderssecurity.com/showpost.php?p=2041710&postcount=16


As for the second question, I have no idea...I stay far, far away from WinHex.

PD

 

Oh, so let me see if I got this straight:

1. you made a bootable SD card with the procedure you outlined.
2. you overwrote the TC bootloader on your drive with the original Windows bootloader so as not to leave any traces of the TC loader on the drive.

Is that it?

If so, then isn't the TrueCrypt boot loader restored to the drive's boot sector each time you use the SD card to boot?

 

Yes, you are correct.

No, the boot loader doesn't get written back to the main disk.

There's a guy on the TC forums that runs a modified Hidden OS by going through the Hidden OS creation, but after installing the decoy OS, he defers encryption and then just uninstalls TC. You are left with a normal looking Windows PC that boots right up to the decoy when you hit the power button. To get into the hidden OS, he just goes into the BIOS and enables the boot device selection option (normally hidden and protected by the BIOS pass), and boots from the SD Card. To access the Outer Volume (If needed), he uses TC Portable. His threat model is the "Turn your computer on so we can see it's actually a working computer" check, at airports, without possibly being delayed by questions about encryption. Any cursory examination of the OS, won't reveal TC installed. The RAW partition his hidden by removing the drive letter in Drive Management, preventing anybody from clicking on it and getting the "This drive must be formatted" prompt, and accidentally formatting the Hidden OS.

I actually want to try that approach, it sounds pretty usable. Obviously, an expert would ask questions about the partition sizes and the RAW partition in Drive Management, but that's all they could do...there's still no proof of anything. Then you just do the same as you would do with the normal Hidden OS setup: Reveal the Outer Volume (to keep your data safe from criminals that may steal the laptop at the airport) containing the 'decoy' sensitive data. It's actually no different from the normal Hidden OS setup, in that anyone looking at your decoy OS would see the exact same thing and have the same questions...except this way, it seems, having it boot directly to Windows could get you on your way without any questions...there's no TC Boot Loader screaming 'encryption!' at power on.

PD

 

Thanks for the reply.

I thought that the option from within the TC rescue disc was to simply "restore the truecrypt boot loader". Doesn't this restore it to the disk, making it available again? How do you manage to boot from the rescue disk without restoring the loader to the boot sector?

Sounds intesresting. However, I would be worried to use that approach myself, as I feel it could potentially lead to some critical unknown implementation errors.

 

The rescue.iso looks (and works) exactly the same as the normal boot loader. It says TC Boot loader 7.1, has the Esc and F8 options, and asks for your password/phrase. Enter the correct one and you get "Booting..." The MBR is untouched and retains the Windows boot loader. It's just like installing Linux and putting /boot on an SD Card or USB device...anti-Evil Maid countermeasure

PD

 

Man, I just can't seem to be able to replicate this, even though it sounds so easy

Here are the steps I'm taking:

1. Encrypted a 4GB VM partition with Windows XP.
2. Created the TC rescue disk and mounted it on my host PC.
3. Replaced the TC loader with the Windows loader (entire first sector up to signature hex 55AA)
4. Restarted the VM - No bootable partition found. Ok, sure.
5. Restarted the VM with the rescue disk mounted on my host machine and enabled in the VM. The TrueCrypt Rescue Disk 7.1a launches, with the following below:

Esc doesn't do anything, just keeps refreshing the error message.

Clicking F8 sends me over to the Repair Options, which include:

None of the above allow me to simply boot while using the rescue ISO as a standalone boot loader - they all rewrite the loader on the boot sector.

What am I doing wrong?

EDIT: WAIT! Do you mean to say that the rescue disk will only work in the way you describe, if it is prepared on a USB/SD card in accordance with the instructions you provided (the ones copied from the TC forums)?

EDIT 2: Nope that is not it, I just tried booting from a USB following the instructions to the T, and got the same result. This is what I expected though, but it seemed like the only thing I did differently from what you outlined, so I had to try.

EDIT 3: Ok, I think I got it to work as you described. Apparently I must have overwritten the TC bootloader with the windows one incorrectly the first time, not sure. However, it does perform a chkdsk after booting this way. Do you skip it?

 

I've never seen that disk check. I don't know why you're having all the problems, maybe the VM? If you can grab a regular old laptop, and follow bob7's instructions to the letter, you should be able to boot from an external device (if your BIOS supports it) with no trouble...I do it daily. I'm on Win7 and *don't* have a 100MB System Partition (if that matters).

PD

 

The disk check has dissapeared after 2-3 restarts and playing around with the boot sector, so it might have been more related to something I was doing rather than the method itself.

Basically I think I just made an error when replacing the TC loader with the Windows loader, which I should mention at this point to other readers is KEY; you can't just delete the TC loader, you have to replace it completely with the original Windows loader, so make sure you back it up before you start encrypting. Now I can get it right each time I try. So thanks for sticking around PD

BTW, none of my computers/laptops support USB booting; I use PLOP (http://www.plop.at/) - it allows you to boot from USB even if your BIOS doesn't support it. I boot it from a CD and then boot the USB from within PLOP.

 

Hooray! Success! BTW, after you make the bootable USB a few times, you can do it in seconds. If you make your rescue.iso available to yourself, world wide, you don't even have to travel with it...the tools are on Sourceforge and you can get your .iso. with Hamachi or Team Viewer. Of course, you'd need to go with that TC Forum poster's unencrypted decoy method...unless you want to carry around a brick and answer questions on why you do so

PD

 

Yeah I'm already doing it really quick, as I probably made around 20 attempts at the thing

You could actually upload it to some server, inside a Truecrypt container....

BTW, I must refine what I said above: if you want to be able to boot from the rescue disc, the boot sector signature (55AA) must be present. It doesn't matter what else is in the boot sector, as long as that signature is there at the end. If it is not, then you won't be able to load even from within the rescue disc.

 

Right there is where i encounter my issue, i used winhex (first made a copy) to replace the sig with zeros, then of course win gui cannot boot. I was attempting to reach it with a boot disc loaded with a hex editor in order to simply re-write the 55AA back, but ran into problems.

 

Yeah now I'm doing everything in a VM and trying everything out 10 times before I actually apply it to my real machine. And I'm thinking about some good disk imaging utility that allows to restore an image before windows boots.

What problems did you run into after editing back the signature in?

 

I returned the exact same 4 alpha-digits as before but unless WinHex done something more then when i used it to zero the sig values, i don't know what else could cause it. To answer your question, i couldn't get it to boot back normally again. That same Hard Drive is sitting on the shelf untill i can delve into it again and see if theres anything i can do besides copying off all the data thats at least reachable still.

 

I actually had that same exact problem when experimenting with winhex in my VM; after I removed the sig, restoring it didn't seem to help and I had to restore a system snapshot.

I'll be playing around with it some more so if I come to a solution I'll let you know.

 

I found this by accident, maybe it will help:

http://support.microsoft.com/kb/149877

 

Useful Find i think. Thanks, something i definitely have to try out.