ZyOrca

导航

为什么在ASLR机制下DLL文件在不同进程中的加载基址相同？

1. DLL 注入实现

以下是实现 DLL注入的简要步骤：

1.1 打开 Visual Studio，并创建一个新的 DLL 项目。

1.2 在"dllmain.cpp" 添加以下的代码

 1 // dllmain.cpp : 定义 DLL 应用程序的入口点。
 2 #include "pch.h"
 3 
 4 BOOL APIENTRY DllMain( HMODULE hModule,
 5                        DWORD  ul_reason_for_call,
 6                        LPVOID lpReserved
 7                      )
 8 {
 9     switch (ul_reason_for_call)
10     {
11     case DLL_PROCESS_ATTACH:
12         MessageBoxA(NULL, "您的进程已被注入", "注入警告", NULL);
13         break;
14     case DLL_THREAD_ATTACH:
15         MessageBoxA(NULL, "您的进程已被注入", "注入警告", NULL);
16         break;
17     case DLL_THREAD_DETACH:
18         MessageBoxA(NULL, "您的进程已被注入", "注入警告", NULL);
19         break;
20     case DLL_PROCESS_DETACH:
21         MessageBoxA(NULL, "您的进程已被注入", "注入警告", NULL);
22         break;
23     }
24     return TRUE;
25 }

1.3 生成 DLL 文件，得到一个名为 "InjectDll.dll" 的 DLL文件。

1.4 运行以下代码，将 DLL文件注入到记事本进程中

 1 #include <Windows.h>
 2 #include <stdio.h>
 3 
 4 int main()
 5 {
 6     // 获取目标进程的句柄
 7     HWND hWnd = FindWindow(NULL, L"无标题 - Notepad");
 8     if (hWnd == NULL) {
 9         printf("未找到目标进程\n");
10         return 1;
11     }
12 
13     DWORD processId;
14     GetWindowThreadProcessId(hWnd, &processId);
15     HANDLE hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, processId);
16     if (hProcess == NULL) {
17         printf("无法打开目标进程\n");
18         return 1;
19     }
20 
21     // 在目标进程中分配内存
22     LPVOID pRemoteBuffer = VirtualAllocEx(hProcess, NULL, MAX_PATH, MEM_COMMIT, PAGE_READWRITE);
23     if (pRemoteBuffer == NULL) {
24         printf("无法在目标进程中分配内存\n");
25         return 1;
26     }
27 
28     // 将DLL路径写入目标进程
29     char dllPath[] = "E:\\Test\\InjectDll.dll";
30     if (!WriteProcessMemory(hProcess, pRemoteBuffer, dllPath, sizeof(dllPath), NULL)) {
31         printf("无法写入目标进程内存\n");
32         return 1;
33     }
34 
35     // 获取LoadLibrary函数的地址
36     HMODULE hKernel32 = GetModuleHandle(L"kernel32.dll");
37     if (hKernel32 == NULL) {
38         printf("未找到kernel32.dll\n");
39         return 1;
40     }
41 
42     FARPROC pLoadLibrary = GetProcAddress(hKernel32, "LoadLibraryA");
43     if (pLoadLibrary == NULL) {
44         printf("未找到LoadLibrary函数\n");
45         return 1;
46     }
47 
48     // 在目标进程中调用LoadLibrary函数加载DLL
49     HANDLE hThread = CreateRemoteThread(hProcess, NULL, 0, (LPTHREAD_START_ROUTINE)pLoadLibrary, pRemoteBuffer, 0, NULL);
50     if (hThread == NULL) {
51         printf("无法在目标进程中创建远程线程\n");
52         return 1;
53     }
54 
55     printf("DLL注入成功\n");
56 
57     // 等待远程线程退出
58     WaitForSingleObject(hThread, INFINITE);
59 
60     // 清理资源
61     CloseHandle(hThread);
62     VirtualFreeEx(hProcess, pRemoteBuffer, 0, MEM_RELEASE);
63     CloseHandle(hProcess);
64 
65     return 0;
66 }

总结一下 Dll 注入步骤

  • 定位目标进程：使用Windows API函数（如FindWindow）或其他技术来获取目标进程的句柄或进程ID；
  • 打开目标进程：使用OpenProcess函数打开目标进程，获取进程的句柄，以便后续操作；
  • 在目标进程中分配内存：使用VirtualAllocEx函数在目标进程中分配一块内存，用于存储DLL路径或其他数据；
  • 将DLL路径写入目标进程：使用WriteProcessMemory函数将DLL路径或其他数据写入目标进程的内存空间；
  • 获取函数地址：获取所需函数（例如LoadLibrary）在目标进程所加载的模块中的地址，通常使用GetModuleHandle和GetProcAddress函数；
  • 在目标进程中创建远程线程：使用CreateRemoteThread函数在目标进程中创建一个远程线程，该线程执行加载DLL的函数，并将DLL路径作为参数传递；
  • 等待远程线程退出：使用WaitForSingleObject函数等待远程线程退出，确保注入操作完成；
  • 清理资源：关闭句柄、释放内存等，以确保不会产生资源泄漏。

2. 为什么在ASLR机制下DLL文件在不同进程中加载的基址相同

2.1. ALSR

ASLR（Address Space Layout Randomization）是一种用于增加系统安全性的技术，它通过随机化内存地址的分配，使攻击者更难以利用已知的内存布局漏洞进行攻击。实际上ASLR的概念在Windows XP时代就已经提出来了，只不过XP上面的ASLR功能很有限，只是对PEB和TEB进行了简单的随机化处理，而对于模块的加载基址没有进行随机化处理，直到Windows Vista出现后，ASLR才真正开始发挥作用。

微软从Visual Studio 2005 SP1开始加入了/dynamicbase链接选项使编译好的程序支持随机基址，只需要在编译程序的时候启用/dynmicbase链接选项。（Visual Studio 2022 可以在项目属性中设置：配置属性——链接器——高级——随机基址）

 

PE文件中IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE值为1，则说明该 PE文件支持ASLR，如下图所示。

 

ALSR 会随机化的地址包括：

  • 堆地址
  • 栈地址
  • PE文件加载基址
  • PEB和TEB地址

ALSR 机制能保证在每次系统重启后，系统DLL文件在进程中的加载基址不会是默认的地址0x10000000（EXE文件的默认加载基址是0x00400000），而是一个随机的地址。系统重启后这个加载基址会再次变化，ASLR的出现使得shellcode中的关键跳转只能在系统重启前，甚至只有程序的本次运行时才能执行，这使得exploit的难度大大增加。在ALSR开启的状态下，DLL 注入依然能实现是因为DLL文件在不同进程中加载的基址虽然经过了随机化的处理，但系统DLL文件(如system32目录下的DLL)在各个进程中通常加载地址仍然是相同的，以保证不同进程能互相调用这些系统DLL提供的 API。

2.2. Copy-On-Write

其中更深层次的原因是操作系统需要支持写时复制机制（copy-on-write）。写时复制是现代操作系统的一个重要特性。操作系统使用页表（Page Table）来将进程的虚拟地址映射到物理地址。页表是一种数据结构，它存储了虚拟地址和物理地址之间的映射关系。

A 进程和 B 进程共享同一个 DLL 时，它们的虚拟地址空间中的虚拟地址会指向相同的物理内存页。这意味着它们共享同一份物理内存。当 A 进程尝试对 DLL 内存页进行写操作时，操作系统会触发写时复制，操作系统会将共享的物理内存页复制一份，创建一个新的物理页供 A 进程使用。A 进程会拥有自己的独立副本，而进程B仍然使用原始的物理内存页。

Copy-On-Write机制触发并不会影响虚拟地址空间的映射关系。因此，在Copy-On-Write机制中，虚拟地址空间中DLL的加载基址不会发生变化。进程A仍然可以通过原始的加载基址访问和调用DLL中的代码和数据。当多个进程加载同一个 DLL 文件并且它们的加载基址保持相同时，可以更好地利用 Copy-On-Write 机制。这样可以实现代码和只读数据的共享，延迟数据的复制，并提高内存利用率和性能。如果 DLL 加载地址不一致，Copy-On-Write 无法共享内存页，每个进程都需要单独复制 DLL 的只读内存，失去了内存优化的效果。

2.3. PE文件的加载机制

在 PE 文件中有一个加载基址（Image Base）的字段，它指定了 DLL 文件在内存中的起始地址。操作系统在加载DLL文件时，首先会检查文件头中的标志，确定是否启用了ASLR或者是否存在重定位表。如果存在重定位表，操作系统会遍历重定位表中的每个条目。重定位表中的每个条目包含了两个关键信息：

  • 重定位类型（Relocation Type）： 指定了需要进行的重定位操作，例如相对地址的基址绝对化。
  • 偏移量（Offset）： 指定了在文件中的位置，即需要进行重定位的虚拟地址相对于模块基址的偏移量。

操作系统使用以下公式计算PE 文件中需要进行重定位的虚拟地址：VirtualAddress = ImageBase + Offset（偏移量）

在相同的操作系统和相同的加载条件下，相同的DLL文件在不同进程中的重定位计算是一致的。因此，无论 ASLR 是否启用，PE 文件的加载机制决定了 DLL 文件在各个进程中的加载基址是相同的。

 

综合这三个角度，虽然ASLR在操作系统的进程管理中引入了加载基址的随机化，但由于Copy-On-Write和PE文件加载机制的作用，同一DLL文件在不同进程中的加载基址仍然是相同的。这有助于确保不同进程中的DLL文件内部结构保持一致，同时确保进程间的数据隔离，提高系统的整体安全性和资源使用效率。

posted on 2023-11-18 23:08  ZyOrca  阅读(147)  评论(0)  编辑  收藏  举报