Reverse Engineer
Guide an agent through binary reconnaissance, disassembly, and analysis with IDA, Ghidra, radare2, and related scripting stacks when you need to understand unknown executables.
Overview
Reverse Engineer is an agent skill for the Ship phase that structures binary reconnaissance, disassembly planning, and RE toolchain scripting for IDA Pro, Ghidra, and radare2-style workflows.
Install
npx skills add https://github.com/sickn33/antigravity-awesome-skills --skill reverse-engineerWhat is this skill?
- Four-phase analysis methodology starting with reconnaissance, file ID, metadata, and packer triage
- Covers IDAPython, Ghidra scripting, r2pipe, pwntools, capstone, keystone, unicorn, angr, and Triton
- Actionable goals, constraints, inputs, and verification steps before deep playbook work
- Pointers to implementation-playbook.md for detailed examples when the task needs them
- Community-sourced skill tagged offensive risk—review scope before running against systems you do not own
- Four-phase analysis methodology with Phase 1 reconnaissance broken into four initial triage steps
Adoption & trust: 584 installs on skills.sh; 40.1k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have an unknown or obfuscated binary and no repeatable checklist for triage, tooling, and verification before deeper analysis.
Who is it for?
Solo builders doing authorized security review, malware triage, game mod research, or CTF-style binary puzzles who already use or plan to use mainstream RE tools.
Skip if: General app development, routine debugging of your own source, or any analysis of systems you are not permitted to inspect—skip when the task is unrelated to binary RE.
When should I use this skill?
Working on common RE scripting environment tasks or needing best practices and checklists for binary analysis workflows.
What do I get? / Deliverables
You get clarified goals, phased recon steps, and validated next actions aligned to your RE environment instead of ad-hoc guessing in chat.
- Recon triage notes (type, architecture, strings, imports)
- Packer or obfuscation assessment
- Actionable verification steps before deep dive
Recommended Skills
Journey fit
Reverse engineering sits in Ship because it validates trust and behavior of binaries before you ship, integrate, or run third-party code in production. Security is the canonical shelf for offensive-risk analysis workflows that inspect imports, packers, and control flow rather than everyday feature coding.
How it compares
Use instead of unstructured chat prompts when you need a phased RE methodology; this is a skill playbook, not an automated sandbox or MCP server.
Common Questions / FAQ
Who is reverse-engineer for?
It is for indie and solo developers and security-minded builders who need agent-guided binary analysis using professional RE toolchains and scripting APIs.
When should I use reverse-engineer?
Use it during Ship security work when triaging executables, during Operate incident response when unpacking behavior matters, or during Validate scope when a dependency’s binary behavior is unclear—only on assets you may legally analyze.
Is reverse-engineer safe to install?
The skill is labeled with offensive risk from community source; review the Security Audits panel on this Prism page and your agent permissions before enabling shell or filesystem access.
SKILL.md
READMESKILL.md - Reverse Engineer
# Common RE scripting environments - IDAPython (IDA Pro scripting) - Ghidra scripting (Java/Python via Jython) - r2pipe (radare2 Python API) - pwntools (CTF/exploitation toolkit) - capstone (disassembly framework) - keystone (assembly framework) - unicorn (CPU emulator framework) - angr (symbolic execution) - Triton (dynamic binary analysis) ``` ## Use this skill when - Working on common re scripting environments tasks or workflows - Needing guidance, best practices, or checklists for common re scripting environments ## Do not use this skill when - The task is unrelated to common re scripting environments - You need a different domain or tool outside this scope ## Instructions - Clarify goals, constraints, and required inputs. - Apply relevant best practices and validate outcomes. - Provide actionable steps and verification. - If detailed examples are required, open `resources/implementation-playbook.md`. ## Analysis Methodology ### Phase 1: Reconnaissance 1. **File identification**: Determine file type, architecture, compiler 2. **Metadata extraction**: Strings, imports, exports, resources 3. **Packer detection**: Identify packers, protectors, obfuscators 4. **Initial triage**: Assess complexity, identify interesting regions ### Phase 2: Static Analysis 1. **Load into disassembler**: Configure analysis options appropriately 2. **Identify entry points**: Main function, exported functions, callbacks 3. **Map program structure**: Functions, basic blocks, control flow 4. **Annotate code**: Rename functions, define structures, add comments 5. **Cross-reference analysis**: Track data and code references ### Phase 3: Dynamic Analysis 1. **Environment setup**: Isolated VM, network monitoring, API hooks 2. **Breakpoint strategy**: Entry points, API calls, interesting addresses 3. **Trace execution**: Record program behavior, API calls, memory access 4. **Input manipulation**: Test different inputs, observe behavior changes ### Phase 4: Documentation 1. **Function documentation**: Purpose, parameters, return values 2. **Data structure documentation**: Layouts, field meanings 3. **Algorithm documentation**: Pseudocode, flowcharts 4. **Findings summary**: Key discoveries, vulnerabilities, behaviors ## Response Approach When assisting with reverse engineering tasks: 1. **Clarify scope**: Ensure the analysis is for authorized purposes 2. **Understand objectives**: What specific information is needed? 3. **Recommend tools**: Suggest appropriate tools for the task 4. **Provide methodology**: Step-by-step analysis approach 5. **Explain findings**: Clear explanations with supporting evidence 6. **Document patterns**: Note interesting code patterns, techniques ## Code Pattern Recognition ### Common Patterns ```c // String obfuscation (XOR) for (int i = 0; i < len; i++) str[i] ^= key; // Anti-debugging (IsDebuggerPresent) if (IsDebuggerPresent()) exit(1); // API hashing (common in malware) hash = 0; while (*name) hash = ror(hash, 13) + *name++; // Stack string construction char s[8]; *(DWORD*)s = 0x6C6C6548; // "Hell" *(DWORD*)(s+4) = 0x6F; // "o\0" ``` ### Calling Conventions - **x86 cdecl**: Args on stack, caller cleans - **x86 stdcall**: Args on stack, callee cleans - **x64 Windows**: RCX, RDX, R8, R9, then stack - **x64 System V**: RDI, RSI, RDX, RCX, R8, R9, then stack - **ARM**: R0-R3, then stack ## Security & Ethics ### Authorized Use Only - Security research with proper authorization - CTF competitions and educational challenges - Malware analysis for defensive purposes - Vulnerability disclosure through responsible channels - Understanding software for interoperability ### Never Assist With - Unauthorized access to systems