一：背景 1.講故事 有朋友咨詢個問題，他每次在調試 WinDbg 的時候，進程初始化斷點之前都會有一些 dll 載入到進程中，比如下麵這樣： Microsoft (R) Windows Debugger Version 10.0.25200.1003 X86 Copyright (c) Micro ...
一：背景
1.講故事
有朋友咨詢個問題，他每次在調試 WinDbg 的時候，進程初始化斷點之前都會有一些 dll 載入到進程中，比如下麵這樣：
Microsoft (R) Windows Debugger Version 10.0.25200.1003 X86
Copyright (c) Microsoft Corporation. All rights reserved.
CommandLine: D:\net6\ConsoleApp1\Debug\ConsoleApplication3.exe
************* Path validation summary **************
Response Time (ms) Location
Deferred srv*c:\mysymbols*https://msdl.microsoft.com/download/symbols
Symbol search path is: srv*c:\mysymbols*https://msdl.microsoft.com/download/symbols
Executable search path is:
ModLoad: 00400000 0041f000 ConsoleApplication3.exe
ModLoad: 774b0000 77653000 ntdll.dll
ModLoad: 753a0000 75490000 C:\Windows\SysWOW64\KERNEL32.DLL
ModLoad: 75900000 75b14000 C:\Windows\SysWOW64\KERNELBASE.dll
ModLoad: 79bc0000 79d36000 C:\Windows\SysWOW64\ucrtbased.dll
ModLoad: 79ba0000 79bbe000 C:\Windows\SysWOW64\VCRUNTIME140D.dll
(44c.4b0c): Break instruction exception - code 80000003 (first chance)
eax=00000000 ebx=00000000 ecx=afe00000 edx=00000000 esi=774c1ff4 edi=774c25bc
eip=77561a42 esp=0019fa20 ebp=0019fa4c iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
ntdll!LdrpDoDebuggerBreak+0x2b:
77561a42 cc int 3
問是否可以用 WinDbg 解讀下內部運作原理，哈哈，其實要瞭解運作原理，一定要熟知 PE 頭，那這篇就安排上。
二：理解 PE 頭結構
1. 測試代碼
為了方便講述，先上一段測試代碼，這裡故意載入 combase.dll 是為了提取 PE 中的某些數據結構，代碼如下：
#include <iostream>
#include <Windows.h>
int main(int argc, char* argv[]) {
LoadLibrary(L"combase.dll");
getchar();
}
其實你仔細想一想也能知道，既然能做到初始化載入，必然在 PE 頭上藏了什麼東西，這些東西讓 Windows 載入器可以順利載入諸如 ntdll.dll, KERNEL32.dll 等等，接下來一起觀察下。
2. 可視化觀察 PE 頭
要想可視化觀察 PE 頭，工具有很多，這裡使用 PPEE 工具，截圖如下：
從圖中可以看到，其實初始化載入什麼，由可選頭中的 DIRECTORY_ENTRY_IMPORT 數據目錄項決定，哪這裡包含了哪些初始化 dll 呢？ 可以選中右邊的 DIRECTORY_ENTRY_IMPORT 項即可，如下圖所示：
肯定有朋友說，WinDbg 上顯示的是 5 個，你這裡才 3 個，還有 2 個為什麼沒有？ 很簡單，多餘的 ntdll.dll 和 KERNELBASE.dll 必然是依賴項哈。
3. 用 WinDbg 深入探究
玩 WinDbg 都喜歡刨根問底，拿可視化 PPEE 肯定忽悠不過去，那好吧，我們用 C 中的結構體去解剖它。
- DOS Header 節
這一塊信息在源碼中是用 ntdll!_IMAGE_DOS_HEADER 結構來承載的，可以用 dt 輸出，起始點就是我們的 ConsoleApplication3.dll 在進程的首位置，即： 0x400000。
0:000> dt 0x400000 _IMAGE_DOS_HEADER
ConsoleApplication3!_IMAGE_DOS_HEADER
+0x000 e_magic : 0x5a4d
+0x002 e_cblp : 0x90
+0x004 e_cp : 3
...
+0x024 e_oemid : 0
+0x026 e_oeminfo : 0
+0x028 e_res2 : [10] 0
+0x03c e_lfanew : 0n232
- NT Header 節
接下來就是 NT Header 節，它在源碼中是由 _IMAGE_NT_HEADERS 結構來承載的，起始位置的偏移已經保存在上面的 e_lfanew 欄位中，即 0n232。
0:000> dt 0x400000+0n232 _IMAGE_NT_HEADERS
ConsoleApplication3!_IMAGE_NT_HEADERS
+0x000 Signature : 0x4550
+0x004 FileHeader : _IMAGE_FILE_HEADER
+0x018 OptionalHeader : _IMAGE_OPTIONAL_HEADER
- _IMAGE_DATA_DIRECTORY
在 PPEE 的第一張截圖中，我們查看的是 Data Directorys 數組中的第二項 DIRECTORY_ENTRY_IMPORT 內容，它裡面定義了我們需要初始化導入的 dll，我們可以用 dt r3 展開一下，然後一直點點點就好了，簡化後如下：
0:000> dt -r3 0x400000+0n232 _IMAGE_NT_HEADERS
ConsoleApplication3!_IMAGE_NT_HEADERS
+0x000 Signature : 0x4550
+0x004 FileHeader : _IMAGE_FILE_HEADER
+0x000 Machine : 0x14c
...
+0x012 Characteristics : 0x103
+0x018 OptionalHeader : _IMAGE_OPTIONAL_HEADER
+0x000 Magic : 0x10b
+0x002 MajorLinkerVersion : 0xe ''
...
+0x05c NumberOfRvaAndSizes : 0x10
+0x060 DataDirectory : [16] _IMAGE_DATA_DIRECTORY
+0x000 VirtualAddress : 0
+0x004 Size : 0
0:000> dx -r1 (*((ConsoleApplication3!_IMAGE_DATA_DIRECTORY (*)[16])0x400160))
(*((ConsoleApplication3!_IMAGE_DATA_DIRECTORY (*)[16])0x400160)) [Type: _IMAGE_DATA_DIRECTORY [16]]
[0] [Type: _IMAGE_DATA_DIRECTORY]
[1] [Type: _IMAGE_DATA_DIRECTORY]
[2] [Type: _IMAGE_DATA_DIRECTORY]
...
[15] [Type: _IMAGE_DATA_DIRECTORY]
0:000> dx -r1 (*((ConsoleApplication3!_IMAGE_DATA_DIRECTORY *)0x400168))
(*((ConsoleApplication3!_IMAGE_DATA_DIRECTORY *)0x400168)) [Type: _IMAGE_DATA_DIRECTORY]
[+0x000] VirtualAddress : 0x1b1cc [Type: unsigned long]
[+0x004] Size : 0x50 [Type: unsigned long]
從輸出的 VirtualAddress=0x1b1cc 中可以看到，我們 PPEE 截圖二中的 DIRECTORY_ENTRY_IMPORT 真實內容是在偏移 0x1b1cc 處，它是一個 combase!_IMAGE_IMPORT_DESCRIPTOR 結構體，輸出如下：
0:005> dt 0x400000+0x1b1cc combase!_IMAGE_IMPORT_DESCRIPTOR
+0x000 Characteristics : 0x1b21c
+0x000 OriginalFirstThunk : 0x1b21c
+0x004 TimeDateStamp : 0
+0x008 ForwarderChain : 0
+0x00c Name : 0x1b40c
+0x010 FirstThunk : 0x1b000
到這裡就很關鍵了，涉及到如下幾點信息：
- 載入的 dll 名字是什麼?
可以從 Name 欄位提取，參考如下代碼：
0:005> da 0x400000+0x1b40c
0041b40c "KERNEL32.dll"
- 載入的 方法名 是什麼？
這需要提取 OriginalFirstThunk 欄位，這裡是一個 _IMAGE_IMPORT_BY_NAME類型的指針數組，代碼如下：
0:005> dp 0x400000+0x1b21c
0041b21c 0001b3e8 0001b3fc 0001b954 0001b942
0041b22c 0001b934 0001b924 0001b912 0001b906
0041b23c 0001b8fa 0001b8ea 0001b8d6 0001b8ba
...
0:005> dt 0x400000+0x0001b3e8 combase!_IMAGE_IMPORT_BY_NAME
+0x000 Hint : 0x382
+0x002 Name : [1] "I"
0:005> da 0x400000+0x0001b3e8+0x2
0041b3ea "IsDebuggerPresent"
結合上面的輸出，我們知道 IsDebuggerPresent() 是屬於 KERNEL32.dll 下的，有了這兩點信息，Windows 載入器就可以用 LoadLibrary 和 GetProcAddress 方法將其載入到進程中了，轉化為 C 代碼大概是這樣的。
typedef BOOL(CALLBACK* DeubbgerFunc)();
int main(int argc, char* argv[])
{
HMODULE hModule = LoadLibrary(L"KERNEL32.dll");
DeubbgerFunc func = (DeubbgerFunc)GetProcAddress(hModule, "IsDebuggerPresent");
BOOL b= func();
}
- func 函數地址會保存嗎？
當然會保存了，會放在 _IMAGE_IMPORT_DESCRIPTOR 結構下的 FirstThunk 欄位中，這是一個函數地址的指針數組，可以用 dds 觀察。
0:005> dt 0x400000+0x1b1cc combase!_IMAGE_IMPORT_DESCRIPTOR
+0x000 Characteristics : 0x1b21c
+0x000 OriginalFirstThunk : 0x1b21c
+0x004 TimeDateStamp : 0
+0x008 ForwarderChain : 0
+0x00c Name : 0x1b40c
+0x010 FirstThunk : 0x1b000
0:005> dds 0x400000+0x1b000
0041b000 753c20d0 KERNEL32!IsDebuggerPresentStub
0041b004 753c16c0 KERNEL32!LoadLibraryWStub
0041b008 753c2e80 KERNEL32!GetCurrentProcess
0041b00c 753bf550 KERNEL32!GetProcAddressStub
0041b05c 753b9910 KERNEL32!TerminateProcessStub
...
還有一點要註意，如果你在代碼中使用 IsDebuggerPresent() 方法的話，它會從 0041b000 位置上取函數地址，參考如下彙編代碼：
三：總結
對初學者來說，搞懂這些還是有一定困難的，我在網上找了一份很好的參考圖，大家可以對照著這張圖理解，在此感謝作者。
- INT 是 Windows 需要載入的函數名列表。
- IAT 是存放 GetProcAddress 返回函數地址的列表。
