In the Unity engine, SO (Shared Object) files serve as the core carrier of native code, hosting critical modules such as core gameplay logic, encryption algorithms, and payment verification. This means that once an attacker successfully reverse-engineers an SO file, tasks like memory modification, protocol cracking, and cheat development become significantly easier.
Attackers typically use static analysis tools (such as IDA Pro or Ghidra) to read the import/export tables of SO files. For example, by searching for imported symbols from system libraries like libc.so or libcrypto.so, attackers can locate calls to key APIs involved in network transmission, file I/O, encryption, and decryption.
Given how helpful the import table in Unity SO files is for reverse engineering, one might ask: Can we remove the import table or avoid using imported functions altogether?
Even in a blank C project with no explicit API calls, the compiled SO file still contains around 10 imported functions. This is because the compiler automatically links runtime libraries that depend on system APIs. If the import table is simply deleted, the SO file will fail to load, causing the application to crash.
So, is it possible to technically remove the import table while still allowing the SO file to load correctly? Doing so presents several highly challenging technical issues:
- ● Without imported functions, no system APIs can be called directly. However, the protected SO still needs to call many APIs. How can these API addresses be resolved without using system APIs like dlsym, which themselves require imports?
- ● In theory, one could manually parse all function addresses from system modules. In practice, however, some functions are not exported in system modules on Android versions 4.4 through 7.0.
- ● The same API name may be exported by multiple system modules. How do you determine which one is correct? Using the wrong one can cause process crashes.
- ● Compatibility with emulators is another issue. Most mainstream emulators run on x86 CPUs and use hard-coded techniques to emulate ARM instruction sets, often applying non-standard handling to specific functions.Especially when running non-x86 modules, the process may contain two sets of instruction set modules simultaneously, making handling extremely complex.If import functions exist, the operating system handles all these complexities. Without them, developers must reverse-engineer and replicate these system behaviors without any documentation.
The JikGuard technical team, leveraging years of expertise in security technology, has successfully solved these Unity SO protection challenges. They pioneered the industry's first Unity SO protection scheme with no import functions. This solution has been integrated into multiple popular games and has demonstrated outstanding protective capabilities.
Below is the result after applying JikGuard's no-import-function SO protection: the "Imports" section shows no functions.
In addition to eliminating import functions, the JikGuard protection scheme offers the following security features:
Export Function Removal and Encryption
Exported functions are either removed or encrypted, leaving no analytical clues for attackers.
Virtualization of ELF Structure
The SO file structure is virtualized, preventing attackers from reconstructing or restoring the original SO file, thus making unpacking impossible.
System Call Interception
System functions can be monitored via dynamic hooks. After Unity SO protection, these system calls are intercepted, rendering dynamic hooking ineffective.
Encryption of global-metadata.dat File
The global-metadata.dat file is encrypted transparently to developers. Developers only need to run a single command-line tool to enable encryption—no additional file uploads are required.
