Can Windows API functions be over-written and called after it?

Question

I want to modify the native functions available in Windows API, such as CreateWindowEx or ShowWindow in a way that when an application is compiled with those functions included, it will instead call my functions, perform the tasks there, and then call the original native function.

In other words, I want to in a way proxy the functions, while still using the same names (so if a program was written to be compiled with the native API, simply adding these functions would modify the way those native functions are handled)

HWND WINAPI CreateWindowEx(
  __in      DWORD dwExStyle,
  __in_opt  LPCTSTR lpClassName,
  __in_opt  LPCTSTR lpWindowName,
  __in      DWORD dwStyle,
  __in      int x,
  __in      int y,
  __in      int nWidth,
  __in      int nHeight,
  __in_opt  HWND hWndParent,
  __in_opt  HMENU hMenu,
  __in_opt  HINSTANCE hInstance,
  __in_opt  LPVOID lpParam
) {

    //my custom code here....

    // done with my custom code... so now I want to run the native function
    return CreateWindowEx(dwExStyle, lpClassName, lpWindowName, dwStyle, x, y, nWidth, nHeight, hWndParent, hMenu, hInstance, lpParam);
}

This (for obvious reasons) gives a stack overflow, as it keeps on calling itself over and over. What I would want it to do is, when it is called, it runs through the custom function I've created, and thereafter runs the native functions available in Windows API.

I am quite new to c++, but for example in many other languages, I could store a reference to the native function under another name, which I could then call inside my custom function. Is there anything similar available in c++?

Once upon a time there was the Detours project from Microsoft Research. Now it isn't free anymore (At least the Pro version that runs on x64). But try googling for Detours alternatives. — xanatos, Oct 14 '11 at 16:20
The reason why you are doing this will dictate what the best solution is. Can you provide more context? — tenfour, Oct 14 '11 at 16:30
@tenfour I am looking to bind these functions to send the details (window options, actions etc) over web sockets to javascript — , Oct 14 '11 at 16:39

score 3 · Accepted Answer · edited May 23 '17 at 11:47

3

As I've written in the comment, the parent of many hooking libraries was probably the microsoft Detours

Now that it isn't free anymore there are various alternatives. Here there is a comparison of some of them (link removed. I'm not sure it was safe. Try googling for "Microsoft Detours is a library utilized in the particular interception" and select a source or more simply for Detours Alternatives.

Mmmh it seems the only free alternative at this time are http://easyhook.codeplex.com/ and http://www.codeproject.com/KB/system/mini_hook_engine.aspx

There is a SO question: Detours alternative for Registry interception if you are interested.

edited May 23 '17 at 11:47

Community

1
1

answered Oct 14 '11 at 16:24

xanatos

109,618
12
197
280

I didn't realize Detours was no longer free. What a shame. – ildjarn Oct 14 '11 at 16:25
This wasn't what I was looking for, but may in fact be what I needed. Will need to read more in detail what exactly it is all about – Oct 14 '11 at 16:41

tenfour · Answer 2 · 2011-10-14T16:48:58.463

One interpretation of your question is that you have a project, with source code, and you want to change that project so it uses your own versions of certain winapi functions.

Here is a solution which you can implement for each imported API function. Example here is for ShowWindow:

#define ShowWindow Deleted_Winapi_ShowWindow // prevent windows.h from defining ShowWindow
#include <windows.h>
#undef ShowWindow

namespace HiddenWinapi
{
    extern "C"
    {
        // Do what windows.h does, but hide it inside a namespace.
        WINUSERAPI BOOL WINAPI ShowWindow( __in HWND hWnd, __in int nCmdShow);
    }
}

// make your own function to be called instead of the API, and delegate to the actual API in the namespace.
BOOL WINAPI ShowWindow(HWND hwnd, int nCmdShow)
{
    // ... do stuff ...
    // call the original API
    return HiddenWinapi::ShowWindow(hwnd, nCmdShow);
}

To use this solution for CreateWindowEx, you need to stub the actual imported function name (e.g. CreateWindowExW), because CreateWindowEx is just a macro which expands to CreateWindowExW or CreateWindowExA.

Here is a solution which replaces the macro with your own, but I think in all cases it would be better to use the above solution.

#include <windows.h>

#undef CreateWindowEx

// Note that this is a unicode-only version. If your app mixes A and W versions, see 
// the solution below for non-macro APIs.
HWND WINAPI CreateWindowEx(DWORD dwExStyle, LPCWSTR lpClassName, LPCWSTR lpWindowName, DWORD dwStyle, int X, int Y, int nWidth, int nHeight, HWND hWndParent, HMENU hMenu, HINSTANCE hInstance, LPVOID lpParam)
{
    // ... do stuff ...
    // call the REAL function.
    return CreateWindowExW(dwExStyle, lpClassName, lpWindowName, dwStyle, X, Y, nWidth, nHeight, hWndParent, hMenu, hInstance, lpParam);
}

This seems quite close to what I was initially after, but looking at xanatos answer regarding Detours and EasyHook, it may be in fact what I really need. It may however be a problem if in fact all of the functions are not macros, in which case some different solution would be necessary in those cases. — , Oct 14 '11 at 16:37
Sorry, I edited it to include an elegant solution for non-macro api calls. — tenfour, Oct 14 '11 at 16:38

score 0 · Answer 3 · answered Oct 14 '11 at 16:22

If you want to do this yourself the easiest way is to modify the import address table in the PE (portable executable) header. This is not trivial, though.

However, I believe there's a standard library for what you want called Detours. I've never used that one myself, though, because it wasn't around when I started doing this, so I have a - not for public consumption - library for doing it via the import table when I need it.

Can Windows API functions be over-written and called after it?

3 Answers3