I have been working on a contract that has necessitated the use of function hooking. Basically, I need to intercept an arbitrary program’s usage of a system dll library in order to interject my own logic, and interact with the objects produced by that binary.
There is a nice tool created by Microsoft Research, called Detours. This is basically an API which helps you to perform binary function interception and instrumentation. This API is fairly robust and well thought out, and I use it in this project. However, there is certainly a fair amount of missing functionality.
While testing my application against a popular product that uses the “unicows” library, I stumbled across a very interesting situation during which the Detours method of function interception will not apply.
Basically, unicows has it’s own custom version of GetProcAddress build in. This custom code crawls through the in memory PE header and obtains function offsets by hand. This means that, for dynamically loaded function addresses, using the Detours functionality I am unable to intercept functions loaded at run-time.
So, in order to properly intercept these functions, it was necessary to create an additional API from within Detours. This function needs to crawl through the PE header, and replace the Export Directory entry for a given API with the virtual address of the function you wish to be called, instead. The function will also return the original virtual address, so that you can call that function within your intercepted version.
The new code is here: DetourReplaceExport.txt
So, now I have a working solution for hijacking an API which is linked dynamically using a non-standard GetProcAddress. Yays!
5 thoughts on “Function Hijacking via Export Directory”
hi caustik. today i was reading about this well made hooker, maybe it’s useful to ya: http://help.madshi.net/madCodeHook.htm
Thanks, khu – looks like a really cool library.
Awesome, glad I could help out 🙂
Pretty awesome article. Thanks! – CowDir
very interesting, but I don’t agree with you