so文件混淆与修复

一、对section header进行混淆

由于linker不会对section header进行加载,所以对section header进行改动,不会影响so文件正常加载到内存,因此有些程序对section header进行了混淆,导致IDA无法正常进行静态分析。

so文件混淆与修复_第1张图片

混淆方法:
1.将section header table中的addr、offsize等字段值清0,如果清空的是dynsym段,就会使IDA无法找到函数符号
2.对section header中的name字段进行修改,可以更改段名

二、对Program header进行混淆

linker在加载so文件的时候会用到LOAD段,但是没有直接用到其他段的数据,比如说Dynamic段中的数据,在linker源码中会通过switch的方式对Dynamic中的字段进行赋值,也就是说如果对Dynamic中的字段进行复制混淆一样不会影响linker进行加载,因为同样的字段,后面的会覆盖前面的,但这样的静态混淆有个明显的缺陷,同字段的值,一定是最后一个是有效的。

so文件混淆与修复_第2张图片

三、so文件的修复

3.1 最简单的修复方式

如果elf header中的section header offset是一个异常的值,IDA加载时会报错,并且无法正常的静态分析

so文件混淆与修复_第3张图片
so文件混淆与修复_第4张图片
so文件混淆与修复_第5张图片

最简单的修改方法是将以下几个值清0,这样IDA就不会报错,但是修复的程序非常有限

so文件混淆与修复_第6张图片
so文件混淆与修复_第7张图片

3.2 手动修复

虽然section header的addr完全清0了,但是恢复并不是没有办法

so文件混淆与修复_第8张图片
section header的0段addr和off永远是0。
sectioin header的1段size是0x13,对比Program header的INTERP段可以看出,它的size也是13,就可以猜测对应的是INTERP段,所以section header的1段addr和offset是0x134
so文件混淆与修复_第9张图片

有了1段的addr和offset就可以根据size和align计算出下一个段的addr和offset
so文件混淆与修复_第10张图片
计算到段13的时候,发现0x8b88+340=0x8ec8,这时候根据LOAD段,可以得知它的地址其实应该包含到第二个LOAD段中了,它的offset是9da8,addr是ada8

在这里插入图片描述

当修正到段[23]时,修改值是45da4,第二个LOAD段的offset+filesize=45da4,所以下面的段[24]的修正需要采用另一种方法

在这里插入图片描述
注意到这个段的类型是NOBITS,它的段名应该是.bss,而bss的后面的段是comment段

在这里插入图片描述
可以看到comment段和bss段的offset是一样的
so文件混淆与修复_第11张图片
所以修改如下
在这里插入图片描述

对address的修正
so文件混淆与修复_第12张图片
最后几个address为0
在这里插入图片描述

在010中找到对应的字段全部修正,保存,再用IDA打开。
修复前

so文件混淆与修复_第13张图片

修复后

so文件混淆与修复_第14张图片
so文件混淆与修复_第15张图片

你可能感兴趣的:(移动安全)