FAT - Boot Record (boot code section 0x3E..0x1FE)

[quadrant]

If you are creating a FAT(16) disk image to just hold files, with no intention of making it bootable, can you fill the whole boot code section (0x3E..0x1FE of the boot record) with zeros?

In this excellent FAT16 tutorial, the section looks like this (yellow):

The text "Non-system disk\nPress any key to reboot\n" makes sense. But what is the blurb before from 0x3E..0x66? Is this a standard blurb?

[alexfru]

That text won’t be printed if there’s no code to print it (nothing would know to look for the text at that non-standardized location). If you disassemble the part after the BPB, you should see a bit of code that prints the text. cd 10 eb f5 looks like int 10h followed by a jump backwards (the author of the recent flame-catchy thread should appreciate my ability to decode machine code with naked eye! ). IOW, there should be code that prints the text using BIOS functionality, one char at a time.

[quadrant]

Ah, I see! Thanks!

[quadrant]

Btw, running it through objdump yielded:

[alexfru]

Btw, running it through objdump yielded:

Must disassemble as 16-bit code.

[quadrant]

Must disassemble as 16-bit code.

Ohh, in that case:

Edit: updated image

[Octocontrabass]

That sample code doesn't work properly. It sets up a stack that's way too small, and relies on the initial value of CS to calculate the location of the message. In some cases, it will display a garbled message, complete gibberish, or nothing at all.

[quadrant]

I double checked and noticed that I transcribed one of the bytes incorrectly . The following:

Code: Select all

43: bc 90 7c

should be:

Code: Select all

43: bc 00 7c

if that makes a difference.

Updated image:

[MichaelFarthing]

It makes a colossal difference.

The correct version sets the top of stck, sensibly, at 0:7c00 giving masses of space for the stack.
The incorrect version sets it at 0:7c90 which is in the middle of the loaded bootcode and as soon as it is used it will start over-writing the loaded instructions!

You should also take note of Octocontrabrass's comment about relying on cs. This is the following lines of code

Code: Select all

call 0x4c
pop %si
add 0x19 %si

which will probably work on the machine you are using and the emulators but will fail on some machines.

There are two solutions:

(a) Replace the code with:

Code: Select all

be 65 7c       mov  0x7c65 %si
90 90 90 90  nop nop nop nop  //nop means do nothing: you are basically stopping the next two instructions doing anything
 

which is far clearer code than the original. The objection to it might be that the code becomes 'position dependent' but in a bootloader this is a bit pedantic.

(b) Use the initial five bytes of the bootloader to get a consistent value in cs by doing a far jump instead of a (near) short jump:

Code: Select all

ea 3e 7c 00 00  jmp far 0x0000:0x7c3e  

(Your disassembly of this may look slightly different: I'm not used to the syntax it uses)
This approach is slightly problematic because the last two bytes mess up the "IB" of the IBM signature at the start of the boot record, but I suspect this is not used anywhere.

[and people says nobody ever writes in machine code... Which is also why this post must be treated with caution: it is very very easy to make mistakes and I may have done so]

[Octocontrabass]

(b) Use the initial five bytes of the bootloader to get a consistent value in cs by doing a far jump instead of a (near) short jump:

Sadly, this is not an option: some operating systems expect the boot record to start with 0xE9 or 0xEB (a near jump) and will reject the filesystem as invalid if it begins with any other byte. You also can't store any code or data in the "IBM signature" since some disk utilities will overwrite it.

If you really want to play machine code golf, you could replace "mov %ax,%ds" with "push %cs" and "pop %ds". If the author of the code was aiming for position-independence, this would be the way to do it. (Unfortunately, it's much more likely that the author simply didn't understand segmentation well enough to realize there was an issue.)

I was going to suggest using a freely-available bug-free alternative, such as the boot sector in dosfstools, but that one has the same bug! I guess if no one has noticed by now, it must not be too important to have working boot code.

[quadrant]

Thank you for the analyses!

[Brendan]

Hi,

If you are creating a FAT(16) disk image to just hold files, with no intention of making it bootable, can you fill the whole boot code section (0x3E..0x1FE of the boot record) with zeros?

In theory; the BIOS has a list of devices it should try to boot from (e.g. maybe "CD-ROM then floppy then hard disk then network") that's configured by the user; and for disks, if the first sector doesn't have the "0x55, 0xAA" signature at the end to mark it as bootable (and doesn't have a jump at the start either); then the BIOS will know that it isn't bootable and simply move on to the next device in its list, and display a "no bootable device found" message if it reaches the end of its list. In this case, you can literally fill the MBR with zeros - no need to have any code at all, and no need to have your own message. Note: For CD ("El Torito") and network boot (PXE) it's essentially the same - BIOS tries to boot from the CD or network, notices that the CD or network can't be booted from, and moves on to the next thing in its list - the only difference is how the BIOS determines that the device is not bootable.

Unfortunately; in practice Microsoft are "excessively unintelligent". For disks that aren't supposed to be booted, MS-DOS and Windows make them bootable (to display a ridiculous "this disk isn't bootable" message when the disk is booted). The consequence of this is that if the user happens to leave a "non-bootable, data only" disk inserted then they have to put up with the unnecessary annoyance of seeing the ridiculous message, then swearing, then removing the disk and then rebooting (and then re-inserting the disk so that they can use the data after the OS boots).

More unfortunately; because Microsoft are "excessively unintelligent" other operating system developers (IBM, Linux, etc) worry about compatibility and/or the probability of things (e.g. BIOS) not working correctly if the OS is sane. For this reason, most operating systems continue to do the same "excessively unintelligent" nonsense.

Ideally, people would stop doing it (and would encourage Microsoft to stop doing it) and eventually (after any compatibility problems are fixed) the unnecessary annoyance it causes would no longer exist.


Cheers,

Brendan

[quadrant]

Ohh, I see, thanks for the info! Theory vs practice bites again!