脱壳后软件无法运行原因分析与对策

脱壳后软件无法运行原因分析与对策一、脱壳是否成功的标志一般说来，对软件脱壳是不会改变原软件的运行机制的。它只是将加密的IAT地址还原成装载前的API函数名字串的地址，并以明码方式显示。脱壳是否成功的标志是软件运行前图标和脱壳前一致、运行时windows并未发出“……，初始化失败……”的警告，那么脱壳大体是成功的。若出现初始化失败警告，则百分之百是IID表或IAT表搞错了。二、用OD加载时出现“异常”或直接运行时，windows弹出“发送错误报告”消息。原因：（1）OEP入口地址错误；（2）在手动脱壳时“张冠李戴”，把某函数的地址写到了另一个函数的地址上去了。三、软件一运行就退出1．原因：（1）如果脱壳前软件能（直接）运行，脱壳后软件一闪而过，说明软件有“文件校验”。软件脱壳前后的最大变化是文件尺寸变化，那么软件的“校验和”一定要发生变化，当它发现“校验和”变了时，知道了你对软件“动了手脚”，它就毫不犹豫地退出了。若这时你想找到“文件校验”的位置，无异于大海捞针！（2）如果脱壳后能直接运行，但用OD加载时就退出或有无法跳过的异常，则是有“反跟踪”部件。（这和脱不脱壳没有关系）反跟踪不是本文今天讨论的内容，只是附带说一声。2．对策：在一个软件中去找出它的“文件检验”代码在什么地方，同样得用“思想”，和破案也差不多。别急，先看看它是什么语言编写的。若是用“VC++”或“Delphi”编写的，则脱壳后的软件对于使用者，则基本上没有秘密可言。唯一的是它们的“call”嵌套太深，要进行底层的跟踪，很容易跟丢。举个例子，说明跟踪方法。有个商业软件，脱壳前可以运行，脱壳后就不能运行了。它是用“VC++”编写的。3．破解思路：用“VC++”或“Delphi”来编写软件，有它快捷方便的一面。但是，因为它不能直接对内存进行操作，所以灵活性受到很大影响。例如，它就不能对运行中的内存文件进行“校验和”检验，若非要检验，除非在VC编程中嵌入ASM代码，但这样一来，地址的起点和终点难于确定，且给调试带来麻烦。一个变通的办法是：打开同一文件的一个“副本”，检验它“副本”的“校验和”也可以达到对自身检验的目的。这样一来，软件的秘密也就暴露无遗了，用OD来查看(已经脱壳的)软件怎样打开另一个文件，那实在是“再容易”不过的事情了！4．具体操作：（1）用OD打开要跟踪的软件，右键打开搜索“所有模块间的调用”，在所有“CreateFile”和“ReadFile”的调用地址上设断点。（2）运行OD，按“F9”，中断在一个CreateFile上：CreateFile中断：（该函数的返回值是被打开文件的句柄）……………………………………………………………………0013E7080013E90C|FileName = E:\xxxx\New_xxxxxxx.exe0013E70C|Access = GENERIC_READ0013E710|ShareMode = FILE_SHARE_READ|FILE_SHARE_WRITE0013E714|pSecurity = NULL0013E718|Mode = OPEN_EXISTING0013E71C|Attributes = NORMAL0013E720\hTemplateFile = NULL……………………………………………………………………以上是堆栈中的显示，其中，FileName = E:\xxxx\New_xxxxxxx.exe是将要打开的文件。若不是正在运行中的同名文件，则继续按“F9”。其余的参数是打开方式，不重要。监视CreateFile中断的另一个收获是知道了该软件在硬盘上写入了哪些文件，比如注册表中、系统文件夹中等（我最讨厌那些在硬盘中乱写文件的软件）。更重要的是，若软件有“反跟踪”代码，那么“CreateFile”或“FindWindow”等API函数调用时，它明码显示的文件名或窗口名是某个“调试软件”，就表明它在“反跟踪”，若发现了它们，相应的“反—反跟踪”措施也应该不是太困难的事。当然，高明的作者用VC也会让你伤透脑筋。当FileName=“正在运行的文件名时”， 再按“F9”来到ReadFile的中断上：ReadFile中断：…………………………………………………………0013E708000001C0|hFile = 000001C00013E70C0013EA10|Buffer = 0013EA100013E710|BytesToRead = 1000 (4096.)0013E7140013E71C|pBytesRead = 0013E71C0013E718\pOverlapped = NULL0013E71C0013E7200013E724004C5CD7 0013E7280000016F；调用次数记录……………………………………………