Syslinux - May 2009 - [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

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.

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.