# 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 * [Hexagon support](/9.4/core/disassembler/concepts/hexagon.md), for the DSP images these containers carry * [Supported processors](/9.4/core/disassembler/specification/supported-processors.md) * [-T switch loader selection](/9.4/core/user-interface/concepts/command-line-switches/t-switch-loader-selection.md) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.hex-rays.com/9.4/core/disassembler/how-tos/loading-qualcomm-mbn.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.