2

I'm reading the wikipedia article on Master Boot Record and specifically curious about what (if anything) needs to be in the "bootstrap code area" for the MBR to be readable in modern systems. I used parted to create an MBR on an SD card then used xxd /dev/mmcblk0 to peek at the raw data that was written. I can see:

  • partition entries at 0x01BE and 0x01CE
  • boot signature 0x55AA at 0x01FE-0x01FF

But what is the meaning of the data from 0x0000 through 0x01BD?

Example:

00000000: fab8 0010 8ed0 bc00 b0b8 0000 8ed8 8ec0  ................
00000010: fbbe 007c bf00 06b9 0002 f3a4 ea21 0600  ...|.........!..
00000020: 00be be07 3804 750b 83c6 1081 fefe 0775  ....8.u........u
00000030: f3eb 16b4 02b0 01bb 007c b280 8a74 018b  .........|...t..
00000040: 4c02 cd13 ea00 7c00 00eb fe00 0000 0000  L.....|.........
00000050: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000060: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000070: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000080: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000090: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000100: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000110: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000120: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000130: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000140: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000150: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000160: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000170: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000180: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000190: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001b0: 0000 0000 0000 0000 fed0 4bb2 0000 8020  ..........K.... 
000001c0: 2100 8328 0d0c 0008 0000 f1f2 0200 0003  !..(............
000001d0: c2eb 8303 c1eb f1fa 0200 0000 6000 0000  ............`...
000001e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001f0: 0000 0000 0000 0000 0000 0000 0000 55aa  ..............U.

Some context: This is a disk image for a bootable SD card in a Beablebone-like ARM/Linux SBC. But since the MBR is architecture/ OS independent, I assume - at least on ARM - there is no actual machine code in the "bootstrap code area." Is it x86/ BIOS machine code that exists by convention and is ignored on ARM?

If I wrote arbitrary data in 0x100-0x150 would the MBR still be readable?

Michael Petch
  • 46,082
  • 8
  • 107
  • 198
thom_nic
  • 7,809
  • 6
  • 42
  • 43
  • 1
    I can confirm that the code from 0x0000 to 0x004a is in fact 16-bit x86 code that acts as a chain loader. The code copies itself to 0x600 in memory (from 0x7c00 where it was loaded) then continues executing in the 0x600 memory area. It finds the first partition that has a bootable flag that isn't 0x00 and loads the volume boot record from the first sector of the partition marked active to memory address 0x0000:0x7c00. It then transfers to 0x0000:0x7c00 and executes the code in the volume boot record that was loaded. – Michael Petch Jan 25 '23 at 07:28
  • 1
    My guess is on your ARM beaglebone that the firmware looks at the partition table directly (starting at 0x1be) looking for the one marked active, loads the volume boot record and transfers control to it. I assume the Volume Boot record has ARM code in it. – Michael Petch Jan 25 '23 at 07:28
  • 3
    Basically, I suspect the bootstrap code in the MBR is completely bypassed and the firmware does that work instead. I wouldn't be surprised if you were able to modify any of the bytes less than offset 0x1b8 and still have it work. At 0x1b8 there is a 4 byte disk signature followed by 2 bytes with 0 and then the partition table (4 entries of 16 bytes each) and then boot signature in last 2 bytes. – Michael Petch Jan 25 '23 at 07:44

0 Answers0