What an IL2CPP build leaves in the APK
Unity offers two scripting backends. The Mono backend ships managed assemblies that a .NET decompiler reads directly. IL2CPP converts the managed code to C++ at build time and compiles the result into a native shared library, so the package contains that library and a metadata file instead of readable assemblies. The code is still there, expressed as machine instructions with no type information attached.
What survives is names. The metadata file holds the type system: class names, method names, field names, parameter names and string literals, together with an offset for each method in the native library. That pairing is what makes an IL2CPP app tractable, because the API surface is described in the metadata even though the logic is native.
Recover names from the metadata
Extract the shared libraries and the metadata file from the APK, then run a metadata parser such as Il2CppDumper over the pair. The output is a set of dummy .NET assemblies plus a header with the method offsets. The assemblies carry no bodies, but a decompiler or an object browser still lists every type, method and field, and string literals appear in a string table you can read on its own.
Read the string table before the code. Base URLs, path templates, header names and JSON field names appear as literals, so filtering for a URL scheme or a leading slash produces most of the endpoint inventory in one pass. The metadata answers what the app calls and with which field names, which is the first half of an API reconstruction.
Find the transport layer
Unity apps send requests through a small number of paths. UnityWebRequest is the engine's own client and appears in metadata as a type with methods for setting a URL, an upload handler and a download handler. Other projects use the .NET HttpClient from the managed base class library, and a commercial asset such as BestHTTP or RestSharp adds its own types. Search the metadata for these names, then list every method that references them.
Serialisation is the second half of the picture. JsonUtility is Unity's built-in serializer and works with plain classes, while Newtonsoft.Json appears when the project needs more control. Either way, the field names on the request class are the field names on the wire, so the metadata gives you the payload shape without reading a single instruction.
Follow one request into the native library
Take the string literal for an endpoint and find its address. That address is a valid cross-reference target in a disassembler, so loading the native library and jumping to the references of the string shows the code that uses it. A typical call site loads the URL, sets a method and headers, attaches a body, and then calls the transport method in the generated C++.
The metadata offsets make this faster. Each managed method has an offset from the start of the library, so when you identify a signing or header-building method by name, you can go straight to its address and read the compiled form. Instrumentation tools that know the module base address can also hook that address directly, which lets you watch arguments at run time rather than inferring them from assembly.
When the metadata has been transformed
A protected build can modify the metadata so that a parser rejects it. Some protectors encrypt the file or its string table, and some obfuscate names while leaving the structure intact. A parser that fails with a version or magic error usually indicates encryption rather than corruption, and the decryption happens inside the app before the runtime consumes the metadata.
The reliable recovery in that case is to run the app and capture the metadata after decryption, either by hooking the routine that produces it or by dumping the region from process memory once loading has finished. When only the strings are encrypted, the string accessor is the smaller target, and hooking it yields the plaintext of every literal the app uses.
What the reconstruction contains
The finished work pairs the recovered names with observed behaviour: an endpoint inventory with methods and payload fields, the headers the client builds, and the values it derives per request. The last of those cannot be read from metadata alone, because a signing key or a session value exists only while the app runs, so a capture or an instrumented run supplies it.
Native shared libraries in Android apps covers the disassembly side, and native Android reverse engineering is the broader service. Unity IL2CPP reverse engineering is the engagement that delivers a working client for this kind of build.
Related work
Reviewed 28 September 2026 · SReverse research desk