The MBR is the first absolute sector of the device or LBA 0 and sure it is 512 bytes in size.
What a normal BIOS does is (essentially) the following:
1 let me check that the last two bytes of first sector are 55 AA
2.a if they are not, hang or reboot
2.b if they are, simply run the code in the MBR
So what changes behaviour when booting is the actual code in the MBR.
Let's set aside the grldr.mbr (that has code that spans beyond the first sector, and all other "complex" MBR's), a *normal* MBR code does the following:
1. Read the partiton table (i.e. the 4 entries of 16 bytes each starting at offset 446 in the MBR itself) addresses
2. find if among them there is one marked as "active", if there is, then:
3. chainload the first sector (the PBR) at the address of the entry marked as active and execute the code there (which in itself will load the loader or system file, etc.)
What the UMBR does:
1. Read an address in *another* structure, similar to a partition table, this address is set up to the absolute LBA extents of a grldr
2. chainload that (i.e. chainload grldr directly)
What my modified MBR code does (in the specific case of a "hidden partition on GPT disk):
1. Read an address in *another* structure, similar to a partition table, this address is set up to the absolute LBA extents of a small volume residing bewtween the GPT reserved sectors and the first "real" volume, i.e. normally unused and blank area
2. chainload the first sector (the PBR) of that minimal volume, that is the "normal" grub4dos floppy PBR, i.e. that chainloads grldr directly.
Now, this small partition needs to be "hidden" in the specific case of a GPT disk modified to boot on a BIOS machine in a way that doesn't alter *anything" when on UEFI, but in a "normal" BIOS only MBR disk you can have its address duplicated in the "real" partition table and so make it visible (and no need to have it active), but again we are back to the good ol'advice by Gilles Vollant (the Author of Winimage), which paraphrased says, no matter what, always have a small FAT partition active, if you can "afford" to "waste" one of the 4 partition entries for a small FAT volume, that is the most flexible approach.
Back to the grldr.mbr, it is a far more complex piece of code.
When it is started by the BIOS it looks for all disks connected to find the grldr (and this scan is likely what makes it hang in your case) as - by design - it is not intended to boot from a grldr on a given partition.
Finally the UMBR is "good" BUT when/if you update the grldr or even - in some cases - you defragment the volume where grldr resides (let alone if you expand/shrink/move partitions) you need to re-install the UMBR.
My half-@§§ed approach has the advantages that:
1. the minimal volume resides in an area at the beginning of a disk, that won't be affected by expand/shrink/move of partitions
2. there are no issues when you want/need to update the grldr since the address/size changes are taken care of by the FAT(12) filesystem
BUT (at least in the specific version with the minimal volume "hidden") you need to mount the extent to update the grldr (or to edit the menu.lst there)
To answer your questions, there are many tools that allow to change parts (let's call these parts "data" of the MBR). i.e. the Disk Signature and the Partition table (basically all partitioning tools do this), the rest is "code" and can be modified by any hex editor, but of course the code needs to make sense (it is "pure" assembly).
If you want to play a bit with the MBR (the data part) manually (to see what is inside it) I can recommend Tiny Hexer with my (shameless plug) MBRview and PTNview structure viewer scripts:
 this latter is not really an issue, as the menu.lst in the minimal volume can be written so that it chainloads another menu.lst in a "more accessible" volume.