首页
论坛
专栏
课程

[原创]也谈PE-Armor0.49记事本的脱壳经历

2010-2-26 16:28 6061

[原创]也谈PE-Armor0.49记事本的脱壳经历

2010-2-26 16:28
6061
这两天研究这个壳,让我对壳的认识有了进一步的加深,特将脱壳的过程附上,与大家共勉,在此先得感谢每位指点我的人,学到新知识的确是让人开心的一件事!

这个壳本身到OEP不难,主要是壳的修复比较麻烦,因为这个壳抽掉了OEP,并且对CALL [XXX]的一些地方进行了硬编码,变成了CALL XXX,这样脱壳以后CALL的地址就不正确了!

加载以后,运行的话会发现产生了N多的异常,这里借用resty的方法,并加上自己的心得,给出一个简单的到OEP的方法:

1、        除INT3断点外,忽略所有异常。SHIFT+F9,运行:



2、        不忽略整数除0异常,SHIFT+F9运行:



3、        CTRL+F查找跳到OEP的命令 JMP EAX, 在其上F2下断点,SHIFT+F9运行:



这里就是跳向光明之巅!取消断点后,F8到OEP处。
然后就是体力劳动了,呵呵,正好这两天初学OllyScript,也就想用脚本来恢复CALL XXX!

我们首先要知道的是CALL XXX处 (原来是CALL [XXX])是如何还原:
F4到任意一个CALL XXX,然后在代码段下内存访问断点,这样就能跟踪到壳的处理函数处:



这在里,我们就知道了,原来壳是用一张表来处理CALL XXX的形式的。记下ESI的表头位址,不同的机器这个地址不一样,这张表以0000结束!在我这里这个地址就是

0x3A3474 这个表的大小是0X458,算一下壳一共处理了多少个函数?
0x458/4/2 =0x8B=139个!晕啊,想把人累死啊!!!!



没办法,只好学学OllyScript了,用脚本来恢复CALL,下面是自己写的恢复脚本,
呵呵,大侠们别笑,有好多命令不会用…… 采用原壳的解密算法,直接读取密表进行解码后恢复,下面是脚本的原型,虽然很丑,不过确实起到了减轻劳力的作用,哈哈

var passtableaddr
var vaddr
var nCount
var caddr
var encode

mov nCount, 0

lbFind:

find eip, #90E8#
cmp $RESULT, 0
je lbEnd

inc nCount
mov eip, $RESULT
add eip, 6
mov caddr, eip
mov passtableaddr, 3a3474

lbstart:
cmp passtableaddr, 3a38c4
jg lbFind
mov vaddr, [passtableaddr]
cmp vaddr, caddr
jne lbsearch
mov encode, [passtableaddr+4], 4
sub encode, vaddr
not encode
rol encode,10
mov [vaddr-6], #FF15#
mov [vaddr-4], encode

lbsearch:
add passtableaddr, 8
jmp lbstart

jmp lbFind

lbEnd:
   mov eip, 4010cc
   eval "共替换{nCount}处CALL"
   msg $RESULT
ret



然后恢复下OEP为如图的情况,直接DUMP即可,无需修复IAT,即可运行,PEID查看已经成功脱壳:



总结:以前以为到了OEP之后修复IAT成功了壳基本就脱完了,遇到这个壳让我觉得自己太浅薄了!

[公告]安全服务和外包项目请将项目需求发到看雪企服平台:https://qifu.kanxue.com

上传的附件:
  • 1.JPG (48.34kb,311次下载)
  • 2.JPG (69.63kb,311次下载)
  • 3.JPG (62.23kb,313次下载)
  • 4.JPG (60.72kb,309次下载)
  • 5.JPG (106.24kb,313次下载)
  • 6.JPG (58.83kb,308次下载)
  • 7.JPG (25.96kb,305次下载)
最新回复 (11)
xflin 2010-2-26 17:45
2
0
楼主可以考虑MAJIC JUMP法,

呵呵,解决IAT还比较特效

这种老壳应该有majic jump吧,没去研究去
不问年少 15 2010-2-26 20:00
3
0
我开始也这么想的,不过这壳不是那么做的,它并没有加密IAT,而是对CALL [XXX]代码进行了替换。而且一开始解码后并没有任何数据是 CALL 00000000,所以如果直接跳过替换的话,这里全是无效CALL……
resty 2 2010-2-26 20:08
4
0
你可以再试试看这个记事本的打开保存文件等功能是否正常
我在原帖补发了一个新脚本,因为那个替换的地方不光有 call [xxx] 还有 jmp [xxx]......
不问年少 15 2010-2-26 21:42
5
0
[QUOTE=resty;767305]你可以再试试看这个记事本的打开保存文件等功能是否正常
我在原帖补发了一个新脚本,因为那个替换的地方不光有 call [xxx] 还有 jmp [xxx]......[/QUOTE]

的确是这样啊这壳还真是有点烦人!
不问年少 15 2010-2-26 23:55
6
0
继续研究了一阵,原来还对菜单的七个函数进行了单独处理……,晕死!密表还是同一张,只不过在地址前加上了标记 80!

上传的附件:
  • 1.JPG (61.53kb,279次下载)
xflin 2010-2-27 13:16
7
0
难道不是在shellcode中处理的IAT,
到目前为止,我只认真看过烟兄的zp,是在加壳过程中替换的CALL,
所以没有MAJIC JUMP,不过寻找API的过程是直接写死的,ZP的IAT处理是一个不错的学习

上次得到S牛指点后,才发现这点的
芳草碧连 2010-2-27 20:14
8
0
能否帖上试炼文件^
resty 2 2010-2-28 09:02
9
0
试炼文件
http://bbs.pediy.com/upload/bbs/unpackfaq/unpackme.rar
xiaobaozi 1 2010-3-2 15:45
10
0
现在的壳都是在加壳的时候把代码给替换了
makeme 3 2010-3-3 21:17
11
0
找不到壳的处理函数。真愚笨。请教请教
芳草碧连 2010-5-29 15:48
12
0
到oep后 对代码段下内存访问断点,shift+f9就到了
游客
登录 | 注册 方可回帖
返回