This little project of mine got influnce from many places. First was monoceres' example of hooking a local API call by modifying the IAT. Next was Ward's MemoryDll UDF, which formed a basis for my method. Lastly was a CodeProject article here -

which describes a hook engine, and from which I took the idea for the hook bridge, which allows a hooking function to call the real function without resetting the hook (makes this process thread-safe). I'm also using Distorm64 for the disassembly. The compiled distorm64 DLL is included and used via Ward's MemoryDll UDF.

What this archive contains -

Source for the testapp, example app, and DLL

The compiled DLL that is injected into the testapp to hook the MessageBoxW function

In order to do remote hooking, a DLL must* be used. This method uses RtlCreateUserThread() to cause the remote process to call LoadLibraryA to load the remote DLL. Similarly, it can be made to call FreeLibrary, or any function in your injected DLL. This method can be used to retrieve a remote process's commandline, for example.

I hope the included sample DLL can show the functions needed and how to use them. 2 functions are requred for each API - 1 to do the actual hooking, and 1 to retrieve the Bridge address. This function must be called manually before setting the hook to provide the remote process with the address of the Bridge. Well, the 2nd function and manual call are only required if you want your hooking function to be able to call the original function.

Comments welcome!

* I said must above, but that's not 100% true. There is a way to do it without an external DLL using WriteProcessMemory, but it sill requires the binary data of compiled code, and the code must adhere to specific guidelines -

Share this post

Link to post

Share on other sites

JRSmile 16

JRSmile 16

This little project of mine got influnce from many places. First was monoceres' example of hooking a local API call by modifying the IAT. Next was Ward's MemoryDll UDF, which formed a basis for my method. Lastly was a CodeProject article here -

which describes a hook engine, and from which I took the idea for the hook bridge, which allows a hooking function to call the real function without resetting the hook (makes this process thread-safe). I'm also using Distorm64 for the disassembly. The compiled distorm64 DLL is included and used via Ward's MemoryDll UDF.

What this archive contains -

A compiled testapp (the app that will be hooked)

A compiled example app which will show both local and remote hooking

A compiled DLL that is injected into the testapp to hook the MessageBoxW function

In order to do remote hooking, a DLL must* be used. This method uses CreateRemoteThread to cause the remote process to call LoadLibraryA to load the remote DLL. Similarly, it can be made to call FreeLibrary, or any function in your injected DLL. This method can be used to retrieve a remote process's commandline, for example.

I hope the included sample DLL can show the functions needed and how to use them. 2 functions are requred for each API - 1 to do the actual hooking, and 1 to retrieve the Bridge address. This function must be called manually before setting the hook to provide the remote process with the address of the Bridge. Well, the 2nd function and manual call are only required if you want your hooking function to be able to call the original function.

Comments welcome!

* I said must above, but that's not 100% true. There is a way to do it without an external DLL using WriteProcessMemory, but it sill requires the binary data of compiled code, and the code must adhere to specific guidelines -

Share this post

Link to post

Share on other sites

wraithdu 73

wraithdu 73

Ok, duh, I figured it out. I did find one error in the example, but it wasn't necessarily related to the crash.

For those who had problems with the test crashing, please download the VC++ 2008 SP1 Redistributable and install the runtimes. The msgdll.dll was failing to load on systems without the runtimes and crashing the testapp. See first post for an updated archive and download link for the runtimes.

Share this post

Link to post

Share on other sites

JRSmile 16

JRSmile 16

this is my normal procedure if i find interresting code for further development: download, categorize (function name includes dlls used etc..) upload to svn, backup on nas and a zipped working example on all of my machines. sorry to dissapoint you :-)

Share this post

Link to post

Share on other sites

wraithdu 73

wraithdu 73

Where exactly are you having trouble, injecting the DLL, hooking the API, or coding the DLL to do what you want? What do you want the hook to do? Also, are you hooking the Ansi or Unicode version of the function, or both?

FYI, the script already gets the SE_DEBUG privilege if it can, so you should be OK to open explorer. Be careful though, if ya mess up, you're taking explorer down with you

Share this post

Link to post

Share on other sites

wraithdu 73

wraithdu 73

Could you post the source for your DLL, and if you can figure it out, at what step exactly Explorer is crashing.

From the name of your function, something doesn't look right. Both the SHFileOp hook function and the _Get function should only have 1 parameter, and so should be named at @4. Post the source and I'll look at it.