Lab 02 — Binary Hardening Report Analyzer

Difficulty: 3/5 | Runs locally: yes

Pairs with the Phase 01 WARMUP Chapters 7 and 10 (executable formats, compiler/ runtime hardening) and the HITCHHIKERS-GUIDE ("Inspecting the Final Binary").

Why This Lab Exists (Purpose & Goal)

A memory-safety bug that is exploitable and one that is merely a crash are worlds apart, and the difference is largely decided by which hardening mitigations the binary was compiled with. The goal of this lab is to teach you to read a compiled binary's protections the way a reviewer must: given normalized ELF/PE/Mach-O metadata, report what is missing — ASLR/PIE, NX, stack canary, RELRO, code signing — and flag the cardinal sin, a writable+executable segment. You are building the tested policy engine that turns "is this build hardened?" from a hunch into an answer.

The Concept, In the Weeds

These mitigations do not make bugs correct; they make them harder to exploit, and each covers a specific technique:

  • ASLR/PIE randomizes where code, stack, and heap land, so an attacker can't hardcode addresses. It requires the binary to be position-independent (PIE / a DYN ELF type). Defeated by an information leak that reveals one real address.
  • NX / DEP / W^X marks writable pages non-executable, so injected data can't run as code. This is why a writable+executable segment is a red flag — it re-opens the door NX closed.
  • Stack canary places a random value before the saved return address and checks it on return, detecting contiguous stack overflows.
  • RELRO makes the relocation/GOT tables read-only after startup, blocking a classic function-pointer overwrite.
  • Code signing establishes author/integrity (especially on Mach-O/Windows).

The design lesson is in the architecture: the lab separates format collection from policy so that platform-specific extractors (one for ELF, one for PE, one for Mach-O) can all feed one tested evaluator. That separation — normalize first, then apply one policy — is how real security tooling scales across heterogeneous inputs without duplicating the judgment.

Why This Matters for Protecting the Company

Supply-chain and third-party binaries are a real attack surface: you ship dependencies, vendor agents, and base-image binaries you did not compile. "Is this artifact hardened?" is a question that comes up in supply-chain review (Phase 03), in incident response (Phase 09 — was the exploited process hardened?), and in vendor assessments. Reading the format yourself, rather than trusting a tool's one-line summary, lets you answer precisely and defend the answer. Crucially, you also learn the discipline of never downgrading a memory-corruption bug to "won't fix" just because mitigations are on — mitigations raise cost, they don't eliminate the bug.

How This Is Used on the Job

This is a build-pipeline gate and an assessment checklist. CI can fail a release whose binary lost PIE or RELRO; a pentest report flags a service running a non-hardened binary; an IR analyst checks whether a compromised process had the mitigations that would have changed the attacker's effort. The "normalize, then evaluate" split is the same pattern you'll reuse in detection engineering (Phase 05/ 09) where many telemetry sources feed one rule set.

Build It

Implement the evaluator over normalized binary metadata: report each missing protection (PIE/ASLR, NX, canary, RELRO, signing) and flag any writable+executable segment. Keep the policy independent of the format-specific collection.

LAB_MODULE=solution pytest -q

On a real binary you'd feed it from readelf -lW, readelf -d, checksec, or the PE/Mach-O equivalents (Phase 01 HITCHHIKERS).

Validation — What You Should Be Able to Do Now

  • Name each mitigation, the exploitation technique it blunts, and how it is defeated.
  • Explain why a writable+executable mapping is a critical finding.
  • Read the hardening flags off a binary yourself instead of trusting a summary.
  • Explain why mitigations change exploitability, never correctness, so a bug stays a bug.

The Broader Perspective

This lab develops the reviewer's habit of reading the artifact, not the intention: the build script may claim -fstack-protector -pie, but the shipped binary is the truth, and only inspecting it proves it. That "verify the effective state, not the configured intent" discipline runs through the whole curriculum — it is the same reason Phase 07 queries deployed cloud state instead of trusting Terraform, and Phase 05 reads the running service's effective seccomp/capabilities instead of the unit file.

Interview Angle

  • "What hardening would you check on a shipped binary, and what does each prevent?" — PIE/ASLR (no hardcoded addresses), NX/W^X (data can't execute), stack canary (detects stack smashing), RELRO (GOT read-only), signing (author/integrity). Then note that an info leak or ROP defeats them in combination, so they reduce reliability, not the existence of the bug.

Extension (Stretch)

Write the actual ELF and Mach-O collectors that feed the evaluator, and wire it into a CI gate that fails a release on a regression in hardening flags.

References

  • Phase 01 WARMUP Chapters 7, 10; ELF / PE / Mach-O specifications.
  • checksec, readelf; "hardening-check" tooling; glibc/GCC/Clang hardening documentation.