关于Windows应用程序加载DLL的总结

0x00 背景

最近在开发项目上遇到一个奇怪的问题，项目使用到OPENSSL库，进行加密，某个DLL(A.DLL)对该库进行封装后调用。EXE对A.DLL采用动态链接的方式进行加载，调动里面的函数之后，使用FreeLibrary释放DLL。
结果竟然没有卸载掉该DLL。这就突破了我的认知了，我的见识里面所了解到的加载DLL方式包括两种：

1. 隐式链接：程序运行时DLL被加载进来，等待程序结束之后，卸载加载的DLL。
2. 动态链接：程序使用LoadLibaray(Ex)等函数加载DLL，到不需要时主要使用FreeLibrary卸载DLL。

关于以上两点的详细介绍，请参见其他文章。

0x01 调查

程序使用了如下所示的伪代码：

int main()
{
    HMODULE h = LoadLibraryA("DLLName");
    if (h != NULL)
    {
        Function func = reinterpret_cast<Function>(
                GetProcAddress(h, "FunctionName")
            );
        if (func != NULL)
        {
            func();
        }

        FreeLibrary();
    }
    return 0;
}

经过单步注释代码的方式（很傻），发现只有在调用DLL里面的函数的时候，问题才会发生。那么只要把焦点放在DLL的这个函数上就好了。
可是结果没有这么简单，这个DLL也是OPENSSL的一个包装而已，并没有实际的代码。可是眼下并没有OPENSSL的源码，只能是调试调查了。

在调试之前，要想好目标才行，想着DLL是有引用计数的，那看看，在加载的时候，引用计数是多少。
使用windbg的!dlls命令查看DLL的引用计数、在LoadLibrary之后，看到此时DLL的引用计数是1，然而在
调用过DLL里面的函数之后此时DLL的引用计数变成了0x0000ffff了!

那么这个0x0000ffff代表着什么呢？经过查找资料，发现它是代表着DLL被隐式链接的。这就奇怪了，明明是动态加载的，怎么变成隐式链接了呢？

接下来的目标是查看这个引用计数是什么时候被改变的，经过查找资料找到了，如下的结构

struct _LDR_MODULE
{
    LIST_ENTRY InLoadOrderModuleList;
    LIST_ENTRY InMemoryOrderModuleList;
    LIST_ENTRY InInitializationOrderModuleList;
    PVOID BaseAddress;
    PVOID EntryPoint;
    ULONG SizeOfImage;
    UNICODE_STRING FullDllName;
    UNICODE_STRING BaseDllName;
    ULONG Flags;
    USHORT LoadCount;  <------看这里
    USHORT TlsIndex;
    LIST_ENTRY HashTableEntry;
    ULONG TimeDateStamp;
} LDR_MODULE, *PLDR_MODULE;

有了这个信息，结合Windbg自身手册里面提供的一个脚本内容：

$$ Get module list LIST_ENTRY in $t0.
r? $t0 = &@$peb->Ldr->InLoadOrderModuleList
 
$$ Iterate over all modules in list.
.for (r? $t1 = *(ntdll!_LDR_DATA_TABLE_ENTRY**)@$t0;
 (@$t1 != 0) & (@$t1 != @$t0);
      r? $t1 = (ntdll!_LDR_DATA_TABLE_ENTRY*)@$t1->InLoadOrderLinks.Flink)
{
    $$ Get base address in $Base.
 as /x ${/v:$Base} @@c++(@$t1->DllBase)
 
 $$ Get full name into $Mod.
 as /msu ${/v:$Mod} @@c++(&@$t1->FullDllName)
 
 .block
    {
        .echo ${$Mod} at ${$Base}
    }
 
    ad ${/v:$Base}
    ad ${/v:$Mod}
}

其实上面的LDR_MODULE就是_LDR_DATA_TABLE_ENTRY，那就好办了，找到相应的DLL对应的结构地址，
使用ba w1下断点，运行之后，看到了调用栈里面出现了GetModuleHandleEx函数，它的第一个
参数是5，是如下两个值得组合(或)

• GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS (0x00000004)
• GET_MODULE_HANDLE_EX_FLAG_PIN (0x00000001)

其中MSDN对GET_MODULE_HANDLE_EX_FLAG_PIN的解释是：
The module stays loaded until the process is terminated, no matter how many times FreeLibrary is called.

至此，一切真相大白了！
不过倒是没搞懂，为什么这个版本的OPENSSL这么做，之前的代码并没有找到这样的处理。

0x02 附录

https://docs.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-getmodulehandleexw
https://securityxploded.com/dllrefcount.php
https://stackoverflow.com/questions/3553231/how-to-check-dlls-reference-count-how-to-know-where-the-dll-was-loaded