前言
只是普通的单机手游,广告比较多,所以分析处理了下,校验流程蛮有意思的,所以就分享出来了
1.重打包崩溃处理
样本进行了加固,对其dump出dex后重打包出现崩溃
ida分析地址发现为jni函数引起
利用Xposed直接替换该函数,崩溃问题解决
1 2 3 4 5 6 |
|
2.卡加载界面处理
但是出现了新的问题,游戏卡在了加载页面
对该类的其他jni函数进行分析,发现supportVulkan很明显进行了签名读取,对其去除签名校验。
此处参考项目:ApkSignatureKillerEx
3.地图无法进入问题分析(基于原包)
去除完签名校验后,游戏能正常进入主页面,但是点击游戏地图没有任何反应。
在对原包进行多次测试发现,在首次启动游戏时,如果断网也会出现无法正常进入地图的问题,怀疑是游戏首次启动进行了网络请求进行数据校验
经过抓包对比定位到可疑数据包
利用Frida的算法通杀脚本没有定位到相关内容,怀疑是so层进行了请求
3.1 hook send函数进行调用栈分析
通过调用栈可以很清晰看到请求是从unity引擎相关的so中发出的。
3.2 il2cppTrace对请求调用栈分析
查阅资料,在unity中,网络请求主要通过UnityWebRequest
类来执行网络请求,利用frida-il2cpp-bridge对UnityWebRequest进行trace,打印调用栈得
1 2 3 4 5 6 7 8 9 10 |
|
在IDA中进行交叉引用分析定位到UnitySDKManager类
1 2 3 |
|
增加UnitySDKManager类重新对其trace(因为出现报错,把参数输出关了)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 |
|
通过调用栈可以初步对校验流程进行了解,主要通过ServerVerifyApk函数进行校验,经过一系列字符串加解密,最后进行网络请求
3.3 加解密函数hook分析
对关键函数进行hook分析
1 2 3 4 5 6 |
|
发现之前抓包获得的请求体相对应,其中,appFileList还是密文,继续分析
3.4 追EncryptString函数
与dump.cs中的函数进行对照发现v14 由字符串转hex转base64获得
1 |
|
hook HexStringToHex 函数获得参数
1 |
|
IDA继续查找调用发现其中字符串由GetFileInfoList函数获得
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
|
很明显,调用了libUnitySDK.so中的GetFileInfoList函数获得
3.5 libUnitySDK.so分析
1 2 3 4 |
|
FileInfoListStr在writeFileJson函数中被赋值,而writeFileJson则是由java函数上文中的IsHDR_DisplayBoot调用(该函数首个参数为base.apk路径)
很明显,ll11l1l1ll函数 对之前的明文字符串进行了加密,frida hook打印参数
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
其中 HashList 中文件对应的值为文件的 crc
至此,除了具体的字符串加密算法,游戏的校验流程已经很清晰
4.校验流程归纳
- 签名校验
- 读取base.apk进行关键文件crc读取
- 进行服务器请求,对关键文件crc校验
5.后记
对该校验去除的思路:
- 对读取安装包的函数 zip_open 或java层的 IsHDR_DisplayBoot 函数进行hook,进行参数替换,进行io重定向
- 基于il2cpp中的ServerVerifyApk函数进行更详细的分析,直接对其检测去除