Analyze Unreal, Unity, Source, Godot, and custom engine trust boundaries and select matching repository resources. Use for engine/build identification, full source versus C# reference subsets, version-matched demos, editor versus shipped plugins, reflection and object lifecycles, Mono/IL2CPP, asset schemas, and replication ownership. Produce a versioned artifact and boundary map; route transport authority, release trust, and graphics measurements to their dedicated skills.
64
76%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Low
Low-risk findings worth noting
Fix and improve this skill with Tessl
tessl review fix ./.claude/skills/game-engine/SKILL.mdThis skill covers game engine development resources from the awesome-game-security collection, including both commercial (Unreal, Unity) and open-source engines.
When choosing resources from this repository, read the engine resource guide for source subsets, versioned demos, editor integration, and serialized-asset readers.
Engine globals, object layouts, metadata formats, and helper APIs vary by engine
branch, build configuration, platform, and game modifications. Verify the exact
version and binary artifacts; use
research-rigor before generalizing signatures or
offsets.
For tick/frame distinctions, prediction, replication ordering and replay limitations, use time and replay evidence.
Use game-server-security for authority, sessions, inventory and purchases, and game-supply-chain-security for build, update and mod-distribution trust. For owned-build diagnostic reports, use robustness and triage.
Baseline the engine branch, game build/hash, platform/ABI, scripting backend, stripping configuration, symbol availability, and plugin versions. Separate reflected metadata, native/managed execution, serialized assets, plugins, and client/server replication; each exposes a different research surface.
Describe attack scenarios by the boundary that must fail: untrusted content accepted by an importer, a plugin granted in-process execution, or client assertions accepted as authoritative game state. Correlate asset provenance, plugin inventory, owned-build diagnostics, serialization checks, and server validation evidence. Engine identification or object discovery alone does not establish compromise.
Report the affected boundary, prerequisite, artifact, observed result, benign controls, and version-dependent limits. Sources above were reviewed on 2026-09-09.
Game Engine > GuideGame Engine > SourceGame Engine Plugins:UnrealGame Engine Plugins:UnityGame Engine Plugins:GodotGame Engine Plugins:LumixGame Engine DetectorCheat > SDK CodeGenCheat > Game Engine Explorer:UnrealCheat > Game Engine Explorer:UnityCheat > Game Engine Explorer:SourceAnti Cheat > Game Engine Protection:UnrealAnti Cheat > Game Engine Protection:UnityAnti Cheat > Game Engine Protection:SourceGame Develop > MCP server- Learning resources and tutorials
- Architecture documentation
- Best practices and style guides- Complete engine implementations
- Subsystem references (renderer, physics, audio)
- Plugin and extension examples- ImGui integration for debug UIs
- Scripting language bindings (Lua, .NET)
- Editor tool pluginsWhen researching engines for security analysis or development:
1. Identify UE version from binary signatures
2. Inject Dumper-7 into running game process
3. SDK output: C++ headers with UObject hierarchy
4. Key structures: UObject, FName, UClass, UFunction, UProperty
5. Generated SDK enables: property access, function calls, blueprint hooks
6. Alternative tools: UnrealDumper, UE4SS (live scripting + SDK dump)1. Locate global-metadata.dat + GameAssembly.dll (or libil2cpp.so)
2. Run IL2CPPDumper → outputs: dump.cs, il2cpp.h, script.json
3. Load generated headers into IDA/Ghidra for symbol recovery
4. Key structures: Il2CppClass, MethodInfo, FieldInfo, Il2CppType
5. For Mono builds: directly decompile Assembly-CSharp.dll with dnSpy1. Walk ClientClass linked list from CHLClient
2. For each class, enumerate RecvTable → RecvProp entries
3. Build offset map: class name → property name → offset
4. Example: CCSPlayer → m_iHealth → 0x100
5. Tools: hazedumper, source2gen (Source 2)Core hierarchy:
UObject → UField → UStruct → UClass
UObject → AActor → APawn → ACharacter → APlayerCharacter
Key globals:
GUObjectArray / GObjects: registered UObject slots; lifecycle and reachability
filtering are still required
GNames / FNamePool: name storage; symbol and structure names vary by UE version
GWorld (UWorld*): current world context
GEngine (UEngine*): engine singleton
Memory layout:
Common UObject fields include VTable, flags, internal index, class, name, and
outer pointers; order, packing, and presence are build-specific
Reflected property offsets come from the version-specific class metadataCore structures:
Il2CppDomain → Il2CppAssembly → Il2CppImage → Il2CppClass
Il2CppClass: fields, methods, vtable, static_fields pointer
Key patterns:
il2cpp_domain_get() → domain singleton
il2cpp_class_from_name() → class lookup by namespace + name
il2cpp_runtime_invoke() → call managed methods from native
Metadata:
global-metadata.dat contains string pool, type definitions, method signatures
Encrypted metadata in some protected games (requires custom decryptor)Core systems:
Entity list: IClientEntityList → GetClientEntity(index)
ConVar system: ICvar → FindVar("sv_cheats")
NetVars: RecvTable hierarchy for network-replicated properties
Key interfaces (accessed via CreateInterface export):
IVEngineClient, IClientEntityList, IEngineTrace
ISurface, IPanel (for overlay rendering in Source)The README's > MCP server subcategory includes servers relevant
to game engine workflows:
- Unreal Engine MCP: AI agent controls UE editor (spawn actors, modify properties, blueprints)
- Unity MCP: AI agent interacts with Unity editor and C# scripting
- Godot MCP: AI agent controls Godot editor and GDScript
These complement the RE-focused MCP tools (see reverse-engineering skill)
by enabling AI-assisted game development and rapid prototyping.For game security research, understanding engine internals helps with:
For repository selection, load the engine resource guide on demand. Use shared repository navigation for local lookup, casing, missing snapshots, and current-source verification. The compiled engine overview is a discovery map; generated summaries are not independent evidence of capability or behavior.
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/game-engine.md. Raw URL: game-engine 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.