C variables representation in ELF 2 - Relocations
Previously, we've explored program and section headers and typical sections in ELF.
In this post, I'll try to explore the symbols and their relocation according to the symbol table and the assembly.
elf#
C variables representation in ELF 1 - Sections
Previously, we've used gcc -S to stop assembling and gcc -c to stop linking, and explored C variables representation in assembly(gcc -S) and object(gcc -c).
The symbols in the intermediate object file (vars-section.o) are waiting to be relocated and resolved to determine their actual virtual address. It's the linker's turn.
After linking, all object files (*.o) are linked into one ELF. By default, it links dynamically and the type of outcome is DYN (position-independent executable file).
C variables representation in object(gcc -c)
Compared to gcc -S, gcc -c will assemble and stop linking, and generate intermediate object file, see REL ELF Walkthrough.
Object files (usually ended with .o) contain machine instructions that are in principle executable by the processor.
Then we can use objdump to display information from object files and explore what's in them.
VMA & LMA
Every loadable or allocatable output section has two addresses. The first is the VMA, or virtual memory address. This is the address the section will have when the output file is run. The second is the LMA, or load memory address. This is the address at which the section will be loaded.
In most cases, the two addresses will be the same, because wherever the program is loaded into memory, that is where it will be executed. So what's the actual difference between the VMA and the LMA? Under what circumstances does VMA != LMA?
reloc puts@plt via GOT - r2 debug
Previously, we've dynamically analysed how shared dynamic symbols such as puts are resolved and relocated at runtime using gdb-pwndbg.
On this post, we'll do much the same work, but change our dynamic analysis tool to the popular open-source SRE toolkit r2(aka radare2).
It is also a thorough and comprehensive debugging exercise, demonstrating the power and versatility of the r2 toolset.
reloc puts@plt via GOT - pwndbg
Previously we've statically analysed the layout and ingredients of the DYN PIE ELF a.out. In particular, we've focused on dynamic sections/symbols and relocation entries.
In this article, we'll do some dynamic analysis, taking a closer look at how shared dynamic symbols such as puts are resolved and relocated at runtime.
It is also a thorough and comprehensive pwndbg debugging exercise, showcasing the use of the advanced features of GDB.
puts@plt/rela/got - static analysis
So far we've been through the default gcc compilation process and had a look at the product of our C demo program a.out with GNU binutils.
It links dynamically by default, a dynamic linker (aka interpreter) is used to resolve the final dependencies on dynamic libraries when the executable is loaded into memory to run.
Previously, we've gone through the basic concepts of static linking and dynamic linking. In this article I'll have a look at how the shared dynamic symbol such as puts is designated at link time in the DYN PIE ELF.
Dynamic Linking and Relocations
In this article I'll explore the basic concepts associated with dynamic linking - PIC, dynamic relocation, GOT and PLT.
Symbol resolution & relocation
In this article I'll explore the basic concepts associated with static linking - symbol resolution and relocation.
REL ELF Walkthrough
Previously we've compiled our C demo program with gcc -c command.
gcc -c compile or assemble the source files, but do not link. The linking stage simply is not done. The ultimate output is in the form of an object file for each source file.
In this article, I'll practice using GNU binutils to take a close look at the 0701.o product.