mcpField
R
reverse-engineer

reverse-engineer

github.com/rmyndharisSecurity1.9k70 installsUpdated 2w ago
Repository

About reverse-engineer

reverse-engineer is a guidance skill for reverse-engineering workflows, intended for security researchers, CTF participants, and software analysts. It organizes work into reconnaissance, static and dynamic analysis, and documentation, with coverage of common scripting environments.

Key features

  1. 01Covers common reverse-engineering scripting environments
  2. 02Outlines file reconnaissance and initial triage
  3. 03Guides static analysis and cross-referencing
  4. 04Structures dynamic analysis and execution tracing
  5. 05Emphasizes authorized analysis and validation

Use cases

  1. 01Analyze binaries in authorized testing
  2. 02Study programs in CTF challenges
  3. 03Inspect malware for defensive purposes
  4. 04Document closed-source library behavior

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/rmyndharis/antigravity-skills --skill reverse-engineer

After installing, type/reverse-engineerin Claude Code to confirm it loaded.

Details

From the project README

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.

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
// 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
  • Creating malware for malicious purposes
  • Bypassing software licensing illegitimately
  • Intellectual property theft
  • Any illegal activities

Example Interactions

CTF Binary Challenge
User: "I have a CTF binary that asks for a password. How do I approach this?"

Response: Let me guide you through the analysis:

1. First, identify the binary type:
   $ file challenge
   $ checksec --file=challenge

2. Load in Ghidra/IDA and find main()

3. Look for:
   - String comparisons (strcmp, memcmp)
   - Crypto functions (xor loops, constants like 0x5A827999)
   - Input validation logic

4. Set breakpoints on comparison functions in GDB:
   $ gdb ./challenge
   (gdb) break strcmp
   (gdb) run

5. Examine memory at comparison point to see expected value
Library Analysis
User: "I need to understand how this closed-source DLL handles authentication"

Response: For authorized analysis of the DLL:

1. Static analysis:
   - List exports: dumpbin /exports library.dll
   - Find auth-related functions by name patterns
   - Load in IDA/Ghidra, analyze exported functions

2. Dynamic analysis:
   - Hook API calls with Frida
   - Monitor network traffic
   - Trace function parameters

3. Documentation:
   - Document function signatures
   - Map data structures
   - Note any security considerations

Comments

Markdown supported