Menu
My preliminary knowledge is that:
.dynamic contains libraries that the executable needs to load.dynsym contains external symbols such as setsockopt@GLIBC_2.0
.dynstr contains strings of function requirementsOverall, I am a bit confused as to how these sections work together to create a binary - specifically .dynsym and .dynstr. So my question is two-fold. Are my statements above correct? If so, how do these three sections work together to create a binary?
428
An ELF file consists of zero or more segments, and describe how to create a process/memory image for runtime execution. When the kernel sees these segments, it uses them to map them into virtual address space, using the mmap(2) system call. In other words, it converts predefined instructions into a memory image.
Loading an ELF binary is handled by the load_elf_binary() function, which starts by examining the ELF header to check that the file in question does indeed look like a supported ELF format.
ELF files are used by two tools: the linker and the loader. A linker combines multiple ELF files into an executable or a library and a loader loads the executable ELF file in the memory of the process.
.interp. This section holds the path name of a program interpreter. If the file has a loadable segment that includes relocation, the sections' attributes will include the SHF_ALLOC bit; otherwise, that bit will be off.
Are my statements above correct?
The .dynsym section contains a set of fixed-length records of type Elf32_Sym or Elf64_Sym.
Since these are fixed length entries, they can not by themselves describe arbitrary length symbols (strings) that the binary exports or imports.
Therefore these entries don't contain the strings. Instead, they contain an offset into .dynstr (in the .st_name field), and the symbol name is found at this offset.
So it's not true that ".dynsym contains setsockopt@GLIBC_2.0" and that ".dynstr contains strings of function requirements" (whatever that last statement means).
The .dynsym contains an Elf32_Sym or an Elf64_sym describing an imported symbol setsockopt, and referencing the offset of "setsockopt" string in the .dynstr section.
Likewise, ".dynamic contains libraries that the executable needs to load" is false -- the section doesn't contain any libraries.
It contains fixed length entries of Elf64_Dyn or Elf32_Dyn, some of which (such as ones with .d_tag == DT_NEEDED or DT_RPATH) may reference strings from .dynstr via their offsets. The dynamic loader interprets these entries in certain way -- for DT_NEEDED as "must load this other library", for DT_RPATH as "must search these colon-separated paths", etc.
94
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
