未脱壳的代码如下图所示:
401535前面都是壳代码,从call eax进入到实际代码运行,从7ff8165c开始,但是实际代码运行后下api断点都断不来
从7ff8166b这个调用跟进去,发现它指向了一个mov edi,edi,然后跟转到kernel32中去
问题就在这里,它是先跳到一个跳板内存里,跳板内存直接跳到api入口往后偏移两个字节的指令,因为前面两个字节指令是无实际意义的mov edi,edi,但是api断点是自动设到这里的,它这样跳转后,api断点就被它绕过去了。
7ff80000本来是iat指向的内存,这里被它偷梁换柱,先转到一块跳板内存,再跳转到api函数地址+2
先来修复一下这个iat表吧
通过patch前面的壳代码,让这里的iat表直接指向api函数地址
正常的导入表内存:
再次运行到call eax后,已经可以直接看到调用的api函数名字了
到这里如果创建一个虚拟机快照,纯OD来分析已经比较方便了。但是如果要用IDA来分析话,就必须把这个进程DUMP出来并修复好。但是问题来了,这块7ff80000内存是后来申请的内存,它本身并不是一个PE结构,原始PE也没有这个节,直接dump full出来的文件,是没法修复的。
danteng了一下,方法还是来了。没有这个节,就给它加个节吧
先还是dump full
然后把7ff80000这个内存也dump出来
通过ffi给这个PE加个section
修改virtual Offset,这里要用7ff80000减去400000
好了,现在可以用import rec来 fix dump了,这里把rva手动指向到7ff80000的相对偏移
再把dumped_exe的入口改一下,前面import rec上直接改也可以
OK,搞定了,用IDA打开看一下,很爽吧
这个病毒的原体还是挺强悍的,.net加壳方式可以过掉360主防,而且免杀比较方便。
本文出自 “燕十二” 博客,请务必保留此出处http://chenjava.blog.51cto.com/374566/1573925