/find-oep
Smart trace-based OEP finder for packed/protected PE executables. Traces through packer stubs using intelligent stepping, anti-debug evasion, and heuristic OEP detection, then captures a state snapshot at the original entry point.
Claude Code
$ npx -y skills add dariushoule/x64dbg-skills --skill find-oep --agent claude-code
Codex
$ npx skills add dariushoule/x64dbg-skills --skill find-oep -a codex -y
Cursor
$ npx skills add dariushoule/x64dbg-skills --skill find-oep -a cursor -y
Gemini CLI
$ npx skills add dariushoule/x64dbg-skills --skill find-oep -a gemini-cli -y
GitHub Copilot
$ npx skills add dariushoule/x64dbg-skills --skill find-oep -a github-copilot -y
OpenCode
$ npx skills add dariushoule/x64dbg-skills --skill find-oep -a opencode -y
Windsurf
$ npx skills add dariushoule/x64dbg-skills --skill find-oep -a windsurf -y
SKILL.md
find-oep.SKILL.mdname: find-oep
description: Smart trace-based OEP finder for packed/protected PE executables. Traces through packer stubs using intelligent stepping, anti-debug evasion, and heuristic OEP detection, then captures a state snapshot at the original entry point.
allowed-tools: mcp__x64dbg__list_sessions, mcp__x64dbg__start_session, mcp__x64dbg__connect_to_session, mcp__x64dbg__get_debugger_status, mcp__x64dbg__disconnect, mcp__x64dbg__allocate_memory, mcp__x64dbg__write_memory, mcp__x64dbg__read_memory, mcp__x64dbg__set_register, mcp__x64dbg__get_register, mcp__x64dbg__get_all_registers, mcp__x64dbg__disassemble, mcp__x64dbg__assemble, mcp__x64dbg__set_breakpoint, mcp__x64dbg__clear_breakpoint, mcp__x64dbg__list_breakpoints, mcp__x64dbg__step_over, mcp__x64dbg__step_into, mcp__x64dbg__go, mcp__x64dbg__pause, mcp__x64dbg__run_to_return, mcp__x64dbg__set_comment, mcp__x64dbg__set_label, mcp__x64dbg__get_symbol, mcp__x64dbg__eval_expression, mcp__x64dbg__execute_command, mcp__x64dbg__refresh_gui, mcp__x64dbg__get_memory_map, mcp__x64dbg__trace_over, mcp__x64dbg__trace_into, mcp__x64dbg__wait_for_event, AskUserQuestion, Bash, Read, Write, Skill
find-oep
Smart trace-based OEP finder for packed/protected PE executables. Walks through unpacking stages using intelligent stepping, anti-debug evasion, and heuristic OEP detection. Once the OEP is found, captures a state snapshot for downstream use (PE reconstruction, analysis, etc.).
Instructions
1. Gather input and assess target
Ask the user (via `AskUserQuestion`) for any information not already provided:
- **Target path** — absolute path to the packed PE on disk
- **x64dbg path** — absolute path to x64dbg/x32dbg (if not already known)
- **Bitness** — 64-bit or 32-bit (default: 64)
Determine the CIP register name: `rip` for 64-bit, `eip` for 32-bit. Determine the stack pointer register: `rsp` for 64-bit, `esp` for 32-bit. Determine the debugger variant: `x64dbg.exe` for 64-bit, `x32dbg.exe` for 32-bit.
2. Launch the debugger and load the target
Use `mcp__x64dbg__start_session` with:
- `executable_path`: the packed PE path
- `x64dbg_path`: the appropriate debugger binary
Always start a new session for a clean environment. Wait for the debugger to settle — call `mcp__x64dbg__get_debugger_status` and confirm the debuggee is paused at the entry point. If running, call `mcp__x64dbg__pause`.
Record the **session PID** and **x64dbg path** for later reconnection.
3. Initial reconnaissance
Gather information about the packed binary to inform the unpacking strategy:
1. **Capture entry state**: Call `mcp__x64dbg__get_all_registers` to record the initial register state (especially the stack pointer — packers often restore it before jumping to OEP). 2. **Memory map**: Call `mcp__x64dbg__get_memory_map` to identify the module's sections, their protections, and any suspicious characteristics (e.g., sections with write+execute, sections with zero raw size but large virtual size, non-standard section names). 3. **Entry point disassembly**: Disassemble 50–100 instructions from the entry point using `mcp__x64dbg__disassemble` to identify the packer stub pattern. 4. **YARA scan**: Invoke `/yara-sigs` via `Skill("yara-sigs")` to identify the packer and obvious crypto/anti-debug signatures.
- You may rerun this YARA scan if the packer contains self-decrypting code that hides signatures until unpacked.
Summarize findings to the user:
- Identified packer (if recognized)
- Section layout and anomalies
- Entry stub characteristics
- Recommended unpacking strategy
4. Heuristic OEP discovery (core loop)
This is the main unpacking loop. The goal is to trace through the packer stub and identify when execution transfers to the original, unpacked code.
OEP Heuristics
The OEP is likely reached when several of these conditions align:
| Heuristic | Description | |-----------|-------------| | **Section transition** | CIP moves from a packer section (e.g., `.rsrc`, `.aspack`, last section) into the original code section (usually `.text` or the first section) | | **Stack restoration** | ESP/RSP returns to (or near) its initial value from step 3 | | **Common OEP patterns** | Disassembly shows typical compiler entry sequences: `push ebp; mov ebp, esp`, `sub rsp, N`, `call __security_init_cookie`, MSVC/GCC/Delphi/Borland CRT init patterns | | **Large code region** | After writes settle, a large contiguous region of valid-looking code exists in the original code section | | **IAT populated** | The import table region contains valid pointers to API functions |
Stepping strategy
1. **Start at the packed entry point**. Disassemble the current location. 2. **Identify the current phase**:
- *Decode loop*: Repetitive instruction patterns (xor, mov byte, loop/dec+jnz). Set a breakpoint after the loop (on the first instruction following the loop exit) and `go`. If you cannot determine the loop exit, use `mcp__x64dbg__trace_over` with a `break_condition` that detects leaving the loop (e.g., a CIP range check).
- *API resolution*: Calls to `GetProcAddress`, `LoadLibrary*`, hash-based API resolution. Step over these — they are building the IAT.
- *Anti-debug check*: See step 6 for detection and evasion.
- *Inter-module call*: Calls into system DLLs. Step over unless they appear suspicious.
- *Tail jump / OEP transfer*: A `jmp` or `push+ret` that lands in a different section — potential OEP. Verify with the heuristics above.
- *Multi-stage transition*: Decoded stub that itself decodes another layer. Repeat the process.
3. **When in a repetitive region** (same addresses appearing repeatedly):
- Use `mcp__x64dbg__trace_over` with a `break_condition` like `cip < <loop_start> || cip > <loop_end>` to escape the loop efficiently.
- Alternatively, identify the loop counter and set a conditional breakpoint: `mcp__x64dbg__set_breakpoint` with an appropriate condition.
4. **At each significant transition**, disassemble 20–30
Read more
name: find-oep description: Smart trace-based OEP finder for packed/protected PE executables. Traces through packer stubs using intelligent stepping, anti-debug evasion, and heuristic OEP detection, then captures a state snapshot at the original entry point. allowed-tools: mcp__x64dbg__list_sessions, mcp__x64dbg__start_session, mcp__x64dbg__connect_to_session, mcp__x64dbg__get_debugger_status, mcp__x64dbg__disconnect, mcp__x64dbg__allocate_memory, mcp__x64dbg__write_memory, mcp__x64dbg__read_memory, mcp__x64dbg__set_register, mcp__x64dbg__get_register, mcp__x64dbg__get_all_registers, mcp__x64dbg__disassemble, mcp__x64dbg__assemble, mcp__x64dbg__set_breakpoint, mcp__x64dbg__clear_breakpoint, mcp__x64dbg__list_breakpoints, mcp__x64dbg__step_over, mcp__x64dbg__step_into, mcp__x64dbg__go, mcp__x64dbg__pause, mcp__x64dbg__run_to_return, mcp__x64dbg__set_comment, mcp__x64dbg__set_label, mcp__x64dbg__get_symbol, mcp__x64dbg__eval_expression, mcp__x64dbg__execute_command, mcp__x64dbg__refresh_gui, mcp__x64dbg__get_memory_map, mcp__x64dbg__trace_over, mcp__x64dbg__trace_into, mcp__x64dbg__wait_for_event, AskUserQuestion, Bash, Read, Write, Skill
find-oep
Smart trace-based OEP finder for packed/protected PE executables. Walks through unpacking stages using intelligent stepping, anti-debug evasion, and heuristic OEP detection. Once the OEP is found, captures a state snapshot for downstream use (PE reconstruction, analysis, etc.).
Instructions
1. Gather input and assess target
Ask the user (via `AskUserQuestion`) for any information not already provided:
- **Target path** — absolute path to the packed PE on disk
- **x64dbg path** — absolute path to x64dbg/x32dbg (if not already known)
- **Bitness** — 64-bit or 32-bit (default: 64)
Determine the CIP register name: `rip` for 64-bit, `eip` for 32-bit. Determine the stack pointer register: `rsp` for 64-bit, `esp` for 32-bit. Determine the debugger variant: `x64dbg.exe` for 64-bit, `x32dbg.exe` for 32-bit.
2. Launch the debugger and load the target
Use `mcp__x64dbg__start_session` with:
- `executable_path`: the packed PE path
- `x64dbg_path`: the appropriate debugger binary
Always start a new session for a clean environment. Wait for the debugger to settle — call `mcp__x64dbg__get_debugger_status` and confirm the debuggee is paused at the entry point. If running, call `mcp__x64dbg__pause`.
Record the **session PID** and **x64dbg path** for later reconnection.
3. Initial reconnaissance
Gather information about the packed binary to inform the unpacking strategy:
1. **Capture entry state**: Call `mcp__x64dbg__get_all_registers` to record the initial register state (especially the stack pointer — packers often restore it before jumping to OEP). 2. **Memory map**: Call `mcp__x64dbg__get_memory_map` to identify the module's sections, their protections, and any suspicious characteristics (e.g., sections with write+execute, sections with zero raw size but large virtual size, non-standard section names). 3. **Entry point disassembly**: Disassemble 50–100 instructions from the entry point using `mcp__x64dbg__disassemble` to identify the packer stub pattern. 4. **YARA scan**: Invoke `/yara-sigs` via `Skill("yara-sigs")` to identify the packer and obvious crypto/anti-debug signatures.
- You may rerun this YARA scan if the packer contains self-decrypting code that hides signatures until unpacked.
Summarize findings to the user:
- Identified packer (if recognized)
- Section layout and anomalies
- Entry stub characteristics
- Recommended unpacking strategy
4. Heuristic OEP discovery (core loop)
This is the main unpacking loop. The goal is to trace through the packer stub and identify when execution transfers to the original, unpacked code.
OEP Heuristics
The OEP is likely reached when several of these conditions align:
| Heuristic | Description | |-----------|-------------| | **Section transition** | CIP moves from a packer section (e.g., `.rsrc`, `.aspack`, last section) into the original code section (usually `.text` or the first section) | | **Stack restoration** | ESP/RSP returns to (or near) its initial value from step 3 | | **Common OEP patterns** | Disassembly shows typical compiler entry sequences: `push ebp; mov ebp, esp`, `sub rsp, N`, `call __security_init_cookie`, MSVC/GCC/Delphi/Borland CRT init patterns | | **Large code region** | After writes settle, a large contiguous region of valid-looking code exists in the original code section | | **IAT populated** | The import table region contains valid pointers to API functions |
Stepping strategy
1. **Start at the packed entry point**. Disassemble the current location. 2. **Identify the current phase**:
- *Decode loop*: Repetitive instruction patterns (xor, mov byte, loop/dec+jnz). Set a breakpoint after the loop (on the first instruction following the loop exit) and `go`. If you cannot determine the loop exit, use `mcp__x64dbg__trace_over` with a `break_condition` that detects leaving the loop (e.g., a CIP range check).
- *API resolution*: Calls to `GetProcAddress`, `LoadLibrary*`, hash-based API resolution. Step over these — they are building the IAT.
- *Anti-debug check*: See step 6 for detection and evasion.
- *Inter-module call*: Calls into system DLLs. Step over unless they appear suspicious.
- *Tail jump / OEP transfer*: A `jmp` or `push+ret` that lands in a different section — potential OEP. Verify with the heuristics above.
- *Multi-stage transition*: Decoded stub that itself decodes another layer. Repeat the process.
3. **When in a repetitive region** (same addresses appearing repeatedly):
- Use `mcp__x64dbg__trace_over` with a `break_condition` like `cip < <loop_start> || cip > <loop_end>` to escape the loop efficiently.
- Alternatively, identify the loop counter and set a conditional breakpoint: `mcp__x64dbg__set_breakpoint` with an appropriate condition.
4. **At each significant transition**, disassemble 20–30
Other skills on x64dbg-skills.
shellcode-analyzer
Load, unpack, and analyze shellcode in x64dbg. Use this skill when the user wants to analyze shellcode, load a shellcode blob…
state-diff
Compare two state snapshots to identify register and memory changes between two points in time
state-snapshot
Capture a full debuggee state snapshot (all committed memory regions + processor state) to disk for offline analysis
tracealyzer
Trace execution (into or over calls) for N steps or until a condition, then analyze the recorded instruction log
vuln-hunter
Hunt for vulnerabilities in a running debuggee by analyzing imports/exports, triaging attack surface, and iteratively testing for…
More skills from other plugins.
api-security
Use for authorized security assessment of REST, GraphQL, WebSocket, or SOAP APIs, including discovery, authentication,…
abusing-dpapi-for-cred…
Extract and decrypt Windows DPAPI-protected secrets (Credential Manager, browser logins/cookies, Wi-Fi credentials, KeePass keys)…
clean-user-facing-text
Clean and finalize authorized natural-language text intended for readers by auditing suspicious invisible Unicode and rewriting…
Questions about find-oep.
- Which coding agents can use find-oep?
- find-oep installs in Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot, OpenCode and Windsurf with the skills CLI, using each agent's flag shown on this page. Flowy's auto-invocation, which fires a skill when your prompt matches, runs in Claude Code only.

