软件解密技术研究

—-Windows PE 文件脱壳

通过设置Hook，动态跟踪堆栈，对加过壳的可执行文件进行解密还原。

 

当然，要解密，至少先要—-得到一个被加密过的“正版” 软件。

然后—-编写简单的Debugger。

 

仅需要拦截LoadLibray/GetModuleHandle/GetProcAddress，在这三个Hook中执行记录Library文件名，Procedure(导入函数)名。自己按ImportTable结构伪造一个ImportTable，并存储额外的相关信息。

为每个导入函数生成一个Hook函数体，该函数(我们的Hook) 从堆栈中取得返回地址(即调用该函数的call指令的下一条指令的地址) ，对返回地址的前一条指令(即调用该函数的call指令)进行译码，一般是如下可能的形式：

   call   jump_thunk

   call   [thunk_fun]

   call   reg         ；为简单，先忽略此形式

   call   [reg]       ；为简单，先忽略此形式

   call   [reg + thunk_offset] ；为简单，先忽略此形式

其它奇奇怪怪的形式完全忽略不考虑，如

   push   offset ret_address

push   fun_address

ret

ret_address:

或：

   push   offset ret_address

jmp    fun_address

ret_address:

关键的难点在这里，很有可能在此处出现问题，因为反向译码有可能把一个地址错误的当成指令译码了(不过这种情况很少) 。如果忽略这些问题，则这一个难点就OK了。

称返回地址的前一条指令，即调用该函数的call指令，为caller_entry。

   caller_entry指令的bin code为：op XXXXXXXX，其中XXXXXXXX为转向地址。我们的hook code都做些什幺工作呢？

1.      读出caller_entry及其附近一些bin code并写入我们的crack文件，为其后进一步分析用，当然该指令中XXXXXXXX会被记录下来。

2.      由于动态自动跟踪不可能跟踪到所有调用Import Function的地方，但几乎可以跟踪到对至少一个Import Function的一次调用。所以改动XXXXXXXX(即jump_thunk或fun_thunk的值)可能不太实际，于是只有—-

3.      对 jump jump_thunk，我们走到jump_thunk，这里一般是
”call [fun_thunk]” 的形式。

4.      把fun_thunk写入我们的Crack文件，为进一步分析使用。

5.      在这样的过程中我们需要用户尽量遍历“该正版软件”所有的操作路径(如点文件>存储/另存，编辑>复制/粘贴…

6.      用户点击Debugger的“遍历结束” 按钮，就可以把整个PE Image Dump出来。

然后，点击Debugger的“分析&破解” ，即可分析我们生成的Crack文件。

分析过程中的主要操作是：

1.      修改 Dump出来的内存，主要是PE Header和Section Table。

2.      走到fun_thunk，把[fun_thunk] 改为我们的hook地址。

该脱壳软件的特点(区别与其它脱壳软件)基本上只有一点：其它脱壳软件都是想办法取得残留的ImportAddressTable或ImportNameTable，从其中做文章。

而该软件是从程序的运行中获得实际的thunk地址，并自己构造ImportTable。

其实一切都很简单!
后记：

本人一年前作“软件加密技术及实现” 为毕业论文，工作一年来，因专注于工作，几乎已经废弃了加密的研究。

不久前有朋友说：“你就会加密，你怎知你加密的不能被别人破解？” 于是又老毛病大发，连做梦都想：用什幺办法可以使别人不能破解？想来想去，总不能找到完全之策。最后终于想到了一个：“地址加密” 方法，即把ImportFunction的地址加密，调用ImportFunciton时，先解密地址再跳转到ImportFunciton，具体实现如下：

写一个Hook Code，把ImportAddressTable中的地址填为该Hook Code的地址，于是对应与每一个ImportAddressTableEntry，都有一个Hook Code的副本，该Hook Code对加密过的地址进行解密，然后再跳转过去。该Hook Code让它(cracker) 总不能从 PE Image中得到任何ImportFunction的地址。

我自以为此方法完美无缺，然而不久我又想到了破解方法，即此文所描述的。

于是，很快，我又找到了另外一种方法来对付这种破解—-

在HookCode开始，把返回地址(即文中所说的call_entry) 加密，然后为被调函数(即该ImportFunction) 建立一个新的StackFrame，再把call_entry之前传来的参数拷贝到新的这个StackFrame中。然后调用ImportFuncion。

然而此方法也有问题—-我实际上不知道被调函数有几个参数。

所以我为它创建StackFrame时，只能把该StackFrame建得足够大，可以容纳参数最多的函数—-如我假设它至少有100个参数，于是这会浪费较多的堆栈区，幸好这里不会有递归调用，否则堆栈有可能溢出。这个问题暂时得到了解决。

然而又出现了另外一个问题—-当被调函数返回，我不知道它到底跳过了几个参数(ImportFunction一般是stdcall，跳过参数区的责任由被调者完成) 。即被调函数返回后，ESP的值与调用前不同。

幸好，函数调用不会改变ESI，EDI，EBX，EBP的值，我只要选用这其中的一个寄存器，如EBP，然后用他存储调用前的ESP(当然要先把它存入堆栈而后在恢复)。再调用ImportFunction，待它返回后，
ParamSize =(StackFrameSize ?C (EBP ?C ESP)) 就是被调者跳过的参数区的尺寸。

然而又有问题：此刻怎幺返回？我必须跳过参数区呀! 如果我可以生成一条指令ret ParamSize—-(ParamSize必须是立即数) ，就可以了。

但又有问题—-这样的代码是不可重入的!

没办法了吗？当然有，这样的代码可以完成ret ParamSize的功能：

    add    ESP, ParamSize

    jmp    [ESP ?C ParamSize] ;此刻，该返回地址已经解密.

一切OK!!

此加密方法，征求破解!!