Non-POSIX only here.
An ELF file contains the following parts:
- ELF header. Points to the position of the section header table and the program header table.
- Section header table (optional on executable). Each has
e_shnumsection headers, each pointing to the position of a section. - N sections, with
N <= e_shnum(optional on executable) - Program header table (only on executable). Each has
e_phnumprogram headers, each pointing to the position of a segment. - N segments, with
N <= e_phnum(only on executable)
The order of those parts is not fixed: the only fixed thing is the ELF header that must be the first thing on the file: Generic docs say:
In pictures: sample object file with three sections:
+-------------------+
| ELF header |---+
+---------> +-------------------+ | e_shoff
| | |<--+
| Section | Section header 0 |
| | |---+ sh_offset
| Header +-------------------+ |
| | Section header 1 |---|--+ sh_offset
| Table +-------------------+ | |
| | Section header 2 |---|--|--+
+---------> +-------------------+ | | |
| Section 0 |<--+ | |
+-------------------+ | | sh_offset
| Section 1 |<-----+ |
+-------------------+ |
| Section 2 |<--------+
+-------------------+But nothing (except sanity) prevents the following topology:
+-------------------+
| ELF header |---+ e_shoff
+-------------------+ |
| Section 1 |<--|--+
+---------> +-------------------+ | |
| | |<--+ | sh_offset
| Section | Section header 0 | |
| | |------|---------+
| Header +-------------------+ | |
| | Section header 1 |------+ |
| Table +-------------------+ |
| | Section header 2 |---+ | sh_offset
+---------> +-------------------+ | sh_offset |
| Section 2 |<--+ |
+-------------------+ |
| Section 0 |<---------------+
+-------------------+But some newbies may prefer PNGs :-)
Running:outputs:
readelf -h hello_world.oMagic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: REL (Relocatable file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x0
Start of program headers: 0 (bytes into file)
Start of section headers: 64 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 0 (bytes)
Number of program headers: 0
Size of section headers: 64 (bytes)
Number of section headers: 7
Section header string table index: 3Running:outputs:
readelf -h hello_world.outMagic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x4000b0
Start of program headers: 64 (bytes into file)
Start of section headers: 272 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 2
Size of section headers: 64 (bytes)
Number of section headers: 6
Section header string table index: 3Bytes in the object file:
00000000 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 |.ELF............|
00000010 01 00 3e 00 01 00 00 00 00 00 00 00 00 00 00 00 |..>.............|
00000020 00 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 |........@.......|
00000030 00 00 00 00 40 00 00 00 00 00 40 00 07 00 03 00 |....@.....@.....|Executable:
00000000 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 |.ELF............|
00000010 02 00 3e 00 01 00 00 00 b0 00 40 00 00 00 00 00 |..>.......@.....|
00000020 40 00 00 00 00 00 00 00 10 01 00 00 00 00 00 00 |@...............|
00000030 00 00 00 00 40 00 38 00 02 00 40 00 06 00 03 00 |....@.8...@.....|Structure represented:
# define EI_NIDENT 16
typedef struct {
unsigned char e_ident[EI_NIDENT];
Elf64_Half e_type;
Elf64_Half e_machine;
Elf64_Word e_version;
Elf64_Addr e_entry;
Elf64_Off e_phoff;
Elf64_Off e_shoff;
Elf64_Word e_flags;
Elf64_Half e_ehsize;
Elf64_Half e_phentsize;
Elf64_Half e_phnum;
Elf64_Half e_shentsize;
Elf64_Half e_shnum;
Elf64_Half e_shstrndx;
} Elf64_Ehdr;Manual breakdown:
- 0 0:
EI_MAG=7f 45 4c 46=0x7f 'E', 'L', 'F': ELF magic number - 0 4:
EI_CLASS=02=ELFCLASS64: 64 bit elf - 0 5:
EI_DATA=01=ELFDATA2LSB: little endian data - 0 6:
EI_VERSION=01: format version - 0 7:
EI_OSABI(only in 2003 Update) =00=ELFOSABI_NONE: no extensions. - 0 8:
EI_PAD= 8x00: reserved bytes. Must be set to 0. - On the executable it is
02 00forET_EXEC.Another important possibility for the executable isET_DYNfor PIE executables and shared libraries.ET_DYNtells the Linux kernel that the code is position independent, and can loaded at a random memory location with ASLR. - 1 2:
e_machine=3e 00=62=EM_X86_64: AMD64 architecture - 1 4:
e_version=01 00 00 00: must be 1 - 1 8:
e_entry= 8x00: execution address entry point, or 0 if not applicable like for the object file since there is no entry point.On the executable, it isb0 00 40 00 00 00 00 00. The kernel puts the RIP directly on that value when executing. It can be configured by the linker script or-e. But it will segfault if you set it too low: stackoverflow.com/questions/2187484/why-is-the-elf-execution-entry-point-virtual-address-of-the-form-0x80xxxxx-and-n 40 00 00 00on the executable, i.e. it starts immediately after the ELF header.- 2 8:
e_shoff=407x00=0x40: section header table file offset, 0 if not present. The Intel386 architecture defines no flags; so this member contains zero.
- 3 4:
e_ehsize=40 00: size of this elf header. TODO why this field needed? Isn't the size fixed? 38 00on executable: it is 56 bytes long02 00on executable: there are 2 entries.- 3 A:
e_shentsizeande_shnum=40 00 07 00: section header size and number of entries - 3 E:
e_shstrndx(Section Header STRing iNDeX) =03 00: index of the.shstrtabsection.
Now that we've done one section manually, let's graduate and use the
readelf -S of the other sections: [Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 2] .text PROGBITS 0000000000000000 00000210
0000000000000027 0000000000000000 AX 0 0 16.text is executable but not writable: if we try to write to it Linux segfaults. Let's see if we really have some code there:objdump -d hello_world.ohello_world.o: file format elf64-x86-64
Disassembly of section .text:
0000000000000000 <_start>:
0: b8 01 00 00 00 mov $0x1,%eax
5: bf 01 00 00 00 mov $0x1,%edi
a: 48 be 00 00 00 00 00 movabs $0x0,%rsi
11: 00 00 00
14: ba 0d 00 00 00 mov $0xd,%edx
19: 0f 05 syscall
1b: b8 3c 00 00 00 mov $0x3c,%eax
20: bf 00 00 00 00 mov $0x0,%edi
25: 0f 05 syscallIf we grep
b8 01 00 00 on the hd, we see that this only occurs at 00000210, which is what the section says. And the Size is 27, which matches as well. So we must be talking about the right section.The most interesting part is line to pass the address of the string to the system call. Currently, the This modification is possible because of the data of the
a which does:movabs $0x0,%rsi0x0 is just a placeholder. After linking happens, it will be modified to contain:4000ba: 48 be d8 00 60 00 00 movabs $0x6000d8,%rsi.rela.text section.Contains a lot of different flag masks.
Died of cancer at age 53. Ciro Santilli just can't help but speculate that it is linked to radioactivity exposure.
Pinned article: Introduction to the OurBigBook Project
Welcome to the OurBigBook Project! Our goal is to create the perfect publishing platform for STEM subjects, and get university-level students to write the best free STEM tutorials ever.
Everyone is welcome to create an account and play with the site: ourbigbook.com/go/register. We belive that students themselves can write amazing tutorials, but teachers are welcome too. You can write about anything you want, it doesn't have to be STEM or even educational. Silly test content is very welcome and you won't be penalized in any way. Just keep it legal!
Intro to OurBigBook
. Source. We have two killer features:
- topics: topics group articles by different users with the same title, e.g. here is the topic for the "Fundamental Theorem of Calculus" ourbigbook.com/go/topic/fundamental-theorem-of-calculusArticles of different users are sorted by upvote within each article page. This feature is a bit like:
- a Wikipedia where each user can have their own version of each article
- a Q&A website like Stack Overflow, where multiple people can give their views on a given topic, and the best ones are sorted by upvote. Except you don't need to wait for someone to ask first, and any topic goes, no matter how narrow or broad
This feature makes it possible for readers to find better explanations of any topic created by other writers. And it allows writers to create an explanation in a place that readers might actually find it.
Figure 1. Screenshot of the "Derivative" topic page. View it live at: ourbigbook.com/go/topic/derivativeVideo 2. OurBigBook Web topics demo. Source. - local editing: you can store all your personal knowledge base content locally in a plaintext markup format that can be edited locally and published either:This way you can be sure that even if OurBigBook.com were to go down one day (which we have no plans to do as it is quite cheap to host!), your content will still be perfectly readable as a static site.
- to OurBigBook.com to get awesome multi-user features like topics and likes
- as HTML files to a static website, which you can host yourself for free on many external providers like GitHub Pages, and remain in full control
Figure 3. Visual Studio Code extension installation.
Figure 4. Visual Studio Code extension tree navigation.
Figure 5. Web editor. You can also edit articles on the Web editor without installing anything locally.Video 3. Edit locally and publish demo. Source. This shows editing OurBigBook Markup and publishing it using the Visual Studio Code extension.Video 4. OurBigBook Visual Studio Code extension editing and navigation demo. Source. 
- Infinitely deep tables of contents:
All our software is open source and hosted at: github.com/ourbigbook/ourbigbook
Further documentation can be found at: docs.ourbigbook.com
Feel free to reach our to us for any help or suggestions: docs.ourbigbook.com/#contact