Procedure Linkage Table

What the Procedure Linkage Table does

The Procedure Linkage Table, or PLT, is the indirection layer that lets a dynamically linked program call functions defined outside its own binary. Instead of binding every external symbol at load time, the PLT provides a small set of jump stubs that hand control to the dynamic linker when a function is first needed.

This design keeps binaries modular and reduces upfront relocation work, but it also means execution flows through resolver logic before a final function address is fixed. The PLT therefore sits at the boundary between compiled code, the Global Offset Table, and the runtime linker.

How PLT and GOT work together

In the common ELF model, a PLT entry is paired with a GOT slot. On the first call, the PLT stub routes execution to the resolver, which updates the GOT with the resolved address. Later calls can jump directly through the now-patched GOT entry, avoiding repeat resolution overhead.

This split between code stubs and writable relocation data is what makes lazy binding possible. It also explains why PLT behaviour can differ across linkers, loaders, and hardening settings: the exact runtime path depends on when symbols are resolved and how relocation sections are protected.

Why the PLT matters for reverse engineering and debugging

For analysts, the PLT is often the easiest place to spot imported functionality because each stub typically corresponds to an external symbol. Disassemblers and debuggers use these entries to identify where a program reaches into shared libraries, which can reveal dependencies, call patterns, and the presence of late-bound APIs.

Because the PLT is a trampoline rather than the final implementation, stepping through it can be confusing if you expect a direct function body. Understanding the PLT helps distinguish a program's own logic from loader-managed indirection, which is especially useful when tracing crashes, instrumenting calls, or reviewing control flow in shared-object heavy software.

Security implications of PLT indirection

The PLT is not inherently a vulnerability, but it is part of a code path that attackers may try to influence when they can corrupt relocation-related data or exploit memory-safety flaws elsewhere in the process. Any mechanism that redirects control flow through writable or indirectly resolved pointers deserves attention in hardened builds.

Its security significance is strongest in the broader context of dynamic linking, relocation, and executable memory protection. Defenders typically care about whether indirect call targets can be tampered with, whether relocation data is protected after resolution, and whether tooling assumptions about imported symbols remain valid during incident analysis.

Risk and Threat Considerations

PLT entries create an intentional control-flow indirection point, so any weakness in how relocation data is managed can become a control-flow abuse opportunity. The practical risk is not the PLT itself, but the combination of lazy binding, writable relocation state, and memory corruption in the same process.

Failure mechanism: An attacker who can alter a GOT entry, hijack a relocation path, or exploit a related memory bug may redirect a later PLT-mediated call to an unintended target.

Impact: That can produce arbitrary code execution, function-call redirection, or difficult-to-detect tampering with normal program behaviour, especially in long-running processes that make repeated external calls.

Practitioner Guidance

What to watch for: Treat PLT behaviour as a normal part of dynamic linking, but verify whether your build and deployment settings reduce exposure from lazy binding and writable relocation data. Hardened binaries are easier to reason about because the loader's role is more constrained after startup.

Practitioner takeaway: When debugging or auditing a binary, follow the PLT to understand where control is handed off, then confirm that the imported-function path is consistent with the program's expected dependencies and hardening posture.

Related resources from NHI Mgmt Group

• What breaks when identity controls stop at table-level permissions?
• How should security teams prevent rainbow table attacks on password hashes?
• How should security teams govern PostgreSQL table discovery in production environments?
• Why do stored database credentials increase risk even for read-only table queries?