前言

Android加固方案经过这么长时间的发展，从开始的整体dex加密压缩方案逐步开始往native层发展，市面上知名的几款商业级加固方案中很容易发现这种方案的身影。这样看来，在今后相当长的一段时间内，Android逆向中不可避免的会频繁接触到与So加固的对抗了。

❖工具的初衷

搜集常见So加固方案（主要是日常分析中遇到的）

自动化对抗加固方案，解放双手

开源工具源码

1.把切实可行的解决方案想法落地到代码

2.方便需要的同学查看解决方案原理

3.希望有更多的人参与进来，慢慢打造一个好用上手的工具

目前状态工具目前还处于娃娃阶段，平时上班没有太多时间来撸^..^，目前包含了如下的功能：

1.So文件信息读取显示

1.1 显示Elf头

1.2 显示Program头

1.3 显示Section头

2.So文件节表修复重建功能（适合面目全非型）

2.1 根据.dynamic 节重建其他节信息

工具简介

• 开源地址：https://http://github.com/freakishfox/xAnSo。
• 目录结构如下：

Core

• 主要存放一些基础组件类

fix

• 主要存放一些修复方案逻辑
• 持续增加...

util

• 逻辑无关的工具类

viewer

• 界面显示相关逻辑

Windows

• 工具在Windows平台下编译需要的工程配置及相关文件

工具编译

• 目前Windows平台的编译可以在Visual Studio2013环境下完成，Android目录下的编译配置文件还没配置上去

实战一波（阿里安全加固方案测试版）

环境准备

• 要测试工具效果，我们自己写一个很简单的Android App, , 使用Android Studio创建一个工程，主要代码如下：

开始分析

• 把下载回来的加固包丢入 AndroidKiller （请自行更新包里的工具ApkTool到最新版本，省的再踩老坑反编译报错...）

• 图中我框出了经过加固之后的变化部分
• MainActivity->OnCreate函数变成了Native, 里面原先的代码看不到了
• 增加了一个类fixHelper
• 增加了几个附带的So文件
• 为了更加直观，我们把AndroidKiller反编译出来的classes-dex2jar.jar 拖入jd-gui查看，代码很直观，如下：

• 很自然，我们要跟着 fixHelper.fixfunc 进一步分析，继续观察代码，发现悲剧了，进入native层了，直接看图：

• 逃不掉了，必须要看So的代码了， 从这里的代码我们知道，肯定有那么一个So库，有那么一个导出函数fixfunc可以供Java层调用，看上面的这个代码结构的架势，估计是在运行时动态修复MainActivity.OnCreate函数的，
• 带着这样的疑问，我们在这个fixHelper类中找到了一个static{}代码块中找到了经典的 System.load("libdemolish.so")，那清楚了，二话不说在反编译后的目录里面找到这个So文件，直接拖入IDA静候佳音！

陷入杯具

• IDA反编译的结果是这样的：

• IDA分析完成之后，函数列表是空的， 导出函数也是空的，代码区域啥的都是 1% ~~~~，显然是这个So文件经过了处理，并成功干扰到了IDA的分析

开始思考

• 内心的想法
  • 到这里，一开始是懵逼的，到底这个So文件被搞了什么鬼导致IDA跟着懵逼呢？但是我知道一个前提，如果我们自己编译一个So文件，不经过处理，那IDA分析起来是比较溜的，于是我们这个时候考虑启用 对比大法
• 开始对比
  • 要对比，那我们就找一个没有经过（加固）处理的So模块来，我随便找了一个模块，为了描述方便，我称为A模块吧， 于是开始使用 readelf 这个工具分别查看模块的状态，得如下结果：

• • 这是节表显示结果，通过对比，结果很直观，被处理过的So模块，节表大部分信息已乱，除了elf执行必须的.DYNAMIC节之外，于是我们首先怀疑可能就是这里的问题导致了IDA的紊乱，找到了一处怀疑点，那就开始干，把不一样的变的一样（西医就是这么个思路~~）, 那具体要怎么修复呢， 了解ELF格式的同学应该比较快速的知道，利用 .DYNAMIC信息来进行修复（修复原理可以参考：https://bbs.pediy.com/thread-192874.htm=>
    6
    [原创]ELF section修复的一些思考， 感谢 @ThomasKing），部分修复操作在 @ThomasKing的基础上做了修改调整
• 解决问题
  • 问题初步定位了大致方向， 原理也了解了， 于是落地到代码， 启动写好的工具对节表信息进行修复：

• 等待一会儿会修复完毕，于是我们得到修复后的文件：、

再次尝试

• 刚才跟节表磕了一会儿，现在再回过神来继续想想 fixHelper.fixfunc 搞定了没有，把我们修复之后的文件拖入IDA, 经过一小会儿的分析， 效果出来了， 基本有了我们希望的结果(直接有图有真相)：

就到这里了

• 到这里之后，估计很多人都能继续着手分析了， 也达到了本文的目的。最后提醒一点是，大家在自己动手修复节表这种东西的时候，不要忘记修复 符号表，对IDA来说还是比较重要的，不然分析出来的效果会降低，具体情况大家可以尝试一遍，印象会更深刻。
• 另外建议新手有空可以读一下 apkTool 的代码，确实没几行代码，但是在熟悉这块代码之后，对后续的一些初级坑的帮助还是挺大的 ^..^