Module ElfSource

Linux ELF parser based on /usr/include/elf.h

What is the Auxiliary Vector?

The auxiliary vector (auxv) is a mechanism used by the Linux kernel and other Unix-like systems to pass system and program-specific information to user programs at startup. It consists of an array of key-value pairs containing essential data that programs and dynamic linkers need to function properly.

Purpose and Usage

The auxiliary vector serves several critical purposes:

• Provides system information (page size, CPU features, security context)
• Passes program metadata (entry point, program headers location)
• Enables efficient dynamic linking without filesystem access
• Allows secure communication of sensitive data (user/group IDs)
• Supports performance optimizations by avoiding redundant system calls

Common auxiliary vector entries include:

• AT_PAGESZ: System memory page size (typically 4096 bytes)
• AT_PHDR: Memory address where program headers are loaded
• AT_ENTRY: Program entry point address
• AT_BASE: Base address of the dynamic linker/interpreter
• AT_UID/AT_GID: Real user and group IDs for security context

Memory Location

The auxiliary vector can be accessed from two sources:

• Memory: Located on the program stack above environment variables during startup
• Filesystem: Available via /proc/<pid>/auxv for any running process

The exact memory location is platform-specific; consult the platform ELF ABI documents for details. See: https://refspecs.linuxbase.org/elf/x86_64-abi-0.99.pdf

The auxiliary vector is essential for program interpreters and dynamic linkers (such as /lib/ld-linux-x86-64.so.2) to bootstrap the dynamic linking process without requiring additional system calls to examine executable files.

ELF Sections and Segments

ELF files organize their content using two overlapping but distinct structures: sections and segments. Understanding their relationship is crucial for working with ELF files effectively.

Sections vs Segments

Sections are used during linking and debugging:

• Fine-grained organization of data and code
• Each section has a specific purpose (code, data, symbols, strings, etc.)
• Defined by the Section Header Table
• Used by linkers, debuggers, and analysis tools
• Can be stripped from executables to reduce size

Segments are used during program loading:

• Coarse-grained organization for runtime loading
• Group related sections together for efficient loading
• Defined by the Program Header Table
• Used by the OS loader and dynamic linker
• Essential for program execution (cannot be stripped)

Memory Layout Relationship

ELF File Structure:
+------------------+
|   ELF Header     |  <- Points to both header tables
+------------------+
|  Program Headers |  <- Segments (for loading)
+------------------+
|                  |
|   File Content   |  <- Actual data/code
|                  |
+------------------+
| Section Headers  |  <- Sections (for linking/debug)
+------------------+

Segment-to-Section Mapping:
+----------------+     +------------------+
|    LOAD        |---->| .text (code)     |
|   Segment 1    |     | .rodata (const)  |
+----------------+     +------------------+
|    LOAD        |---->| .data (init var) |
|   Segment 2    |     | .bss (uninit var)|
+----------------+     +------------------+
|   DYNAMIC      |---->| .dynamic         |
+----------------+     +------------------+

Common Sections

• .text: Executable code
• .rodata: Read-only data (string literals, constants)
• .data: Initialized global and static variables
• .bss: Uninitialized global and static variables
• .symtab: Static symbol table (for debugging)
• .dynsym: Dynamic symbol table (for runtime linking)
• .strtab/.dynstr: String tables for symbol names
• .rel/.rela: Relocation information
• .dynamic: Dynamic linking information

Common Segments

• LOAD: Segments to be loaded into memory (typically .text, .data)
• DYNAMIC: Dynamic linking information
• INTERP: Path to program interpreter (dynamic linker)
• NOTE: Auxiliary information (build ID, ABI notes)
• GNU_STACK: Stack permissions and properties

Why Two Systems?

The dual organization serves different phases of a program's lifecycle:

• Link time: Sections provide fine-grained control for combining object files
• Load time: Segments provide efficient bulk loading with proper permissions
• Debug time: Sections provide detailed symbol and debugging information
• Strip time: Sections can be removed while preserving executable functionality

Standard ELF Symbol Tables

ELF files contain standardized symbol tables as defined by the ELF specification and System V Application Binary Interface (ABI):

Static Symbol Table (.symtab)

• Contains all symbols in the object file (local, global, debug information)
• Used by debuggers, profilers, and development tools
• Often stripped from release binaries to reduce file size
• Uses read_symbol_table with ~symtab_name:".symtab"
• Associated string table: .strtab

Dynamic Symbol Table (.dynsym)

• Contains only symbols needed for dynamic linking at runtime
• Always present in dynamically linked executables and shared libraries
• Smaller subset focused on runtime symbol resolution
• Cannot be stripped as it's required for program execution
• Uses read_symbol_table with ~symtab_name:".dynsym"
• Associated string table: .dynstr

Usage Examples

(* Read default symbol table (tries .symtab first, falls back to .dynsym) *)
let symbols = read_symbol_table buffer header sections

(* Read static symbols explicitly *)
let static_symbols =
  read_symbol_table ~symtab_name:".symtab" buffer header sections

(* Read dynamic symbols explicitly *)
let dynamic_symbols =
  read_symbol_table ~symtab_name:".dynsym" buffer header sections

ELF symbol table entry