前言

那天酒足饭饱，夜不能寐，在日韩区看的津津有味，索性动身打开电脑，来一场酣畅淋漓的文章。废话不多说，欢迎大家来到日韩专区，这次的主角是 NHN AppGuard ，主角的特征是 libdiresu.so libloader.so
 

游戏启动

主角圆润的弹窗，不得不说很标特否，粗略扫一眼，完蛋居然被检测到我那藏起来的根（Rooting）

直接给我干闪退，网上说日韩很温柔，都是骗人的！！！幸好我打印了so 加载，不得不让我怀疑 libloader.so，现在目标明确，先干它
 

libloader

现在就让我们用IDA 好好蹂躏它吧，可以看到.init_array 有很多个函数，只有第一个函数sub_1718D4被IDA识别到，嗦嘎！！！明显是第一个函数解密了后面的函数，这里有个执行顺序的问题，如果JNI_Onload 是加密的，那么就往init_array，init_proc 去分析，假如都是加密的，那没得说了

这个壳的解密过程就不细说了，感兴趣可以去看下乐佬写的文章，看的我意犹未尽，从壳的加载解密到闪退等等，说的很详细，点赞
乐佬的文章

当看完乐佬的文章，你已经可以进入这次的主角，距离成功只差临门一脚。
 

弹窗反推

分析Security Warning弹窗，从弹窗的样式以so加载，可以看出是Java层触发的

通过Frida 对 Android Dialog.show 打堆栈，可以定位到com.siem.ms7.DetectionPopup

代码中存在很多隐晦难理解的字符串，先不管它，直接找create的地方，什么鬼，居然没调用

别慌，从堆栈打印中看到了native，得知这是从native 反射调用滴，嗦嘎！！！

当我们打印art的所有JNI函数，在NewStringUtf 发现令人激动的一幕

图上所示，这堆栈怎么没有so名称和偏移啊！！！！不会是自定义linker和开辟了一块匿名内存做检测吧？没事，我们先根据堆栈地址，从maps能不能找到一些有用的信息（正常逻辑是要分析libloader.so对Engine的加载）

通过对maps 分析，找到堆栈位置在/data/data/com.mobirix.mbpdh/.dtam145zau/fkr5gbebm3 (deleted) 里面，其中(deleted)符合堆栈没有so名字与符号的情况，不用看，直接Hook remove

可以看到remove了加载的so地址，我们阻止remove将so拷贝出来(暂且叫它“Engine”)，此时打印堆栈就能看到对应的so名字

 

Engine so分析

除了导出函数混淆以外，代码段没加密（奇怪，我分析那会，是对代码段有加密的，现在没加密了）

跳到 0x706391c34c iuyz5u972r!0xa834c 处，调用了JNI NewStringUTF

打印堆栈，最终找出触发点，看出有libc的kill和syscall exit，把a2的值改成0绕过检测

检测点，就不一一说了

现在frida 可以无忧无虑调式了
 

il2cpp

好家伙，init_array 和导出函数加密了，也没见start 与 .init_proc 函数，基本确定是通过其他so去解密的（elf结构没啥问题）

直接揭晓，解密由libloader.so操作，过程有点复杂就不贴出来了，大概流程就是加载elf，解析elf，找到代码段，解压缩代码段，复制解压的数据回填到il2cpp里，这里推荐一个简单的办法，对il2cpp的代码段监听读写，就得用上MemoryAccessMonitor.enable

打印出一个大概的地址，偏差不会很大，decode_iL2cpp 的v10代码段起始地址，v11是长度，hook dump出指定起始地址与长度，回填到il2cpp

 

global-metadata.dat

舒服，终于看到了熟悉的操作，dump出global-metadata.dat

用Il2CppDumper dump出游戏的sdk

查看dump.cs，舒服啊，还有韩文注释了函数的作用，hook 这些函数达到让人意想不到的结果

 

总结

难度中下，骚操作不多，集中在libloader，有机会我得好好学习日文跟韩文，大佬们有没有资料发下
样本：com.mobirix.mbpdh