ftofficer|张聪的blog

【这篇文章就是我在twitter上说过的那篇文章，早已写好，但由于一些原因压到现在才发表，深表歉意】

众所周知，Windows的几乎所有带有字符串参数的API都是有W和A两个版本，分别对应于Unicode和ANSI版本。同时，Windows内部是使用Unicode的，因此所有的A版本的API函数都是实际上调用了一次ANSI到Unicode的字符集转换之后，再调用Unicode版本的函数。

你真的清楚这中间的这一步转换吗？普通的工程师确实不需要了解太深刻，但是我们是做安全软件的，安全软件的一个基本实现机制就是Hook，就是在原本的API调用路径上面拐一个弯，改变原本的API执行流程，以便在其中插入安全检查等逻辑。

这当中，如果没有对于所要Hook的函数的深刻理解，也许会有很多看似灵异的事件出现。在我们的代码当中，我们就使用了Hook的机制，然后很幸运的（很不幸？），遇到了这样一个灵异问题：

在测试当中，发现某个软件一旦被我们Hook，就总是崩溃。必现的崩溃总是很容易解决的定位的，很快，我们发现崩溃来源于下面一个调用序列：

HMODULE hMod = LoadLibraryA("Kernel32");
PROC pfxIsWow64Process = GetProcAddress(hMod, "IsWow64Process");

对LoadLibrary的调用返回没有检查返回值，进而继续调用GetProcAddress。那么，当hMod = NULL的时候，GetProcAddress并不检查hMod是否是0，而直接试图去寻找其中的导出表，于是导致了非法的内存访问。

但是，这里的代码当中，调用的是LoadLibraryA(“kernel32”)，kernel32.dll作为系统的核心链接库，通常情况下几乎必然是已经加载到了进程空间当中，即使没有，加载此DLL也不应该失败。

但是调试的结果显示，这个返回值的确是NULL，看起来相当灵异。但是我们相信，计算机没有灵异事件。为了排错，我们祭出WinDbg和IDAPro，从汇编层面一步步跟踪LoadLibraryA函数，看看中间究竟发生了什么。经过漫长的错误定位工作，在此略过不表（关于整个排查过程可以写一篇专门的文章），我们终于发现了问题的所在。

没错，加载了Hook就会造成崩溃，因此崩溃的原因在于Hook。

我们使用Inline Hook技术修改了LoadLibrary函数的执行流程，使得在进行真正的DLL加载之前进行某些校验和检查的工作。LoadLibrary函数其实是一个函数族，包括LoadLibraryA，LoadLibraryW，LoadLibraryExA，和LoadLibraryExW。它们之间的调用关系如下图：

我们选择了在整个调用依赖树的最底端的LoadLibraryExW的入口点作为Hook点，当一个函数调用LoadLibraryExW的时候，其实是调用到我们的Hook函数，Hook函数再调用真正的LoadLibraryExW，经过Hook，一个典型的LoadLibraryA的调用流程如下图：

问题就出在了这个CheckLibrary函数里面。在这个函数里面，我们调用了一个公共模块当中的日志函数，这个日志函数的逻辑是，以追加模式打开一个日志文件，写入然后关闭。且不论这个日志函数这样做的合理性，先来看看这段代码：

void Log(const char* msg) {
FILE* pf = fopen(_g_log_file, "a");
fprintf(pf, "%s\n", msg);
fclose(pf);
}

非常直观的程序，怎么会带来问题呢？我们来继续分析fopen函数。fopen函数是c库提供的文件IO函数，最终调用到Windows API CreateFileA，然后CreateFileA会调用到CreateFileW。把这个调用关系加上，调用序列如下图所示：

在这个函数调用序列当中，存在两次ANSI 到 Unicode 的转换，即图中标记有五角星的两个地方。那么我们来看看两个转换的代码是什么样子的：

LoadLibraryExA:

CreateFileA

注意到其中高亮的部分了么？两个函数在进入之后，都调用了一个公共的函数 _Base8bitStringToStaticUnicodeString，从名字就可以看出来，这段代码负责将输入的ANSI字符串转换为Unicode。那么这个函数做了什么呢？跟进去看看（这个使用了Hex-Rays的反编译功能，看得更清楚一点）：

再仔细看给RtlAntiStringToUnicodeString这个函数传入的参数地址pUnicodeString，来自*MK_FP(__FS__, 24) + 3064，这是Hex-Rays的表示法，其实对应下面一串汇编序列（由于编译器的优化导致的乱序，重点看红线标出来的指令）：

large fs:18h 这句魔法一样的指令，其实是 TEB 的地址。这个地址对于同一个线程来说是一样的，因此，如果在一个线程当中调用这个函数，总是会引用到同一个地址，这个地址就是当前线程的TEB当中的一个静态缓冲区（StaticUnicodeString & StaticUnicodeBuffer）。

很明显，这个静态缓冲区的作用是性能优化，对于ANSI到Unicode的转换，复用一个thread-specific的缓冲区来接受目标Unicode字符串。对于不太长的函数参数字符串，这个优化可以避免一次堆分配的过程，对性能的提升是很明显的。正常情况下这个优化是合理而且有效的。但是在存在Hook的情况下，事情就不是这么简单了。考虑一下上面那张图当中的LoadLibrary的调用序列：

解释一下：

1. 在第1次ANSI到Unicode转换的时候， LoadLibraryA将目标Unicode字符串 L”kernel32″ 存入 StaticUnicodeBuffer，然后将这个字符串的首地址传递给LoadLibraryW
2. LoadLibraryW在调用到LoadLibraryExW之前，先调用到了Hook函数
3. Hook函数调用到了CreateFileA，传入日志文件名（ANSI）作为函数参数
4. CreateFileA进行第二次ANSI到Unicode转换，将目标Unicode字符串（日志文件名）存入了StaticUnicodeBuffer，然后将这个字符串首地址传给CreateFileW
5. CreateFileW返回，
6. CreateFileA返回，
7. Hook函数返回，
8. 调用到实际的LoadLibraryExW。此时LoadLibraryExW从参数指针当中取出字符串试图进行加载动态库的操作，但是，它取出的是被在第4步当中覆盖掉的字符串，也就是Unicode版本的日志文件名！试图加载日志文件，自然会收到LoadLibrary失败的返回。‘
9. LoadLibraryExW返回NULL，LoadLibraryW返回NULL，LoadLibraryA返回NULL。

然后，没有检查LoadLibraryA返回值的程序，在调用GetProcAddress的时候，biu~ 掉了。

好了，知道了为什么，怎么解决也就很容易了，在CheckLibrary当中，先备份传入的参数的内容，然后继续走流程，等到需要调用原本函数的时候，将备份的参数传给原本函数。

这就是Hook爱好者们的义务：当你试图改变某个执行流程的时候，请务必清楚地了解关于这个流程的一切。