一、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)