轉載（不要一輩子靠技術生存）

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

五種程序設計方法

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

程序的內存分配

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

char s1[] = "aaaaaaaaaaaaaaa";
char *s2 = "bbbbbbbbbbbbbbbbb";
aaaaaaaaaaa是在運行時刻賦值的；
而bbbbbbbbbbb是在編譯時就確定的；
但是，在以后的存取中，在棧上的數組比指針所指向的字符串(例如堆)快。
比如：
#include
void main()
{
char a = 1;
char c[] = "1234567890";
char *p ="1234567890";
a = c[1];
a = p[1];
return;
}
對應的匯編代碼
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
第一種在讀取時直接就把字符串中的元素讀到寄存器cl中，而第二種則要先把指edx中，在根據edx讀取字符，顯然慢了。

2.7小結：
堆和棧的區別可以用如下的比喻來看出：
使用棧就象我們去飯館里吃飯，只管點菜（發出申請）、付錢、和吃（使用），吃飽了就走，不必理會切菜、洗菜等準備工作和洗碗、刷鍋等掃尾工作，他的好處是快捷，但是自由度小。
使用堆就象是自己動手做喜歡吃的菜肴，比較麻煩，但是比較符合自己的口味，而且自由度大。

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

代碼注入的三種方法

• Windows 鉤子
• CreateRemoteThread 和 LoadLibrary 技術
  ——進程間通信
• CreateRemoteThread 和 WriteProcessMemory 技術
  ——如何用該技術子類化遠程控件
  ——何時使用 CreateRemoteThread 和 WriteProcessMemory 技術
• 結束語
• 附錄A
• 附錄B
• 附錄C
• 附錄D
• 附錄E
• 附錄F
• 參考資料
  

簡介

　　本文將討論如何把代碼注入不同的進程地址空間，然后在該進程的上下文中執行注入的代碼。 我們在網上可以查到一些窗口/密碼偵測的應用例子，網上的這些程序大多都依賴 Windows 鉤子技術來實現。本文將討論除了使用 Windows 鉤子技術以外的其它技術來實現這個功能。如圖一所示：

圖一　WinSpy 密碼偵測程序

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

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

通常有三種可能性來解決這個問題。

1. 將你的代碼放入某個 DLL，然后通過 Windows 鉤子映射該DLL到遠程進程；
2. 將你的代碼放入某個 DLL，然后通過 CreateRemoteThread 和 LoadLibrary 技術映射該DLL到遠程進程；
3. 如果不寫單獨的 DLL，可以直接將你的代碼拷貝到遠程進程——通過 WriteProcessMemory——并用 CreateRemoteThread 啟動它的執行。本文將在第三部分詳細描述該技術實現細節；

第一部分： Windows 鉤子

范例程序——參見HookSpy 和HookInjEx

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

1. 在成功調用 SetWindowsHookEx 后，系統自動映射 DLL 到鉤子作用的線程地址空間，但不必立即發生映射，因為 Windows 鉤子都是消息，DLL 在消息事件發生前并沒有產生實際的映射。例如：
   　　如果你安裝一個鉤子監控某些線程（WH_CALLWNDPROC）的非隊列消息，在消息被實際發送到（某些窗口的）鉤子作用的線程之前，該DLL 是不會被映射到遠程進程的。換句話說，如果 UnhookWindowsHookEx 在某個消息被發送到鉤子作用的線程之前被調用，DLL 根本不會被映射到遠程進程（即使 SetWindowsHookEx 本身調用成功）。為了強制進行映射，在調用 SetWindowsHookEx 之后馬上發送一個事件到相關的線程。
   　　在UnhookWindowsHookEx了之后，對于沒有映射的DLL處理方法也一樣。只有在足夠的事件發生后，DLL才會有真正的映射。
2. 當你安裝鉤子后，它們可能影響整個系統得性能（尤其是系統級鉤子），但是你可以很容易解決這個問題，如果你使用線程專用鉤子的DLL映射機制，并不截獲消息。考慮使用如下代碼：
   

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

   　　那么會發生什么呢？首先我們通過Windows 鉤子將DLL映射到遠程進程。然后，在DLL被實際映射之后，我們解開鉤子。通常當第一個消息到達鉤子作用線程時，DLL此時也不會被映射。這里的處理技巧是調用LoadLibrary通過增加 DLLs的引用計數來防止映射不成功。
   　　現在剩下的問題是如何卸載DLL，UnhookWindowsHookEx 是不會做這個事情的，因為鉤子已經不作用于線程了。你可以像下面這樣做：
   
   
   • 就在你想要解除DLL映射前，安裝另一個鉤子；
   • 發送一個“特殊”消息到遠程線程；
   • 在鉤子過程中截獲這個消息，響應該消息時調用 FreeLibrary 和 UnhookWindowsHookEx；

    

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

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

第二部分：CreateRemoteThread 和 LoadLibrary 技術

范例程序——LibSpy

通常，任何進程都可以通過 LoadLibrary API 動態加載DLL。但是，如何強制一個外部進程調用這個函數呢？答案是：CreateRemoteThread。
首先，讓我們看一下 LoadLibrary 和FreeLibrary API 的聲明：

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

現在將它們與傳遞到 CreateRemoteThread 的線程例程——ThreadProc 的聲明進行比較。

DWORD WINAPI ThreadProc(
LPVOID lpParameter // 線程數據
);

你可以看到，所有函數都使用相同的調用規范并都接受 32位參數，返回值的大小都相同。也就是說，我們可以傳遞一個指針到LoadLibrary/FreeLibrary 作為到 CreateRemoteThread 的線程例程。但這里有兩個問題，請看下面對CreateRemoteThread 的描述：

1. CreateRemoteThread 的 lpStartAddress 參數必須表示遠程進程中線程例程的開始地址。
2. 如果傳遞到 ThreadFunc 的參數lpParameter——被解釋為常規的 32位值（FreeLibrary將它解釋為一個 HMODULE），一切OK。但是，如果 lpParameter 被解釋為一個指針（LoadLibraryA將它解釋為一個串指針）。它必須指向遠程進程的某些數據。

　　第一個問題實際上是由它自己解決的。LoadLibrary 和 FreeLibray 兩個函數都在 kernel32.dll 中。因為必須保證kernel32存在并且在每個“常規”進程中的加載地址要相同，LoadLibrary/FreeLibray 的地址在每個進程中的地址要相同，這就保證了有效的指針被傳遞到遠程進程。
　　第二個問題也很容易解決。只要通過 WriteProcessMemory 將 DLL 模塊名（LoadLibrary需要的DLL模塊名）拷貝到遠程進程即可。

所以，為了使用CreateRemoteThread 和 LoadLibrary 技術，需要按照下列步驟來做：

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

　　此外，處理完成后不要忘了關閉所有句柄，包括在第四步和第八步創建的兩個線程以及在第一步獲取的遠程線程句柄。現在讓我們看一下 LibSpy 的部分代碼，為了簡單起見，上述步驟的實現細節中的錯誤處理以及 UNICODE 支持部分被略掉。

HANDLE hThread;
char    szLibPath[_MAX_PATH];  // “LibSpy.dll”模塊的名稱 (包括全路徑);
void*   pLibRemote;   // 遠程進程中的地址，szLibPath 將被拷貝到此處;
DWORD   hLibModule;   // 要加載的模塊的基地址（HMODULE）
HMODULE hKernel32 = ::GetModuleHandle("Kernel32");
// 初始化szLibPath
//...
// 1. 在遠程進程中為szLibPath 分配內存
// 2. 將szLibPath 寫入分配的內存
pLibRemote = ::VirtualAllocEx( hProcess, NULL, sizeof(szLibPath),
MEM_COMMIT, PAGE_READWRITE );
::WriteProcessMemory( hProcess, pLibRemote, (void*)szLibPath,
sizeof(szLibPath), NULL );
// 將"LibSpy.dll" 加載到遠程進程（使用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 );		

// 從目標進程中卸載"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 技術

范例程序——WinSpy

　　另外一個將代碼拷貝到另一個進程地址空間并在該進程上下文中執行的方法是使用遠程線程和 WriteProcessMemory API。這種方法不用編寫單獨的DLL，而是用 WriteProcessMemory 直接將代碼拷貝到遠程進程——然后用 CreateRemoteThread 啟動它執行。先來看看 CreateRemoteThread 的聲明：

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

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

綜上所述，我們得按照如下的步驟來做：

1. 獲取一個遠程進程的HANDLE (OpenProces) ；
2. 在遠程進程地址空間中為注入的數據分配內存（VirtualAllocEx）；
3. 將初始的 INDATA 數據結構的一個拷貝寫入分配的內存中（WriteProcessMemory）；
4. 在遠程進程地址空間中為注入的代碼分配內存；
5. 將 ThreadFunc 的一個拷貝寫入分配的內存；
6. 用 CreateRemoteThread啟動遠程的 ThreadFunc 拷貝；
7. 等待遠程線程終止（WaitForSingleObject）；
8. 獲取遠程來自遠程進程的結果（ReadProcessMemory 或 GetExitCodeThread）；
9. 釋放在第二步和第四步中分配的內存（VirtualFreeEx）；
10. 關閉在第六步和第一步獲取的句柄（CloseHandle）；

ThreadFunc 必須要遵循的原則：

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

   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:				

   或者將它們修改成一個 if-else if 結構語句（參見附錄E）。

　　如果你沒有按照這些規則來做，目標進程很可能會崩潰。所以務必牢記。在目標進程中不要假設任何事情都會像在本地進程中那樣 （參見附錄F）。

GetWindowTextRemote(A/W)

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

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

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

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

　　INJDATA 是一個被注入到遠程進程的數據結構。但在注入之前，結構中指向 SendMessageA 的指針是在本地應用程序中初始化的。因為對于每個使用user32.dll的進程來說，user32.dll總是被映射到相同的地址，因此，SendMessageA 的地址也肯定是相同的。這就保證了被傳遞到遠程進程的是一個有效的指針。

ThreadFunc函數

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

ThradFunc 是被遠程線程執行的代碼。

• 注釋：注意AfterThreadFunc 是如何計算 ThreadFunc 大小的。通常這樣做并不是一個好辦法，因為鏈接器可以隨意更改函數的順序（也就是說ThreadFunc可能被放在 AfterThreadFunc之后）。這一點你可以在小項目中很好地保證函數的順序是預先設想好的，比如 WinSpy 程序。在必要的情況下，你還可以使用 /ORDER 鏈接器選項來解決函數鏈接順序問題。或者用反匯編確定 ThreadFunc 函數的大小。

范例程序——InjectEx

下面我們將討論一些更復雜的內容，如何子類化屬于另一個進程的控件。

首先，你得拷貝兩個函數到遠程進程來完成此任務

1. ThreadFunc實際上是通過 SetWindowLong子類化遠程進程中的控件；
2. NewProc是子類化控件的新窗口過程；

　　這里主要的問題是如何將數據傳到遠程窗口過程 NewProc，因為 NewProc 是一個回調函數，它必須遵循特定的規范和原則，我們不能簡單地在參數中傳遞 INJDATA指針。幸運的是我找到了有兩個方法來解決這個問題，只不過要借助匯編語言，所以不要忽略了匯編，關鍵時候它是很有用的！

方法一：

如下圖所示：

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

static LRESULT CALLBACK NewProc(
HWND hwnd,       // 窗口句柄
UINT uMsg,       // 消息標示符
WPARAM wParam,   // 第一個消息參數
LPARAM lParam )  // 第二個消息參數
{
INJDATA* pData = (INJDATA*) NewProc;  // pData 指向 NewProc
pData--;              // 現在pData 指向INJDATA;
// 回想一下INJDATA 被置于遠程進程NewProc之前;
//-----------------------------
// 此處是子類化代碼
// ........
//-----------------------------
// 調用原窗口過程;
// fnOldProc (由SetWindowLong 返回) 被（遠程）ThreadFunc初始化
// 并被保存在（遠程）INJDATA;中
return pData->fnCallWindowProc( pData->fnOldProc,
hwnd,uMsg,wParam,lParam );
}

INJDATA* pData = (INJDATA*) NewProc;

　　這種方式 pData得到的是硬編碼值（在我們的進程中是原 NewProc 的內存地址）。這不是我們十分想要的。在遠程進程中，NewProc “當前”拷貝的內存地址與它被移到的實際位置是無關的，換句話說，我們會需要某種類型的“this 指針”。
雖然用 C/C++ 無法解決這個問題，但借助內聯匯編可以解決，下面是對 NewProc的修改：

static LRESULT CALLBACK NewProc(
HWND hwnd,       // 窗口句柄
UINT uMsg,       // 消息標示符
WPARAM wParam,   // 第一個消息參數
LPARAM lParam )  // 第二個消息參數
{
// 計算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 );
}

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

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

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

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

此即為 InjecEx 中使用的解決方案，類似于 HookInjEx，交換鼠標點擊“開始”左右鍵時的功能。

方法二：

對于我們的問題，在遠程進程地址空間中將 INJDATA 放在 NewProc 前面不是唯一的解決辦法。看下面 NewProc的變異版本：

static LRESULT CALLBACK NewProc(
HWND hwnd,      // 窗口句柄
UINT uMsg,      // 消息標示符
WPARAM wParam,  // 第一個消息參數
LPARAM lParam ) // 第二個消息參數
{
INJDATA* pData = 0xA0B0C0D0;    // 虛構值
//-----------------------------
// 子類化代碼
// ........
//-----------------------------
// 調用原來的窗口過程
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 拷貝到目標進程；
2. 修改 NewProc 的代碼，以便 pData 中保存的是 INJDATA 的真實地址。
   例如，假設 INJDATA 的地址（VirtualAllocEx返回的值）在目標進程中是 0x008a0000。然后象下面這樣修改NewProc的代碼：

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

   也就是說，你用真正的 INJDATA（注2） 地址替代了虛擬值 A0B0C0D0（注2）。
   
3. 開始執行遠程的 ThreadFunc，它負責子類化遠程進程中的控件。
   

• 注1、有人可能會問，為什么地址 A0B0C0D0 和 008a0000 在編譯時順序是相反的。因為 Intel 和 AMD 處理器使用 little-endian 符號來表示（多字節）數據。換句話說，某個數字的低位字節被存儲在內存的最小地址處，而高位字節被存儲在最高位地址。
  假設“UNIX”這個詞存儲用4個字節，在 big-endian 系統中，它被存為“UNIX”，在 little-endian 系統中，它將被存為“XINU”。
• 注2、某些破解（很糟）以類似的方式修改可執行代碼，但是一旦加載到內存，一個程序是無法修改自己的代碼的（代碼駐留在可執行程序的“.text” 區域，這個區域是寫保護的）。但仍可以修改遠程的 NewProc，因為它是先前以 PAGE_EXECUTE_READWRITE 許可方式被拷貝到某個內存塊中的。

何時使用 CreateRemoteThread 和 WriteProcessMemory 技術

　　與其它方法比較，使用 CreateRemoteThread 和 WriteProcessMemory 技術進行代碼注入更靈活，這種方法不需要額外的 dll，不幸的是，該方法更復雜并且風險更大，只要ThreadFunc出現哪怕一丁點錯誤，很容易就讓（并且最大可能地會）使遠程進程崩潰（參見附錄 F），因為調試遠程 ThreadFunc 將是一個可怕的夢魘，只有在注入的指令數很少時，你才應該考慮使用這種技術進行注入，對于大塊的代碼注入，最好用 I.和II 部分討論的方法。

WinSpy 以及 InjectEx 請從這里下載源代碼。

到目前為止，有幾個問題是我們未提及的，現總結如下：

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

　　最后，有幾件事情一定要了然于心：你的注入代碼很容易摧毀目標進程，尤其是注入代碼本身出錯的時候，所以要記住：權力帶來責任！
　　因為本文中的許多例子是關于密碼的，你也許還讀過 Zhefu Zhang 寫的另外一篇文章“Super Password Spy++” ，在該文中，他解釋了如何獲取IE 密碼框中的內容，此外，他還示范了如何保護你的密碼控件免受類似的攻擊。

附錄A：

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

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

總之，對于 WinNT 4 和較高的版本中

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

附錄B：

/GZ 編譯器開關

　　在生成 Debug 版本時，/GZ 編譯器特性是默認打開的。你可以用它來捕獲某些錯誤（具體細節請參考相關文檔）。但對我們的可執行程序意味著什么呢？
　　當打開 /GZ 開關，編譯器會添加一些額外的代碼到可執行程序中每個函數所在的地方，包括一個函數調用（被加到每個函數的最后）——檢查已經被我們的函數修改的 ESP堆棧指針。什么！難道有一個函數調用被添加到 ThreadFunc 嗎？那將導致災難。ThreadFunc 的遠程拷貝將調用一個在遠程進程中不存在的函數（至少是在相同的地址空間中不存在）

靜態函數和增量鏈接

　　增量鏈接主要作用是在生成應用程序時縮短鏈接時間。常規鏈接和增量鏈接的可執行程序之間的差別是——增量鏈接時，每個函數調用經由一個額外的JMP指令，該指令由鏈接器發出（該規則的一個例外是函數聲明為靜態）。這些 JMP 指令允許鏈接器在內存中移動函數，這種移動無需修改引用函數的 CALL指令。但這些JMP指令也確實導致了一些問題：如 ThreadFunc 和 AfterThreadFunc 將指向JMP指令而不是實際的代碼。所以當計算ThreadFunc 的大小時：

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

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

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

附錄D：

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

　　局部變量總是存儲在堆棧中，如果某個函數有256個字節的局部變量，當進入該函數時，堆棧指針就減少256個字節（更精確地說，在函數開始處）。例如，下面這個函數：

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      ; 承諾一個新頁內存（如果還沒有承諾）
sub    esp, 0x1000    ; "分配" 第二次4 Kb
test  [esp], eax      ; ...
sub    esp, 0x1000
test  [esp], eax

注意事項
　　“每一個線程到達其自己的堆棧空間，默認情況下，此空間由承諾的以及預留的內存組成，每個線程使用 1 MB預留的內存，以及一頁承諾的內存，系統將根據需要從預留的堆棧內存中承諾一頁內存區域” （參見 MSDN CreateThread > dwStackSize > Thread Stack Size）
　　還應該清楚為什么有關　/GS 的文檔說在堆棧探針在 Win32 應用程序和Windows NT虛擬內存管理器之間進行謹慎調整。

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

為什么要將開關語句拆分成三個以上?

用下面這個例子很容易解釋這個問題，假設有如下這么一個函數：

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

地址      操作碼/參數       解釋后的指令
--------------------------------------------------
; 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表示最壞的時間復雜度；
2. 我們假設需要5條指令來進行表查詢計算偏移量，最終跳到相應的地址；

　　現在，你也許認為出現上述情況只是因為CASE常量被有意選擇為連續的（1，2，3，4）。幸運的是，它的這個方案可以應用于大多數現實例子中，只有偏移量的計算稍微有些復雜。但有兩個例外：

• 如果CASE語句少于等于三個；
• 如果CASE 常量完全互不相關（如：“"case 1” ，“case 13” ，“case 50” ， 和“case 1000” ）；

　　顯然，單獨判斷每個的CASE常量的話，結果代碼繁瑣耗時，但使用CMP和JMP指令則使得結果代碼的執行就像普通的if-else 語句。
有趣的地方：如果你不明白CASE語句使用常量表達式的理由，那么現在應該弄明白了吧。為了創建地址表，顯然在編譯時就應該知道相關地址。

現在回到問題！
注意到地址 0040100C 處的JMP指令了嗎？我們來看看Intel關于十六進制操作碼 FF 的文檔是怎么說的：

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

　　原來JMP 使用了一種絕對尋址方式，也就是說，它的操作數（CASE語句中的 0040102C）表示一個絕對地址。還用我說什么嗎？遠程 ThreadFunc 會盲目地認為地址表中開關地址是 0040102C，JMP到一個錯誤的地方，造成遠程進程崩潰。

為什么遠程進程會崩潰呢？

當遠程進程崩潰時，它總是會因為下面這些原因：

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

   :004014C0    push EBP         ; ThreadFunc 的入口點
       :004014C1    mov EBP, ESP
       ...
       :004014C5    call 0041550     ;  這里將使遠程進程崩潰
       ...
       :00401502    ret
       

   如果 CALL 是由編譯器添加的指令（因為某些“禁忌” 開關如/GZ是打開的），它將被定位在 ThreadFunc 的開始的某個地方或者結尾處。

　　不管哪種情況，你都要小心翼翼地使用 CreateRemoteThread 和 WriteProcessMemory 技術。尤其要注意你的編譯器/鏈接器選項，一不小心它們就會在 ThreadFunc 添加內容。

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

CreateRemoteThread

CreateRemoteThread提供了一個在遠程進程中執行代碼的方法,就像代碼長出翅膀飛到別處運行。本文將做一個入門介紹，希望對廣大編程愛好者有所幫助。

先解釋一下遠程進程，其實就是要植入你的代碼的進程，相對于你的工作進程（如果叫本地進程的話）它就叫遠程進程，可理解為宿主。

首先介紹一下我們的主要工具CreateRemoteThread，這里先將函數原型簡單介紹以下。

CreateRemoteThread可將線程創建在遠程進程中。

函數原型
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
);
參數說明：
hProcess
[輸入] 進程句柄
lpThreadAttributes
[輸入] 線程安全描述字，指向SECURITY_ATTRIBUTES結構的指針
dwStackSize
[輸入] 線程棧大小，以字節表示
lpStartAddress
[輸入] 一個LPTHREAD_START_ROUTINE類型的指針，指向在遠程進程中執行的函數地址
lpParameter
[輸入] 傳入參數
dwCreationFlags
[輸入] 創建線程的其它標志

lpThreadId
[輸出] 線程身份標志，如果為NULL,則不返回

返回值
成功返回新線程句柄，失敗返回NULL，并且可調用GetLastError獲得錯誤值。

接下來我們將以兩種方式使用CreateRemoteThread，大家可以領略到CreateRemoteThread的神通，它使你的代碼可以脫離你的進程，植入到別的進程中運行。

第一種方式

第一種方式，我們使用函數的形式。即我們將自己程序中的一個函數植入到遠程進程中。

步驟1：首先在你的進程中創建函數MyFunc，我們將把它放在另一個進程中運行，這里以windows

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

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

步驟3：獲得目標進程句柄，這里用到兩個不太常用的函數（當然如果經常做線程/進程等方面的 項目的話，就很面熟了），但及有用
DWORD PID, TID;
TID = ::GetWindowThreadProcessId (hStart, &PID);

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

步驟4：在目標進程中配變量地址空間，這里我們分配10個字節，并且設定為可以讀

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

PAGE_READWRITE );

步驟5：寫內容到目標進程中分配的變量空間
::WriteProcessMemory( hProcess, pDataRemote, szBuffer,(sizeof(szBuffer),NULL);

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

PAGE_EXECUTE_READWRITE );

步驟7：寫內容到目標進程中分配的代碼地址空間
WriteProcessMemory( hProcess, pCodeRemote, &MyFunc, cbCodeSize, NULL);

步驟8：在目標進程中執行代碼

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

這里有幾個值得說明的地方:
使用WaitForSingleObject等待線程結束;
使用GetExitCodeThread獲得返回值；
最后關閉句柄CloseHandle。

步驟9：清理現場

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

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

關閉進程句柄
::CloseHandle( hProcess );

第二種方式

第二種方式，我們使用動態庫的形式。即我們將自己一個動態庫植入到遠程進程中。

這里不再重復上面相同的步驟,只寫出其中關鍵的地方.
關鍵1:
在步驟5中將動態庫的路徑作為變量傳入變量空間.
關鍵2:
在步驟8中,將GetProcAddress作為目標執行函數.

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

另外在步驟9,清理現場中首先要先進行釋放我們的動態庫.也即類似步驟8執行函數FreeLibrary

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

好了,限于篇幅不能夠介紹的很細,在使用過程中如有疑問可向作者咨詢.（開發環境：windows2000/vc6.0）
 

本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/fangchao918628/archive/2008/08/30/2852744.aspx

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

dll #pragma data_seg 實現數據的共享

#pragma data_seg("flag_data")
   int count=0;
#pragma data_seg()
#pragma comment(linker,"/SECTION:flag_data,RWS")
這種方法只能在沒有def文件時使用，如果通過def文件進行導出的話，那么設置就要在def文件內設置而不能
在代碼里設置了。
SETCTIONS
flag_data READ WRITE SHARED

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

個新的數據段并定義共享數據，其具體格式為：

#pragma data_seg （"shareddata") //名稱可以

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

HWND sharedwnd=NULL;//共享數據

#pragma data_seg()



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

第一點：什么是共享數據段？為什么要用共享數據段？？它有什么用途？？
在Win16環境中，DLL的全局數據對每個載入它的進程來說都是相同的；而在Win32環境中，情況卻發生了變化，DLL函數中的代碼所創建的任何對象（包括變量）都歸調用它的線程或進程所有。當進程在載入DLL時，操作系統自動把DLL地址映射到該進程的私有空間，也就是進程的虛擬地址空間，而且也復制該DLL的全局數據的一份拷貝到該進程空間。也就是說每個進程所擁有的相同的DLL的全局數據，它們的名稱相同，但其值卻并不一定是相同的，而且是互不干涉的。

因此，在Win32環境下要想在多個進程中共享數據，就必須進行必要的設置。在訪問同一個Dll的各進程之間共享存儲器是通過存儲器映射文件技術實現的。也可以把這些需要共享的數據分離出來，放置在一個獨立的數據段里，并把該段的屬性設置為共享。必須給這些變量賦初值，否則編譯器會把沒有賦初始值的變量放在一個叫未被初始化的數據段中。



#pragma data_seg預處理指令用于設置共享數據段。例如：

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

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



當進程隱式或顯式調用一個動態庫里的函數時，系統都要把這個動態庫映射到這個進程的虛擬地址空間里(以下簡稱"地址空間")。這使得DLL成為進程的一部分，以這個進程的身份執行，使用這個進程的堆棧。(這項技術又叫code Injection技術，被廣泛地應用在了病毒、黑客領域！呵呵^_^)



第二點：在具體使用共享數據段時需要注意的一些問題！

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. (注意: 即使是全局變量和靜態變量也都不是共享的!) 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. (這個編譯參數既可以使用pragma指令來指定，也可以在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 深邃者 閱讀(423) | 評論 (0) | 編輯 收藏

#Pragma 指令介紹

在所有的預處理指令中，#Pragma 指令可能是最復雜的了，它的作用是設定編譯器的狀態或者是指示編譯器完成一些特定的動作。#pragma指令對每個編譯器給出了一個方法,在保持與C和C ++語言完全兼容的情況下,給出主機或操作系統專有的特征。依據定義,編譯指示是機器或操作系統專有的,且對于每個編譯器都是不同的。

其格式一般為: #Pragma Para
其中Para 為參數，下面來看一些常用的參數。

(1)message 參數。

Message 參數是我最喜歡的一個參數，它能夠在編譯信息輸出窗口中輸出相應的信息，這對于源代碼信息的控制是非常重要的。其使用方法為：
#Pragma message(“消息文本”)
當編譯器遇到這條指令時就在編譯輸出窗口中將消息文本打印出來。
當我們在程序中定義了許多宏來控制源代碼版本的時候，我們自己有可能都會忘記有沒有正確的設置這些宏，此時我們可以用這條指令在編譯的時候就進行檢查。
假設我們希望判斷自己有沒有在源代碼的什么地方定義了_X86這個宏可以用下面的方法
#ifdef _X86
#Pragma message(“_X86 macro activated!”)
#endif
當我們定義了_X86這個宏以后，應用程序在編譯時就會在編譯輸出窗口里顯示“_
X86 macro activated!”。我們就不會因為不記得自己定義的一些特定的宏而抓耳撓腮了。

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

格式如：
#pragma code_seg( ["section-name"[,"section-class"] ] )
它能夠設置程序中函數代碼存放的代碼段，當我們開發驅動程序的時候就會使用到它。

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

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

(4)#pragma hdrstop

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

(5)#pragma resource

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

(6)#pragma warning

（7）pragma comment(...)

（8）progma data_seg

應用程序的入口文件前面加上

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

然后程序啟動的地方加上

if(app_count>0)     // 如果計數大于0，則退出應用程序。
{
   //MessageBox(NULL, "已經啟動一個應用程序", "Warning", MB_OK);

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

   return FALSE;
}
app_count++;

Windows 在一個Win32程序的地址空間周圍筑了一道墻。通常，一個程序的地址空間中的數據是私有的，對別的程序而言是不可見的。但是執行STRPROG的多個執行實體表示了STRLIB在程序的所有執行實體之間共享數據是毫無問題的。當您在一個STRPROG窗口中增加或者刪除一個字符串時，這種改變將立即反映在其它的窗口中。

在全部例程之間，STRLIB共享兩個變量：一個字符數組和一個整數（記錄已儲存的有效字符串的個數）。STRLIB將這兩個變量儲存在共享的一個特殊內存區段中：

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

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

連結器必須知道有一個「shared」共享數據段。在「Project Settings」對話框選擇「Link」頁面卷標。選中「STRLIB」時在「Project Options」字段（在Release和Debug設定中均可），包含下面的連結敘述：

/SECTION:shared,RWS
        

字母RWS表示段具有讀、寫和共享屬性。或者，您也可以直接用DLL原始碼指定連結選項，就像我們在STRLIB.C那樣：

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

共享的內存段允許iTotal變量和szStrings字符串數組在STRLIB的所有例程之間共享。因為MAX_STRINGS等于256，而 MAX_LENGTH等于63，所以，共享內存段的長度為32,772字節－iTotal變量需要4字節，256個指針中的每一個都需要128字節。

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

RTTI、虛函數和虛基類的實現方式、開銷分析及使用指導

RTTI、虛函數和虛基類的實現方式、開銷分析及使用指導

白楊

http://baiy.cn

“在正確的場合使用恰當的特性” 對稱職的C++程序員來說是一個基本標準。想要做到這點，首先要了解語言中每個特性的實現方式及其開銷。本文主要討論相對于傳統 C 而言，對效率有影響的幾個C++新特性。

相對于傳統的 C 語言，C++ 引入的額外開銷體現在以下兩個方面：

編譯時開銷

運行時開銷

圖中虛箭頭代表偏移，實箭頭代表指針

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

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

Debug 和 Release

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

DLL 線程本地存儲

DLL, 線程本地存儲

1.概覽

.構造DLL  

   (1)僅導出函數

      DLL可以導出全局變量和類，但我們不建議這么做，建議導出函數。

   (2).lib

      每個DLL都有與之相對應的.lib文件,該文件中列出了DLL中導出的函數和變量的符號名

   (3)指定要導出的函數名

       因為不同編譯器的Name mangle規則不同，這就導致DLL不能跨編譯器使用。

       有以下兩種方法可以解決這個問題：

            1.在.def文件中指定要導出的函數名

            2.在編譯指中指定要導出的函數名：

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

.DLL加載路徑

    當需要加載一個DLL時，系統會依照下面的順序去尋找所需DLL直到找到為止，然后加載，否則加載失敗。

              (1)當前可執行文件路徑

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

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

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

              (5)當前進程所在路徑

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

­

.創建\使用動態鏈接庫

首先必須創建一個包含需要導出的符號的頭文件，以便其他程序鏈接到該dll上：

// dllexample.h

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

#define DLLEXAMPLE_API __declspec(dllexport)

#else

#define DLLEXAMPLE_API __declspec(dllimport)

#endif

DLLEXAMPLE_API int fnDllexample(void);

當其他應用包含該頭文件，意圖使用該dll的導出符號時，因為沒有定義DLLEXAMPLE_EXPORTS，所以使用的是__declspec(dllimport)，這樣編譯器編譯時便知道這是從外部引入的函數。在鏈接時，鏈接程序將生成導入表(ImportAddressTable),該表羅列了所有調用到的函數，以及一個空白的對應地址。在程序執行時，加載器將動態的填入每個函數符號在本進程中的地址，使得程序能正確的調用到dll中的函數上。

這種通過dll提供的.h和.lib文件進行鏈接dll的使用方式，稱為隱式鏈接。用vc開發程序時，幾乎所有的系統API調用都用了隱式鏈接。

.顯式鏈接

在exe創建時不引用.lib文件中的符號，當然也不必包含.h頭文件，而是由程序調用LoadLibrary(Ex)以及GetProcAddress函數來獲取每個需要使用的函數地址，從而進行dll中的函數調用，這種dll使用方法稱為顯式鏈接。顯式鏈接時不生成對應dll的IAT.

當決定不再使用該dll時，通過調用FreeLibrary來卸載。需要注意的是，同一個進程中共計調用LoadLibrary的次數要和調用FreeLibrary的次數相等，因為系統維護了一個使用計數，當計數為0時，才會真正的卸載該dll.

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

GetProcAddress可以傳遞函數名或者序號(通過MAKEINTRESOURCE(2)來"制作"序號).

­

1.1動態加載DLL文件 LoadLibraryEx

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

PCTSTR pszDLLPathName,

HANDLE hFile,

DWORD dwFlags);

dwFlags 可以有以下幾個值

              (1) DONT_RESOLVE_DLL_REFERENCES

                                    建議永遠不要使有這個值，它的存在僅僅是為了向后兼容、

                  更多內容請訪問：http://blogs.msdn.com/oldnewthing/archive/2005/02/14/372266.aspx

              (2) LOAD_LIBRARY_AS_DATAFILE

                  把要加載的DLL文件以數據文件的形式加載到進程中。

                  GetModuleHandle和GetProcAddress返回NULL

              (3) LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE

                  與前者相同，不同的時獨占打開，禁止其它進程訪問和修改該DLL中的內容。

              (4) LOAD_LIBRARY_AS_IMAGE_RESOURCE

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

              (5) LOAD_WITH_ALTERED_SEARCH_PATH

                   修改DLL的加載路徑

1.2 DLL的加載與卸載

    (1)加載

       不要在同一進程中，同時使用LoadLIbrary和LoadLibraryEx加載同一DLL文件。

       DLL的引用計數是以進程為單位的。LoadLibrary會把DLL文件加載到內存，然后映射到進程空間中。

       多次加載同一DLL只會增加引用計數而不會多次映射。當所有進程對DLL的引用計數都為0時，系統會在內存中釋放該DLL。

    (2)卸載

         FreeLibrary,FreeLibraryAndExitThread對當前進程的DLL的引用計數減1

    (3) GetProcAddress

         取得函數地址。它只接受ANSI字符串。

2.DLL的入口函數

      2.1 DllMain

              BOOL WINAPI DllMain(

              HINSTANCE hInstDll, ""加載后在進程中的虛擬地址

              DWORD fdwReason, ""系統因何而調用該函數

              PVOID fImpLoad ""查看是隱工還是動態加載該DLL

    DLLs用DllMain方法來初始化他們自已。DllMain中的代碼應盡量簡單，只做一些簡單的初始化工作。

    不要在DllMain中調用LoadLibrary,FreeLibrary及Shell, ODBC, COM, RPC, 和 socket 函數，從而避免不可預期的錯誤。

  2.2 fdwReason的值

    (1)DLL_PROCESS_ATTACH

      系統在為每個進程第一次加載該DLL時會，執行DLL_PROCESS_ATTACH后面的語句來初始化DLL,DllMain的返回值僅由它決定。

     系統會忽略DLL_THREAD_ATTACH等執行后DllMain的返回值。

     如果DllMain返回FALSE,系統會自動調用DLL_PROCESS_DETACH的代碼并解除DLL文件中進程中的內存映射。        

    (2)DLL_PROCESS_DETACH

        如果DLL是因進程終止而卸載其在進程中的映射，那么負責調用ExitProcess的線程會調用DllMain中DLL_PROCESS_DETACH所對應的代碼。

        如果DLL是因FreeLibrary或FreeLibraryAndExitThread，而卸載其在進程中的映射, 那么FreeLibrary或FreeLibraryAndExitThread會負責調用DllMain中DLL_PROCESS_DETACH所對應的代碼。

        如果DLL是因TerminateProcess而卸載其在進程中的映射,系統不會調用DllMain中DLL_PROCESS_DETACH所對應的代碼。

    (3) DLL_THREAD_ATTACH

        若進程是先加載的DLL,后創建的線程

        那么在進程中創建新線程時(主線程除外)，系統會執行該進程已載的所有DLL的DllMain中DLL_THREAD_ATTACH對應的代碼。

         若進程是先創建的線程,后加載的DLL

         那么系統不會調用DLL的DllMain中的代碼。

     (4) DLL_THREAD_DETACH

         進程中的線程退出時，會先執行所有已加載DLL的DllMain中DLL_THREAD_DETACH所對應的代碼。若該代碼中有死循環，線程不會退出。              

2.3 同步化DllMain的調用

      同一時間只能有一個線程調用DllMain中的代碼，所以下面的代碼會導致死循環

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會DLL_THREAD_ATTACH中的代碼，但是由于當前線程并未執行完畢,

      //所以DLL_THREAD_ATTACH 中的代碼不會被執行，且CreateThread永無不會返回。

      // 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.延時加載DLL

(1)延時加載DLL的限制

         延遲加載的D L L是個隱含鏈接的D L L，它實際上要等到你的代碼試圖引用D L L中包含的一個符號時才進行加載，它與動態加載不同。

        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會先去該位置查找有無相應的鍵值與DLL要對應，若有則根據鏈值去%SystemRoot%"System32加載鍵值對應的DLL

    若無則根據默認規去尋找DLL

5.Bind and Rebase Module

    它可以程序啟動的速度。ReBaseImage

­

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

1.概覽

  每個進程都有自已獨立的地址空間，一個進程不可能創建一個指向其它進程地址空間的指針。

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

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

2.用注冊表注入DLL

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

     所有的GUI應用程序在啟動時都會加載User32.dll，而在User32.dll的DLL_PROCESS_ATTACH代碼根據注冊表中的信息

來注入用戶指定的DLL

注冊表項　HKEY_LOCAL_MACHINE"Software"Microsoft"Windows NT"CurrentVersion"Windows"

中有兩個值：

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

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

    注:

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

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

一.注入dll

1.通過注冊表項 HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs 來指定你的dll的路徑，那么當一個GUI程序啟動時就要加載User32.dll,而User32.dll將會檢查這個值，如果有的話就LoadLibrary該Dll。這個方法不好，因為大多數情況我們只需要針對性的注入，并且沒辦法注入到不使用User32.dll的進程中；

­

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

­

3.使用遠程線程注入Dll(Injecting a DLL Using Remote Threads)

這個方法比較好。流程是這樣的:

?調用VirtualAllocEx，在目標進程保留一塊內存，并提交，其長度是你要注入Dll的全路徑長度nLen + 1，返回地址pv;

?調用WriteProcessMemory，在目標進程的pv處寫入Dll的全路徑，注意要添加\0結束符;

?獲取本進程的LoadLibrary函數的地址，方法是調用pfn = GetProcAddress(GetModuleHandle(TEXT("Kernel32")), "LoadLibraryA")——之所以獲取本進程的地址，是因為kernel32.dll在每個進程的映射地址都相同，倘若不同，那么此方法則無效;

?調用HANDLE hThread = CreateRemoteThread(hProcessRemote, NULL, 0,  pfn, pv, 0, NULL)來創建遠程線程，其實這個線程函數就是LoadLibrary函數，因此將執行映射Dll到目標進程的操作;

?調用VirtuallFreeEx(hProcessRemote, pv)釋放提交的內存;

這便完成了dll注入。

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

­

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

其實就是替換某個目標進程要加載的a.dll，并把a.dll的所有引出函數用函數轉發器在自己的dll引出。

­

5.用調試函數插入Dll

ReadProcessMemory和WriteProcessMemory是windows提供的調試函數。如果在方法3中調用WriteProcessMemory寫入的不是字串而是精心編排好的機器指令，并且寫在目標進程特定的地址空間，那么這段機器指令就有機會執行——而這段機器指令恰好完成了LoadLibrary功能;

­

6.其他方法（略）

­

二.掛接API(API Hooking)

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

所謂掛接API就是在目標進程調用windows API之前，先執行我們的仿API函數，從而控制系統API的行為，達到特殊的目的。

我們的仿造函數必須與要替換的系統API有相同的型參表以及相同的返回值類型.

­

1.改寫系統API代碼的前幾個字節，通過寫入jmp指令來跳轉到我們的函數。在我們的函數里執行操作，可以直接返回一個值，也可以將系統API的前幾個字節復原，調用系統API，并返回系統API的值——隨便你想怎么做。

此方法的缺點是對于搶占式多線程的系統不太管用。

­

2.通過改寫目標進程IAT中要調用的函數地址來達到目的。具體操作見書中示例

­

­

­

線程本地存儲(Thread-Local Storage)

例子C / C + +運行期庫要使用線程本地存儲器（ T L S）。由于運行期庫是在多線程應用程序出現前的許多年設計的，因此運行期庫中的大多數函數是用于單線程應用程序的。函數s t r t o k就是個很好的例子。

盡可能避免使用全局變量和靜態變量

1.動態TLS

圖21-1 用于管理T L S的內部數據結構

­

在創建線程時，進程會為當前創建的線程分配一個void *的數組作為TLS用。它用于存儲只限當前線程可見的全局變量。

從而使進程中的每個線程都可以有自已的(不能其它線程訪問的)全局變量。

TlsAlloc在返回時會先把槽中的值置為0。每個線程至少有64個槽。

2.靜態TLS

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

              要求聲明的變量必須是全局變量或靜態變量。

3.Common API:

              TlsAlloc   TlsFree

              TlsSetValue   TlsGetValue

              __declspec(thread)

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