Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

mem-exploitability

Étoiles0

Forks0

Mis à jour29 mai 2026 à 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.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

allsmog

allsmog/kuzushi-security-plugin

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Analystes en sécurité de l'informationProfessions informatiques et mathématiques·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.

Plus depuis ce dépôt

même dépôt

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.