Inspect Unity Artifacts

Inspect Unity Artifacts

Overview

Classify the player platform, Unity version, and scripting backend before selecting managed or native analysis. Preserve relationships among the player, data directory, metadata, libraries, symbols, and assets.

Read references/unity-artifact-analysis.md for common layouts, backend decisions, IL2CPP evidence, asset boundaries, and official sources.

Workflow

1. Preserve the complete build shape.

   • Record container and member hashes, platform, architecture, executable, data directory, Unity version clues, timestamps, symbols, and acquisition source.
   • Keep file relationships and relative paths intact in the working copy.
   • Classify the input as original player material, copied build content, extracted content, or a reconstructed/exported project. Record the extraction or reconstruction tool and version when known.

2. Identify the scripting backend.

   • Managed or Mono clues: Managed/, runtime libraries, and assemblies such as Assembly-CSharp.dll.
   • IL2CPP clues: native GameAssembly or platform equivalent plus global-metadata.dat and Unity player data.
   • Record mixed, stripped, obfuscated, or incomplete cases instead of forcing a choice.

3. Inventory code artifacts.

   • Managed: assembly identities, references, PDBs, target/runtime clues, generated code, and engine assemblies.
   • IL2CPP: player and native-library identity, metadata identity and version clues, symbols, architecture, exports, registration and metadata relationships, and platform-specific signing or Mach-O context.

4. Inventory data and resources.

   • Record scenes, serialized assets, resource archives, streaming assets, plug-ins, bundles, and package or catalog clues.
   • Keep asset parsing separate from code-behavior claims.

5. Choose the analysis path.

   • Use inspect-dotnet-assemblies for managed assemblies.
   • Use native and platform workflows for IL2CPP-generated code and the player.
   • Correlate metadata and native functions with exact tool versions and record generated names as tool output.

6. Preserve cross-artifact mappings.

   • Record which metadata record, managed identity, generated name, symbol, native function, asset, or scene supports each relationship.

7. Hand Unity project authoring, builds, profiling, package repair, or source changes to game-dev-skills.

Guardrails

• Do not analyze one managed assembly without preserving its dependency and build context.
• Do not promote a reconstructed project's ProjectVersion.txt, managed directory, or generated project layout into a claim about the original player unless it is corroborated against original build artifacts.
• Do not treat IL2CPP-generated pseudocode as recovered C# source.
• Do not assume metadata and native libraries from different builds can be combined.
• Do not run an untrusted player as an implied inspection step.
• Do not conflate asset extraction with permission to redistribute the assets.

Output

Return build manifest, platform and Unity version clues, scripting-backend classification, code and asset inventories, symbol state, chosen workflow, cross-artifact mappings, uncertainty, and next check.