Investigate supplied game binaries, protection components, drivers, dumps, and traces through reproducible binary analysis. Use for repository resource selection, PE/symbol inspection, disassembly and decompilation, control/data-flow reconstruction, build comparison, obfuscation classification, and interface evidence with IDA, Ghidra or debuggers. Match tool scope to the artifact and produce versioned findings with addresses, provenance, uncertainty and defensive implications.
60
71%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Passed
No findings from the security scan
Fix and improve this skill with Tessl
tessl review fix ./.claude/skills/reverse-engineering/SKILL.mdThis skill covers evidence-driven analysis of game clients, protection modules, drivers, and memory artifacts. Use static and observed behavior to reconstruct interfaces and trust boundaries, while documenting how protection, obfuscation, or instrumentation limits the conclusions.
Treat performance, stealth, coverage, and compatibility claims as
target/version-specific. Record the binary hash, tool version, configuration,
environment, and observed evidence; use
research-rigor for consequential conclusions.
For native Linux or Proton context, first use linux-platform-security. For diagnostic reports from owned test builds, use robustness and triage.
Preserve the sample hash, provenance, architecture, image layout, tool version, analysis configuration, and symbol identity. Keep file offsets, RVAs, and runtime addresses distinct, including relocation assumptions in disk/memory comparisons. Match symbols to the actual binary; public and private symbol sets offer different information. PE format, Symbols and symbol files
Decompiler output is a reconstruction. Validate inferred types, names, prototypes, and function boundaries against instructions, ABI constraints, and available observations. Ghidra's instruction semantics and p-code model are useful for understanding why displayed C is not recovered source. Ghidra language documentation, Ghidra analysis guide
Classify the question before selecting an analysis mode:
| Question | Evidence to develop | Limit to state |
|---|---|---|
| Interface abuse | Input origin, callers, required privilege, validation and protected resource | Reachable code is not proof of invocation or abuse |
| Integrity tampering | Independently acquired comparison data and collector trust | A compromised or incomplete collector can distort results |
| Packing/obfuscation | Representation changes and uncertainty in recovered structure | Obfuscation alone does not establish maliciousness |
| Anti-analysis behavior | Conditions associated with differing execution | Observation coverage may be limited by the environment |
| Security-relevant binary change | Semantic differences and affected trust boundary | Compiler, library, and layout changes can dominate a diff |
Report supporting addresses/artifacts and explain each inference. An imported API, reachable path, and observed call are distinct findings. Preserve missing symbols, incomplete dumps, generated code, and unexecuted paths as limitations. Sources in this section were reviewed on 2026-09-09.
Choose resources by artifact and evidence need: binary interpretation, bounded debugger observations, build comparison, or offline dump parsing. Read repository resources when selecting a project or locating the matching README family.
- Cheat Engine: Pattern scanning, value searching
- ReClass.NET: Structure reconstruction
- Process Hacker: System analysis- KsDumper: Kernel-space process dumping
- PE-bear: PE file analysis
- ImHex: Hex editor for REException-driven instrumentation observes selected execution points while changing some combination of code, memory permissions, exception handling, state or timing. Treat the resulting trace as an observation under those conditions. A static control-flow graph or a smaller modification footprint does not establish a universally safer or more complete strategy.
For owned test programs, assess:
DynamoRIO's transparency documentation explains state, resource, synchronization and timing concerns for its own clients. It supports these review dimensions; it does not validate the ad hoc exception instrumentation previously described here. Sources reviewed: 2026-09-09.
- Runtime call graph generation with register context at each edge
- Divergence testing: compare traces across different inputs/environments
→ Quickly locates input validation, anti-debug, anti-tamper trigger points
- Deobfuscation: resolve indirect branches observed under covered executions;
completeness requires additional path exploration or proof
- Hot path analysis, branch coverage measurement
- Report measured tracing overhead for the exact workload, collector and
environment; preserve timeouts and observation-induced failures
- Portable to other architectures: ARM (UDF), RISC-V (illegal instruction)A user-mode application can manage guest partitions and virtual processors through Windows Hypervisor Platform, backed by the Windows hypervisor. This is not the same as running the hypervisor inside that process, forcing all guest code to execute in user mode, or gaining arbitrary control of the running host kernel. Microsoft WHP API
For an existing analysis trace, record host/guest boundaries, guest execution state, modeled memory/devices, enabled capabilities and the actual exit reason. A page-access exit can support a finding about that access under the configured policy; it does not provide complete instruction or edge coverage. The documented exit enumeration has no generic syscall exit: do not assume every guest system call automatically transfers control to the analysis application. Microsoft exit contexts
Match OS/SDK/architecture and nested-environment support to the particular API and tool. Use the Windows WHP contract for version and capability details. Preserve unmodeled scheduler, device, timing and concurrency effects, along with unsupported instructions and missing trace intervals. Review semantic fidelity against an owned baseline before drawing conclusions from a modeled execution. Sources reviewed: 2026-09-09.
GameAssembly.dll (IL2CPP) or managed DLLs1. Identify protections (packer, obfuscator, anti-cheat)
2. Determine game engine and version
3. Collect symbol information if available
4. Map out key modules, callbacks, and trust boundaries1. Locate target functionality
2. Trace execution flow
3. Document structures, memory artifacts, and relationships
4. Correlate IOCTLs, callbacks, and runtime checks- Linear MBA: e.g., x + y = (x ^ y) + 2*(x & y)
- Polynomial MBA: higher-degree expressions over boolean/arithmetic mix
- Tools: SSPAM, MBA-Blast, SiMBA for simplification
- Common in: VMProtect, Themida, custom LLVM passes- OLLVM-style: many protected basic blocks routed through a dispatcher loop
- Recovery: symbolic execution, pattern matching, deobfuscation passes
- Tools: D-810 (IDA), de-ollvm scripts, SATURN
- Variants: nested dispatchers, encrypted state variables- Invariant conditions injected to confuse static analysis
- Number-theoretic (x² mod 4 ∈ {0,1}), pointer-aliasing based
- Detection: abstract interpretation, SMT solvers (Z3)VMProtect / Themida / Code Virtualizer:
- Custom bytecode VM with randomized opcode set per build
- Handler table dispatch loop: fetch → decode → execute
- Devirtualization approaches:
- Trace-based: record handler execution, lift to IR
- Pattern-based: identify handler semantics by structure
- Symbolic: concolic execution through VM dispatch
- Tools: VMPAttack, NoVmp, Oreans UnVirtualizer, vtil- Lift machine code to compiler IR (LLVM IR, VEX, ESIL)
- Enables compiler-level optimization passes for deobfuscation
- Tools: McSema, remill, RetDec, Binary Ninja MLIL/HLILCategories found in README (> IDA Plugins, 150+ entries):
- Decompiler enhancers: HexRaysPyTools, HRDevHelper
- Type recovery: ClassInformer, auto_struct
- Signature: FLIRT, Lumina, IDA Signature Database
- Scripting: IDAPython, IDC, LazyIDA
- Visualization: IDAGraph, Lighthouse (coverage)
- Anti-obfuscation: D-810 (MBA), de-ollvm, Patfinder
- Game-specific: SDK loaders, structure importers- Sidekick, snippets, type libraries
- HLIL-based analysis scripts
- Custom architectures and loaders
- Headless analysis for batch processing- GhidraScript (Java/Python), Ghidra extensions
- Ghidraaas (Ghidra-as-a-Service)
- Type importers, signature matchers
- Firmware analysis (SVD loader, embedded)- r2pipe scripting (Python, JS, Rust)
- iaito: official radare2 Qt GUI
- r2ghidra: Ghidra decompiler integration
- r2dec: lightweight decompiler- SwishDbgExt, WinDbgX
- Time Travel Debugging (TTD) extensions
- !analyze extensions, custom formatters
- Kernel debugging helpers- ScyllaHide (anti-anti-debug)
- TitanEngine, x64dbgpy
- Trace plugins, pattern scanners
- Conditional breakpoint scripts- Mono/IL2CPP helpers
- Auto-assembler templates
- Structure dissectors
- Pointer scanner extensionsThe README's MCP server section and RE tool ecosystem now include
AI-assisted reverse engineering through Model Context Protocol:
- IDA MCP: AI agent controls IDA Pro (rename, annotate, navigate)
- Ghidra MCP: AI agent queries Ghidra decompilation and PCODE
- Binary Ninja MCP: AI agent interacts with Binary Ninja API
- radare2 MCP: AI agent drives r2 sessions via r2pipe
- x64dbg MCP: AI agent controls live debugging sessions
Workflow: LLM ↔ MCP server ↔ RE tool, enabling natural-language
queries like "find all functions calling CreateRemoteThread" or
"rename this function based on its decompiled logic"Tools for comparing binary versions (patch analysis, vulnerability research):
- BinDiff (Google): graph-based structural comparison
- Diaphora: IDA-based program comparison; matching quality requires validation
- ghidriff: Ghidra-based diffing, command-line and scriptable
- DarunGrim: patch analysis focused differ
- turbodiff: lightweight IDA diffing plugin
Use cases in game security:
- Tracking anti-cheat driver updates between versions
- Reviewing changed behavior and trust-boundary assumptions in supplied builds
- Comparing obfuscated builds to isolate logic changesDiaphora's maintainer documentation describes an IDA-based diffing tool; a comparative quality ranking requires a specified benchmark and independently checked matches. Preserve tool/IDA versions, both input hashes, architecture, compiler/optimization changes and unmatched functions. Similarity scores and decompiled differences are candidate evidence; corroborate a claimed semantic change before assigning security impact. Source reviewed: 2026-09-09.
- IsDebuggerPresent / CheckRemoteDebuggerPresent
- NtQueryInformationProcess (ProcessDebugPort, ProcessDebugFlags, ProcessDebugObjectHandle)
- NtSetInformationThread (ThreadHideFromDebugger)
- PEB.BeingDebugged, PEB.NtGlobalFlag, heap flags
- INT 2D, INT 3 scanning, OutputDebugString tricks
- Timing checks: rdtsc, QueryPerformanceCounter, GetTickCount64
- TLS callbacks for early detection
- Exception-based: unhandled exception filter, VEH chain inspection
- Parent process checks (csrss.exe verification)
- Self-debugging: NtCreateDebugObject- KdDebuggerEnabled / KdDebuggerNotPresent
- Debug register (DR0-DR7) monitoring and clearing
- KPROCESS.DebugPort zeroing
- NMI callbacks for debugger detection
- Hardware breakpoint detection via context inspection- ScyllaHide: comprehensive anti-anti-debug (x64dbg/IDA/standalone)
- TitanHide: kernel-mode debugger hiding
- HyperHide: hypervisor-based anti-debug bypass
- SharpOD: OllyDbg anti-anti-debug pluginLoad repository resources for this domain's resource choices and evidence outputs. Use shared repository navigation for local discovery layers, case-sensitive paths, missing snapshots and current upstream verification. Generated summaries are discovery aids, not independent evidence.
The compiled reverse-engineering overview can help locate related material; trace consequential claims to their underlying source.
Use the following repository sources directly when applying this skill. Prefer available local files for discovery and scoped historical inspection; use the raw URLs when the collection is not installed locally. These entrypoint details are retained here so source lookup does not depend on loading another skill.
Start with wiki/index.md for topical synthesis and cross-project connections. Wiki schema describes its structure. Generated wiki pages are discovery aids; follow their original citations before adopting technical claims.
Raw catalog: wiki/index.md. For this domain, read wiki/overviews/reverse-engineering.md. Raw URL: reverse-engineering overview.
A direct project question can start with its README entry or description below; reading the entire wiki is unnecessary.
README.md contains the collection's actual categories, subcategories, project URLs and short descriptions. Find the relevant category and retain the original URL, including any specific file or revision suffix.
Raw index: README.md.
For a concise project summary, look for the actual local path:
description/{owner}/{repo}/description_en.txt
https://raw.githubusercontent.com/gmh5225/awesome-game-security/refs/heads/main/description/{owner}/{repo}/description_en.txtExample: bgfx description. Extract owner/repository from the original GitHub project URL, omitting a .git suffix. Resolve existing path casing before constructing a local/raw path. Descriptions are generated summaries, not independent verification. If absent or inaccessible, use the README entry, relevant archive or original project.
For deeper inspection of an available captured source tree, locate:
archive/{owner}/{repo}.txt
https://raw.githubusercontent.com/gmh5225/awesome-game-security/refs/heads/main/archive/{owner}/{repo}.txtExample: bgfx archive. Prefer inspecting the relevant portion of an existing archive over re-cloning merely to inspect the same captured material. Archives may exclude files, use fallback extraction or contain truncation; they are not guaranteed complete checkouts. Record any upstream revision evidence and included-file limits. If missing or insufficient, follow the README's original upstream URL.
For a specific project, locate its README identity, use a description or wiki page for orientation when helpful, then inspect the relevant archive/source artifact for the question. For current compatibility or exact implementation, verify the matching upstream documentation, release or immutable source revision. Keep the collection revision and capture/generation dates separate from the upstream version. Multiple generated layers from one source are not independent corroboration, and missing archive content does not establish upstream absence.
The per-domain resource guide above helps choose useful artifacts. Shared repository navigation adds the optional read-only indexer, case-ambiguity handling and maintenance details; it supplements this Data Source section rather than replacing it.
c7e4d3f
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.