Axie Infinity
As we all know, Axie Infinity was the most popular GameFi game last year. It was developed by the Vietnamese team Sky Mavis and became popular in Southeast Asia in just a few months. The largest market is the Philippines, followed by Vietnam, Malaysia, Indonesia and the United States. Wait.
In June last year, the game’s single-day average revenue was tied for the first place in the world with “Honor of Kings”; the average revenue in the past July 30 last year was also US$334 million, surpassing the US$231 million of Honor of Kings and won the throne.
Since the epidemic, the economy of Southeast Asia has been hit hard. As many as 7.3 million people in the Philippines have lost their jobs. The unemployment rate in Malaysia has also reached its peak since 1993. Unemployed groups are more widespread in various fields: fresh university graduates, tricycle drivers, and migrant workers overseas to make money of people. When they lose their income due to the lockdown or being unable to go abroad, Axie, which can make money online, naturally becomes the best opportunity to make the game popular quickly.
However, as the tide and bubbles fade, the GameFi sector has plummeted since December last year. We should be cautious about P2E chain games. Just a little entertainment, and don’t invest too much. After all, the risk is huge.
Simulator detection
The official Android APK provided by Axie Infinity cannot run normally on the Android emulator on the PC side. I believe we have all discovered it. Take the thunderbolt simulator as an example. After installation and running, the screen is blank. 
The first thing that comes to mind is that there may be an official simulator test.
We checked the lib directory of the APK, and sure enough, we saw a library like [libemulator_check.so] that is obviously used for simulator detection. It can be seen that the official has also put a lot of effort into testing in the native code layer, not just in the Java code layer, so it is difficult to do it only with Java layer Hook technology such as Xposed.
But no matter how his [libemulator_check.so] is detected, even if he uses countless detection methods, even if he uses vmp to pack this .so, as long as I find a way to make his Java code not call [libemulator_check.so] Wouldn't that work?
After some research and searching, I found that this [libemulator_check.so] actually came from an open source project:
https://github.com/happylihang/AntiFakerAndroidChecker
Sure enough, after decompiling with [jadx] , we saw that it was called in the Java code
EmulatorDetectUtil.isEmulator(context);
To perform simulator detection, we decompile it through [apktool] , modify the smali code, remove these calls, and then repackage it.
However, a tragic thing happened. After we repackaged the APK, it could not run, even on a normal Xiaomi mobile phone. It seems that in addition to emulator detection, it also performs signature verification.
Sure enough, we found in the decompiled code that he did signature verification in [libglvnftpb.so]
However, for the cracking of signature verification, we have an all-purpose killer:
"Android Reverse [4]: Brute force cracking APK signature verification, happy repackage WeChat Alipay APK"
https://blog.csdn.net/CharlesSimonyi/article/details/122184098
Of course, we can also Hook directly through Xposed without repackaging his APK [ EmulatorDetectUtil.isEmulator() ]
But in the end, we still failed, and the game was still blank on the simulation.
So we directly searched [System.loadLibrary] in the decompiled code to see what so was loaded. So
far, we found the magical function [C0010.m9(485)], which comes from the book of [libglvnftpb.so]. machine code.
Good guy, we found that his few Java codes actually called [C0010.m9] this function up to 531 times! It turned out that he compressed all the strings required by the Java code part of the entire APK into [libglvnftpb.so]. After the APP runs, it will
load [libglvnftpb.so] through System.loadLibrary("glvnftpb"); At this time, [libglvnftpb.so] will perform signature verification, simulator detection and other operations. After the self-test is passed, these strings will be released into memory. Next, the [C0010.m9] method of [libglvnftpb.so] will be called. Pass different numbers to look up the table to get the correct string.
Then if you just kill [libglvnftpb.so] and let it not load [libglvnftpb.so], it will not work, because the Java code of the entire APP relies on [C0010.m9] of [libglvnftpb.so] everywhere to obtain the necessary String.
Solutions
There are two ways to start:
-
First run the original [Axie Infinity] on the real Android machine, then use frida to write a script, repeatedly call [C0010. Come out, and then write a [libglvnftpb.so] to replace it. Of course, our own [libglvnftpb.so] does not do any detection and returns the correct string directly. Of course, there are still a lot of details to deal with.
-
Collecting old versions of APKs is very important for game APP reverse engineering. If you are concerned about a game APP, it is best to write a script to watch every new version of the official release from the beginning, and collect as many old versions as possible. Version APK. Because the official confrontation with the studio is also gradual, in the early days of [Axie Infinity], not only did not do simulator detection and signature verification, even its il2cpp code was not obfuscated, and all functions and variables were clear at a glance , but as the official and the studio have been fighting for nearly a year, various detection and obfuscation methods have emerged one after another. By collecting as many historical versions as possible, we can compare the differences between two consecutive new and old versions, and it is easier to find out what changes have been made by the official. In the same way, another idea to solve the simulator detection is that we still use the old version of the Java code, but integrate the new version of the unity file, the old version of the Java code used to start the unity environment does not call so for the simulator detection, At the same time, the changes of each new version of game APP are mainly the unity files. After this application, the Java code of the APP will not be tested by the simulator, but the unity is the latest version, and the game can be played normally. Of course, this depends on the specific implementation of the APP. Fortunately, the detection logic of [Axie Infinity] is basically in so, and the game logic is all in [libil2cpp.so]. As for the Java part, the new and old versions have not changed much, so we do It is possible to apply the old and the new.
Revision
Due to limited time and energy and some other reasons, we cannot give the specific steps and codes for modifying the Axie Infinity simulator detection in detail for the time being, so at present, a modified APK file is given first, and it will be updated with the official new version. The current modified version of the APK can be downloaded here (download from [Releases] on the right):
https://github.com/encoderlee/cracked_axie_infinity
running result
The effect of the latest version 1.1.3.3 running in the thunderbolt simulator
some good open source projects
After running on the thunderbolt simulator, we can easily open N more numbers on one computer, and set different agents for each client. At the same time, we can also use the following open source projects to realize the automation of Android devices , so as to realize some automated operations:
Android automated testing tools: https://github.com/openatx/uiautomator2
Mobile game automated testing tools developed by NetEase: https://airtest.netease.com