本帖最后由 水波摇曳 于 2015-12-13 22:01 编辑
学习移动安全快一年了，最近花了一些时间写了一个脱壳机（分百度版和通用版）。核心思想是：根据dalvik 获取dex各个数据段的方式，我也用同样的函数去获取，然后一步一步去恢复成一个合法的dex文件。基本思想很简单，也已有大牛实现过。 这里先拿百度加固来举例说明，百度加固相对于其它厂商的加固，好像并没有在类加载的时候做什么事。其它厂商的加固有的会在类加载的时候执行静态函数，有的会hook一些类加载的中间函数，才去恢复真正的数据。对于这些加固，必须去主动加载类，然后去获取ClazzObject 数据结构，这里面的数据才可能真正是正确的，其余内存的dex大部分数据多半已经被抹掉成没用的。但是主动加载类又会有很多其它的问题，比如 类的初始化会去优化指令，dvmLinkClass函数中：
上面这个函数在一些特殊情况下又会去修改ClazzObject 中virtualMethodCount 原本的值，还有的加固会改变AccessFlag的最高位，这些都会对最后脱壳产生影响。关于需要主动加载类这一块加固的脱壳，以后跟大家交流。 下面还是回到百度加固的问题上来，由于百度加固并没有在类加载的时候做什么事，导致我们不需要去主动加载类，我们直接可以通过dalvik的的一些函数去获取所需要的数据，
在源码目录中：/dalvik/libdex/DexFile.h和/dalvik/libdex/DexClass.h ，这两个文件里基本包含了所有的dalvik去获取dex各个数据段的函数。如下图：
（部分函数截图） 我们可以直接调用这些函数，或者去根据这些函数去获取内存中dex数据的方式，写出类似的代码去获取数据。这里比较重要的一点：因为是对dex每一块最小的数据段都进行了再次获取，所以需要对dex文件的格式有足够的了解，这样才能一步一步的恢复、重构成一个合法的dex文件,代码实现起来比较麻烦点的就是重写dex结构里的那些偏移。 当然百度加固并没有这么简单，虽然没有在类加载的时候干点坑人的事，但是有以下几个需要解决的点。 1 .听说有负偏移。 实际上这里的负偏移的含义是由于dex的DexMethod结构的codeOff是u4类型，而它的值过大，再加上dex 在内存的baseaddr ，结果就溢出了，这样就造成的DexCode在内存的位置变成了baseaddr的上面去了，但是这种加固方案并木有对我这种脱壳方式有啥影响，对于静态分析的大神进行脱壳修复就有一点麻烦了。
2. onCreate001 函数指令执行时存在，执行后抹去。关于这点，目前一些通用脱壳的方式是改变脱壳点的位置，然后去获取抹去的指令。当onCreate001函数过多，这样做好像有点麻烦。后来多亏某位大神的提醒，采用java反射的方式，能够自动恢复所有onCreate001里的指令。经测试，的确可以 这里反射调用的d方法就是百度加固用来恢复指令的。它会用e方法去抹去指令。
详细文档：去看雪下吧，没找到传附件的位置http://bbs.pediy.com/showthread.php?p=1405978#post1405978镜像地址：http://yunpan.cn/c35IHMVuIGIiD （提取码：53bd）PS:为了防止大家对别人的app重打包，对app的指令都调用了系统函数进行优化。大家就用它去逆向分析那些有恶意行为的app吧（谁让dex加固基本免费呢）。使用上有什么问题，私信我，或者发我邮箱[email protected].
| 
