Exploitability (`--exploit`)¶

--exploit adds static mitigation-obstruction analysis. It reports which memory-corruption techniques the binary's posture fails to block, citing the evidence (imports, relocations, segment permissions) behind each verdict.

What it claims — and does not¶

It is not a vulnerability scanner. It never says a binary is "exploitable."
VIABLE means: this technique is not blocked by the mitigation posture, and the binary contains the primitives it needs. It assumes a reachable bug.
Every verdict cites its evidence and lists its assumptions.

Tiers¶

Tier	Meaning
VIABLE	Not blocked; required primitive present; minimal assumptions.
LIKELY	Not blocked; primitive present but conditionally unsafe.
REQUIRES-LEAK	Not blocked, but needs an info leak first.
REQUIRES-INPUT-CONTROL	Needs attacker control of a specific input.
ENABLER	A primitive that unlocks other techniques.
BLOCKED	A mitigation defeats this technique.

Example¶

Run against an unhardened binary (no RELRO, no canary, NX disabled):

$ checksec file ./target --exploit
... (the normal check row) ...
Exploitability (static; mitigation-obstruction, not proof):
  LIKELY                 stack-bof-overwrite   stack overflow via an unbounded copy   strcpy
  VIABLE                 got-overwrite         GOT entry overwrite                    printf; strcpy; ...
  VIABLE                 shellcode-injection   Shellcode injection                    NX disabled
  VIABLE                 ret2libc              ret2libc                               strcpy; dynamically linked
  REQUIRES-INPUT-CONTROL format-string         Format-string read/write primitive     printf
  VIABLE                 ret2dlresolve         ret2dlresolve                          strcpy; lazy binding
  Bar: Attacker needs a reachable bug; no leak or bypass required.

Each line is TIER rule-id technique citations. The trailing Bar: line is a one-sentence synthesis of the overall attacker cost — e.g. whether an info leak or canary bypass is still required, or (as above) whether the posture leaves techniques unobstructed outright.

Techniques¶

The Phase A corpus reasons about the classic memory-corruption techniques:

Rule id	Technique
`stack-bof-overwrite`	Stack overflow overwriting the return address
`ret2plt`	Return into a PLT stub (e.g. `system@plt`) without a leak
`ret2libc`	Return into libc
`got-overwrite`	Overwrite a writable GOT entry to redirect a call
`shellcode-injection`	Inject and execute shellcode
`format-string`	Format-string read/write primitive
`ret2dlresolve`	Abuse the lazy dynamic resolver

Usage¶

# Append the exploitability section to the default table
checksec file ./target --exploit

# Add a labelled hypothesis exploit chain (implies --exploit)
checksec file ./target --exploit --chain

# Machine-readable — verdicts embed under each report's `exploitability` key,
# with tiers serialized as their names (e.g. "VIABLE")
checksec file ./target --exploit -o json

# Grounded, paste-into-an-LLM report with verdicts inline
checksec file ./target --exploit -o llm

CI gating¶

With --exploit, --fail-if accepts two exploitability predicates:

# Fail if any technique is VIABLE
checksec file ./target --exploit --fail-if=exploit.viable

# Fail if a specific technique is open (tier REQUIRES-LEAK or higher)
checksec file ./target --exploit --fail-if=exploit.technique=got-overwrite

`--chain` (hypothesis)¶

--chain assembles a labelled hypothesis exploit chain from the VIABLE verdicts — a control-flow-hijack step plus a compatible payload step. It is always marked hypothesis, never presented as fact, and prints no consistent chain at current tier when the VIABLE set can't be assembled into one. Use it as a starting sketch, not a proof.

Exploitability (--exploit)¶