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

So文件信息读取显示
1.1 显示Elf头
1.2 显示Program头
1.3 显示Section头

So文件节表修复重建功能（适合面目全非型）
2.1 根据.dynamic 节重建其他节信息

环境准备

开始分析

增加了几个附带的So文件

为了更加直观，我们把AndroidKiller反编译出来的classes-dex2jar.jar 拖入jd-gui查看，代码很直观，如下：

• 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://github.com/freakishfox/xAnSo
• 目录结构：
  • Core
    • 主要存放一些基础组件类
  • fix
    • 主要存放一些修复方案逻辑
    • 持续增加...
  • util
    • 逻辑无关的工具类
  • viewer
    • 界面显示相关逻辑
  • Windows
    • 工具在Windows平台下编译需要的工程配置及相关文件
• 工具编译
  • 目前Windows平台的编译可以在Visual Studio2013环境下完成，Android目录下的编译配置文件还没配置上去

• Core
  • 主要存放一些基础组件类
• fix
  • 主要存放一些修复方案逻辑
  • 持续增加...
• util
  • 逻辑无关的工具类
• viewer
  • 界面显示相关逻辑
• Windows
  • 工具在Windows平台下编译需要的工程配置及相关文件

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

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

• 逻辑无关的工具类

• 界面显示相关逻辑

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

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

• 环境准备

  • 要测试工具效果，我们自己写一个很简单的Android App, , 使用Android Studio创建一个工程，主要代码如下：
  • 
  • 代码很简单，基本是一个空页面的App，直接编译打包，上传到阿里安全进行加固（Demo），把加固后的结果下载回来

• 开始分析

  • 把下载回来的加固包丢入 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静候佳音！

• 要测试工具效果，我们自己写一个很简单的Android App, , 使用Android Studio创建一个工程，主要代码如下：
• 
• 代码很简单，基本是一个空页面的App，直接编译打包，上传到阿里安全进行加固（Demo），把加固后的结果下载回来

• 把下载回来的加固包丢入 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的基础上做了修改调整

• 到这里，一开始是懵逼的，到底这个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 的代码，确实没几行代码，但是在熟悉这块代码之后，对后续的一些初级坑的帮助还是挺大的 ^..^

1. 把切实可行的解决方案想法落地到代码
2. 方便需要的同学查看解决方案原理
3. 希望有更多的人参与进来，慢慢打造一个好用上手的工具

1. So文件信息读取显示
   1.1 显示Elf头
   1.2 显示Program头
   1.3 显示Section头

2. So文件节表修复重建功能（适合面目全非型）
   2.1 根据.dynamic 节重建其他节信息

目录结构：

• Core
  • 主要存放一些基础组件类
• fix
  • 主要存放一些修复方案逻辑
  • 持续增加...
• util
  • 逻辑无关的工具类
• viewer
  • 界面显示相关逻辑
• Windows
  • 工具在Windows平台下编译需要的工程配置及相关文件

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！