关闭

360加固之libjiagu.so dump修复

标签: 360加固libjiagu.sodump修复
5045人阅读 评论(0) 收藏 举报
分类:

一、elfheader修复

dump出来的内存如下图所示,elf header结构有缺失

下面是正常elf头的对比图

下面是010editor对正常elf header的解析

    由上图可知,dump出来的elf header除了e_phoff、e_phentsize、e_phum三个值,其它都为0。

   不过这里缺失的,除了e_shoff, e_shnum, e_shtrndx三个是变量,其它都是固定值。而实际上e_shoff, e_shnum, e_shtrndx这三个值在dlopen时并没有用到,全部填0,也可以正常使用。

   那么这里elf header把固定值填上,e_shoff, e_shnum, e_shtrndx三个值留空,elf header就修复好了。

   elf header修复完成后的dump就跟一个so经过dlopen后,dump出来的内存是一样的了。但是这样的dump是不能直接加载的,很多情况下用IDA分析也会缺失导入函数的解析。

 

二、so及其dump差异分析

    为了修复这个dump出来的so,我们写一个so来做个测试。

将测试so加载后,dump出来进行加载前后的对比


    后面一大块数据不一样。首先有个问题就是内存里的对齐跟文件是有差异的。

    看下elf Loadable Segment


    可以发现第二个Loadable Segmentp_offsetp_vadder是一样的,相差了0x1000,dump出来的内存在这个位置会比file0x1000

 

   Dynamic Segment同样存在这样的差异。

三、so dump修复

   由于dump的数据是跟内存加载后是一致的,把上面两个Segment里的p_offset都改成跟p_vaddr一样的值。

   完成这样的修改后,IDA就可以正常解析导入函数了,因为IDA对导入函数的解析依赖于Dynamic Segment里的数据。

   如果要能让dump能正常被dlopen起来,还需要继续对重定位数据进行修复

下面是DynamicSegmentrel对应的数据


可知rel对应的数据开始于0x6aa8,大小为0xf30


0x6aa8指向的elf32_rel结构体数组

typedef structelf32_rel {
       Elf32_Addr   r_offset;
       Elf32_Word  r_info;
} Elf32_Rel;

r_offset指向的地址会被重定位

下图是原始so的数据:


下图是dump内经过重定位的数据:


    可以发现dump里的数据被加上了so的加载基址,修复的时候,减去基址就可以恢复原始数据

    除了rel还有plt_rel需要修复,修复方法跟rel一样

    由于relplt_rel需要修复的数据量比较大,手动修复不太现实,需要编写个工具来完成这样的修复。可以把dlopen里的源码扣出来做一些修改完成这样的操作。

    下面是两张IDA分析的截图:




    修复后的so,跟普通so已经没什么区别了,导入函数和字符串暴露无遗。居然没有对字符串做加密,这样给分析者带来很大方便,对于加固核心so来说有点太依赖so加固了。

  (创建了一个Android逆向分析群,欢迎有兴趣的同学加入,群号码:376745720)

1
1

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:146234次
    • 积分:1796
    • 等级:
    • 排名:千里之外
    • 原创:35篇
    • 转载:17篇
    • 译文:0篇
    • 评论:48条
    最新评论