背景

      APK有so加固和dex加固。

      启动会检测环境以及反调试，然后主动crash。

初步分析

     根据frida启动打印的crash stackTrace和jadx分析，确认最前期的启动初始化的逻辑

     首先ProtectedAppApplication类的attachBaseContext方法里加载 xxboot.so

     然后在attachBaseContext和onCreate方法里调用3个xxboot里的native方法

     分别是 vCtFD x iwjhDgm

     其中检测操作以及crash操作就是在 vCtFD 方法触发

     x 方法返回一个初始化的 byte[] ，一堆操作后给 vCtFD 做参数

     iwjhDgm 感觉像最前面做初始化操作的

尝试方法1

    frida hook这些native方法，直接bypass掉，确实没crash，但后面会立马报错找不到一些class，说明核心类的加载逻辑和防护逻辑强关联。

    感觉这个路走不通，毕竟不可能设计的这么简单。

尝试方法2

   硬啃，争取把解密后的so dump出来，看能不能找到这几个native方法的代码。

   基于 dump_so.js 这个 dump出了xxboot.so，放到ida里看了下，和原始的比，稍微强了点，String View里能看到一些明文串，JNI_OnLoad能看到的逻辑也多了点，但没什么用，还是些sub_xxx 和看不到名字的 __fastcall 方法，全局搜索也没有和3个native函数名相关的任何东西。

  小菜安卓做的不多，请各位佬来指点下，有些什么操作可以看到这3个native方法，或者这种类型问题应该用其他的路子。

[尝试hook so动态注册的的函数]

通过hook RegisterNative 打印出6个动态注册的方法，其中有3个是可以看到名字和模块名，可以和java层的native方法对应上，还有3个匿名函数。

<libxxboot.so> method_name => void com.xxx.iwjhDgm() ,offset=> 0x7443e473d4 0x13d4 ,module_name=> libxxboot.so ,module_base=> 0x7443e46000
<libxxboot.so> method_name => byte[] com.xxx.x() ,offset=> 0x7443e4754c 0x154c ,module_name=> libxxboot.so ,module_base=> 0x7443e46000
<libxxboot.so> method_name => void com.xxx.vCtFD(java.lang.Object) ,offset=> 0x7443e475e8 0x15e8 ,module_name=> libxxboot.so ,module_base=> 0x7443e46000


<anonymous> method_name => , addr => 0x7443da67b8
<anonymous> method_name => , addr => 0x7443da6918
<anonymous> method_name => , addr => 0x7443d9010c

   奇怪的事情来了，我一开始以为这样就找到了native方法对应的地址，然后用地址去hook 方法 com.xxx.vCtFD ，同时hook对应java层的方法。

   最后日志显示 java层的vCtFD 方法被调用了，但用地址hook那个没反应。

   后面把这6个注册的方法都hook上，再次运行测试。

  确认每次执行java层的 vCtFD 方法时 ，so层 执行的是方法 0x7443da6918

  且测试多次发现这个方法的地址始终在module的base前面，且差值不是固定的，

    0x7443dd2918 - 0x7443eb1000 = -0xde6e8

    0x7443ddb918 - 0x7443e98000 = -0xbc6e8

    0x7443da6918 - 0x7443e46000 = -0x9f6e8

  大佬门来指点下这是什么trick，怎么搞。

谢谢

[培训]Windows内核深度攻防：从Hook技术到Rootkit实战！