IMG booting if modified with a jmp instruction

[davide8226]

Dear all,
I have an x86 IMG file booting only if modified by adding a jmp instruction at the beginning, although having a x86 jmp instruction at the beginning seems not to be a requirement according to MBR specs...

Any idea on why this happens?

[scottgus1]

Is this question related to this one: viewtopic.php?p=541553#p541553

[davide8226]

Nope, it is another issue (and related to another img)...

[mpack]

How are we supposed to diagnose this? Telepathy?

Can't comment without seeing a hex dump of the first sector.

[davide8226]

You're right, sorry.

Here attached are therefore the original file "tetros.txt" that does not boot, and the edited "tetros_edited.txt" which does boot, where a jmp instruction (jmp 0x02 in x86 Intel assembly = 0xEB00 in x86 binary) has been added at the very beginning, as first instruction of the MBR.

I used each of these as a floppy image, like booting my VM from a floppy added as VM device (indeed, both files are just the size of MBR...).
My VirtualBox version is 7.0.6 r155176 (Qt5.15.2)

N.B.: They have been here renamed as .txt in order to be able to attach them to this post. Please rename them as .img.

[mpack]

Anyway, the assertion that the VirtualBox MBR BIOS requires a jump instruction at offset 0 is definitely false. None of my MBR sectors has that. It only thing the BIOS requires is that it is valid executable code, because that's how a MBR BIOS boot works: nothing fancy, just load sector 0 into a buffer and jump to it.

And incidentally, neither of the attached files contains an MBR. They both appear to contain boot sector code. This would be the first sector of a bootable partition, or the first sector on a floppy drive. I didn't think ISO's had this sector, but I could be wrong.

[fth0]

Any idea on why this happens?

No, but I'll have a look ...

PS: It's a complete Tetris clone that fits into 446 bytes and can therefore be used as an MBR or as a boot sector. Google "TetrOS" if you're interested.

[davide8226]

Yes, that's why I tested it
And you know, issues usually emerge when dealing with small things...

[davide8226]

Anyway, the assertion that the VirtualBox MBR BIOS requires a jump instruction at offset 0 is definitely false. None of my MBR sectors has that. It only thing the BIOS requires is that it is valid executable code, because that's how a MBR BIOS boot works: nothing fancy, just load sector 0 into a buffer and jump to it.

And incidentally, neither of the attached files contains an MBR. They both appear to contain boot sector code. This would be the first sector of a bootable partition, or the first sector on a floppy drive. I didn't think ISO's had this sector, but I could be wrong.

Sure, that's true and known in theory.
The question on why the exhibited behavior does not fulfill the expectations (and, secondarily, why it works instead with such a (casual) modification...) remains anyway open

[mpack]

The question on why ... it works instead with such a (casual) modification...) remains anyway open

I don't believe there is any mystery there. Any valid executable code at offset 0 will work. I assume the failure indicates that it isn't valid code - I don't have the means to easily disassemble raw Intel binary tho. It's not a direction I commonly need to go in.

[davide8226]

The question on why ... it works instead with such a (casual) modification...) remains anyway open

I don't believe there is any mystery there. Any valid executable code at offset 0 will work. I assume the failure indicates that it isn't valid code - I don't have the means to easily disassemble raw Intel binary tho. It's not a direction I commonly need to go in.

...but the x86 opcode in the edited MBR has just been shifted by 2 bytes, thus getting at byte 2 of the edited MBR instead of its original position at byte 0 in the original file.
So it cannot be an invalid x86 opcode issue...

[mpack]

VirtualBox has no mechanism to affect the contents of the MBR in any way, so I'm not sure what you are saying. If the code is offset by 2 bytes then the tool (or person) which wrote the code to sector 0 is buggy.

And in any case, the VirtualBox BIOS seems to have no problem with any of the many guest OS's it successfully boots.

[fth0]

I can confirm that the issue is also reproducible with VirtualBox 6.1.46. VirtualBox successfully loads the boot sector from a virtual floppy disk image or the MBR from a virtual hard disk image, and in both cases "for some reason" decides that "VMMDev: Guest Log: BIOS: Boot from [...] failed".

I think there will be some checks taking place before control is given from the VirtualBox BIOS to the loaded code ...

[fth0]

Inserting the two bytes also shifted the artificial partition table entry (for the MBR case). To see if the jump or the shift plays a role: What happens if you insert "0x90 0x90" instead of "0xEB 0x00"?

Interestingly enough, the result of this test would have mislead me.

I'll explain this later ...

[davide8226]

Inserting the two bytes also shifted the artificial partition table entry (for the MBR case). To see if the jump or the shift plays a role: What happens if you insert "0x90 0x90" instead of "0xEB 0x00"?

Nice idea, thank you. Indeed, I have just tried and it works with 0x9090 as well (instead of 0xEB00).
So it seems like misplaced partition table issue?
But as opcodes are sequentially executed, the first opcodes should not be executed anyway, with issues eventually showing up at a (even short in time but) later stage?

As I was reading your reply I remembered that I already gave it a try before today by not shifting the partition table of two bytes, as I aware - like you highlighted - that the insertion of two bytes at the beginning for the jmp instruction would have shifted the partition table as well.
And, well... it correctly booted that way, too!
So it seems not a misplaced partition table issue, thus...