Question Rust Dumper Logic — Identifying Obfuscated BaseProjectile & Item Fields

[byte_corvus]

Tired of hitting a wall while trying to build a reliable dumper for Rust? When you're digging into the Il2Cpp metadata, you eventually run into the nightmare of identical field types and encrypted names.

The core of the problem lies in classes like BaseProjectile and Item. You have fields like hipAimConeOffset, hipAimConeScale, sightAimConeOffset, and sightAimConeScale that all share the same protection level and type. The same goes for Item stats like health, max_health, and amount. If the names are stripped or obfuscated, traditional string-based dumping is useless.

Methods for Reliable Field Detection:

1. Field Ordering: In many Unity versions, the field order in the metadata remains consistent between minor game updates. If you identify one 'anchor' field that isn't obfuscated, you can calculate others by their relative position.
2. Cross-Referencing Method Logic: Don't just look at the fields. Check the property getters. Even if the field name is garbage, the IL/Assembly code for get_hipAimConeScale often has a unique signature or references specific constants that differentiate it from other cone offsets.
3. String Literal Anchors: Scan for methods that use these fields and also contain hardcoded strings (like error logs or UI labels). These can act as pointers to the correct field offsets.
4. Type Sequence Analysis: Map out the sequence of types in the class. If Item has a specific sequence of float, float, int surrounded by unique types, that pattern can be your signature.

Spoiler: Technical Context

Rust's reliance on Il2Cpp means most of the 'meat' is in the

GameAssembly.dll

. If you're building an auto-dumper, you should be looking at parsing the method bytecodes rather than just relying on the

global-metadata.dat

, as developers frequently mess with the metadata to break public tools.

How are you guys handling the field collision in your current dumper builds?