> For the complete documentation index, see [llms.txt](https://docs.hex-rays.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.hex-rays.com/core/disassembler/concepts/loaders.md). # Loaders IDA loaders are specialized modules that parse executable formats and populate the initial database. They recognize file structures, map binary contents into memory segments, and configure imports and metadata before the disassembler begins autoanalysis. When loading a file, two modules work in sequence: * A **Loader** parses the executable format and extracts code, data, and metadata into an IDA database. * A **Processor Module** identifies and traverses the code in the database and disassembles all bytes to instructions. Each loader typically handles one file format family. Some formats have multiple loaders, for example, a .NET PE file can be loaded as a managed assembly or as a raw PE. IDA presents all suitable options and lets you choose. See [Supported file formats](/core/disassembler/specification/supported-file-formats.md) and [Supported processors](/core/disassembler/specification/supported-processors.md) for lists of formats and architectures that IDA recognizes out of the box. ## What a loader produces A loader builds the database that the disassembler then analyzes. When the loader finishes, the database typically contains: * **Segments** - the file's sections (`.text`, `.data`, `.bss`, ...) mapped to their intended addresses, each with R/W/X permissions declared in the file. Regions that exist only at runtime, such as uninitialized data, are created without byte values. * **Byte values** - file contents copied to the addresses where they will reside in memory, with file offsets translated into virtual addresses. From this point IDA works from the bytes in the database, not from the file on disk. * **Entry points** - the addresses where analysis should begin (program entry, exported functions, format-specific callbacks such as TLS, ...). These are the starting points for autoanalysis. * **Names** - symbols taken from the file, so functions and data appear with their original identifiers instead of generic labels. * **Imports** - external functions and data the file depends on, so calls into shared libraries resolve to meaningful names. * **Relocations** - IDA can adjust addresses correctly if the program is later rebased to a different load address. * **Type libraries and signatures** - give known API functions proper prototypes and argument names. Depending on the format, a loader may also load resources, hand debug information to the PDB or DWARF plugins, and extract format-specific metadata such as .NET tables. Everything else, such as remaining functions and cross-references, is recovered afterward by autoanalysis. ## How IDA selects a loader When you open a file, IDA polls all available loaders and presents the ones that match the file in the **Load a new file** dialog. ![Load a new file dialog](/files/ZA8YD7niFuoLXOfTTYv0) IDA also pre-selects the processor module based on the loader's suggestion. For example, an ELF loader reads the file header to determine whether the target is ARM, MIPS, x86-64, or another architecture. You can override both the loader and the processor selection before confirming. {% hint style="info" %} For command-line use, see [-T switch loader selection](/core/user-interface/concepts/command-line-switches/t-switch-loader-selection.md) to force a specific loader and skip the dialog. {% endhint %} ## Load options The defaults are chosen per format and are correct for most files. The main options are: * **Create segments** - build the segments defined by the file format. If disabled, the bytes are loaded without the format's segmentation. * **Load resources** - parse and load resource data, such as a PE file's `.rsrc`. * **Rename DLL entries** - try to resolve imports that are referenced only by ordinal to their real names. * **Manual load** - confirm or adjust the placement of each segment as it is loaded, instead of letting the loader place everything automatically. * **Fill segment gaps** - create bytes to fill the gaps between segments so the address space is contiguous. * **Create imports segment** - collect imported functions into a dedicated imports segment. * **Loading options** - open an additional, loader-specific options dialog for loaders that provide one. ## Binary file loader The **Binary file** option is always present as a fallback for files that IDA does not recognize — raw binaries without headers or metadata to describe them. You reach for it with firmware dumps, ROM images, extracted shellcode, memory snapshots, and any other headerless blob. Because the file carries no structure, the loader cannot read the memory layout from a header. You must supply it yourself. {% hint style="info" %} See Igor's Tip of the Week: [Binary file loader](https://hex-rays.com/blog/igors-tip-of-the-week-41-binary-file-loader). {% endhint %} ## Archives and containers Some inputs are containers that package multiple programs. For these, the loader lists the members it finds and lets you pick one, extracts that member, and then loads it as if you had opened it on its own. Formats handled this way include: * Static libraries (`.a`, `.lib`) - pick an object member. * ZIP archives - pick a packaged file. * Fat/universal Mach-O - pick an architecture slice (for example `arm64` vs `x86_64`). ## Format-specific loaders Some formats require additional setup or follow a specific loading workflow. The following loaders have dedicated documentation: * [Windmp file loader](/core/disassembler/concepts/windmp-file-loader.md) - loads Windows minidump (`.dmp`) files for static analysis * [DSC workflow](/core/disassembler/concepts/dsc-workflow.md) - working with Apple DYLD shared cache files * [Loading Qualcomm MBN files](/core/disassembler/how-tos/loading-qualcomm-mbn.md) - loads Qualcomm MBN boot-image files ## Custom loaders You can develop loaders for unsupported binary formats using the [C++ SDK](/developer/cpp-sdk.md). The SDK ships with sample loaders for various formats — see the [`src/ldr/`](https://github.com/HexRaysSA/ida-sdk/tree/main/src/ldr) folder in the IDA SDK repository. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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, and the optional `goal` query parameter: ``` GET https://docs.hex-rays.com/core/disassembler/concepts/loaders.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.