轉(zhuǎn)載（不要一輩子靠技術(shù)生存）

posted @ 2013-04-14 22:27 深邃者 閱讀(483) | 評(píng)論 (1) | 編輯 收藏

五種程序設(shè)計(jì)方法

posted @ 2010-09-16 14:45 深邃者 閱讀(319) | 評(píng)論 (0) | 編輯 收藏

程序的內(nèi)存分配

堆和棧的理論知識(shí)
2.1申請(qǐng)方式
stack:
由系統(tǒng)自動(dòng)分配。 例如，聲明在函數(shù)中一個(gè)局部變量 int b; 系統(tǒng)自動(dòng)在棧中為b開(kāi)辟空間
heap:
需要程序員自己申請(qǐng)，并指明大小，在c中malloc函數(shù)
如p1 = (char *)malloc(10);
在C++中用new運(yùn)算符
如p2 = (char *)malloc(10);
但是注意p1、p2本身是在棧中的。
2.2申請(qǐng)后系統(tǒng)的響應(yīng)
棧：只要棧的剩余空間大于所申請(qǐng)空間，系統(tǒng)將為程序提供內(nèi)存，否則將報(bào)異常提示棧溢出。
堆：首先應(yīng)該知道操作系統(tǒng)有一個(gè)記錄空閑內(nèi)存地址的鏈表，當(dāng)系統(tǒng)收到程序的申請(qǐng)時(shí)，
會(huì) 遍歷該鏈表，尋找第一個(gè)空間大于所申請(qǐng)空間的堆結(jié)點(diǎn)，然后將該結(jié)點(diǎn)從空閑結(jié)點(diǎn)鏈表中刪除，并將該結(jié)點(diǎn)的空間分配給程序，另外，對(duì)于大多數(shù)系統(tǒng)，會(huì)在這塊內(nèi) 存空間中的首地址處記錄本次分配的大小，這樣，代碼中的delete語(yǔ)句才能正確的釋放本內(nèi)存空間。另外，由于找到的堆結(jié)點(diǎn)的大小不一定正好等于申請(qǐng)的大 小，系統(tǒng)會(huì)自動(dòng)的將多余的那部分重新放入空閑鏈表中。
2.3申請(qǐng)大小的限制
棧：在Windows下,棧是向低地址擴(kuò)展的數(shù)據(jù)結(jié)構(gòu)，是一塊 連續(xù)的內(nèi)存的區(qū)域。這句話(huà)的意思是棧頂?shù)牡刂泛蜅５淖畲笕萘渴窍到y(tǒng)預(yù)先規(guī)定好的，在 WINDOWS下，棧的大小是2M（也有的說(shuō)是1M，總之是一個(gè)編譯時(shí)就確定的常數(shù)），如果申請(qǐng)的空間超過(guò)棧的剩余空間時(shí)，將提示overflow。因 此，能從棧獲得的空間較小。
堆：堆是向高地址擴(kuò)展的數(shù)據(jù)結(jié)構(gòu)，是不連續(xù)的內(nèi)存區(qū)域。這是由于系統(tǒng)是用鏈表來(lái)存儲(chǔ)的空閑內(nèi)存地址的，自然是不連續(xù)的，而鏈表的遍歷方向是由低地址向高地址。堆的大小受限于計(jì)算機(jī)系統(tǒng)中有效的虛擬內(nèi)存。由此可見(jiàn)，堆獲得的空間比較靈活，也比較大。
2.4申請(qǐng)效率的比較：
棧由系統(tǒng)自動(dòng)分配，速度較快。但程序員是無(wú)法控制的。
堆是由new分配的內(nèi)存，一般速度比較慢，而且容易產(chǎn)生內(nèi)存碎片,不過(guò)用起來(lái)最方便.
另外，在WINDOWS下，最好的方式是用VirtualAlloc分配內(nèi)存，他不是在堆，也不是在棧是直接在進(jìn)程的地址空間中保留一快內(nèi)存，雖然用起來(lái)最不方便。但是速度， 也最靈活
2.5堆和棧中的存儲(chǔ)內(nèi)容
棧： 在函數(shù)調(diào)用時(shí)，第一個(gè)進(jìn)棧的是主函數(shù)中后的下一條指令（函數(shù)調(diào)用語(yǔ)句的下一條可執(zhí)行語(yǔ)句）的地址，然后是函數(shù)的各個(gè)參數(shù)，在大多數(shù)的C編譯器中，參數(shù)是由右往左入棧的，然后是函數(shù)中的局部變量。注意靜態(tài)變量是不入棧的。
當(dāng)本次函數(shù)調(diào)用結(jié)束后，局部變量先出棧，然后是參數(shù)，最后棧頂指針指向最開(kāi)始存的地址，也就是主函數(shù)中的下一條指令，程序由該點(diǎn)繼續(xù)運(yùn)行。
堆：一般是在堆的頭部用一個(gè)字節(jié)存放堆的大小。堆中的具體內(nèi)容有程序員安排。
2.6存取效率的比較

char s1[] = "aaaaaaaaaaaaaaa";
char *s2 = "bbbbbbbbbbbbbbbbb";
aaaaaaaaaaa是在運(yùn)行時(shí)刻賦值的；
而bbbbbbbbbbb是在編譯時(shí)就確定的；
但是，在以后的存取中，在棧上的數(shù)組比指針?biāo)赶虻淖址?例如堆)快。
比如：
#include
void main()
{
char a = 1;
char c[] = "1234567890";
char *p ="1234567890";
a = c[1];
a = p[1];
return;
}
對(duì)應(yīng)的匯編代碼
10: a = c[1];
00401067 8A 4D F1 mov cl,byte ptr [ebp-0Fh]
0040106A 88 4D FC mov byte ptr [ebp-4],cl
11: a = p[1];
0040106D 8B 55 EC mov edx,dword ptr [ebp-14h]
00401070 8A 42 01 mov al,byte ptr [edx+1]
00401073 88 45 FC mov byte ptr [ebp-4],al
第一種在讀取時(shí)直接就把字符串中的元素讀到寄存器cl中，而第二種則要先把指edx中，在根據(jù)edx讀取字符，顯然慢了。

2.7小結(jié)：
堆和棧的區(qū)別可以用如下的比喻來(lái)看出：
使用棧就象我們?nèi)ワ堭^里吃飯，只管點(diǎn)菜（發(fā)出申請(qǐng)）、付錢(qián)、和吃（使用），吃飽了就走，不必理會(huì)切菜、洗菜等準(zhǔn)備工作和洗碗、刷鍋等掃尾工作，他的好處是快捷，但是自由度小。
使用堆就象是自己動(dòng)手做喜歡吃的菜肴，比較麻煩，但是比較符合自己的口味，而且自由度大。

posted @ 2010-09-16 14:22 深邃者 閱讀(341) | 評(píng)論 (1) | 編輯 收藏

代碼注入的三種方法

• Windows 鉤子
• CreateRemoteThread 和 LoadLibrary 技術(shù)
  ——進(jìn)程間通信
• CreateRemoteThread 和 WriteProcessMemory 技術(shù)
  ——如何用該技術(shù)子類(lèi)化遠(yuǎn)程控件
  ——何時(shí)使用 CreateRemoteThread 和 WriteProcessMemory 技術(shù)
• 結(jié)束語(yǔ)
• 附錄A
• 附錄B
• 附錄C
• 附錄D
• 附錄E
• 附錄F
• 參考資料
  

簡(jiǎn)介

　　本文將討論如何把代碼注入不同的進(jìn)程地址空間，然后在該進(jìn)程的上下文中執(zhí)行注入的代碼。 我們?cè)诰W(wǎng)上可以查到一些窗口/密碼偵測(cè)的應(yīng)用例子，網(wǎng)上的這些程序大多都依賴(lài) Windows 鉤子技術(shù)來(lái)實(shí)現(xiàn)。本文將討論除了使用 Windows 鉤子技術(shù)以外的其它技術(shù)來(lái)實(shí)現(xiàn)這個(gè)功能。如圖一所示：

圖一　WinSpy 密碼偵測(cè)程序

為了找到解決問(wèn)題的方法。首先讓我們簡(jiǎn)單回顧一下問(wèn)題背景。
　　要“讀取”某個(gè)控件的內(nèi)容——無(wú)論這個(gè)控件是否屬于當(dāng)前的應(yīng)用程序——通常都是發(fā)送 WM_GETTEXT 消息來(lái)實(shí)現(xiàn)。這個(gè)技術(shù)也同樣應(yīng)用到編輯控件，但是如果該編輯控件屬于另外一個(gè)進(jìn)程并設(shè)置了 ES_PASSWORD 式樣，那么上面講的方法就行不通了。用 WM_GETTEXT 來(lái)獲取控件的內(nèi)容只適用于進(jìn)程“擁有”密碼控件的情況。所以我們的問(wèn)題變成了如何在另外一個(gè)進(jìn)程的地址空間執(zhí)行：

::SendMessage( hPwdEdit, WM_GETTEXT, nMaxChars, psBuffer );

通常有三種可能性來(lái)解決這個(gè)問(wèn)題。

1. 將你的代碼放入某個(gè) DLL，然后通過(guò) Windows 鉤子映射該DLL到遠(yuǎn)程進(jìn)程；
2. 將你的代碼放入某個(gè) DLL，然后通過(guò) CreateRemoteThread 和 LoadLibrary 技術(shù)映射該DLL到遠(yuǎn)程進(jìn)程；
3. 如果不寫(xiě)單獨(dú)的 DLL，可以直接將你的代碼拷貝到遠(yuǎn)程進(jìn)程——通過(guò) WriteProcessMemory——并用 CreateRemoteThread 啟動(dòng)它的執(zhí)行。本文將在第三部分詳細(xì)描述該技術(shù)實(shí)現(xiàn)細(xì)節(jié)；

第一部分： Windows 鉤子

范例程序——參見(jiàn)HookSpy 和HookInjEx

　　Windows 鉤子主要作用是監(jiān)控某些線(xiàn)程的消息流。通常我們將鉤子分為本地鉤子和遠(yuǎn)程鉤子以及系統(tǒng)級(jí)鉤子，本地鉤子一般監(jiān)控屬于本進(jìn)程的線(xiàn)程的消息流，遠(yuǎn)程鉤子是線(xiàn)程專(zhuān)用的，用于監(jiān)控屬于另外進(jìn)程的線(xiàn)程消息流。系統(tǒng)級(jí)鉤子監(jiān)控運(yùn)行在當(dāng)前系統(tǒng)中的所有線(xiàn)程的消息流。
　　如果鉤子作用的線(xiàn)程屬于另外的進(jìn)程，那么你的鉤子過(guò)程必須駐留在某個(gè)動(dòng)態(tài)鏈接庫(kù)（DLL）中。然后系統(tǒng)映射包含鉤子過(guò)程的DLL到鉤子作用的線(xiàn)程的地址空間。Windows將映射整個(gè) DLL，而不僅僅是鉤子過(guò)程。這就是為什么 Windows 鉤子能被用于將代碼注入到別的進(jìn)程地址空間的原因。
　　本文我不打算涉及鉤子的具體細(xì)節(jié)（關(guān)于鉤子的細(xì)節(jié)請(qǐng)參見(jiàn) MSDN 庫(kù)中的 SetWindowHookEx API），但我在此要給出兩個(gè)很有用心得，在相關(guān)文檔中你是找不到這些內(nèi)容的：

1. 在成功調(diào)用 SetWindowsHookEx 后，系統(tǒng)自動(dòng)映射 DLL 到鉤子作用的線(xiàn)程地址空間，但不必立即發(fā)生映射，因?yàn)?Windows 鉤子都是消息，DLL 在消息事件發(fā)生前并沒(méi)有產(chǎn)生實(shí)際的映射。例如：
   　　如果你安裝一個(gè)鉤子監(jiān)控某些線(xiàn)程（WH_CALLWNDPROC）的非隊(duì)列消息，在消息被實(shí)際發(fā)送到（某些窗口的）鉤子作用的線(xiàn)程之前，該DLL 是不會(huì)被映射到遠(yuǎn)程進(jìn)程的。換句話(huà)說(shuō)，如果 UnhookWindowsHookEx 在某個(gè)消息被發(fā)送到鉤子作用的線(xiàn)程之前被調(diào)用，DLL 根本不會(huì)被映射到遠(yuǎn)程進(jìn)程（即使 SetWindowsHookEx 本身調(diào)用成功）。為了強(qiáng)制進(jìn)行映射，在調(diào)用 SetWindowsHookEx 之后馬上發(fā)送一個(gè)事件到相關(guān)的線(xiàn)程。
   　　在UnhookWindowsHookEx了之后，對(duì)于沒(méi)有映射的DLL處理方法也一樣。只有在足夠的事件發(fā)生后，DLL才會(huì)有真正的映射。
2. 當(dāng)你安裝鉤子后，它們可能影響整個(gè)系統(tǒng)得性能（尤其是系統(tǒng)級(jí)鉤子），但是你可以很容易解決這個(gè)問(wèn)題，如果你使用線(xiàn)程專(zhuān)用鉤子的DLL映射機(jī)制，并不截獲消息。考慮使用如下代碼：
   

   BOOL APIENTRY DllMain( HANDLE hModule,
       DWORD  ul_reason_for_call,
       LPVOID lpReserved )
       {
       if( ul_reason_for_call == DLL_PROCESS_ATTACH )
       {
       // Increase reference count via LoadLibrary
       char lib_name[MAX_PATH];
       ::GetModuleFileName( hModule, lib_name, MAX_PATH );
       ::LoadLibrary( lib_name );
       // Safely remove hook
       ::UnhookWindowsHookEx( g_hHook );
       }
       return TRUE;
       }			

   　　那么會(huì)發(fā)生什么呢？首先我們通過(guò)Windows 鉤子將DLL映射到遠(yuǎn)程進(jìn)程。然后，在DLL被實(shí)際映射之后，我們解開(kāi)鉤子。通常當(dāng)?shù)谝粋€(gè)消息到達(dá)鉤子作用線(xiàn)程時(shí)，DLL此時(shí)也不會(huì)被映射。這里的處理技巧是調(diào)用LoadLibrary通過(guò)增加 DLLs的引用計(jì)數(shù)來(lái)防止映射不成功。
   　　現(xiàn)在剩下的問(wèn)題是如何卸載DLL，UnhookWindowsHookEx 是不會(huì)做這個(gè)事情的，因?yàn)殂^子已經(jīng)不作用于線(xiàn)程了。你可以像下面這樣做：
   
   
   • 就在你想要解除DLL映射前，安裝另一個(gè)鉤子；
   • 發(fā)送一個(gè)“特殊”消息到遠(yuǎn)程線(xiàn)程；
   • 在鉤子過(guò)程中截獲這個(gè)消息，響應(yīng)該消息時(shí)調(diào)用 FreeLibrary 和 UnhookWindowsHookEx；

    

   　　目前只使用了鉤子來(lái)從處理遠(yuǎn)程進(jìn)程中DLL的映射和解除映射。在此“作用于線(xiàn)程的”鉤子對(duì)性能沒(méi)有影響。
   下面我們將討論另外一種方法，這個(gè)方法與 LoadLibrary 技術(shù)的不同之處是DLL的映射機(jī)制不會(huì)干預(yù)目標(biāo)進(jìn)程。相對(duì)LoadLibrary 技術(shù)，這部分描述的方法適用于 WinNT和Win9x。
   　　但是，什么時(shí)候使用這個(gè)技巧呢？答案是當(dāng)DLL必須在遠(yuǎn)程進(jìn)程中駐留較長(zhǎng)時(shí)間（即如果你子類(lèi)化某個(gè)屬于另外一個(gè)進(jìn)程的控件時(shí)）以及你想盡可能少的干涉目標(biāo)進(jìn)程時(shí)。我在 HookSpy 中沒(méi)有使用它，因?yàn)樽⑷隓LL 的時(shí)間并不長(zhǎng)——注入時(shí)間只要足夠得到密碼即可。我提供了另外一個(gè)例子程序——HookInjEx——來(lái)示范。HookInjEx 將DLL映射到資源管理器“explorer.exe”，并從中/解除影射，它子類(lèi)化“開(kāi)始”按鈕，并交換鼠標(biāo)左右鍵單擊“開(kāi)始”按鈕的功能。

HookSpy 和 HookInjEx 的源代碼都可以從本文的下載源代碼中獲得。

第二部分：CreateRemoteThread 和 LoadLibrary 技術(shù)

范例程序——LibSpy

通常，任何進(jìn)程都可以通過(guò) LoadLibrary API 動(dòng)態(tài)加載DLL。但是，如何強(qiáng)制一個(gè)外部進(jìn)程調(diào)用這個(gè)函數(shù)呢？答案是：CreateRemoteThread。
首先，讓我們看一下 LoadLibrary 和FreeLibrary API 的聲明：

HINSTANCE LoadLibrary(
LPCTSTR lpLibFileName // 庫(kù)模塊文件名的地址
);
BOOL FreeLibrary(
HMODULE hLibModule // 要加載的庫(kù)模塊的句柄
);

現(xiàn)在將它們與傳遞到 CreateRemoteThread 的線(xiàn)程例程——ThreadProc 的聲明進(jìn)行比較。

DWORD WINAPI ThreadProc(
LPVOID lpParameter // 線(xiàn)程數(shù)據(jù)
);

你可以看到，所有函數(shù)都使用相同的調(diào)用規(guī)范并都接受 32位參數(shù)，返回值的大小都相同。也就是說(shuō)，我們可以傳遞一個(gè)指針到LoadLibrary/FreeLibrary 作為到 CreateRemoteThread 的線(xiàn)程例程。但這里有兩個(gè)問(wèn)題，請(qǐng)看下面對(duì)CreateRemoteThread 的描述：

1. CreateRemoteThread 的 lpStartAddress 參數(shù)必須表示遠(yuǎn)程進(jìn)程中線(xiàn)程例程的開(kāi)始地址。
2. 如果傳遞到 ThreadFunc 的參數(shù)lpParameter——被解釋為常規(guī)的 32位值（FreeLibrary將它解釋為一個(gè) HMODULE），一切OK。但是，如果 lpParameter 被解釋為一個(gè)指針（LoadLibraryA將它解釋為一個(gè)串指針）。它必須指向遠(yuǎn)程進(jìn)程的某些數(shù)據(jù)。

　　第一個(gè)問(wèn)題實(shí)際上是由它自己解決的。LoadLibrary 和 FreeLibray 兩個(gè)函數(shù)都在 kernel32.dll 中。因?yàn)楸仨毐ＷCkernel32存在并且在每個(gè)“常規(guī)”進(jìn)程中的加載地址要相同，LoadLibrary/FreeLibray 的地址在每個(gè)進(jìn)程中的地址要相同，這就保證了有效的指針被傳遞到遠(yuǎn)程進(jìn)程。
　　第二個(gè)問(wèn)題也很容易解決。只要通過(guò) WriteProcessMemory 將 DLL 模塊名（LoadLibrary需要的DLL模塊名）拷貝到遠(yuǎn)程進(jìn)程即可。

所以，為了使用CreateRemoteThread 和 LoadLibrary 技術(shù)，需要按照下列步驟來(lái)做：

1. 獲取遠(yuǎn)程進(jìn)程（OpenProcess）的 HANDLE；
2. 為遠(yuǎn)程進(jìn)程中的 DLL名分配內(nèi)存（VirtualAllocEx）；
3. 將 DLL 名，包含全路徑名，寫(xiě)入分配的內(nèi)存（WriteProcessMemory）；
4. 用 CreateRemoteThread 和 LoadLibrary. 將你的DLL映射到遠(yuǎn)程進(jìn)程；
5. 等待直到線(xiàn)程終止（WaitForSingleObject），也就是說(shuō)直到 LoadLibrary 調(diào)用返回。另一種方法是，一旦 DllMain（用DLL_PROCESS_ATTACH調(diào)用）返回，線(xiàn)程就會(huì)終止；
6. 獲取遠(yuǎn)程線(xiàn)程的退出代碼（GetExitCodeThread）。注意這是一個(gè) LoadLibrary 返回的值，因此是所映射 DLL 的基地址（HMODULE）。
   在第二步中釋放分配的地址（VirtualFreeEx）；
7. 用 CreateRemoteThread 和 FreeLibrary從遠(yuǎn)程進(jìn)程中卸載 DLL。傳遞在第六步獲取的 HMODULE 句柄到 FreeLibrary（通過(guò) CreateRemoteThread 的lpParameter參數(shù)）；
8. 注意：如果你注入的 DLL 產(chǎn)生任何新的線(xiàn)程，一定要在卸載DLL 之前將它們都終止掉；
9. 等待直到線(xiàn)程終止（WaitForSingleObject）；

　　此外，處理完成后不要忘了關(guān)閉所有句柄，包括在第四步和第八步創(chuàng)建的兩個(gè)線(xiàn)程以及在第一步獲取的遠(yuǎn)程線(xiàn)程句柄。現(xiàn)在讓我們看一下 LibSpy 的部分代碼，為了簡(jiǎn)單起見(jiàn)，上述步驟的實(shí)現(xiàn)細(xì)節(jié)中的錯(cuò)誤處理以及 UNICODE 支持部分被略掉。

HANDLE hThread;
char    szLibPath[_MAX_PATH];  // “LibSpy.dll”模塊的名稱(chēng) (包括全路徑);
void*   pLibRemote;   // 遠(yuǎn)程進(jìn)程中的地址，szLibPath 將被拷貝到此處;
DWORD   hLibModule;   // 要加載的模塊的基地址（HMODULE）
HMODULE hKernel32 = ::GetModuleHandle("Kernel32");
// 初始化szLibPath
//...
// 1. 在遠(yuǎn)程進(jìn)程中為szLibPath 分配內(nèi)存
// 2. 將szLibPath 寫(xiě)入分配的內(nèi)存
pLibRemote = ::VirtualAllocEx( hProcess, NULL, sizeof(szLibPath),
MEM_COMMIT, PAGE_READWRITE );
::WriteProcessMemory( hProcess, pLibRemote, (void*)szLibPath,
sizeof(szLibPath), NULL );
// 將"LibSpy.dll" 加載到遠(yuǎn)程進(jìn)程（使用CreateRemoteThread 和 LoadLibrary）
hThread = ::CreateRemoteThread( hProcess, NULL, 0,
(LPTHREAD_START_ROUTINE) ::GetProcAddress( hKernel32,
"LoadLibraryA" ),
pLibRemote, 0, NULL );
::WaitForSingleObject( hThread, INFINITE );
// 獲取所加載的模塊的句柄
::GetExitCodeThread( hThread, &hLibModule );
// 清除
::CloseHandle( hThread );
::VirtualFreeEx( hProcess, pLibRemote, sizeof(szLibPath), MEM_RELEASE );		

// 從目標(biāo)進(jìn)程中卸載"LibSpy.dll"  (使用 CreateRemoteThread 和 FreeLibrary)
hThread = ::CreateRemoteThread( hProcess, NULL, 0,
(LPTHREAD_START_ROUTINE) ::GetProcAddress( hKernel32,
"FreeLibrary" ),
(void*)hLibModule, 0, NULL );
::WaitForSingleObject( hThread, INFINITE );
// 清除
::CloseHandle( hThread );		

第三部分：CreateRemoteThread 和 WriteProcessMemory 技術(shù)

范例程序——WinSpy

　　另外一個(gè)將代碼拷貝到另一個(gè)進(jìn)程地址空間并在該進(jìn)程上下文中執(zhí)行的方法是使用遠(yuǎn)程線(xiàn)程和 WriteProcessMemory API。這種方法不用編寫(xiě)單獨(dú)的DLL，而是用 WriteProcessMemory 直接將代碼拷貝到遠(yuǎn)程進(jìn)程——然后用 CreateRemoteThread 啟動(dòng)它執(zhí)行。先來(lái)看看 CreateRemoteThread 的聲明：

HANDLE CreateRemoteThread(
HANDLE hProcess,        // 傳入創(chuàng)建新線(xiàn)程的進(jìn)程句柄
LPSECURITY_ATTRIBUTES lpThreadAttributes,  // 安全屬性指針
DWORD dwStackSize,      // 字節(jié)為單位的初始線(xiàn)程堆棧
LPTHREAD_START_ROUTINE lpStartAddress,     // 指向線(xiàn)程函數(shù)的指針
LPVOID lpParameter,     // 新線(xiàn)程使用的參數(shù)
DWORD dwCreationFlags,  // 創(chuàng)建標(biāo)志
LPDWORD lpThreadId      // 指向返回的線(xiàn)程ID
);				

• 在 CreateRemoteThread中，hProcess是額外的一個(gè)參數(shù)，一個(gè)進(jìn)程句柄，新線(xiàn)程就是在這個(gè)進(jìn)程中創(chuàng)建的；
• 在 CreateRemoteThread中，lpStartAddress 表示的是在遠(yuǎn)程進(jìn)程地址空間中的線(xiàn)程起始地址。線(xiàn)程函數(shù)必須要存在于遠(yuǎn)程進(jìn)程中，所以我們不能簡(jiǎn)單地傳遞一個(gè)指針到本地的 ThreadFunc。必須得先拷貝代碼到遠(yuǎn)程進(jìn)程；
• 同樣，lpParameter 指向的數(shù)據(jù)也必須要存在于遠(yuǎn)程進(jìn)程，所以也得將它拷貝到那。

綜上所述，我們得按照如下的步驟來(lái)做：

1. 獲取一個(gè)遠(yuǎn)程進(jìn)程的HANDLE (OpenProces) ；
2. 在遠(yuǎn)程進(jìn)程地址空間中為注入的數(shù)據(jù)分配內(nèi)存（VirtualAllocEx）；
3. 將初始的 INDATA 數(shù)據(jù)結(jié)構(gòu)的一個(gè)拷貝寫(xiě)入分配的內(nèi)存中（WriteProcessMemory）；
4. 在遠(yuǎn)程進(jìn)程地址空間中為注入的代碼分配內(nèi)存；
5. 將 ThreadFunc 的一個(gè)拷貝寫(xiě)入分配的內(nèi)存；
6. 用 CreateRemoteThread啟動(dòng)遠(yuǎn)程的 ThreadFunc 拷貝；
7. 等待遠(yuǎn)程線(xiàn)程終止（WaitForSingleObject）；
8. 獲取遠(yuǎn)程來(lái)自遠(yuǎn)程進(jìn)程的結(jié)果（ReadProcessMemory 或 GetExitCodeThread）；
9. 釋放在第二步和第四步中分配的內(nèi)存（VirtualFreeEx）；
10. 關(guān)閉在第六步和第一步獲取的句柄（CloseHandle）；

ThreadFunc 必須要遵循的原則：

1. 除了kernel32.dll 和user32.dll 中的函數(shù)之外，ThreadFunc 不要調(diào)用任何其它函數(shù)，只有 kernel32.dll 和user32.dll被保證在本地和目標(biāo)進(jìn)程中的加載地址相同（注意，user32.dll并不是被映射到每個(gè) Win32 的進(jìn)程）。如果你需要來(lái)自其它庫(kù)中的函數(shù)，將LoadLibrary 和 GetProcAddress 的地址傳給注入的代碼，然后放手讓它自己去做。如果映射到目標(biāo)進(jìn)程中的DLL有沖突，你也可以用 GetModuleHandle 來(lái)代替 LoadLibrary。
   　　同樣，如果你想在 ThreadFunc 中調(diào)用自己的子例程，要單獨(dú)把每個(gè)例程的代碼拷貝到遠(yuǎn)程進(jìn)程并用 INJDATA為 ThreadFunc 提供代碼的地址。
2. 不要使用靜態(tài)字符串，而要用 INJDATA 來(lái)傳遞所有字符串。之所以要這樣，是因?yàn)榫幾g器將靜態(tài)字符串放在可執(zhí)行程序的“數(shù)據(jù)段”中，可是引用（指針）是保留在代碼中的。那么，遠(yuǎn)程進(jìn)程中ThreadFunc 的拷貝指向的內(nèi)容在遠(yuǎn)程進(jìn)程的地址空間中是不存在的。
3. 去掉 /GZ 編譯器開(kāi)關(guān)，它在調(diào)試版本中是默認(rèn)設(shè)置的。
4. 將 ThreadFunc 和 AfterThreadFunc 聲明為靜態(tài)類(lèi)型，或者不啟用增量鏈接。
5. ThreadFunc 中的局部變量一定不能超過(guò)一頁(yè)（也就是 4KB）。
   注意在調(diào)試版本中4KB的空間有大約10個(gè)字節(jié)是用于內(nèi)部變量的。
6. 如果你有一個(gè)開(kāi)關(guān)語(yǔ)句塊大于3個(gè)case 語(yǔ)句，將它們像下面這樣拆分開(kāi)：

   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:				

   或者將它們修改成一個(gè) if-else if 結(jié)構(gòu)語(yǔ)句（參見(jiàn)附錄E）。

　　如果你沒(méi)有按照這些規(guī)則來(lái)做，目標(biāo)進(jìn)程很可能會(huì)崩潰。所以務(wù)必牢記。在目標(biāo)進(jìn)程中不要假設(shè)任何事情都會(huì)像在本地進(jìn)程中那樣 （參見(jiàn)附錄F）。

GetWindowTextRemote(A/W)

要想從“遠(yuǎn)程”編輯框獲得密碼，你需要做的就是將所有功能都封裝在GetWindowTextRemot(A/W):中。

int GetWindowTextRemoteA( HANDLE hProcess, HWND hWnd, LPSTR lpString );
int GetWindowTextRemoteW( HANDLE hProcess, HWND hWnd, LPWSTR lpString );
參數(shù)說(shuō)明：
hProcess：編輯框控件所屬的進(jìn)程句柄；
hWnd：包含密碼的編輯框控件句柄；
lpString：接收文本的緩沖指針；
返回值：返回值是拷貝的字符數(shù)；

　　下面讓我們看看它的部分代碼——尤其是注入數(shù)據(jù)的代碼——以便明白 GetWindowTextRemote 的工作原理。此處為簡(jiǎn)單起見(jiàn)，略掉了 UNICODE 支持部分。

INJDATA
typedef LRESULT (WINAPI *SENDMESSAGE)(HWND,UINT,WPARAM,LPARAM);
typedef struct {
HWND hwnd; // 編輯框句柄
SENDMESSAGE fnSendMessage; // 指向user32.dll 中 SendMessageA 的指針
char psText[128]; // 接收密碼的緩沖
} INJDATA;

　　INJDATA 是一個(gè)被注入到遠(yuǎn)程進(jìn)程的數(shù)據(jù)結(jié)構(gòu)。但在注入之前，結(jié)構(gòu)中指向 SendMessageA 的指針是在本地應(yīng)用程序中初始化的。因?yàn)閷?duì)于每個(gè)使用user32.dll的進(jìn)程來(lái)說(shuō)，user32.dll總是被映射到相同的地址，因此，SendMessageA 的地址也肯定是相同的。這就保證了被傳遞到遠(yuǎn)程進(jìn)程的是一個(gè)有效的指針。

ThreadFunc函數(shù)

static DWORD WINAPI ThreadFunc (INJDATA *pData)
{
pData->fnSendMessage( pData->hwnd, WM_GETTEXT, // Get password
sizeof(pData->psText),
(LPARAM)pData->psText );
return 0;
}
// 該函數(shù)在ThreadFunc之后標(biāo)記內(nèi)存地址
// int cbCodeSize = (PBYTE) AfterThreadFunc - (PBYTE) ThreadFunc.
static void AfterThreadFunc (void)
{
}

ThradFunc 是被遠(yuǎn)程線(xiàn)程執(zhí)行的代碼。

• 注釋?zhuān)鹤⒁釧fterThreadFunc 是如何計(jì)算 ThreadFunc 大小的。通常這樣做并不是一個(gè)好辦法，因?yàn)殒溄悠骺梢噪S意更改函數(shù)的順序（也就是說(shuō)ThreadFunc可能被放在 AfterThreadFunc之后）。這一點(diǎn)你可以在小項(xiàng)目中很好地保證函數(shù)的順序是預(yù)先設(shè)想好的，比如 WinSpy 程序。在必要的情況下，你還可以使用 /ORDER 鏈接器選項(xiàng)來(lái)解決函數(shù)鏈接順序問(wèn)題。或者用反匯編確定 ThreadFunc 函數(shù)的大小。

范例程序——InjectEx

下面我們將討論一些更復(fù)雜的內(nèi)容，如何子類(lèi)化屬于另一個(gè)進(jìn)程的控件。

首先，你得拷貝兩個(gè)函數(shù)到遠(yuǎn)程進(jìn)程來(lái)完成此任務(wù)

1. ThreadFunc實(shí)際上是通過(guò) SetWindowLong子類(lèi)化遠(yuǎn)程進(jìn)程中的控件；
2. NewProc是子類(lèi)化控件的新窗口過(guò)程；

　　這里主要的問(wèn)題是如何將數(shù)據(jù)傳到遠(yuǎn)程窗口過(guò)程 NewProc，因?yàn)?NewProc 是一個(gè)回調(diào)函數(shù)，它必須遵循特定的規(guī)范和原則，我們不能簡(jiǎn)單地在參數(shù)中傳遞 INJDATA指針。幸運(yùn)的是我找到了有兩個(gè)方法來(lái)解決這個(gè)問(wèn)題，只不過(guò)要借助匯編語(yǔ)言，所以不要忽略了匯編，關(guān)鍵時(shí)候它是很有用的！

方法一：

如下圖所示：

　　在遠(yuǎn)程進(jìn)程中，INJDATA 被放在NewProc 之前，這樣 NewProc 在編譯時(shí)便知道 INJDATA 在遠(yuǎn)程進(jìn)程地址空間中的內(nèi)存位置。更確切地說(shuō)，它知道相對(duì)于其自身位置的 INJDATA 的地址，我們需要所有這些信息。下面是 NewProc 的代碼：

static LRESULT CALLBACK NewProc(
HWND hwnd,       // 窗口句柄
UINT uMsg,       // 消息標(biāo)示符
WPARAM wParam,   // 第一個(gè)消息參數(shù)
LPARAM lParam )  // 第二個(gè)消息參數(shù)
{
INJDATA* pData = (INJDATA*) NewProc;  // pData 指向 NewProc
pData--;              // 現(xiàn)在pData 指向INJDATA;
// 回想一下INJDATA 被置于遠(yuǎn)程進(jìn)程N(yùn)ewProc之前;
//-----------------------------
// 此處是子類(lèi)化代碼
// ........
//-----------------------------
// 調(diào)用原窗口過(guò)程;
// fnOldProc (由SetWindowLong 返回) 被（遠(yuǎn)程）ThreadFunc初始化
// 并被保存在（遠(yuǎn)程）INJDATA;中
return pData->fnCallWindowProc( pData->fnOldProc,
hwnd,uMsg,wParam,lParam );
}

INJDATA* pData = (INJDATA*) NewProc;

　　這種方式 pData得到的是硬編碼值（在我們的進(jìn)程中是原 NewProc 的內(nèi)存地址）。這不是我們十分想要的。在遠(yuǎn)程進(jìn)程中，NewProc “當(dāng)前”拷貝的內(nèi)存地址與它被移到的實(shí)際位置是無(wú)關(guān)的，換句話(huà)說(shuō)，我們會(huì)需要某種類(lèi)型的“this 指針”。
雖然用 C/C++ 無(wú)法解決這個(gè)問(wèn)題，但借助內(nèi)聯(lián)匯編可以解決，下面是對(duì) NewProc的修改：

static LRESULT CALLBACK NewProc(
HWND hwnd,       // 窗口句柄
UINT uMsg,       // 消息標(biāo)示符
WPARAM wParam,   // 第一個(gè)消息參數(shù)
LPARAM lParam )  // 第二個(gè)消息參數(shù)
{
// 計(jì)算INJDATA 結(jié)構(gòu)的位置
// 在遠(yuǎn)程進(jìn)程中記住這個(gè)INJDATA
// 被放在NewProc之前
INJDATA* pData;
_asm {
call    dummy
dummy:
pop     ecx         // <- ECX 包含當(dāng)前的EIP
sub     ecx, 9      // <- ECX 包含NewProc的地址
mov     pData, ecx
}
pData--;
//-----------------------------
// 此處是子類(lèi)化代碼
// ........
//-----------------------------
// 調(diào)用原來(lái)的窗口過(guò)程
return pData->fnCallWindowProc( pData->fnOldProc,
hwnd,uMsg,wParam,lParam );
}

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

• 啞函數(shù)調(diào)用；就是JUMP到下一個(gè)指令并PUSH EIP到堆棧；
• 然后將堆棧頂POP到 ECX，ECX再保存EIP；這也是 POP EIP指令的真正地址；
• 注意 NewProc 的入口點(diǎn)和 “POP ECX”之間的“距離”是9 個(gè)字節(jié)；因此為了計(jì)算 NewProc的地址，要從 ECX 減9。

　　這樣一來(lái)，不管 NewProc 被移到什么地方，它總能計(jì)算出其自己的地址。但是，NewProc 的入口點(diǎn)和 “POP ECX”之間的距離可能會(huì)隨著你對(duì)編譯/鏈接選項(xiàng)的改變而變化，由此造成 RELEASE和DEBUG版本之間也會(huì)有差別。但關(guān)鍵是你仍然確切地知道編譯時(shí)的值。

1. 首先，編譯函數(shù)
2. 用反匯編確定正確的距離
3. 最后，用正確的距離值重新編譯

此即為 InjecEx 中使用的解決方案，類(lèi)似于 HookInjEx，交換鼠標(biāo)點(diǎn)擊“開(kāi)始”左右鍵時(shí)的功能。

方法二：

對(duì)于我們的問(wèn)題，在遠(yuǎn)程進(jìn)程地址空間中將 INJDATA 放在 NewProc 前面不是唯一的解決辦法。看下面 NewProc的變異版本：

static LRESULT CALLBACK NewProc(
HWND hwnd,      // 窗口句柄
UINT uMsg,      // 消息標(biāo)示符
WPARAM wParam,  // 第一個(gè)消息參數(shù)
LPARAM lParam ) // 第二個(gè)消息參數(shù)
{
INJDATA* pData = 0xA0B0C0D0;    // 虛構(gòu)值
//-----------------------------
// 子類(lèi)化代碼
// ........
//-----------------------------
// 調(diào)用原來(lái)的窗口過(guò)程
return pData->fnCallWindowProc( pData->fnOldProc,
hwnd,uMsg,wParam,lParam );
}

 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.

1. 將INJDATA，ThreadFunc和NewProc 拷貝到目標(biāo)進(jìn)程；
2. 修改 NewProc 的代碼，以便 pData 中保存的是 INJDATA 的真實(shí)地址。
   例如，假設(shè) INJDATA 的地址（VirtualAllocEx返回的值）在目標(biāo)進(jìn)程中是 0x008a0000。然后象下面這樣修改NewProc的代碼：

   	558BECC745FCD0C0B0A0......8BE55DC21000 <- 原來(lái)的NewProc （注1）
       558BECC745FC00008A00......8BE55DC21000 <- 修改后的NewProc，使用的是INJDATA的實(shí)際地址。

   也就是說(shuō)，你用真正的 INJDATA（注2） 地址替代了虛擬值 A0B0C0D0（注2）。
   
3. 開(kāi)始執(zhí)行遠(yuǎn)程的 ThreadFunc，它負(fù)責(zé)子類(lèi)化遠(yuǎn)程進(jìn)程中的控件。
   

• 注1、有人可能會(huì)問(wèn)，為什么地址 A0B0C0D0 和 008a0000 在編譯時(shí)順序是相反的。因?yàn)?Intel 和 AMD 處理器使用 little-endian 符號(hào)來(lái)表示（多字節(jié)）數(shù)據(jù)。換句話(huà)說(shuō)，某個(gè)數(shù)字的低位字節(jié)被存儲(chǔ)在內(nèi)存的最小地址處，而高位字節(jié)被存儲(chǔ)在最高位地址。
  假設(shè)“UNIX”這個(gè)詞存儲(chǔ)用4個(gè)字節(jié)，在 big-endian 系統(tǒng)中，它被存為“UNIX”，在 little-endian 系統(tǒng)中，它將被存為“XINU”。
• 注2、某些破解（很糟）以類(lèi)似的方式修改可執(zhí)行代碼，但是一旦加載到內(nèi)存，一個(gè)程序是無(wú)法修改自己的代碼的（代碼駐留在可執(zhí)行程序的“.text” 區(qū)域，這個(gè)區(qū)域是寫(xiě)保護(hù)的）。但仍可以修改遠(yuǎn)程的 NewProc，因?yàn)樗窍惹耙?PAGE_EXECUTE_READWRITE 許可方式被拷貝到某個(gè)內(nèi)存塊中的。

何時(shí)使用 CreateRemoteThread 和 WriteProcessMemory 技術(shù)

　　與其它方法比較，使用 CreateRemoteThread 和 WriteProcessMemory 技術(shù)進(jìn)行代碼注入更靈活，這種方法不需要額外的 dll，不幸的是，該方法更復(fù)雜并且風(fēng)險(xiǎn)更大，只要ThreadFunc出現(xiàn)哪怕一丁點(diǎn)錯(cuò)誤，很容易就讓?zhuān)ú⑶易畲罂赡艿貢?huì)）使遠(yuǎn)程進(jìn)程崩潰（參見(jiàn)附錄 F），因?yàn)檎{(diào)試遠(yuǎn)程 ThreadFunc 將是一個(gè)可怕的夢(mèng)魘，只有在注入的指令數(shù)很少時(shí)，你才應(yīng)該考慮使用這種技術(shù)進(jìn)行注入，對(duì)于大塊的代碼注入，最好用 I.和II 部分討論的方法。

WinSpy 以及 InjectEx 請(qǐng)從這里下載源代碼。

到目前為止，有幾個(gè)問(wèn)題是我們未提及的，現(xiàn)總結(jié)如下：

• 注3：顯然，你無(wú)法hook一個(gè)沒(méi)有消息隊(duì)列的線(xiàn)程，此外，SetWindowsHookEx不能與系統(tǒng)服務(wù)一起工作，即使它們與 USER32.DLL 進(jìn)行鏈接；
• 注4：Win9x 中沒(méi)有 CreateRemoteThread，也沒(méi)有 VirtualAllocEx （實(shí)際上，在Win9x 中可以仿真，但不是本文討論的問(wèn)題了）；
• 注5：所有進(jìn)程 = 所有 Win32 進(jìn)程 + csrss.exe
  本地應(yīng)用 （smss.exe, os2ss.exe, autochk.exe 等）不使用 Win32 API，所以也不會(huì)與 kernel32.dll 鏈接。唯一一個(gè)例外是 csrss.exe，Win32 子系統(tǒng)本身，它是本地應(yīng)用程序，但其某些庫(kù)（~winsrv.dll）需要 Win32 DLLs，包括 kernel32.dll；
• 注6：如果你想要將代碼注入到系統(tǒng)服務(wù)中（lsass.exe, services.exe, winlogon.exe 等）或csrss.exe，在打開(kāi)遠(yuǎn)程句柄（OpenProcess）之前，將你的進(jìn)程優(yōu)先級(jí)置為 “SeDebugPrivilege”（AdjustTokenPrivileges）。

　　最后，有幾件事情一定要了然于心：你的注入代碼很容易摧毀目標(biāo)進(jìn)程，尤其是注入代碼本身出錯(cuò)的時(shí)候，所以要記住：權(quán)力帶來(lái)責(zé)任！
　　因?yàn)楸疚闹械脑S多例子是關(guān)于密碼的，你也許還讀過(guò) Zhefu Zhang 寫(xiě)的另外一篇文章“Super Password Spy++” ，在該文中，他解釋了如何獲取IE 密碼框中的內(nèi)容，此外，他還示范了如何保護(hù)你的密碼控件免受類(lèi)似的攻擊。

附錄A：

為什么 kernel32.dll 和user32.dll 總是被映射到相同的地址。

　　我的假定：因?yàn)镸icrosoft 的程序員認(rèn)為這樣做有助于速度優(yōu)化，為什么呢？我的解釋是——通常一個(gè)可執(zhí)行程序是由幾個(gè)部分組成，其中包括“.reloc” 。當(dāng)鏈接器創(chuàng)建 EXE 或者 DLL文件時(shí)，它對(duì)文件被映射到哪個(gè)內(nèi)存地址做了一個(gè)假設(shè)。這就是所謂的首選加載/基地址。在映像文件中所有絕對(duì)地址都是基于鏈接器首選的加載地址，如果由于某種原因，映像文件沒(méi)有被加載到該地址，那么這時(shí)“.reloc”就起作用了，它包含映像文件中的所有地址的清單，這個(gè)清單中的地址反映了鏈接器首選加載地址和實(shí)際加載地址的差別（無(wú)論如何，要注意編譯器產(chǎn)生的大多數(shù)指令使用某種相對(duì)地址尋址，因此，并沒(méi)有你想象的那么多地址可供重新分配），另一方面，如果加載器能夠按照鏈接器首選地址加載映像文件，那么“.reloc”就被完全忽略掉了。
　　但kernel32.dll 和user32.dll 及其加載地址為何要以這種方式加載呢？因?yàn)槊恳粋€(gè) Win32 程序都需要kernel32.dll，并且大多數(shù)Win32 程序也需要 user32.dll，那么總是將它們（kernel32.dll 和user32.dll）映射到首選地址可以改進(jìn)所有可執(zhí)行程序的加載時(shí)間。這樣一來(lái)，加載器絕不能修改kernel32.dll and user32.dll.中的任何（絕對(duì)）地址。我們用下面的例子來(lái)說(shuō)明：
　　將某個(gè)應(yīng)用程序 App.exe 的映像基地址設(shè)置成 KERNEL32的地址（/base:"0x77e80000"）或 USER32的首選基地址（/base:"0x77e10000"），如果 App.exe 不是從 USER32 導(dǎo)入方式來(lái)使用 USER32，而是通過(guò)LoadLibrary 加載，那么編譯并運(yùn)行App.exe 后，會(huì)報(bào)出錯(cuò)誤信息（"Illegal System DLL Relocation"——非法系統(tǒng)DLL地址重分配），App.exe 加載失敗。
為什么會(huì)這樣呢？當(dāng)創(chuàng)建進(jìn)程時(shí)，Win 2000、Win XP 和Win 2003系統(tǒng)的加載器要檢查 kernel32.dll 和user32.dll 是否被映射到首選基地址（實(shí)際上，它們的名字都被硬編碼進(jìn)了加載器），如果沒(méi)有被加載到首選基地址，將發(fā)出錯(cuò)誤。在 WinNT4中，也會(huì)檢查ole32.dll，在WinNT 3.51 和較低版本的Windows中，由于不會(huì)做這樣的檢查，所以kernel32.dll 和user32.dll可以被加載任何地方。只有ntdll.dll總是被加載到其基地址，加載器不進(jìn)行檢查，一旦ntdll.dll沒(méi)有在其基地址，進(jìn)程就無(wú)法創(chuàng)建。

總之，對(duì)于 WinNT 4 和較高的版本中

• 一定要被加載到基地址的DLLs 有：kernel32.dll、user32.dll 和ntdll.dll；
• 每個(gè)Win32 程序都要使用的 DLLs+ csrss.exe：kernel32.dll 和ntdll.dll；
• 每個(gè)進(jìn)程都要使用的DLL只有一個(gè)，即使是本地應(yīng)用：ntdll.dll；

附錄B：

/GZ 編譯器開(kāi)關(guān)

　　在生成 Debug 版本時(shí)，/GZ 編譯器特性是默認(rèn)打開(kāi)的。你可以用它來(lái)捕獲某些錯(cuò)誤（具體細(xì)節(jié)請(qǐng)參考相關(guān)文檔）。但對(duì)我們的可執(zhí)行程序意味著什么呢？
　　當(dāng)打開(kāi) /GZ 開(kāi)關(guān)，編譯器會(huì)添加一些額外的代碼到可執(zhí)行程序中每個(gè)函數(shù)所在的地方，包括一個(gè)函數(shù)調(diào)用（被加到每個(gè)函數(shù)的最后）——檢查已經(jīng)被我們的函數(shù)修改的 ESP堆棧指針。什么！難道有一個(gè)函數(shù)調(diào)用被添加到 ThreadFunc 嗎？那將導(dǎo)致災(zāi)難。ThreadFunc 的遠(yuǎn)程拷貝將調(diào)用一個(gè)在遠(yuǎn)程進(jìn)程中不存在的函數(shù)（至少是在相同的地址空間中不存在）

靜態(tài)函數(shù)和增量鏈接

　　增量鏈接主要作用是在生成應(yīng)用程序時(shí)縮短鏈接時(shí)間。常規(guī)鏈接和增量鏈接的可執(zhí)行程序之間的差別是——增量鏈接時(shí)，每個(gè)函數(shù)調(diào)用經(jīng)由一個(gè)額外的JMP指令，該指令由鏈接器發(fā)出（該規(guī)則的一個(gè)例外是函數(shù)聲明為靜態(tài)）。這些 JMP 指令允許鏈接器在內(nèi)存中移動(dòng)函數(shù)，這種移動(dòng)無(wú)需修改引用函數(shù)的 CALL指令。但這些JMP指令也確實(shí)導(dǎo)致了一些問(wèn)題：如 ThreadFunc 和 AfterThreadFunc 將指向JMP指令而不是實(shí)際的代碼。所以當(dāng)計(jì)算ThreadFunc 的大小時(shí)：

const int cbCodeSize = ((LPBYTE) AfterThreadFunc - (LPBYTE) ThreadFunc)

:00401020   jmp  004014C0
...
:004014C0   push EBP          ; ThreadFunc 的實(shí)際地址
:004014C1   mov  EBP, ESP
...

WriteProcessMemory( .., &ThreadFunc, cbCodeSize, ..);

附錄D：

為什么 ThreadFunc的局部變量只有 4k？

　　局部變量總是存儲(chǔ)在堆棧中，如果某個(gè)函數(shù)有256個(gè)字節(jié)的局部變量，當(dāng)進(jìn)入該函數(shù)時(shí)，堆棧指針就減少256個(gè)字節(jié)（更精確地說(shuō)，在函數(shù)開(kāi)始處）。例如，下面這個(gè)函數(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

sub    esp, 0x1000    ; "分配" 第一次 4 Kb
test  [esp], eax      ; 承諾一個(gè)新頁(yè)內(nèi)存（如果還沒(méi)有承諾）
sub    esp, 0x1000    ; "分配" 第二次4 Kb
test  [esp], eax      ; ...
sub    esp, 0x1000
test  [esp], eax

注意事項(xiàng)
　　“每一個(gè)線(xiàn)程到達(dá)其自己的堆棧空間，默認(rèn)情況下，此空間由承諾的以及預(yù)留的內(nèi)存組成，每個(gè)線(xiàn)程使用 1 MB預(yù)留的內(nèi)存，以及一頁(yè)承諾的內(nèi)存，系統(tǒng)將根據(jù)需要從預(yù)留的堆棧內(nèi)存中承諾一頁(yè)內(nèi)存區(qū)域” （參見(jiàn) MSDN CreateThread > dwStackSize > Thread Stack Size）
　　還應(yīng)該清楚為什么有關(guān)　/GS 的文檔說(shuō)在堆棧探針在 Win32 應(yīng)用程序和Windows NT虛擬內(nèi)存管理器之間進(jìn)行謹(jǐn)慎調(diào)整。

現(xiàn)在回到我們的ThreadFunc以及 4KB 限制
　　雖然你可以用 /Gs 防止調(diào)用堆棧探測(cè)例程，但在文檔對(duì)于這樣的做法給出了警告，此外，文件描述可以用 #pragma check_stack 指令關(guān)閉或打開(kāi)堆棧探測(cè)。但是這個(gè)指令好像一點(diǎn)作用都沒(méi)有（要么這個(gè)文檔是垃圾，要么我疏忽了其它一些信息？）。總之，CreateRemoteThread 和 WriteProcessMemory 技術(shù)只能用于注入小塊代碼，所以你的局部變量應(yīng)該盡量少耗費(fèi)一些內(nèi)存字節(jié)，最好不要超過(guò) 4KB限制。

為什么要將開(kāi)關(guān)語(yǔ)句拆分成三個(gè)以上?

用下面這個(gè)例子很容易解釋這個(gè)問(wèn)題，假設(shè)有如下這么一個(gè)函數(shù)：

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;
}

地址      操作碼/參數(shù)       解釋后的指令
--------------------------------------------------
; 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 到表***中的地址之一
; 注意 ECX 包含的偏移
: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

1. O表示最壞的時(shí)間復(fù)雜度；
2. 我們假設(shè)需要5條指令來(lái)進(jìn)行表查詢(xún)計(jì)算偏移量，最終跳到相應(yīng)的地址；

　　現(xiàn)在，你也許認(rèn)為出現(xiàn)上述情況只是因?yàn)镃ASE常量被有意選擇為連續(xù)的（1，2，3，4）。幸運(yùn)的是，它的這個(gè)方案可以應(yīng)用于大多數(shù)現(xiàn)實(shí)例子中，只有偏移量的計(jì)算稍微有些復(fù)雜。但有兩個(gè)例外：

• 如果CASE語(yǔ)句少于等于三個(gè)；
• 如果CASE 常量完全互不相關(guān)（如：“"case 1” ，“case 13” ，“case 50” ， 和“case 1000” ）；

　　顯然，單獨(dú)判斷每個(gè)的CASE常量的話(huà)，結(jié)果代碼繁瑣耗時(shí)，但使用CMP和JMP指令則使得結(jié)果代碼的執(zhí)行就像普通的if-else 語(yǔ)句。
有趣的地方：如果你不明白CASE語(yǔ)句使用常量表達(dá)式的理由，那么現(xiàn)在應(yīng)該弄明白了吧。為了創(chuàng)建地址表，顯然在編譯時(shí)就應(yīng)該知道相關(guān)地址。

現(xiàn)在回到問(wèn)題！
注意到地址 0040100C 處的JMP指令了嗎？我們來(lái)看看Intel關(guān)于十六進(jìn)制操作碼 FF 的文檔是怎么說(shuō)的：

操作碼　指令 　　　　描述
FF /4 　JMP r/m32 　Jump near, absolute indirect,
　　　　　　　　　　　address given in r/m32

　　原來(lái)JMP 使用了一種絕對(duì)尋址方式，也就是說(shuō)，它的操作數(shù)（CASE語(yǔ)句中的 0040102C）表示一個(gè)絕對(duì)地址。還用我說(shuō)什么嗎？遠(yuǎn)程 ThreadFunc 會(huì)盲目地認(rèn)為地址表中開(kāi)關(guān)地址是 0040102C，JMP到一個(gè)錯(cuò)誤的地方，造成遠(yuǎn)程進(jìn)程崩潰。

為什么遠(yuǎn)程進(jìn)程會(huì)崩潰呢？

當(dāng)遠(yuǎn)程進(jìn)程崩潰時(shí)，它總是會(huì)因?yàn)橄旅孢@些原因：

1. 在ThreadFunc 中引用了一個(gè)不存在的串；
2. 在在ThreadFunc 中 中一個(gè)或多個(gè)指令使用絕對(duì)尋址（參見(jiàn)附錄E）；
3. ThreadFunc 調(diào)用某個(gè)不存在的函數(shù)（該調(diào)用可能是編譯器或鏈接器添加的）。你在反匯編器中可以看到這樣的情形：

   :004014C0    push EBP         ; ThreadFunc 的入口點(diǎn)
       :004014C1    mov EBP, ESP
       ...
       :004014C5    call 0041550     ;  這里將使遠(yuǎn)程進(jìn)程崩潰
       ...
       :00401502    ret
       

   如果 CALL 是由編譯器添加的指令（因?yàn)槟承?#8220;禁忌” 開(kāi)關(guān)如/GZ是打開(kāi)的），它將被定位在 ThreadFunc 的開(kāi)始的某個(gè)地方或者結(jié)尾處。

　　不管哪種情況，你都要小心翼翼地使用 CreateRemoteThread 和 WriteProcessMemory 技術(shù)。尤其要注意你的編譯器/鏈接器選項(xiàng)，一不小心它們就會(huì)在 ThreadFunc 添加內(nèi)容。

posted @ 2010-09-16 14:06 深邃者 閱讀(611) | 評(píng)論 (0) | 編輯 收藏

CreateRemoteThread

CreateRemoteThread提供了一個(gè)在遠(yuǎn)程進(jìn)程中執(zhí)行代碼的方法,就像代碼長(zhǎng)出翅膀飛到別處運(yùn)行。本文將做一個(gè)入門(mén)介紹，希望對(duì)廣大編程愛(ài)好者有所幫助。

先解釋一下遠(yuǎn)程進(jìn)程，其實(shí)就是要植入你的代碼的進(jìn)程，相對(duì)于你的工作進(jìn)程（如果叫本地進(jìn)程的話(huà)）它就叫遠(yuǎn)程進(jìn)程，可理解為宿主。

首先介紹一下我們的主要工具CreateRemoteThread，這里先將函數(shù)原型簡(jiǎn)單介紹以下。

CreateRemoteThread可將線(xiàn)程創(chuàng)建在遠(yuǎn)程進(jìn)程中。

函數(shù)原型
HANDLE CreateRemoteThread(
HANDLE hProcess,                          // handle to process
LPSECURITY_ATTRIBUTES lpThreadAttributes, // SD
SIZE_T dwStackSize,                       // initial stack size
LPTHREAD_START_ROUTINE lpStartAddress,    // thread function
LPVOID lpParameter,                       // thread argument
DWORD dwCreationFlags,                    // creation option
LPDWORD lpThreadId                        // thread identifier
);
參數(shù)說(shuō)明：
hProcess
[輸入] 進(jìn)程句柄
lpThreadAttributes
[輸入] 線(xiàn)程安全描述字，指向SECURITY_ATTRIBUTES結(jié)構(gòu)的指針
dwStackSize
[輸入] 線(xiàn)程棧大小，以字節(jié)表示
lpStartAddress
[輸入] 一個(gè)LPTHREAD_START_ROUTINE類(lèi)型的指針，指向在遠(yuǎn)程進(jìn)程中執(zhí)行的函數(shù)地址
lpParameter
[輸入] 傳入?yún)?shù)
dwCreationFlags
[輸入] 創(chuàng)建線(xiàn)程的其它標(biāo)志

lpThreadId
[輸出] 線(xiàn)程身份標(biāo)志，如果為NULL,則不返回

返回值
成功返回新線(xiàn)程句柄，失敗返回NULL，并且可調(diào)用GetLastError獲得錯(cuò)誤值。

接下來(lái)我們將以?xún)煞N方式使用CreateRemoteThread，大家可以領(lǐng)略到CreateRemoteThread的神通，它使你的代碼可以脫離你的進(jìn)程，植入到別的進(jìn)程中運(yùn)行。

第一種方式

第一種方式，我們使用函數(shù)的形式。即我們將自己程序中的一個(gè)函數(shù)植入到遠(yuǎn)程進(jìn)程中。

步驟1：首先在你的進(jìn)程中創(chuàng)建函數(shù)MyFunc，我們將把它放在另一個(gè)進(jìn)程中運(yùn)行，這里以windows

計(jì)算器為目標(biāo)進(jìn)程。
static DWORD WINAPI MyFunc (LPVOID pData)
{
//do something
//...
//pData輸入項(xiàng)可以是任何類(lèi)型值
//這里我們會(huì)傳入一個(gè)DWORD的值做示例，并且簡(jiǎn)單返回
return *(DWORD*)pData;
}
static void AfterMyFunc (void) {
}
這里有個(gè)小技巧，定義了一個(gè)static void AfterMyFunc (void)；為了下面確定我們的代碼大小

步驟2：定位目標(biāo)進(jìn)程，這里是一個(gè)計(jì)算器
HWND hStart = ::FindWindow (TEXT("SciCalc"),NULL);

步驟3：獲得目標(biāo)進(jìn)程句柄，這里用到兩個(gè)不太常用的函數(shù)（當(dāng)然如果經(jīng)常做線(xiàn)程/進(jìn)程等方面的 項(xiàng)目的話(huà)，就很面熟了），但及有用
DWORD PID, TID;
TID = ::GetWindowThreadProcessId (hStart, &PID);

HANDLE hProcess;
hProcess = OpenProcess(PROCESS_ALL_ACCESS,false,PID);

步驟4：在目標(biāo)進(jìn)程中配變量地址空間，這里我們分配10個(gè)字節(jié)，并且設(shè)定為可以讀

寫(xiě)PAGE_READWRITE，當(dāng)然也可設(shè)為只讀等其它標(biāo)志，這里就不一一說(shuō)明了。
char szBuffer[10];
*(DWORD*)szBuffer=1000;//for test
void *pDataRemote =(char*) VirtualAllocEx( hProcess, 0, sizeof(szBuffer), MEM_COMMIT,

PAGE_READWRITE );

步驟5：寫(xiě)內(nèi)容到目標(biāo)進(jìn)程中分配的變量空間
::WriteProcessMemory( hProcess, pDataRemote, szBuffer,(sizeof(szBuffer),NULL);

步驟6：在目標(biāo)進(jìn)程中分配代碼地址空間
計(jì)算代碼大小
DWORD cbCodeSize=((LPBYTE) AfterMyFunc - (LPBYTE) MyFunc);
分配代碼地址空間
PDWORD pCodeRemote = (PDWORD) VirtualAllocEx( hProcess, 0, cbCodeSize, MEM_COMMIT,

PAGE_EXECUTE_READWRITE );

步驟7：寫(xiě)內(nèi)容到目標(biāo)進(jìn)程中分配的代碼地址空間
WriteProcessMemory( hProcess, pCodeRemote, &MyFunc, cbCodeSize, NULL);

步驟8：在目標(biāo)進(jìn)程中執(zhí)行代碼

HANDLE hThread = CreateRemoteThread(hProcess, NULL, 0,
(LPTHREAD_START_ROUTINE) pCodeRemote,
pDataRemote, 0 , NULL);
DWORD h;
if (hThread)
{
::WaitForSingleObject( hThread, INFINITE );
::GetExitCodeThread( hThread, &h );
TRACE("run and return %d\n",h);
::CloseHandle( hThread );
}

這里有幾個(gè)值得說(shuō)明的地方:
使用WaitForSingleObject等待線(xiàn)程結(jié)束;
使用GetExitCodeThread獲得返回值；
最后關(guān)閉句柄CloseHandle。

步驟9：清理現(xiàn)場(chǎng)

釋放空間
::VirtualFreeEx( hProcess, pCodeRemote,
                 cbCodeSize,MEM_RELEASE );

::VirtualFreeEx( hProcess, pDataRemote,
                 cbParamSize,MEM_RELEASE );

關(guān)閉進(jìn)程句柄
::CloseHandle( hProcess );

第二種方式

第二種方式，我們使用動(dòng)態(tài)庫(kù)的形式。即我們將自己一個(gè)動(dòng)態(tài)庫(kù)植入到遠(yuǎn)程進(jìn)程中。

這里不再重復(fù)上面相同的步驟,只寫(xiě)出其中關(guān)鍵的地方.
關(guān)鍵1:
在步驟5中將動(dòng)態(tài)庫(kù)的路徑作為變量傳入變量空間.
關(guān)鍵2:
在步驟8中,將GetProcAddress作為目標(biāo)執(zhí)行函數(shù).

hThread = ::CreateRemoteThread( hProcess, NULL, 0,
            (LPTHREAD_START_ROUTINE )::GetProcAddress(
             hModule, "LoadLibraryA"),
             pDataRemote, 0, NULL );

另外在步驟9,清理現(xiàn)場(chǎng)中首先要先進(jìn)行釋放我們的動(dòng)態(tài)庫(kù).也即類(lèi)似步驟8執(zhí)行函數(shù)FreeLibrary

hThread = ::CreateRemoteThread( hProcess, NULL, 0,
(LPTHREAD_START_ROUTINE )::GetProcAddress(
hModule, "FreeLibrary"),
(void*)hLibModule, 0, NULL );

好了,限于篇幅不能夠介紹的很細(xì),在使用過(guò)程中如有疑問(wèn)可向作者咨詢(xún).（開(kāi)發(fā)環(huán)境：windows2000/vc6.0）
 

本文來(lái)自CSDN博客，轉(zhuǎn)載請(qǐng)標(biāo)明出處：http://blog.csdn.net/fangchao918628/archive/2008/08/30/2852744.aspx

posted @ 2010-09-16 14:05 深邃者 閱讀(563) | 評(píng)論 (0) | 編輯 收藏

#Pragma 指令介紹

在所有的預(yù)處理指令中，#Pragma 指令可能是最復(fù)雜的了，它的作用是設(shè)定編譯器的狀態(tài)或者是指示編譯器完成一些特定的動(dòng)作。#pragma指令對(duì)每個(gè)編譯器給出了一個(gè)方法,在保持與C和C ++語(yǔ)言完全兼容的情況下,給出主機(jī)或操作系統(tǒng)專(zhuān)有的特征。依據(jù)定義,編譯指示是機(jī)器或操作系統(tǒng)專(zhuān)有的,且對(duì)于每個(gè)編譯器都是不同的。

其格式一般為: #Pragma Para
其中Para 為參數(shù)，下面來(lái)看一些常用的參數(shù)。

(1)message 參數(shù)。

Message 參數(shù)是我最喜歡的一個(gè)參數(shù)，它能夠在編譯信息輸出窗口中輸出相應(yīng)的信息，這對(duì)于源代碼信息的控制是非常重要的。其使用方法為：
#Pragma message(“消息文本”)
當(dāng)編譯器遇到這條指令時(shí)就在編譯輸出窗口中將消息文本打印出來(lái)。
當(dāng)我們?cè)诔绦蛑卸x了許多宏來(lái)控制源代碼版本的時(shí)候，我們自己有可能都會(huì)忘記有沒(méi)有正確的設(shè)置這些宏，此時(shí)我們可以用這條指令在編譯的時(shí)候就進(jìn)行檢查。
假設(shè)我們希望判斷自己有沒(méi)有在源代碼的什么地方定義了_X86這個(gè)宏可以用下面的方法
#ifdef _X86
#Pragma message(“_X86 macro activated!”)
#endif
當(dāng)我們定義了_X86這個(gè)宏以后，應(yīng)用程序在編譯時(shí)就會(huì)在編譯輸出窗口里顯示“_
X86 macro activated!”。我們就不會(huì)因?yàn)椴挥浀米约憾x的一些特定的宏而抓耳撓腮了。

(2)另一個(gè)使用得比較多的pragma參數(shù)是code_seg。

格式如：
#pragma code_seg( ["section-name"[,"section-class"] ] )
它能夠設(shè)置程序中函數(shù)代碼存放的代碼段，當(dāng)我們開(kāi)發(fā)驅(qū)動(dòng)程序的時(shí)候就會(huì)使用到它。

(3)#pragma once (比較常用）

只要在頭文件的最開(kāi)始加入這條指令就能夠保證頭文件被編譯一次，這條指令實(shí)際上在VC6中就已經(jīng)有了，但是考慮到兼容性并沒(méi)有太多的使用它。

(4)#pragma hdrstop

表示預(yù)編譯頭文件到此為止，后面的頭文件不進(jìn)行預(yù)編譯。BCB可以預(yù)編譯頭文件以加快鏈接的速度，但如果所有頭文件都進(jìn)行預(yù)編譯又可能占太多磁盤(pán)空間，所以使用這個(gè)選項(xiàng)排除一些頭文件。
有時(shí)單元之間有依賴(lài)關(guān)系，比如單元A依賴(lài)單元B，所以單元B要先于單元A編譯。你可以用#pragma startup指定編譯優(yōu)先級(jí)，如果使用了#pragma package(smart_init) ，BCB就會(huì)根據(jù)優(yōu)先級(jí)的大小先后編譯。

(5)#pragma resource

#pragma resource "*.dfm"表示把*.dfm文件中的資源加入工程。*.dfm中包括窗體外觀(guān)的定義。

(6)#pragma warning

（7）pragma comment(...)

（8）progma data_seg

應(yīng)用程序的入口文件前面加上

#pragma data_seg("flag_data")
int app_count = 0;
#pragma data_seg()
#pragma comment(linker,"/SECTION:flag_data,RWS")

然后程序啟動(dòng)的地方加上

if(app_count>0)     // 如果計(jì)數(shù)大于0，則退出應(yīng)用程序。
{
   //MessageBox(NULL, "已經(jīng)啟動(dòng)一個(gè)應(yīng)用程序", "Warning", MB_OK);

   //printf("no%d application", app_count);

   return FALSE;
}
app_count++;

Windows 在一個(gè)Win32程序的地址空間周?chē)艘坏缐ΑＭǔ＃粋€(gè)程序的地址空間中的數(shù)據(jù)是私有的，對(duì)別的程序而言是不可見(jiàn)的。但是執(zhí)行STRPROG的多個(gè)執(zhí)行實(shí)體表示了STRLIB在程序的所有執(zhí)行實(shí)體之間共享數(shù)據(jù)是毫無(wú)問(wèn)題的。當(dāng)您在一個(gè)STRPROG窗口中增加或者刪除一個(gè)字符串時(shí)，這種改變將立即反映在其它的窗口中。

在全部例程之間，STRLIB共享兩個(gè)變量：一個(gè)字符數(shù)組和一個(gè)整數(shù)（記錄已儲(chǔ)存的有效字符串的個(gè)數(shù)）。STRLIB將這兩個(gè)變量?jī)?chǔ)存在共享的一個(gè)特殊內(nèi)存區(qū)段中：

#pragma      data_seg ("shared")
         
int                 iTotal = 0 ;
         
WCHAR               szStrings [MAX_STRINGS][MAX_LENGTH + 1] = { '\0' } ;
         
#pragma      data_seg ()
        

第一個(gè)#pragma敘述建立數(shù)據(jù)段，這里命名為shared。您可以將這段命名為任何一個(gè)您喜歡的名字。在這里的#pragma敘述之后的所有初始化了的變量都放在shared數(shù)據(jù)段中。第二個(gè)#pragma敘述標(biāo)示段的結(jié)束。對(duì)變量進(jìn)行專(zhuān)門(mén)的初始化是很重要的，否則編譯器將把它們放在普通的未初始化數(shù)據(jù)段中而不是放在shared中。

連結(jié)器必須知道有一個(gè)「shared」共享數(shù)據(jù)段。在「Project Settings」對(duì)話(huà)框選擇「Link」頁(yè)面卷標(biāo)。選中「STRLIB」時(shí)在「Project Options」字段（在Release和Debug設(shè)定中均可），包含下面的連結(jié)敘述：

/SECTION:shared,RWS
        

字母RWS表示段具有讀、寫(xiě)和共享屬性。或者，您也可以直接用DLL原始碼指定連結(jié)選項(xiàng)，就像我們?cè)赟TRLIB.C那樣：

#pragma comment(linker,"/SECTION:shared,RWS")
        

共享的內(nèi)存段允許iTotal變量和szStrings字符串?dāng)?shù)組在STRLIB的所有例程之間共享。因?yàn)镸AX_STRINGS等于256，而 MAX_LENGTH等于63，所以，共享內(nèi)存段的長(zhǎng)度為32,772字節(jié)－iTotal變量需要4字節(jié)，256個(gè)指針中的每一個(gè)都需要128字節(jié)。

posted @ 2010-09-16 10:25 深邃者 閱讀(258) | 評(píng)論 (0) | 編輯 收藏

dll #pragma data_seg 實(shí)現(xiàn)數(shù)據(jù)的共享

#pragma data_seg("flag_data")
   int count=0;
#pragma data_seg()
#pragma comment(linker,"/SECTION:flag_data,RWS")
這種方法只能在沒(méi)有def文件時(shí)使用，如果通過(guò)def文件進(jìn)行導(dǎo)出的話(huà)，那么設(shè)置就要在def文件內(nèi)設(shè)置而不能
在代碼里設(shè)置了。
SETCTIONS
flag_data READ WRITE SHARED

在主文件中，用#pragma data_seg建立一

個(gè)新的數(shù)據(jù)段并定義共享數(shù)據(jù)，其具體格式為：

#pragma data_seg （"shareddata") //名稱(chēng)可以

//自己定義，但必須與下面的一致。

HWND sharedwnd=NULL;//共享數(shù)據(jù)

#pragma data_seg()



僅定義一個(gè)數(shù)據(jù)段還不能達(dá)到共享數(shù)據(jù)的目的，還要告訴編譯器該段的屬性，有兩種方法可以實(shí)現(xiàn)該目的 （其效果是相同的），一種方法是在.DEF文件中加入如下語(yǔ)句： SETCTIONS shareddata READ WRITE SHARED 另一種方法是在項(xiàng)目設(shè)置鏈接選項(xiàng)(Project Setting --〉Link)中加入如下語(yǔ)句： /SECTION:shareddata,rws

第一點(diǎn)：什么是共享數(shù)據(jù)段？為什么要用共享數(shù)據(jù)段？？它有什么用途？？
在Win16環(huán)境中，DLL的全局?jǐn)?shù)據(jù)對(duì)每個(gè)載入它的進(jìn)程來(lái)說(shuō)都是相同的；而在Win32環(huán)境中，情況卻發(fā)生了變化，DLL函數(shù)中的代碼所創(chuàng)建的任何對(duì)象（包括變量）都?xì)w調(diào)用它的線(xiàn)程或進(jìn)程所有。當(dāng)進(jìn)程在載入DLL時(shí)，操作系統(tǒng)自動(dòng)把DLL地址映射到該進(jìn)程的私有空間，也就是進(jìn)程的虛擬地址空間，而且也復(fù)制該DLL的全局?jǐn)?shù)據(jù)的一份拷貝到該進(jìn)程空間。也就是說(shuō)每個(gè)進(jìn)程所擁有的相同的DLL的全局?jǐn)?shù)據(jù)，它們的名稱(chēng)相同，但其值卻并不一定是相同的，而且是互不干涉的。

因此，在Win32環(huán)境下要想在多個(gè)進(jìn)程中共享數(shù)據(jù)，就必須進(jìn)行必要的設(shè)置。在訪(fǎng)問(wèn)同一個(gè)Dll的各進(jìn)程之間共享存儲(chǔ)器是通過(guò)存儲(chǔ)器映射文件技術(shù)實(shí)現(xiàn)的。也可以把這些需要共享的數(shù)據(jù)分離出來(lái)，放置在一個(gè)獨(dú)立的數(shù)據(jù)段里，并把該段的屬性設(shè)置為共享。必須給這些變量賦初值，否則編譯器會(huì)把沒(méi)有賦初始值的變量放在一個(gè)叫未被初始化的數(shù)據(jù)段中。



#pragma data_seg預(yù)處理指令用于設(shè)置共享數(shù)據(jù)段。例如：

#pragma data_seg("SharedDataName") HHOOK hHook=NULL; //必須在定義的同時(shí)進(jìn)行初始化!!!!#pragma data_seg()

在#pragma data_seg("SharedDataName")和#pragma data_seg()之間的所有變量將被訪(fǎng)問(wèn)該Dll的所有進(jìn)程看到和共享。再加上一條指令#pragma comment(linker,"/section:.SharedDataName,rws"),[注意：數(shù)據(jù)節(jié)的名稱(chēng)is case sensitive]那么這個(gè)數(shù)據(jù)節(jié)中的數(shù)據(jù)可以在所有DLL的實(shí)例之間共享。所有對(duì)這些數(shù)據(jù)的操作都針對(duì)同一個(gè)實(shí)例的，而不是在每個(gè)進(jìn)程的地址空間中都有一份。



當(dāng)進(jìn)程隱式或顯式調(diào)用一個(gè)動(dòng)態(tài)庫(kù)里的函數(shù)時(shí)，系統(tǒng)都要把這個(gè)動(dòng)態(tài)庫(kù)映射到這個(gè)進(jìn)程的虛擬地址空間里(以下簡(jiǎn)稱(chēng)"地址空間")。這使得DLL成為進(jìn)程的一部分，以這個(gè)進(jìn)程的身份執(zhí)行，使用這個(gè)進(jìn)程的堆棧。(這項(xiàng)技術(shù)又叫code Injection技術(shù)，被廣泛地應(yīng)用在了病毒、黑客領(lǐng)域！呵呵^_^)



第二點(diǎn)：在具體使用共享數(shù)據(jù)段時(shí)需要注意的一些問(wèn)題！

Win32 DLLs are mapped into the address space of the calling process. By default, each process using a DLL has its own instance of all the DLLs global and static variables. (注意: 即使是全局變量和靜態(tài)變量也都不是共享的!) If your DLL needs to share data with other instances of it loaded by other applications, you can use either of the following approaches:

· Create named data sections using the data_seg pragma.

· Use memory mapped files. See the Win32 documentation about memory mapped files.

Here is an example of using the data_seg pragma:

#pragma data_seg (".myseg")
int i = 0;
char a[32] = "hello world";
#pragma data_seg()

data_seg can be used to create a new named section (.myseg in this example). The most typical usage is to call the data segment .shared for clarity. You then must specify the correct sharing attributes for this new named data section in your .def file or with the linker option /SECTION:.MYSEC,RWS. (這個(gè)編譯參數(shù)既可以使用pragma指令來(lái)指定，也可以在VC的IDE中指定！)

There are restrictions to consider before using a shared data segment:

· Any variables in a shared data segment must be statically initialized. In the above example, i is initialized to 0 and a is 32 characters initialized to hello world.

· All shared variables are placed in the compiled DLL in the specified data segment. Very large arrays can result in very large DLLs. This is true of all initialized global variables.

· Never store process-specific information in a shared data segment. Most Win32 data structures or values (such as HANDLEs) are really valid only within the context of a single process.

· Each process gets its own address space. It is very important that pointers are never stored in a variable contained in a shared data segment. A pointer might be perfectly valid in one application but not in another.

· It is possible that the DLL itself could get loaded at a different address in the virtual address spaces of each process. It is not safe to have pointers to functions in the DLL or to other shared variables.

posted @ 2010-09-16 10:25 深邃者 閱讀(447) | 評(píng)論 (0) | 編輯 收藏

RTTI、虛函數(shù)和虛基類(lèi)的實(shí)現(xiàn)方式、開(kāi)銷(xiāo)分析及使用指導(dǎo)

RTTI、虛函數(shù)和虛基類(lèi)的實(shí)現(xiàn)方式、開(kāi)銷(xiāo)分析及使用指導(dǎo)

白楊

http://baiy.cn

“在正確的場(chǎng)合使用恰當(dāng)?shù)奶匦?#8221; 對(duì)稱(chēng)職的C++程序員來(lái)說(shuō)是一個(gè)基本標(biāo)準(zhǔn)。想要做到這點(diǎn)，首先要了解語(yǔ)言中每個(gè)特性的實(shí)現(xiàn)方式及其開(kāi)銷(xiāo)。本文主要討論相對(duì)于傳統(tǒng) C 而言，對(duì)效率有影響的幾個(gè)C++新特性。

相對(duì)于傳統(tǒng)的 C 語(yǔ)言，C++ 引入的額外開(kāi)銷(xiāo)體現(xiàn)在以下兩個(gè)方面：

編譯時(shí)開(kāi)銷(xiāo)

運(yùn)行時(shí)開(kāi)銷(xiāo)

圖中虛箭頭代表偏移，實(shí)箭頭代表指針

由上圖得到每種特性的運(yùn)行時(shí)開(kāi)銷(xiāo)如下： 　 特性 時(shí)間開(kāi)銷(xiāo) 空間開(kāi)銷(xiāo) RTTI 幾次整形比較和一次取址操作（可能還會(huì)有1、2次整形加法） 每類(lèi)型一個(gè)type_info對(duì)象（包括類(lèi)型ID和類(lèi)名稱(chēng)），典型情況下小于32字節(jié) 　 虛函數(shù) 一次整形加法和一次指針間接引用 每類(lèi)型一個(gè)虛表，典型情況下小于128字節(jié) 每對(duì)象若干個(gè)（大部分情況下是一個(gè)）虛表指針，典型情況下小于8字節(jié) 　 虛基類(lèi) 從虛繼承的子類(lèi)中訪(fǎng)問(wèn)虛基類(lèi)的數(shù)據(jù)成員或其虛函數(shù)時(shí)，將增加兩次指針間接引用和一次整形加法（部分情況下可以?xún)?yōu)化為一次指針間接引用）。 每類(lèi)型一個(gè)虛基類(lèi)表，典型情況下小于32字節(jié) 每對(duì)象若干虛基類(lèi)表指針，典型情況下小于8字節(jié) 在同時(shí)使用了虛函數(shù)的時(shí)候，虛基類(lèi)表可以合并到虛表（virtual table）中，每對(duì)象的虛基類(lèi)表指針（vbptr）也可以省略（只需vptr即可）。實(shí)際上， 很多實(shí)現(xiàn)都是這么做的。 　  * 其中“每類(lèi)型”或“每對(duì)象”是指用到該特性的類(lèi)型/對(duì)象。對(duì)于未用到這些功能的類(lèi)型及其對(duì)象，則不會(huì)增加上述開(kāi)銷(xiāo) 可見(jiàn)，關(guān)于老天“餓時(shí)掉餡餅、睡時(shí)掉老婆”等美好傳說(shuō)純屬謠言。但凡人工制品必不完美，總有設(shè)計(jì)上的取舍，有其適應(yīng)的場(chǎng)合也有其不適用的地方。 C++中的每個(gè)特性，都是從程序員平時(shí)的生產(chǎn)生活中逐漸精化而來(lái)的。在不正確的場(chǎng)合使用它們必然會(huì)引起邏輯、行為和性能上的問(wèn)題。對(duì)于上述特性，應(yīng)該只在必要、合理的前提下才使用。 "dynamic_cast" 用于在類(lèi)層次結(jié)構(gòu)中漫游，對(duì)指針或引用進(jìn)行自由的向上、向下或交叉強(qiáng)制。"typeid" 則用于獲取一個(gè)對(duì)象或引用的確切類(lèi)型，與 "dynamic_cast" 不同，將 "typeid" 作用于指針通常是一個(gè)錯(cuò)誤，要得到一個(gè)指針指向之對(duì)象的type_info，應(yīng)當(dāng)先將其解引用（例如："typeid(*p);"）。 一般地講，能用虛函數(shù)解決的問(wèn)題就不要用 "dynamic_cast"，能夠用 "dynamic_cast" 解決的就不要用 "typeid"。比如： void rotate(IN const CShape& iS) {     if (typeid(iS) == typeid(CCircle))     {         // ...     }     else if (typeid(iS) == typeid(CTriangle))     {         // ...     }     else if (typeid(iS) == typeid(CSqucre))     {         // ...     }     // ... } 以上代碼用 "dynamic_cast" 寫(xiě)會(huì)稍好一點(diǎn)，當(dāng)然最好的方式還是在CShape里定義名為 "rotate" 的虛函數(shù)。 虛函數(shù)是C++眾多運(yùn)行時(shí)多態(tài)特性中開(kāi)銷(xiāo)最小，也最常用的機(jī)制。虛函數(shù)的好處和作用這里不再多說(shuō)，應(yīng)當(dāng)注意在對(duì)性能有苛刻要求的場(chǎng)合，或者需要頻繁調(diào)用，對(duì)性能影響較大的地方（比如每秒鐘要調(diào)用成千上萬(wàn)次，而自身內(nèi)容又很簡(jiǎn)單的事件處理函數(shù)）要慎用虛函數(shù)。 需要特別說(shuō)明的一點(diǎn)是：虛函數(shù)的調(diào)用開(kāi)銷(xiāo)與通過(guò)函數(shù)指針的間接函數(shù)調(diào)用（例如：經(jīng)典C程序中常見(jiàn)的，通過(guò)指向結(jié)構(gòu)中的一個(gè)函數(shù)指針成員調(diào)用；以及調(diào)用DLL/SO中的函數(shù)等常見(jiàn)情況）是相當(dāng)?shù)摹１绕鸷瘮?shù)調(diào)用本身的開(kāi)銷(xiāo)（保存現(xiàn)場(chǎng)->傳遞參數(shù)->傳遞返回值->恢復(fù)現(xiàn)場(chǎng)）來(lái)說(shuō)，一次指針間接引用是微不足道的。這就使得在絕大部分可以使用函數(shù)的場(chǎng)合中都能夠負(fù)擔(dān)得起虛方法的些微額外開(kāi)銷(xiāo)。 作為一種支持多繼承的面向?qū)ο笳Z(yǔ)言，虛基類(lèi)有時(shí)是保證類(lèi)層次結(jié)構(gòu)正確一致的一種必不可少的手段。但在需要頻繁使用基類(lèi)提供的服務(wù)，又對(duì)性能要求較高的場(chǎng)合，應(yīng)該盡量避免使用它。在基類(lèi)中沒(méi)有數(shù)據(jù)成員的場(chǎng)合，也可以解除使用虛基類(lèi)。例如，在上圖中，如果類(lèi) "BB" 中不存在數(shù)據(jù)成員，那么 "BB" 就可以作為一個(gè)普通基類(lèi)分別被 "B1" 和 "B2" 繼承。這樣的優(yōu)化在達(dá)到相同效果的前提下，解除了虛基類(lèi)引起的開(kāi)銷(xiāo)。不過(guò)這種優(yōu)化也會(huì)帶來(lái)一些問(wèn)題：從 "DD" 向上強(qiáng)制到 "BB" 時(shí)會(huì)引起歧義，破壞了類(lèi)層次結(jié)構(gòu)的邏輯關(guān)系。 上述特性的空間開(kāi)銷(xiāo)一般都是可以接受的，當(dāng)然也存在一些特例，比如：在存儲(chǔ)布局需要和傳統(tǒng)C結(jié)構(gòu)兼容的場(chǎng)合、在考慮對(duì)齊的場(chǎng)合、在需要為一個(gè)本來(lái)尺寸很小的類(lèi)同時(shí)實(shí)例化許多對(duì)象的場(chǎng)合等等。

posted @ 2010-08-10 17:35 深邃者 閱讀(453) | 評(píng)論 (0) | 編輯 收藏

Debug 和 Release

posted @ 2009-11-21 22:39 深邃者 閱讀(315) | 評(píng)論 (0) | 編輯 收藏

DLL 線(xiàn)程本地存儲(chǔ)

DLL, 線(xiàn)程本地存儲(chǔ)

1.概覽

.構(gòu)造DLL  

   (1)僅導(dǎo)出函數(shù)

      DLL可以導(dǎo)出全局變量和類(lèi)，但我們不建議這么做，建議導(dǎo)出函數(shù)。

   (2).lib

      每個(gè)DLL都有與之相對(duì)應(yīng)的.lib文件,該文件中列出了DLL中導(dǎo)出的函數(shù)和變量的符號(hào)名

   (3)指定要導(dǎo)出的函數(shù)名

       因?yàn)椴煌幾g器的Name mangle規(guī)則不同，這就導(dǎo)致DLL不能跨編譯器使用。

       有以下兩種方法可以解決這個(gè)問(wèn)題：

            1.在.def文件中指定要導(dǎo)出的函數(shù)名

            2.在編譯指中指定要導(dǎo)出的函數(shù)名：

                #pragma comment(linker, "/export:MyFunc=_MyFunc@8")

.DLL加載路徑

    當(dāng)需要加載一個(gè)DLL時(shí)，系統(tǒng)會(huì)依照下面的順序去尋找所需DLL直到找到為止，然后加載，否則加載失敗。

              (1)當(dāng)前可執(zhí)行文件路徑

              (2)GetWindowsDirectory返回的Windows系統(tǒng)路徑

              (3)16位系統(tǒng)的路徑 windows"system

              (4)GetSystemDirectory返回的Windows系統(tǒng)路徑

              (5)當(dāng)前進(jìn)程所在路徑

              (6)PATH環(huán)境中所指定的路徑

­

.創(chuàng)建\使用動(dòng)態(tài)鏈接庫(kù)

首先必須創(chuàng)建一個(gè)包含需要導(dǎo)出的符號(hào)的頭文件，以便其他程序鏈接到該dll上：

// dllexample.h

#ifdef DLLEXAMPLE_EXPORTS // 在編譯命令中已定義，所以實(shí)際用的是 __declspec(dllexport)

#define DLLEXAMPLE_API __declspec(dllexport)

#else

#define DLLEXAMPLE_API __declspec(dllimport)

#endif

DLLEXAMPLE_API int fnDllexample(void);

當(dāng)其他應(yīng)用包含該頭文件，意圖使用該dll的導(dǎo)出符號(hào)時(shí)，因?yàn)闆](méi)有定義DLLEXAMPLE_EXPORTS，所以使用的是__declspec(dllimport)，這樣編譯器編譯時(shí)便知道這是從外部引入的函數(shù)。在鏈接時(shí)，鏈接程序?qū)⑸蓪?dǎo)入表(ImportAddressTable),該表羅列了所有調(diào)用到的函數(shù)，以及一個(gè)空白的對(duì)應(yīng)地址。在程序執(zhí)行時(shí)，加載器將動(dòng)態(tài)的填入每個(gè)函數(shù)符號(hào)在本進(jìn)程中的地址，使得程序能正確的調(diào)用到dll中的函數(shù)上。

這種通過(guò)dll提供的.h和.lib文件進(jìn)行鏈接dll的使用方式，稱(chēng)為隱式鏈接。用vc開(kāi)發(fā)程序時(shí)，幾乎所有的系統(tǒng)API調(diào)用都用了隱式鏈接。

.顯式鏈接

在exe創(chuàng)建時(shí)不引用.lib文件中的符號(hào)，當(dāng)然也不必包含.h頭文件，而是由程序調(diào)用LoadLibrary(Ex)以及GetProcAddress函數(shù)來(lái)獲取每個(gè)需要使用的函數(shù)地址，從而進(jìn)行dll中的函數(shù)調(diào)用，這種dll使用方法稱(chēng)為顯式鏈接。顯式鏈接時(shí)不生成對(duì)應(yīng)dll的IAT.

當(dāng)決定不再使用該dll時(shí)，通過(guò)調(diào)用FreeLibrary來(lái)卸載。需要注意的是，同一個(gè)進(jìn)程中共計(jì)調(diào)用LoadLibrary的次數(shù)要和調(diào)用FreeLibrary的次數(shù)相等，因?yàn)橄到y(tǒng)維護(hù)了一個(gè)使用計(jì)數(shù)，當(dāng)計(jì)數(shù)為0時(shí)，才會(huì)真正的卸載該dll.

如果想確認(rèn)一個(gè)dll是否已經(jīng)被映射到進(jìn)程空間中，盡量使用GetModuleHandle，最好不要冒然使用LoadLibrary(Ex).

GetProcAddress可以傳遞函數(shù)名或者序號(hào)(通過(guò)MAKEINTRESOURCE(2)來(lái)"制作"序號(hào)).

­

1.1動(dòng)態(tài)加載DLL文件 LoadLibraryEx

HMODULE LoadLibraryEx( //返回DLL加載到進(jìn)程空間原首地址。

PCTSTR pszDLLPathName,

HANDLE hFile,

DWORD dwFlags);

dwFlags 可以有以下幾個(gè)值

              (1) DONT_RESOLVE_DLL_REFERENCES

                                    建議永遠(yuǎn)不要使有這個(gè)值，它的存在僅僅是為了向后兼容、

                  更多內(nèi)容請(qǐng)?jiān)L問(wèn)：http://blogs.msdn.com/oldnewthing/archive/2005/02/14/372266.aspx

              (2) LOAD_LIBRARY_AS_DATAFILE

                  把要加載的DLL文件以數(shù)據(jù)文件的形式加載到進(jìn)程中。

                  GetModuleHandle和GetProcAddress返回NULL

              (3) LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE

                  與前者相同，不同的時(shí)獨(dú)占打開(kāi)，禁止其它進(jìn)程訪(fǎng)問(wèn)和修改該DLL中的內(nèi)容。

              (4) LOAD_LIBRARY_AS_IMAGE_RESOURCE

                  不修改DLL中的RVA，以image的形式加載到進(jìn)程中。常與LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE一起使用。

              (5) LOAD_WITH_ALTERED_SEARCH_PATH

                   修改DLL的加載路徑

1.2 DLL的加載與卸載

    (1)加載

       不要在同一進(jìn)程中，同時(shí)使用LoadLIbrary和LoadLibraryEx加載同一DLL文件。

       DLL的引用計(jì)數(shù)是以進(jìn)程為單位的。LoadLibrary會(huì)把DLL文件加載到內(nèi)存，然后映射到進(jìn)程空間中。

       多次加載同一DLL只會(huì)增加引用計(jì)數(shù)而不會(huì)多次映射。當(dāng)所有進(jìn)程對(duì)DLL的引用計(jì)數(shù)都為0時(shí)，系統(tǒng)會(huì)在內(nèi)存中釋放該DLL。

    (2)卸載

         FreeLibrary,FreeLibraryAndExitThread對(duì)當(dāng)前進(jìn)程的DLL的引用計(jì)數(shù)減1

    (3) GetProcAddress

         取得函數(shù)地址。它只接受ANSI字符串。

2.DLL的入口函數(shù)

      2.1 DllMain

              BOOL WINAPI DllMain(

              HINSTANCE hInstDll, ""加載后在進(jìn)程中的虛擬地址

              DWORD fdwReason, ""系統(tǒng)因何而調(diào)用該函數(shù)

              PVOID fImpLoad ""查看是隱工還是動(dòng)態(tài)加載該DLL

    DLLs用DllMain方法來(lái)初始化他們自已。DllMain中的代碼應(yīng)盡量簡(jiǎn)單，只做一些簡(jiǎn)單的初始化工作。

    不要在DllMain中調(diào)用LoadLibrary,FreeLibrary及Shell, ODBC, COM, RPC, 和 socket 函數(shù)，從而避免不可預(yù)期的錯(cuò)誤。

  2.2 fdwReason的值

    (1)DLL_PROCESS_ATTACH

      系統(tǒng)在為每個(gè)進(jìn)程第一次加載該DLL時(shí)會(huì)，執(zhí)行DLL_PROCESS_ATTACH后面的語(yǔ)句來(lái)初始化DLL,DllMain的返回值僅由它決定。

     系統(tǒng)會(huì)忽略DLL_THREAD_ATTACH等執(zhí)行后DllMain的返回值。

     如果DllMain返回FALSE,系統(tǒng)會(huì)自動(dòng)調(diào)用DLL_PROCESS_DETACH的代碼并解除DLL文件中進(jìn)程中的內(nèi)存映射。        

    (2)DLL_PROCESS_DETACH

        如果DLL是因進(jìn)程終止而卸載其在進(jìn)程中的映射，那么負(fù)責(zé)調(diào)用ExitProcess的線(xiàn)程會(huì)調(diào)用DllMain中DLL_PROCESS_DETACH所對(duì)應(yīng)的代碼。

        如果DLL是因FreeLibrary或FreeLibraryAndExitThread，而卸載其在進(jìn)程中的映射, 那么FreeLibrary或FreeLibraryAndExitThread會(huì)負(fù)責(zé)調(diào)用DllMain中DLL_PROCESS_DETACH所對(duì)應(yīng)的代碼。

        如果DLL是因TerminateProcess而卸載其在進(jìn)程中的映射,系統(tǒng)不會(huì)調(diào)用DllMain中DLL_PROCESS_DETACH所對(duì)應(yīng)的代碼。

    (3) DLL_THREAD_ATTACH

        若進(jìn)程是先加載的DLL,后創(chuàng)建的線(xiàn)程

        那么在進(jìn)程中創(chuàng)建新線(xiàn)程時(shí)(主線(xiàn)程除外)，系統(tǒng)會(huì)執(zhí)行該進(jìn)程已載的所有DLL的DllMain中DLL_THREAD_ATTACH對(duì)應(yīng)的代碼。

         若進(jìn)程是先創(chuàng)建的線(xiàn)程,后加載的DLL

         那么系統(tǒng)不會(huì)調(diào)用DLL的DllMain中的代碼。

     (4) DLL_THREAD_DETACH

         進(jìn)程中的線(xiàn)程退出時(shí)，會(huì)先執(zhí)行所有已加載DLL的DllMain中DLL_THREAD_DETACH所對(duì)應(yīng)的代碼。若該代碼中有死循環(huán)，線(xiàn)程不會(huì)退出。              

2.3 同步化DllMain的調(diào)用

      同一時(shí)間只能有一個(gè)線(xiàn)程調(diào)用DllMain中的代碼，所以下面的代碼會(huì)導(dǎo)致死循環(huán)

BOOL WINAPI DllMain(HINSTANCE hInstDll, DWORD fdwReason, PVOID fImpLoad) {

   HANDLE hThread;

   DWORD dwThreadId;

   switch (fdwReason) {

   case DLL_PROCESS_ATTACH:

      // The DLL is being mapped into the process' address space.

      // Create a thread to do some stuff.

      hThread = CreateThread(NULL, 0, SomeFunction, NULL,

         0, &dwThreadId);// CreateThread會(huì)DLL_THREAD_ATTACH中的代碼，但是由于當(dāng)前線(xiàn)程并未執(zhí)行完畢,

      //所以DLL_THREAD_ATTACH 中的代碼不會(huì)被執(zhí)行，且CreateThread永無(wú)不會(huì)返回。

      // Suspend our thread until the new thread terminates.

      WaitForSingleObject(hThread, INFINITE);

­

      // We no longer need access to the new thread.

      CloseHandle(hThread);

      break;

­

   case DLL_THREAD_ATTACH:

      // A thread is being created.

      break;

­

   case DLL_THREAD_DETACH:

      // A thread is exiting cleanly.

      break;

­

   case DLL_PROCESS_DETACH:

      // The DLL is being unmapped from the process' address space.

      break;

   }

   return(TRUE);

}

­

3.延時(shí)加載DLL

(1)延時(shí)加載DLL的限制

         延遲加載的D L L是個(gè)隱含鏈接的D L L，它實(shí)際上要等到你的代碼試圖引用D L L中包含的一個(gè)符號(hào)時(shí)才進(jìn)行加載，它與動(dòng)態(tài)加載不同。

        http://msdn2.microsoft.com/en-us/library/yx1x886y(VS.80).aspx

4.已知的DLL (Known DLLs)

    位置：HKEY_LOCAL_MACHINE"SYSTEM"CurrentControlSet"Control"Session Manager"KnownDLLs

    LoadLibrary在查找DLL會(huì)先去該位置查找有無(wú)相應(yīng)的鍵值與DLL要對(duì)應(yīng)，若有則根據(jù)鏈值去%SystemRoot%"System32加載鍵值對(duì)應(yīng)的DLL

    若無(wú)則根據(jù)默認(rèn)規(guī)去尋找DLL

5.Bind and Rebase Module

    它可以程序啟動(dòng)的速度。ReBaseImage

­

DLL 注入和API鉤(DLL Injection and API Hooking)

1.概覽

  每個(gè)進(jìn)程都有自已獨(dú)立的地址空間，一個(gè)進(jìn)程不可能創(chuàng)建一個(gè)指向其它進(jìn)程地址空間的指針。

   然而如果我們把自已的DLL注射到另一個(gè)進(jìn)程的地址空間去，我們就可以在那個(gè)被注入的進(jìn)程里為所欲為了。

   Subclass同一進(jìn)程中的窗體：http://msdn2.microsoft.com/en-us/library/ms649784.aspx.

2.用注冊(cè)表注入DLL

     該方法適用于給GUI的程序注入DLL

     所有的GUI應(yīng)用程序在啟動(dòng)時(shí)都會(huì)加載User32.dll，而在User32.dll的DLL_PROCESS_ATTACH代碼根據(jù)注冊(cè)表中的信息

來(lái)注入用戶(hù)指定的DLL

注冊(cè)表項(xiàng)　HKEY_LOCAL_MACHINE"Software"Microsoft"Windows NT"CurrentVersion"Windows"

中有兩個(gè)值：

    LoadAppInit_Dlls：鍵值中指定要注入的DLL　如:c:"inject.dll

AppInit_Dlls：若其鍵值為1,則注入LoadAppInit_Dlls中指定的DLL，否則若為0則不注入。

    注:

(1)LoadAppInit_Dlls中的值是以空格或分號(hào)分隔的，所以DLL的路徑中最好不要有空格，最后不指定路徑，直接將DLL放到windows系統(tǒng)目錄中。

(2) 用注冊(cè)表注入DLL的方式有很大的局限性,Kernel32.dll和Ntdll.dll中有的函數(shù)才能調(diào)用

一.注入dll

1.通過(guò)注冊(cè)表項(xiàng) HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs 來(lái)指定你的dll的路徑，那么當(dāng)一個(gè)GUI程序啟動(dòng)時(shí)就要加載User32.dll,而User32.dll將會(huì)檢查這個(gè)值，如果有的話(huà)就LoadLibrary該Dll。這個(gè)方法不好，因?yàn)榇蠖鄶?shù)情況我們只需要針對(duì)性的注入，并且沒(méi)辦法注入到不使用User32.dll的進(jìn)程中；

­

2.用SetWindowsHookEx函數(shù)，并傳遞目標(biāo)線(xiàn)程ID、需要掛載的Dll在本進(jìn)程中的映射地址(hInstance)、替換函數(shù)在本進(jìn)程中的地址。這樣，當(dāng)被掛載進(jìn)程的這個(gè)線(xiàn)程要執(zhí)行相應(yīng)的操作時(shí)(GETMESSAGE、鍵盤(pán)消息之類(lèi)的)，就會(huì)發(fā)現(xiàn)已經(jīng)安裝了WH_XX，The system checks to see whether the DLL containing the GetMsgProc function is mapped into Process B's address space，如果還未映射該Dll，則強(qiáng)制LoadLibrary。然后系統(tǒng)調(diào)用hThisInstance + (GetMsgProc - hInstance),從而實(shí)現(xiàn)了事件的通知。這種方法的好處是可以針對(duì)某個(gè)進(jìn)程安裝Hook，缺點(diǎn)是容易被目標(biāo)進(jìn)程發(fā)現(xiàn)、同樣只適用于GUI進(jìn)程。如果不再想使用掛鉤了，那么需要調(diào)用UnhookWindowsHookEx，卸載Hook。

­

3.使用遠(yuǎn)程線(xiàn)程注入Dll(Injecting a DLL Using Remote Threads)

這個(gè)方法比較好。流程是這樣的:

?調(diào)用VirtualAllocEx，在目標(biāo)進(jìn)程保留一塊內(nèi)存，并提交，其長(zhǎng)度是你要注入Dll的全路徑長(zhǎng)度nLen + 1，返回地址pv;

?調(diào)用WriteProcessMemory，在目標(biāo)進(jìn)程的pv處寫(xiě)入Dll的全路徑，注意要添加\0結(jié)束符;

?獲取本進(jìn)程的LoadLibrary函數(shù)的地址，方法是調(diào)用pfn = GetProcAddress(GetModuleHandle(TEXT("Kernel32")), "LoadLibraryA")——之所以獲取本進(jìn)程的地址，是因?yàn)閗ernel32.dll在每個(gè)進(jìn)程的映射地址都相同，倘若不同，那么此方法則無(wú)效;

?調(diào)用HANDLE hThread = CreateRemoteThread(hProcessRemote, NULL, 0,  pfn, pv, 0, NULL)來(lái)創(chuàng)建遠(yuǎn)程線(xiàn)程，其實(shí)這個(gè)線(xiàn)程函數(shù)就是LoadLibrary函數(shù)，因此將執(zhí)行映射Dll到目標(biāo)進(jìn)程的操作;

?調(diào)用VirtuallFreeEx(hProcessRemote, pv)釋放提交的內(nèi)存;

這便完成了dll注入。

缺點(diǎn)是不能用在windows98上。但是對(duì)于xp都要被微軟拋棄的年代，windows98地影響不大了。

­

4.披著羊皮的狼：使用特洛伊Dll來(lái)注入Dll(Injecting a DLL with a Trojan DLL)

其實(shí)就是替換某個(gè)目標(biāo)進(jìn)程要加載的a.dll，并把a(bǔ).dll的所有引出函數(shù)用函數(shù)轉(zhuǎn)發(fā)器在自己的dll引出。

­

5.用調(diào)試函數(shù)插入Dll

ReadProcessMemory和WriteProcessMemory是windows提供的調(diào)試函數(shù)。如果在方法3中調(diào)用WriteProcessMemory寫(xiě)入的不是字串而是精心編排好的機(jī)器指令，并且寫(xiě)在目標(biāo)進(jìn)程特定的地址空間，那么這段機(jī)器指令就有機(jī)會(huì)執(zhí)行——而這段機(jī)器指令恰好完成了LoadLibrary功能;

­

6.其他方法（略）

­

二.掛接API(API Hooking)

其實(shí)，這是許多注入的Dll都愿意做的事情。

所謂掛接API就是在目標(biāo)進(jìn)程調(diào)用windows API之前，先執(zhí)行我們的仿API函數(shù)，從而控制系統(tǒng)API的行為，達(dá)到特殊的目的。

我們的仿造函數(shù)必須與要替換的系統(tǒng)API有相同的型參表以及相同的返回值類(lèi)型.

­

1.改寫(xiě)系統(tǒng)API代碼的前幾個(gè)字節(jié)，通過(guò)寫(xiě)入jmp指令來(lái)跳轉(zhuǎn)到我們的函數(shù)。在我們的函數(shù)里執(zhí)行操作，可以直接返回一個(gè)值，也可以將系統(tǒng)API的前幾個(gè)字節(jié)復(fù)原，調(diào)用系統(tǒng)API，并返回系統(tǒng)API的值——隨便你想怎么做。

此方法的缺點(diǎn)是對(duì)于搶占式多線(xiàn)程的系統(tǒng)不太管用。

­

2.通過(guò)改寫(xiě)目標(biāo)進(jìn)程IAT中要調(diào)用的函數(shù)地址來(lái)達(dá)到目的。具體操作見(jiàn)書(shū)中示例

­

­

­

線(xiàn)程本地存儲(chǔ)(Thread-Local Storage)

例子C / C + +運(yùn)行期庫(kù)要使用線(xiàn)程本地存儲(chǔ)器（ T L S）。由于運(yùn)行期庫(kù)是在多線(xiàn)程應(yīng)用程序出現(xiàn)前的許多年設(shè)計(jì)的，因此運(yùn)行期庫(kù)中的大多數(shù)函數(shù)是用于單線(xiàn)程應(yīng)用程序的。函數(shù)s t r t o k就是個(gè)很好的例子。

盡可能避免使用全局變量和靜態(tài)變量

1.動(dòng)態(tài)TLS

圖21-1 用于管理T L S的內(nèi)部數(shù)據(jù)結(jié)構(gòu)

­

在創(chuàng)建線(xiàn)程時(shí)，進(jìn)程會(huì)為當(dāng)前創(chuàng)建的線(xiàn)程分配一個(gè)void *的數(shù)組作為TLS用。它用于存儲(chǔ)只限當(dāng)前線(xiàn)程可見(jiàn)的全局變量。

從而使進(jìn)程中的每個(gè)線(xiàn)程都可以有自已的(不能其它線(xiàn)程訪(fǎng)問(wèn)的)全局變量。

TlsAlloc在返回時(shí)會(huì)先把槽中的值置為0。每個(gè)線(xiàn)程至少有64個(gè)槽。

2.靜態(tài)TLS

              __declspec(thread)關(guān)鍵字用于聲明，線(xiàn)程本地的全局變量。

              要求聲明的變量必須是全局變量或靜態(tài)變量。

3.Common API:

              TlsAlloc   TlsFree

              TlsSetValue   TlsGetValue

              __declspec(thread)

posted @ 2009-10-26 18:33 深邃者 閱讀(1057) | 評(píng)論 (0) | 編輯 收藏