Ejecuta cualquier Skill en Manus
con un clic

Ejecuta cualquier Skill en Manus con un clic

mem-exploitability

Estrellas0

Forks0

Actualizado29 de mayo de 2026 a las 02:51

Memory-corruption exploitability ASSESSMENT. For each memory-safety finding (systems-hunt / verify), the mem-exploit-analyst agent works the analysis phases — vuln shape, control/offset plausibility, input constraints, mitigation posture (NX/PIE/canary/RELRO/FORTIFY/CFG from build flags + read-only binary inspection) — and assigns an exploitability tier + remediation, attaching an `exploitability` block onto .kuzushi/findings.json. Assessment only — never produces exploit payloads or mitigation bypasses.

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Ejecutar en Manus

Fuente

allsmog

allsmog/kuzushi-security-plugin

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ejecutar en Manus

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Analistas de seguridad de la informaciónOcupaciones informáticas y matemáticas·SOC 15-1212

SKILL.md

readonly

name	mem-exploitability
description	Memory-corruption exploitability ASSESSMENT. For each memory-safety finding (systems-hunt / verify), the mem-exploit-analyst agent works the analysis phases — vuln shape, control/offset plausibility, input constraints, mitigation posture (NX/PIE/canary/RELRO/FORTIFY/CFG from build flags + read-only binary inspection) — and assigns an exploitability tier + remediation, attaching an `exploitability` block onto .kuzushi/findings.json. Assessment only — never produces exploit payloads or mitigation bypasses.
context	fork
agent	mem-exploit-analyst
user-invocable	false

Memory-corruption exploitability assessment

Assess how exploitable the repo's memory-safety findings are. Requires memory-corruption findings in .kuzushi/findings.json first — run /systems-hunt (native / memory-safety review) or /verify to populate them.

Assessment only. This produces exploitability tiers + mitigation posture + remediation. It does not generate shellcode, ROP/JOP chains, DEP/ASLR/canary/RELRO/CFG bypasses, or any working hijack payload. Empirical crash proof is /poc (gated sandbox).

Run node "${CLAUDE_PLUGIN_ROOT}/scripts/cmd/mem-exploitability-prepare.mjs" --target "<repo root>" (optionally --input '{"maxCandidates":12}'). It errors if there are no memory-corruption findings. Read the prep's prepPath — candidates[] and the repo mitigations posture.
For each candidate, do the per-candidate walk (vuln shape → control/offset plausibility → constraints → mitigation factor → tier + remediation). Use each candidate's findingFingerprint verbatim. Reason about control; never construct an overwrite or payload.
Write the { candidates: [...] } bundle to the prep's draftPath, then run the assembleCommand (finalize) — it validates tiers + remediation and attaches an exploitability block onto each finding (status unchanged).
Report tier counts, the repo mitigation posture, and the likely-code-exec / control-flow-hijack-plausible findings. Point to /poc for empirical crash proof.

When NOT to use

On non-memory findings (injection, authz, SSRF…) — those don't have a memory-corruption tier.
Before any memory-safety finding exists — run /systems-hunt (or /verify) first.
To produce a working exploit — out of scope by design; this is assessment only. Empirical crash proof is /poc.

Rationalizations to Reject

"It's a memory bug, so it's likely-code-exec." → Tier by the actual control/offset plausibility and mitigation posture; many overflows are crash-only or dos, not code-exec.
"Mitigations are on, so it's not exploitable." → Record the mitigation posture as a factor, not a verdict; NX/PIE/canary raise the bar, they don't always close it.
"I'll sketch a quick ROP chain to prove it." → Never. Reason about control; do not construct overwrites, payloads, or bypasses.

Más de este repositorio

mismo repositorio

deep-hunt

allsmog/kuzushi-security-plugin

Interprocedural, hypothesis-driven hunt — finds the multi-file source→sink bugs that pattern-gating and same-file taint miss. Ranks trace anchors (entry points + dangerous sinks), then the deep-hunter agent walks each flow ACROSS files (forward/backward call-graph CLIs) over multiple rounds, confirming propagation and defeating guards, and promotes confirmed cross-file flows into findings.json with the path stored as evidenceGraph. Token-expensive, budget-bounded. Part of the HUNT phase (run via /sweep --deep, or ask for it); leads flow to /verify (panel).

2026-06-110

deep-scan

allsmog/kuzushi-security-plugin

Whole-file deep reader — finds bugs by READING risk-ranked files in full and reasoning from first principles, not by grepping for known patterns. Catches the long tail (project-specific wrappers, business logic, cross-function flaws) that pattern-gated producers structurally miss. Token-expensive; budget-bounded and risk-ranked. Promotes leads into .kuzushi/findings.json (source "deep-scan").

2026-06-110

taint-analysis

allsmog/kuzushi-security-plugin

IRIS-style source→sink taint hunt. Ranks a typed CWE catalog for the repo, then drives subagents to label dangerous sinks, label sources of user input, run Joern/CodeQL dataflow queries (or same-file linking) to connect them, and triage each flow as finding/candidate/rejected. Promotes verdicts into .kuzushi/findings.json. Benefits from a prebuilt CodeQL DB / Joern CPG but degrades gracefully.

2026-06-110

threat-hunt

allsmog/kuzushi-security-plugin

Adversarial per-threat review (Carlini doctrine). For each threat in .kuzushi/threat-model.json, state attacker capabilities, walk source→sink, attempt to bypass every guard, and assign a verdict with evidence. Promotes findings into .kuzushi/findings.json. Requires /threat-model first.

2026-06-110

partition

allsmog/kuzushi-security-plugin

Split the attack surface into parallel-discovery partitions so fan-out hunters explore different subsystems instead of converging on the same shallow bug. Deterministic grouping of /x-ray entry points by component → .kuzushi/partitions.json, which a hunt coordinator hands to one subagent per partition. Run /x-ray first.

2026-06-100

poc

allsmog/kuzushi-security-plugin

Empirical proof-of-concept for the PoC-ready findings. For each finding /verify marked confirmed-exploitable or inconclusive, synthesize a minimal harness that triggers the bug; a host script then runs it in a sandbox (Docker --network none when present, else a gated local run) and classifies the crash into a proof verdict. Attaches a poc block onto each finding. Requires /verify first.

2026-06-100

name	mem-exploitability
description	Memory-corruption exploitability ASSESSMENT. For each memory-safety finding (systems-hunt / verify), the mem-exploit-analyst agent works the analysis phases — vuln shape, control/offset plausibility, input constraints, mitigation posture (NX/PIE/canary/RELRO/FORTIFY/CFG from build flags + read-only binary inspection) — and assigns an exploitability tier + remediation, attaching an `exploitability` block onto .kuzushi/findings.json. Assessment only — never produces exploit payloads or mitigation bypasses.
context	fork
agent	mem-exploit-analyst
user-invocable	false

Memory-corruption exploitability assessment

Run node "${CLAUDE_PLUGIN_ROOT}/scripts/cmd/mem-exploitability-prepare.mjs" --target "<repo root>" (optionally --input '{"maxCandidates":12}'). It errors if there are no memory-corruption findings. Read the prep's prepPath — candidates[] and the repo mitigations posture.
For each candidate, do the per-candidate walk (vuln shape → control/offset plausibility → constraints → mitigation factor → tier + remediation). Use each candidate's findingFingerprint verbatim. Reason about control; never construct an overwrite or payload.
Write the { candidates: [...] } bundle to the prep's draftPath, then run the assembleCommand (finalize) — it validates tiers + remediation and attaches an exploitability block onto each finding (status unchanged).
Report tier counts, the repo mitigation posture, and the likely-code-exec / control-flow-hijack-plausible findings. Point to /poc for empirical crash proof.

When NOT to use

On non-memory findings (injection, authz, SSRF…) — those don't have a memory-corruption tier.
Before any memory-safety finding exists — run /systems-hunt (or /verify) first.
To produce a working exploit — out of scope by design; this is assessment only. Empirical crash proof is /poc.

Rationalizations to Reject

"It's a memory bug, so it's likely-code-exec." → Tier by the actual control/offset plausibility and mitigation posture; many overflows are crash-only or dos, not code-exec.
"Mitigations are on, so it's not exploitable." → Record the mitigation posture as a factor, not a verdict; NX/PIE/canary raise the bar, they don't always close it.
"I'll sketch a quick ROP chain to prove it." → Never. Reason about control; do not construct overwrites, payloads, or bypasses.