Writing a Boot Loader

[Astro]

Hi,

Is this question permitted here?

I want to modify the boot process for TrueCrypt so it supports more than just passwords. I think the best way to achieve it is to write a custom loader that does the additional checking for a device, getting a key from it, then passing it on to TC somehow.

The reason TC doesn't do this already is due to space limitations in the boot sector, so I need a way to get around this.

Best regards,
Astro.

[hutch--]

Robin,

What media are you going to use for the boot process ? Floppys are a pain and past it, CDs are common and memory sticks are cheap enough but you must have a BIOS that supports memory stick USB boot.

The Acronis stuff I own uses Linux stuff to start the disk and apparently has something like Samba so it can read Windows NTFS formatted disks. Its just that if you use a larger storage media to boot you are not restricted to boot sector code but as much code as you can fit on the media.

[thomas_remkus]

I might be off base here but you might want to look at the tools that will turn your USB device into a bootable device. Google for "windows 7" "boot" "usb" and you should find how you can take tools from the standard windows CD and format your USB and flag it as bootable. Then from there you might be able to learn how it works to create your own bootable thingie. Again, this might be off base but it sounds like fun having your own bootable USB with your own tools.

[Vortex]

You can use BartPE to boot from a CD\DVD, USB memory or hard disk :

http://www.nu2.nu/pebuilder

[Astro]

Hi,

The Acronis stuff I own uses Linux stuff to start the disk and apparently has something like Samba so it can read Windows NTFS formatted disks. Its just that if you use a larger storage media to boot you are not restricted to boot sector code but as much code as you can fit on the media.

My BIOS supports booting of USB sticks, so I was going to initially see if I could get some form of boot loader running off that.

I've started looking at the GRUB boot loader to see how it does it, but it isn't totally clear yet. Seems it is some form of C with assembler mixed in (it appears it is GAS - GNU Assembler).

Looks like I figured most of the syntax already. GAS uses AT&T syntax, with an option to use Intel style. http://www.redhat.com/docs/manuals/enterprise/RHEL-3-Manual/gnu-assembler/i386-syntax.html

Looks like I've got a bit of reading to do on 16-bit assembler (can MASM do 16-bit? I haven't checked), in particular, commands.

It would appear that I need a way of jumping out of the boot sector to the first sector of 'a' partition. I guess that is where the fun starts!  :cheekygreen:

EDIT: I found the 16-bit linker required.

BartPE seems to only create boot disks from Windows binaries. I need to be the boot process. The other issue I've got is accessing the USB from this level.  :eek :dazzled:

Best regards,
Robin.

[hutch--]

Its the guys who have played wirth mini OS design that would probably be the most use to you here, as long as the USB stick you have in mind will handle a boot sector you can branch off to anything you like from the boot code but then you must be able to interface with the disk format on the hard disks if you want to install or restore anything.

[Astro]

That's what I was wondering.

I think I've got a disk editor somewhere so if I get desperate I'll just hand-write the data direct to the disk until I have something more formal sorted out.

I know at least one of my sticks is bootable - it had Fedora 7 on there until recently.

Are the mini OS guys on this board?

Best regards,
Robin.

[BogdanOntanu]

I want to modify the boot process for TrueCrypt so it supports more than just passwords.

What exactly is this "more" thing that you want to "add" ?

I think the best way to achieve it is to write a custom loader that does the additional checking for a device, getting a key from it, then passing it on to TC somehow.

I think TC uses the "well known" PKCS#11 as a crypto token interface API. But then again you should have known this if this is your real level of interest or work experience.

The reason TC doesn't do this already is due to space limitations in the boot sector, so I need a way to get around this.

I doubt that this is true.

Yes there is very limited space inside a boot sector and even more limited space inside a MBR ... BUT the code in there can load a second stage code from the boot media and continue from there. This second stage code is not limited anymore.

I think TC does not do this simply because it serves no purpose.

You can not deny that your HDD contains encrypted data if the boot sector is not "normal" or "standard". Being able to deny any kind of encryption is of the essence in security... otherwise somebody will place a gun at your head or at your kids/wife/friend's head and "kindly" ask you for password/key/whatever he needs... works every time.

Besides there is no time to decrypt a full HDD "on the fly" at boot time and the OS must be able to read it's boot files from the HDD and it will be unaware of your encryption.

Hence TC concentrates on hiding encrypted data in files or inside hidden partitions AFTER the PC/OS has performed a normal boot.

Doing such operations at boot time serves no purpose... well no purpose  without special support from the OS and hardware devices on the motherboard and CPU level (such special motherboards do exist).

I think I've got a disk editor somewhere so if I get desperate I'll just hand-write the data direct to the disk until I have something more formal sorted out.

You can also use rawwrite, partcopy, rawwritewin, or write your own application in windows to access the raw disk interfaces if you are admin of that machine.

Are the mini OS guys on this board?

Yes I am here (Solar_OS http://www.oby.ro/os/index.html) but I had to close a few of your initial threads and I am still kind of reluctant concerning your real motives for asking such questions.

For OS dev forums you can also check: http://forum.osdev.org/ This is where hobby OS developers usually chat.

Accessing the USB device from boot sector or from your own mini OS is not going to be simple. Trying to do it in 16 bits CPU mode is going to complicate things additionally.

Other than boot time emulation you will have NO support from BIOS for your USB device.

You will have to read the documentation of your hardware device and the USB standards and implement your own USB stack  and drivers in order to communicate with an USB device from your own stand alone code. You will also need PCI drivers for the USB host controller interfaces.

I did that USB thing / drivers in Solar_OS. My advice is to do it in 32 bits and not in 16 bits in order to ease the pain a little.

For you the general idea would be to:
1) in you 2nd stage loader temporary switch the CPU in 32bits protected mode using a flat memory model
2) access USB key and perform additional security actions
3) return to real mode and continue chain loading the OS

However IF you decrypt something on HDD in step 2) then a hardware reset at that point followed by a boot from another media (CD-ROM/USB/Floppy) will leave your decrypted HDD data naked and exposed.

[Astro]

I think TC uses the "well known" PKCS#11 as a crypto token interface API. But then again you should have known this if this is your real level of interest or work experience.

Actually - it only supports tokens *after* the system has booted and Windows is up and running. It does *NOT* support pre-boot authentication mechanisms other than passwords at the present time (I wish to change this).

The part about space in the boot loader being the reason is the reason cited on the TC forums many times. If you doubt this, please go take a look.

http://www.truecrypt.com/

TC can't put its own boot loader code into an encrypted partition for many reasons. It would require some reserved space (akin to Linux /boot partition) at the start of the disk to contain the additional boot code. TC does not modify partition layout, and this is why it is limited to the boot sector.

One change my mod would require is to create a small partition to contain the rest of the boot loader.

What exactly is this "more" thing that you want to "add" ?

A form of token authentication (some WDE systems accept a smartcard prior to boot), except I want to put on spin on this idea.

Hence TC concentrates on hiding encrypted data in files or inside hidden partitions AFTER the PC/OS has performed a normal boot.

If you look, TC supports whole disk encryption. The OS itself is encrypted (boot files included). TC loads itself ahead of the OS. Don't ask me how that works - I haven't looked yet.  :dazzled:

I think TC does not do this simply because it serves no purpose.

No-one knows the reason why they didn't include it - all that is known at present is that they won't. Other WDE products do include the functionality to use tokens and smartcards, and I can see the point (take a stolen laptop for example).

This mod needs to be made in order to work with our hardware, the way we desire. We can't take an off-the-shelf solution as our device wouldn't be compatible anyway.

At the least, please familiarise yourself with the *current* functionality of TC, especially as you seem to doubt my intentions. It would appear you are unaware of the WDE function of TC (introduced in TC5 I think).

Thanks for the links - I'll check them out.  :thumbu

Best regards,
Robin.

[BogdanOntanu]

...
Actually - it only supports tokens *after* the system has booted and Windows is up and running. It does *NOT* support pre-boot authentication mechanisms other than passwords at the present time (I wish to change this).

I did not say that TC does support pre-boot token authentication. All I have said was the "well known" name of the API that is used in this industry in order to perform authentication with smart cards and tokens. This should have helped your in 2 ways:
1) your device's wiil become compatible with other software and hardware.
2) you know what API you have to implement

The part about space in the boot loader being the reason is the reason cited on the TC forums many times.

Maybe it is "quoted" ... but IMHO nobody considers that such a task can be done in the limited space of a boot sector. Any sane human will consider reading a second stage code from some media. I was trying to give you a hint...

Sometimes you have to read in "between the lines". I really doubt that THAT is the real reason why they do not implement is even IF they say so... ;)

If you doubt this, please go take a look.
http://www.truecrypt.com/

Thank you for the link.... never heard of it :P

However I do use TC on a daily basis because it is required by my tasks when I handle sensitive security info for my work/job. Well,to be more exact I do not have to use it every day starting from 16.09.2009... because I have returned to work in the office ... wow 3 days without TC ... :P

TC can't put its own boot loader code into an encrypted partition for many reasons.

a) it will be too easy to hack.
b) can not deny encryption (very important feature)
c) might require hardware and BIOS support

It would require some reserved space (akin to Linux /boot partition) at the start of the disk to contain the additional boot code. TC does not modify partition layout, and this is why it is limited to the boot sector.

Such reserved space is already there. There is a slack of approximative 64 sectors or less in between the MBR and the start of the first partition. Some security WDE software did used it in the past. Today such concepts are made obsolete by motherboard / BIOS pre-boot authentication support.

Additionally it is very simple to reserve such space in between partitions or even create a separate partition. No problems here other than being very easy to detect.

By today standards all clients that require such a feature use special motherboard hardware + BIOS support + UEFI ... and guess what API they use to authenticate with the smartcard/fingerprint/token ?

One change my mod would require is to create a small partition to contain the rest of the boot loader.

That is one valid option ...  but kind of obsolete IMHO.

A form of token authentication (some WDE systems accept a smartcard prior to boot), except I want to put on spin on this idea.

I see.

Please see above: you need hardware support for this and you must conform to hardware/BIOS/UEFI standards if you want to stand any chance. A software only solution using  a hardware token at boot time BUT without BIOS/ motherboard support is sub-optimal and offers no additional advantage when compared to having encryption only AFTER the OS has booted.

Any attacker can re-install another standard Windows XP for example and then sell the stolen laptop. The laptop's HDD can be replace with ease. With no support from motherboard hardware you can not stop this.

The protected DATA is secure encrypted in a hidden file or in a hidden encrypted partition even IF the boot process and OS was not "protected".

However with WDE you can not deny that you have any sensitive data on your laptop and this makes you a bigger target.
As I have said before being able to deny any encrypted data IS an important feature.

If you look, TC supports whole disk encryption. The OS itself is encrypted (boot files included). TC loads itself ahead of the OS. Don't ask me how that works - I haven't looked yet.  :dazzled:

Pretty easy... any boot manager does this...  BUT as I have said above it offers no real advantage, only problems.
Check XOSL boot manager source code to see how you can run something relatively big before the OS boot.

No-one knows the reason why they didn't include it - all that is known at present is that they won't. Other WDE products do include the functionality to use tokens and smartcards, and I can see the point (take a stolen laptop for example).

I think it is pretty clear why they do not include it: there is no purpose. Your sensitive data is safe if your laptop is stolen even if it is stored inside an encrypted file... in fact the attacker might not even know that it is there and you might recover it free of charge at a later time.

Not being able to reinstall another OS and to use the stolen laptop requires support from the motherboard hardware and BIOS and raises big suspicions.

A simple USB token is not enough for such a feature even if it has GSM or satellite tracking devices. It is much better to have those things on the motherboard.

The USB token can be thrown away in a second, the HDD changed in a minute and the OS reinstalled... however it is much harder to change the motherboard of a laptop...

Additionally the USB token can be sniffed by an intermediate device. Also the attacker can stole only the token and make an DOS attack.

It is very hard to steal my password from my mind if is do not want to tell it to you... and it is very hard to deny the use of my password once you left the room... and without WDE you might not even notice that there is anything sensitive on my HDD/laptop and leave it there.

Of course that USB tokens are usefully... but IMHO after the OS has booted... used as a hard to copy key. No need to remember the password ... but it can be lost or stolen like any physical key :D

As for the device tracking and  BOOT time features it is much better to have them on the motherboard... and make it very HARD to physically remove them without damaging it if possible.

This mod needs to be made in order to work with our hardware, the way we desire. We can't take an off-the-shelf solution as our device wouldn't be compatible anyway.

I have guessed that much and I have tried to make you aware of the problems. IMHO the correct solution is to study some existing hardware+BIOS solutions that work with multiple devices (smartcard or token or fingerprint device) and make your OWN device compatible with the requirements and API or protocols used and comply to the standards in this area....

At the least, please familiarise yourself with the *current* functionality of TC, especially as you seem to doubt my intentions.

I am familiar with TC because I use it every day.

However I fail to see the connection with my doubt in you. My doubt will stand but I will comply with Hutch decision to allow some of your posts ... after all it is his forum and his rules ;)

May it be that in time this doubt will fade away if you show good will.

It would appear you are unaware of the WDE function of TC (introduced in TC5 I think).

I am aware of WDE. However I consider it a poor choice without motherboard hardware + BIOS support.

Thanks for the links - I'll check them out.  :thumbu

I also remembered that the FASM forums have a sub forum dedicated to OS development and somebody with the nick pfranz posted some bootable hardware tests that included some USB code... it might be handy as a start for talking to your device from a boot environment:http://board.flatassembler.net/topic.php?t=6544

However do not expect any short cuts... it IS  a LOT of work.

[Astro]

Hi,

Your points are noted.

We are not interested in the laptop/hard disk. Steal away! :D

We are also working under the assumption the attacker is all-knowing, down to the contents of the drive.

Your point on denying encryption is valid, but deniability is a very dodgy area. It is only truely invisible when the attacker doesn't know what he's got, and doesn't look to see if something may be there. If the attacker knows (our assumption), it merely makes their task harder.

Best regards,
Robin.