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 and Supported processors 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

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.

For command-line use, see -T switch loader selection to force a specific loader and skip the dialog.

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.

See Igor's Tip of the Week: Binary file loader.

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 - loads Windows minidump (.dmp) files for static analysis

• DSC workflow - working with Apple DYLD shared cache files

• Loading Qualcomm MBN files - loads Qualcomm MBN boot-image files

Custom loaders

You can develop loaders for unsupported binary formats using the C++ SDK. The SDK ships with sample loaders for various formats — see the src/ldr/ folder in the IDA SDK repository.