只是普通的单机手游,广告比较多,所以分析处理了下,校验流程蛮有意思的,所以就分享出来了
样本进行了加固,对其dump出dex后重打包出现崩溃
ida分析地址发现为jni函数引起
利用Xposed直接替换该函数,崩溃问题解决
1 2 3 4 5 6 |
|
但是出现了新的问题,游戏卡在了加载页面
对该类的其他jni函数进行分析,发现supportVulkan很明显进行了签名读取,对其去除签名校验。
此处参考项目:ApkSignatureKillerEx
去除完签名校验后,游戏能正常进入主页面,但是点击游戏地图没有任何反应。
在对原包进行多次测试发现,在首次启动游戏时,如果断网也会出现无法正常进入地图的问题,怀疑是游戏首次启动进行了网络请求进行数据校验
利用Frida的算法通杀脚本没有定位到相关内容,怀疑是so层进行了请求
通过调用栈可以很清晰看到请求是从unity引擎相关的so中发出的。
查阅资料,在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函数进行校验,经过一系列字符串加解密,最后进行网络请求
对关键函数进行hook分析
1 2 3 4 5 6 |
|
发现之前抓包获得的请求体相对应,其中,appFileList还是密文,继续分析
与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函数获得
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
至此,除了具体的字符串加密算法,游戏的校验流程已经很清晰
对该校验去除的思路: