Relocation

What relocation means in executable loading

Relocation is the loader’s instruction set for fixing up code and data when a program is mapped somewhere other than the address it was originally linked for. In practice, the operating system applies those adjustments while loading, which lets the same binary run at different addresses and supports position-independent code.

The key security and performance implication is that relocation is not just a naming detail, it is an active write step during load time. That write activity can alter page state, including turning otherwise constant pages into dirty memory, which affects how the system accounts for and shares those pages.

Why relocation exists

Modern executables and libraries often cannot rely on fixed addresses. Address space layout randomisation, shared libraries, and position-independent code all depend on the loader being able to resolve references after mapping. Relocation is the mechanism that makes those references correct at runtime without hard-coding a single memory layout.

This matters because the same concept underpins both compatibility and hardening. A binary can be built once and loaded safely in different memory layouts, but the loader must still modify selected instructions or pointers so that control flow and data references remain valid after randomisation.

How relocation changes memory behaviour

Relocation introduces a write path into pages that may otherwise have been read-only or shareable. Once the loader updates relocation entries, those pages can no longer be treated as untouched static image pages in the same way, because the system has materially modified them during load.

That change is important for memory efficiency and observability. Dirtying pages can reduce sharing across processes, increase resident memory use, and make the loaded image behave differently from a purely immutable code segment. In low-level debugging and performance analysis, relocation activity is often one reason a binary’s memory footprint does not match its on-disk layout.

Relocation in practice for security analysis

For defenders, relocation is a normal and expected loader behaviour, not a sign of compromise by itself. It becomes interesting when you are reasoning about executable image integrity, memory accounting, or whether code pages stayed in a state that your monitoring tool expected. It also helps explain why some binaries and libraries are compatible with address randomisation while others need more loader intervention.

When analysing a process, it is useful to distinguish relocation from later runtime memory writes. The former happens during loading as part of normal image setup, while the latter may indicate self-modifying code, JIT activity, unpacking, or exploitation behaviour. That distinction keeps memory forensics and performance tuning from conflating ordinary loader fixups with suspicious post-startup modification.

Risk and Threat Considerations

Relocation is usually benign, but it creates an early write window during program start-up, which can complicate memory integrity assumptions and page-sharing efficiency. In environments that rely on stable page state, the loader’s fixups can also make memory accounting and baselining less intuitive.

Failure mechanism: If teams assume executable pages remain untouched after mapping, they may misread normal relocation writes as suspicious activity, or miss later writes because the page was already dirtied during load.

Impact: The result can be weaker detection fidelity, less reliable memory baselines, and higher memory overhead when pages that could have stayed shared or clean become private dirty pages.

Practitioner Guidance

What to watch for: Treat relocation as part of normal loader behaviour and separate it from post-load code modification in telemetry, memory forensics, and incident response. When you profile a process, account for relocation-driven page dirtying before drawing conclusions about self-modification or tampering.

Practitioner note: If a workload’s memory footprint or page cleanliness matters, the useful question is not whether relocation exists, but whether the binary’s loading model and instrumentation can tolerate the loader’s expected write activity.

Related resources from NHI Mgmt Group

• What evidence shows Relocation Read-Only (RELRO) is working?
• Relocation Services Contractor
• Latency Relocation
• Protective relocation