Acessing the Master Boot Record!

[dedndave]

ok - this is from a more recent Phoenix AT-class BIOS document...

1.1.2.1.9 INT 18h, Boot Fault Routine
After POST initializes the system, it calls INT 19h to boot the operating system from the appropriate device. If the INT 19h service fails to load the operating system, then the BIOS (or the operating system boot record) executes an INT 18h instruction, so that the ROM BIOS can regain control and perform an alternate function. By default, EMBEDDED BIOS initializes the INT 18h function to a routine that prints "No boot device available.", and prompts to enter the debugger or SETUP system, or reboot the system. At any point prior to the boot process, user-written code, such as code in ROM BIOS Extensions, can "hook" the INT 18h interrupt vector and gain control in this situation, thereby replacing the default handler in the BIOS. In the original PC, INT 18h jumped to a separate ROM that contained ROM BASIC. The embedded system developer might use this mechanism to execute application code from ROM in the event of a boot device failure.

[laskar01]

Hi y'all!
I need a little help on how EDI, ESI,EBP,ESP,EBX,EDX, ECX and EAX is filled from these instructions.

seg000:0061                 push    large 0                                                    //what is large?
seg000:0067                 push    large dword ptr [bp+8] ; DATA XREF: seg000:00E5r
seg000:0067                                         ; seg000:0125r
seg000:006B                 push    0
seg000:006E                 push    7C00h
seg000:0071                 push    1
seg000:0074                 push    10h
then
seg000:009B                 popad

Kindest regards,
Lasse

[KeepingRealBusy]

The PUSHAD instruction pushes the registers in the following order:

eax,ecx,edx,ebx,esp,ebp,esi,edi (esi is pushed as its value at the start of the process)

The POPAD instruction pops them off of the stack such that the registers are restored to their state at the time of the PUSHAD (just reverses the process).

Dave.

[dedndave]

...PUSHAD stores the contents of ESP (what it was before the PUSHAD instruction)
POPAD does not alter the ESP register

[KeepingRealBusy]

Dave,

You are absolutely correct, as usual.

Dave.

[dedndave]

lol
nahhhhh
i just happened to have previously made the same mistake   :lol:

[KeepingRealBusy]

Dave,

The esi for the PUSHAD was a typo, the POPAD was an omission.

I did this off of the top of my head - I have not yet put my data on this laptop so I cannot yet get to my AMD specs.

If you are interested in a long sad story, I will make up a text description of my "challenges" in updating my systems and PM you, otherwise I will save my energy for the real work to complete my task.

I'll be off-line for a while, see you in a bit.

Dave.

[dedndave]

here's a little trick...

Code: [Select]

        mov     edi,sizeof ICONMETRICS
        pushad
bang - you made a structure on the stack with the size filled in   

[Gunther]

bang - you made a structure on the stack with the size filled in   

Good trick. I hope that I can remember, if I need some day this technique.

Gunther

[laskar01]

Hi y'all and thank you for all help you've given me!  :t

Could you prooofread my comments that I've added to the code?  :icon_redface:

I still don't know how the rest of the code works after the copying of the 512 bytes from 7C00h to 600h and starting of execution from 612h.
My guess is that it is troubleshootingcode and the system through tests with the help of in13, makes it choose between the three error mesages.

Here is a part of my MBR


The grey part is the three error strings, the yellow part is the adresses to the three strings, the blue is a partition table(?)
//Correction the blue number 036h,067h,036h,067h a signature, where the second and fourth byte is always the same.
according to
http://thestarman.pcministry.com/asm/mbr/Win2kmbr.htm#CHS
and the green is a number all MBR have at the end

[dedndave]

I still don't know how the rest of the code works after the copying of the 512 bytes from 7C00h to 600h and starting of execution from 612h.
My guess is that it is troubleshootingcode and the system through tests with the help of in13, makes it choose between the three error mesages.

well - hopefully, the error messages are not needed, right ?   :P

when the computer boots up, the BIOS code reads the boot sector into memory and executes it
it is 512 bytes - not a lot of room for advanced code
the task of the boot sector code is to load a more advanced piece of code into memory and execute it

this process varies from OS to OS
some OS's may read 1 sector in and execute it
some may locate a series of sectors and read them
in DOS, the bootloader had to be the first thing in the data area of the disk
and it had to be in contiguous sectors
that way, the code that loaded it did not have to find it or chain sectors together to load it

i think modern ones read several sectors in and execute
now - the code has some room for more advanced code
like code that is complex enough to locate files on an NTFS drive and load/execute

[laskar01]

Hi people!

I think I understand ca 70% of the code in the MBR-record know. The key to understand the troubleshooting part is to know the structure of the partitiontable http://en.wikipedia.org/wiki/Master_boot_record
Almost all troubleshooting is done checking  offset 0, of the four 16 byte partitiontable-sections.

Should be 80h or 00h. 80 means bootable, 00 is not bootable but is a valid number for offset 0.
If anything else than 0 or 80h at offset 0, immediately the code redirects to output the message "invalid partition table".

The reason we enter a loop that runs maximum 4 times at the beginning of the troubleshooting part is that we are doing an analysis of
of the 4 partitiontable sections.

There is something that bothers me...
1. This MBR is supposed to start at adress 0000:0000.
According to http://thestarman.pcministry.com/asm/mbr/STDMBR.htm#F2
Bios copies this MBR to 0000:7C00 after Power on reset. Where is the code executed if the code itself has a part where it copies
itself to 0000:0600. Can it execute the code that it is copying at the same time?

2. Can I dump 512 bytes from location 0000:7C00? The code that I received on this thread
Dumps memory through this primitive, I believe "szFileName  db '\\.\PhysicalDrive0',0", Can I modify this code for the purpose?

Greatful for your patience :t
Kindes regards,
Lasse

[Farabi]

You can check syslinux code for this purpose. On the 16-bit mode, you can access the disk function using Interupt. I believe reading and writing to the MBR is an easy task, but making it work as you want is the difficult task. You will need to understand how the Disk File System work and it is complicated.

[MichaelTripi68]

Laskar1...in repsonse to your question about whether it can execute code it is copying at the same time:
once the bios passes control to the loaded boot sector at 0000:7C00 the "boot code" starts to execute...in 16-bit REAL MODE.  The memory contents are not "protected" meaning you can read/write to any locations.  So, once the "code" copies itself to address 0000:0600 it then "restarts/continues" execution at whatever "offset" it designated.  The original code that was loaded by the BIOS is essentially "inactive" at that time and can even be "reclaimed" by the copy running at the 0000:0600 location.
Does this help explain anything to you?  I am a new to not only assembler but boot loader code so I have been doing alot of research.  This is my understanding of how the "copy and transfer of control" code works.  Can any experienced coders confirm this for me?   

[goofprog]

The old fashioned way was to use the dos debug tool to look at the MBR.  the MBR is the first 1024 bytes or so in the hard drive...wait that is the boot sector.. meh I guess I don't know.