Cross-platform x86 detours

[mlg]

Hey there,

as first post, I wanted to publish my detour library which I have just finished writing for one of my projects.

FEATURES

• Cross-platform x86 and x86-64 function detouring (Windows, Linux and other unixes)
• Object orientated programming
• Relocates overwritten original code
• Works on every common compiler (tested with VC8, VC9, VC10, MinGW and GCC 4.4)
• No typecasting on your side
• MIT license

In fact my main problem on Windows was that detouring the sendto WinSock function of specific games which XFire already hooked made the whole process crash. To work around this issue, my detour library relocates the copied original code and does by default not modify the target function again when removing the detour. Instead, it redirects the trampoline (im in ur memory, placing my jmps) directly back to the original code.



USAGE EXAMPLE

#include <iostream>
#include "detours.h"

typedef int (*tPrintIntegers)(int, int);

MologieDetours::Detour<tPrintIntegers>* detour_PrintIntegers = NULL;
MologieDetours::Detour<tPrintIntegers>* detour2_PrintIntegers = NULL;

int hook_PrintIntegers(int param1, int param2)
{
	param1 <<= 1;
	param2 <<= 1;
	
	int two = detour_PrintIntegers->GetOriginalFunction()(param1, param2);
	return two + 1;
}

int hook2_PrintIntegers(int param1, int param2)
{
	param1 <<= 1;
	param2 <<= 1;
	
	// Issue 1: A detour library which does not relocate code would get you to the unrelocated
	// jmp hook_PrintIntegers from detour_PrintIntegers now. This would result in a crash.
	int two = detour2_PrintIntegers->GetOriginalFunction()(param1, param2);
	return two + 2;
}

int PrintIntegers(int param1, int param2)
{
	std::cout << "Param1: " << param1 << ", Param2: " << param2 << std::endl;
	return 2;
}

int main(int argc, char* argv[])
{
	// Prints "Param1: 1, Param2: 2", returns 2
	PrintIntegers(1, 2);
	
	// Detour PrintIntegers
	try
	{
		detour_PrintIntegers = new MologieDetours::Detour<tPrintIntegers>(PrintIntegers, hook_PrintIntegers);
		detour2_PrintIntegers = new MologieDetours::Detour<tPrintIntegers>(PrintIntegers, hook2_PrintIntegers);
	}
	catch(MologieDetours::DetourException &e)
	{
		// Something went wrong
		std::cerr << e.what() << std::endl;
		return 1;
	}
	
	// Prints "Param1: 4, Param2: 8", returns 5
	PrintIntegers(1, 2);
	
	// Issue 2: Every detour library I have tested before would break the callchain at this point.
	// The next call to PrintIntegers would crash the application.
	delete detour_PrintIntegers;
	
	// Prints "Param1: 2, Param2: 4", returns 3
	PrintIntegers(1, 2);
	
	// Remove the second hook. Usually, this hook would have to be removed first.
	delete detour2_PrintIntegers;
	
	// Prints "Param1: 1, Param2: 2", returns 2
	PrintIntegers(1, 2);
	
	// Huge success!
	return 0;
}

I hope this will prove itself useful. HDE32 and HDE64 are included in the download, they have been modified to use boost/cstdint.h. Boost is required for this to work, VC9 does not have a stdint.h and Boost's header is a great replacement.

Greez,
mlg

[v3n0m4]

nice one,
you should consider using beaengine and then port it to x64

[xmy]

This looks really cool. A x64 port would be great!
Thanks for the contribution.

[mlg]

Thank you for your comments, and thank you for making this an article and sticky.

BeaEngine is great, however I do not really like its license. I am a fan of open source and GPL/LGPL, however it does not really make your software free. I want to distribute my application as single, closed-source module. The LGPL license BeaEngine uses would force me to dynamically link BeaEngine as shared object though. Especially when it comes to gamehacks, most people will have the same issue.

Basically, if I make this library use BeaEngine, I can not use it for my own project anymore, which is why the library right now uses ADE32 as disassembler.

Does anyone know a good, non-GPL disassembler written in C or C++ for x86 and x86-64?

[Chazwazza]

http://www.beaengine.org/index.php?o...&id=8&Itemid=9


This library is released under LGPL license. That means you can use it in your projects even if they are under free or proprietary licenses. You don't have to modify your license (if there is one) and you don't have to publish your source code. But, if you improve BeaEngine, you have to publish the modified library under one of the following license : LGPL or GPL.

[mlg]

[vb won't let me quote the link]

This library is released under LGPL license. That means you can use it in your projects even if they are under free or proprietary licenses. You don't have to modify your license (if there is one) and you don't have to publish your source code. But, if you improve BeaEngine, you have to publish the modified library under one of the following license : LGPL or GPL.

Generally this is correct, however, what I have gathered from the LGPL license text itself and Wikipedia, it must be possible for the end user to replace the LGPL module by another version. This can only be achieved by dynamically linking BeaEngine so the module can be replaced or providing the software's object files so the BeaEngine object can be replaced, which both is a problem for me.

[Chazwazza]

I searched around a bit on your behalf and it seems that this is one of those 'grey areas'. The consensus seems to be that you are allowed to static link an LGPL binary if you provide either the source code OR the object files to your program. So, you could protect your source code by providing linkable object files, but I'm not sure whether this is seen as the 'right' thing to do.

I would recommend contacting the author of BeaEngine and asking for his permission.

[mlg]

I have fixed an issue which caused the Revert() function to fail if the code has been relocated before. If you have issues with using Revert() (usually crashes), try updating to the latest release.
This does not affect you if you were not using the Revert() function.

EDIT: It would be great if someone updates the article on the frontpage as it appears to be a copy of the OP only.

[Fyyre]

use hde64/hde32... is clone of z0mbie's XDE, simple and straight forward to use..

[mlg]

Thanks for the tip, HDE appears to be exactly what I have been looking for. I will see to update this library to support x86-64 soon.

[Chazwazza]

Cool. Looking forward to the update.

[MegaByte]

This sounds like quite a good project I will have to check out this detouring library.

Edit:
A slight problem I am having.
I am trying to hook the API on windows CreateFileW.

HMODULE Kernel32 = GetModuleHandle("Kernel32.dll");		
detour_CreateFileW = new MologieDetours::Detour<tCreateFileW>(Kernel32,"CreateFileW", hook_CreateFileW);

But my hook_CreateFileW is never accessed. The detour is put in place I can see it when I goto CreateFileW using OllyDBG however when I step into it, it appears to jump back to the original function straight away.

Here are my defines

typedef HANDLE ( WINAPI* tCreateFileW )(LPCWSTR lpFileName,DWORD dwDesiredAccess,DWORD dwShareMode,LPSECURITY_ATTRIBUTES lpSecurityAttributes,DWORD dwCreationDisposition,DWORD dwFlagsAndAttributes,HANDLE hTemplateFile);
HANDLE WINAPI hook_CreateFileW(LPCWSTR lpFileName,DWORD dwDesiredAccess,DWORD dwShareMode,LPSECURITY_ATTRIBUTES lpSecurityAttributes,DWORD dwCreationDisposition,DWORD dwFlagsAndAttributes,HANDLE hTemplateFile);
MologieDetours::Detour<tCreateFileW>* detour_CreateFileW = NULL;

I am using Visual Studio 2008 and compiling in Release Mode.
Is there anything I am doing wrong? Could you please give an example detouring a windows API.

I put a messagebox in the deconstructor of Detour and it showed. So it seems that the trampolean is having its JMP set to goto the backupOrigionalCode when using Detour(HMODULE module, const char* lpProcName, FunctionType pDetour).

Im going to try putting the exact address in instead of using this constructor to see if it makes a difference.
And it seems it does

detour_CreateFileW = new MologieDetours::Detour<tCreateFileW>((tCreateFileW)GetProcAddress(Kernel32,"CreateFileW"),hook_CreateFileW);

Works fine.
I think by using Detour() constructor inside the module one creates a tempoary Detour object which is destroyed when it is out of scope. Prehaps a fix for this would be to make a function such as SetDetour and just call that from each constructor passing propper paramaters.

Suggested fix

Copy current code from the first constructor into a private void CreateDetour( FunctionType pSource, FunctionType pDetour );
Make the constructors use this method rather than using another constructor.

I googled the problem I cannot post links so here is a search string

site:stackoverflow.com can-constructor-call-another-constructor-in-c

Other than that its a very nice clean library, its just waiting for more types of detours

[mlg]

Thanks for your feedback MegaByte. I have included your suggested fix into the attached update. I have tested the attached files and have not noticed any bugs when compiling for Win32 so far. The usage has not changed, this should be a drop-in replacement for the update.

Version 2.0 PRE-RELEASE ALPHA 1:
	Added DoxyGen documentation
	Added HDE as replacement for LDE
	Added x86-64 support
	Removed LDE
	Fixed bug in constructor for creating a detour using a module handle and exported function name

Please note that Boost is required for using this library now as I am using boost/cstdint.h for keeping this cross-platform without having to mess around with MSVC (which does not include stdint.h until version 10) while breaking GCC and MinGW compatibility.

Detouring in native x86-64 processes has barely been tested (using MSVC 10.0). I am uploading this PRE-RELEASE library for testing purposes only, which is why I am not updating the OP yet. Patches are greatly appreciated.
I will update the OP as soon as I found some time for testing detouring on x86-64 more extensively.

[MegaByte]

Cool I shall give it a test out on 64bit later as well, when I can find something worth doing it to thats 64bit...
Any ideas what we can use in place of __declspec(naked) in 64bit? I heard that it was removed or something it can be handy when you want to detour something that is not a function or API but half way through already existing functions.

Although im reminded that I cant do anything in 64bit in terms of reversing as I use OllyDBG and not IDA Pro so im going to have to learn how to use IDA first.

Thanks for your work on this libary

[Chazwazza]

WinDbg supports x64 fyi.

As far as __declspec(naked) goes, you can compile your assembler code using MASM then link the generated object file into your program (MSVC will let you do this), however, personally I just use AsmJit.