11.4.9  解析程序的参数

回到程序的主入口点函数，你会发现另一个NtDelayExecution调用，其后还紧跟着一个调用，这好像是程序入口点中（402082）调用的最后一个函数（而不是那个明显毫无用处的IsDebuggerPresent调用）。

当然，402082也是加了密的，所以你要在402198（就在用于解密的解密代码之后）处设置一个断点。在这个断点处，你一下子就会看到一段熟悉的代码（如果Olly此时显示的依然是垃圾数据而非代码，你可以试着跟踪到这些代码中看看它自己是否会自动更正过来，或者你也可以通过右键点击第一行并选择“Analysis”，或者选择“During next analysis, treat selection as  Command（在下次分析时，将所选代码当作命令来处理）”，来明确地告诉Olly将这些字节当作代码对待）。在接下来的代码中你会看到一个NtDelayExecution调用，后面紧跟着的代码加载了一个新的DLL：SHELL32.DLL。加载代码后面又是生成混乱的模块接口：在一个随机地址处分配内存空间，为每一个导出的SHELL32.DLL函数名计算校验和，然后将整个代码段拷贝到新分配的内存块中。所有这些工作之后，程序调用一个KERNEL32.DLL中的函数，这个函数是一个纯用户模式的实现，这迫使你只能使用函数索引的方法来让这个函数“现出原形”。我们最终确定出这个API是GetCommandLineW。实际上，GetCommandLineW返回一个指向我们的测试命令行的指针。

下面是对SHELL32.DLL中的一个API函数的调用。同样，这个SHELL32 API函数也没有直接调用内核函数，所以你又被某个长长的函数挡住了去路，你不知道这是个什么函数。这次你还得使用函数的索引来弄清Defender调用的是哪个API函数。这次查找的结果是CommandLineToArgvW函数。CommandLineToArgvW函数所做的是对命令行字符串进行解析并返回一个字符串数组，数组中的每一项都是一个单独的参数。Defender必须直接调用CommandLineToArgvW函数，因为Defender根本就没有使用通常情况下用来处理这些事情的运行库函数。

在CommandLineToArgvW调用结束后，你终于抵达了Defender中我们期待已久的区域：解析命令行参数的代码。

开始部分是一段比较简单的代码，用以验证参数的合法性。代码检查了参数的总数（由CommandLineToArgvW返回），确保参数的总数为3（Defender.EXE这个名字再加上用户名和序列号）。然后再检查第三个参数的长度是否为16个字符，如果不是16个字符，Defender将会跳转的位置与参数不是三个的所跳转的位置一样。再往后，Defender调用了在401CA8处的内部函数，这个函数验证这个16进制的字符串只包含数字和字母（可以是大写或小写）。该函数返回一个布尔值来指示这段代码号是否是一个合法的十六进制数。同样，如果返回值是0，代码将跳转到同一个位置（40299C），这个位置显然是“bad parameters（错误参数）”的处理代码。接下来的代码调用了另一个函数（401CE3）来确认用户名中只包含字母（可以是大写或小写）。这之后，你将会看到下面三行代码：

这三行代码执行后，EAX中存放的是用户名验证代码返回的值。如果EAX为0，代码将跳转至输入错误的处理代码（在40299C处）执行，如果EAX不为0，则跳转至402AC4，这里显然是输入正确的处理代码。需要注意的是，跳转到4029EC的这条代码又一次使用了CALL指令来跳过存放在代码中的字符串。在OllyDbg的“data”视图中快速查看一下位于这条CALL指令之后的地址，其内容显示如下：

看来，你显然已经找到了“bad parameters（错误参数）”消息的显示代码。没有必要再研究这段代码了——你应该直接进入“good parameters（参数正确）”的代码中，看看那里做了些什么。看起来你已经越来越接近目标了！