ASLR

Most exploits need to KNOW an address — where libc's system() sits, where a ROP gadget lives, where the stack is. ASLR is the defense of moving the furniture: each time a program runs, the operating system loads its pieces at randomized base addresses, so the attacker can no longer hard-code the address they need. It is like a building whose room numbers are reshuffled on every visit — your map from last time is useless.

Concretely, when a process starts, the loader places major regions — the executable (if built position-independent), shared libraries, the heap, the stack, and the mmap region — at base addresses chosen with random bits added. So libc might load at 0x7f3a... one run and 0x7f8c... the next. Anything an exploit references by absolute address (a gadget, a function, a buffer) is now at an unknown location, breaking ROP chains and return-to-libc that were written for fixed addresses. The strength of ASLR is measured in ENTROPY — how many random bits go into the base address; more bits mean more possible locations and a smaller chance of a lucky guess.

It matters as a cheap, broad mitigation that raises the bar for nearly all memory exploits, but it is honestly a probabilistic obstacle, not a wall. Two things defeat it. First, an information leak (an arbitrary read, a format-string %x, an uninitialized-memory disclosure) that reveals one real runtime address lets the attacker compute all the others, since regions move together by a single random base. Second, LOW ENTROPY: on 32-bit systems there are too few random bits, so brute-forcing or heap spraying can win; 64-bit ASLR is far stronger. This is why ASLR is always paired with DEP, canaries, and CFI — it slows attackers but a single leak can undo it.