Windows API spying/hijacking techniques

Question

I'm interested in using API spying/hijacking to implement some core features of a project I'm working on. It's been mentioned in this question as well, but that wasn't really on topic so I figured it'd be better with a question of its own for this.,

I'd like to gather as much information as possible on this, different techniques/libraries (MS Detours, IAT patching) or other suggestions.

Also, it'd be especially interesting to know if someone has any real production experience of using such techniques -- can they be made stable enough for production code or is this strictly a technique for research? Does it work properly over multiple versions of windows? How bug prone is it?

Personal experiences and external links both appreciated.

Answer 1

I implemented syringe.dll (L-GPL) instead of MS Detours (we did not like the license requirements or huge payment for x64 support) it works fantastically well, I ported it from Win32 to Win64, we have been using in our off-the-self commercial applications for around 2 years now.

We use it for very simple reasons really its to provide a presentation frame work for re-packing, re-branding the same compiled application as many different products, we do general filtering and replacment for string, general resource, toolbar, and menus.

Being L-GPL'd we supply the source, copyright etc, and only dynamically link to the library.

Answer 2

Hooking standard WinAPI functions is relatively safe since they're not going to change much in the near future, if at all, since Microsoft does it's best to keep the WinAPI backwards compatible between versions. Standard WinAPI hooking, I'd say, is generally stable and safe.

Hooking anything else, as in the target program's internals, is a different story. Regardless of the target program, the hooking itself is usually a solid practice. The weakest link of the process is usually finding the correct spot, and hanging on to it.

The smallest change in the application can and will change the addresses of functions, not to mention dynamic libraries and so forth.

In gamehacking, where hooking is standard practice, this has been defeated to some degree with "sigscanning", a technique first developed by LanceVorgin on the somewhat infamous MPC boards. It works by scanning the executable image for the static parts of a function, the actual instruction bytes that won't change unless the function's action is modified. Sigscanning is obviously better than using static address tables, but it will also fail eventually, when the target application is changed enough.

Example implementation of sigscanning in c++ can be found here.

Answer 3

I've been using standard IAT hooking techniques for a few years now and it works well has been nice and stable and ported to x64 with no problems. The main problems I've had have been more to do with how I inject the hooks in the first place, it took a fair while to work out how best to suspend managed processes at the 'right' point in their start up so that injection was reliable and early enough for me. My injector uses the Win32 debug API and whilst this made it easy to suspend unmanaged processes it took a bit of trial and error to get managed processes suspended at an appropriate time.

My uses for IAT have mostly been for writing test tools, I have a deadlock detection program which is detailed here: http://www.lenholgate.com/archives/000643.html a GetTickCount() controlling program which is available for download from here http://www.lenholgate.com/archives/000648.html and a time shifting application which is still under development.