[原创] 实现将AJM 脱UPX壳修复so文件

22小时前 261

工具使用:IDA6.8, 010 Editor

开始前描述现象:

将原APP解压出来的libexec.so放到IDA中加载发现打开的函数不能进行F5转为C代码

在该函数中按F5会弹出该提示,使我们无法转为C代码进行进一步的分析

1.提取调试手机linker文件

2.分析linker文件获取加载so文件的偏移地址

在String表中直接搜索calling,选择第一个结果进入.

接着查看该信息的交叉引用,选择第一个点击进入.

在调用字符串下面函数的偏移地址就是我们所需要的.

3.dump so操作

经过IDA一波的附加操作,待加载了libexec.so后即可开始干活了.

查看linker的基址

计算绝对地址

0xB6F14000+0x2464= 0xB6F16464

G键跳转进入并下断

接着F9进入该函数,待进来后继续F9一下.

现在可以在module list中搜索libexec.so

使用脚本dump libexec.so

观望一眼dump出来的so文件

使用IDA工具查看一下dump出来的libexec.so,大家可以看到导入导出表里面是空的.其实这是AJM的变形壳.接着下一步准备去修复libexec.so

4.根据UPX数据结构分析得出真实的数据大小

使用010 Editoe工具先加载app的原libexec.so

接着搜索关键字”AJM!”,选择第一个

接着使用IDA打开app里面的原libexec.so,待加载完毕后在导出表中搜索”.init_proc”并进入

此位置就是so的开始位置

那么接着在010 Editor中可以看到刚才搜索的位置就在0x11A20开始

其中结构体我这边是参考 一只流浪狗 大神写的  upx分析原理 进行分析的

里面共有3个结构体共36个字节,其实大家关注的地位就在第三个结构体中的sz_cpr字段的数据.

其数据为第二行后4字节.即0x91

那么计算压缩前数据的初始位置,从魔数位置开始算起,也就是UPX结构体的后面开始计算得出记录原始数据数据段大小的位置:0x11A44+0x91= 0x11AD5

现在跟进0x11AD5的位置所在的12个字节数据就是对应压缩前,压缩后的数据大小,分别为0x46A50和0x28B55

5.修复libexec.so

现在知道了压缩前的数据大小了,那么接着开始修复.首先将之前在内存中dump出来的libexec.so拖到010 Editor里面使用elf结构解析脚本进行解析.

修复的话只需修复01~03段即可.

01段 只需要将之前得出的0x46A50转换为十进制进行将01段的数值替换即可

改前:

改后:

02段:将offset的值改为下面一行的0x59E78即可

改前:

改后:

03段:修改的地方与02段一致

改前:

改后:

Ok,修改了这三处地方后记得保存,目前到了这一步已经修复完了.那么现在可以使用IDA来进行验证,随便在导出表中找一个函数打开并且看能否进行F5转换C代码即可.

具体样本在附件.

2020安全开发者峰会（2020 SDC）议题征集 中国.北京 7月！

最后于 22小时前 被guanlingji编辑 ，原因：