OSDev.org

Posted: **Mon Jun 08, 2009 7:13 pm**

Hey osdev, Im Lye. Pretty new here and havnt been around too long, so bear with me. I had seen a few discussions about os development and took an interest. After browsing around, I came up with an idea.

What Id like to do, is add a password feature before my bootloader is loaded. The plan follows:

Relocate the original MBR to sector 2 (Ive been told this is free?), write my code to the first sector. When my code executes, it relocates its self in mem between 0x100 and 0x7C00 (believe this area is good for use), and passes execution to its relocated self. If the password entry is correct, it will read sector 2 where the original loader is newly located, and load to 7c00h. Now the original loader is where it expects to be, and I can successfully pass execution to it.
My hopes here are that I wont have to write the loader myself, and it wont be case-specific as the mbr is preserved.

The relocation and all will be somewhat of a pain. Any ideas, recommendations, or criticism is welcomed. Especially if theres a simpler way to do this.

Thanks guys.

Edit
Initial code to check for mbr sig, and to write [HERE]
Passcheck code [HERE]
Some of it needs to be cleaned up, but I need to pass the design stage.

Posted: **Mon Jun 08, 2009 8:02 pm**

lye wrote:Hey osdev, Im Lye. Pretty new here and havnt been around too long, so bear with me. I had seen a few discussions about os development and took an interest. After browsing around, I came up with an idea.

What Id like to do, is add a password feature before my bootloader is loaded. The plan follows:

Relocate the original MBR to sector 2 (Ive been told this is free?), write my code to the first sector. When my code executes, it relocates its self in mem between 0x100 and 0x7C00 (believe this area is good for use), and passes execution to its relocated self. If the password entry is correct, it will read sector 2 where the original loader is newly located, and load to 7c00h. Now the original loader is where it expects to be, and I can successfully pass execution to it.
My hopes here are that I wont have to write the loader myself, and it wont be case-specific as the mbr is preserved.

The relocation and all will be somewhat of a pain. Any ideas, recommendations, or criticism is welcomed. Especially if theres a simpler way to do this.

Thanks guys.

Edit
Initial code to check for mbr sig, and to write [HERE]
Passcheck code [HERE]
Some of it needs to be cleaned up, but I need to pass the design stage.

I don't know much about 16 bit code, but I do know that it's more efficient to collapse the strcmp and such down to a single block of assembler (it's only ever going to need to do a single comparison wrt the _KEY). and thus no need to use any non-local-block control transfers.

Posted: **Mon Jun 08, 2009 8:58 pm**

You can look up some asm relocation code here

Posted: **Mon Jun 08, 2009 10:59 pm**

Syn: I know, that isnt a problem at the moment. Im not sure how ill expand this, so It may/not be used later. Please dont quote the whole post though.

Geppyfx: Thanks man, definitely useful. Looks like Ive got the outline pretty much set.

I put together [THIS] to read the 2nd sector of my hard drive to confirm the 2nd sector will be free, and it was. So it looks like I can safely put move the original loader there. Oh, happy days were on our way.

Posted: **Tue Jun 09, 2009 1:59 am**

Hi,

geppyfx wrote:You can look up some asm relocation code here

That website is dodgy - I got this:

Code: Select all

phpBB : Critical Error

Could not connect to the database

This simplest way to relocate might go something like:

Code: Select all

    org 0x7A00

    jmp .start

.start:
    xor ax,ax
    mov ds,ax
    mov es,ax
    cli
    mov ss,ax
    mov sp,STACK_TOP

    cld
    mov si,0x7C00
    mov di,0x7A00
    mov cx,512/2
    rep movsw

    jmp 0x0000:.here      ;Jump to the relocated code
.here:

lye wrote:Relocate the original MBR to sector 2 (Ive been told this is free?)

You were told wrong - the second sector may or may not be free, depending on which boot manager and/or which OS is installed. Boot managers are free to use all the space from the first sector (MBR) to the beginning of the first partition.

For an example, see this web page that describes how GRUB uses these sectors (including the second sector).

Here's another web page for GAG ("Graphical Boot Manager", a different open source boot manager) that says: "GAG doesn't need its own partition. It installs itself in the first track of the hard disk, wich is reserved for these kinds of programs. It can also be instaled on a floppy disk, without using the hard disk."

The only reliable way to have a password at boot is to build your own boot manager (like GRUB or GAG or any of the others), or to add the feature to an existing boot manager.

Of course none of this has anything to do with security...

Cheers,

Brendan

Posted: **Tue Jun 09, 2009 2:31 am**

Understood.

This will be mainly for personal use really as a fun project. I checked on the windows box (xp VM) and the 2nd sector was indeed free. So im OK there for the moment. i know this negates the "universal" aspect, but I still dont have to mess with the bootloader as of yet. I may do this first, then move onto the full stand alone loader.

Youre right, security wont be good. I could XOR encrypt it or something, but a simple look at the loader would give away the pass immediately. I plan on (attempting to) tackle this later. For the moment, a constant key is acceptable.

Brendan: Youre right, the site did the same for me. A simple refresh fixed that. I appreciate you taking the time to write an example. Tomorrow I should have most if not all of this done, so ill post up and let you know how it went.

Posted: **Tue Jun 09, 2009 3:17 am**

lye wrote:Youre right, security wont be good. I could XOR encrypt it or something, but a simple look at the loader would give away the pass immediately. I plan on (attempting to) tackle this later. For the moment, a constant key is acceptable.

That's not the point. Insert a Knoppix CD, and your password check never makes it to the screen...

The "simplified canon" understanding of the matter is, if someone has physical access to your machine, there is nothing you can do to ensure the security of your system, unless your hardware provides the means (intrusion detection / self destruct or something alike).

That's not the whole truth there - you can go far with encrypted partitions et al. - but a password check resulting in a "yes / continue" vs. "no / abort" is the wrong tree to bark up.

Posted: **Tue Jun 09, 2009 3:27 am**

what r u trying to achieve ? I am not able to understand ...
if you are thinking about security, still it is easy to bypass by your idea .

Posted: **Tue Jun 09, 2009 3:28 am**

Oh, well of course.

The point isnt really security. Its just a project I wanted to try, and plan on finishing. If anyone did have physical access and booted a live cd, id hope theyd use something other then knoppix atleast.

Posted: **Tue Jun 09, 2009 6:23 am**

It would be much simpler to just copy the partition table and implement your own MBR rather than trying to keep the old one on copy. It's pretty simple really. If you move the MBR to sector 2, once windows disk manager runs and tries to read the first sector of the disk to find out the partition information, it will not be able to find the correct partition table, and will say that the disk is not partitioned. You must preserve the partition tables in the first sector, everything else is fair game. I have written my own MBR that preserves the partition table, was tested succesfully with windows xp, dos and my own OS. It let me choose my boot partition (so I could boot into windows, dos (for direct access), and my own OS), and preserved the current partition table, all while fitting in the first sector (so I didn't have to worry about if sector 2, etc was free). If you're interested, message me and i'll see if I can dig it up. You can simply change the codes around to ask for a password rather than a partition to boot from. It automatically detects whatever partition is set as the primary and after a timeout (I think 5 seconds I have it set at right now), it will boot into the default if you don't press any key. It then loads the first sector of whatever partition you chose at 0x7C00, sets dl to boot drive, and jumps

. (Yes, it copies itself out of the way before it loads the new sector).

Posted: **Tue Jun 09, 2009 3:08 pm**

Funny, I actually thought about that. It never clicked in my brain to keep the partition table on the first sector though.

It sounds pretty similar to what Im trying, but more feature rich. Contacting you.

Posted: **Tue Jun 09, 2009 9:09 pm**

Well, its almost done. I reread my loader into 0x500, and jmp there. It prints a "load OK" message, the waits for a keypress to load the original loader from sector 2 to 0x7c00. Then it jmps there, and all should be good.

Although, when I jmp to 0x7C00 it re-prints "Sector read OK" like the read didnt load the data there. What am i missing?

Edit-Some code might help, find it [HERE] pass osdev

Pshhh it shouldve been a "jmp 0000:0x7C00". It works,

Dont think ive ever been so happy to see such an ugly screen. Big thanks to jester01 in irc for being such a helpful guy.

Posted: **Wed Jul 07, 2010 3:34 pm**

Sorry to bring up a dead thread, but message sent, sorry, I didn't realize I had a new message, haha. Anyone else wants the code, please message me. I have tested it with windows 98, xp and dos so far and works flawlessly (biggest thing in 98 was setting the active partition flag for the bootsector if you selected the non-default one). Also, if you use it, please note that you must copy it but not overwrite your existing partition table.

OSDev.org

MBR relocation, preserving functionality.

MBR relocation, preserving functionality.

Re: MBR relocation, preserving functionality.

Re: MBR relocation, preserving functionality.

Re: MBR relocation, preserving functionality.

Re: MBR relocation, preserving functionality.

Re: MBR relocation, preserving functionality.

Re: MBR relocation, preserving functionality.

Re: MBR relocation, preserving functionality.

Re: MBR relocation, preserving functionality.

Re: MBR relocation, preserving functionality.

Re: MBR relocation, preserving functionality.

Re: MBR relocation, preserving functionality.

Re: MBR relocation, preserving functionality.