{"componentChunkName":"component---src-templates-post-template-js","path":"/linux-got-plt-en","result":{"data":{"markdownRemark":{"id":"ebfbf40f-f071-55ab-8803-3899a86d1338","html":"
\n

This page has been machine-translated from the original page.

\n
\n

This article explores the overview of GOT and PLT along with practical verification.

\n

The motivation for writing this article was that I became confused about GOT while researching Position Independent Code (PIC).

\n\n

Table of Contents

\n\n

Shared Libraries and Dynamic Linking

\n

Most ELF binaries have library functions (predefined, frequently used convenient functions) linked via dynamic linking.

\n

Dynamic linking is a mechanism that links the actual body of library functions and other elements required for program execution at runtime.

\n

The counterpart to dynamic linking is static linking, where all necessary library functions and other components are linked into a single program beforehand.

\n

By using dynamic linking for functions and modules commonly used by multiple programs, such as library functions, there are benefits such as reducing the file size of programs and improving memory usage efficiency at runtime.

\n

You can check which shared libraries an ELF binary depends on using the ldd command.

\n
$ ldd test.o\nlinux-vdso.so.1 (0x00007ffdb417f000)\nlibc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f02af5ca000)\n/lib64/ld-linux-x86-64.so.2 (0x00007f02af7d7000)
\n

Reference: Man page of LDD

\n

This article summarizes the mechanism for linking dynamically linked shared libraries at program runtime.

\n

Flow of Shared Library Function Calls

\n

When executing an ELF binary with dynamically linked library functions, the library functions are not bound until they are actually called during processing.

\n

This mechanism is called lazy binding and is supported by the PLT (Procedure Linkage Table).

\n

When a shared library function is called during program execution, the initially called address is not the actual shared library function, but an entry in the .plt section.

\n

The invoked PLT entry then jumps to an area called the GOT (Global Offset Table).

\n

Reference: Detailed Security Contest

\n

GOT

\n

The GOT (Global Offset Table) refers to a section of computer program memory (executable files and shared libraries) used to ensure that programs compiled as ELF files can execute correctly.

\n

Reference: Global Offset Table - Wikipedia

\n

Simply put, the GOT is an area for maintaining a list of library function addresses.

\n

This area is populated with the addresses of library functions used during program execution.

\n

The GOT makes it easy to relocate library functions within the process memory space.

\n

PLT

\n

The PLT (Procedure Linkage Table) is a collection of small code snippets for calling library functions.

\n

The PLT contains the same number of code entries as the library functions held by the GOT.

\n

The behavior of the code in the PLT is to jump to the value set in the GOT.

\n

When PLT code is called and the function address has not yet been set in the GOT, it sets the address in the GOT before jumping.

\n

Reference: What are PLT and GOT? · Keichi Takahashi

\n

Tracing GOT and PLT Operations

\n

From here, we’ll use GDB to examine the memory map in practice.

\n

Source Code and Build

\n

The code used for verification is as follows.

\n
#include <stdio.h>\n#include <stdlib.h>\n\nint test()\n{\n    return 0;\n}\n\nint main()\n{\n    int a = test();\n    int b = rand();\n    int c = rand();\n    return a * b;\n}
\n

Compile with the following command and launch with gdb.

\n
gcc -fcf-protection=none -no-pie -g test.c -o test.o\ngdb ./test.o
\n

Virtual Memory Output

\n

Linux provides the /proc directory as a pseudo-directory for currently running processes.

\n

Directly under the /proc directory, there are numeric directories corresponding to the PIDs of running processes, with process control tables mapped inside them.

\n

Reference: About Process Memory Maps (Linux)

\n

Reference: embedded - Understanding Linux /proc/pid/maps or /proc/self/maps - Stack Overflow

\n

To check the process memory map, I used the following command.

\n
$ cat /proc/`pidof test.o`/maps\naddress           permission offset   device inode      pathname\n00400000-00401000 r--p 00000000 fd:00 786517                             /home/ubuntu/gottest/test.o\n00401000-00402000 r-xp 00001000 fd:00 786517                             /home/ubuntu/gottest/test.o\n00402000-00403000 r--p 00002000 fd:00 786517                             /home/ubuntu/gottest/test.o\n00403000-00404000 r--p 00002000 fd:00 786517                             /home/ubuntu/gottest/test.o\n00404000-00405000 rw-p 00003000 fd:00 786517                             /home/ubuntu/gottest/test.o\n7ffff7dc3000-7ffff7de8000 r--p 00000000 fd:00 945235                     /lib/x86_64-linux-gnu/libc-2.31.so\n7ffff7de8000-7ffff7f60000 r-xp 00025000 fd:00 945235                     /lib/x86_64-linux-gnu/libc-2.31.so\n7ffff7f60000-7ffff7faa000 r--p 0019d000 fd:00 945235                     /lib/x86_64-linux-gnu/libc-2.31.so\n7ffff7faa000-7ffff7fab000 ---p 001e7000 fd:00 945235                     /lib/x86_64-linux-gnu/libc-2.31.so\n7ffff7fab000-7ffff7fae000 r--p 001e7000 fd:00 945235                     /lib/x86_64-linux-gnu/libc-2.31.so\n7ffff7fae000-7ffff7fb1000 rw-p 001ea000 fd:00 945235                     /lib/x86_64-linux-gnu/libc-2.31.so\n7ffff7fb1000-7ffff7fb7000 rw-p 00000000 00:00 0 \n7ffff7fcb000-7ffff7fce000 r--p 00000000 00:00 0                          [vvar]\n7ffff7fce000-7ffff7fcf000 r-xp 00000000 00:00 0                          [vdso]\n7ffff7fcf000-7ffff7fd0000 r--p 00000000 fd:00 945231                     /lib/x86_64-linux-gnu/ld-2.31.so\n7ffff7fd0000-7ffff7ff3000 r-xp 00001000 fd:00 945231                     /lib/x86_64-linux-gnu/ld-2.31.so\n7ffff7ff3000-7ffff7ffb000 r--p 00024000 fd:00 945231                     /lib/x86_64-linux-gnu/ld-2.31.so\n7ffff7ffc000-7ffff7ffd000 r--p 0002c000 fd:00 945231                     /lib/x86_64-linux-gnu/ld-2.31.so\n7ffff7ffd000-7ffff7ffe000 rw-p 0002d000 fd:00 945231                     /lib/x86_64-linux-gnu/ld-2.31.so\n7ffff7ffe000-7ffff7fff000 rw-p 00000000 00:00 0 \n7ffffffde000-7ffffffff000 rw-p 00000000 00:00 0                          [stack]\nffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0                  [vsyscall]
\n

maps indicates contiguous virtual memory regions within a process or thread.

\n

The address records the start and end addresses of the region in the process address space, and permission records the permissions for that region.

\n

From the above results, we can see that two shared libraries are being used: /lib/x86_64-linux-gnu/libc-2.31.so and /lib/x86_64-linux-gnu/ld-2.31.so.

\n

Here, the shared library /lib/x86_64-linux-gnu/ld-2.31.so is mapped to 7ffff7fcf000, but this is not a fixed address.

\n

The memory address where a shared library is deployed is determined at program runtime and may be deployed to different addresses depending on the circumstances.

\n

The mechanism that investigates which memory address a shared library is actually deployed to at runtime and calls it is PLT and GOT.

\n

Call Instruction

\n

Here’s an excerpt of the call instruction locations from the assembly source.

\n
$ disas main\nDump of assembler code for function main:\n   0x000000000040113e <+13>:call   0x401126 <test>\n   0x0000000000401146 <+21>:call   0x401030 <rand@plt>\n   0x000000000040114e <+29>:call   0x401030 <rand@plt>\nEnd of assembler dump.
\n

The call instruction executes a combination of the following two processes:

\n\n

Reference: Function Calls in x86 Assembly Language

\n

Here, let’s output the assembly for each of the two call instructions.

\n
# 0x401126 <test>\n$ disas 0x401126\nDump of assembler code for function test:\n   0x0000000000401126 <+0>:push   rbp\n   0x0000000000401127 <+1>:mov    rbp,rsp\n   0x000000000040112a <+4>:mov    eax,0x0\n   0x000000000040112f <+9>:pop    rbp\n   0x0000000000401130 <+10>:ret    \nEnd of assembler dump.
\n
# 0x401030 <rand@plt>\n$ disas 0x401030\nDump of assembler code for function rand@plt:\n   0x0000000000401030 <+0>:jmp    QWORD PTR [rip+0x2fe2]        # 0x404018 <rand@got.plt>\n   0x0000000000401036 <+6>:push   0x0\n   0x000000000040103b <+11>:jmp    0x401020\nEnd of assembler dump.
\n

When comparing these, we can see that while the user function test is directly called, when calling rand, rand@plt is called instead.

\n

When rand@plt is called, the first JMP instruction calls rand@got.plt.

\n

This is because the destination address has not yet been set in the GOT.

\n

Calling Shared Library Functions

\n

Next, we’ll set breakpoints at the first and second rand function call points respectively, and observe the changes in the GOT before and after the shared library function is bound through the PLT and GOT.

\n
$ b *0x401146\n$ b *0x40114e\n$ run
\n

Now we’ve reached the first rand function call point.

\n

From the disassembly result of rand@plt, we know that the corresponding GOT address is 0x404018.

\n

In other words, ultimately the address of the rand function body should be stored at 0x404018.

\n

However, at this point, the rand function has not been called once during program execution, so the GOT contains the address of rand@plt+6.

\n
$ telescope 0x404018\n0000| 0x404018 --> 0x401036 (<rand@plt+6>:push   0x0)
\n

Reference: Command dereference - GEF - GDB Enhanced Features documentation

\n

The processing at address rand@plt+6 pushes a value (0x0) onto the stack and then jumps to 0x401020.

\n
$ disas 0x401030\nDump of assembler code for function rand@plt:\n   0x0000000000401030 <+0>:jmp    QWORD PTR [rip+0x2fe2]        # 0x404018 <rand@got.plt>\n   0x0000000000401036 <+6>:push   0x0\n   0x000000000040103b <+11>:jmp    0x401020\nEnd of assembler dump.
\n

The subsequent processing stores another value on the stack and then continues with processing that jumps to the address stored at 0x404010.

\n
$ x/16 0x401020\n   0x401020:push   QWORD PTR [rip+0x2fe2]        # 0x404008\n   0x401026:jmp    QWORD PTR [rip+0x2fe4]        # 0x404010
\n

Setting a breakpoint at 0x401036 and tracing the subsequent processing yielded the following results.

\n
=> 0x401026:jmp    QWORD PTR [rip+0x2fe4]        # 0x404010\n | 0x40102c:nop    DWORD PTR [rax+0x0]\n | 0x401030 <rand@plt>:jmp    QWORD PTR [rip+0x2fe2]        # 0x404018 <rand@got.plt>\n | 0x401036 <rand@plt+6>:push   0x0\n | 0x40103b <rand@plt+11>:jmp    0x401020\n |->   0x7ffff7fe7bb0:endbr64 \n       0x7ffff7fe7bb4:push   rbx\n       0x7ffff7fe7bb5:mov    rbx,rsp\n       0x7ffff7fe7bb8:and    rsp,0xffffffffffffffc0\n       0x7ffff7fe7bbc:sub    rsp,QWORD PTR [rip+0x14b45]        # 0x7ffff7ffc708 <_rtld_global_ro+232>
\n

The function being called here is _dl_runtime_resolve.

\n

The following reference was very helpful for details.

\n

Reference: Ret2dl_resolve x64

\n

This function resolves the address of the target rand function and calls it.

\n

Since the GOT is updated at this point, subsequent calls to the rand function will directly call the resolved rand function address from the GOT.

\n

When we actually stop at the second rand function call point and check the contents of the GOT referenced by rand@plt as before, we find that it contains the address of the rand function body.

\n
$ telescope 0x404018\n0000| 0x404018 --> 0x7ffff7e0de90 (<rand>:endbr64)
\n

Therefore, on the second execution, _dl_runtime_resolve is not called, and the rand function is executed directly.

\n

Summary

\n

I started by reading UNIX code but ended up investigating GOT and PLT.

\n

Since Detailed Security Contest contains more detailed information, I plan to dig deeper while also trying things like GOT Overwrite.

\n

References

\n","fields":{"slug":"/linux-got-plt-en","tagSlugs":["/tag/linux-en/","/tag/os-en/","/tag/kernel-en/","/tag/english/"]},"frontmatter":{"date":"2022-01-06","description":"This article summarizes the overview of GOT and PLT and presents practical verification results.","tags":["Linux (en)","OS (en)","Kernel (en)","English"],"title":"Tracing Library Function Calls Through GOT/PLT","socialImage":{"publicURL":"/static/a4f7c9e2f649a8b7bec38cf6b030aece/linux-got-plt.png"}}}},"pageContext":{"slug":"/linux-got-plt-en"}},"staticQueryHashes":["251939775","401334301","825871152"]}