Binary Formats & Tools — Reading ELF and PE Like a Map

What you'll learn

By the end of this lesson you will be able to:

• Read the structure of an ELF file by hand and with readelf: the header, the sections (the linker's view) and the segments (the loader's view)
• Explain what symbols, imports, exports and relocations tell you about a program, using nm, readelf and objdump
• Find your way through a Windows PE file: the MZ header, the PE signature, the COFF and optional headers, the section table, and convert an RVA into a file offset
• Pick the right tool for each question, from file up to a disassembler and decompiler such as Ghidra

A book is more than its pages 📚

Pick up a library book. Before chapter one there is a cover with the title, then a table of contents that says where every chapter starts. At the back you find an index of names and a bibliography of the other books it relies on. The binder may also have sewn the pages into a few thick bundles that are easier to handle than loose sheets.

An executable is built the same way. The header is the cover. The section table is the table of contents. The symbol table is the index, the imports are the bibliography, and the segments are the sewn bundles that the loader actually carries into memory. In the first lesson you read the cover; in this one you read the rest of the book.

As in every lesson of this track, the files here are a tiny program compiled for the lesson or byte dumps written by hand. Apply these skills only to files you are allowed to analyze.

ELF: one file, two views

ELF is defined by the System V ABI and documented on Linux in the elf(5) manual page. The same file is described twice, for two different readers:

 offset 0   ┌──────────────────────────┐
            │ ELF header (64 bytes)    │  says where the two tables are
 e_phoff    ├──────────────────────────┤
            │ program header table     │  segments: what the LOADER maps
            ├──────────────────────────┤
            │ .interp .dynsym .rela.*  │ ┐
            │ .text .plt               │ │ bytes covered by LOAD segments
            │ .rodata .eh_frame        │ │
            │ .data .got               │ ┘
            │ .comment .symtab .strtab │   for tools only, never mapped
 e_shoff    ├──────────────────────────┤
            │ section header table     │  sections: what LINKERS and analysts use
            └──────────────────────────┘

• A section is a unit for the linker: a name, a type, flags, an address, a file offset and a size. Common types are PROGBITS (bytes stored in the file), NOBITS (.bss: no bytes in the file), SYMTAB/DYNSYM, STRTAB, RELA and DYNAMIC. Flags: A (alloc: occupies memory at run time), W (write), X (execute).
• A segment (one program header) is a unit for the loader: a type (LOAD, INTERP, DYNAMIC, GNU_STACK, GNU_RELRO...), a file offset, a virtual address, a size in the file (p_filesz), a size in memory (p_memsz) and flags R W E. One segment usually holds several sections that need the same permissions. When p_memsz is larger than p_filesz, the loader fills the difference with zeros: that is where .bss lives.

The loader needs only the program headers. The section table is optional for running a program, which is why a stripped, or deliberately damaged, section table does not stop a binary from working, and why you should never trust section names blindly.

Here is real output for this lesson's small program (a 16064-byte PIE built by gcc 13 on Ubuntu 24.04), shortened:

$ readelf -h hello
  Type:                              DYN (Position-Independent Executable file)
  Machine:                           Advanced Micro Devices X86-64
  Entry point address:               0x1060
  Start of program headers:          64 (bytes into file)
  Start of section headers:          14080 (bytes into file)
  Size of program headers:           56 (bytes)
  Number of program headers:         13
  Size of section headers:           64 (bytes)
  Number of section headers:         31
  Section header string table index: 30

Section names are not stored in the section headers themselves but as offsets into a string table; the last field says which section holds those names (.shstrtab, number 30). Note that 14080 + 31 × 64 = 16064, the size of the file: the section header table sits at the very end.

$ readelf -lW hello                       (the four LOAD segments and GNU_STACK)
  Type       Offset   VirtAddr           FileSiz  MemSiz   Flg
  LOAD       0x000000 0x0000000000000000 0x000628 0x000628 R
  LOAD       0x001000 0x0000000000001000 0x00018d 0x00018d R E
  LOAD       0x002000 0x0000000000002000 0x000100 0x000100 R
  LOAD       0x002db8 0x0000000000003db8 0x00025c 0x000268 RW
  GNU_STACK  0x000000 0x0000000000000000 0x000000 0x000000 RW

 Section to Segment mapping:      (readelf's numbers: 00 is PHDR, 01 is INTERP)
   02     .interp .note.gnu.property ... .dynsym .dynstr ... .rela.dyn .rela.plt
   03     .init .plt .plt.got .plt.sec .text .fini
   04     .rodata .eh_frame_hdr .eh_frame
   05     .init_array .fini_array .dynamic .got .data .bss

How to read it: segment 03 is the only executable one and holds all the code. Segment 05 has a FileSiz of 0x25c but a MemSiz of 0x268; the extra 0xc bytes are .bss, zero-filled at load time. GNU_STACK with RW and no E means the stack is not executable; an RWE stack would be a red flag. The type DYN with addresses starting near 0 means the file is position-independent: the loader chooses a random base (ASLR) and every address above is an offset from it.

Symbols, imports and exports

A symbol is a name with a value (usually an address), a size, a type (function or object) and a binding (local, global or weak). An ELF executable can carry two symbol tables:

• .symtab: every name the linker knew, including static functions. It is only for tools, and strip removes it
• .dynsym: only the names needed for dynamic linking, that is the functions the program imports from shared libraries and the ones a library exports. It is allocated memory and must survive stripping, or the program could not be linked at run time

nm prints symbols with a one-letter type; upper case means global, lower case local. Real output for our program, shortened:

$ nm hello
0000000000001149 T add3
0000000000004010 D counter
0000000000001152 T main
                 U puts@GLIBC_2.2.5
0000000000002000 R _IO_stdin_used
0000000000004018 B zeroed
0000000000001090 t deregister_tm_clones
                 w __gmon_start__

• T/t code in .text; D/d initialized data; B/b .bss; R/r read-only data
• U means undefined here: it lives in another file, so it is an import. w is a weak reference that may stay unresolved
• @GLIBC_2.2.5 is a symbol version: the program needs the puts that glibc's interface has offered since version 2.2.5

Now strip a copy. nm answers no symbols, yet nm -D still lists puts and __libc_start_main: imports cannot be stripped, which is why the import list is such a reliable clue in triage. Our own names add3 and main are gone, and Ghidra would show them as FUN_00101149-style labels.

A symbol is not proof that code is used. This build used -O1, and the compiler inlined add3 into main:

$ objdump -d -M intel --no-show-raw-insn hello      (main, shortened)
    115a:  mov    eax,DWORD PTR [rip+0x2eb0]   # 4010 <counter>
    1160:  add    eax,0x5                      # add3(counter, 2) = counter + 2 + 3
    1163:  mov    DWORD PTR [rip+0x2eaf],eax   # 4018 <zeroed>
    1170:  call   1050 <puts@plt>

Exports go the other way: the functions a shared library offers to others. nm -D --defined-only libfoo.so or readelf --dyn-syms libfoo.so lists them, and a library exporting names such as compress_block and verify_signature tells a story before you read any code. C++ names arrive mangled (_ZN3Foo3barEv); nm -C or c++filt turns them back into Foo::bar().

Relocations: the loader's to-do list

When the linker writes a file it cannot know everything: where the program will be loaded (ASLR picks a random base) or where puts will sit inside libc. Every such hole is recorded as a relocation: "at this address, write this value". readelf -r lists them:

$ readelf -rW hello      (shortened)
Relocation section '.rela.dyn' at offset 0x550 contains 8 entries:
    Offset             Info             Type               Symbol's Value  Symbol's Name + Addend
0000000000003db8  0000000000000008 R_X86_64_RELATIVE                         1140
0000000000003fd8  0000000100000006 R_X86_64_GLOB_DAT      0000000000000000 __libc_start_main@GLIBC_2.34 + 0
Relocation section '.rela.plt' at offset 0x610 contains 1 entry:
0000000000003fd0  0000000300000007 R_X86_64_JUMP_SLOT     0000000000000000 puts@GLIBC_2.2.5 + 0

The three types you meet in almost every x86-64 executable (the formulas come from the x86-64 psABI, where B is the load base, S the symbol's address and A the addend):

• R_X86_64_RELATIVE writes B + A. Slot 0x3db8 is in .init_array and must hold the run-time address of the function at offset 0x1140, which only exists once the base is chosen
• R_X86_64_GLOB_DAT writes S into a .got slot, for global data and function pointers
• R_X86_64_JUMP_SLOT writes S into the .got slot that the .plt stub of puts jumps through: call 1050 <puts@plt> lands on that stub
• (In object files you will also see R_X86_64_64, S + A, and PC-relative types that the static linker resolves.)

Lazy or immediate binding. Traditionally JUMP_SLOT entries were resolved lazily, the first time each function is called. Linking with -z now (the dynamic flag BIND_NOW, which this Ubuntu build has by default: readelf -d shows FLAGS BIND_NOW) resolves everything at start-up, and RELRO then makes those GOT pages read-only, so a memory-corruption bug cannot redirect them. The GNU_RELRO segment marks exactly that range.

For an analyst, relocations are gold. In a stripped binary, the relocation that names puts tells you that slot 0x3fd0 means "puts", so every indirect call through it is a call to puts. Disassemblers use exactly this to print call puts@plt instead of a bare address.

PE: the Windows container

Windows programs (.exe, .dll, .sys) use the Portable Executable format, specified by Microsoft in the PE Format documentation. It descends from COFF and keeps an MS-DOS header at the front for compatibility.

 offset 0    ┌─────────────────────────────┐
             │ DOS header "MZ"             │  e_lfanew (4 bytes at 0x3C) = offset of the PE signature
             │ DOS stub                    │  prints "This program cannot be run in DOS mode."
 e_lfanew    ├─────────────────────────────┤
             │ "PE\0\0" signature          │
             │ COFF file header (20 bytes) │  Machine, NumberOfSections, TimeDateStamp,
             │                             │  SizeOfOptionalHeader, Characteristics
             │ optional header             │  Magic, AddressOfEntryPoint, ImageBase, alignments,
             │                             │  SizeOfHeaders, data directories
             ├─────────────────────────────┤
             │ section table (40 B each)   │  Name, VirtualSize, VirtualAddress,
             │                             │  SizeOfRawData, PointerToRawData, Characteristics
             ├─────────────────────────────┤
             │ .text .rdata .data .rsrc    │
             │ .reloc ...                  │
             └─────────────────────────────┘

• COFF file header. Machine is 0x14c for x86, 0x8664 for x64 and 0xaa64 for ARM64. Characteristics is a bit set: 0x0002 means an executable image, 0x2000 a DLL. TimeDateStamp is meant to be the link time, but deterministic builds may store a hash there, so do not treat it as evidence on its own.
• Optional header (required for images despite the name). Magic is 0x10b for PE32 (32-bit) and 0x20b for PE32+ (64-bit). AddressOfEntryPoint is at offset 16 of this header; ImageBase is at offset 28 (4 bytes) in PE32 and at offset 24 (8 bytes) in PE32+. Microsoft's linker defaults to 0x400000 for 32-bit EXEs, 0x10000000 for 32-bit DLLs, 0x140000000 for 64-bit EXEs and 0x180000000 for 64-bit DLLs.
• RVA (relative virtual address). Almost every address inside a PE is an offset from the image base after loading: VA = ImageBase + RVA. To find the bytes of an RVA in the file you need the section table: file offset = PointerToRawData + (RVA − VirtualAddress). Sections are aligned to FileAlignment on disk (default 0x200) and to SectionAlignment in memory (default: the page size, 0x1000 on x86), which is why offsets and RVAs differ.
• Data directories. Sixteen (RVA, size) pairs at the end of the optional header point to the export table, import table, resources, base relocations, debug data, the Import Address Table (IAT), the .NET header and more.
• Imports. For every DLL (KERNEL32.dll, WS2_32.dll...) the import table lists functions by name or by ordinal number. At load time the loader writes their real addresses into the IAT, and code calls through it (call qword ptr [rip+...]). The IAT is PE's equivalent of the GOT.
• Exports. A DLL's export directory lists the names and ordinals it offers.
• Base relocations (.reloc). The places to patch when the image is not loaded at its preferred ImageBase; with ASLR (the DYNAMIC_BASE flag) that is the normal case.

On Linux you can read PE files with objdump -x program.exe (binutils understands PE), Python's pefile library, rabin2 -I -i -E from radare2, or Ghidra. None of these runs the file.

Your toolbelt: which tool answers which question

• What is it? file reads the magic bytes and the header.
• How is it built? readelf -h -l -S for ELF; objdump -x for ELF and PE. readelf parses ELF directly, while objdump goes through the BFD library, which understands many formats.
• What does it need and offer? readelf -d (look for NEEDED), nm -D, readelf --dyn-syms; for PE the import and export directories (objdump -x, pefile, rabin2 -i / -E).
• What does the loader patch? readelf -r, and for PE the base relocation directory.
• What does the code do? objdump -d -M intel for a quick look, then a disassembler and decompiler: Ghidra (free, released as open source by the NSA in 2019), radare2, Cutter (the graphical interface of Rizin, a fork of radare2), IDA or Binary Ninja.

A first session in Ghidra: create a project, import the file (it recognizes ELF or PE and the CPU), accept the auto-analysis, then use the Symbol Tree (Imports, Exports, Functions), the Defined Strings window, the Memory Map (it shows the segments and sections from this lesson, with their permissions) and the cross-references from the static-analysis lesson. Rename things as you understand them.

A practical order for an unknown ELF:

file sample                      # format, architecture, PIE, stripped?
readelf -h sample                # entry point, table positions
readelf -lW sample               # segments and permissions: anything RWE?
readelf -SW sample               # sections: odd names, huge or high-entropy sections?
readelf -d sample | grep NEEDED  # libraries
nm -D sample                     # imports and exports
readelf -rW sample               # which slots get which symbols
objdump -d -M intel sample | less

None of these commands executes the file. The exception to remember from the first lesson is ldd, which may run the program's loader: prefer readelf -d. Unusual structure is itself a finding: a writable and executable segment, a section table that disagrees with the segments, an entry point outside .text, or almost no imports in a large file (a common sign of packing) are all worth a note.

Summary and what to practice next

• An ELF file has two views: sections for linkers and analysts, segments for the loader; only the segments are needed to run it
• p_memsz > p_filesz means zero-filled memory (.bss); segment permissions matter, and writable plus executable is a red flag
• Imports live in .dynsym and survive stripping; exports are what a library offers; relocations say which slot receives which address (RELATIVE = base + addend)
• A PE starts with MZ, e_lfanew points to "PE\0\0", then the COFF header, the optional header (PE32 or PE32+) and the section table; convert an RVA with PointerToRawData + (RVA − VirtualAddress)
• Use file, readelf, nm, objdump first, then a disassembler such as Ghidra; none of them runs the file

Practice next: compile a small C program twice, once with -O0 and once with -O2 -s (stripped), and compare readelf -lW, nm and nm -D for both. Build a tiny shared library with one exported function and find it with nm -D --defined-only. If you have a Windows SDK sample or an open-source Windows program you are allowed to study, load it with pefile and walk its import table. Next: how defenders use all of this to study malicious software safely.