根据”so劫持”过360加固详细分析
参考：https://bbs.pediy.com/thread-223699.htm
http://blog.csdn.net/luoshengyang/article/details/8923483
前几日看到大神写的 https://bbs.pediy.com/thread-223699.htm这篇博客感觉受益匪浅，但是其中有一些自己的理解想跟大家一起分享，算不上原创，希望各位大侠不要嘲笑。共同学习。
一：思路分析：
一个经过360加固的APK的运行过程应该为图中左边所示，在以上这种so劫持的思路为:第一步通过hook loadlibrary方法先加载自己的so，即：libhook.so
第二步在libhook.so中再加载libjiagu.so,并执行其中的JNI_Onload方法，完成最后的解释。
这样做有个最大的好处是：就是在libhook.so中通过hook 注册函数dvmUseJNIBridge()得到oncreate函数的地址，更好的进一步分析360的虚拟解释函数。因为360壳比较复杂，前面有一堆的解密等操作，这样做可以直接切入要害。
二、此思路能否过反调试？
1.原作者这种巧妙的运用sleep(9),不以调试模式启动，等在sleep（9）的时候直接附加，这个时候360在JNI_Onload中的反调试已经运行完了，所以不会触发反调试。
2.以下这种是在以调试模式启动的时候过反调试的基本操作：
首先看Dalvik虚拟机JNI方法的注册过程分析，通过老罗的分析博客，（老罗的分析真的很到位，此处盗用老罗的图）可以大致知道运行图如下：
因此来说在整个so劫持的关于JNI方法注册大致是如下：
从中我们可以看出要想在调试运行过程中在new_dvmUseJNIBridge()函数处下断点，必然是要触发反调试，接下里就是想办法过掉反调试。
三、过反调试
首先等APP加载起来在 LoadSo_InitJni()函数处，下断点，等运行到如图所示的时候F7进去分析如下，就进入了熟悉的libjiagu.so的JNI_Onload函数里面。
第一处反调试：rtld_db_dlactivity函数
作用功能发挥：
从linker通过符号表，找到函数rtld_db_dlactivity对应的模块中的地址（这里直接使用了简单的遍历符号表Sym结构的方式），然后返回。如果地址里面的值不为0则会调用raise函数发送一个结束进程的信号终止程序。
rtld_db_dlactivity函数：
这个函数实则默认情况下为空函数，这里的值应该为0，而当有调试器时，这里会被改为断点指令，0xDE10实则为thumb指令的断点。函数的功能是用于处理一些调试器的特殊情况的。比如调试器对模块的某个地址进行下断，但这个地址实际不存在，得在模块加载后才存在等的特殊情况下的函数。起的作用就是类似于协商解决特殊问题。
方法一：在乐固中也会调用raise函数进行进程的终止，可以通过在这个函数处下断点，然后，对这个函数中的函数体做响应的操作，无论在哪调用或者怎么调用，都不会使得反调试起作用，但是在360中我们知道第一处的反调试也是会通过调用这个函数，但是我在实验的过程中发现，等把raise函数体改变以后，整个程序不能跑，因此看来只能一步一步的往下跟。。
方法二：
思考：因为从上面可以知道要通过linker找到函数对应的模块地址，首先肯定会通过mmap函数把linker映射到内存中，因此首先在mmap函数处下断点，等到调用时返回就OK。
方法三：
由于在360加固中的核心的函数libjiagu.so中的核心分支点为：case 31和33，并且在31处中的BLX LR来执行不同的函数，在此处下断点，看R0的返回值。
如图所示，对应的直接把将DE 10修改为nop指令 C0 46或者00 00，就OK了，过掉第一处反调试。
第二处反调试：TracePid
对于TracePid的检测，此处LR的值为strtol，将其返回值修改为0，
我这里是由于把系统内核的TracePid进行了修改，因此会出现：以下R0是0.
第三处反调试：端口的检测
对于端口的检测，这个好过，直接在刚开始调试的时候通过“./xyy -p7359”把端口换掉就可以了。
第四处反调试：
这个一看就是对于时间前后差值就行检测，如下图所示：
F5以后更为明显：
那么这个也好办，在time函数处下断点让它每次返回的值都为0就可以了。这样就绕过了检测。
这样就基本过完了所有的反调试，接着往下分析。
通过uncompress函数解压第二个so文件并解密找到对应的JNI_Onload函数，主要作用就是动态注册那些被native的函数，这不是本文的重点。
当然这里也可以不用手动过反调试，对反调试中的一些关键函数进行HOOK，比如time函数，返回0等，也可以过掉。
四、寻找核心解释函数
接着就该被Hook的注册函数dvmUseJNIBridge()发挥作用的时候。接着F9就到了
由于注册的函数有很多，因此直接在sleep(9)之后下断点，就可以。
到了关键函数处，通过“ALT+G”修改为Thumb指令，再通过P键就可以出来指令。
作者这里是通过一种很巧妙的方法，通过观察运行的过程中的log输出来判断核心函数地方，是个很聪明的做法。很值得借鉴。可以很容易的得到偏移值为
debbug offest=0x3b534。
在分析这个虚拟解释函数之前首先要dump出除onCreate函数以外的dex文件。
1.可以通过分析图中那个关键函数在dex解密完，就可以在HEX区域看到。
2.通过memcpy函数下断点得到。
3.通过主动调用dvmDefineClass进行加载。
以上都可以dump到dex。
如图所示dex2jar后，接着分析onCreate函数的虚拟解释过程。
五、理解虚拟解释函数过程
具体过程如下：作者已经在他的帖子中说的很到位了，这块简单贴几个图。
首先是每个样本的key不一样，在这个样本中的key值为：3232；
通过R4值得到如下的虚拟指令为：
07 12 75 18 71 32 F2 22 2B 0C 31 32 35 32 CC 33
01 33 93 22 E6 0C 32 32 BE 30 93 12 EE 0A 13 32
87 32
接着就是读取虚拟指令首先是与key进行异或运算得到中间值1；再与0xFF进行与运算得到中间值2，再与0X5C相加得到表中的分支，最后找分支进行解释运算。如下图所示。
以下是找到分支以后进行比较找相关的解释函数进行解释。
在这个样本中就是如下图所示的规则：
六、还原&总结：
还原：
、
对于每个不同的APP经过360加固以后，虚拟指令、中间值1、中间值2可能都不相同，但是每个指令的对应的表的分支是一样的，比如在这里面就是74对应着invoke-super Smali指令。
因此我们可以选择一个写上所有的Smali指令的APP经过360加固进行分析找出真实的指令与表的分支的对应映射表，对于一个待逆向的APP，只需要提取出对应的分支就可以根据映射表得到真实的指令，完成还原。
总结：
360加固保这种加固做到了dex的虚拟化，但是由于无论中间的过程怎么复杂的变换，加上Android中Smali指令数量不是很大，总是会有表中的分支与真实指令之间的一个对应关系。总是可以想办法进行还原，如果想加强，我觉得是不是可以采用“多虚拟的思想”里面有多套map表，每次随机选择运行，并且360反调试有点过于集中，可以在每套map表的逻辑转换中插入一些反调试，以上纯粹YY，希望各位大侠不要嘲笑。
原文地址： https://bbs.pediy.com/thread-223796.htm