Windows API Spy / Capture Methods

Question

I am interested in using the spy / capture API to implement some of the basic functions of the project I'm working on. This question was mentioned, but it was not on the topic, so I decided that it would be better with my own question for this.

I would like to collect as much information as possible about this, various methods / libraries ( MS Detours , IAT patching ) or other suggestions.

In addition, it would be especially interesting to find out if anyone has any real experience using such methods - can they be stable enough for production code or is it strictly a research method? Does he work correctly on multiple versions of windows? How can this be a mistake?

Personal experience and external links are evaluated.

Answer 1

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

We use it for very simple reasons, to provide a presentation framework for repackaging, re-branding the same compiled application as many other products, we do general filtering and replacement for the line, share, toolbar and menu.

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

Answer 2

Acquiring standard WinAPI features is relatively safe, as they will not change much in the near future, if at all, since Microsoft does this best to maintain WinAPI compatibility between versions. The standard WinAPI connection, I would say, is generally stable and secure.

Involving anything else, as well as the internal components of the target program, is a completely different story. Regardless of the target program, binding itself is usually a solid practice. The weakest link in the process usually finds the right spot, and hangs on it.

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

In gamehacking, where binding is standard practice, this is somewhat defeated by sigscanning, a technique first developed by LanceVorgin on a somewhat infamous MPC. It works by scanning the executable image for the static parts of the function, the actual bytes of the commands that will not be changed, if only the action of the function changes. Sigscanning is obviously better than using static address tables, but in the end it will also work when the target application is changed.

An example implementation of sigscanning in C ++ can be found here .

Answer 3

I have been using standard IAT binding methods for several years, and it works well, was nice and stable, and ported to x64 without any problems. The main problems that I encountered were more related to the way I introduce hooks in the first place, it took enough time to determine how best to suspend controlled processes at the right point when they start, so that the injection is reliable and sufficient early for me. My injector uses the Win32 debugging API, and at the same time, it made it easier to suspend unmanaged processes, and it took a bit of trial and error to suspend managed processes at the right time.

My IAT applications are mainly for writing test tools, I have a deadlock detection program that is described in detail here: http://www.lenholgate.com/blog/2006/04/deadlock-detection-tool-updates.html , the GetTickCount () control program, available for download from here http://www.lenholgate.com/blog/2006/04/tickshifter-v02.html and a time-shift application that is still under development.

Answer 4

Something that many people forget about is that Windows dlls are compiled as hot image patches ( MSDN ).

Hot-patching is the best way to bypass WinAPI, as it is clean and simple, and preserves the original function, that is, you do not need to use the built-in assembly, only slightly configured function pointers.

A small guide to hot fixes can be found here .