高级破解Defender教程图解

Defender 与底层操作系统的集成非常紧密，而且是专门为基于 NT 的 Windows 系统设计的。它能在当前所有 NT 系系统中运行，包括 Windows XP、Windows Server 2003、Windows 2000 和 Windows NT 4.0，但在非 NT 系的操作系统（比如 Windows 98 和 Windows Me）上就不行了。 好，先实际跑一下 Defender.EXE 看看效果。这个程序是一个控制台模式的应用程序，也就是说它需要在命令提示符窗口里运行。之所以把它做成控制台程序，主要是为了简化编写过程——当然，在普通 GUI 应用程序里也能构建同样强大的保护机制，但写代码会花上更多时间。需要说明的是，控制台应用程序可不是 DOS 程序！基于 NT 的系统可以用 NTVDM 虚拟机运行 DOS 程序，但 Defender 不需要这个。像 Defender 这样的控制台程序其实是标准的 32 位 Windows 程序，只不过它避开了 Windows GUI API 函数（实际上它完全可以调用其他任何 Win32 API 函数），只通过简单的文本窗口和用户交互。 在命令提示符下运行 Defender.EXE，就会看到它的使用说明消息。图 11.10 展示了默认的用法提示。 500)this.width=500" title="点击这里用新窗口浏览图片" /> 图 11.10 不带命令行参数运行 Defender.EXE Defender 可以接收一个用户名和一个 16 位的十六进制序列号。现在试着给它输入一些假的值，看看会怎样。图 11.11 展示了输入用户名为 John Doe、序列号为 1234567890ABCDEF 后 Defender 的响应。 毫无悬念——Defender 只是简单报告序列号错误。在破解过程中，这一步很有必要，至少能让你看到程序在收到错误注册信息时会抛出什么样的错误消息。你应该能在可执行文件的某个地方找到这条错误消息。 接下来把 Defender.EXE 加载到 OllyDbg 中看一看。第一步是查看“Executable Modules”窗口，确认有哪些 DLL 静态链接到了 Defender。图 11.12 显示了 Defender 的模块列表。 500)this.width=500" title="点击这里用新窗口浏览图片" /> 图 11.11 将用户名 John Doe 和序列号 12345678ABCDEF 作为参数运行 Defender.EXE 500)this.width=500" title="点击这里用新窗口浏览图片" /> 图 11.12 （从 OllyDbg 中看）静态链接到 Defender 的可执行模块 500)this.width=500" title="点击这里用新窗口浏览图片" /> 图 11.13 （从 OllyDbg 中看）Defender.EXE 的导入与导出函数 这个列表非常短——只有 NTDLL.DLL 和 KERNEL32.DLL 两项。回想我们之前提到的图形界面 crackme 程序 KeygenMe-3，它的可执行模块列表要长得多，不过 Defender 只是一个控制台程序，这也说得过去。接着看看“Names”窗口，确认一下 Defender 调用了哪些 API 函数。图 11.13 展示了 Defender.EXE 的“Names”窗口。 确实很奇怪，Defender.EXE 似乎只从 KERNEL32.DLL 中调用了 IsDebuggerPresent API 函数。不用太多推理就能猜到，这不太可能是真的。除了调用 IsDebuggerPresent 之外，程序一定还通过其他方式和操作系统通信——比如，如果没有调用操作系统的函数，它怎么在控制台窗口上输出信息？这显然不可能。再用 DUMPBIN 处理一下这个程序，看看 Defender 的导入表里都有些什么。列表 11.4 显示了用 /IMPORTS 选项的 DUMPBIN 输出。 500)this.width=500" title="点击这里用新窗口浏览图片" /> 列表 11.4 用 /IMPORTS 选项对 Defender.EXE 运行 DUMPBIN 的输出 500)this.width=500" title="点击这里用新窗口浏览图片" /> 列表 11.4 依然没有新发现。DUMPBIN 的输出也表明 Defender.EXE 只调用了 IsDebuggerPresent。不过有一个有趣的地方——Summary 段，DUMPBIN 在这里列出了该模块的各个段。我们发现 Defender 没有 .text 段（通常 PE 可执行文件的代码就放在 .text 段中），反而有两个奇怪的段：.h3mf85n 和 .h477w81。这并不意味着程序里没有代码，只是说明代码很可能藏在这两个名字奇怪的段里。 这时候比较明智的做法是用 /HEADERS 选项再跑一次 DUMPBIN，看看 Defender 是如何创建的（见列表 11.5）。 500)this.width=500" title="点击这里用新窗口浏览图片" /> 列表 11.5 用 /HEADERS 选项对 Defender.EXE 运行 DUMPBIN 的输出 500)this.width=500" title="点击这里用新窗口浏览图片" /> 500)this.width=500" title="点击这里用新窗口浏览图片" /> 500)this.width=500" title="点击这里用新窗口浏览图片" /> 500)this.width=500" title="点击这里用新窗口浏览图片" /> 500)this.width=500" title="点击这里用新窗口浏览图片" /> 500)this.width=500" title="点击这里用新窗口浏览图片" /> 500)this.width=500" title="点击这里用新窗口浏览图片" /> 500)this.width=500" title="点击这里用新窗口浏览图片" /> 500)this.width=500" title="点击这里用新窗口浏览图片" /> 500)this.width=500" title="点击这里用新窗口浏览图片" /> 列表 11.5 在 /HEADERS 选项下，DUMPBIN 为我们提供了有关 Defender.EXE 程序的更多细节。比如，很容易看出 #1 段（即 .h3mf85n）就是代码段——它被标识为 Code，而且程序入口点就在这里（入口点在 404232，.h3mf85n 从地址 401000 开始到 4042FF 结束，所以入口点在这个段内）。另一个名字奇怪的段 .h477w81 看起来像是一个小型数据段，可能包含一些变量。还需要提一下的是子系统标志（subsystem flag）等于 3，说明这是一个 Windows 控制台用户界面（CUI）程序，Windows 在运行这个程序时会自动为它创建一个控制台窗口。 所有这些奇怪的段名都说明程序很可能经过了某种加壳处理（packed）。加壳程序能够创建包含加壳后的代码或用于脱壳的代码的特殊段。有个好办法——通过 PEiD 运行程序，看它是否被未知的加壳程序加过壳。PEiD 可以识别常见可执行文件的特征码，并显示这个文件是否使用流行的可执行文件加壳程序或拷贝保护产品做过加壳处理。可以从这个网址下载 PEiD：http://peid.has.it/。图 11.14 显示了 PEiD 处理 Defender.EXE 时的输出。 不幸的是，PEiD 报告“Nothing found”，所以可以有把握地说 Defender 没有做过加壳处理，或者说被一个未知的加壳程序加过壳。接下来对这个程序进行反汇编，找找“Sorry … Bad key, try again.”这条消息是从哪里来的。 500)this.width=500" title="点击这里用新窗口浏览图片" /> 图 11.14 用 PEiD 程序处理 Defender.EXE 时报告“Nothing found”