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 : 按照如下目录搜索：
- 进程当前目录。 Windows的系统目录。 16 位Windows的系统目录。 Windows目录。 path环境变量目录。
默认情况下，LoadLibrary和LoadLibrary按照如下目录搜索：
- 进程当前目录。 SetDllDirectory设置的文件夹路径。 Windows的系统目录。 16 位Windows的系统目录。 Windows目录。 path环境变量目录。
1.2 SetDllDirectoryW
这个函数的实现如下：
其中KernelBaseGetGlobalData返回的结果信息如下：
如下信息为：
0:003> dd KERNELBASE!KernelBaseGlobalData75b155a0 00000000 00000000 00160014 7f9a124075b155b0 00280026 7f9a1260 00000000 0000000075b155c0 00000000 00e60000 75b156c0 7fff000075b155d0 00c4b494 0000011a 00cc1914 0000012c75b155e0 00cb9f34 00000253 00cc2658 00cc5e2075b155f0 00000000 00e84380 0000000f ffffffff75b15600 ffffffff 00000000 00000000 0000000075b15610 020007d0 75950000 00000000 000000000:003> du 7f9a12407f9a1240 "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 LdrpDefaultPath00061560 "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+0x1404 0029d884 777c052e 00000000 73bd12d3 777a7c9a ntdll!LdrpRunInitializeRoutines+0x26f05 0029d9f0 777c232c 0029da50 0029da1c 00000000 ntdll!LdrpLoadDll+0x4d106 0029da24 75b688ee 00072acc 0029da64 0029da50 ntdll!LdrLoadDll+0x9207 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”)不会去匹配加载了，如下：
那么我们按照这种方式加载呢？
int main(int args, char* argv[]){LoadLibraryW(L"DllTest.dll");LoadLibraryW(L"C:\\DllTest.dll");system("pause");return 0;}
按照规则来说，应该是可以加载的，如下：
这个中情况在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详解内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！
去旅行不在于记忆，而在于当时的那份心情。
