发现加载到libglesv3_1.so frida就退出了，所以现在主要分析这个so

使用上面那个hook添加几行，看看是不是死在JNI_OnLoad里面的，如果so死在前面的初始化阶段hook_dlopen的hook就不会有onLeave的输出

发现是有输出的，所以重点放在JNI_OnLoad，打开就发现一个函数sub_1d8490

点进去就发现一个很可疑的字符串 thread constructor failed 并且上面创建了一个子线程，应该是用来做循环检测的

看看sub_1d6304,,LABEL_2 标签不就是杀进程的吗，所以重点放在v27和v28上面

交叉引用v27发现 v27 = strstr(s, needle);的比较结果，所以hook看一下needle是什么东西,发现是frida-agent很明显就是做检测的，所以我们直接在这个位置对这个字符串进行替换就行了

发现在当前so就不会进行闪退了，现在主要关注libmsaoaidsec.so，这个也算非常经典了，过掉线程创建就过了，但是我失败了，现在来看一下吧

这个so在JNI_OnLoad之前就死了，验证方法之前说过了，执行流程主要有init init_array JNI_OnLoad 这个后面在看，现在试试nop他的线程看看能过吗

frida没有退出但是登陆页面卡住了，也不知道这么回事，所以dump一份程序日志看看

发现这几行，所以卡界面的原因可能是libglesv3_1.so在里面睡觉

到0x7e8bc看一下，发现在这里一直睡，所以nop 0x7E8C0就好了

现在不卡界面了，但是闪了所以现在重点看一下libmsaoaidsec.so

通过 android_dlopen_ext 直接去hook他的init init_array里面的执行函数是不可取，因为android_dlopen_ext加载完成的时候这两个地方早就执行完了，所以我们通过hook linker64的构造执行函数__dl__ZN6soinfo17call_constructorsEv，贴一段ai说的，通过这个hook我们就可以得到这个so的基地址，并且这两个阶段还没有开始执行

先写一个简单工具函数便于定位函数的执行情况

直接搜索 DT_INIT_ARRAY ，看到0x14400就是init，所以对这个函数进行一下hook，发现这个函数只进不出，所以程序就是在这里面没的

所以重点看一下这个函数，这个函数有ollvm混淆，不是本篇讲的内容,就跳过了，sub_25A48有点可疑，hook一下，发现返回值是0,修改一下返回里面的函数都不会执行了是不是就绕过了检测？

并且init也正常结束了，我们在hook一下JNI_OnLoad,如果能hook说明程序不是在init_array里面死的，JNI_OnLoad只进不出，然后用只进不出定位一下，定位到0xed8c,这里面的函数一个都没有执行，所以只能trace看看了

trace结果如下,说明x0参数不对导致的空指针异常吧(不知道是不是空指针，反正就是在这里没得)，看看x0传的什么，并且在哪里有被使用

这里使用了这个地址，接着返回上层函数

又回到了梦开始的地方，说明强行修改了sub_25A48，导致sub_13728没有执行，造成的

[培训]《冰与火的战歌：Windows内核攻防实战》！从零到实战，融合AI与Windows内核攻防全技术栈，打造具备自动化能力的内核开发高手。