The Global Offset Table stores addresses used by dynamically linked binaries for external functions and global variables. It acts as the indirection layer between code and the runtime-resolved address, supporting both eager and lazy binding models.
What the Global Offset Table Does
The Global Offset Table, or GOT, is the runtime address table used by dynamically linked programs to reach external functions and global variables. It lets the binary call or read symbols whose final addresses are not fixed until load time.
In practice, the GOT is one half of the indirection path that makes dynamic linking work. The code usually references a table entry, and the dynamic loader fills that entry with the resolved address, either before execution begins or on first use depending on the binding model.
How the GOT Fits Dynamic Linking
The GOT exists because shared libraries and position-independent code cannot assume that a symbol will live at a fixed address. The table gives the program a stable reference point while the actual target address can vary from run to run, process to process, or library to library.
This indirection is what makes relocation manageable. Instead of rewriting every instruction that needs an external symbol, the loader updates selected table entries and the program reads those entries when it needs to transfer control or access data.
Eager Binding, Lazy Binding, and the PLT Relationship
The GOT is closely related to the Procedure Linkage Table, which is used for function calls in many ELF binaries. With eager binding, symbol resolution happens up front and the GOT entry is populated before the program relies on it. With lazy binding, the first call may route through the PLT, which then asks the dynamic loader to resolve the symbol and update the GOT entry.
That split matters because it affects startup cost, call-path behavior, and when addresses become trustworthy. A binary using lazy binding may leave some GOT entries unresolved until they are actually used, while eager binding resolves more of the dependency graph at load time.
Why the GOT Matters for Security and Reverse Engineering
The GOT is a normal part of dynamic linking, but it also creates a high-value target because it controls where indirect calls and global symbol references land. If an attacker can corrupt GOT entries, they can redirect control flow or alter how the program resolves a dependency.
For defenders and analysts, that means GOT behavior is useful in both hardening and triage. It helps explain why position-independent binaries, relocation metadata, and loader behavior are central to understanding exploitability, call redirection, and runtime integrity.
Risk and Threat Considerations
GOT corruption can turn an ordinary memory-write bug into control-flow hijacking, because the table governs the addresses used for indirect calls and symbol access. The risk is greatest when writable relocation targets remain exposed after resolution or when an attacker can influence relocation-related memory.
Failure mechanism: An attacker or buggy overwrite changes a GOT entry, so later calls or accesses resolve to an unintended address instead of the legitimate function or object.
Impact: The result can be code execution, process tampering, crash-only denial of service, or stealthy redirection of program behavior.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1574 — Hijack Execution Flow | GOT overwrite redirects execution through a controlled address. |
| Recommendation — Map suspicious GOT tampering to Hijack Execution Flow and hunt for control-flow redirection. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Memory corruption that alters GOT entries is a validation and integrity failure path. |
| SI-7 — Software, Firmware, and Information Integrity | GOT integrity is part of preserving executable behavior and runtime trust. | |
| Recommendation — Validate and constrain externally influenced inputs to reduce memory corruption that can alter relocation targets. Apply integrity controls to detect unauthorized changes to executable memory and relocation state. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Secure binary design and memory safety reduce exploitation paths that target GOT entries. |
| Recommendation — Design and verify binaries to minimize memory corruption surfaces that can redirect GOT-based control flow. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Binary hardening and linker configuration are software hardening concerns tied to GOT exposure. |
| Recommendation — Harden build and runtime configurations to reduce writable relocation and indirect-call abuse. | ||
Practitioner Guidance
What to watch for: Treat GOT-related discussion as a signal to review whether the binary uses modern linker and compiler protections, especially where relocation targets or indirect-call surfaces are exposed. Analysts should also remember that lazy binding can delay symbol resolution, which changes when runtime behavior becomes observable.
Practitioner takeaway: When debugging or securing a dynamically linked binary, the GOT is not just an implementation detail, it is part of the program’s runtime trust boundary.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
