结束是为了开始，再见是为了遇见，日落是为了日出。那，我应该为谁而出现？为自己，还是为他人？
Defender与底层操作系统紧密集成在一起，且它是专为在基于NT的Windows系统中运行设计的。它可以在当前所有基于NT的系统中运行，包括Windows XP、Windows Server 2003、Windows 2000和Windows NT 4.0，但不能在非基于NT的操作系统中运行，如Windows 98和Windows Me。
我们先运行一下Defender.EXE程序，看看会发生什么事。需要指出的是，Defender是一个控制台模式的应用程序，所以通常它要在命令提示符（Command Prompt）窗口中运行的。我之所将Defender设计成为一个控制台模式的程序，是因为这大大简化了Defender程序的编写。当然，我们也可以在普通的GUI应用程序中创建一个同样强大的保护，但写代码要花更长的时间。有一点需要指出的是，控制台模式的应用程序并不是DOS程序！基于NT的系统可以用NTVDM虚拟机运行DOS程序，但对Defender程序不需要NTVDM虚拟机。像Defender这样的控制台程序是一般的32位Windows程序，它只是避开使用Windows GUI API函数（实际上它可以调用其他任何一个Win32 API函数），只使用简单的文本窗口与用户进行通信。
你可以在命令提示符窗口中运行Defender.EXE，并会收到Defender的使用方法的消息。图11.10显示了Defender的默认使用方法的消息。
图11.10 不带命令行参数运行Defender.EXE
Defender程序可以接收一个用户名和一个16位的十六进制序列号。现在，我们给它输入一些编造的值作为参数，看看会发生什么。图11.11显示了当我们输入用户名为John Doe、序列号为1234567890ABCDEF后Defender的响应。
毫无悬念——Defender只是简单地报告我们的序列号是错误的。在做破解的时候，试试这个步骤是有必要的，至少你能看到程序在接收到错误的注册信息会报告什么样的错误消息。你应该能够在可执行文件的某个地方找到这个错误消息。
我们将Defender.EXE加载到OllyDbg中看看。你要做的第一件事就是查看“Executable Modules”窗口以确定有哪些DLL静态链接到了Defender。图11.12显示了Defender的“Executable Modules”窗口。
图11.11 将用户名John Doe和序列号12345678ABCDEF作为参数运行Defender.EXE
图11.12 （从OllyDbg中看）静态链接到Defender的可执行模块
图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的输出。
列表11.4 用/IMPORTS选项对Defender.EXE运行DUMPBIN的输出
列表11.4
这儿也没有什么新的发现。DUMPBIN的输出也表明Defender.EXE只调用了IsDebuggerPresent。不过，这里还有个有趣的地方，那就是Summary段，DUMPBIN在这里列出该模块的各个段。从这里我们发现Defender没有.text段（通常PE可执行文件中的代码就放在.text段中）。相反，它有两个奇怪的段：.h3mf85n和.h477w81。这并不是说程序中没有任何代码，这只是说明代码很可能就躲在这两个名字奇怪的段中。
在这个时候，聪明的做法是用/HEADERS选项再运行一次DUMPBIN，来看看Defender是怎样创建的（见列表11.5）。
列表11.5 用/HEADERS选项对Defender.EXE运行DUMPBIN的输出
列表11.5
在/HEADERS选项条件下DUMPBIN为我们提供有关Defender.EXE程序的更多细节信息。例如，容易看出#1段（即.h3mf85n）就是代码段。它被指定为Code，而且程序的入口点就在这里（入口点在404232，.h3mf85n从地址401000开始，到4042FF结束，所以我们知道入口点就在这个段内）。另一个名字奇怪的段.h477w81看上去像是一个小型的数据段，可能包含一些变量。还需要提一下的是子系统标志（subsystem flag）等于3，说明这是一个Windows控制台用户界面（console user interface，CUI）程序，Windows在运行这个程序的时候会自动为它创建一个控制台窗口。
所有这些奇怪的段名都说明了程序很可能是经过了某种加壳处理（packed）。加壳程序能够创建包含加壳后的代码（packed code）或用于脱壳的代码（unpacking code）的特殊段。有个不错的方法——通过在PEiD中运行程序来看它是否被一个未知的加壳程序做过加壳处理。PEiD程序可以识别常见的可执行文件的特征码（signatures），并显示这个可执行文件是否用流行的可执行文件加壳程序或者拷贝保护产品做过加壳处理。你可以从下面这个网址下载PEiD：http://peid.has.it/。图11.14显示了PEiD处理Defender.EXE时的输出。
不幸的是，PEiD报告“Nothing found”，所以可以有把握地说Defender没有做过加壳处理，或者说是被一个未知的加壳程序做的加壳处理。我们接下来对这个程序进行反汇编，找找“Sorry … Bad key, try again.”这条消息是从哪里来的。
图11.14 用PEiD程序处理Defender.EXE时报告“Nothing found”
本文高级破解Defender好代码教程（图） 到此结束。时间并不会真的帮我们解决什么问题，它只是把原来怎样也想不通的问题，变得不再重要了。小编再次感谢大家对我们的支持！
