freeman
2009-May-26 03:45 UTC
[syslinux] [How-To?] Using Syslinux AltMBR + TrueCrypt System Encryption (RFE: swap drive ID's)
Just achieved success using syslinux to multi-OS boot, including a WinXP System (boot) partition that's been encrypted with TrueCrypt (TC). You'll need syslinux version 3.81-pre13 or newer to get a working altmbr.bin file. I used: http://www.kernel.org/pub/linux/utils/boot/syslinux/Testing/syslinux-3.81-pre13.zip Background: I started with a 'normal' multi-OS boot setup as follows: MBR - syslinux hda1 - 24G - [0c] - FAT32 - WinXP (Encrypted via TrueCrypt) hda2 - 53G - [0f] - Extended hda5 - 0.5G - [06] - [boot] FAT16, boots syslinux menu hda6+ --- Various_Other_Partitions, none with [boot] active --- All was booting & working fine but I wanted to encrypt the WinXP boot partition (hda1) with TC. Doing so would entail: - TC replacing the MBR boot code with its own boot loader - TC filling in some sectors immediately following the boot (MBR) sector with TC's full boot loader/code. - obviously: TC encrypting all data including hda1's FAT32 'boot record' - So I booted XP, ran the TC system encryption wizard and it did its thing all fine. Afterwards booting up would now bring me straight to the TC password prompt, as expected. At this point I needed to put the syslinux MBR back into the MBR sector of hda and have it chain to TC's MBR for the times I wanted to boot into XP. - I booted linux and created backups of the MBR and separately, the first 8 * 63 sectors (hey, I was just copying what I found in: http://www.steve-oh.com/blog/index.php/2009/03/12/ubuntu-vista-dual-boot-full-encryption-with-truecrypt/ which spoke of going it under grub) by executing: :: dd if=/dev/hda of=/mnt/hda5/name_tc.mbr count=1 :: dd if=/dev/hda of=/mnt/hda5/name_tc.img count=8 bs=63b :: using fdisk, make hda1's boot flag active (and leave hda5's boot flag active, too!) About TC's boot loader: It's pretty 'brain dead' - it will only attempt to 'mount' partitions whose boot flag is active ... which would break using syslinux since normally the syslinux MBR boots into the partition marked as active (which can't be hda1 since the *whole shebang* is encrypted). Enter syslinux's 'altmbr.bin'. The logic of controlling which partition syslinux boots into is changed from being based on the boot flag in the partition tables, to being a whatever partition number is specified by a single 'configuration' byte in the MBR, specifically the 440th byte (the one right before the 4-byte disk_signature). So using this altmbr.bin lets us keep the active flag on hda1 (which keeps the TC boot loader happy) but lets us still initially boot into hda5 with the syslinux configuration. (Note that altmbr.bin doesn't seem to detect multiple bootable partitions at all - FWICT the normal MBR.bin only detect multiple partitions *of the same type* - primary or logical - so even with the normal syslinux MBR one can safely have a boot_active primary partition and boot_active logical partition ... but for what purpose?!?!) Back to work. So we apply the alternate syslinux mbr by: :: dd if=/mnt/hda5/altmbr.bin of=/dev/hda bs=1 count=439 Next we need to adjust the boot_partition config_byte in the MBR so syslinux knows which partition to boot. To have syslinux boot Xda1, put 0x01 in there. For me, using hda5, I put a 0x05. All we need to do now is to adjust the syslinux.cfg file to boot the TC MBR. I found this can be achieved in 3 ways: # Method A; use *.IMG file (img extension needed!) # (my tc_name.IMG is 258,048 bytes in size; # the 512 MBR does not contain all needed code) ################################################################## #kernel /utils/syslinux/memdisk #append initrd=/tc_name.img # ############## # Method B - (only need 512-byte MBR!) ######################################################### #kernel /utils/syslinux/chain.c32 #append hd0 1 file=/tc_name.mbr # ############## # Method C (best?!) - (only need 512-byte MBR!) ######################################################### boot /tc_name.mbr And that's it! (Naming tc_name.mbr as tc_name.bs is probably the proper, official nomenclature for this type of bootfile tho). (I chose to keep hda1 and hda5 as 'boot active' so that if I boot into the TC MBR I can sort of cancel and go back to syslinux without rebooting by: pressing escape at the TC password prompt - TC then tries to locate another bootable partition, finds my hda5 (and calls it "partition 2") and apparently attempts to boot into it but fails (did I mention the TC boot loader is brain dead) and I can press escape again to exit the TC MBR and cause syslinux's MBR to reload.) I've crafted this post hoc, from memory, but think I covered the key points. Hope it helps some. And a major hat-tip thx to hpa for the quick response & fix to the altmbr.bin code! For anyone interested TC source code can be found here: http://www.truecrypt.org/downloads2 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Uh, and uh, since I'm here, shall I toss in an RFE based on my experience? That brain-dead TC system encryption feature has a build_rescue_CD function built in, which after booting will permit the user to replace the MBR and/or boot_loader code, as well as the encrypted volume's header. It's designed to be created as a bootable ISO for burning to CD (*optical* drive) and I can see why - if you extract the bootable-floppy image from the ISO and put it onto a USB fob (esp one with a full MBR/partition table & discrete partitions) when you boot from that USB fob your PC may see the fob as a harddrive and call it (in TC vernacular) "drive 0" (aka device 0x80?!). But the TC boot-loader repair seems to be hard-coded to repair only upon "drive 0", thus it'll bork your USB fob's MBR if you proceed with a repair. So it'd be nice to be able to instruct syslinux (used to boot the USB fob) to make the current booting device into device 0x81 (or other) and let the PC's normally_booting hard drive be seen as 0x80, to let things like this TC rescue beast work. This might seem to be simply an extension of the "swap" option for chain.c32, since AIUI this swap option seems to only force the boot device to *become* 0x80, but not let the boot device abandon identification 0x80 and make some other device possess that drive id. So this RFE seems doable and maybe even simple? (And could/should this feature be added to the boot token?) 'Nuff for now, thx again for syslinux! scott
H. Peter Anvin
2009-May-26 05:06 UTC
[syslinux] [How-To?] Using Syslinux AltMBR + TrueCrypt System Encryption (RFE: swap drive ID's)
freeman wrote:> > (Note that altmbr.bin doesn't seem to detect multiple bootable > partitions at all - FWICT the normal MBR.bin only detect multiple > partitions *of the same type* - primary or logical - so even with the > normal syslinux MBR one can safely have a boot_active primary partition > and boot_active logical partition ... but for what purpose?!?!) >To answer the question: there are some buggy partitioning programs out there which set the Active flag on *ALL* logical partitions, so we ignore the Active flag on logical partitions if there are active primary partitions. It also makes the code slightly simpler. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.
H. Peter Anvin
2009-May-26 05:09 UTC
[syslinux] [How-To?] Using Syslinux AltMBR + TrueCrypt System Encryption (RFE: swap drive ID's)
freeman wrote:> > This might seem to be simply an extension of the "swap" option for > chain.c32, since AIUI this swap option seems to only force the boot > device to *become* 0x80, but not let the boot device abandon > identification 0x80 and make some other device possess that drive id. >"swap" does exactly that ... it swaps two drive IDs. On the tech level it actually contains a full remapping table and it can in theory handle any arbitrary mapping. What are you looking for, specifically? It's probably quite trivial to do, as long as it can be quantified. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.