LoadLibrary深入案例详解

LoadLibrary流程分析

在Windows开发中，我们都有过一个规定：在DllMain中不应该处理过于复杂的事情，防止死锁的发生。

那么，到底为什么DllMain中容易导致死锁呢？下面我们来分析一下LoadLibrary的整个流程和原理。

1. 使用

我们来看一下LoadLibrary怎么使用的，由于这个函数底层是调用LoadLibraryEx我们看LoadLibraryEx的使用情况。

1.1 声明

HMODULE WINAPI LoadLibraryEx(
_In_       LPCTSTR lpFileName,
_Reserved_ HANDLE  hFile,
_In_       DWORD   dwFlags
);

这里主要第三个参数使用起来有需要注意的地方：

DONT_RESOLVE_DLL_REFERENCES : 这个标志用于告诉系统将DLL映射到调用进程的地址空间中，但是不调用DllMain并且不加载依赖Dll（只映射自己本身）。
LOAD_LIBRARY_AS_DATAFILE : 这个标志与DONT_RESOLVE_DLL_REFERENCES标志相类似，因为系统只是将DLL映射到进程的地址空间中，就像它是数据文件一样。系统并不花费额外的时间来准备执行文件中的任何代码。
LOAD_LIBRARY_SEARCH_USER_DIRS : 搜索路径的使用使用AddDllDirectory和SetDllDirectory设置的路径（保护Dll自己和依赖Dll）。
LOAD_LIBRARY_SEARCH_SYSTEM32 : 从%windows%\system32加载Dll和其依赖项。
LOAD_LIBRARY_SEARCH_APPLICATION_DIR : 应用程序安装路径搜索Dll和其依赖项。
LOAD_WITH_ALTERED_SEARCH_PATH : 按照如下目录搜索：
1. 进程当前目录。
2. Windows的系统目录。
3. 16 位Windows的系统目录。
4. Windows目录。
5. path环境变量目录。

默认情况下，LoadLibrary和LoadLibrary按照如下目录搜索：

进程当前目录。
SetDllDirectory设置的文件夹路径。
Windows的系统目录。
16 位Windows的系统目录。
Windows目录。
path环境变量目录。

1.2 SetDllDirectoryW

这个函数的实现如下：

LoadLibrary深入案例详解

其中KernelBaseGetGlobalData返回的结果信息如下：

LoadLibrary深入案例详解

如下信息为：

0:003> dd KERNELBASE!KernelBaseGlobalData
75b155a0  00000000 00000000 00160014 7f9a1240
75b155b0  00280026 7f9a1260 00000000 00000000
75b155c0  00000000 00e60000 75b156c0 7fff0000
75b155d0  00c4b494 0000011a 00cc1914 0000012c
75b155e0  00cb9f34 00000253 00cc2658 00cc5e20
75b155f0  00000000 00e84380 0000000f ffffffff
75b15600  ffffffff 00000000 00000000 00000000
75b15610  020007d0 75950000 00000000 00000000
0:003> du 7f9a1240
7f9a1240  "C:\Windows"
0:003> du 7f9a1260 
7f9a1260  "C:\Windows\system32"

2. LoadLibrary分析

下面来分析一下这个函数的执行过程：

HMODULE __stdcall LoadLibraryW(LPCWSTR lpLibFileName)
{
return LoadLibraryExW(lpLibFileName, 0, 0);
}

2.1 LoadLibraryExW

对于LoadLibraryW的主要流程如下：

HMODULE __stdcall LoadLibraryExW(LPCWSTR lpLibFileName, HANDLE hFile, DWORD dwFlags)
{
  //...
  SearchPath = BaseGetProcessDllPath(
                     &dwFlags,
                     (chFlags & LOAD_WITH_ALTERED_SEARCH_PATH) != 0 ? DllName.Buffer : 0,
                     0,
                     (int)&dwFlags);

  //...
  ntStatus = LdrLoadDll(SearchPath, (PULONG)&lpLibFileName, &DllName, &hFile);
}

通过BaseGetProcessDllPath获取到的路径为：

00072acc  "C:\Users\xxx\Desktop;C:\Windows\"
00072b0c  "system32;C:\Windows\system;C:\Wi"
00072b4c  "ndows;.;C:\Windows\system32;C:\W"
00072b8c  "indows;C:\Windows\System32\Wbem;"
00072bcc  "C:\Windows\System32\WindowsPower"
00072c0c  "Shell\v1.0\"

接下来就是使用LdrLoadDll价值dll了。

2.2 LdrLoadDll

NTSTATUS __stdcall LdrLoadDll(PWSTR SearchPath, PULONG LoadFlags, PUNICODE_STRING DllName, PVOID *BaseAddress)
{
//...
if ( SearchPath )
{
  result = RtlInitUnicodeStringEx(&DestinationString, SearchPath);
  if ( result < 0 )
    return result;
  NewSearchPath = &DestinationString;
}
else
{
  NewSearchPath = &LdrpDefaultPath;
}
//...
v7 = LdrpLoadDll(DllName, (int)NewSearchPath, v6, 1, 0, (int)&DllName);
//...
return v7;
}

这里有一个默认的加载路径为LdrpDefaultPath,路径信息如下：

0:000> dS LdrpDefaultPath
00061560  "C:\Users\xxx\Desktop;C:\Windows\"
000615a0  "system32;C:\Windows\system;C:\Wi"
000615e0  "ndows;.;C:\Windows\system32;C:\W"
00061620  "indows;C:\Windows\System32\Wbem;"
00061660  "C:\Windows\System32\WindowsPower"
000616a0  "Shell\v1.0\"

2.3 LdrpLoadDll

int __stdcall LdrpLoadDll(PCUNICODE_STRING Source, int a2, int a3, char a4, int a5, int a6)
{
  //...
  if ( !LdrpInLdrInit )
    RtlEnterCriticalSection(&LdrpLoaderLock);
  
  //...
  LdrpFindOrMapDll(*(PCUNICODE_STRING *)((char *)&v31 + 1), v29, a3, v27[0], (int)&v33, (int)&v31);

  //...
  if ( v21 & 0x1000000 )
      v22 = LdrpCorProcessImports((void *)v21, v33);
  else
      v22 = LdrpProcessStaticImports(v33, v29);
  //...

  LdrpRunInitializeRoutines(0);

  //...

  if ( !LdrpInLdrInit )
    RtlLeaveCriticalSection(&LdrpLoaderLock);
}

这个函数的整理流程如下：

获取加载锁RtlEnterCriticalSection(&LdrpLoaderLock);尝试加载dll: LdrpFindOrMapDll。处理导入表信息。运行回调函数LdrpRunInitializeRoutines。释放锁RtlLeaveCriticalSection(&LdrpLoaderLock);。

这里值得注意的地方就是LdrpRunInitializeRoutines是调用DllMain函数，调用堆栈信息如下：

# ChildEBP RetAddr  Args to Child              
00 0029d718 67f42c22 67ef0000 00000001 00000000 DllTest!DllMain 
01 0029d75c 67f42def 67ef0000 00000001 00000000 DllTest!dllmain_dispatch+0xb2 
02 0029d770 777b89d8 67ef0000 00000001 00000000 DllTest!_DllMainCRTStartup+0x1f 
03 0029d790 777c5c41 67f3dcc5 67ef0000 00000001 ntdll!LdrpCallInitRoutine+0x14
04 0029d884 777c052e 00000000 73bd12d3 777a7c9a ntdll!LdrpRunInitializeRoutines+0x26f
05 0029d9f0 777c232c 0029da50 0029da1c 00000000 ntdll!LdrpLoadDll+0x4d1
06 0029da24 75b688ee 00072acc 0029da64 0029da50 ntdll!LdrLoadDll+0x92
07 0029da5c 763d3c12 00000000 00000000 00000001 KERNELBASE!LoadLibraryExW+0x15a

加载dll的时候，会获取锁LdrpLoaderLock;然而加载的时候又会调用LdrpRunInitializeRoutines进入DllMain。

2.4 LdrpFindOrMapDll

加载和映射的dll的函数是LdrpFindOrMapDll，这个函数在加载Dll之前，需要判断Dll是否被加载过, 已经加载的dll，通过一个哈希表加载，哈希表如下：

LIST_ENTRY LdrpHashTable[LDR_HASH_TABLE_ENTRIES];

其实每个LdrpHashTable都是通过一个_LDR_DATA_TABLE_ENTRY的成员HashLinks链接起来，结构如下：

0:000> dt ntdll!_LDR_DATA_TABLE_ENTRY 
 +0x000 InLoadOrderLinks : _LIST_ENTRY
 +0x008 InMemoryOrderLinks : _LIST_ENTRY
 +0x010 InInitializationOrderLinks : _LIST_ENTRY
 +0x018 DllBase          : Ptr32 Void
 +0x01c EntryPoint       : Ptr32 Void
 +0x020 SizeOfImage      : Uint4B
 +0x024 FullDllName      : _UNICODE_STRING
 +0x02c BaseDllName      : _UNICODE_STRING
 +0x034 Flags            : Uint4B
 +0x038 LoadCount        : Uint2B
 +0x03a TlsIndex         : Uint2B
 +0x03c HashLinks        : _LIST_ENTRY  //LdrpHashTable连接的列表结构
 +0x03c SectionPointer   : Ptr32 Void
 +0x040 CheckSum         : Uint4B
 +0x044 TimeDateStamp    : Uint4B
 +0x044 LoadedImports    : Ptr32 Void
 +0x048 EntryPointActivationContext : Ptr32 _ACTIVATION_CONTEXT
 +0x04c PatchInformation : Ptr32 Void
 +0x050 ForwarderLinks   : _LIST_ENTRY
 +0x058 ServiceTagLinks  : _LIST_ENTRY
 +0x060 StaticLinks      : _LIST_ENTRY
 +0x068 ContextInformation : Ptr32 Void
 +0x06c OriginalBase     : Uint4B
 +0x070 LoadTime         : _LARGE_INTEGER

对于每个加载的DLL，都会有两种形式：

dll名称加载。
dll全路径加载。

在LdrpFindLoadedDllByName也会根据不同的加载来匹配不同的情况：

如果使用dll名称加载，那么比较BaseDllName;使用RtlEqualUnicodeString.
如果使用dll全路径加载，那么比较FullDllName;使用RtlEqualUnicodeString.

例如：

0:000> dt ntdll!_LDR_DATA_TABLE_ENTRY 006f6270
 +0x000 InLoadOrderLinks : _LIST_ENTRY [ 0x6f6358 - 0x6f5eb8 ]
 +0x008 InMemoryOrderLinks : _LIST_ENTRY [ 0x6f6360 - 0x6f5ec0 ]
 +0x010 InInitializationOrderLinks : _LIST_ENTRY [ 0x6f6e38 - 0x6f6368 ]
 +0x018 DllBase          : 0x75b30000 Void
 +0x01c EntryPoint       : 0x75b43273 Void
 +0x020 SizeOfImage      : 0x110000
 +0x024 FullDllName      : _UNICODE_STRING "C:\Windows\syswow64\kernel32.dll"   //全路径匹配这个
 +0x02c BaseDllName      : _UNICODE_STRING "kernel32.dll"   //Dll名称匹配这个
 +0x034 Flags            : 0x84004
 +0x038 LoadCount        : 0xffff
 +0x03a TlsIndex         : 0
 +0x03c HashLinks        : _LIST_ENTRY [ 0x77c148a0 - 0x77c148a0 ]
 +0x03c SectionPointer   : 0x77c148a0 Void
 +0x040 CheckSum         : 0x77c148a0
 +0x044 TimeDateStamp    : 0x589c961f
 +0x044 LoadedImports    : 0x589c961f Void
 +0x048 EntryPointActivationContext : (null) 
 +0x04c PatchInformation : (null) 
 +0x050 ForwarderLinks   : _LIST_ENTRY [ 0x718580 - 0x718580 ]
 +0x058 ServiceTagLinks  : _LIST_ENTRY [ 0x6f62c8 - 0x6f62c8 ]
 +0x060 StaticLinks      : _LIST_ENTRY [ 0x6f63f0 - 0x6f62f0 ]
 +0x068 ContextInformation : 0x77b4ef40 Void
 +0x06c OriginalBase     : 0x7dd60000
 +0x070 LoadTime         : _LARGE_INTEGER 0x01d48576`ee26eab0

如果，这里匹配成功了，那么Dll就不会再加载了。

3. 总结

3.1 同名DLL

一个进程是否可以加载相同名字的Dll呢？按照上面分析有一个加载规则

在LdrpFindLoadedDllByName也会根据不同的加载来匹配不同的情况：

如果使用dll名称加载，那么比较BaseDllName;使用RtlEqualUnicodeString.
如果使用dll全路径加载，那么比较FullDllName;使用RtlEqualUnicodeString.

那么可以从这个规则来看，是看加载是的方式：

int main(int args, char* argv[])
{
	LoadLibraryW(L"C:\\DllTest.dll");
	LoadLibraryW(L"DllTest.dll");
	system("pause");
	return 0;
}

这种方式，第二个应该LoadLibraryW(L"DllTest.dll")不会去匹配加载了，如下：

LoadLibrary深入案例详解

那么我们按照这种方式加载呢？

int main(int args, char* argv[])
{
	LoadLibraryW(L"DllTest.dll");
	LoadLibraryW(L"C:\\DllTest.dll");
	system("pause");
	return 0;
}

按照规则来说，应该是可以加载的，如下：

LoadLibrary深入案例详解

这个中情况在wow64 情况下，有时候会踩到坑，例如，对于wowo64路径，如果直接使用C:\Windows\system32\kernel32.dll路径加载，那么LdrpFindLoadedDllByName一定会失败，因为FullDllName为wow64使用的值：C:\Windows\syswow64\kernel32.dll.

3.2 死锁

我们知道，在调用Dllmain的时候，会占用锁RtlEnterCriticalSection(&LdrpLoaderLock)，所有凡是在DllMain中调用可能获取RtlEnterCriticalSection(&LdrpLoaderLock)的操作，就可能会导致死锁，例如：

直接调用LoadLibrary(Ex)。
调用CoInitializeEx（在CoInitializeEx底层会调用LoadLibraryEx）。
调用CreateThread(因为CreateThread会继续调用DllMain，稍有不慎可能就会死锁)。
调用GetModuleFileName、GetModuleHandle 等（底层获取RtlEnterCriticalSection(&LdrpLoaderLock)锁）。

到此这篇关于LoadLibrary深入案例详解的文章就介绍到这了,更多相关LoadLibrary详解内容请搜索服务器之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持服务器之家！

原文链接：https://blog.csdn.net/xiangbaohui/article/details/103743201