Inline HOOK API 改进版（hot-patching）

记得在之前写过一篇hook api的文章（C/C++ HOOK API（原理深入剖析之-LoadLibraryA）），那篇文章主要原理是构造一块代码字节，将LoadLibraryA函数的前面16个字节给修改，然后跳转到自定义的函数中。要调用正常的函数时，又将其unHook，这样一来再一次调用中，有一次unhook和一次hook，操作显得过于频繁。而且hook与unhook当时设计成了thiscall，因此维护传递this的寄存器（通常是ecx）就成了必然，再加上参数的传递，__Inline_Hook_Func函数的逻辑就显得有点复杂和臃肿。

 

就以上情况，本文打算较之前的逻辑做个改进，抛弃掉this和参数的维护，利用windows为多数API预留的前五个字节的nop空间和mov edi, edi占用的两个字节来实现inline hook。即所谓的hot-patching技术，运行时修改函数的行为，同时不破坏函数的主体逻辑，因此免去了hook与unhook不断切换，在线程安全上也有很好的效果。

 

本文还是以LoadLibraryA函数为例，先看LoadLibraryA的反汇编：

7602285F  nop             
76022860  nop             
76022861  nop             
76022862  nop             
76022863  nop             
76022864  mov         edi,edi
76022866  push        ebp 
76022867  mov         ebp,esp
76022869  cmp         dword ptr [ebp+8],0
7602286D  push        ebx 
7602286E  push        esi 
7602286F  push        edi 
76022870  je          7602288A
76022872  push        760228A0h
76022877  push        dword ptr [ebp+8]
7602287A  call        dword ptr ds:[75FD12E4h]
76022880  pop         ecx 
76022881  pop         ecx 
76022882  test        eax,eax
76022884  je          7603F39F
7602288A  push        0   
7602288C  push        0   
7602288E  push        dword ptr [ebp+8]
76022891  call        76022859
76022896  pop         edi 
76022897  pop         esi 
76022898  pop         ebx 
76022899  pop         ebp 
7602289A  ret         4  

 

如上，前面红色的部分即是可以灵活操作的部分，mov edi,edi两个字节可以替换成一个short jmp，5个nop字节可以替换成一个长跳。

蓝色的0x76022864地址是LoadLibraryA的入口，如果将这里改成short jmp后，要调用正常的LoadLibraryA，则只需要在此基础上加2个字节的偏移进行call即可。清楚了原理，先动手吧，用C++实现，先写一个类。

class InlineHookHolder { public: class _ReadWriteVPHolder { public: _ReadWriteVPHolder( void* addr, DWORD size ) : pAddr( addr ), dwSize( size ) { VirtualProtect( pAddr, dwSize, PAGE_EXECUTE_READWRITE, &dwFlag ); } ~_ReadWriteVPHolder( void ) { VirtualProtect( pAddr, dwSize, dwFlag, &dwFlag ); } private: void* pAddr; DWORD dwFlag; DWORD dwSize; }; InlineHookHolder( int dst_jmp_func, int src_hook_func ) : pSrcFunc( ( BYTE* )src_hook_func - 5 ) { // raii vp Holder _ReadWriteVPHolder holder( pSrcFunc, 7 ); // jmp offset, contain 5 byte of itself ( int& )pSrcFunc[1] = ( int )dst_jmp_func - ( int )pSrcFunc - 5; pSrcFunc[ 0 ] = 0xE9; // far jmp // mov edi, edi pSrcFunc[ 5 ] = 0xEB; // short jmp pSrcFunc[ 6 ] = 0xF9; // short jmp offset: -7 } ~InlineHookHolder( void ) { // raii vp holder _ReadWriteVPHolder holder( pSrcFunc, 7 ); // 5 nop memset( pSrcFunc, 0x90, 5 ); // unhook mov edi, edi pSrcFunc[ 5 ] = 0x8B; pSrcFunc[ 6 ] = 0xFF; } private: BYTE* pSrcFunc; };

 

这个InlineHookHolder构造时，便将目标函数进行hook操作，这个操作将mov edi,edi替换成jmp XX，这里是相对偏移，偏移量为7字节（5个nop字节加上本身2个字节），所以有：
pSrcFunc[ 5 ]       = 0xEB;     // short jmp
pSrcFunc[ 6 ]       = 0xF9;     // short jmp offset: -7

0xEB即是short jmp的机器码，0xF9即偏移，这里是负数，向前偏移7个字节。

 

至于5个nop即替换成了jmp 0x???????。因此有：

( int& )pSrcFunc[1] = ( int )dst_jmp_func - ( int )pSrcFunc - 5; // 跳转的偏移，目标地址与当前地址的差值+jmp本身的5个字节
pSrcFunc[ 0 ]       = 0xE9;   // 长jmp 的机器码

 

在构造函数修改之后，析构函数负责unhook，在其间的过程中都不需要操作。

写好了类，然后再写跳转到的自定义函数，代码如下：

 typedef WINBASEAPI HMODULE ( WINAPI *PLOADLIBA )( LPCSTR lpFileName ); typedef WINBASEAPI HMODULE ( WINAPI *PLOADLIBW )( LPCWSTR lpFileName ); #define LOADER_CAST( T, ptr ) reinterpret_cast< T >( ( ( int )ptr ) + 2 ); #define WINAPI_FUNC( _ret, _name ) _ret WINAPI _name #define DECLARE_HOOK_HOLDER( _T, holder, jmp_, src_ ) / _T jmp_##holder( ( int )jmp_, ( int )src_ ); WINAPI_FUNC( HMODULE, MyLoadLibraryA )( LPCSTR lpFileName ) { if ( lpFileName == NULL ) return NULL; PLOADLIBA pLoader = LOADER_CAST( PLOADLIBA, LoadLibraryA ); HMODULE hMod = pLoader( lpFileName ); // code.... return hMod; }

 

如上面代码，LOADER_CAST宏用于将API的入口地址加上2，避免又跳转到自定义hook函数里面了。

 

由于LoadLibraryA是__stdcall(WINAPI宏)，会在内部ret时保持堆栈平衡，因此我们自定义的函数也保持这个规则，不然会导致堆栈不平衡。WINAPI_FUNC宏就是为了遵循这个规则而定义的，免得粗心忘了加__stdcall了。

 

DECLARE_HOOK_HOLDER宏是声明定义一个InlineHookHolder对象，将原函数和目标函数传入构造函数进行hook操作。我们可以将这个对象声明成全局的，这样在程序退出时调用析构进行unhook，_ReadWriteVPHolder类也是为了RAII的机制。

 

最后调用代码可以简单如下：

DECLARE_HOOK_HOLDER( InlineHookHolder, _inline_hook_a, MyLoadLibraryA, LoadLibraryA ); int main( void ) { LoadLibraryA( "d3d9.dll" ); // 假如load这个dll return 0; }

 

当然在MyLoadLibraryA里就可以做一些我们想做的事情了，比如检测你加载的DLL是否合法等，这对于比较简单的游戏反外挂上有一定的作用。本文就只抛砖引玉介绍下原理吧。

 

 

与之前的版本比较，这种方法只能应用于预留了5个nop和mov edi,edi这7个字节的API函数，不建议强制使用这种方式，视情况而定。再者，在本文中没有涉及手工编写内嵌汇编代码，逻辑简单且更清晰，在效率上也较高一些，安全性方面也要好一些。不过之前的方法对于追究堆栈调用模型很有好处。

 

本文原理比较简单，就先介绍到此，欢迎大牛拍砖。