某数字公司加固方案分析（1）
最近是接手了一个App检测的项目，正想分析的时候，发现被加了壳。于是旅程被开始了，由于加固的so也被修改了，于是开始了悲摧的脱壳之旅。
解压apk，拖出so文件。
把so文件拖入ida分析，会发现一堆乱码，一点卵用都没有。使用readelf -a 命令输出对于so文件的分析。会发现：
Entry point address: 0x0
可以知道应该是使用init array中的函数作为起始地址的。
0x00000019 (INIT_ARRAY) 0x2ac1c
0x0000001b (INIT_ARRAYSZ) 16 (bytes)
在ida中找到0x2ac1c会发现
在ida中按G，0x55aaa5ab输入查找地址，会发现根本没有这个地址。
看来静态分析情况下是走不通的。
(下面假设你可以配置ida调试so的环境)
使用2015年的kill -19 的思路（也就是进程暂停的方法），可以获得内存中的so文件，把so文件整个dump下来，脚本如下：
auto i,fp;
fp = fopen("d:\\dump1.so","wb");
for(i=开始地址;i<=结束地址;i++)
fputc(Byte(i),fp);
把dump下来的so文件（下面统称dump1.so），载入ida中会发现已经部分解密了，可以看到里面有函数列表了
下一步就可以动态调试so了，看看加固了什么东西
当app断到加固的so加载的地方的时候（至于如何断，网上有文章，请自行查找），查找加固so的基地址(本次的基地址=0x773ef000)，使用0x773ef000+ 0x2ac1c查找init_array，会发现有三个函数指针，分别是:
773f47a8 ----> va:57A8
773f47ec ----> va:57EC
773f9338 ----> va:A338
在code界面上查找这三个地址（ARM体系结构有两种不同的指令集, 32位的ARM和16位的THUMB），0x773f47a8与773f47ec处的代码是code 16。你如果移动鼠标到这两个位置，进行强制汇编（按c键），会出现很蛋疼得汇编指令，必须是code 16。具体做法是鼠标点到这个位置，使用alt+g，会弹出一个框，选择t，并在value处写下1，然后在强制汇编就可以了。
在dump1.so文件中找到57A8，57EC，A338强制汇编会得到这三个函数，通过在这三个位置下断点，跟完之后发现不是在这里。那只能是jni_onload函数了。
对于jni_onload的查找，因为原始so文件ida无法正常解析，但是
对于我手机而言，我的调用jni_onload的地方是0x4176c000+0x511d0的位置，在so文件刚加载的时候，在这个点下断点，我写了一个idapython的脚本:
from idaapi import *
from idc import *
so_base = 0x4176c000 # the base address of libdvm.so
class DumpHook(DBG_Hooks):
def dbg_bpt(self,tid,ea):
return 1
#hook call jni_onload
AddBpt(so_base+0x511d0)
print "set hook ok...\n"
debug = DumpHook()
debug.hook()
也就是上面红线标注的位置，r8种存储的就是jni_onload的地址，进去之后就可以分析了
（注：上面的脚本是一个调试框架，从这个框架可以实现类似odscript的功能，可以实现全线自动化，上面的架构实现在了idc.py中，我们这里实现了重载，所有的断点被触发的时候都会进入这个函数dbg_bpt(self,tid,ea)，其中ea是当前的指令的地址）