Run any Skill in Manus with one click

binary-recon

Stars0

Forks0

UpdatedMay 29, 2026 at 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").

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

allsmog

allsmog/kuzushi-security-plugin

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Information Security AnalystsComputer and Mathematical Occupations·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.

More from this repository

same repository

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.