Section header elf file

The switch -l short for —program-headers or —segments reveals more details as shown in Listing 4. The third part of the ELF structure is the section header. It is meant to list the single sections of the binary. The switch -S short for —section-headers or —sections lists the different headers.

As for the touch command, there are 27 section headers, and Listing 5 shows the first four of them plus the last one, only. Each line covers the section size, the section type as well as its address and memory offset. The first candidate we will have a look at is the file utility.

The second candidate is readelf. It displays detailed information about an ELF file. The list of switches is comparably long, and covers all the aspects of the ELF format. Using the switch -n short for —notes Listing 7 shows the note sections, only, that exist in the file touch — the ABI version tag, and the build ID bitstring. As of , there has not been a new release or update since Number three is the package named elfutils [6] that is purely available for Linux.

Last but not least we will mention objdump. This tool is similar to readelf but focuses on object files. It provides a similar range of information about ELF files and other object formats. This set of utilities provides a number of tools that help to validate ELF files. As an example, dumpelf analyzes the ELF file, and returns a C header file containing the details — see Figure 2. Use the elfdump command to inspect the components of an object or executable file generated by the assembler.

Sections do not need to be specified in any particular order. The current section is the section to which code is generated. These sections contain all other information in an object file and satisfy several conditions. Every section must have one section header describing the section. However, a section header does not need to be followed by a section. Each section occupies one contiguous sequence of bytes within a file. The section may be empty that is, of zero-length. An object file may have inactive space.

The contents of the data in the inactive space are unspecified. Sections can be added for multiple text or data segments, shared data, user-defined sections, or information in the object file for debugging. The section header allows you to locate all of the file sections. An entry in a section header table contains information characterizing the data in a section.

However, only the following fields are of immediate interest to the assembly language programmer because they can be specified in assembler pseudo-operations directives :. Description: One-bit descriptions of section attributes. Figure 6, Table 6, Section Attribute Flags describes the some of the section attribute flags.

For details and additional flags, see Section Headers in Oracle Solaris Description: Extra information. The interpretation of this information depends on the section type, as described in Figure 7, Table 7, Section Types Modified by Assembler Pseudo-ops. Description: Section header table index link. Description: Specifies the section name. An index into the section header string table section specifies the location of a null-terminated string.

A section that can be manipulated by the section control directives is known as a user section. You can use the section control directives to change the user section in which code or data is generated.

The following predefined user sections can be named in section control directives:. For details and additional information, see Special Sections in Oracle Solaris To create an. At link time, the. To understand these fields we have to go back to the concept of relocations. Whenever an elf file references a function from a shared library, it does not get filled up until it is called in the code, i. It says in the final binary patch the address of puts at offset 0xa. If we can disassemble this file, we can also see that at offset 0xa it is waiting for a 4-byte address to be filled in.

Examining the value at turns out to be next instruction i. Then the code makes a jump to PLT at which first pushed the value at probably dynamic linker and then call dynamic linker. Whenever an external library function is referenced, then on first call the stub will be called which in turn will call dynamic linker with the address of the called function.

The dynamic linker now knows that it has got the address of the function and must patch it up back in GOT. As we can see below now, the puts have to address to map to.

Packers were originally used to compress executables to increase disk space but these days packers are being used to obfuscate binaries. So once packer packs the file, it is the packer responsibility to decompress the binary in memory as would OS loader have done. It dons the role of OS loader at that point. To a binary it does not matter, and it gets decompressed and then being referenced in memory. So this means that all of our sections. As we can see above is that packer compresses the file on disk and loads it into memory.