The docs have been restructured for better navigation. Found a broken link or have feedback to share? Let us know
here.
Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Loading Qualcomm MBN containers

MBN is Qualcomm's signed firmware-container format. Qualcomm does not expand the acronym in its public documentation; for this boot-image family it is usually read as multi-image binary, after the multi-image boot scheme the format was built for and the MI_ prefix in Qualcomm's own packaging tools. (The .mbn extension is also reused for modem carrier-configuration blobs, where it reads as modem configuration binary, but those are not what this loader targets.) A container prepends a boot or hash-segment header to an embedded ELF image, and follows it with a signature, a certificate chain, and metadata. The embedded image can be almost any piece of device firmware: the secondary bootloaders and TrustZone (ARM and AArch64), the hypervisor (AArch64), the resource power manager (a Cortex-M core), or the modem and DSP images (Hexagon). The loader parses the container and hands the embedded image to the matching processor: QDSP6 for the DSP and modem images, ARM or AArch64 otherwise.

This is why the loader is documented on its own, outside any one processor's pages. If you open a DSP image you get Hexagon; if you open sbl1.mbn or tz.mbn you get ARM or AArch64. The container is the same either way.

Recognizing a container

The MBN loader handles any file whose extension is .mbn, .mdn, .melf, or .pbn, and any file that begins with a recognizable MBN or SBL header. It reads header versions 3, 5, 6, and 7, and the 80-byte SBL header that begins with the magic words 0x844BDCD1 and 0x73D71034. For the MBN-family extensions it is the default choice in the loader-selection dialog.

To load a container, open the file and confirm the Qualcomm MBN (...) entry in the loader-selection dialog. The processor is preset from the embedded image: QDSP6 for a Hexagon image, ARM or AArch64 otherwise.

The loader also recognizes the container layouts that appear in real flash images: GPT-partitioned images, 256-byte-aligned MBN concatenation, the SBL1 layout that inserts a 12-byte magic cookie every 128 KB (the loader stitches the segment back together across the cookies), and XBL_SEC segments that embed a complete inner ELF. An embedded inner ELF, such as a TrustZone image, is extracted and loaded.

Selecting an image

A container can hold several concatenated images. When it does, the loader labels it Qualcomm MBN (Multi-ELF: N images) and lists every image in the Output window with its offset, machine type, bitness, and, for Hexagon images, the ISA version. It then prompts you for the index of the image to load, and marks your choice with [LOADING]. To examine a different image, reload the file and pick another index.

What the loader reports

After loading, read the Output window. The loader logs the decoded header: its version or SBL form, the image type, the code and image sizes, and the signature, certificate-chain, and metadata sizes. Version 7 adds SoC, serial, and OEM fields. It also reports whether the image is marked relocatable, in which case it suggests a rebase alignment, and for a Hexagon image it logs the ISA version.

Segments are created from the ELF program headers. A segment is named after the matching ELF section when one is present, and otherwise after its MBN segment type (AMSS, HASH, BOOT, SWAPPED, and so on) or a generic seg_N. Permissions and the code/data class come from the program-header flags or the MBN access bits. Hash and program-header metadata segments are created read-only as data so they are not mistaken for code.

The entry point is set automatically. When the image records a physical (load) entry address, the loader translates it to the virtual address and adds a start entry point there; the log notes the translation as physical -> virtual.

Watch the log for two notices that affect what you see. An XML metadata header detected or image may be encrypted message means the bytes may not be real code, so the disassembly can be noise. Hash and signature integrity is reported but never required: when a hash table and a matching code segment are found, the loader prints the result of a code-hash check (SHA-1, SHA-256, or SHA-384) as OK or with a mismatch count.

See also

Last updated

Was this helpful?