前言

• 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目录下的编译配置文件还没配置上去

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

• 环境准备

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

• 开始分析

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

  • 图中我框出了经过加固之后的变化部分

    1. MainActivity->OnCreate函数变成了Native, 里面原先的代码看不到了
    2. 增加了一个类fixHelper
    3. 增加了几个附带的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 的代码，确实没几行代码，但是在熟悉这块代码之后，对后续的一些初级坑的帮助还是挺大的 ^..^