Format String Attacks Demystified

Sun, 14 Dec 2025 00:00:00 +0000

Format string vulnerabilities happen when user-controlled input ends up as the first argument to printf(). Instead of printing text, the attacker reads or writes arbitrary memory.

We demonstrate reading the stack with %08x specifiers, then escalate to an arbitrary write using %n. The write-what-where primitive turns a seemingly harmless logging call into full code execution.

The fix is trivial: always pass a format string literal. printf("%s", buf) instead of printf(buf). Yet this class of bug resurfaces in embedded firmware to this day.

Why does this still happen? Because logging code is often treated as harmless, copied fast, and reviewed late. In small C projects, developers optimize for speed of implementation and forget that formatting functions are tiny parsers with side effects.

Exploitation ladder

Typical progression in a lab binary:

Leak stack values with %x and locate attacker-controlled bytes.
Calibrate offsets until output is deterministic.
Use width specifiers to control write count.
Trigger %n (or %hn) to write controlled values to target addresses.

At that point, you can often redirect flow indirectly by corrupting function pointers, GOT entries (where applicable), or security-relevant flags.

Defensive pattern

Treat every formatting call as a sink:

enforce literal format strings in coding guidelines
compile with warnings that detect non-literal format usage
isolate logging wrappers so raw printf calls are rare
review embedded diagnostics paths as carefully as network parsers

Buffer Overflow 101

Mon, 03 Nov 2025 00:00:00 +0000

A stack-based buffer overflow is the oldest trick in the book and still one of the most instructive. We start with a vulnerable C program, compile it without canaries, and walk through EIP control step by step.

The target binary accepts user input via gets() — a function so dangerous that modern compilers emit a warning just for including it. We feed it a carefully crafted payload: 64 bytes of padding, followed by the address of our shellcode sitting on the stack.

Key takeaways: always compile test binaries with -fno-stack-protector -z execstack when learning, and never on a production box.

What makes this topic timeless is not the exact exploit recipe, but the mental model it gives you: memory layout, calling convention, control-flow integrity, and why unsafe copy primitives are dangerous by construction.

Reliable lab workflow

Confirm binary protections (checksec style checks).
Crash with pattern input to find exact overwrite offset.
Validate instruction pointer control with marker values.
Build payload in small increments and verify each stage.
Only then attempt shellcode or return-oriented payloads.

Expected outcome before each run should be explicit. If behavior differs, do not “try random bytes”; explain the difference first. That habit turns exploit practice into engineering instead of cargo cult.

Defensive mirror

Learning offensive mechanics should immediately map to mitigation: