当前位置:   article > 正文

so文件反编译_安卓攻防so模块自动化修复实战

so 修复

前言

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。
  • 目录结构如下:

6384911ba2932cf1ae868d992a890825.png

Core

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

fix

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

util

  • 逻辑无关的工具类

viewer

  • 界面显示相关逻辑

Windows

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

工具编译

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

实战一波(阿里安全加固方案测试版)

环境准备

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

92a7594e174deda7ea53e61611c7dd48.png

开始分析

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

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

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

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

陷入杯具

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

58c55b94f5e280b3b5f895beb3b82849.png

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

开始思考

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

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

578c82b4a2534374ca25319ba343bb30.png
  • 等待一会儿会修复完毕,于是我们得到修复后的文件:、

ae4db3a73048074a8c81d5704bde7000.png

再次尝试

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

fe683bdfc970c6e960033ef11d8f16fe.png

8eac85498fb01733ce1e2d84d596d532.png

就到这里了

  • 到这里之后,估计很多人都能继续着手分析了, 也达到了本文的目的。最后提醒一点是,大家在自己动手修复节表这种东西的时候,不要忘记修复 符号表,对IDA来说还是比较重要的,不然分析出来的效果会降低,具体情况大家可以尝试一遍,印象会更深刻。
  • 另外建议新手有空可以读一下 apkTool 的代码,确实没几行代码,但是在熟悉这块代码之后,对后续的一些初级坑的帮助还是挺大的 ^..^
声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/运维做开发/article/detail/872315
推荐阅读
相关标签
  

闽ICP备14008679号