You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In addition to the Il2Cpp native exports, there are a large number of helper methods created during the Il2Cpp conversion. These methods can be detected with disassembly analysis. Ideally, we could:
Detect them by analyzing calls from other methods.
This detection can be used recursively to find all the helper methods.
Analyze the calls and method content to build a method signature.
This may involve injecting additional fixed-size structs for unknown parameter types.
Assign the method a stable name and inject it under a static class like Cpp2ILInjected.CppNativeMethods.
In doing this, we can expand our capabilities in other areas
Call Analysis will report less "unknown" methods.
Attribute Injection will be able to generate an AddressAttribute for each of these disassembled methods.
Il2CppInterop could generate a usable wrapper for these methods allowing them to be called from managed code.
They could be patched with Harmony if desirable, or natively since the address is known and the function parameters are blittable.
Since they would have stable names, they could even be renamed with a deobfuscation map.
The text was updated successfully, but these errors were encountered:
In addition to the Il2Cpp native exports, there are a large number of helper methods created during the Il2Cpp conversion. These methods can be detected with disassembly analysis. Ideally, we could:
Cpp2ILInjected.CppNativeMethods
.In doing this, we can expand our capabilities in other areas
AddressAttribute
for each of these disassembled methods.The text was updated successfully, but these errors were encountered: