各种脱壳总结（生命在于运动，知识在于积累）
2016-05-26 22:22
781 查看
1.Xdex（百度版）脱壳工具基本原理：
核心思想是：根据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里的指令。经测试，的确可以
-------------
梆梆脱壳分析1-所有线程抗gdb技术实现：
对于梆梆，可以attach到其binder线程上，通过gcore、dd来dump内存中的dex。但对于其最新版本，当使用gdb attach到主进程的任一线程上时，要么permission denied，要么会退出。现对其实现机理进行一下分析：
1.主进程fork子进程c1，c1 fork子进程c2；
2. c1会ptrace attach到主进程的主线程与GC线程（其也会操作memory，所以需要用ptrace方法保护），这样当试图ptrace attach时，会有permission denied；
3. 主进程为了能让c1这个子进程跟踪，需要调用prctl，option为SET_DUMPABLE。但这个API比较危险，其效果与AndroidManifest文件中debuggable选项设为true等价。如果不调用这个api，子进程是不能trace父进程的；
4. c1也会ptrace到c2进程，来对其进行保护；
5. 这个三个进程间彼此用pipe进行通信；
6. c1会向主进程内存空间注入大约52字节的数据，应为密钥；
7. 之后c1进入pipe读阻塞sleep；
8. c2使用inotify监控主进程的每个clone process的mem与pagemap，于是当gdb、dd试图dump内存时，mem的access事件被触发，三个进程集体退出，导致内存dump不完整；这边漏了一个，同时c2会不断打开主进程的各个status文件，看其tracerpid是否为0，非0则被attach，退出；
9. c2并monitor主进程的task目录，来判断是否有新的clone process或现有的已消亡，来更新monitor的select loop的fd集合。
爱加密也是使用类似方法来实现其功能。另外，梆梆还hook了write方法，来阻止在进程内部将header为dex的magic code的内容写入磁盘。
----------------------
应用资源文件格式解析及阿里破解示例：
腾讯，360等对apk资源保护的方法是通过自动化测试工具寻找一些异常的数据格式，安卓虚拟机及aapt对于这些异常的格式可以正常处理，而apktool工具处理分析时会出现异常。找到这些异常的数据格式后，利用改装后的aapt工具，对apk打包时设置这些异常的格式，从而达到保护的作用。
核心思想是：根据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里的指令。经测试，的确可以
-------------
梆梆脱壳分析1-所有线程抗gdb技术实现：
对于梆梆，可以attach到其binder线程上，通过gcore、dd来dump内存中的dex。但对于其最新版本，当使用gdb attach到主进程的任一线程上时，要么permission denied，要么会退出。现对其实现机理进行一下分析：
1.主进程fork子进程c1，c1 fork子进程c2；
2. c1会ptrace attach到主进程的主线程与GC线程（其也会操作memory，所以需要用ptrace方法保护），这样当试图ptrace attach时，会有permission denied；
3. 主进程为了能让c1这个子进程跟踪，需要调用prctl，option为SET_DUMPABLE。但这个API比较危险，其效果与AndroidManifest文件中debuggable选项设为true等价。如果不调用这个api，子进程是不能trace父进程的；
4. c1也会ptrace到c2进程，来对其进行保护；
5. 这个三个进程间彼此用pipe进行通信；
6. c1会向主进程内存空间注入大约52字节的数据，应为密钥；
7. 之后c1进入pipe读阻塞sleep；
8. c2使用inotify监控主进程的每个clone process的mem与pagemap，于是当gdb、dd试图dump内存时，mem的access事件被触发，三个进程集体退出，导致内存dump不完整；这边漏了一个，同时c2会不断打开主进程的各个status文件，看其tracerpid是否为0，非0则被attach，退出；
9. c2并monitor主进程的task目录，来判断是否有新的clone process或现有的已消亡，来更新monitor的select loop的fd集合。
爱加密也是使用类似方法来实现其功能。另外，梆梆还hook了write方法，来阻止在进程内部将header为dex的magic code的内容写入磁盘。
----------------------
应用资源文件格式解析及阿里破解示例：
腾讯，360等对apk资源保护的方法是通过自动化测试工具寻找一些异常的数据格式，安卓虚拟机及aapt对于这些异常的格式可以正常处理，而apktool工具处理分析时会出现异常。找到这些异常的数据格式后，利用改装后的aapt工具，对apk打包时设置这些异常的格式，从而达到保护的作用。
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- 自加自减运算符
- ArcSDE 日志文件表（二）
- C语言里面邻接表的创建
- C++基础(一些经常混淆的概念)
- 个人工作总结03（第二阶段）
- 多图详解Spring框架的设计理念与设计模式（1-2-3-4-5-6）
- strace实时查看进程日志输出
- HDOJ/HDU 5686 Problem B(斐波拉契+大数~)
- HDOJ/HDU 5686 Problem B(斐波拉契+大数~)
- find 命令的参数详解
- spark action 操作（1）
- CentOS环境下vim配置（有图）
- css3 -- 文本
- 205. Isomorphic Strings
- 类、函数和正则表达式
- 删除目录软链接注意事项
- 京东2016校招编程题
- JavaEE的十大安全控制
- c中的\n和单双引号
- GetProcAddress函数实现和分析