NoobyProtect SE1.7.0.0 脱壳之找OEP

不容易找到啊

NoobyProtectSE1.7.0.0脱壳之找OEP

Author:three-D

2010.3.16

昨天下午一朋友说碰到一个疑似盗号木马的东东加了NoobyProtect的壳搞不定，就让偶帮他看下。偶就抱着学习大牛作品和试一试的态度看了一下这个东东。嘿嘿，还不小心给俺脱掉了。下面就把偶找OEP的过程给大家分享一下。第一次写技术文章，有不对的地方欢迎大家拍砖。

（注：壳内部有NoobyProtectSE1.7.0.0Demo的字符串，具体是否真是NoobyProtect偶就不得而知了^_^

）

好了，言归正传

一、NoobyProtectSE1.7.0.0的特点

1.使用异常处理反调试

2.使用了代码变形技术

3.解密和导入表修复代码虚拟化保护

4.虚拟化过程有一个统一的出口（由于代码变形的原因，不同的文件加壳后，其虚拟化出口代码会不一样）

5.还原后的原代码在.text节

二、找OEP思路

俗话说“授人以鱼不如授人以渔”。我就给大家分享一下，偶脱这个壳的思路

（问题解决的过程实际上也是不断提出新问题，然后解决之，一步步逼近最终方案的过程，所以我们就已问答的形式来展开说明偶找OEP的思路。）

1.我们要找壳的OEP，那么OEP是什么？

OEP是原程序的入口，是壳代码和原始代码的分界。前面的分析我们知道NoobyProtect把原代码还原到.text节，从壳代码所在的节跳转到.text节的地方就离OEP不远了。

2.壳代码什么时候跳转到原代码执行？

这不是废话嘛，当然壳代码干完自己的事情之后啦。

不容易找到啊

3.那壳一般都做什么事情嘞？

解密原代码啦，修复导入表啦，需要重定位的根据重定位信息修复数据啦。

对于exe来说一般跳出修复导入表的循环后离OEP就不远了。对于dll最后一个步骤可能就是重定位数据了。

嘿嘿，经过上面的分析，你想到了什么？

<1>对修复导入表一般都会用到LoadLibrary，断LoadLibraryA定位修复导入表的循环，跳出来离OEP就不远了。(不过这个方法对本壳无效，因为他木有加密导入表)

<2>修复需要重定位的数据，肯定要修改数据的值了，那么内存写断点定位咯

4.那么多需要修复的数据，内存写断点断下来n多,我怎么找最后一个修复的点嘞？这个问题问的好！（臭鸡蛋……）

方法一:也是效率最低但很有效的方法——写脚本log修复的地址，记录的最后一个就是咯。

方法二:两次运行法。

把程序运行起来（没有人在真机里直接跑未知样本的吧），从.text节的末尾往上找保存本节的地址的地址。记下来几个这样的地址。再次加载样本，停入口处，go到我们记录的地址的地方，看该地址上的值是否我们之前记录的那个地址上的值一致，如果不是，恭喜你找到了最后一个从定位点，在这个地址上下内存写断点。如果是，那么这个就不是需要重定位的点，用相同的方法继续往上找。

当然你也可以在靠后的位置找一个符合上面描述的点下内存写断点（不一定是最后一个），然后写脚本log修复的点。（偶用的就是这个方法）

要是你还想再偷懒，也成，在.text节中查找字符串，在地址最大的那个上面下内存访问断点。然后对整段下内存写断点，去逼近最后一个修复点。

（靠，你表达太烂了，我都晕了都没明白。）呵呵，没明白没关系，后面我们具体操作里有演示，看了就明白了。

5.我找到最后一个修复点了，怎么找跳到.text的点？

方法一:Trace跟踪，设置Tracerunpauseoneipinrange的范围为.text节的范围。这种方法的缺点是要有个漫长的等待过程。偶是急性子，不愿等。所以就有方法二加速查找。

方法二:前面我们提到虚拟化过程有一个统一的出口。修复重定位数据的代码是虚拟化保护的，他要去执行还原后的代码，必须的从虚拟化过程中出来吧。嘿嘿，出来虚拟化过程中出来前我就逮住他，他就乖乖的带我去找OEP啦。

6.如何找到虚拟化返回点？

虚拟化保护的代码执行在他自己的一套环境中,在进入虚拟化过程前需要保存原来执行环境，并建立自己的执行环境。从虚拟化过程中出来是这个过程的反过程。在执行没有虚拟化

不容易找到啊

保护的代码前，要把执行环境还原到真实的环境。有人问了，花指令、垃圾跳转充斥的代码里你怎么找没有用虚拟化保护的代码？API嘛，你虚拟化，总不至于把系统的API代码也都给虚拟化了吧。所以断到API，出来之后的代码还是真实的执行环境。然后？从新进入虚拟化环境嘛，不然要你虚拟保护干嘛！一般进入虚拟化过程会是一个call，我们对call下面的地址下断，Trace跟踪之。在Trace的结果里我们很容易找到虚拟化过程返回的地址。

偶debode,debode了这么多，大家也都云里雾里了这么久。来点直观的吧，进入下一个环节——脱壳过程。

三、脱壳过程

1.使用StrongOD的SkipSomeExceptions(不知道为什么使用od自身的忽略异常会很慢，知道原因的童鞋可以告诉偶

)

图1

2.得到虚拟化函数的返回点

首先对VirtualProtect下断，F9运行之,

断到这里

图2

不容易找到啊

图

3

图4

这里是修改节解表中Characteristics所在内存的属性，然后修改之，修改过后再调VirtualProtect修改回来

然后从VirtualProtect

中返回

图5

我们看到VirtualProtect返回后有个Call1009A08E

来看一下Call1009A08E

里面的内容

图5

分析过虚拟化过程的童鞋可以看出这里是虚拟化过程的入口，如果不确定的话可以再跟进去看一看，这里我们就不多说了。

不容易找到啊

在虚拟化函数的返回地址上下断（对100D7785下断）如图5所示

按Ctrl+F11TraceInto，该函数返回后会断在100D7785处

下面我们看下Trace

跟踪的结果。

图6

从上面我们看到VM过程的出口是

10085A4D

图7

对100854D下断，可以观察脱壳过程中对API调用。

我们这里记下这个地址，或者先对其下断，然后先disable掉

到这里我们找到了虚拟化的返回点（如果虚拟化返回点不唯一的化，也可以通过类似方法得到）

3.

找到修复后的代码，并下断，防止意外跑飞（不是必要的）

图8

F9运行，断到修复代码的地方

不容易找到啊

图9

修复的代码如：

F9运行若干下以后就会有一部分修复好的代码,

我们随便找几个下断点

图10

4.找到最后一个修复的点

F9运行起来，断到10001000处，此时运行的已经是脱过壳的代码了。

我们在dump窗口中go到.text节，从后往前找其值为.text中地址的地址，如：地址10049994,其值100049998是落在.text节中。所以1003E7EB

有可能是需要修复点。

图11

下面就印证一下

重新加载样本，停在入口处。

在dump窗口中go到10049994

处

图12

不容易找到啊

我们看到地址10049994的值是为修复前的值50B4AC3D。所以10049994就是符合要求的需要修复点。但是这个不一定是最后一个。

我们对地址10049994下内存写入断点，F9

运行

图13

再次F9运行一次(由于重定位时修改两次修复点)

断下来后，取消10049994处的内存断点，然后在Memory窗口中对.text节下内存写断点。F9运行，如果直接跑到原代码里的话，恭喜你找到最后一个重定位点。如果没有，说明这个点不是最后一个重定位修复点。

下面我们运行下面的简单脚本来找最后一个重定位点

findloop:

run

cmpeip,100840E9

jnzExit0

logeax

jmpfindloop;

Exit0:

100840E9就是上面图13中修改重定位的代码的地址，运行该脚本的前提是对.text节下内存写断点，除了还原后代码里外的所有断点全取消。

最后我们从Log窗口中很容易找到最后一个修复点地址

10056DEE

图14

5.找到OEP

重新加载样本，对地址10056DEE下内存写断点。

不容易找到啊

F9

运行起来后断到

图15

再次F9运行一次(由于重定位时修改两次修复点)，没出意外的话还是断到上面的位置。还记得3.中我们得到的虚拟化返回点么？呵呵，这里该他大显身手了。对VM返回点下断，或enable原来的那个断点。

F9

运行，断到

图16

这个地方代码可能跟偶的不一样哦，只要用上面偶提到的方法找到的vm过程的出口就好。

单步返回

图17

跟过虚拟化的童鞋对这个应该很熟悉，是虚拟化的一部分，所以，这里不是跳转到OEP的真实代码（偶猜测是虚拟化嵌套了）

F9运行，再次断到vm

过程的出口

图18

再次单步返回，到这里

图19

呵呵，看到可爱的popad（当然可能是类似的恢复真实寄存器值的操作），胜利向我们招手了。

单步往下我们就看到熟悉的代码了

不容易找到啊

图

20

图21

我们从上面的代码可以看到入口处的代码pushesp被挪到了.text节之外。其他没有太大的变化。从入口可以清晰的看出是vc6编译的代码。

结束语：

到这里，我们的OEP就找到了。由于偶拿到的样本是个dll，加此壳的exe偶也没见过，所以偶上面提到的方法也不一定通用。

上面有不对的地方请兄弟们不吝赐教.

偶的EMAILE:zhanglei3019@

本文来源：https://www.bwwdw.com/article/yfk1.html