Well, I'm looking for a Detouring Library that works fine with GunZ. I was actually using CDetour, it works mostly fine, but I found out some incompatibilities with x64, plus, I'm wanting to upgrade to Visual Studio 2008, and CDetour conversion for 2008 is giving me a bunch of errors. I've already tried Micro$oft Detours, but it isn't that good for Gunz. That's it, I would really appreciate all the suggestions. Thanks.
Microsoft Detours 2.0 works fine.
It does, but it crashes sometimes when calling the original function after the detoured one ends. Especially with the ones that has classes and structures as parameters.Originally Posted by PaulBub
Writing your own isn't terribly complicated.
Example.cpp:
Example.h:Code:#include "hiJackr.h" PBYTE _LastFunction; PBYTE _LastHook; DWORD _LastReturnAddress; CRITICAL_SECTION CS; BOOL iCS = FALSE; PBYTE Detour( PBYTE Offset, PBYTE Hook ) { PBYTE _Prologue = new BYTE[_HookLength]; DWORD OldProtect; if( !iCS ) { InitializeCriticalSection( &CS ); iCS = TRUE; } memcpy( _Prologue, &Offset[0], _HookLength ); VirtualProtect( Offset, _HookLength, PAGE_EXECUTE_READWRITE, &OldProtect ); Offset[0] = 0xE8; *( DWORD_PTR * ) ( &Offset[1] ) = ( DWORD_PTR ) ( Hook - Offset ) - _HookLength; VirtualProtect( Offset, _HookLength, OldProtect, &OldProtect ); return( _Prologue ); } void RepairFunction( BYTE *Offset, BYTE *Buffer ) { DWORD OldProtect; VirtualProtect( Offset, _HookLength, PAGE_EXECUTE_READWRITE, &OldProtect ); for( UINT i = 0; i < _HookLength; i++ ) *( ( PBYTE ) Offset + i ) = Buffer[i]; VirtualProtect( Offset, _HookLength, OldProtect, &OldProtect ); } void RepairDetour( ) { Detour( ( PBYTE ) _LastFunction, ( PBYTE ) &_LastHook ); *( ( DWORD_PTR * ) _AddressOfReturnAddress( ) ) = _LastReturnAddress; LeaveCriticalSection( &CS ); }
Terribly organized, but this does serve well as an example.Code:#pragma once #define WIN32_LEAN_AND_MEAN #include <windows.h> #include <intrin.h> #ifndef _M_IX86 #ifndef _M_X64 #error Platform not supported: build for x86 or x86-64 only. #endif #endif #ifdef _M_IX86 #define _HookLength 5 #elif _M_X64 #define _HookLength 9 #endif #define _Prologue( _Prologue ) \ _LastFunction = ( PBYTE ) ( ( DWORD ) _ReturnAddress( ) - _HookLength ); \ RepairFunction( ( PBYTE ) _LastFunction, _Prologue ); #define _Epilogue( this ) \ EnterCriticalSection( &CS ); \ _LastHook = ( PBYTE ) this; \ *( ( DWORD_PTR * ) _AddressOfReturnAddress( ) ) -= _HookLength; \ _LastReturnAddress = ( DWORD ) *( ( ( DWORD_PTR * ) _AddressOfReturnAddress( ) ) \ + 8 / sizeof( DWORD_PTR * ) ); \ *( ( DWORD_PTR * ) _AddressOfReturnAddress( ) + 4 / sizeof( DWORD_PTR * ) ) = ( DWORD_PTR ) RepairDetour; \ return; extern PBYTE _LastFunction; extern PBYTE _LastHook; extern DWORD _LastReturnAddress; extern CRITICAL_SECTION CS; extern BOOL iCS; PBYTE Detour( PBYTE Offset, PBYTE Hook ); void RepairFunction( PBYTE Offset, PBYTE Buffer ); void RepairDetour( );
So, where does it copy the original instructions that the detour jump copies over? That can't be a memcpy...
Code:Offset[0] = 0xE8; *( DWORD_PTR * ) ( &Offset[1] ) = ( DWORD_PTR ) ( Hook - Offset ) - _HookLength;
You missed what I was trying to say. But I now assume this is was never meant to return to the original function.
Oh, yes it does.
Code:#define _Prologue( _Prologue ) \ _LastFunction = ( PBYTE ) ( ( DWORD ) _ReturnAddress( ) - _HookLength ); \ RepairFunction( ( PBYTE ) _LastFunction, _Prologue ); #define _Epilogue( this ) \ EnterCriticalSection( &CS ); \ _LastHook = ( PBYTE ) this; \ *( ( DWORD_PTR * ) _AddressOfReturnAddress( ) ) -= _HookLength; \ _LastReturnAddress = ( DWORD ) *( ( ( DWORD_PTR * ) _AddressOfReturnAddress( ) ) \ + 8 / sizeof( DWORD_PTR * ) ); \ *( ( DWORD_PTR * ) _AddressOfReturnAddress( ) + 4 / sizeof( DWORD_PTR * ) ) = ( DWORD_PTR ) RepairDetour; \ return;
_Epilogue repairs and returns.
Thanks gWX0, I'm gonna take a look at it. Btw someone have any clue about why some detouring libraries fails at returning to the original function when it has classes or structures as parameters?
Last edited by cerealnp; 25-08-09 at 06:29 PM.
Be sure to compile it in release version.
Yeah, that's not the prob, function's declaration looks fine too, that's why I'm asking if there is some kinda bug at the libraries.
Ahhh! I see. So you can't return to the function in the middle of the hook.
Er, the idea is you run _Prologue and _Epilogue to represent the beginning and ending of your hook. _Epilogue returns back to your function.
OK, I get it now.
CDetour does not have any compatibility issues with x64, and in fact it cannot, because x64s run gunz in an x86 emulator
to get CDetour working with 2008, exclude CDetourDis and include detours.h (microsoft detours 1.5) instead
the struct thing is probably caused by not defining the calling convention of your hook functions
and gWX0, your detour library blows
1) Yes, CDetour does have issues with x64, as in it cannot compile for x64 platforms......................
2) On 64-bit platforms, Gunz isn't ran in an "emulator"; though it is running under "emulation mode", using what you could call a pseudo-emulator at best.
3) What..? Remove the proper CDetour definitions and use the Microsoft Detours build? That changes the library entirely, making it a hybrid of MS Detours and CDetour, unless you mean to exclude all CDetour files and just use Microsoft's detours library.
4) Why would that only happen for structures or classes? Calling convention isn't the issue.
5) It works without using a run-length disassembler, which adds forward-compatibility when newer instructions are introduced and used in function prologue code.
EDIT:
Using the example:
Code:#include "example.h" PBYTE MBA_Prologue; void MBA_Hook( ) { _Prologue( MBA_Prologue ); MessageBoxA( 0, "Hooked!", "", MB_OK ); _Epilogue( MBA_Hook ); } int WINAPI WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd ) { MBA_Prologue = Detour( ( PBYTE ) MessageBoxA + 5, ( PBYTE ) &MBA_Hook ); MessageBoxA( 0, "Works fine", "???", MB_OK ); return( 0 ); }
Last edited by Guy; 27-08-09 at 12:52 AM.
CDetourDis = Microsoft Detour File renamed.
If it's just renamed, why would you need to include a different file?
Newer version? I don't know(well care really).
Why would you mix old and new project files? That's like trying to replace a 1964 Mustang's windshield with a 2009 Mustang's windshield; it might work, but the result will be ugly and unsafe.
It won't fit. Don't try it. Besides, the new glass is safer. Unless you compromise the A-pillar of the '64 trying to put in the new glass. Then it's not. Whatever this thread wasn't about cars in the first place ;p
But yes it has been written on Microsoft's detours the whole time as I am aware. The original author of CDetour probably renamed the include file. And I guess it is kind of stupid to recompile it with a new version of Detours which does function differently, as it is likely inefficient.
1) Which makes my point rather clear; in this type of scenario, don't mix new with old, and vice versa.
2) The original author was Lance, and what version of Detours he used, I'm not sure of. Regardless, refer to #1's point.
wat? you shouldn't be trying to compile it FOR x64, not only would that fail horribly, only x64 users would be able to run it and see the failure
my mistake, that only applies for itanium
the ms detours lib included with CDetour doesn't compile in 2008, i see no problem with using a newer version that does, as the functionality of the portions that are used has not changed
good point
it depends on whether he's referring to functions that take pointers or references to various structs or functions that actually take the structs - in the case of the former it's likely some asterisks and ampersands were overlooked, in the case of the latter his structs probably aren't the right size (could be caused by member offset even if they are written correctly)
OP, feel free to elaborate
it requires you to call a function at the beginning and end of every hook, which could result in a host of problems, and really i don't see the point of your prologue or epilogue
the prologue appears to just fix the hooked function, which could be done as easily by the user if they planned to call it (if you really want simplicity, use an "org" function like CDetour), and the epilogue sets some unused globals
also, what if you're hooking a member function? ecx could get changed if the prologue isn't in asm
Exactly; it won't compile for x64.
If that's true; mixing'n'matching can open you up to new kinds of vulnerabilities or unforeseeable problems.the ms detours lib included with CDetour doesn't compile in 2008, i see no problem with using a newer version that does, as the functionality of the portions that are used has not changed
1) Pseudo-function; they're just macros. I didn't intend for it to be used, more so, learned from.it requires you to call a function at the beginning and end of every hook, which could result in a host of problems, and really i don't see the point of your prologue or epilogue
the prologue appears to just fix the hooked function, which could be done as easily by the user if they planned to call it (if you really want simplicity, use an "org" function like CDetour), and the epilogue sets some unused globals
also, what if you're hooking a member function? ecx could get changed if the prologue isn't in asm
2) The prologue pseudo-function fixes the function; the epilogue, on the other hand, spoofs the second return address, so when the function returns, the hook is re-added, then the original, non-spoofed second return address is returned to.
3) It shouldn't be changed, no operations being executed leave such opportunity to occur. However, if the user's hook does, then the PUSHAD and POPAD instructions could be used executed as well by the prologue and epilogue code.
eek ego ego ego,
lets just leave the issue alone, i think the op got his answer
that obama picture is hilarious though xD
Last edited by Wucas; 27-08-09 at 04:38 AM.
Reply With Quote