ELF Files¶

The content of this section is derived from the ELF 1.2 standard, with some modifications and reorganization. The main references are as follows:

1. ELF File Format Analysis, Peking University, Teng Qiming
2. ELF - Destroying Christmas

Introduction¶

ELF (Executable and Linkable Format) files, also known as object files in Linux, mainly have the following three types:

• Relocatable File: Contains code and data generated by the compiler. The linker will link it with other object files to create executable files or shared object files. In Linux systems, such files generally have the .o suffix.

• Executable File: The programs we typically execute in Linux.

• Shared Object File: Contains code and data; these files are what we call library files, generally ending with .so. Generally, there are two usage scenarios:

  • The linker (Link eDitor, ld) may process it along with other relocatable files and shared object files to generate another object file.
  • The Dynamic Linker combines it with an executable file and other shared objects to create a process image.

Regarding the naming of Link eDitor, https://en.wikipedia.org/wiki/GNU_linker

Object files are created by the assembler and linker. They are the binary form of text programs and can run directly on a processor. Programs that require a virtual machine to execute (such as Java) do not fall within this scope.

Here, we mainly focus on the ELF file format.

File Format¶

Object files participate in both program linking and program execution. For convenience and efficiency, depending on the process, the object file format provides two parallel views of its content, as shown below:

First, let's focus on the linking view.

At the beginning of the file is the ELF Header, which provides the overall organization of the entire file.

If a Program Header Table exists, it tells the system how to create a process. Object files used to generate a process must have a program header table, but relocatable files do not need this table.

The section part contains most of the information used in the linking view: instructions, data, symbol tables, relocation information, and so on.

The Section Header Table contains information describing the file's sections. Each section has an entry in the table, providing the section name, section size, and other information. Object files used for linking must have a section header table; other object files may or may not have one.

Here is a more visual representation of the linking view:

For the execution view, the main difference is that there are no sections, but rather multiple segments. In fact, these segments mostly originate from sections in the linking view.

Note:

Although the diagram arranges things in the order of ELF header, program header table, sections, and section header table, in reality, except for the ELF header, the other parts do not have a strict order.

Data Representation¶

The ELF file format supports 8-bit/32-bit architectures. Of course, this format is extensible and can also support processors with smaller or larger bit widths. Therefore, object files contain some control data that indicates the architecture used by the object file, allowing it to be identified and interpreted in a generic way. Other data in the object file is encoded in the format of the target processor, regardless of the machine on which it was created. What this essentially means is that object files can be cross-compiled — we can generate ARM platform executable code on an x86 platform.

All data structures in an object file follow "natural" size and alignment rules, as shown below:

If necessary, data structures can contain explicit padding to ensure that 4-byte objects are 4-byte aligned, to force the size of data structures to be a multiple of 4, and so on. Data is also aligned accordingly. Thus, a structure containing an Elf32_Addr member will be aligned on a 4-byte boundary in the file.

For portability, ELF files do not use bit fields.

Character Representation¶

To be determined.

Note: In the following discussion, we primarily focus on 32-bit as our basis for explanation.

ELF Header¶

The ELF Header describes the overview of the ELF file. Using this data structure, all information in the ELF file can be indexed. The data structure is as follows:

#define EI_NIDENT   16

typedef struct {
    unsigned char   e_ident[EI_NIDENT];
    ELF32_Half      e_type;
    ELF32_Half      e_machine;
    ELF32_Word      e_version;
    ELF32_Addr      e_entry;
    ELF32_Off       e_phoff;
    ELF32_Off       e_shoff;
    ELF32_Word      e_flags;
    ELF32_Half      e_ehsize;
    ELF32_Half      e_phentsize;
    ELF32_Half      e_phnum;
    ELF32_Half      e_shentsize;
    ELF32_Half      e_shnum;
    ELF32_Half      e_shstrndx;
} Elf32_Ehdr;

Each member starts with the prefix e, which should stand for ELF. The specific description of each member is as follows.

e_ident¶

As mentioned earlier, ELF provides an object file framework to support multiple processors and multiple encoding formats. This variable specifies how to decode and interpret the machine-independent data in the file. The meanings of different indices in this array are as follows:

Among these,

e_ident[EI_MAG0] through e_ident[EI_MAG3], the first 4 bytes of the file, are called the "magic number" and identify the file as an ELF object file. As for why it starts with 0x7f, that has not been specifically researched.

e_ident[EI_CLASS] is the byte following e_ident[EI_MAG3] and identifies the file's class or capacity.

The ELF file is designed to be portable among machines with different byte lengths, without imposing the maximum or minimum byte length of the machine. ELFCLASS32 supports machines with file sizes and virtual address spaces up to 4GB; it uses the basic types defined above.

ELFCLASS64 is used for 64-bit architectures.

The e_ident[EI_DATA] byte specifies the encoding of processor-specific data in the object file. The currently defined encodings are:

Other values are reserved and will be assigned to new encodings as necessary in the future.

The file data encoding indicates how the file contents should be parsed. As mentioned earlier, ELFCLASS32 files use variable types of 1, 2, and 4 bytes. For the different defined encodings, their representations are shown below, with the byte number in the upper-left corner.

ELFDATA2LSB encoding uses two's complement, with the Least Significant Byte occupying the lowest address.

ELFDATA2MSB encoding uses two's complement, with the Most Significant Byte occupying the lowest address.

e_ident[EI_DATA] specifies the version number of the ELF header. Currently, this value must be EV_CURRENT, which is the previously mentioned e_version.

e_ident[EI_PAD] specifies the starting address of unused bytes in e_ident. These bytes are reserved and set to 0; programs that process object files should ignore them. If these bytes are used in the future, the value of EI_PAD will change.

e_type¶

e_type identifies the object file type.

Although the content of core dump files is not specified in detail, ET_CORE is still reserved to mark such files. From ET_LOPROC to ET_HIPROC (inclusive) is reserved for processor-specific scenarios. Other values may be assigned to new object file types as necessary in the future.

e_machine¶

This field specifies the machine architecture on which the current file can run.

Here, EM should be an abbreviation for ELF Machine.

Other values are reserved for new machines as necessary in the future. Additionally, processor-specific ELF names use the machine name for differentiation, and flags generally have a prefix of EF_ (ELF Flag). For example, a flag called WIDGET on the EM_XYZ machine would be called EF_XYZ_WIDGET.

e_version¶

Identifies the version of the object file.

1 indicates the initial file format; future extensions will use larger numbers. Although the value of EV_CURRENT is 1 above, it may change to reflect the current version number — for example, ELF is still only at version 1.2 to this day.

e_entry¶

This field specifies the virtual address where the system transfers control to the corresponding code in the ELF file. If there is no associated entry point, this field is 0.

e_phoff¶

This field gives the byte offset of the Program Header Table from the beginning of the file (Program Header table OFFset). If the file has no program header table, this value is 0.

e_shoff¶

This field gives the byte offset of the Section Header Table from the beginning of the file (Section Header table OFFset). If the file has no section header table, this value is 0.

e_flags¶

This field gives processor-specific flags associated with the file. These flags are named in the format EF_machine_flag.

e_ehsize¶

This field gives the byte size of the ELF file header (ELF Header Size).

e_phentsize¶

This field gives the byte size of each entry in the program header table (Program Header ENTry SIZE). All entries are the same size.

e_phnum¶

This field gives the number of entries in the program header table (Program Header entry NUMber). Therefore, the product of e_phnum and e_phentsize gives the total byte size of the program header table. If the file has no program header table, this value is 0.

e_shentsize¶

This field gives the byte size of a section header (Section Header ENTry SIZE). A section header is one entry in the section header table; all entries in the section header table occupy the same amount of space.

e_shnum¶

This field gives the number of entries in the section header table (Section Header NUMber). Therefore, the product of e_shnum and e_shentsize gives the total byte size of the section header table. If the file has no section header table, this value is 0.

e_shstrndx¶

This field gives the index of the section header table entry associated with the section name string table (Section Header table InDeX related with section name STRing table). If the file has no section name string table, this value is SHN_UNDEF. For more details, please refer to the "Sections" and "String Table" sections later.

Program Header Table¶

Overview¶

The Program Header Table is an array of structures, where each element is of type Elf32_Phdr, describing a segment or other information the system needs when preparing the program for execution. In the ELF header, e_phentsize and e_phnum specify the size of each element and the number of elements in this array. A segment in an object file contains one or more sections. Program headers are only meaningful for executable files and shared object files.

In other words, the Program Header Table is specifically designed for the segments used during ELF file runtime.

The data structure of Elf32_Phdr is as follows:

typedef struct {
    ELF32_Word  p_type;
    ELF32_Off   p_offset;
    ELF32_Addr  p_vaddr;
    ELF32_Addr  p_paddr;
    ELF32_Word  p_filesz;
    ELF32_Word  p_memsz;
    ELF32_Word  p_flags;
    ELF32_Word  p_align;
} Elf32_Phdr;

The description of each field is as follows:

Segment Types¶

The segment types in an executable file are as follows:

Base Address¶

The virtual addresses in the program header may not be the actual virtual addresses in the program's memory image. Typically, executable programs contain code with absolute addresses. For the program to execute correctly, segments must reside at the corresponding virtual addresses. On the other hand, shared object files usually contain position-independent code. This allows shared object files to be loaded by multiple processes while maintaining correct program execution. Although the system selects different virtual addresses for different processes, it still preserves the relative addresses between segments, because position-independent code uses relative addresses between segments for addressing, and the differences between virtual addresses in memory must match the differences between virtual addresses in the file. The difference between the virtual address of any segment in memory and the corresponding virtual address in the file is a single constant value for any given executable or shared object. This difference is the base address, and one use of the base address is to relocate the program during dynamic linking.

The base address of an executable or shared object file is computed during execution from the following three values:

• The virtual memory load address
• The maximum page size
• The lowest virtual address of the program's loadable segments

To compute the base address, first determine the smallest virtual memory address among the loadable segments' p_vaddr values, then round down that memory virtual address to the nearest multiple of the maximum page size — this is the base address. Depending on the type of file being loaded into memory, the memory address may or may not be the same as p_vaddr.

Segment Permissions - p_flags¶

A program loaded into memory has at least one loadable segment. When the system creates the memory image for a loadable segment, it sets the segment permissions according to p_flags. The possible segment permission bits are:

Among these, all bits in PF_MASKPROC are reserved for processor-specific semantic information.

If a permission bit is set to 0, that type of segment is not accessible. The actual memory permissions depend on the corresponding memory management unit, and different systems may operate differently. Although all permission combinations are possible, the system generally grants more permissions than requested. In any case, unless explicitly stated otherwise, a segment will not have write permission. Below are all possible combinations.

For example, generally speaking, the .text segment usually has read and execute permissions, but not write permission. The data segment typically has write, read, and execute permissions.

Segment Contents¶

A segment may contain one or more sections, but this does not affect program loading. Nevertheless, we still need various data to enable program execution, dynamic linking, and so on. Below we describe the typical contents of segments. For different segments, the order of sections and the number of sections they contain may differ. Additionally, processor-related constraints may alter the structure of the corresponding segment.

As shown below, the code segment contains only read-only instructions and data. Of course, this example does not cover all possible segments.

The data segment contains writable data and instructions. Typically, it includes the following:

The PT_DYNAMIC type element in the program header points to the .dynamic section. The GOT (Global Offset Table) and PLT (Procedure Linkage Table) contain information related to position-independent code. Although in the example given here the PLT section appears in the code segment, this may vary for different processors.

The .bss section has the type SHT_NOBITS, which means it does not occupy space in the ELF file, but it does occupy space in the executable file's memory image. Typically, uninitialized data is at the end of the segment, which is why p_memsz is larger than p_filesz.

Note:

• Different segments may overlap, meaning different segments can contain the same sections.

Section Header Table¶

This data structure is actually located at the end of the ELF file (Why is it placed at the end of the file?), but for the convenience of explanation, we discuss this table here.

This structure is used to locate the specific position of each section in the ELF file.

First, the e_shoff field in the ELF header gives the byte offset from the beginning of the file to the section header table's location. e_shnum tells us the number of entries in the section header table; e_shentsize gives the byte size of each entry.

Second, the section header table is an array where each element is of type ELF32_Shdr, and each element describes an overview of a section.

ELF32_Shdr¶

Each section header can be described using the following data structure:

typedef struct {
    ELF32_Word      sh_name;
    ELF32_Word      sh_type;
    ELF32_Word      sh_flags;
    ELF32_Addr      sh_addr;
    ELF32_Off       sh_offset;
    ELF32_Word      sh_size;
    ELF32_Word      sh_link;
    ELF32_Word      sh_info;
    ELF32_Word      sh_addralign;
    ELF32_Word      sh_entsize;
} Elf32_Shdr;

The meaning of each field is as follows:

As mentioned earlier, the section header at index zero (SHN_UNDEF) also exists and marks undefined section references. The information for this entry is as follows:

Special Indices¶

Several special indices in the section header table are as follows:

The system reserves index values between SHN_LORESERVE and SHN_HIRESERVE (inclusive), and these values are not referenced in the section header table. That is, the section header table does not contain entries for reserved indices. This is not entirely clear.

Selected Section Header Fields¶

sh_type¶

Section types currently have the following possible range. SHT is an abbreviation for Section Header Table.

sh_flags¶

Each bit in the sh_flags field of a section header provides corresponding flag information, defining whether the content of the corresponding section can be modified, executed, and so on. If a flag bit is set, its value is 1; undefined bits are all 0. The currently defined values are as follows; other values are reserved.

sh_link & sh_info¶

When the section type differs, sh_link and sh_info will have different meanings.

Example¶

Here is a classic example of an ELF file.

When time permits, a better example will be provided with a concrete program.

References¶

• https://blogs.oracle.com/ali/gnu-hash-elf-sections
• https://bbs.pediy.com/thread-204642.htm