I am an electrical engineer who has recently discovered the need to modify the code in the MBR. Basically I need the ability to execute code on the HDD before, the OS starts up
The editing of the MBR is perfectly possible from within Windows(XP). For this is used the HxD hex editor, you can literily copy-paste a hex file over the MBR, even on your active system drive (use with caution ! :)) http://mh-nexus.de/en/hxd/
As a starting point a would get the MBR of which the source is available, for instance Grub. (So let grub do the botoing to Windows) With this you have a good starting point to do the changes to your MBR. Editing the MBR shouldn't be too hard, as this little piece of software is pretty basic. Some 16bit (DOS) assembler skills are needed though. An other way is to let grub run some extra payload and not changing the MBR at all, but I'm 100% sure if this is possible; please refer to Grub manuals.
If you can make a floppy, cd or memory stick that will boot to a MS command prompt, and have a matching version of MS debug, you can read and write to the MBR as below. A machine running win95 or win98 should be able to create a boot floppy for you. Just copy debug from the windows\command directory to the floppy.
inside debug: use the r command to change register values. set ax to 0201 for read, or 0301 for write. set es:bx to the starting address of the memory (buffer) you wish to use. 0000:7C00 might work, as this is typically the area that your next sector gets read to in the boot process. set cx to 0001 to read / write one sector of 512 bytes. set dx to 0080 for first physical hard drive.
use the "a" command to assemble the one line of code: INT 13h
use the "p" command to proceed. The data will be read or written, based on your choice of AX.
You could read to memory, "n" to name a file, "w" to write the file, and then edit a copy of the mbr in some other program. Once complete, use debug's "n" and "L" to name and load the edited MBR file, and call int 13h using ax= 0301h to write the image to the correct sector.
Basically I figure I'll insert a call and leave the rest of the MBR alone
What will be called by this subroutine call? The only code in memory at that point is whatever is in the MBR or ROM.
Please think carefully about whether you really need this or that's there's not a better alternative before you spend too much time on it. Third-party code written to an MBR (other than the MBR that the OS loader puts in there) is often not well received by users because:
So if you do decide to continue on this path, please tread carefully and be prepared for headaches.
There are various ways of writing to the boot sector of a drive, and there is a general reference I used back when I was experimenting with homebrew OS development: http://wiki.osdev.org/
I personally just boot under linux and use dd:
Backup first
dd if=/dev/sda of=~/windows_bootloader.bin bs=512 count=1
Disassemble the bootloader
ndisasm -b16 -o7C00h ~/windows_bootloader.bin > ~/windows_bootloader.asm
Make your modifications and reassemble
nasm ~/windows_bootloader.asm -f bin ~/modified_bootloader.bin
Overwrite the bootloader
dd if=~/modified_bootloader.bin of=/dev/sda bs=512 count=1
This assumes your that 'sda' is the correct block device. And note that the step 4 doesn't just copy the file to /dev/sda (which it could, but then you might overwrite more than just the first sector if the output binary > 512 Bytes )
Obviously you're not going to want to debug this approach on a live system. It will save you a lot of headaches to use some kind of x86 emulator like bochs, qemu or VMWare Server.
However as Michael Burr has stated, this will probably be a bad idea. Modifying the Windows bootloader, will probably leave you with little or no room for your own code.
I found a similar question which may help:
Modifying the MBR of Windows
However, you may want to elaborate on what you plan to do. As I have found out myself bootloader code can be quite tedious to work with. Also, I would certainly test this with a floppy if possible.
As far as actually doing this all from Windows, I am a bit clueless. Just about all of my programming experience to this point has been under a Unix environment.