Key takeaways
- Cpp2IL can now rebuild Unity IL2CPP metadata even when the file header is encrypted and its sections have been moved around.
- With the metadata restored, an attacker can map it to the game's native code and find important logic much faster.
- Encrypting
global-metadata.datalone is no longer enough. Code, native libraries, metadata and resources need to be protected together.
Cpp2IL is an open-source tool for reverse engineering Unity games built with IL2CPP. A recent update to its Mfuscator support plugin changes how it deals with metadata protected by Mfuscator, a commercial IL2CPP protection tool that encrypts the metadata file and rearranges its layout.
This is one tool adding support for one protection scheme. Still, it's worth paying attention to. Reverse-engineering tools are getting better at reconstructing protected data on their own, and protection that depends on one file staying unreadable is harder to rely on than it used to be.
What changed in Cpp2IL
A common way to protect IL2CPP metadata is to encrypt the file and change its header and section layout. If a tool reads the file using the standard format, it gets the wrong offsets, and strings, types and methods all fail to parse.
The updated Cpp2IL doesn't trust the header. It first tries to recover the XOR key used on the header and work out how that key changes. Then it recalculates where each section should start, based on how string literals, type definitions, fields, methods and assemblies refer to each other. Layouts that don't fit those references get ruled out, and the metadata is rebuilt from what's left.
What global-metadata.dat gives an attacker
In an IL2CPP build, your C# code is converted to C++ and compiled to native machine code. Most of the names are gone from that code. The global-metadata.dat file is where type names, method names, fields and strings still live, and it's what ties the native code back to something a person can read.
Tools like Cpp2IL read the metadata and the native binary together to match methods to their addresses in native code. Once that works, an attacker can search by name instead of guessing, and go straight to things like:
- Reward and settlement logic
- Combat values and damage calculations
- Purchase verification
- Security and integrity checks
That makes memory editing, hooking and bypassing detection a lot quicker to set up.
For more background on IL2CPP reverse engineering, see our earlier posts on how games counter Il2CppDumper and on protecting global-metadata.dat.
Why this matters for live games
Better tooling means cheat makers spend less time getting started, and less time updating their cheats after each patch.
Once cheats are in a live game, other players notice quickly. Rankings and in-game economies get skewed, and people who earned or paid for their progress see it devalued. Players complain, reviews drop, and over time it shows up in retention and revenue.
Why one protected file isn't enough
Mfuscator isn't unusual here. Any protection that depends on a single file staying unreadable can eventually be worked around by a tool built for that purpose.
It's more useful to think about the path an attacker takes. Metadata, native code, packaged resources and runtime data all help each other make sense. If those links are weakened in several places, recovering one piece doesn't give the attacker the full picture.
How JikGuard protects Android game builds
JikGuard protects Android games built with Unity, Cocos and Unreal Engine. Protection is applied to your APK or AAB at build time and covers several parts of the package:
- Code: Helps make unauthorized extraction or modification of supported packaged game code harder.
- Native components: Covers supported native libraries and components, including Android
.sofiles packaged with the game. - Engine metadata: Covers supported game-engine metadata, including Unity global-metadata files where applicable.
- Packaged resources: Helps protect supported packaged resources, such as Unity AssetBundles, against extraction or unauthorized modification.
When the game runs, JikGuard's client-side protection helps raise the cost of common tampering, runtime manipulation such as memory modification and hooking, and play in high-risk environments.
Because several parts of the build are covered, a clue recovered from one part is less useful on its own. Your signing keys stay with your team throughout.
Client-side protection should sit alongside server-side validation, not replace it.
Summary
Cpp2IL's update shows how quickly reverse-engineering tools adapt to new protection. Encrypting the metadata file is still worth doing, but it shouldn't be the only thing between an attacker and your game logic.
To see what JikGuard covers, take a look at Game Code & Asset Protection and Anti-Cheat & Anti-Hack, or start with the documentation.