Strictly speaking, mbmloader1) is one of the first components in the boot_chain. It verifies and then loads the mbm component. It checks mbmbackup for newer versions of mbm, so that mbm cannot be downgraded2).
More generally speaking, we sometimes say “mbmloader” to refer to the whole bootstrap system, which is composed by the CH table, the Initial Software image, and mbmloader itself (inside the ISW image). For example, the mtd-hack module by janneg allows us to dump mtd00 which includes all of these, and we usually call this the “mbmloader dump” or “mbmloader CG”.
It seems the mbmloader has public certificates on it (see the ISW section). These certificates don't seem to be in any recognizable format, but they conform to CSST's HS signed image format, so we can assume mbmloader is signed. We also know that both the Milestone and the Droid run in HS mode, which requires this format.
According to the CSST's use of openssl, the openssl “commands” used to generate the certificates may somehow be intercepted. Moreover, analyzing the csstcli(command line tool) and it's parameters may identify what and how the certificates are signing upon.
mbm is Motorola Boot Manager3). According to the Boot Chain, mbmloader will pass the control to mbm after the signature embedded in mbm is verified.
yakk has contributed his effort to map many high level functions name for the mbmloader image. This allows easier inspection of how the verification of mbm is performed. Perhaps he has already reviewed the related portion of codes for potential vulnerability, trying to document the findings that allows continuation could be a possible way to figure out a way.
mbm is read into address 0x8f310000.
Search for the end of signature mark(the data length suggests a sha1sum):
6B D3 98 E2 D6 F0 F8 CF FC D4 96 72 5E B3 A8 B3 6B F9 B1 16