- Status
- Offline
- Joined
- Mar 3, 2026
- Messages
- 779
- Reaction score
- 457
Anyone digging into Unity internals knows the pain—rebuilding the same export resolution and metadata lookup logic for every single project. If you are finally moving your tooling to Rust to escape the fragility of typical C++ glue, this library is a solid foundation.
The Technical Core
il2cpp-bridge-rs isn't a full-blown mod loader; it's a building block. It handles the low-level mess of interacting with the IL2CPP runtime so you can focus on the actual logic of your reverse engineering workflow or runtime diagnostics.
Key Capabilities:
Why Rust for IL2CPP?
Let's be real—interaction with IL2CPP is fundamentally unsafe and pointer-heavy. Rust doesn't magically make the runtime "safe," but it forces structure on the chaos. It allows for better organization of wrappers and isolates the unsafe boundaries, which is a godsend when building complex native injectors or debuggers.
This is an early release, but the architecture is there. It is meant for devs building their own tooling, native mods, or injected libraries who need reliable runtime interaction without the headache of manual export resolution.
Anyone already integrated this into a project for an EAC-protected game or tested the Android bindings?
You cant view this link please login.
The Technical Core
il2cpp-bridge-rs isn't a full-blown mod loader; it's a building block. It handles the low-level mess of interacting with the IL2CPP runtime so you can focus on the actual logic of your reverse engineering workflow or runtime diagnostics.
Key Capabilities:
- Dynamic export resolution from the loaded runtime.
- Metadata cache management for looking up assemblies, classes, and fields.
- Runtime method invocation (both static and instance methods).
- Common Unity object wrappers and metadata dumping.
- Cross-platform support for Windows, Android, Linux, macOS, and iOS.
Why Rust for IL2CPP?
Let's be real—interaction with IL2CPP is fundamentally unsafe and pointer-heavy. Rust doesn't magically make the runtime "safe," but it forces structure on the chaos. It allows for better organization of wrappers and isolates the unsafe boundaries, which is a godsend when building complex native injectors or debuggers.
If you are building a native mod or a runtime debugger, this library simplifies:
- Runtime and thread attachment handling.
- Walking assemblies and classes manually.
- Dumping metadata for inspection and debugging.
- Working with runtime-owned memory without the usual C++ boilerplate.
- Runtime and thread attachment handling.
- Walking assemblies and classes manually.
- Dumping metadata for inspection and debugging.
- Working with runtime-owned memory without the usual C++ boilerplate.
This is an early release, but the architecture is there. It is meant for devs building their own tooling, native mods, or injected libraries who need reliable runtime interaction without the headache of manual export resolution.
Anyone already integrated this into a project for an EAC-protected game or tested the Android bindings?
