What Is an .EXE File?

PE Windows Executable (.exe, .dll)

Overview

PE (Portable Executable) is the binary format used by every executable, dynamic library, driver, and system component on Windows. An .exe is a program that can be launched; a .dll is a library loaded into another process. Both use the identical PE structure, differing only in a header flag and in whether an entry point is meant to be executed directly.

PE is the Windows counterpart to ELF on Linux and Mach-O on macOS. It also underpins .sys drivers, .ocx controls, .cpl control panel applets, and .NET assemblies.

Technical Specifications

Format Details

• MIME Type: application/x-msdownload
• File Extensions: .exe, .dll, .sys, .ocx, .cpl, .scr, .efi
• Category: Binary
• Full name: Portable Executable, derived from Unix COFF
• Introduced: Windows NT 3.1 (1993)
• Architectures: x86, x86-64, ARM, ARM64, IA-64

Magic Numbers

Every PE file begins with a DOS MZ header, followed by the PE signature at an offset stored in the DOS header:

Offset 0x00:   4D 5A                      "MZ"     DOS header
Offset 0x3C:   (4-byte pointer to PE header, e.g. 0x00000080)
Offset 0x80:   50 45 00 00                "PE\0\0" PE signature
Offset 0x84:   4C 01  → 0x014C            i386
               64 86  → 0x8664            x86-64
               64 AA  → 0xAA64            ARM64

The MZ prefix is a compatibility artifact: it is a tiny real-mode DOS program - the DOS stub: that prints "This program cannot be run in DOS mode" if the file is executed under DOS. Every modern Windows binary still carries it.

Identifying a PE file therefore means checking for MZ, following the e_lfanew pointer at offset 0x3C, and confirming PE\0\0 there. A file with MZ but no valid PE signature is a genuine DOS executable, not a Windows one.

File Structure

app.exe
├── DOS Header (MZ)              e_lfanew → offset of PE header
├── DOS Stub                     16-bit "cannot be run in DOS mode"
├── PE Signature                 "PE\0\0"
├── COFF File Header             machine, number of sections, characteristics
├── Optional Header
│     ├── Magic                  0x10B = PE32, 0x20B = PE32+
│     ├── AddressOfEntryPoint
│     ├── ImageBase              preferred load address
│     ├── Subsystem              GUI, console, native, EFI
│     └── DataDirectory[16]      export, import, resource, reloc, ...
├── Section Table
└── Sections
      ├── .text                  executable code
      ├── .rdata                 read-only data, import/export tables
      ├── .data                  initialised writable data
      ├── .rsrc                  resources: icons, dialogs, version info, manifest
      ├── .reloc                 base relocations for ASLR
      └── .pdata                 exception handling data (x64)

Imports and exports

The import table lists the DLLs a binary depends on and the functions it calls from each. The Windows loader resolves these at load time, patching an Import Address Table with real addresses. The export table lists what a DLL provides, by name or by ordinal.

Reading the import table is the fastest way to understand what a binary does: a program importing CreateRemoteThread, WriteProcessMemory, and VirtualAllocEx is doing process injection regardless of what its filename claims.

Resources

The .rsrc section holds icons, cursors, dialog templates, string tables, version information, and the application manifest. Version resources are where the familiar Properties → Details fields come from.

History and Development

PE was introduced with Windows NT 3.1 in 1993, adapted from the COFF format used on Unix System V. It replaced the 16-bit NE (New Executable) format from Windows 3.x, and the name reflected an aim of portability across the processor architectures NT targeted - x86, MIPS, Alpha, and PowerPC.

PE32+ extended the format for 64-bit addressing without changing its fundamental layout. .NET later reused the PE container: a managed assembly is a PE file whose code section holds CIL bytecode and metadata rather than native instructions, with a small native stub to bootstrap the runtime. UEFI firmware applications also use PE.

Common Use Cases

• Windows applications: every .exe a user launches.
• Shared libraries: .dll files providing reusable code and the Windows API itself.
• Kernel drivers: .sys files loaded into kernel space.
• .NET assemblies: managed code in a PE wrapper.
• UEFI applications: bootloaders and firmware utilities.
• Malware analysis: PE parsing is the foundation of static analysis on Windows.

How to Inspect a PE File

Windows tooling

REM Headers, imports, exports, sections
dumpbin /headers app.exe
dumpbin /imports app.exe
dumpbin /exports library.dll
dumpbin /dependents app.exe

REM Verify a digital signature
signtool verify /pa /v app.exe

Cross-platform tooling

# Identify architecture and subsystem
file app.exe

# Full header dump
objdump -f app.exe
objdump -p app.exe          # PE-specific private headers

# Disassemble the code section
objdump -d app.exe

# Extract readable strings
strings -n 8 app.exe | head -40

Python

import pefile

pe = pefile.PE("app.exe")
print(hex(pe.OPTIONAL_HEADER.AddressOfEntryPoint))
print("64-bit:", pe.OPTIONAL_HEADER.Magic == 0x20B)

for entry in pe.DIRECTORY_ENTRY_IMPORT:
    print(entry.dll.decode())
    for imp in entry.imports[:5]:
        print("   ", imp.name.decode() if imp.name else imp.ordinal)

GUI tools

• PE-bear, CFF Explorer, PEview: structural browsers for headers, sections, and tables.
• Ghidra, IDA Pro, Binary Ninja: full disassemblers and decompilers.
• Dependency Walker / Dependencies: DLL dependency graphs.
• Process Hacker / Process Explorer: inspecting loaded PE images in running processes.

Security Considerations

PE files are executable code, and the format is the primary malware delivery vehicle on Windows. Practical points:

• Authenticode signatures live in a data directory; verify them rather than trusting filenames or icons.
• Extension spoofing is common - a file named invoice.pdf.exe with a PDF icon is still a PE binary. Content-based detection catches this immediately, which is precisely the case where reading the bytes beats trusting the name.
• Packing: many samples are compressed or encrypted with UPX or a custom packer, so the on-disk sections bear little resemblance to what runs.
• High entropy sections in a PE often indicate packing or encryption.
• Never execute an unknown PE outside an isolated analysis environment.

Advantages

• Universal on Windows: one format for applications, libraries, drivers, and firmware.
• Rich metadata: version info, manifests, and resources travel inside the binary.
• Code signing: built-in Authenticode support.
• ASLR and DEP support: relocations and security flags built into the format.
• Multi-architecture: the same structure across x86, x64, and ARM.

Limitations

• Windows-only: running PE elsewhere requires Wine or a compatibility layer.
• Complex: the DOS stub, data directories, and RVA arithmetic make parsing fiddly.
• Legacy baggage: every file still carries a 16-bit DOS program.
• Prime malware target: the format's ubiquity makes it the default vehicle for Windows threats.

Related Formats

• ELF: the Unix and Linux executable format.
• MACHO: the macOS and iOS executable format.
• COFF: the object format PE was derived from.
• PDB: the debug symbols that accompany a PE build.
• MSI: the Windows Installer package that typically delivers PE files.