API hook 原理与Windows hook 应用
CSDN 上图片很麻烦，请到百度文库直接看Word 文档，图片比这个全http://wenku.baidu.com/view/0946ce1155270722192ef74f.html
Hook 字面的意思是钩子，但是实际上更像提供一种过滤，或者说修改消息处理，或者API的机制。
API hook
什么是API的hook呢，其实就是将API调用的地方进行了转移，或者重新实现的一种技术。这种技术不仅仅可以用在windows 上，其他OS上一样可以使用，我曾经在brew mp 上的手机开发上测试过API hook。所以这里主要只讲windows 下的API hook。 API的hook 基本思路都是想办法替换原来的API，使函数的调用关系，直接进行转换， 典型的如下
可以看到client 端要调用的FunctionA，在A进入之后，就调用了FunctionB , 在Function B 中回到FunctionA 做具体A应该做的事情，从A返回之后，FunctionB 然后在返回给Client，那么在FunctionB 中使用FunctionA的前后，它自己都可以干自己想要干的事情，这样就是一个API的hook, 下面我们主要讨论Windows 上最常用的两种API hook 策略。
A）IAT 替换API hook
所谓的IAT (import address table ) 这个是PE文件中一个重要的部分，这里我们不详细讨论PE文件的构成，因为这个本来就可以写一张内容。我们主要了解的是PE如何在一个已经加载在内存中的PE文件如何找到它的IAT。
（1） 为什么要找IAT？
一个模块，可能依赖别的API，也可能提供API，供别的模块调用，MS为了在PE文件中，分别用导入表和导出表进行描述两种关系。导入表IAT 主要是描述了这个模块依赖那些其他模块提供的API。 而导出表EAT 是描述这个模块中都提供那些函数供别的模块调用。如果我们在某个模块的导入表中替换它所依赖的函数，那么这样就可以实现API hook.
（2） 如何找IAT？
要找IAT 要稍微了解一下PE文件的结构，
一个PE 文件的大概长相就是这样，我们要找的IAT，就是要先找到PE文件可选头，在这个数据结构中，描述了IAT 描述的位置在那里，然后给距IAT descriptor 就可以找到IAT了。
BOOL TestFunctionInIAT( HMODULE hModule, ULONG FunctionAddress )
{
BOOL bReturn = FALSE;
unsigned char *pBaseAddr = reinterpret_cast(hModule);
// 获取DOS header 的位置
PIMAGE_DOS_HEADER pDosHeader = reinterpret_cast(pBaseAddr);
// 获取NTImage header 的位置
PIMAGE_NT_HEADERS pNtHeader = reinterpret_cast(
pBaseAddr + pDosHeader->e_lfanew );
// 获取 PE option header的位置
PIMAGE_OPTIONAL_HEADER pPEOptionHeader = &pNtHeader->OptionalHeader;
// 获取导入表的目录结构
PIMAGE_DATA_DIRECTORY pIATDataDirectory = &(pPEOptionHeader->DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT]);
// 获取导入表 descriptor
PIMAGE_IMPORT_DESCRIPTOR pImportDescriptor = reinterpret_cast(
pBaseAddr + pIATDataDirectory->VirtualAddress );
// 从pImportDescriptor 开始是一堆导入表，一张接着一张，直到
// 导入表的名字为空为止，其实就是对应Windows 的一个dll，有几张表，就表示
// 该模块依赖几个dll 的导出函数, Name 字段是dll的名称的相对虚拟地址
while ( pImportDescriptor->Name != 0 )
{
// thunk data 就是表示导入dll 中函数描述
PIMAGE_THUNK_DATA pThunkData = reinterpret_cast(
pBaseAddr + pImportDescriptor->FirstThunk);
while( pThunkData->u1.Function != 0 )
{
ULONG *ppfn = ( ULONG *)&pThunkData->u1.Function;
if ( *ppfn == FunctionAddress )
{
bReturn = TRUE;
break;
}
++pThunkData;
}
++pImportDescriptor;
}
return bReturn;
}
PROC g_CreateFunc = NULL;
typedef BOOL (WINAPI *PCreateProcessW)(
__in_opt LPCWSTR lpApplicationName,
__inout_opt LPWSTR lpCommandLine,
__in_opt LPSECURITY_ATTRIBUTES lpProcessAttributes,
__in_opt LPSECURITY_ATTRIBUTES lpThreadAttributes,
__in BOOL bInheritHandles,
__in DWORD dwCreationFlags,
__in_opt LPVOID lpEnvironment,
__in_opt LPCWSTR lpCurrentDirectory,
__in LPSTARTUPINFOW lpStartupInfo,
__out LPPROCESS_INFORMATION lpProcessInformation);
BOOL WINAPI MyCreateProcessW(
__in_opt LPCWSTR lpApplicationName,
__inout_opt LPWSTR lpCommandLine,
__in_opt LPSECURITY_ATTRIBUTES lpProcessAttributes,
__in_opt LPSECURITY_ATTRIBUTES lpThreadAttributes,
__in BOOL bInheritHandles,
__in DWORD dwCreationFlags,
__in_opt LPVOID lpEnvironment,
__in_opt LPCWSTR lpCurrentDirectory,
__in LPSTARTUPINFOW lpStartupInfo,
__out LPPROCESS_INFORMATION lpProcessInformation)
{
MessageBoxW(NULL, lpCommandLine, L"CreateProcessW", MB_OK);
return ((PCreateProcessW)g_CreateFunc)(
lpApplicationName,
lpCommandLine,
lpProcessAttributes,
lpThreadAttributes,
bInheritHandles,
dwCreationFlags,
lpEnvironment,
lpCurrentDirectory,
lpStartupInfo,
lpProcessInformation);
}
int _tmain(int argc, _TCHAR* argv[])
{
HMODULE hModule = NULL;
GetModuleHandleEx(
GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS,
(LPCTSTR)TestFunctionInIAT,
&hModule);
BOOL bReturn = TestFunctionInIAT( hModule , (ULONG_PTR)CreateProcessW );
if ( bReturn )
{
printf("Found address CreateProcessW!\n");
}
else
{
printf("found failed!\n");
}
g_CreateFunc = install_api_hook(hModule, "kernel32.dll", (PROC)CreateProcessW, (PROC)MyCreateProcessW);
wchar_t szProcessName[] = L"notepad.exe";
STARTUPINFO si = {sizeof(si)};
PROCESS_INFORMATION pi;
CreateProcessW(NULL,
szProcessName,
NULL,
NULL,
FALSE,
0,
NULL,
NULL,
&si,
&pi);
return 0;
}
PROC install_api_hook(
HMODULE hHookModule,
const char * szDllName,
PROC pfnHookFunAddr,
PROC pfnNewFundAddr
)
{
PROC pOrigFunc = NULL;
unsigned char *pBaseAddr =
reinterpret_cast(hHookModule);
PIMAGE_DOS_HEADER pDosHeader =
reinterpret_cast(pBaseAddr);
PIMAGE_NT_HEADERS pNtHeader =
reinterpret_cast(
pBaseAddr + pDosHeader->e_lfanew );
PIMAGE_OPTIONAL_HEADER pPEOptionHeader =
&pNtHeader->OptionalHeader;
PIMAGE_DATA_DIRECTORY pIATDataDirectory =
&(pPEOptionHeader->DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT]);
PIMAGE_IMPORT_DESCRIPTOR pImportDescriptor =
reinterpret_cast(
pBaseAddr + pIATDataDirectory->VirtualAddress );
for ( ; pImportDescriptor->Name; pImportDescriptor++ )
{
const char* pszModName =
reinterpret_cast(
pBaseAddr + pImportDescriptor->Name);
if ( 0 == lstrcmpiA( pszModName, szDllName ) )
{
break;
}
}
if ( 0 == pImportDescriptor->Name )
{
return pOrigFunc;
}
PIMAGE_THUNK_DATA pThunkData =
reinterpret_cast(
pBaseAddr + pImportDescriptor->FirstThunk);
while( pThunkData->u1.Function != 0 )
{
PROC *ppFunc = reinterpret_cast(
&pThunkData->u1.Function);
if ( *ppFunc == pfnHookFunAddr )
{
DWORD dwOldProtect = 0;
VirtualProtect( ppFunc, sizeof(PROC), PAGE_READWRITE, &dwOldProtect );
pOrigFunc = *ppFunc;
CopyMemory(ppFunc, &pfnNewFundAddr, sizeof(PROC));
// SIZE_T stMemorySize = 0;
// WriteProcessMemory(
// GetCurrentProcess(),
// ppFunc,
// &uNewFundAddr,
// sizeof(*ppFunc),
// &stMemorySize);
VirtualProtect( ppFunc, sizeof(PROC), dwOldProtect, 0 );
break;
}
}
return pOrigFunc;
} 另外要获得导入表描述符，只要使用这个API ImageDirectoryEntryToData 就可以了，
但是这个API是有依赖的。我们使用Dumpbin，或者TC 都可以看到这个exe 确实使用kernel32 dll, 所以，我们下一步要替换我们的自己MyCreateProcessW. 将上面函数稍微优化一下，修改一下，就可以了，
然后在看这样的使用，那么一定会在CreateProcess 的时候，先弹出一个对话框，这样，就是我们的效果。
B）JMP 指令替换
现在你在网上搜索一下，说JMP指令替换的，一般都说保存函数入口处5个字节，其实这是相对地址跳转，当然了，如果使用了绝对跳转，那么就不至5个字节了，如果使用相对短地址跳转，当然少于5个字节，这个部分可以参看80x86 汇编instruction set, operator code.
这里我们也采用相对地址跳转，但是最后会说明如何用短跳转实现API hook, 因为这个很有用。至于是什么跳转，主要是他们跳转地址范围不同。相对地址跳转-2G到2G。
跳转的hook 的原理
第一种， 就是进入FunctionA 就跳转到FunctionB，做完B应该做的事情之后，将FunctionA的入口处的JMP去掉，回复到FunctionA原来的样子。 然后在Function B 中调用FunctionA，
当然这个地方你也可以不调用，根据你的功能决定， 然后再在FunctionA的入口布置JMP指令。 最后就是返回Caller。
我们看看如何实现, 这里补充一下，如何计算JMP指令后的operand. 就是跳转的相对地址。
Label1:
Mov EAX, EAX
Mov Edi, edi
...............................
Label2:
JMP Label1
Label3:
XOR EcX, EcX
那么如果是相对地址跳转JMP label1 汇编机器指令的以后，label1 这个位置的值是多少呢，因为只有知道这个如何计算，那么我们就知道怎么hardcode JMP 指令。因为计算机当执行
JMP Label1 的时候，地址译码机构已经完成了这条指令的译码，并将其送到了可执行单元，在可执行单元还没有开始执行的时候，地址译码机构不能闲着，已经将地址Label3已经装载到EIP中，当可执行单元进行执行JMP Label1的时候，其实是将EIP + JMP 指令operand 合成出来的，那么就有了下面的等式：
Label1 = EIP + operand;
EIP 等于label3 那么
label1= Lebel3+ operand,
那么
operand = Label1 - Label3.
这个是关键。
通常我们是不知道label3 的地址的，但是我们一定能知道lable2 的地址，这个地方就是我们要放JMP 指令的位置，如果我们放相对跳转的JMP 指令，该指令占用5个byte. 那么label3 就可以通过lable2 + JMP 指令的长度 计算出来。
// JmpHook.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include
unsigned char g_StubCode[6] = {0x0};
PROC g_CreateFunc = 0;
void restore_hook(PROC pfnOrigAddr);
void set_hook(PROC pfnOrigAddr, PROC pfnNewAddr );
typedef BOOL (WINAPI *PCreateProcessW)(
__in_opt LPCWSTR lpApplicationName,
__inout_opt LPWSTR lpCommandLine,
__in_opt LPSECURITY_ATTRIBUTES lpProcessAttributes,
__in_opt LPSECURITY_ATTRIBUTES lpThreadAttributes,
__in BOOL bInheritHandles,
__in DWORD dwCreationFlags,
__in_opt LPVOID lpEnvironment,
__in_opt LPCWSTR lpCurrentDirectory,
__in LPSTARTUPINFOW lpStartupInfo,
__out LPPROCESS_INFORMATION lpProcessInformation);
BOOL WINAPI MyCreateProcessW1(
__in_opt LPCWSTR lpApplicationName,
__inout_opt LPWSTR lpCommandLine,
__in_opt LPSECURITY_ATTRIBUTES lpProcessAttributes,
__in_opt LPSECURITY_ATTRIBUTES lpThreadAttributes,
__in BOOL bInheritHandles,
__in DWORD dwCreationFlags,
__in_opt LPVOID lpEnvironment,
__in_opt LPCWSTR lpCurrentDirectory,
__in LPSTARTUPINFOW lpStartupInfo,
__out LPPROCESS_INFORMATION lpProcessInformation)
{
restore_hook(g_CreateFunc);
MessageBoxW(NULL, lpCommandLine, L"CreateProcessW", MB_OK);
BOOL bRetCode = ((PCreateProcessW)g_CreateFunc)(
lpApplicationName,
lpCommandLine,
lpProcessAttributes,
lpThreadAttributes,
bInheritHandles,
dwCreationFlags,
lpEnvironment,
lpCurrentDirectory,
lpStartupInfo,
lpProcessInformation);
set_hook(g_CreateFunc, (PROC)MyCreateProcessW1);
return bRetCode;
}
void set_hook(PROC pfnOrigAddr, PROC pfnNewAddr )
{
unsigned char *pSrcAddr =
reinterpret_cast( pfnOrigAddr );
unsigned char *pDestAddr =
reinterpret_cast( pfnNewAddr );
ULONG uOperand = static_cast
( pDestAddr - (pSrcAddr + 5) );
CopyMemory(g_StubCode, pSrcAddr, 5);
DWORD dwOldProtect = 0;
VirtualProtect( pSrcAddr, 5, PAGE_READWRITE, &dwOldProtect );
unsigned char szJMPCode[5] = {0xE9};
CopyMemory(&szJMPCode[1], &uOperand, 4);
CopyMemory(pSrcAddr, szJMPCode, 5 );
VirtualProtect( pSrcAddr, 5, dwOldProtect, NULL );
}
void restore_hook(PROC pfnOrigAddr)
{
unsigned char *pSrcAddr =
reinterpret_cast( pfnOrigAddr );
DWORD dwOldProtect = 0;
VirtualProtect( pSrcAddr, 5, PAGE_READWRITE, &dwOldProtect );
CopyMemory(pSrcAddr, g_StubCode, 5);
VirtualProtect( pSrcAddr, 5, dwOldProtect, NULL );
}
int _tmain(int argc, _TCHAR* argv[])
{
g_CreateFunc = GetProcAddress(GetModuleHandle(L"kernel32.dll"),"CreateProcessW");
set_hook(g_CreateFunc, (PROC)MyCreateProcessW1);
wchar_t szProcessName[] = L"notepad.exe";
STARTUPINFO si = {sizeof(si)};
PROCESS_INFORMATION pi;
CreateProcessW(NULL,
szProcessName,
NULL,
NULL,
FALSE,
0,
NULL,
NULL,
&si,
&pi);
return 0;
}
基本上就是这个样子了，但是这个有一个致命的缺点，就是如果是多线程，那么可能hook 不到，怎么回事呢？我淫荡的笑，哈哈.........................
那么第二种JMP hook 技术就出来。
首先和第一种一样都有一个g_StubCode，而这个大小已经变大了，不再是5个Byte， 为什么呢，就是hook 完毕之后，就不但算在恢复原来函数的入口的字节了，等跳转到我们自己函数中，做完要做的事情，然后通过stubCode 在返回原来的函数，这样说明了一个问题，就是这样hook 只能在原来函数之前做事，之后，就不能做事了，只能直接返回，当然有没有可能还能做事情呢，能，怎么办，有点复杂。 这里我们先讨论，简单这种。
1. 替换原来函数如果处若干个字节，但是必须大于要放JMP指令字节数，那么这个若干是多少呢？因为相对地址JMP，是5个字节，原函数入口处5个字节正好是完整指令，那么没有问题，如果5个自己不是完整指令，那么这样将一个指令劈成两半的做法是不是很不道德呢。所以这里应该使用反汇编的手法识别出完成指令，且这些指令的长度是大于JMP指令长度的最小值。
2. 将识别出的完整指令备份到stubCode, 然后将原来函数入口处写入JMP指令。
3. 在stubcode 尾部也加入JMP指令，这个JmP指令跳转到原来函数备份到stubCode 中的下一条指令，这样就可以无缝连接在一起了，哈哈，我淫荡的笑啊，我淫荡的笑。。。。。
4. 在新函数的结束的地方将stubCode 强转为该类型的函数指针，调用返回。
上代码：
#include "sethook.h"
#include "disasm.h"
BOOL InstallHook (HOOK_DATA *pHook)
{
ULONG dwJmpDst = 0;
int nInstSize = 0;
int nInstSizeIfMoved = 0;
int nLoop = 0;
BOOLEAN bRetCode = FALSE;
pHook->nHeadSize = 0;
pHook->nStubSize = 5; // == sizeof(JMP rel32)
while (pHook->nHeadSize < 5) // need at least 5 char to path
{
bRetCode = Dasm_GetInstructionSize(pHook->pTargetFunc + pHook->nHeadSize, &nInstSize, &nInstSizeIfMoved);
if (bRetCode == FALSE)
{
return FALSE;
}
pHook->nHeadSize += nInstSize;
pHook->nStubSize += nInstSizeIfMoved;
if (pHook->nStubSize >= MAX_STUB_SIZE)
{
return FALSE;
}
}
memcpy(pHook->pHead, pHook->pTargetFunc, pHook->nHeadSize);
// create stub
bRetCode = Dasm_MoveProgram(pHook->pTargetFunc, pHook->nHeadSize, pHook->pStub, &pHook->nStubSize, MAX_STUB_SIZE);
if (bRetCode == FALSE)
{
return FALSE;
}
if ( (UCHAR)pHook->pTargetFunc[0] == 0xE9)
{
ULONG ulDstAddr = (ULONG)pHook->pTargetFunc + 5 + *(PULONG)(pHook->pTargetFunc + 1);
ULONG ulSrcAddr = (ULONG)pHook->pStub + 5;
dwJmpDst = ulDstAddr - ulSrcAddr;
pHook->pStub[0] = 0xE9;
memcpy(&pHook->pStub[1], &dwJmpDst, 4);
}
// add jmp at the end of the stub
dwJmpDst = (ULONG)pHook->pTargetFunc - (ULONG)pHook->pStub - pHook->nStubSize;
pHook->pStub[pHook->nStubSize] = 0xE9; // JMP rel32
memcpy(&pHook->pStub[pHook->nStubSize+1], &dwJmpDst, 4);
pHook->nStubSize += 5;
DWORD dwOldProtect = 0;
VirtualProtect(pHook->pTargetFunc, pHook->nHeadSize, PAGE_EXECUTE_READWRITE, &dwOldProtect);
pHook->pTargetFunc[0] = 0xE9; // JMP rel32
dwJmpDst = (ULONG)pHook->pHookFunc - (ULONG)pHook->pTargetFunc - 5; // 5==sizeof(JMP rel32)
memcpy(pHook->pTargetFunc + 1, &dwJmpDst, 4);
for (nLoop = 5; nLoop < pHook->nHeadSize; nLoop ++)
pHook->pTargetFunc[nLoop] = 0x90; // NOP
return TRUE;
}int WINAPI MyMessageBoxW(HWND hWnd, LPCWSTR lpText, LPCWSTR lpCaption, UINT uiType)
{
return ((pMessageBoxW)&g_pData->pStub)(
hWnd,
lpText,
lpCaption,
uiType);
return 0;
}
BOOL WINAPI MyCreateProcessW( __in_opt LPCWSTR lpApplicationName,
__inout_opt LPWSTR lpCommandLine,
__in_opt LPSECURITY_ATTRIBUTES lpProcessAttributes,
__in_opt LPSECURITY_ATTRIBUTES lpThreadAttributes,
__in BOOL bInheritHandles,
__in DWORD dwCreationFlags,
__in_opt LPVOID lpEnvironment,
__in_opt LPCWSTR lpCurrentDirectory,
__in LPSTARTUPINFOW lpStartupInfo,
__out LPPROCESS_INFORMATION lpProcessInformation )
{
return ((PCreateProcessW)(&g_pData->pStub))( lpApplicationName,
lpCommandLine,
lpProcessAttributes,
lpThreadAttributes,
bInheritHandles,
dwCreationFlags,
lpEnvironment,
lpCurrentDirectory,
lpStartupInfo,
lpProcessInformation);
}
int _tmain(int argc, _TCHAR* argv[])
{
PCreateProcessW pOrigMBAddress = (PCreateProcessW)GetProcAddress( GetModuleHandle(_T("kernelbase.dll")), "CreateProcessW" );
//BeginRedirect(MyMessageBoxW);
HOOK_DATA *pData = new HOOK_DATA;
g_pData = pData;
pData->pTargetFunc = (PUCHAR)pOrigMBAddress;
pData->pHookFunc = (PUCHAR)MyCreateProcessW;
//InstallHook( pData );
TCHAR szProcessNAme[60] = L"notepad.exe";
STARTUPINFOW info = { sizeof(info)};
PROCESS_INFORMATION Pi = {0};
CreateProcessW( NULL,
szProcessNAme,
NULL,
NULL,
FALSE,
0,
NULL,
NULL,
&info,
&Pi);
return 0;
}可以明显的看到，这样hook 的优势所在. API hook 基本就是这样了，JMP short 的这种怎么实现的，一般我们要看看windows API 的函数汇编，
0x74cd43AB 是CreateProcessW 的地址，这个函数进来的第一件事，就是mov edi, edi 这条指令看起来很蛋疼，但是这个蛋疼的指令，却有着很牛叉的意义，另外MS的所有API都是这样的，这个是一个公开的秘密，在这里放一个JmP short , 那么这个JMP short 跳转的是-127 ~ 127 那么我们怎么可能将函数放到MS API的位置呢，看到函数上面的5个nop 了，
这个5个字节，怎么这么适合放相对地址JMP far, 我淫荡的笑啊.... 剩下的和我们刚才的一样啦，这个技术就是MS在放补丁时候，hot fix 就是这样的。MS都在用，你就放心的用吧，要死大家一起死。
API hook 在本进程中，无非就是兀自手淫，没有什么大意义，那么如何才能将API hook 放到别人的进程中，我们这里讨论两种技术，第一种CreateRomoteThread, 第二种Windows hook,.
1 CreateRomoteThread
用法很简单，
1. 准备一个dll, 在DllMain中的 DLL_PROCESS_ATTACH 中，进行sethook 调用，那么就是可以hook 本进程了。
2. 将这个dll 放到要hook 的进程中去
void Inject(LPCTSTR lpszDllPath, DWORD dwProcessID )
{
HANDLE hProcess = OpenProcess( PROCESS_ALL_ACCESS, FALSE, dwProcessID );
if ( hProcess != NULL )
{
LPVOID pAddr = VirtualAllocEx(
hProcess,
NULL,
(_tcslen(lpszDllPath) + 1) * sizeof(*lpszDllPath),
MEM_COMMIT | MEM_RESERVE,
PAGE_EXECUTE_READWRITE);
if ( pAddr != NULL )
{
SIZE_T uSize = 0;
WriteProcessMemory(
hProcess,
pAddr,
lpszDllPath,
(_tcslen(lpszDllPath) + 1) * sizeof(*lpszDllPath),
&uSize);
HANDLE hThread = CreateRemoteThread( hProcess, NULL, 0, (LPTHREAD_START_ROUTINE)LoadLibraryW, pAddr, 0, 0 );
CloseHandle( hThread );
}
}
}
但是常常因为你没有足够的权限而失败，那么Windows hook 技术就可以帮助到我们了。
Windows hook 技术
大家可以看看http://en.wikipedia.org/wiki/Hooking 对hook 的一种通用解释，
Windows 上主要使用SetWindowsHookEx 或者不带EX的函数，首先我们看看
HHOOK WINAPI SetWindowsHookEx(
__in int idHook,
__in HOOKPROC lpfn,
__in HINSTANCE hMod,
__in DWORD dwThreadId
);
这个API的用法，idHook 表示你要hook 那种事件，如键盘，消息，等，
Lpfn 表示hook 处理函数
Hmod 模块句柄，这个就是dll 的句柄
dwThreadId 表示要hook 那个线程的，如果是0， the hook procedure is associated with all existing threads running in the same desktop as the calling thread. 就是说当前桌面的所有线程都会加载到这个dll. 厉害了吧，我淫荡的笑。。。。。。。。。。。。。
SetWindowsHookEx 一般成功了返回了hook 的句柄，但是这个句柄要在hook 的处理函数中使用，我们不是说，将hook 处理函数写在dll 中，那么dll 的在A进程调用了SetWindowsHookEx ，那么dll 映射到B进程中，可是hook 句柄在A进程中，那么B中的hook 处理函数，如何才能使用这个hook 句柄呢？当然进程通信的方式很多，这里使用一种比较简单的策略，就是dll 中增加一个共享数据段。这个共享数据段，就是当dll 映射到不同进程中，每个进程都可以看到这里数据，而且其中一个进程改变这个区域的数据，其他进程也就看到了。
#pragma comment(linker, "/SECTION:.myseg,RWS")
#pragma data_seg (".myseg")
HWND g_Hwnd = NULL;
HHOOK g_HookHandle = NULL;
#pragma data_seg()做个简单解释，dll 中在不同进程可能相同的内容，映射的地址不同，因为不同进程空间，各自不能直接地址访问，dll 的可读部分，进程中其实大家共享一份，只是映射的在virtual address 不同而已，但是将A进程要去写dll 中的数据，那么对不起，这个时候，OS就会重新分一块空间给A就写，A写进去的，就是A的，不会影响到B进程，但是共享数据段，就是所有进程的将使用同一份物理内存，虽然这个空间在不同进程中的地址不同，但是却是同一块物理内存，这样A写了进去，B就可以看到。
哈哈， 有了这样的技术，大家想干什么就干什么了， 你说是不是呢
http://download.csdn.net/detail/zwh37333/4225393
http://download.csdn.net/detail/zwh37333/4225395
上面的位置，是源码。