codeArt

Ⅲ.CreateRemoteThread和 WriteProcessMemory技術
示例程序：WinSpy

    另一種注入代碼到其他進程地址空間的方法是使用WriteProcessMemory API。這次你不用編寫一個獨立的DLL而是直接復制你的代碼到遠程進程（WriteProcessMemory）并用 CreateRemoteThread執(zhí)行之。

    讓我們看一下CreateRemoteThread的聲明：
HANDLE CreateRemoteThread(
HANDLE hProcess,        // handle to process to create thread in
LPSECURITY_ATTRIBUTES lpThreadAttributes, // pointer to security
                                             // attributes
DWORD dwStackSize,      // initial thread stack size, in bytes
LPTHREAD_START_ROUTINE lpStartAddress,     // pointer to thread
                                             // function
LPVOID lpParameter,     // argument for new thread
DWORD dwCreationFlags, // creation flags
LPDWORD lpThreadId      // pointer to returned thread identifier
);

和CreateThread相比，有一下不同：

●增加了hProcess參數(shù)。這是要在其中創(chuàng)建線程的進程的句柄。
●CreateRemoteThread的lpStartAddress參數(shù)必須指向遠程進程的地址空間中的函數(shù)。這個函數(shù)必須存在于遠程進程中，所以我 們不能簡單地傳遞一個本地ThreadFucn的地址，我們必須把代碼復制到遠程進程。
●同樣，lpParameter參數(shù)指向的數(shù)據(jù)也必須存在于遠程進程中，我們也必須復制它。

    現(xiàn)在，我們總結一下使用該技術的步驟：

    1． 得到遠程進程的HANDLE（OpenProcess）。
    2． 在遠程進程中為要注入的數(shù)據(jù)分配內存（VirtualAllocEx）、
    3． 把初始化后的INJDATA結構復制到分配的內存中（WriteProcessMemory）。
    4． 在遠程進程中為要注入的數(shù)據(jù)分配內存（VirtualAllocEx）。
    5． 把ThreadFunc復制到分配的內存中（WriteProcessMemory）。
    6． 用CreateRemoteThread啟動遠程的ThreadFunc。
    7． 等待遠程線程的結束（WaitForSingleObject）。
    8． 從遠程進程取回指執(zhí)行結果（ReadProcessMemory 或 GetExitCodeThread）。
    9． 釋放第2、4步分配的內存（VirtualFreeEx）。
    10． 關閉第6、1步打開打開的句柄。

    另外，編寫ThreadFunc時必須遵守以下規(guī)則：
    1． ThreadFunc不能調用除kernel32.dll和user32.dll之外動態(tài)庫中的API函數(shù)。只有kernel32.dll和 user32.dll（如果被加載）可以保證在本地和目的進程中的加載地址是一樣的。（注意：user32并不一定被所有的Win32進程加載！）參考附 錄A。如果你需要調用其他庫中的函數(shù)，在注入的代碼中使用LoadLibrary和GetProcessAddress強制加載。如果由于某種原因，你需 要的動態(tài)庫已經(jīng)被映射進了目的進程，你也可以使用GetMoudleHandle代替LoadLibrary。同樣，如果你想在ThreadFunc中調 用你自己的函數(shù)，那么就分別復制這些函數(shù)到遠程進程并通過INJDATA把地址提供給ThreadFunc。
    2． 不要使用static字符串。把所有的字符串提供INJDATA傳遞。為什么？編譯器會把所有的靜態(tài)字符串放在可執(zhí)行文件的“.data”段，而僅 僅在代碼中保留它們的引用（即指針）。這樣，遠程進程中的ThreadFunc就會執(zhí)行不存在的內存數(shù)據(jù)（至少沒有在它自己的內存空間中）。
    3． 去掉編譯器的/GZ編譯選項。這個選項是默認的（看附錄B）。
    4． 要么把ThreadFunc和AfterThreadFunc聲明為static，要么關閉編譯器的“增量連接（incremental linking）”（看附錄C）。
    5． ThreadFunc中的局部變量總大小必須小于4k字節(jié)（看附錄D）。注意，當degug編譯時，這4k中大約有10個字節(jié)會被事先占用。
    6． 如果有多于3個switch分支的case語句，必須像下面這樣分割開，或用if-else if代替：

switch( expression ) {
    case constant1: statement1; goto END;
    case constant2: statement2; goto END;
    case constant3: statement2; goto END;
}
switch( expression ) {
    case constant4: statement4; goto END;
    case constant5: statement5; goto END;
    case constant6: statement6; goto END;
}
END:
（參考附錄E）

    如果你不按照這些游戲規(guī)則玩的話，你注定會使目的進程掛掉！記住，不要妄想遠程進程中的任何數(shù)據(jù)會和你本地進程中的數(shù)據(jù)存放在相同內存地址！（參看附錄 F）
（原 話如此：You will almost certainly crash the target process if you don't play by those rules. Just remember: Don't assume anything in the target process is at the same address as it is in your process.）

GetWindowTextRemote(A/W)

    所有取得遠程edit中文本的工作都被封裝進這個函數(shù)：GetWindowTextRemote(A/W)：
int GetWindowTextRemoteA( HANDLE hProcess, HWND hWnd, LPSTR lpString );
int GetWindowTextRemoteW( HANDLE hProcess, HWND hWnd, LPWSTR lpString );

參數(shù)：
hProcess
目的edit所在的進程句柄
hWnd
目的edit的句柄
lpString
接收字符串的緩沖

返回值：
成功復制的字符數(shù)。

    讓我們看以下它的部分代碼，特別是注入的數(shù)據(jù)和代碼。為了簡單起見，沒有包含支持Unicode的代碼。

INJDATA

typedef LRESULT     (WINAPI *SENDMESSAGE)(HWND,UINT,WPARAM,LPARAM);

typedef struct {   
    HWND hwnd;                    // handle to edit control
    SENDMESSAGE fnSendMessage;   // pointer to user32!SendMessageA

    char psText[128];    // buffer that is to receive the password
} INJDATA;

    INJDATA是要注入遠程進程的數(shù)據(jù)。在把它的地址傳遞給SendMessageA之前，我們要先對它進行初始化。幸運的是unse32.dll在所有 的進程中（如果被映射）總是被映射到相同的地址，所以SendMessageA的地址也總是相同的，這也保證了傳遞給遠程進程的地址是有效的。

ThreadFunc

static DWORD WINAPI ThreadFunc (INJDATA *pData)
{
    pData->fnSendMessage( pData->hwnd, WM_GETTEXT,    // 得到密碼
                          sizeof(pData->psText),
                          (LPARAM)pData->psText );
    return 0;
}

// This function marks the memory address after ThreadFunc.
// int cbCodeSize = (PBYTE) AfterThreadFunc - (PBYTE) ThreadFunc.
static void AfterThreadFunc (void)
{
}

ThreadFunc是遠程線程實際執(zhí)行的代碼。
    ●注意AfterThreadFunc是如何計算ThreadFunc的代碼大小的。一般地，這不是最好的辦法，因為編譯器會改變你的函數(shù)中代碼的順序 （比如它會把ThreadFunc放在AfterThreadFunc之后）。然而，你至少可以確定在同一個工程中，比如在我們的WinSpy工程中，你 函數(shù)的順序是固定的。如果有必要，你可以使用/ORDER連接選項，或者，用反匯編工具確定ThreadFunc的大小，這個也許會更好。

如何用該技術子類（subclass）一個遠程控件
示例程序：InjectEx

    讓我們來討論一個更復雜的問題：如何子類屬于其他進程的一個控件？

    首先，要完成這個任務，你必須復制兩個函數(shù)到遠程進程：
    1． ThreadFunc，這個函數(shù)通過調用SetWindowLong API來子類遠程進程中的控件，
    2． NewProc， 那個控件的新窗口過程（Window Procedure）。

    然而，最主要的問題是如何傳遞數(shù)據(jù)到遠程的NewProc。因為NewProc是一個回調（callback）函數(shù)，它必須符合特定的要求（譯者注：這里 指的主要是參數(shù)個數(shù)和類型），我們不能再簡單地傳遞一個INJDATA的指針作為它的參數(shù)。幸運的我已經(jīng)找到解決這個問題的方法，而且是兩個，但是都要借 助于匯編語言。我一直都努力避免使用匯編，但是這一次，我們逃不掉了，沒有匯編不行的。

解決方案1
看下面的圖片：

不知道你是否注意到了，INJDATA緊挨著NewProc放在NewProc的前面？這樣的話在編譯期間NewProc就可以知道INJDATA 的內存地址。更精確地說，它知道INJDATA相對于它自身地址的相對偏移，但是這并不是我們真正想要的。現(xiàn)在，NewProc看起來是這個樣子：
static LRESULT CALLBACK NewProc(
HWND hwnd,       // handle to window
UINT uMsg,       // message identifier
WPARAM wParam,   // first message parameter
LPARAM lParam ) // second message parameter
{
    INJDATA* pData = (INJDATA*) NewProc; // pData 指向
                                          // NewProc;
    pData--;              // 現(xiàn)在pData指向INJDATA;
                          // 記住，INJDATA 在遠程進程中剛好位于
                          // NewProc的緊前面;

    //-----------------------------
    // 子類代碼
    // ........
    //-----------------------------

    //調用用來的的窗口過程;
    // fnOldProc (由SetWindowLong返回) 是被ThreadFunc（遠程進程中的）初始化
    // 并且存儲在遠程進程中的INJDATA里的;
    return pData->fnCallWindowProc( pData->fnOldProc,
                                    hwnd,uMsg,wParam,lParam );
}

    然而，還有一個問題，看第一行：
INJDATA* pData = (INJDATA*) NewProc;

    pData被硬編碼為我們進程中NewProc的地址，但這是不對的。因為NewProc會被復制到遠程進程，那樣的話，這個地址就錯了。

    用C/C++沒有辦法解決這個問題，可以用內聯(lián)的匯編來解決。看修改后的NewProc：

static LRESULT CALLBACK NewProc(
HWND hwnd,      // handle to window
UINT uMsg,      // message identifier
WPARAM wParam, // first message parameter
LPARAM lParam ) // second message parameter
{
    // 計算INJDATA 的地址;
    // 在遠程進程中，INJDATA剛好在
    //NewProc的前面;
    INJDATA* pData;
    _asm {
        call    dummy
dummy:
        pop     ecx         // <- ECX 中存放當前的EIP
        sub     ecx, 9      // <- ECX 中存放NewProc的地址
        mov     pData, ecx
    }
    pData--;

    //-----------------------------
    // 子類代碼
    // ........
    //-----------------------------

    // 調用原來的窗口過程
    return pData->fnCallWindowProc( pData->fnOldProc,
                                    hwnd,uMsg,wParam,lParam );
}

    這是什么意思？每個進程都有一個特殊的寄存器，這個寄存器指向下一條要執(zhí)行的指令的內存地址，即32位Intel和AMD處理器上所謂的EIP寄存器。因 為EIP是個特殊的寄存器，所以你不能像訪問通用寄存器（EAX，EBX等）那樣來訪問它。換句話說，你找不到一個可以用來尋址EIP并且對它進行讀寫的 操作碼（OpCode）。然而，EIP同樣可以被JMP，CALL，RET等指令隱含地改變（事實上它一直都在改變）。讓我們舉例說明32位的Intel 和AMD處理器上CALL/RET是如何工作的吧：

    當我們用CALL調用一個子程序時，這個子程序的地址被加載進EIP。同時，在EIP被改變之前，它以前的值會被自動壓棧（在后來被用作返回指令指針 [return instruction-pointer]）。在子程序的最后RET指令自動把這個值從棧中彈出到EIP。

    現(xiàn)在我們知道了如何通過CALL和RET來修改EIP的值了，但是如何得到他的當前值？
還記得CALL把EIP的值壓棧了嗎？所以為了得到EIP的值我們調用了一個“假（dummy）函數(shù)”然后彈出棧頂值。看一下編譯過的NewProc：

Address   OpCode/Params   Decoded instruction
--------------------------------------------------
:00401000 55          push ebp            ; entry point of
                                               ; NewProc
:00401001 8BEC            mov ebp, esp
:00401003 51              push ecx
:00401004 E800000000      call 00401009       ; *a*    call dummy
:00401009 59          pop ecx            ; *b*
:0040100A 83E909          sub ecx, 00000009   ; *c*
:0040100D 894DFC          mov [ebp-04], ecx   ; mov pData, ECX
:00401010 8B45FC          mov eax, [ebp-04]
:00401013 83E814          sub eax, 00000014   ; pData--;
.....
.....
:0040102D 8BE5            mov esp, ebp
:0040102F 5D              pop ebp
:00401030 C21000          ret 0010

    a． 一個假的函數(shù)調用；僅僅跳到下一條指令并且（譯者注：更重要的是）把EIP壓棧。
    b． 彈出棧頂值到ECX。ECX就保存的EIP的值；這也就是那條“pop ECX”指令的地址。
    c． 注意從NewProc的入口點到“pop ECX”指令的“距離”為9字節(jié)；因此把ECX減去9就得到的NewProc的地址了。

    這樣一來，不管被復制到什么地方，NewProc總能正確計算自身的地址了！然而，要注意從NewProc的入口點到“pop ECX”的距離可能會因為你的編譯器/鏈接選項的不同而不同，而且在Release和Degub版本中也是不一樣的。但是，不管怎樣，你仍然可以在編譯期 知道這個距離的具體值。
    1． 首先，編譯你的函數(shù)。
    2． 在反匯編器（disassembler）中查出正確的距離值。
    3． 最后，使用正確的距離值重新編譯你的程序。

    這也是InjectEx中使用的解決方案。InjectEx和HookInjEx類似，交換開始按鈕上的鼠標左右鍵點擊事件。

解決方案2

    在遠程進程中把INJDATA放在NewProc的前面并不是唯一的解決方案。看一下下面的NewProc：
static LRESULT CALLBACK NewProc(
HWND hwnd,      // handle to window
UINT uMsg,      // message identifier
WPARAM wParam, // first message parameter
LPARAM lParam ) // second message parameter
{
    INJDATA* pData = 0xA0B0C0D0;    // 一個假值

    //-----------------------------
    // 子類代碼
    // ........
    //-----------------------------

    // 調用以前的窗口過程
    return pData->fnCallWindowProc( pData->fnOldProc,
                                    hwnd,uMsg,wParam,lParam );
}

    這里，0XA0B0C0D0僅僅是INJDATA在遠程進程中的地址的占位符（placeholder）。你無法在編譯期得到這個值，然而你在調用 VirtualAllocEx（為INJDATA分配內存時）后確實知道INJDATA的地址！（譯者注：就是VirtualAllocEx的返回值）

    我們的NewProc編譯后大概是這個樣子：
Address   OpCode/Params     Decoded instruction
--------------------------------------------------
:00401000 55                push ebp
:00401001 8BEC              mov ebp, esp
:00401003 C745FCD0C0B0A0    mov [ebp-04], A0B0C0D0
:0040100A ...
....
....
:0040102D 8BE5              mov esp, ebp
:0040102F 5D                pop ebp
:00401030 C21000            ret 0010

    編譯后的機器碼應該為：558BECC745FCD0C0B0A0......8BE55DC21000。

    現(xiàn)在，你這么做：
    1． 把INJDATA，ThreadFunc和NewFunc復制到目的進程。
    2． 改變NewPoc的機器碼，讓pData指向INJDATA的真實地址。
    比如，假設INJDATA的的真實地址（VirtualAllocEx的返回值）為0x008a0000，你把NewProc的機器碼改為：

558BECC745FCD0C0B0A0......8BE55DC21000 <- 修改前的 NewProc 1   
558BECC745FC00008A00......8BE55DC21000 <- 修改后的 NewProc

    也就是說，你把假值 A0B0C0D0改為INJDATA的真實地址2
    3． 開始指向遠程的ThreadFunc，它子類了遠程進程中的控件。

    ¹ 你可能會問，為什么A0B0C0D0和008a0000在編譯后的機器碼中為逆序的。這時因為Intel和AMD處理器使用littl-endian標記 法（little-endian notation）來表示它們的（多字節(jié)）數(shù)據(jù)。換句話說：一個數(shù)的低字節(jié)（low-order byte）在內存中被存放在最低位，高字節(jié)（high-order byte）存放在最高位。
想像一下，存放在四個字節(jié)中的單詞“UNIX”，在big-endia系統(tǒng)中被存儲為“UNIX”，在little-endian系統(tǒng)中被存儲為 “XINU”。

    ² 一些蹩腳的破解者用類似的方法來修改可執(zhí)行文件的機器碼，但是一個程序一旦載入內存，就不能再更改自身的機器碼（一個可執(zhí)行文件的.text段是寫保護 的）。我們能修改遠程進程中的NewProc是因為它所處的那塊內存在分配時給予了PAGE_EXECUTE_READWRITE屬性。

    何時使用CreateRemoteThread和WriteProcessMemory技術

   通過CreateRemoteThread和WriteProcessMemory來注入代碼的技術，和其他兩種方法相比，不需要一個額外的DLL文件， 因此更靈活，但也更復雜更危險。一旦你的ThreadFunc中有錯誤，遠程線程會立即崩潰（看附錄F）。調試一個遠程的ThreadFunc也是場惡 夢，所以你應該在僅僅注入若干條指令時才使用這個方法。要注入大量的代碼還是使用另外兩種方法吧。

    再說一次，你可以在文章的開頭部分下載到WinSpy，InjectEx和它們的源代碼。

    寫在最后的話

    最后，我們總結一些目前還沒有提到的東西：

    方法 適用的操作系統(tǒng) 可操作的進程進程   
    I. Windows鉤子 Win9x 和WinNT 僅限鏈接了USER32.DLL的進程1   
    II. CreateRemoteThread & LoadLibrary 僅WinNT2 所有進程3，包括系統(tǒng)服務4   
    III. CreateRemoteThread & WriteProcessMemory 近WinNT 所有進程，包括系統(tǒng)服務

    1． 很明顯，你不能給一個沒有消息隊列的線程掛鉤。同樣SetWindowsHookEx也對系統(tǒng)服務不起作用（就算它們連接了USER32）。
    2． 在Win9x下沒有CreateRemoteThread和VirtualAllocEx（事實上可以在9x上模擬它們，但是到目前為止還只是個神話）
   3． 所有進程 ＝ 所有的Win32進程 ＋ csrss.exe
    本地程序（native application）比如smss.exe, os2ss.exe, autochk.exe，不使用Win32 APIs，也沒有連接到kernel32.dll。唯一的例外是csrss.exe，win32子系統(tǒng)自身。它是一個本地程序，但是它的一些庫（比如 winsrv.dll）需要Win32 DLL包括kernel32.dll.
    4.如果你向注入代碼到系統(tǒng)服務或csrss.exe，在打開遠程進程的句柄（OpenProcess）之前把你的進程的優(yōu)先級調整為 “SeDebugprovilege”(AdjustTokenPrivileges)。

    大概就這些了吧。還有一點你需要牢記在心：你注入的代碼（特別是存在錯誤時）很容易就會把目的進程拖垮。記住：責任隨權利而來（Power comes with responsibility）！

    這篇文章中的很多例子都和密碼有關，看過這篇文章后你可能也會對Zhefu Zhang（譯者注：大概是一位中國人，張哲夫??）寫的Supper Password Spy++感興趣。他講解了如何從IE的密碼框中得到密碼，也說了如何保護你的密碼不被這種攻擊。

     最后一點：讀者的反饋是文章作者的唯一報酬，所以如果你認為這篇文章有作用，請留下你的評論或給它投票。更重要的是，如果你發(fā)現(xiàn)有錯誤或bug；或你認為 什么地方做得還不夠好，有需要改進的地方；或有不清楚的地方也都請告訴我。

感謝
    首先，我要感謝我在CodeGuru（這篇文章最早是在那兒發(fā)表的）的讀者，正是由于你們的鼓勵和支持這篇文章才得以從最初的1200單詞發(fā)展到今天這樣 6000單詞的“龐然大物”。如果說有一個人我要特別感謝的話，他就是Rado Picha。這篇文章的一部分很大程度上得益于他對我的建議和幫助。最后，但也不能算是最后，感謝Susan Moore，他幫助我跨越了那個叫做“英語”的雷區(qū)，讓這篇文章更加通順達意。
――――――――――――――――――――――――――――――――――――
附錄
A) 為什么kernel32.dll和user32.dll中是被映射到相同的內存地址？
我的假定：以為微軟的程序員認為這么做可以優(yōu)化速度。讓我們來解釋一下這是為什么。
一般來說，一個可執(zhí)行文件包含幾個段，其中一個為“.reloc”段。

當鏈接器生成EXE或DLL時，它假定這個文件會被加載到一個特定的地址，也就是所謂的假定/首選加載/基地址（assumed /preferred load/base address）。內存映像（image）中的所有絕對地址都時基于該“鏈接器假定加載地址”的。如果由于某些原因，映像沒有加載到這個地址，那么PE加 載器（PE loader）就不得不修正該映像中的所有絕對地址。這就是“.reloc”段存在的原因：它包含了一個該映像中所有的“鏈接器假定地址”與真正加載到的 地址之間的差異的列表（注意：編譯器產(chǎn)生的大部分指令都使用一種相對尋址模式，所以，真正需要重定位[relocation]的地方并沒有你想像的那么 多）。如果，從另一方面說，加載器可以把映像加載到鏈接器首選地址，那么“.reloc”段就會被徹底忽略。

但是，因為每一個Win32程序都需要kernel32.dll，大部分需要user32.dll，所以如果總是把它們兩個映射到其首選地址，那么 加載器就不用修正kernel32.dll和user32.dll中的任何（絕對）地址，加載時間就可以縮短。

讓我們用下面的例子來結束這個討論：
把一個APP.exe的加載地址改為kernel32的（/base:"0x77e80000"）或 user32的（/base:"0x77e10000"）首選地址。如果App.exe沒有引入UESE32，就強制LoadLibrary。然后編譯 App.exe，并運行它。你會得到一個錯誤框（“非法的系統(tǒng)DLL重定位”），App.exe無法被加載。

為什么？當一個進程被創(chuàng)建時，Win2000和WinXP的加載器會檢查kernel32.dll和user32.dll是否被映射到它們的首選地 址（它們的名稱是被硬編碼進加載器的），如果沒有，就會報錯。在WinNT4 中ole32.dll也會被檢查。在WinNT3.51或更低版本中，則不會有任何檢查，kernel32.dll和user32.dll可以被加載到任 何地方。唯一一個總是被加載到首選地址的模塊是ntdll.dll，加載器并不檢查它，但是如果它不在它的首選地址，進程根本無法創(chuàng)建。

總結一下：在WinNT4或更高版本的操作系統(tǒng)中：
●總被加載到它們的首選地址的DLL有：kernel32.dll，user32.dll和ntdll.dll。
●Win32程序（連同csrss.exe）中一定存在的DLL：kernel32.dll和ntdll.dll。
●所有進程中都存在的dll：ntdll.dll。

B) /GZ編譯開關
在Debug時，/GZ開關默認是打開的。它可以幫你捕捉一些錯誤（詳細內容參考文檔）。但是它對我們的可執(zhí)行文件有什么影響呢？

當/GZ被使用時，編譯器會在每個函數(shù)，包含函數(shù)調用中添加額外的代碼（添加到每個函數(shù)的最后面）來檢查ESP棧指針是否被我們的函數(shù)更改過。但 是，等等，ThreadFunc中被添加了一個函數(shù)調用？這就是通往災難的道路。因為，被復制到遠程進程中的ThreadFunc將調用一個在遠程進程中 不存在的函數(shù)。

C) static函數(shù)和增量連接（Incremental linking）
增量連接可以縮短連接的時間，在增量編譯時，每個函數(shù)調用都 是通過一個額外的JMP指令來實現(xiàn)的（一個例外就是被聲明為static的函數(shù)！）這些JMP允許連接器移動函數(shù)在內存中的位置而不用更新調用該函數(shù)的 CALL。但是就是這個JMP給我們帶來了麻煩：現(xiàn)在ThreadFunc和AfterThreadFunc將指向JMP指令而不是它們的真實代碼。所 以，當計算ThreadFunc的大小時：
const int cbCodeSize = ((LPBYTE) AfterThreadFunc - (LPBYTE) ThreadFunc);
你實際得到的將是指向ThreadFunc和AfterThreadFunc的JMP指令之間的“距離”。現(xiàn)在假設我們的ThreadFunc在 004014C0，和其對應的JMP指令在00401020
:00401020   jmp 004014C0
...
:004014C0   push EBP          ; ThreadFunc的真實地址
:004014C1   mov EBP, ESP
...
然后，
WriteProcessMemory( .., &ThreadFunc, cbCodeSize, ..);
將把“JMP 004014C0”和其后的cbCodeSize范圍內的代碼而不是ThreadFunc復制到遠程進程。遠程線程首先會執(zhí)行“JMP 004010C0”，然后一直執(zhí)行到這個進程代碼的最后一條指令（譯者注：這當然不是我們想要的結果）。

然而，如果一個函數(shù)被聲明為static，就算使用增量連接，也不會被替換為JMP指令。這就是為什么我在規(guī)則#4中說把ThreadFunc和 AfterThreadFunc聲明為static或禁止增量連接的原因了。（關于增量連接的其他方面請參看Matt Pietrek寫的“Remove Fatty Deposits from Your Applications Using Our 32-bit Liposuction Tools”）

D) 為什么ThreadFunc只能有4K的局部變量？
局部變量總是保存在棧上的。假設一個函數(shù)有256字節(jié)的局部變量，當進入該函數(shù)時（更確切地說是在functions prologue中），棧指針會被減去256。像下面的函數(shù)：
void Dummy(void) {
    BYTE var[256];
    var[0] = 0;
    var[1] = 1;
    var[255] = 255;
}
會被編譯為類似下面的指令：
:00401000   push ebp
:00401001   mov ebp, esp
:00401003   sub esp, 00000100           ; change ESP as storage for
                                         ; local variables is needed
:00401006   mov byte ptr [esp], 00      ; var[0] = 0;
:0040100A   mov byte ptr [esp+01], 01   ; var[1] = 1;
:0040100F   mov byte ptr [esp+FF], FF   ; var[255] = 255;
:00401017   mov esp, ebp                ; restore stack pointer
:00401019   pop ebp
:0040101A   ret

請注意在上面的例子中ESP（棧指針）是如何被改變的。但是如果一個函數(shù)有多于4K的局部變量該怎么辦？這種情況下，棧指針不會被直接改變，而是通 過一個函數(shù)調用來正確實現(xiàn)ESP的改變。但是就是這個“函數(shù)調用”導致了ThreadFunc的崩潰，因為它在遠程進程中的拷貝將會調用一個不存在的函 數(shù)。

讓我們來看看文檔關于棧探針（stack probes）和/Gs編譯選項的說明：
“/Gssize選項是一個允許你控制棧探針的高級特性。棧探針是編譯器插入到每個函數(shù)調用中的一系列代碼。當被激活時，棧探針將溫和地按照存儲函數(shù)局部 變量所需要的空間大小來移動

如果一個函數(shù)需要大于size指定的局部變量空間，它的棧探針將被激活。默認的size為一個頁的大小（在80x86上為4k）。這個值可以使一個 Win32程序和Windows NT的虛擬內存管理程序和諧地交互，在運行期間向程序棧增加已提交的內存總數(shù)。

我能確定你們對上面的敘述（“棧探針將溫和地按照存儲函數(shù)局部變量所需要的空間大小來移動”）感到奇怪。這些編譯選項（他們的描述！）有時候真的讓 人很惱火，特別是當你想真的了解它們是怎么工作的時候。打個比方，如果一個函數(shù)需要12kb的空間來存放局部變量，棧上的內存是這樣“分配”的
sub    esp, 0x1000    ; 先“分配”4 Kb
test [esp], eax      ; touches memory in order to commit a
                      ; new page (if not already committed)
sub    esp, 0x1000    ; “分配”第二個 4 Kb
test [esp], eax      ; ...
sub    esp, 0x1000
test [esp], eax

注意棧指針是如何以4Kb為單位移動的，更重要的是每移動一步后使用test對棧底的處理（more importantly, how the bottom of the stack is "touched" after each step）。這可以確保了在“分配”下一個頁之前，包含棧底的頁已經(jīng)被提交。

繼續(xù)閱讀文檔的說明：
“每一個新的線程會擁有（receives）自己的棧空間，這包括已經(jīng)提交的內存和保留的內存。默認情況下每個線程使 用1MB的保留內存和一個頁大小的以提交內存。如果有必要，系統(tǒng)將從保留內存中提交一個頁。”（看MSDN中GreateThread > dwStackSize > “Thread Stack Size”）

..現(xiàn)在為什么文檔中說“這個值可以使一個Win32程序和Windows NT的虛擬內存管理程序和諧地交互”也很清楚了。

E) 為什么我要把多于3個case分支的swith分割開來呢？
同樣，用例子來說明會簡單些：
int Dummy( int arg1 )
{
    int ret =0;

    switch( arg1 ) {
    case 1: ret = 1; break;
    case 2: ret = 2; break;
    case 3: ret = 3; break;
    case 4: ret = 0xA0B0; break;
    }
    return ret;
}
將會被編譯為類似下面的代碼：
Address   OpCode/Params    Decoded instruction
--------------------------------------------------
                                             ; arg1 -> ECX
:00401000 8B4C2404         mov ecx, dword ptr [esp+04]
:00401004 33C0             xor eax, eax     ; EAX = 0
:00401006 49               dec ecx          ; ECX --
:00401007 83F903           cmp ecx, 00000003
:0040100A 771E             ja 0040102A

; JMP to one of the addresses in table ***
; note that ECX contains the offset
:0040100C FF248D2C104000   jmp dword ptr [4*ecx+0040102C]

:00401013 B801000000       mov eax, 00000001   ; case 1: eax = 1;
:00401018 C3               ret
:00401019 B802000000       mov eax, 00000002   ; case 2: eax = 2;
:0040101E C3               ret
:0040101F B803000000       mov eax, 00000003   ; case 3: eax = 3;
:00401024 C3               ret
:00401025 B8B0A00000       mov eax, 0000A0B0   ; case 4: eax = 0xA0B0;
:0040102A C3               ret
:0040102B 90               nop

; 地址表 ***
:0040102C 13104000         DWORD 00401013   ; jump to case 1
:00401030 19104000         DWORD 00401019   ; jump to case 2
:00401034 1F104000         DWORD 0040101F   ; jump to case 3
:00401038 25104000         DWORD 00401025   ; jump to case 4

看到switch-case是如何實現(xiàn)的了嗎？
它沒有去測試每個case分支，而是創(chuàng)建了一個地址表（address table）。我們簡單地計算出在地址表中偏移就可以跳到正確的case分支。想想吧，這真是一個進步，假設你有一個50個分支的switch語句，假如 沒有這個技巧，你不的不執(zhí)行50次CMP和JMP才能到達最后一個case，而使用地址表，你可以通過一次查表即跳到正確的case。使用算法的時間復雜 度來衡量：我們把O（2n）的算法替換成了O(5)的算法，其中：
1． O代表最壞情況下的時間復雜度。
2． 我們假設計算偏移（即查表）并跳到正確的地址需要5個指令。

現(xiàn)在，你可能認為上面的情況僅僅是因為case常量選擇得比較好，（1，2，3，4，5）。幸運的是，現(xiàn)實生活中的大多數(shù)例子都可以應用這個方案， 只是偏移的計算復雜了一點而已。但是，有兩個例外：
●如果少于3個case分支，或
●如果case常量是完全相互無關的。（比如 1， 13， 50， 1000）。
最終的結果和你使用普通的if-else if是一樣的。

有趣的地方：如果你曾經(jīng)為case后面只能跟常量而迷惑的話，現(xiàn)在你應該知道為什么了吧。這個值必須在編譯期間就確定下來，這樣才能創(chuàng)建地址表。

回到我們的問題！
注意到0040100C處的JMP指令了嗎？我們來看看Intel的文檔對十六進制操作碼FF的說明：
Opcode   Instruction Description
FF /4    JMP r/m32   Jump near, absolute indirect, address given in r/m32

JMP使用了絕對地址！也就是說，它的其中一個操作數(shù)（在這里是0040102C）代表一個絕對地址。還用多說嗎？現(xiàn)在遠程的ThreadFunc 會盲目第在地址表中004101C然后跳到這個錯誤的地方，馬上使遠程進程掛掉了。

F) 到底是什么原因使遠程進程崩潰了？
如果你的遠程進程崩潰了，原因可能為下列之一：
1． 你引用了ThreadFunc中一個不存在的字符串。
2． ThreadFunc中一個或多個指令使用了絕對尋址（看附錄E中的例子）
3． ThreadFunc調用了一個不存在的函數(shù)（這個函數(shù)調用可能是編譯器或連接器添加的）。這時候你需要在反匯編器中尋找類似下面的代碼：
:004014C0    push EBP         ; entry point of ThreadFunc
:004014C1    mov EBP, ESP
...
:004014C5    call 0041550     ; 在這里崩潰了
                              ; remote process
...
:00401502    ret
如果這個有爭議的CALL是編譯器添加的（因為一些不該打開的編譯開關比如/GZ打開了），它要么在ThreadFunc的開頭要么在 ThreadFunc接近結尾的地方

不管在什么情況下，你使用CreateRemoteThread & WriteProcessMemory技術時必須萬分的小心，特別是編譯器/連接器的設置，它們很可能會給你的ThreadFunc添加一些帶來麻煩的東 西。