Linux ELF Header Basics for Incident Responders

Despite some strange ideas on social media platforms, and despite the fact that Linux-based operating systems really can be great, there is no escaping the fact that we still have to deal with malware and intrusions on every platform. There is no such thing as a "secure OS." At some point, Incident Response is going to be needed.

One thing that can slow down IR, is dealing with unfamiliar file structures. Most IR professionals understand MS Windows PE headers and tend to be pretty good at getting information out of them. With the ELF format used by Linux executables, it isn't so simple.

This article is a quick look at the basic structures that make up an ELF file header, so you can understand the structure a bit more. It isn't a replacement for learning to reverse engineer malware!

ELF Structure

An ELF file contains the following components:

ELF Header:

• Located at the start of the file.
• Contains metadata about the file, including architecture, entry point, and offsets to other parts of the file.

Program Header Table (Optional for object files):

• Describes segments of the file to be loaded into memory.
• Used by the loader to map the file into a process's memory space.

Section Header Table (Optional for executables):

• Describes sections in the file, such as .text, .data, .bss, and .symtab.
• Used by linkers and debugging tools but typically not required for execution.

Sections:

• Contain specific types of data, like executable code, initialized data, uninitialized data, or debugging information.

Segments:

• Represent contiguous regions of memory and are described in the Program Header Table.
• Includes regions like text (code), data (initialized variables), and bss (uninitialized variables).

This article will focus on the ELF Header, which is the first structure.

Generally, the execution flow, for a Linux executable, goes something like:

• ELF Header: Provides metadata to locate the Program Header Table and entry point.
• Program Header Table: Guides the loader on how to map the file into memory.
• Sections: Contain the actual code, data, and linking/debugging information.

ELF Header

This table shows the structure of the ELF header. This is 64 bytes for a 64-bit file and 52 bytes for a 32-bit ELF file. The extra size accounts for the increased size of some fields which deal with the increased 64-bit address space.

Worked Example

This is an ELF header for a 64-bit Linux executable (actually bash) viewed in a hex editor.

Now it is true that, most of the time, you will use tools to parse the structures, it is useful to understand them and to be able to recognise elements. In DFIR engagements you might encounter fragments of an ELF file (especially if a threat actor has tried to delete it), or be faced with environments where your usual tooling is unavailable.

So, let's dig in.

Line 1 - Bytes 0 - 15

• e_ident. This is the 16-byte field starting at offset 0. This is broken down into sub-fields.

The sub-fields are:

1. Magic Bytes - 4 bytes. The string 0x7f454c46, or .ELF in ASCII, confirm this is a Linux ELF format file.
2. Architecture - 1 byte. This specifies the type of file. A 0x01 is a 32-bit file. This file uses 0x02, indicating it is a 64-bit file.
3. Endianness - 1 byte. Here the 0x01 indicates this is a little-endian file. A 0x02 indicates big-endian.
4. ELF Version - 1 byte. This is a 01 indicating ELF version 1, which is the current standard.
5. OS Target - 1 byte. The 8th byte specifies the target operating system (or ABI - Application Binary Interface). This file has 0x00, which is the default and indicates no specific ABI extensions are required. Other values include 0x02 for NetBSD, 0x07 for AIX and 0x09 for FreeBSD.
6. ABI Version - 1 byte. The 9th byte relates to any specific factors relating to the ABI selected in the 8th byte. Here it is 0x00, but this is normal because no ABI was selected.
7. Padding - 7 bytes. This is currently unused space and should be set to 0x00. It is available for use in future versions of the ELF standard.

Line 2 - Bytes 16 - 31

In a 64-bit file, there are four objects on this line.

• e_type - 2 bytes. This indicates the object file type. A 0x0 is no file type, 0x1 is relocatable, 0x2 is executable, 0x3 is a shared object and 0x4 is a core file. Note, remember to check the endianess. In the example here, this field reads 0x0200, which is little endian for 0x2.
• e_machine - 2 bytes. The data here shows the required architecture. This allows ELF files to work on a range of Unix/Linux platforms, which, in turn, means there are a lot of options. The most common value on Linux today is probably 0x3E (62 decimal) which means AMD x86-64 architectures. Other examples include 0x3 for Intel 80386; 0x15 (21 decimal) for 64-bit Power PC; and 0x32 (50 decimal) for Intel IA-64 processor architectures. The bash example we have here has 0x3e00 in this field, which indicates AMD x86-64 architecture.
• e_version - 4 bytes. The only, currently, valid string here is 0x1. This is the ELF file format version.
• e_entry - 8 bytes. This field stores the virtual memory address for the program's entry point. This is where the program would begin execution, and the example here is 0x41F010.

Line 3 - Bytes 32 - 47

There are two objects here in a 64-bit ELF file.

• e_phoff - 8 bytes. This identifies where the program header table starts inside the file. In the example here (little-endian) it would be 0x40, or 64 bytes into the file, and immediately after the ELF header.
• e_shoff - 8 byes. This identifies where the section header table starts, showing the locations of sections such as .text, .data, .bss etc. In the example here, it is 0xE1C48, or decimal. If you go to this location in the file, you will find the start of the section header table, which is always a 64-byte NULL field, followed by the individual sections.

Line 4 - Bytes 48-63

This is 7 fields in a 64-bit ELF.

• e_flags - 4 bytes. This is unused in x86-64 and would normally be 0x00s.
• e_ehsize - 2 bytes. This shows the ELF header size. The example here is 0x0040, which indicates a 64-byte header.
• e_phentsize - 2 bytes. Size of the program header entry. In the example we are using it is 0x0038, or 56 bytes.
• e_phnum - 2 bytes. This shows the number of program header entries. Here we have 0x0008, or 8 entries.
• e_shentsize - 2 bytes. This reports the size of each section header entry. Our example is 0x0040, or 64-byte section headers.
• e_shnum - 2 bytes. This field reports the number of section headers. 0x001C indicates that there are 28 entries in the bash file.
• e_shstrndx - 2 bytes. The index of the section header string table. In our example, this is 0x001B or 27.

Using tools

Although it is important that digital forensic investigators understand how to get this data from the raw files (otherwise how do we know when our tools are mistaken), this information is available through a variety of tooling.

The most basic is the file command.

file filename        

We can also use exiftool, although this is not installed by default on most Linux distros.

exiftool filename        

Another good tool for analysing Linux executables is the readelf command.

readelf -h filename # reads the ELF header
readelf -l filename # reads the program header table
readelf -S filename # shows the section header table        

Using the -h switch gives a full, interpreted, output from the header.

You can directly review the section headers with the -S argument. This should match the data we identified in the raw hex.

Summary

It is important for DIFR investigators/responders to understand the structure of an ELF file. A good place to start is the header as this contains details about how the rest of the file would be structured and tells us where to look to find things like the .bss, .data or .text sections.

Most of the time we can use our tools to recover this information, but it definitely helps if you understand how to validate your tools and how to recover data from damaged files.