This is a comprehensive explanation of addressing in Linux ELF binaries, from the bytes on disk to runtime memory.
- The Three Address Spaces
- ELF File Structure
- Sections vs Segments
- Link-Time Virtual Addresses
- RIP-Relative Addressing in x86-64
- VA to File Offset Translation
- Runtime Loading
- Position-Independent Executables (PIE)
- ASLR (Address Space Layout Randomization)
- /proc/$pid/maps Explained
- Complete Worked Example
When working with ELF binaries, you must distinguish three different "addresses":
┌─────────────────────────────────────────────────────────────────────────────┐
│ THREE DISTINCT ADDRESS SPACES │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ 1. FILE OFFSET │
│ ───────────── │
│ • Byte position within the ELF file on disk │
│ • Range: 0 to (file_size - 1) │
│ • Used by: hexdump, dd, file editors │
│ • Example: 0x1000 means "1000th byte from start of file" │
│ │
│ 2. LINK-TIME VIRTUAL ADDRESS (LVA) │
│ ──────────────────────────────── │
│ • Address assigned by the linker (ld) │
│ • Embedded in the ELF headers and symbol table │
│ • What objdump, readelf, nm display │
│ • For non-PIE: absolute addresses (e.g., 0x401000) │
│ • For PIE: offsets from base 0 (e.g., 0x1000) │
│ │
│ 3. RUNTIME VIRTUAL ADDRESS (RVA) │
│ ─────────────────────────────── │
│ • Actual address in process's virtual memory during execution │
│ • What debuggers (gdb), /proc/pid/maps show │
│ • For non-PIE: RVA == LVA │
│ • For PIE: RVA == load_base + LVA │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
File offset ≠ Virtual address (in general)
The ELF file is not a flat memory image. Different parts of the file get mapped to different virtual addresses, with potential gaps, different alignments, and some parts not mapped at all.
An ELF file has this general layout:
┌────────────────────────────────────────────────────────────────────┐
│ FILE OFFSET 0 │
├────────────────────────────────────────────────────────────────────┤
│ ELF HEADER │
│ • Magic: 0x7f 'E' 'L' 'F' │
│ • Class: 32-bit or 64-bit │
│ • Entry point (virtual address) │
│ • Program header table offset (e_phoff) │
│ • Section header table offset (e_shoff) │
├────────────────────────────────────────────────────────────────────┤
│ PROGRAM HEADER TABLE │
│ • Array of Elf64_Phdr structures │
│ • Describes segments for runtime loading │
│ • Each entry: type, offset, vaddr, paddr, filesz, memsz, flags │
├────────────────────────────────────────────────────────────────────┤
│ │
│ SEGMENT 1 │
│ (might contain .text, .rodata, etc.) │
│ │
├────────────────────────────────────────────────────────────────────┤
│ │
│ SEGMENT 2 │
│ (might contain .data, .got, etc.) │
│ │
├────────────────────────────────────────────────────────────────────┤
│ ... │
├────────────────────────────────────────────────────────────────────┤
│ SECTION HEADER TABLE │
│ • Array of Elf64_Shdr structures │
│ • Describes sections for linking/debugging │
│ • Often at end of file (or stripped away) │
└────────────────────────────────────────────────────────────────────┘
View with:
readelf -h binary # ELF header
readelf -l binary # Program headers (segments)
readelf -S binary # Section headersThis distinction is fundamental and often confused:
┌─────────────────────────────────────────────────────────────────────────────┐
│ SECTIONS vs SEGMENTS │
├───────────────────────────────────┬─────────────────────────────────────────┤
│ SECTIONS │ SEGMENTS │
│ (Linking View) │ (Execution View) │
├───────────────────────────────────┼─────────────────────────────────────────┤
│ • Described by Section Headers │ • Described by Program Headers │
│ • Used by linker (ld) │ • Used by loader (kernel, ld-linux.so) │
│ • Fine-grained logical units │ • Coarse-grained memory mappings │
│ • Examples: │ • Examples: │
│ - .text (code) │ - PT_LOAD (loadable segment) │
│ - .rodata (read-only data) │ - PT_DYNAMIC (dynamic linking info) │
│ - .data (initialized data) │ - PT_INTERP (interpreter path) │
│ - .bss (uninitialized data) │ - PT_GNU_STACK (stack permissions) │
│ - .symtab (symbols) │ │
│ - .strtab (string table) │ │
│ - .rela.plt (relocations) │ │
│ │ │
│ • Can be stripped (optional) │ • Required for execution │
│ • `readelf -S` to view │ • `readelf -l` to view │
└───────────────────────────────────┴─────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐
│ │
│ PT_LOAD Segment (R-X) │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ .text │ .plt │ .rodata │ ... │ │ │
│ │ (code) │ (stubs) │ (strings) │ │ │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
│ PT_LOAD Segment (RW-) │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ .data │ .got │ .got.plt │ .bss (no file bytes) │ │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
typedef struct {
Elf64_Word p_type; // Segment type (PT_LOAD, PT_DYNAMIC, ...)
Elf64_Word p_flags; // Permissions (PF_R, PF_W, PF_X)
Elf64_Off p_offset; // FILE OFFSET where segment starts
Elf64_Addr p_vaddr; // VIRTUAL ADDRESS where segment is mapped
Elf64_Addr p_paddr; // Physical address (usually ignored on Linux)
Elf64_Xword p_filesz; // Size of segment IN THE FILE
Elf64_Xword p_memsz; // Size of segment IN MEMORY (>= p_filesz)
Elf64_Xword p_align; // Alignment requirement
} Elf64_Phdr;Key fields for address translation:
p_offset: where in the filep_vaddr: where in virtual memoryp_filesz: how many bytes from filep_memsz: how many bytes in memory (extra bytes are zero-filled, e.g.,.bss)
gcc -no-pie -o hello hello.cThe linker assigns absolute virtual addresses:
$ readelf -l hello
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000
0x0000000000000518 0x0000000000000518 R 0x1000
LOAD 0x0000000000001000 0x0000000000401000 0x0000000000401000
0x00000000000001bd 0x00000000000001bd R E 0x1000
LOAD 0x0000000000002000 0x0000000000402000 0x0000000000402000
0x0000000000000158 0x0000000000000158 R 0x1000
LOAD 0x0000000000002e10 0x0000000000403e10 0x0000000000403e10
0x0000000000000228 0x0000000000000230 RW 0x1000
Notice:
- VirtAddr starts at
0x400000(traditional x86-64 base) - File offset 0x1000 maps to VirtAddr 0x401000
- The relationship:
p_vaddr - p_offset = 0x400000(constant for these segments)
gcc -pie -o hello hello.c # or just: gcc -o hello hello.c$ readelf -l hello
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000560 0x0000000000000560 R 0x1000
LOAD 0x0000000000001000 0x0000000000001000 0x0000000000001000
0x00000000000001d5 0x00000000000001d5 R E 0x1000
...
Notice:
- VirtAddr starts at
0x0(relative addresses) - File offset often equals VirtAddr (but not guaranteed)
- Actual runtime address = random base + VirtAddr
Your disassembly:
360400f: 4c 8d 05 ca 7f 99 04 lea 0x4997fca(%rip),%r8 # 7f9bfe0
Let's decode this:
┌─────────────────────────────────────────────────────────────────────────────┐
│ RIP-RELATIVE LEA INSTRUCTION │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ Instruction at VA: 0x360400f │
│ Instruction bytes: 4c 8d 05 ca 7f 99 04 (7 bytes) │
│ │
│ Breakdown: │
│ ┌────────┬────────┬────────┬─────────────────────────────┐ │
│ │ 4c │ 8d │ 05 │ ca 7f 99 04 │ │
│ │ REX.WR │ LEA │ ModR/M │ displacement (little-end) │ │
│ └────────┴────────┴────────┴─────────────────────────────┘ │
│ │
│ REX.W = 1: 64-bit operand size │
│ REX.R = 1: extends ModR/M reg field (selects R8-R15) │
│ 8d: LEA opcode │
│ 05: ModR/M byte │
│ - mod=00, reg=000, r/m=101 → RIP-relative addressing │
│ - reg=000 with REX.R=1 → R8 │
│ Displacement: 0x04997fca (little-endian: ca 7f 99 04) │
│ │
│ Calculation: │
│ ───────────── │
│ Next instruction VA = 0x360400f + 7 = 0x3604016 │
│ Target VA = Next_RIP + signed_displacement │
│ = 0x3604016 + 0x4997fca │
│ = 0x7f9bfe0 │
│ │
│ This matches objdump's comment: # 7f9bfe0 │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐
│ WHY USE RIP-RELATIVE ADDRESSING? │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ 1. POSITION-INDEPENDENT CODE (PIC) │
│ • Code can be loaded at any address │
│ • The displacement is relative, not absolute │
│ • Required for shared libraries (.so) │
│ • Required for PIE executables │
│ │
│ 2. SMALLER CODE SIZE │
│ • disp32 (4 bytes) vs absolute 64-bit address (8 bytes) │
│ • Can't even encode 64-bit immediate in most instructions │
│ │
│ 3. NO RELOCATIONS NEEDED AT RUNTIME │
│ • For code referencing code/rodata in same segment │
│ • The relative offset is fixed at link time │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐
│ Common targets of lea ..(%rip), reg: │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ • String literals in .rodata │
│ lea .LC0(%rip), %rdi # "Hello, world!\n" │
│ call printf@PLT │
│ │
│ • Global/static variables │
│ lea global_var(%rip), %rax │
│ │
│ • GOT entries (for external symbols in PIC) │
│ mov stderr@GOTPCREL(%rip), %rax │
│ │
│ • Jump tables (switch statements) │
│ lea .LJTI0_0(%rip), %rax │
│ │
│ • Function addresses │
│ lea my_callback(%rip), %rdi │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐
│ VIRTUAL ADDRESS → FILE OFFSET TRANSLATION │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ Given: target_va (e.g., 0x7f9bfe0) │
│ │
│ For each PT_LOAD segment: │
│ if (target_va >= p_vaddr) AND (target_va < p_vaddr + p_filesz): │
│ file_offset = p_offset + (target_va - p_vaddr) │
│ FOUND! │
│ │
│ If no segment contains target_va within p_filesz: │
│ • If within p_memsz but beyond p_filesz → it's .bss (no file bytes) │
│ • Otherwise → invalid address │
│ │
│ Visual: │
│ ═══════ │
│ │
│ File: │
│ ┌─────────────────────────────────────────┐ │
│ │ p_offset │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ ┌───────────────────────┐ │ │
│ │ │ p_filesz │ │ │
│ │ └───────────────────────┘ │ │
│ └─────────────────────────────────────────┘ │
│ ↕ mapping │
│ Memory: │
│ ┌─────────────────────────────────────────┐ │
│ │ p_vaddr │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ ┌───────────────────────┬──────┐ │ │
│ │ │ p_filesz │ zero │ │ │
│ │ │ (from file) │ fill │ │ │
│ │ └───────────────────────┴──────┘ │ │
│ │ ◄─────── p_memsz ──────────────► │ │
│ └─────────────────────────────────────────┘ │
│ │
│ The zero-fill region (p_memsz - p_filesz) is typically .bss │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
$ readelf -lW binary
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000000 0x0000000000000000 0x0000000000000000 0x3db4e18 0x3db4e18 R 0x1000
LOAD 0x3db5000 0x0000000003db5000 0x0000000003db5000 0x41ebea8 0x41ebea8 R E 0x1000
LOAD 0x7fa1000 0x0000000007fa1000 0x0000000007fa1000 0x003a000 0x003a000 R 0x1000
LOAD 0x7fdb580 0x0000000007fdc580 0x0000000007fdc580 0x0035490 0x0078cd0 RW 0x1000
Target VA: 0x7f9bfe0
Check each segment:
- Segment 1: 0x0 ≤ 0x7f9bfe0 < 0x0 + 0x3db4e18? No (0x7f9bfe0 > 0x3db4e18)
- Segment 2: 0x3db5000 ≤ 0x7f9bfe0 < 0x3db5000 + 0x41ebea8?
- Upper bound = 0x3db5000 + 0x41ebea8 = 0x7fa0ea8
- 0x7f9bfe0 < 0x7fa0ea8? Yes!
- Found in segment 2
file_offset = p_offset + (target_va - p_vaddr)
= 0x3db5000 + (0x7f9bfe0 - 0x3db5000)
= 0x3db5000 + 0x41e6fe0
= 0x7f9bfe0
In this case, file_offset equals VA (common for PIE with aligned segments).
┌─────────────────────────────────────────────────────────────────────────────┐
│ EXECUTABLE LOADING PROCESS │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ 1. execve("./binary", argv, envp) system call │
│ │
│ 2. Kernel reads ELF header, validates magic │
│ │
│ 3. Kernel reads program headers (PT_LOAD segments) │
│ │
│ 4. For PIE/shared objects: kernel chooses random base address │
│ For non-PIE: base = 0 (uses absolute addresses from ELF) │
│ │
│ 5. Kernel maps each PT_LOAD segment: │
│ │
│ For each PT_LOAD: │
│ map_addr = base + p_vaddr (page-aligned down) │
│ mmap(map_addr, p_memsz, prot_from_p_flags, │
│ MAP_PRIVATE | MAP_FIXED, fd, p_offset_aligned) │
│ │
│ 6. If PT_INTERP exists (dynamically linked): │
│ • Kernel loads the interpreter (ld-linux.so) │
│ • Transfers control to interpreter │
│ • Interpreter loads shared libraries, resolves symbols │
│ │
│ 7. If statically linked: │
│ • Kernel transfers control directly to e_entry │
│ │
│ 8. Control reaches _start → __libc_start_main → main() │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐
│ PROCESS VIRTUAL ADDRESS SPACE │
│ (simplified, not to scale) │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ High addresses │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ Kernel space │ │
│ │ (not accessible to user) │ │
│ ├─────────────────────────────────────────────────────────────────┤ │
│ │ Stack │ ↓ grows│
│ │ [rsp points here] │ down │
│ ├─────────────────────────────────────────────────────────────────┤ │
│ │ ↕ │ │
│ │ (unmapped gap) │ │
│ │ ↕ │ │
│ ├─────────────────────────────────────────────────────────────────┤ │
│ │ mmap region │ │
│ │ • Shared libraries (libc.so, etc.) │ │
│ │ • Anonymous mappings │ │
│ │ • File mappings │ │
│ ├─────────────────────────────────────────────────────────────────┤ │
│ │ ↕ │ │
│ │ (unmapped gap) │ │
│ │ ↕ │ │
│ ├─────────────────────────────────────────────────────────────────┤ │
│ │ Heap │ ↑ grows│
│ │ [brk points here] │ up │
│ ├─────────────────────────────────────────────────────────────────┤ │
│ │ .bss (zero-init) │ RW │
│ ├─────────────────────────────────────────────────────────────────┤ │
│ │ .data (init data) │ RW │
│ ├─────────────────────────────────────────────────────────────────┤ │
│ │ .rodata │ R │
│ ├─────────────────────────────────────────────────────────────────┤ │
│ │ .text │ R-X │
│ ├─────────────────────────────────────────────────────────────────┤ │
│ │ ELF headers │ R │
│ └─────────────────────────────────────────────────────────────────┘ │
│ Load base address (0x400000 for non-PIE, random for PIE) │
│ │
│ Low addresses (0x0 typically unmapped - null pointer guard) │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐
│ POSITION-INDEPENDENT EXECUTABLE │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ PIE = executable that can be loaded at ANY address │
│ │
│ Characteristics: │
│ ───────────────── │
│ • ELF type: ET_DYN (same as shared libraries!) │
│ • All code uses position-independent addressing │
│ • Link-time VAs are offsets from 0 │
│ • Kernel adds random base at load time │
│ │
│ Check if binary is PIE: │
│ ──────────────────────── │
│ $ readelf -h binary | grep Type │
│ Type: DYN (Position-Independent Executable file) ← PIE │
│ Type: EXEC (Executable file) ← non-PIE │
│ │
│ Or: │
│ $ file binary │
│ binary: ELF 64-bit LSB pie executable, ... ← PIE │
│ binary: ELF 64-bit LSB executable, ... ← non-PIE │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐
│ NON-PIE (Traditional Executable) │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ Compile: gcc -no-pie -o hello hello.c │
│ │
│ Link-time VA in ELF: 0x0000000000401000 (absolute) │
│ Runtime VA: 0x0000000000401000 (same, always) │
│ │
│ • Code can use absolute addresses │
│ • movabs $0x401000, %rax (valid but rare) │
│ • Predictable addresses → easier exploitation │
│ • ASLR only affects stack, heap, libraries (not main executable) │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐
│ PIE (Position-Independent Executable) │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ Compile: gcc -pie -o hello hello.c (or just gcc, it's default) │
│ │
│ Link-time VA in ELF: 0x0000000000001000 (offset from base 0) │
│ Runtime VA: 0x00005634a2001000 (random base + 0x1000) │
│ │
│ • All references must be relative (RIP-relative, GOT-relative) │
│ • Unpredictable runtime addresses → harder exploitation │
│ • Full ASLR protection │
│ │
│ Runtime address calculation: │
│ ──────────────────────────── │
│ runtime_va = random_base + link_time_va │
│ 0x5634a2001000 = 0x5634a2000000 + 0x1000 │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐
│ PIE CODE REFERENCING GLOBAL DATA │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ Source: │
│ ──────── │
│ const char *msg = "Hello"; │
│ printf("%s\n", msg); │
│ │
│ Generated code (simplified): │
│ ───────────────────────────── │
│ lea .LC0(%rip), %rdi # address of "Hello" string │
│ call printf@PLT │
│ │
│ Why this works at any load address: │
│ ──────────────────────────────────── │
│ │
│ At link time: │
│ .text starts at VA 0x1000 │
│ .rodata starts at VA 0x2000 │
│ "Hello" is at VA 0x2050 │
│ LEA instruction is at VA 0x1100 │
│ displacement = 0x2050 - 0x1107 = 0xf49 (next instruction addr) │
│ │
│ At runtime (base = 0x7f0000000000): │
│ LEA is at 0x7f0000001100 │
│ RIP after LEA = 0x7f0000001107 │
│ "Hello" is at 0x7f0000001107 + 0xf49 = 0x7f0000002050 │
│ │
│ The displacement (0xf49) is CONSTANT regardless of load address! │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐
│ ADDRESS SPACE LAYOUT RANDOMIZATION (ASLR) │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ASLR randomizes base addresses of memory regions at load time. │
│ This makes exploitation harder (attacker can't predict addresses). │
│ │
│ ┌────────────────────┬───────────────┬─────────────────────────────────┐ │
│ │ Component │ ASLR affects? │ Notes │ │
│ ├────────────────────┼───────────────┼─────────────────────────────────┤ │
│ │ Stack │ YES │ Always randomized │ │
│ │ mmap base │ YES │ Shared libs, anonymous maps │ │
│ │ Heap (brk) │ YES │ Randomized offset from data │ │
│ │ PIE executable │ YES │ Random base address │ │
│ │ Non-PIE executable │ NO │ Fixed at 0x400000 │ │
│ │ vDSO │ YES │ Virtual dynamic shared object │ │
│ │ vsyscall page │ Fixed │ Legacy, at fixed address │ │
│ └────────────────────┴───────────────┴─────────────────────────────────┘ │
│ │
│ ASLR Configuration: │
│ ─────────────────── │
│ $ cat /proc/sys/kernel/randomize_va_space │
│ 0 = ASLR disabled │
│ 1 = Stack, mmap, VDSO randomized (not heap) │
│ 2 = Full ASLR (stack, mmap, VDSO, heap) ← default on modern Linux │
│ │
│ Disable for debugging: │
│ ───────────────────── │
│ $ echo 0 | sudo tee /proc/sys/kernel/randomize_va_space │
│ Or for single process: │
│ $ setarch $(uname -m) -R ./binary │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐
│ ASLR ENTROPY ON x86-64 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ Typical entropy bits: │
│ ┌──────────────────┬─────────────┬──────────────────────────────────────┐ │
│ │ Region │ Entropy │ Address range │ │
│ ├──────────────────┼─────────────┼──────────────────────────────────────┤ │
│ │ Stack │ ~30 bits │ Varies by kernel config │ │
│ │ mmap base │ ~28 bits │ Usually 0x7f0000000000 region │ │
│ │ PIE executable │ ~28 bits │ Usually 0x5500000000 region │ │
│ │ Heap │ ~13 bits │ Offset from end of data segment │ │
│ └──────────────────┴─────────────┴──────────────────────────────────────┘ │
│ │
│ Example - Same PIE binary run 3 times: │
│ ────────────────────────────────────── │
│ Run 1: 0x556b3a401000-0x556b3a402000 r-xp /tmp/hello │
│ Run 2: 0x55f8e2c01000-0x55f8e2c02000 r-xp /tmp/hello │
│ Run 3: 0x561a44e01000-0x561a44e02000 r-xp /tmp/hello │
│ │
│ Notice: the offset within the mapping (0x1000) is constant, │
│ but the base address (0x556b3a400000, etc.) changes. │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐
│ /proc/$pid/maps FORMAT │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ address perms offset dev inode pathname │
│ ───────────────────────────────────────────────────────────────────────── │
│ 55d3f4600000-55d3f4601000 r--p 00000000 08:01 1234567 /bin/hello │
│ 55d3f4601000-55d3f4602000 r-xp 00001000 08:01 1234567 /bin/hello │
│ 55d3f4602000-55d3f4603000 r--p 00002000 08:01 1234567 /bin/hello │
│ 55d3f4603000-55d3f4604000 r--p 00002000 08:01 1234567 /bin/hello │
│ 55d3f4604000-55d3f4605000 rw-p 00003000 08:01 1234567 /bin/hello │
│ 7f1c23400000-7f1c23422000 r--p 00000000 08:01 7654321 /lib/x86_64-.../libc.so.6
│ ... │
│ 7ffc12345000-7ffc12366000 rw-p 00000000 00:00 0 [stack] │
│ 7ffc123fe000-7ffc12402000 r--p 00000000 00:00 0 [vvar] │
│ 7ffc12402000-7ffc12404000 r-xp 00000000 00:00 0 [vdso] │
│ ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall] │
│ │
│ Field breakdown: │
│ ───────────────── │
│ address: start-end virtual address range (RUNTIME addresses) │
│ perms: r=read, w=write, x=execute, p=private/s=shared │
│ offset: FILE OFFSET into the mapped file (for file-backed mappings) │
│ dev: device major:minor (08:01 = /dev/sda1) │
│ inode: inode number on that device │
│ pathname: file path, or special region ([stack], [heap], [vdso], etc.) │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐
│ UNDERSTANDING /proc/$pid/maps ENTRIES │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ Example: │
│ 55d3f4601000-55d3f4602000 r-xp 00001000 08:01 1234567 /bin/hello │
│ │
│ This tells us: │
│ ───────────────── │
│ • Runtime VA range: 0x55d3f4601000 - 0x55d3f4602000 (4KB, one page) │
│ • Permissions: read + execute, private mapping │
│ • File offset: 0x1000 (this region comes from file offset 0x1000) │
│ • The file: /bin/hello (inode 1234567 on device 08:01) │
│ │
│ Relationship to ELF: │
│ ─────────────────── │
│ This mapping corresponds to a PT_LOAD segment where: │
│ p_offset = 0x1000 (matches "offset" field) │
│ p_vaddr = 0x1000 (link-time, but runtime adds base) │
│ p_flags = PF_R | PF_X (matches r-xp) │
│ │
│ Calculating base address: │
│ ───────────────────────── │
│ base = runtime_start - file_offset │
│ = 0x55d3f4601000 - 0x1000 │
│ = 0x55d3f4600000 │
│ │
│ This base is added to all link-time VAs to get runtime VAs. │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
# For a running process
cat /proc/$(pidof myprogram)/maps
# Or while running under gdb
(gdb) info proc mappings
# Example useful one-liner: find base of main executable
grep -m1 'r--p.*hello$' /proc/$(pidof hello)/maps | cut -d'-' -f1Let's trace an address from disassembly through to runtime:
$ file mybinary
mybinary: ELF 64-bit LSB pie executable, x86-64, ...
$ readelf -lW mybinary | grep -A1 "Type.*LOAD"
LOAD 0x000000 0x0000000000000000 0x0000000000000000 0x001000 0x001000 R 0x1000
LOAD 0x001000 0x0000000000001000 0x0000000000001000 0x000500 0x000500 R E 0x1000
LOAD 0x002000 0x0000000000002000 0x0000000000002000 0x000200 0x000200 R 0x1000
LOAD 0x002e00 0x0000000000003e00 0x0000000000003e00 0x000250 0x000260 RW 0x1000$ objdump -drwC mybinary | grep lea.*rip
1150: 48 8d 3d a9 0e 00 00 lea 0xea9(%rip),%rdi # 2000 <__cxa_finalize@plt+0x1990>
┌─────────────────────────────────────────────────────────────────────────────┐
│ COMPLETE ADDRESS RESOLUTION │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ STEP 1: Parse the instruction │
│ ───────────────────────────── │
│ Instruction VA: 0x1150 (link-time) │
│ Instruction length: 7 bytes │
│ Displacement: 0x0ea9 (little-endian: a9 0e 00 00) │
│ │
│ STEP 2: Calculate target link-time VA │
│ ────────────────────────────────────── │
│ next_rip = 0x1150 + 7 = 0x1157 │
│ target_va = next_rip + displacement = 0x1157 + 0xea9 = 0x2000 │
│ (Matches objdump comment: # 2000) │
│ │
│ STEP 3: Find containing PT_LOAD segment │
│ ────────────────────────────────────── │
│ Target VA = 0x2000 │
│ Check segment: p_vaddr=0x2000, p_filesz=0x200 │
│ 0x2000 >= 0x2000 AND 0x2000 < 0x2200? YES │
│ │
│ STEP 4: Calculate file offset │
│ ──────────────────────────── │
│ file_offset = p_offset + (target_va - p_vaddr) │
│ = 0x2000 + (0x2000 - 0x2000) │
│ = 0x2000 │
│ │
│ STEP 5: Read from file │
│ ───────────────────── │
│ $ xxd -s 0x2000 -l 32 mybinary │
│ 00002000: 4865 6c6c 6f2c 2057 6f72 6c64 210a 00.. Hello, World!... │
│ │
│ It's a string literal! │
│ │
│ STEP 6: At runtime (example /proc/pid/maps) │
│ ─────────────────────────────────────────── │
│ 55a1b2c00000-55a1b2c01000 r--p 00000000 08:01 123 /path/mybinary │
│ 55a1b2c01000-55a1b2c02000 r-xp 00001000 08:01 123 /path/mybinary │
│ 55a1b2c02000-55a1b2c03000 r--p 00002000 08:01 123 /path/mybinary ← here │
│ 55a1b2c03000-55a1b2c04000 r--p 00002000 08:01 123 /path/mybinary │
│ 55a1b2c04000-55a1b2c05000 rw-p 00003000 08:01 123 /path/mybinary │
│ │
│ Base address: 0x55a1b2c00000 │
│ Runtime VA of string: 0x55a1b2c00000 + 0x2000 = 0x55a1b2c02000 │
│ │
│ Verify in debugger: │
│ (gdb) x/s 0x55a1b2c02000 │
│ 0x55a1b2c02000: "Hello, World!\n" │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐
│ ADDRESS RELATIONSHIPS SUMMARY │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────────┐ │
│ │ ELF File on Disk │ │
│ │ (FILE OFFSETS) │ │
│ └──────────┬───────────┘ │
│ │ │
│ objdump/readelf │ PT_LOAD mappings define: │
│ show LINK-TIME VAs │ file_offset ↔ vaddr relationship │
│ │ │
│ ┌──────────▼───────────┐ │
│ │ Link-Time Virtual │ │
│ │ Addresses (LVA) │ │
│ │ (in ELF headers) │ │
│ └──────────┬───────────┘ │
│ │ │
│ ┌────────────────────┼────────────────────┐ │
│ │ │ │ │
│ Non-PIE PIE Shared Lib │
│ (ET_EXEC) (ET_DYN) (ET_DYN) │
│ │ │ │ │
│ RVA = LVA RVA = base + LVA RVA = base + LVA │
│ (base=0) (base=random) (base=random) │
│ │ │ │ │
│ └────────────────────┼────────────────────┘ │
│ │ │
│ ┌──────────▼───────────┐ │
│ │ Runtime Virtual │ │
│ │ Addresses (RVA) │ │
│ │ (in /proc/pid/maps) │ │
│ └──────────────────────┘ │
│ │
│ │
│ RIP-relative addressing: │
│ ───────────────────────── │
│ displacement = target_LVA - (instruction_LVA + instruction_length) │
│ │
│ This displacement is CONSTANT - works at any runtime base! │
│ │
│ At runtime: │
│ target_RVA = (instruction_RVA + len) + displacement │
│ = (base + instruction_LVA + len) + displacement │
│ = base + target_LVA ✓ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
# View ELF header (entry point, type)
readelf -h binary
# View program headers (segments) - for VA↔file offset
readelf -lW binary
# View section headers
readelf -SW binary
# Disassemble with addresses
objdump -drwC binary
# Find all strings with file offsets
strings -t x binary
# View runtime mappings
cat /proc/$(pidof binary)/maps
# Read bytes at file offset
xxd -s 0x2000 -l 64 binary
dd if=binary bs=1 skip=$((0x2000)) count=64 2>/dev/null | xxd
# Check if PIE
file binary
readelf -h binary | grep Type
# Disable ASLR for debugging
setarch $(uname -m) -R ./binary
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space