转载（不要一辈子靠技术生存）

posted @ 2013-04-14 22:27 深邃者 阅读(416) | 评论 (1) | 编辑 收藏

五种程序设计方法

posted @ 2010-09-16 14:45 深邃者 阅读(254) | 评论 (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 深邃者 阅读(282) | 评论 (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 深邃者 阅读(526) | 评论 (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 深邃者 阅读(484) | 评论 (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 深邃者 阅读(200) | 评论 (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 深邃者 阅读(386) | 评论 (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 深邃者 阅读(394) | 评论 (0) | 编辑 收藏

Debug 和 Release

posted @ 2009-11-21 22:39 深邃者 阅读(257) | 评论 (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 深邃者 阅读(983) | 评论 (0) | 编辑 收藏