360加固之libjiagu.so dump修复

一、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 Segment的p_offset和p_vadder是一样的，相差了0x1000,dump出来的内存在这个位置会比file多0x1000

 

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

三、so dump修复

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

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

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

下面是DynamicSegment里rel对应的数据

可知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一样

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

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

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

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