Dynamic linking, GOT, PLT, and relocation protection

Mechanism

Dynamically linked ELF programs resolve external symbols through relocation records and runtime loader machinery. The PLT commonly provides call stubs while the GOT contains associated addresses. Lazy binding and eager binding produce different runtime states. Relocation protection determines whether certain relocated memory becomes read-only after loading.

Practical method

Inspect dynamic tags and relocations, then map the relevant symbol to its call site. Compare GOT contents before and after the first call if lazy resolution applies. Locate the read-only mapping boundaries in the running process. Treat a function-pointer overwrite plan separately from a symbol-resolution manipulation plan.

readelf -d ./challenge
readelf -r ./challenge
objdump -d ./challenge

Interpreting evidence

A writable-looking section in the file does not guarantee a writable mapping after relocation. Confirm the target address at runtime and identify whether the symbol has already been resolved.

Pitfalls and limits

Full RELRO blocks conventional GOT overwrites, but other application pointers may remain writable. PIE shifts image-relative locations. Loader implementations and modern linker options can change familiar PLT layouts.