Welcome to visit netease Cloud Community to learn more about Netease’s technical product operation experience.
Chen Shiliu, an expert on mobile game security technology of netease Cloud ESHIELD, has introduced this problem in detail in his speech on the 2018 Unity technology road show, which is excerpted as follows:
Preventing Unity3D code from being decomcompiled is a common crack risk in Unity mobile games.
I. Cracking risks faced by Unity
Unity cracking risks mainly include Unity Mono script decryption, Unity IL2CPP script parsing, and Assetbundle resource tampering.
1. Unity Mono script decryption:
The following two pictures show mono script files in binary form and source conversion.
2. Unity IL2CPp script parsing
Dat with libil2cpp.so and global-metadata.dat as input, use Il2CppDumper to parse:
The class name, function name, and corresponding offset can be resolved as follows:
Currently there is no tool in iOS that can parse the source code, but if you can decrypt or parse Android scripts, it will greatly facilitate iOS cracking. Therefore, effective script encryption on Android is necessary.
3. Assetbundle resource tampering:
Perspective gives players using the modified version an asymmetric advantage. In a shooting game shown below, change the material property in the Assetbundle resource to transparent to achieve perspective.
In addition to the risk of resources being tampered with, there is also the risk of resources being stolen and analyzed by competing products.
4. Archived data is modified
Some game archived data exists in plain text. If the data is not verified by the server, or if it is a single player game, there is a huge security risk, and various attributes of the game can be directly modified.
How to secure Unity? Many development teams may also have plans to develop their own hardened protection systems. To do a good job of this protection system, there are many problems that need to be solved, including the following four:
First, the self-research cost of protection scheme is relatively high, which requires continuous research and improvement. Not only do we need to understand the cracking process, but also we need to deeply master the operation principle of Unity engine.
Second, Android compatibility problems, Android devices fragmentation serious, system version upgrade, user environment diversification. Solutions need to be constantly refined. Netease has accumulated a long time in this area to develop a set of protection solutions that meet the requirements of performance, compatibility and security intensity. If the game development team develops the game itself, compatibility can take up a lot of team time and slow down the development of the core logic of the game.
Third, for cracking, the protection of itself is a process of spear and shield, is the process of continuous escalation and confrontation. If a game development team is going to develop its own protection system, it needs to analyze the tools on the market and analyze the methods they use to improve the overall protection system.
Fourthly, compatibility of third-party services. Nowadays, games are more and more in a mode of refined development. Many game teams only develop some core logical gameplay, so protection needs to be compatible with payment modules, hot update schemes, quality tracking and other third-party services. The compatibility of these third-party services presents a big challenge for game development teams.
In summary, if a game development team develops its own protection scheme, it will definitely face great technical and financial challenges, so it is not recommended to develop its own protection scheme.
So how does Easy Shield prevent Unity3D code from being cracked?
Netease ESHIELD can provide Unity Mono DLL script encryption, IL2CPP encryption, Assetbundle encryption and other encryption solutions!
DLL script encryption and decryption can be performed by modifying or HOOK mono_image_open_FROM_DATA_WITH_name. Mono_image_open_from_data_with_name is the loading function of the CSharp script. If the CSharpDLL script is encrypted, it needs to be decrypted before the function is executed. Therefore, as long as the breakpoint or HOOK is placed in this function, the original DLL can be decrypted, without the need for reverse encryption algorithm. Note that there is a memcpy copy operation, and Mono will keep a copy of the decrypted DLL in memory.
Unity Mono DLL script encryption has undergone three generations of technical evolution.
First-generation encryption encrypts DLL files directly and decrypts them at the beginning of the mono_image_open_FROM_datA_WITH_name function. The PE structure file uses the four bytes 4d 5a90 00 as magic head, which can be used as the feature of the CSharp DLL script. Just search the value 0x905a4d, because the cookie modifyer uses the base 10 value. Convert it to the base 10 value :9460301. Therefore, the decryption threshold is very low, as long as the use of the modifier can be decrypted.
The second generation encryption is based on the obvious weaknesses of the first generation encryption, and strengthens the protection against decryption. After decryption, erase the PE header shown below so that the modifier cannot locate the script location. Therefore, the decryption threshold is relatively high, which requires very strong reverse development ability to crack.
The third generation encryption encrypts the Csharp function, that is, the method level encryption, which requires dynamic decryption.
The original unencrypted DNSpy function parses the result
Dnspy function parsing error after function encryption
IL2CPP encryption
The Il2cpp script information is in the form of lib2cpp.so, which can be parsed by combining the symbolic information in the global-metadata.dat file. Therefore, we need to shell libil2cpp.so, as shown in the following figure. The original libil2cpp.so with IDA can see 475 derived functions:
The libil2cpp.so export function is null:
Assetbundle encryption
When the Assetbundle is unencrypted, Unity Studio can parse various resources:
After Assetbundle is encrypted, Unity Studio cannot parse it:
Iii. Characteristics of easy shield protection scheme
Netease’s easy Shield protection scheme has such performance characteristics as pure Native protection, shell of engine SO, high compatibility and stability, little impact on performance, and support hardening of Windows, Linux and Mac platforms.
1. Pure Native protection
The game dex is filled with third-party SDKS and SDKS that do not involve game logic. If DEX is covered, on the one hand, It is easy to cause Fragmentation of Android, leading to DEX being covered, which will reduce the compatibility of APP. In addition, Android has Dalvik and Art virtual machines, so dex shell will increase processing costs in order to accommodate the two virtual machines, resulting in a significant increase in startup time. Alibaba and Tencent have DEX shell service, but Alipay, wechat did not do DEX shell. Alipay and wechat have the most serious security problems among all the apps. It’s telling that they don’t have DEX shell. Besides, all Tencent games don’t have DEX shell. Therefore, if mobile game protection depends on DEX shell, compatibility and security are difficult to guarantee. DEX shells are therefore not recommended for games.
Netease Easy Shield can provide pure Native protection, so that game protection does not rely on DEX shell. The advantages and disadvantages of DEX shell and pure Native protection are compared as follows:
2. Shell the engine SO
Almost all cracking relies on reverse analysis of the engine SO, and shell protection of SO greatly increases the barrier to cracking the game. In addition to shell the engine SO, netease YIDong will also check sensitive function codes.
3. High compatibility and stability
The principle of strong compatibility lies in that all protection is in the SO layer and DEX will not be modified, which effectively avoids compatibility problems caused by Fragmentation of Android. Netease ESHIELD is highly compatible with all versions of Android from 2.3 to 9.0, all emulators and all instruction sets used by game engines.
The stability of mobile game protection needs to follow the following release process:
1. QA testing: tested on 200 mobile phones and various simulators;
2. Pre-online test: integrate the security module into rihuo 1000 APP for online test for 2 weeks;
3. Version release: After the first two rounds of tests are stable, it will be officially released;
4. Online regression: First, conduct online tests on small internal games to ensure stability.
4. Small impact on performance
Easy shield protection scheme also has the characteristics of small performance impact, whether the CPU occupation, memory occupation, startup time, power consumption and other aspects can be almost ignored.
The full text of Chen Shiliu’s speech can be viewed here. You can click to view the reinforcement protection introduction and free trial of netease Cloud Easy Shield mobile games.
Related articles: [Recommended] Review of seven content safety supervision in the field of live broadcast and short video in the first half of 2018