That's no problem at all, unfortunately I know the feeling.
I used the drivemapping as you described and it worked just like you said it would, but only using one of my USB sticks :-(.
When I tried it using my Datasur AES USB stick I had the problems that I described previously.
Anyway I have now found a slightly different solution using an Android app called Drivedroid which allows you to create bootable virtual USB sticks on your phone! This in combination with Diskcryptor is working well for me.
If you feel like compiling your own kernel then you can use Drivedroid as a virtual CD drive to!
As an added layer of security I keep the USB images encrypted on the phone using an app called Cryptonite that implements EncFS, this in turn is cloud synced via Dropbox (and soon Ownsync)
All in all I feel pretty good about my security now, but that's not stopping me from feeling it necessary to set up QubesOS as a management station.
It seems that a tin foil hat wearing geeks work is never done
Sorry I haven't had time to reply on this, I have been very busy :-(. And I didn't see your private message because the forum used to not warn me about those.
I am actually not incredibly knowledgeable about GRUB or the booting process in general, I just messed around with the stuff until I got it working, and was able to post that up. So I can give general advice at this point but not definite knowledge.
From the sound of it, it still sounds like you aren't using the lines to swap the harddrive numbers in grub.
basically I have got this to work only on a USB stick where I have "flipped" the removable bit so that the USB stick reads as a USB HDD. On a standard USB depending on which method I use I get one of two behaviours:
The truecrypt rescue disk boots and after typing in the password it says "Booting" but then nothing happens
The truecrypt rescue disk boots and after typing in the password it says "Incorrect password" !?!
Oddly enough when trying the other rescue disk options they do not affect anything, i.e. if I ask it to restore the original Win 7 bootloader it says that it's done it but it hasn't.
Any thoughts, I was going to give a blow by blow account of all the different ways I've tried this, screenshots and all but I thought I'd answer your questions as they come
First let me thank you for your efforts! Muchly appreciated
Sorry been so late getting back to you by the way, I've been battling with DD-WRT on an old router........but that's another story!
I plan on using this method on all my systems (once it works!) and as one of them will be using UEFI the last part of your post is perfect. Saying that I may just use Qubes on the UEFI capable laptop as it's the only one of my systems with Vt-d & TPM and Qubes has some sort of "Anti evil maid" system.
Wish I got into Linux earlier as my life would be much easier now I'm all security conscious
Anyway I'm going to try those map commands and I'll let you know how I get on.
I had to go look up a lot of old logs and find some old files to remember what all I had done for all this, as it's been a while
When I was running on x86 laptops, I used Grub (Grub4Dos?) as the boot loader, and had the following in its conf to load truecrypt and other linux ISOs from the usb key:
Grub is really useful in that it can allow you to choose from multiple ISOs on your usb drive to boot your computer from. The problem with booting windows+truecrypt from a usb is that windows always expects itself to be booted from drive #0. So part of this grub boot loading process is to swap the usb drive (currently drive #0) and your windows drive (currently drive #1) in the bios before loading truecrypt.
Unfortunately, I believe Grub2 might have broken a lot of the key words, or they have changed, so this won't work out-of-box without some modification.
Another problem is computers with EFI (instead of BIOS). Most new computers nowadays (especially x64), I believe, come with UEFI, which Grub is not compatible with by default, kind of. On my macbook I had a lot of compatibility trouble with grub on my usb key, so I ended up using Universal USB Installer to install a copy of ubuntu on the cd to get grub on it. From there, I deleted all the folders but:
/.disk
/boot/grub
/EFI/BOOT
And then modified /boot/grub/grub.cfg as follows to load some different ISOs
if loadfont /boot/grub/font.pf2 ; then set gfxmode=auto insmod efi_gop insmod efi_uga insmod gfxterm terminal_output gfxterm fi
set menu_color_normal=white/black set menu_color_highlight=black/light-gray
menuentry "Ubuntu 12.10 x64" { set gfxpayload=keep set isofile="/ISOs/ubuntu-12.10-desktop-amd64.iso" loopback loop (hd1,msdos1)$isofile linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile noprompt noeject initrd (loop)/casper/initrd.lz }
menuentry "Ubuntu 12.10 x86" { set gfxpayload=keep set isofile="/ISOs/ubuntu-12.10-desktop-i386.iso" loopback loop (hd1,msdos1)$isofile linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile noprompt noeject initrd (loop)/casper/initrd.lz }
So with the right options you should be able to load truecrypt through this grub setup. If you get it working, I'd love for you to post them here, as I have not spent the time to do it on my Macbook.
Also note that on x64 machines you shouldn't be able to load x86 ISOs, and vice versa.
I came across your article on how you moved your boot loader to a USB whilst trying to find out why I'm having problems doing the same
I am running Windows 7 x64 from a 40GB SSD with a 4x 500GB in a Raid-0 array which I use for storage. I have fully encrypted both my logical drives using Truecrypt, the RAID drive is mounted when the PC starts as a "System favorite" I then create rescue disk iso that I add to my bootable USB Dongle using a program called XBoot which uses Grub4DOS. I can access the Truecrypt Rescue disk via the USB Dongle. All good so far, everything works!
Unfortunately when I try to enter the password for my Truecrypt encrypted system it tells me that there are no bootable partitions then (confusingly) says "Booting" but nothing happens
You indicated that you had a problem and was hoping that this is the problem that you overcame using some magical Grub4DOS fu!
I have been a proponent and user of pre-boot authentication volume (hard drive) encryption for quite a while now, but there is one security hole in it that always bugged me. This is the fact that the boot loader (the code at the beginning [sector 0] of the hard drive that starts the computer [usually loads the operating system]) is unencrypted itself and can be tampered with. Even though the encrypted data is completely safe from reading without a password, the password itself could be hijacked from someone modifying the boot loader and having it record your password when you type it. This hack could also be made hard to detect because the original boot loader could be restored from the hijacked one after the damage is done.
I decided this was a moot point for a long time, until I saw it got slashdotted. This prompted me to finally change my security model slightly so I was no longer vulnerable to this problem. The appropriate method is to always use a known secure TrueCrypt rescue disk, which contains its own boot loader, to boot the hard drive. Unfortunately, CDs are a bit cumbersome to always keep around. The workaround for me was to use a bootable USB Flash Drive instead, as I keep it on my keychain which is always with me. Getting the TrueCrypt boot loader to work from the flash drive was not easy at all due to how bootable flash drives work (they take the hard drive #0 slot in BIOS, which Windows doesn’t like). It took some GRUB4DOS magic to get things going, but it all ended up working out :-).
I removed the TrueCrypt boot loader from my hard drive so I would not be tempted to use it, and would always use the flash drive. This left the boring message of “Error loading operating system” upon booting without the flash drive, which I just couldn’t stand, so I decided to have some fun writing my own “Operating System Not Found” boot loader :-).
Video Notes:
It’s a lot harder to spot the hidden text string from the video than from the actual thing x.x;
The boot loader was ran through a virtual machine (VMWare) so I could easily record it.
Do not attempt to replace the boot loader on your hard drive without knowing what you are doing, as this is a very dangerous operation that can make your computer unbootable. Always back up your boot loader before making modifications to it so you can easily restore it. Also, when writing a boot loader, do not overwrite bytes 0x1BE-0x1FD of your boot sector as they contain important partition information.