Stack Exploitation Dev

Stack Exploitation Development

Goal: turn a stack bug into the right primitive for that ABI and mitigation set, not into reflex shellcode or nostalgic SEH.

When to activate

• Linear stack overflow, off-by-one, saved-frame-pointer corruption, partial return overwrite, VLA/alloca misuse, format-string-assisted stack corruption, or uninitialized stack leak is in play.
• Need mitigation-aware exploit design instead of generic buffer-overflow advice.
• Need to defeat PIE / ASLR with a realistic leak-first, partial-overwrite, or retry-model plan instead of guessed bases.
• Need to choose between ret2libc, ret2dlresolve, ret2csu, SROP, stack pivots, JOP/COP/COOP, or data-only outcomes.
• Target is Linux, Windows user-mode, or AArch64 user-mode and the exploitability story depends on calling convention, frame layout, or modern CFI.
• A working chain breaks across builds and the real problem is environment classification, not just gadget collection.

If the problem is mostly gadget selection, chain scoring, and ABI-correct ROP assembly, use offensive-coding/rop-development-dev after this skill narrows the route.

First classify the environment

1. Identify architecture and ABI
   • x86-64 SysV: 16-byte alignment, classic ret2libc / PLT / resolver patterns.
   • Windows x64: rcx, rdx, r8, r9 + 32-byte shadow space; /GS, CFG, EHCONT, and hardware shadow stack may dominate exploitability.
   • AArch64: x0-x7 args, x30 link register, PAC/BTI/ShadowCallStack may shrink backward-edge options.
2. Classify the primitive
   • linear overflow / partial overwrite
   • off-by-one into saved frame state
   • format-string-assisted write or leak
   • stack disclosure / uninitialized read
   • VLA/alloca / stack-growth bug
3. Decide the capability you actually need
   • canary leak
   • stack or module leak
   • controlled return / LR
   • stack pivot
   • syscall or API call
   • data-only logic corruption
4. Map mitigations before choosing the chain
   • NX / DEP
   • PIE / ASLR
   • RELRO
   • stack canary / SSP
   • _FORTIFY_SOURCE
   • Intel CET shadow stack / IBT
   • Windows /GS, CFG, EHCONT, hardware shadow stack
   • ARM64 PAC / BTI / ShadowCallStack
   • stack-clash protection, seccomp, SUID, sandboxing

Environment-first selection

Technique families worth prioritizing

Mitigation-driven rules

• Canary / SSP: do not plan a final return smash before you know how the canary is leaked, preserved, or bypassed.
• NX / DEP: shellcode is conditional, not default. Verify executable memory first.
• PIE / ASLR: decide which mapping you need to recover (PIE/text, libc, stack, heap), then treat leaks as stage one, not optional polish.
• RELRO: easy GOT-overwrite endings may vanish; leaks and direct chains do not.
• _FORTIFY_SOURCE: _chk aborts change bug shape and timing, but they do not magically erase leak paths or pre-check corruption.
• Intel CET shadow stack: plain return-address corruption usually dies. Stop insisting on RET-only plans when shadow stack is real.
• CET IBT / BTI / CFG: indirect targets must be valid targets, not random gadgets.
• Windows /GS: protects selected functions and some vulnerable parameters, not every data-only route.
• Windows EHCONT: blind NtContinue / RtlRestoreContext abuse is outdated unless the target build genuinely permits it.
• ARM64 PAC: raw forged pointers are lower-probability than signed-pointer reuse or non-return targets.
• ShadowCallStack / hardware shadow stacks: backward-edge hijack becomes the expensive branch; consider forward-edge or data-only outcomes first.
• stack-clash protection: large alloca/VLA leaps are compiler- and target-sensitive; validate actual probing behavior.

Endgame selection

• No NX and truly executable stack: shellcode is fine, but only after verification.
• NX + libc leak: prefer ret2libc, syscall chains, or short ORW.
• No libc leak but dynamic loader path exists: ret2dlresolve.
• Sparse gadgets but sigreturn reachable: SROP.
• CET / CFG / PAC / shadow stacks dominate: bias toward data-only, JOP/COP/COOP, valid-target abuse, or authenticated-pointer reuse.
• Windows: API-call ROP or data-only object/policy corruption, not legacy SEH nostalgia.
• SUID / seccomp: choose credential-safe execve, ORW, or allowed-syscall paths over system("/bin/sh") reflexes.

Reliability checklist

• Confirm exact ABI, stack alignment needs, and whether a frame pointer exists.
• Find the true overwrite offset with evidence, not guesswork.
• Separate leak acquisition, pivot/control primitive, and endgame.
• Track bad characters, encodings, and input transforms before choosing a pivot or frame format.
• Rerun under randomized layouts and slightly different heap/stack schedules.
• Keep a data-only fallback if backward-edge control becomes too expensive.

Anti-patterns

• Recommending stack shellcode on NX/DEP targets by reflex.
• Treating canary brute force as a normal first choice outside fork/respawn models.
• Forcing classic ROP through CET, shadow stack, PAC, or EHCONT when the target is telling you to pivot.
• Treating 32-bit SEH writeups as modern Windows x64 guidance.
• Ignoring compiler/runtime hardening bundles and reasoning from one mitigation at a time.

Resources

references/

• references/linux-techniques.md — load for Linux route selection, ret2libc / ret2dlresolve / SROP / pivot trade-offs.
• references/aslr-bypass.md — load for leak-first routing, ret2plt / ret2main, PIE/text-base leaks, ret2dlresolve, low-byte wins, libc fingerprinting, and brute-force economics.
• references/mitigations-and-selection.md — load when mitigations, compiler flags, or runtime hardening are the main decision point.
• references/windows-techniques.md — load for /GS, CFG, EHCONT, hardware shadow stack, and realistic Windows user-mode routes.
• references/arm64-and-modern-cfi.md — load for AArch64 ABI facts, PAC/BTI, ShadowCallStack, and modern CFI-aware selection.
• references/leaks-pivots-and-partials.md — load for canary leaks, partial overwrites, leave; ret, stage-two pivots, and non-control-data stack wins.
• Upstream methodology: offensive-techniques/binary-exploitation-technique (primitive→impact strategy, mitigation selection) and offensive-ctf/pwn-ctf/references/overflow.md (concrete recipes).

Load references only after architecture, primitive, and mitigation set are clear. Keep SKILL.md as the router; keep the depth in the references.