浅谈被加壳ELF文件的DUMP修复

路人甲 2015-06-10 15:45:00

前面的文章中,我已经介绍了如何调试被加壳的ELF,这里不在叙述,直接进入正题,以某加固为例,如何DUMP和修复被加壳的ELF,使其能调试加载

我们先来看看被加壳ELF的头和Program Header

首先我要让调试器停在入口点0x3860的位置

开始DUMP修复之旅,我的第一次DUMP修复的方法,延续了PE的思路,结果失败了

失败的原因并不是思路不对,而是细节上出现问题

第一次DUMP的方法:

1.废除不影响加载的section(直接把结构体填0),只关心PT_LOAD和PT_DYNAMIC两种类型节 2.计算DUMP文件最大值 align_up(0x28ca4, 0x8000) = 0x31000 3.将offset和va变成相等值,filesize和memsize按照align对齐 4.根据PT_LOAD节数据把数据DUMP出来,把DUMP数据放进文件里

那么根据上图描述数据,应该有两块儿

PT_LOAD : 0 ----align_up(0x12044, 0x8000) = 0 ----- 0x1B000
PT_LOAD : align_down(0x28ca4,0x1000) = 0x28000 ---- align_up(0x28ca4, 0x8000) = 0x31000

因为安卓也是linux内核,内存页对齐粒度为4K(0x1000)

按照上述方法DUMP完,我们来看看IDA加载以后,JNI_ONLOAD的样子

看下红色的部分,奇怪了,本来应该有的代码去哪里了??

0x221b0这个地址竟然无效

可是动态调试器中明明可以看到这段代码:

对照Program Header, 再看0x221b0这个地址,PT_LOAD节中并没有描述这个地址 所以,失败就是在这个地方,壳的代码里一定是mmap了这段内存,将解密后的数据,放进去,并修改了内存属性

通过跟踪壳代码,发现确实如此,壳代码通过svc 0,调用了mmap,mprotect两个函数

mmap(0x3000, 0x23710, 0x3, 0x32, 0xffffffff, 0x0)  
map页属性:PROT_READ | PROT_WRITE
mprotect(0x3000, 0x23710, 0x5)  

修改页属性:PROT_READ | PROT_EXEC 具体参数说明请参考帮助文档

这段区域起始地址:0x3000 大小:align_up(0x23710, 0x1000) = 0x24000结束地址:0x3000 + 0x24000 = 0x270000x221b0这个地址正好在0x3000---|0x27000这个范围里

通过上述过程,重新总结DUMP方法如下

  1. 废除不影响加载的section(直接把结构体填0),只关心PT_LOAD和PT_DYNAMIC两种类型节
  2. 计算DUMP文件最大值align_up(0x28ca4, 0x8000) = 0x31000
  3. 只保留一个PT_LOAD节,从0到0x31000将整块儿数据DUMP下来直接写入文件,修改align为0x1000,修改flag为RWE
  4. 修改PT_DYNAMIC节的offset,和VA相等 修复完的节表如下:

最后一个注意的地方,就是干掉INIT段或者是INIT_ARRAY段

干掉INIT方法:定位INIT描述的数据偏移,将偏移+8的数据,前移8个字节

干掉INIT_ARRAY方法:定位到VA处,按照结构,将数据填充为0xffffffff或者0

看下图,INIT段已经不存在了

我们来打开IDA,加载修复的文件,看看效果:

数据完整,再看看动态加载的效果

加载成功<sub>~</sub>

哈哈,至此,修复完成

评论

路人甲

真正的路人甲.

twitter weibo github wechat

随机分类

安全开发 文章:83 篇
业务安全 文章:29 篇
iOS安全 文章:36 篇
神器分享 文章:71 篇
SQL注入 文章:39 篇

扫码关注公众号

WeChat Offical Account QRCode

最新评论

Article_kelp

因为这里的静态目录访功能应该理解为绑定在static路径下的内置路由,你需要用s

N

Nas

师傅您好!_static_url_path那 flag在当前目录下 通过原型链污

Z

zhangy

你好,为什么我也是用windows2016和win10,但是流量是smb3,加密

K

k0uaz

foniw师傅提到的setfge当在类的字段名成是age时不会自动调用。因为获取

Yukong

🐮皮

目录