Reverse Engineering

Reverse engineer binaries, APIs, protocols, and workflows with evidence ladders, interface maps, and falsifiable hypotheses.

Security Scan

The skill is an instruction-only reverse‑engineering workflow that is internally consistent: it requests no credentials, has no install steps, and confines persistent data to a user-controlled local folder while requiring explicit approval for invasive actions.

Purpose & Capability

Name and description match the actual contents: a structured reverse‑engineering method, templates, and guidance. Requested resources (a local workspace ~/reverse-engineering/) are proportional to the purpose.

Instruction Scope

SKILL.md and supporting files prescribe read-only-first rules, explicit user approval before invasive or credential-bearing steps, and local-only storage by default. There are no instructions to read unrelated system files, contact external endpoints, or exfiltrate data.

Install Mechanism

No install spec or code files that would write or execute code on disk; this is instruction-only, which minimizes risk and is appropriate for the stated purpose.

Credentials

The skill declares no required environment variables, binaries, or credentials. The only persistent artifact is an optional local workspace (~/reverse-engineering/) which the skill explicitly asks permission to create and populate.

Persistence & Privilege

The skill stores durable notes and session files in a single user-controlled directory and requires confirmation before the first persistent write. always is false and there is no attempt to modify other skills or global agent settings.

Assessment

This skill appears coherent and reasonable. Before installing, confirm you are comfortable with the agent creating a ~/reverse-engineering/ workspace and storing notes there, and never provide credentials or access to production systems unless you explicitly authorize a specific, narrowly scoped, safe step. Remember reverse engineering can be dual‑use—only use this on targets you are authorized to analyze and keep sensitive samples local unless you explicitly approve sharing them.

When to Use

User needs to understand something opaque, undocumented, legacy, or partially broken. Agent handles behavioral tracing, artifact mapping, hypothesis testing, and concise documentation for binaries, APIs, file formats, protocols, devices, and human workflows.

Architecture

Memory lives in ~/reverse-engineering/. If ~/reverse-engineering/ does not exist, run setup.md. See memory-template.md for structure.

~/reverse-engineering/
├── memory.md          # durable preferences, approvals, and common target types
├── current-target.md  # active engagement snapshot
├── targets/           # one file per target or system
└── artifacts/         # traces, decoded notes, and reproduction snippets

Quick Reference

Use these files on demand instead of loading the whole method every time.

Topic	File
Setup guide	setup.md
Memory template	memory-template.md
TRACE protocol	protocol.md
Confidence model	evidence-ladder.md
Surface mapping	interface-map.md
Deliverable templates	deliverables.md
Safety boundaries	boundaries.md

Requirements

• Authorized access to the target, samples, and environment being analyzed
• A clear statement of whether the target is production, staging, or an offline copy
• Explicit user approval before any invasive, destructive, or credential-bearing step

Core Rules

1. Bound the job before probing

• Name the target, desired outcome, available artifacts, and operational boundary first.
• Ask what is allowed: read-only inspection, replay, instrumentation, decompilation, fuzzing, or patching.
• If the boundary is unclear, default to the safest read-only path.
• Before the first persistent write, state what will be stored locally and ask for permission.

2. Run the TRACE loop from protocol.md

• Triage the target.
• Record observable behavior.
• Abstract hypotheses.
• Challenge each hypothesis with the smallest useful test.
• Explain the result in user-facing language.

3. Separate evidence, inference, and guess

• Tag every claim using the ladder in evidence-ladder.md.
• Never blur "observed" with "likely" or "possible."
• When certainty is low, say what would raise confidence instead of pretending to know.

4. Map surfaces before internals

• Build the interface inventory from interface-map.md before writing an implementation story.
• Start from inputs, outputs, states, side effects, and trust boundaries.
• Reverse engineering is faster when the outer contract is stable before diving deeper.

5. Prefer minimal, reproducible probes

• Use the smallest sample, trace, packet, call, or binary slice that can prove or disprove a hypothesis.
• Keep every probe replayable and attributable.
• If a result cannot be reproduced, it is a clue, not a conclusion.

6. Deliver models, not raw notes

• Every session should end with concrete outputs from deliverables.md: target brief, interface map, hypothesis ledger, reproduction note, and remaining unknowns.
• Optimize for what the user can act on next: debug, reimplement, migrate, document, or secure.
• Good reverse engineering compresses complexity without hiding uncertainty.

Common Traps

These failures usually waste the most time or create false confidence.

Trap	Why It Fails	Better Move
Jumping straight to decompilation	You lose the external contract and context	Start with behavior, interfaces, and captured artifacts
Treating logs as truth	Logs reflect one code path and one viewpoint	Cross-check with traces, outputs, and controlled inputs
Reverse engineering the whole system	Scope explodes and confidence drops	Pick one question, one layer, and one target surface
Confusing correlation with mechanism	Similar timings or names can mislead	Design a falsifiable probe before concluding
Keeping findings in loose notes	Knowledge becomes untestable and unreusable	Convert findings into deliverables with evidence tags
Poking live systems casually	You create risk and destroy signal	Prefer offline copies, captures, and explicit approvals

Security & Privacy

Data that leaves your machine:

• Nothing by default.
• Only user-approved samples or public documentation if the task explicitly requires external lookup.

Data that stays local:

• Preferences and engagement notes in ~/reverse-engineering/
• Captured traces, decoded notes, and reproduction snippets kept in the workspace or the local reverse-engineering folder

This skill does NOT:

• Steal credentials, bypass authorization, or hide activity
• Run exploit chains on production targets by default
• Claim certainty without evidence
• Persist sensitive data outside the documented local folder
• Create durable local memory without first telling the user what will be stored

Related Skills

Install with clawhub install <slug> if user confirms:

• analysis — structure ambiguous problems and turn raw evidence into decisions
• api — reason about endpoints, payloads, contracts, and integration behavior
• architecture — model system boundaries, components, and data flow once the target is understood
• bash — build small inspection and replay loops for traces, logs, and artifacts
• cybersecurity — evaluate trust boundaries, attack surface, and safe handling of sensitive targets

Feedback

• If useful: clawhub star reverse-engineering
• Stay updated: clawhub sync