{"id":258,"date":"2025-11-22T12:37:26","date_gmt":"2025-11-22T12:37:26","guid":{"rendered":"https:\/\/haco.club\/?p=258"},"modified":"2025-11-22T12:37:26","modified_gmt":"2025-11-22T12:37:26","slug":"pie-relocation-tagging-addresses","status":"publish","type":"post","link":"https:\/\/haco.club\/?p=258","title":{"rendered":"PIE Relocation: Tagging Addresses"},"content":{"rendered":"\n

In a Position-Independent Executable (PIE), absolute addresses aren’t “tagged” directly within the machine code. Instead, the linker creates a separate list of instructions and data locations that need fixing<\/strong>, and this list is stored in a special section of the binary called the relocation table<\/strong>.<\/p>\n\n\n\n

The dynamic loader uses this table at runtime to patch the code with the correct memory addresses once the binary’s actual location in memory is known.<\/p>\n\n\n\n

\n\n\n\n

The Core Mechanism: Linker and Loader Teamwork \ud83e\udd1d<\/h2>\n\n\n\n

Think of it like moving into a new apartment building. You pack your belongings into boxes, but instead of labeling them with the final apartment number (which you don’t know yet), you label them with instructions like “Put this in the kitchen” or “Put this 3 meters from the front door.”<\/p>\n\n\n\n

    \n
  1. The Linker (The Packer):<\/strong>\u00a0When compiling with flags like\u00a0-fPIE<\/code>\u00a0and\u00a0-pie<\/code>, the linker generates position-independent code.\u00a0For any reference to an absolute address, it doesn’t write the final address. Instead, it often writes a placeholder (like 0 or an offset) and creates an entry in the relocation table (.rela.dyn<\/code>\u00a0section). This entry is the “tag” or “label” that says: “Hey, the 8-byte value at\u00a0this specific offset<\/em>\u00a0in the file needs to be updated at runtime.”<\/li>\n\n\n\n
  2. The Dynamic Loader (The Mover):<\/strong>\u00a0When you run the program, the OS kernel loads the dynamic loader (ld-linux.so.2<\/code>\u00a0on Linux) and the PIE binary into memory at some random address. This random starting point is called the\u00a0base address<\/strong>. The dynamic loader then reads the relocation table. For each entry, it performs a simple calculation and writes the result back into the memory of the program, effectively “patching” it live.<\/li>\n<\/ol>\n\n\n\n
    \n\n\n\n

    How the “Tagging” Works: The Relocation Table<\/h2>\n\n\n\n

    Each entry in the relocation table contains three key pieces of information, effectively “tagging” a location for a fix-up.<\/p>\n\n\n\n

      \n
    • r_offset<\/code><\/strong>: The location that needs to be patched. This is the virtual address (relative to the start of the binary) of the pointer or instruction operand that holds the placeholder.<\/li>\n\n\n\n
    • r_info<\/code><\/strong>: The type of relocation. For internal PIE addresses, the most common type on 64-bit systems is\u00a0$R_X86_64_RELATIVE$<\/code>. This tells the loader\u00a0how<\/em>\u00a0to do the calculation.<\/li>\n\n\n\n
    • r_addend<\/code><\/strong>: An initial value to add. For a pointer to a location within the binary, this is the offset of the target from the beginning of the binary.<\/li>\n<\/ul>\n\n\n\n

      The formula the dynamic loader uses for an $R_X86_64_RELATIVE$<\/code> relocation is simple:<\/p>\n\n\n\n

      Final Address=Base Address+Addend<\/p>\n\n\n\n

      The loader calculates this value and writes it to the memory location specified by r_offset<\/code>.<\/p>\n\n\n\n

      \n\n\n\n

      A Concrete Example<\/h2>\n\n\n\n

      Let’s look at a simple C program compiled as a PIE.<\/p>\n\n\n\n

      \/\/ file: mypie.c\nint my_global_var = 42;\nint *my_ptr = &my_global_var; \/\/ This requires an absolute address<\/code><\/pre>\n\n\n\n
      Compile it as a PIE: gcc -fPIE -pie -o mypie mypie.c<\/code><\/p>\n\n\n\n
      1\u3001The Code and Placeholder:<\/strong>\u00a0If we inspect the compiled binary’s data section with\u00a0objdump -s -j .data mypie<\/code>, we’ll see where\u00a0$my_ptr$<\/code>\u00a0is stored. The linker places a placeholder value there\u2014specifically, the offset of\u00a0$my_global_var$<\/code>.<\/p>\n\n\n\n
      2\u3001The Relocation “Tag”:<\/strong>\u00a0If we inspect the relocation table with\u00a0readelf -r mypie<\/code>, we’ll find an entry that looks something like this:<\/p>\n\n\n\n
        <\/ol>\n\n\n\n
        Offset             Info             Type               Addend\n0000000000004038   000000000008     R_X86_64_RELATIVE  0000000000004034<\/code><\/pre>\n\n\n\n
        3\u3001This entry is the “tag” for our pointer. It tells the dynamic loader:<\/p>\n\n\n\n
          \n
        • Location (Offset<\/code>):<\/strong>\u00a0Go to address\u00a0$0x4038$<\/code>\u00a0within the binary. This is the location of our\u00a0$my_ptr$<\/code>.<\/li>\n\n\n\n
        • How (Type<\/code>):<\/strong>\u00a0Perform a\u00a0$R_X86_64_RELATIVE$<\/code>\u00a0relocation.<\/li>\n\n\n\n
        • What (Addend<\/code>):<\/strong>\u00a0The value to use in the calculation is\u00a0$0x4034$<\/code>. This is the offset of\u00a0$my_global_var$<\/code>\u00a0inside the binary.<\/li>\n<\/ul>\n\n\n\n
          4\u3001The Runtime Fix-up:<\/strong>\u00a0Let’s say the OS loads our binary at the base address\u00a00x555555554000<\/code><\/strong>.<\/p>\n\n\n\n
            \n
          • The dynamic loader reads the relocation entry.<\/li>\n\n\n\n
          • It calculates:\u00a0Base Address + Addend<\/code>\u00a0=>\u00a0$0x555555554000 + 0x4034 = 0x555555558034$<\/code>.<\/li>\n\n\n\n
          • This result,\u00a0$0x555555558034$<\/code>, is the final, correct memory address of\u00a0$my_global_var$<\/code>.<\/li>\n\n\n\n
          • The loader then writes this final address into the location of\u00a0$my_ptr$<\/code>, which is at\u00a0Base Address + Offset<\/code>\u00a0=>\u00a0$0x555555554000 + 0x4038 = 0x555555558038$<\/code>.<\/li>\n<\/ul>\n\n\n\n
              <\/ol>\n\n\n\n
              After this process, $my_ptr$<\/code> holds the correct runtime address, and the program can execute correctly from any base address.<\/sup><\/p>\n\n\n\n
              \n\n\n\n
              \u201cRelocation section '.rela.dyn' at offset 0x730 contains 12 entries:\n\n  Offset          Info           Type           Sym. Value    Sym. Name + Addend\n\n00000001fd38  000000000403 R_AARCH64_RELATIV                    b20\n\n00000001fd40  000000000403 R_AARCH64_RELATIV                    acc\n\n00000001ffc0  000000000403 R_AARCH64_RELATIV                    b28\n\n000000020008  000000000403 R_AARCH64_RELATIV                    20008\n\n00000001ffb8  000400000401 R_AARCH64_GLOB_DA 0000000000000000 __stack_chk_guard@GLIBC_2.17 + 0\n\n00000001ffc8  000500000401 R_AARCH64_GLOB_DA 0000000000000000 _ZSt4endlIcSt11ch[...]@GLIBCXX_3.4 + 0\n\n00000001ffd0  000600000401 R_AARCH64_GLOB_DA 0000000000000000 __cxa_finalize@GLIBC_2.17 + 0\n\n00000001ffd8  000b00000401 R_AARCH64_GLOB_DA 0000000000000000 _ZSt4cout@GLIBCXX_3.4 + 0\n\n00000001ffe0  000e00000401 R_AARCH64_GLOB_DA 0000000000000000 _ITM_deregisterTM[...] + 0\n\n00000001ffe8  000f00000401 R_AARCH64_GLOB_DA 0000000000000000 _ZSt3cin@GLIBCXX_3.4 + 0\n\n00000001fff0  001000000401 R_AARCH64_GLOB_DA 0000000000000000 __gmon_start__ + 0\n\n00000001fff8  001100000401 R_AARCH64_GLOB_DA 0000000000000000 _ITM_registerTMCl[...] + 0\n\n\n\nRelocation section '.rela.plt' at offset 0x850 contains 8 entries:\n\n  Offset          Info           Type           Sym. Value    Sym. Name + Addend\n\n00000001ff70  000300000402 R_AARCH64_JUMP_SL 0000000000000000 __stack_chk_fail@GLIBC_2.17 + 0\n\n00000001ff78  000600000402 R_AARCH64_JUMP_SL 0000000000000000 __cxa_finalize@GLIBC_2.17 + 0\n\n00000001ff80  000700000402 R_AARCH64_JUMP_SL 0000000000000000 _ZNSirsERi@GLIBCXX_3.4 + 0\n\n00000001ff88  000800000402 R_AARCH64_JUMP_SL 0000000000000000 __libc_start_main@GLIBC_2.34 + 0\n\n00000001ff90  000900000402 R_AARCH64_JUMP_SL 0000000000000000 _ZStlsISt11char_t[...]@GLIBCXX_3.4 + 0\n\n00000001ff98  000a00000402 R_AARCH64_JUMP_SL 0000000000000000 _ZNSolsEPFRSoS_E@GLIBCXX_3.4 + 0\n\n00000001ffa0  000d00000402 R_AARCH64_JUMP_SL 0000000000000000 abort@GLIBC_2.17 + 0\n\n00000001ffa8  001000000402 R_AARCH64_JUMP_SL 0000000000000000 __gmon_start__ + 0\u201d<\/code><\/pre>\n\n\n\n
              This output is a “to-do list” \ud83d\udcdd for your system’s dynamic loader<\/strong> (ld-linux.so<\/code>). It’s from a tool like readelf<\/code> and shows the instructions the loader needs to follow to make a program runnable in memory. This is essential for modern security features like Address Space Layout Randomization (ASLR) and for using shared libraries.<\/p>\n\n\n\n
              The list is split into two main parts: .rela.dyn<\/code> and .rela.plt<\/code>.<\/p>\n\n\n\n
              \n\n\n\n
              1. .rela.dyn<\/code> (Dynamic Relocations)<\/h3>\n\n\n\n
              This section handles fix-ups for data pointers and internal addresses<\/strong>. Think of it as making sure all the program’s variables and internal references point to the right place once the program is loaded at a random memory address.<\/p>\n\n\n\n
              You see two main types here:<\/p>\n\n\n\n
                \n
              • R_AARCH64_RELATIVE<\/code><\/strong>: This is for\u00a0internal pointers<\/strong>. These entries tell the loader to calculate an address relative to where the program was loaded.\n
                  \n
                • What it means:<\/strong>\u00a0The\u00a0Addend<\/code>\u00a0column (e.g.,\u00a0b20<\/code>,\u00a0acc<\/code>) is an offset from the start of the program file. The loader takes the program’s\u00a0base address<\/strong>\u00a0in memory and adds this offset to get the final, correct memory address. It then writes this final address at the location specified in the\u00a0Offset<\/code>\u00a0column.<\/li>\n\n\n\n
                • Example:<\/strong>\u00a0The first line tells the loader: “Calculate\u00a0Base Address + 0xb20<\/code>\u00a0and write that result into the memory at\u00a0Base Address + 0x1fd38<\/code>.”<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                • R_AARCH64_GLOB_DAT<\/code><\/strong>: This is for\u00a0global variables<\/strong>\u00a0from shared libraries (like GLIBC and libstdc++).\n
                    \n
                  • What it means:<\/strong>\u00a0This tells the loader to find the address of a variable in a shared library and patch it into your program’s memory.<\/li>\n\n\n\n
                  • Example:<\/strong>\u00a0The entry for\u00a0_ZSt4cout<\/code>\u00a0tells the loader: “Find the memory address of the standard output stream (std::cout<\/code>) in the C++ library, and write that address into my program’s memory at\u00a0Base Address + 0x1ffd8<\/code>.” This allows your program to use\u00a0std::cout<\/code>\u00a0correctly.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
                    \n\n\n\n
                    2. .rela.plt<\/code> (Procedure Linkage Table Relocations)<\/h3>\n\n\n\n
                    This section is all about setting up function calls<\/strong> to shared libraries. It enables a clever optimization called lazy binding<\/strong>. Instead of finding the address of every single library function at startup (which is slow), the loader sets up a system to find the address the very first time<\/em> a function is called.<\/p>\n\n\n\n
                    This involves two key components: the Procedure Linkage Table (PLT) and the Global Offset Table (GOT).<\/p>\n\n\n\n
                      \n
                    • R_AARCH64_JUMP_SLOT<\/code><\/strong>: This relocation type is specifically for these function calls.\n
                        \n
                      • What it means:<\/strong>\u00a0The\u00a0Offset<\/code>\u00a0points to an entry in the Global Offset Table (GOT). Initially, this entry points to a helper routine in the PLT. When your code calls a function like\u00a0abort<\/code>\u00a0for the first time, it actually jumps to that helper routine. The helper routine then calls the dynamic loader, which looks up the real address of\u00a0abort<\/code>. The loader then “patches” the real address into the GOT entry (at the specified\u00a0Offset<\/code>).<\/li>\n\n\n\n
                      • The Payoff:<\/strong>\u00a0The\u00a0next<\/em>\u00a0time your code calls\u00a0abort<\/code>, it goes directly to the real function, skipping the loader entirely.<\/li>\n\n\n\n
                      • Example:<\/strong>\u00a0The entry for\u00a0abort@GLIBC_2.17<\/code>\u00a0tells the loader: “Be prepared to find the real address of the\u00a0abort<\/code>\u00a0function. The program has a slot for it at\u00a0Base Address + 0x1ffa0<\/code>.”<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
                        \n\n\n\n
                        Summary<\/h3>\n\n\n\n
                        Section<\/td>What It’s For<\/td>Analogy<\/td><\/tr><\/thead>
                        .rela.dyn<\/code><\/strong><\/td>Fixing addresses of variables<\/strong> (\u043f\u0435\u0440\u0435\u043c\u0435\u043d\u043d\u044b\u0435) and other data, both internal and external.<\/td>Writing down the final addresses on a building’s directory board.<\/td><\/tr>
                        .rela.plt<\/code><\/strong><\/td>Setting up the mechanism for calling functions<\/strong> (funzioni) from shared libraries.<\/td>Creating a speed-dial entry that looks up the number the first time you call.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                        <\/p>\n","protected":false},"excerpt":{"rendered":"
                        In a Position-Independent Executable (PIE), absolute addresses aren’t “tagged” directly […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[42],"tags":[30],"class_list":["post-258","post","type-post","status-publish","format-standard","hentry","category-knowledge-base","tag-binary"],"_links":{"self":[{"href":"https:\/\/haco.club\/index.php?rest_route=\/wp\/v2\/posts\/258","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/haco.club\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/haco.club\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/haco.club\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/haco.club\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=258"}],"version-history":[{"count":1,"href":"https:\/\/haco.club\/index.php?rest_route=\/wp\/v2\/posts\/258\/revisions"}],"predecessor-version":[{"id":259,"href":"https:\/\/haco.club\/index.php?rest_route=\/wp\/v2\/posts\/258\/revisions\/259"}],"wp:attachment":[{"href":"https:\/\/haco.club\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=258"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/haco.club\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=258"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/haco.club\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=258"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}