Execute qualquer Skill no Manus
com um clique

Execute qualquer Skill no Manus com um clique

binary-recon

Estrelas0

Forks0

Atualizado29 de maio de 2026 às 02:51

Read-only static triage of compiled binaries (ELF / PE / Mach-O). Detects them by magic bytes, then surfaces dangerous imported symbols, writable+executable segments, and hardening gaps via on-PATH binutils (nm / readelf / objdump). Assessment only — no execution, no exploit-oriented disassembly. Promotes verdicts into .kuzushi/findings.json (source "binary-recon").

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Executar no Manus

Fonte

allsmog

allsmog/kuzushi-security-plugin

Abrir repositório GitHub Ver repositórios do creator

Download

Executar no Manus

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Analistas de segurança da informaçãoInformática e Matemática·SOC 15-1212

SKILL.md

readonly

name	binary-recon
description	Read-only static triage of compiled binaries (ELF / PE / Mach-O). Detects them by magic bytes, then surfaces dangerous imported symbols, writable+executable segments, and hardening gaps via on-PATH binutils (nm / readelf / objdump). Assessment only — no execution, no exploit-oriented disassembly. Promotes verdicts into .kuzushi/findings.json (source "binary-recon").
context	fork
agent	binary-recon
user-invocable	false

Binary recon

Triage the compiled artifacts a source-only review skips. This is deliberately modest: it tells you what's exposed and how hardened a binary is, and ties that back to the source — it does not write exploits.

Run node "${CLAUDE_PLUGIN_ROOT}/scripts/cmd/binary-recon-prepare.mjs" --target "<repo root>". If it reports no-candidates, there are no binaries to triage — stop.
Read the prep's prepPath. Each candidate is a detected binary with read-only signals (dangerous imports, RWX segments) gathered from whatever binutils were available (toolsUsed). For each signal, decide whether it's a real exposure in context: is the dangerous import reachable with attacker-influenced input? Is the RWX segment a genuine mitigation gap or an expected JIT region? Tie it to the source that produces or invokes the binary where you can.
Write { candidates: [...] } with verdict (finding / candidate / rejected), a binaryClass, a rationale, and evidenceAnchors ({ filePath } = the binary) to the prep's draftPath, then run the assembleCommand.
Report the findings and note these are assessment-grade (hardening/exposure), not proven exploits — escalate real candidates to source-level review.

When NOT to use

On a repo with no compiled binaries (pure source / scripting project).
As an exploitation tool — it never disassembles for gadget hunting or runs the binary. For memory-corruption exploitability use /mem-exploitability.
As a substitute for source review — a signal here is a pointer back to source, not a verdict on its own.

Rationalizations to Reject

"It's just a vendored binary, not our code." → Vendored binaries ship in your artifact and run with your privileges; a backdoored or unhardened dependency is your exposure. Triage it or record why you skipped it.
"nm/readelf weren't installed, so there's nothing to find." → Missing tools means reduced signal, not no risk. Say the triage was magic-only and flag the binary for follow-up rather than implying it's clean.
"A dangerous import exists, so it's a bug" (or the reverse, "…so it's fine"). → An import is a lead, not a verdict. Decide reachability with attacker input before calling it a finding; absence of the symbol doesn't prove safety either.

Mais deste repositório

mesmo repositório

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	binary-recon
description	Read-only static triage of compiled binaries (ELF / PE / Mach-O). Detects them by magic bytes, then surfaces dangerous imported symbols, writable+executable segments, and hardening gaps via on-PATH binutils (nm / readelf / objdump). Assessment only — no execution, no exploit-oriented disassembly. Promotes verdicts into .kuzushi/findings.json (source "binary-recon").
context	fork
agent	binary-recon
user-invocable	false

Binary recon

Run node "${CLAUDE_PLUGIN_ROOT}/scripts/cmd/binary-recon-prepare.mjs" --target "<repo root>". If it reports no-candidates, there are no binaries to triage — stop.
Read the prep's prepPath. Each candidate is a detected binary with read-only signals (dangerous imports, RWX segments) gathered from whatever binutils were available (toolsUsed). For each signal, decide whether it's a real exposure in context: is the dangerous import reachable with attacker-influenced input? Is the RWX segment a genuine mitigation gap or an expected JIT region? Tie it to the source that produces or invokes the binary where you can.
Write { candidates: [...] } with verdict (finding / candidate / rejected), a binaryClass, a rationale, and evidenceAnchors ({ filePath } = the binary) to the prep's draftPath, then run the assembleCommand.
Report the findings and note these are assessment-grade (hardening/exposure), not proven exploits — escalate real candidates to source-level review.

When NOT to use

On a repo with no compiled binaries (pure source / scripting project).
As an exploitation tool — it never disassembles for gadget hunting or runs the binary. For memory-corruption exploitability use /mem-exploitability.
As a substitute for source review — a signal here is a pointer back to source, not a verdict on its own.

Rationalizations to Reject

"It's just a vendored binary, not our code." → Vendored binaries ship in your artifact and run with your privileges; a backdoored or unhardened dependency is your exposure. Triage it or record why you skipped it.
"nm/readelf weren't installed, so there's nothing to find." → Missing tools means reduced signal, not no risk. Say the triage was magic-only and flag the binary for follow-up rather than implying it's clean.
"A dangerous import exists, so it's a bug" (or the reverse, "…so it's fine"). → An import is a lead, not a verdict. Decide reachability with attacker input before calling it a finding; absence of the symbol doesn't prove safety either.