软件解密技术研究

软件解密技术研究

—-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_thunkfun_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 HeaderSection Table

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

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

而该软件是从程序的运行中获得实际的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的值与调用前不同。

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

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

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

没办法了吗?当然有,这样的代码可以完成ret ParamSize的功能:

    add    ESP, ParamSize

    jmp    [ESP – ParamSize] ;此刻,该返回地址已经解密.

一切OK!!

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

 

作者:
该日志由 rockeet 于2003年07月31日发表在操作系统分类下, 你可以发表评论,并在保留原文地址及作者的情况下引用到你的网站或博客。
转载请注明: 软件解密技术研究
标签:
【上一篇】
【下一篇】

您可能感兴趣的文章:

发表评论

您必须 登录 后才能发表评论。