API to make global mods less heavy

[aubymori]

Global mods--those that inject into (nearly) every process--have a glaring inefficiency: they load every DLL they need to hook functions from or otherwise modify the memory of indiscriminately. Take Aerexplorer for example. It is a mod that modifies the user interface of Explorer windows, including the file open/save dialogs seen in other programs. It accomplishes this by hooking functions within ExplorerFrame.dll, shell32.dll, and more. Since it needs to affect file open/save dialogs, it injects into every process. This includes programs that don't use these dialogs and as such normally won't ever load these DLLs, such as a CLI tool like Git. This doesn't affect my system all that much, but it could definitely be problematic for users running lower end systems, and it honestly just irks me thinking about how inefficient this is.

My idea is to listen for DLL loads and simply perform the needed modifications upon that DLL being loaded. Luckily, Windows has an API, LdrRegisterDllNotification that accomplishes this. One could simply write a wrapper function for this that checks if the needed DLL is already loaded and skips the listening entirely.

However, the reason I decided against this is because the aforementioned Windows API is obviously asynchronous. It can't reliably be used with the current Windhawk mod API; it would be simply impossible to detect most failures by the time the mod leaves Wh_ModInit. My current proposition is to provide an API function (perhaps called Wh_Uninject) that would simply unload the mod from the process, the same way as if Wh_ModInit had failed.

Thoughts?

[m417z]

It can't reliably be used with the current Windhawk mod API

What do you mean by "reliably"? You could log the error, abort the initialization, and run the necessary cleanup if needed. The two advantages of having Wh_Uninject that I see are (reliably isn't one of them):

• Visual indication to the user: the mod will be listed as "Unloaded" in the loaded mods dialog.
• Insignificant efficiency: the dll will be unloaded.

Did you have other advantages in mind?

Currently many of the taskbar mods that rely on Taskbar.View.dll hook LoadLibraryExW and do something similar to what you suggest, and it works fine. Generally I think that Wh_Uninject could be a nice addition, but I don't see it as a blocker to implementing what you're suggesting.

[aubymori]

Did you have other advantages in mind?

Well, it would allow for a proper, full uninitialization without the user needing to manually remove all function hooks. Actually, it seems you can technically do this right now by passing NULL (which is equivalent to MH_ALL_HOOKS) to Wh_RemoveFunctionHook, but this behavior isn't documented.

As well, having a proper built-in API for hooking DLLs in a delayed fashion like this as opposed to mods implementing it individually would reduce the amount of boilerplate code required for each global mod (LdrRegisterDllNotification and its related types are not included at all in the Windows SDK provided by Windhawk).

[m417z]

without the user needing to manually remove all function hooks

The way I imagined the usage is that you'll only apply all hooks once everything else succeeded, something like (pseudo code):

HMODULE modX = nullptr;
HMODULE modY = nullptr;

BOOL Wh_ModInit() {
  LdrRegisterDllNotification(OnDllEvent);
  // ...
}

void OnDllEvent(bool loaded, string name) {
  // Update modX, modY...

  if (modX && modY) {
    LdrUnregisterDllNotification(...);
    InitializeMod();
  }
}

bool InitializeMod() {
  // Set hooks and do other stuff...
  if (failed) {
    return false;
  }

  Wh_ApplyHookOperations();
  return true;
}

As well, having a proper built-in API for hooking DLLs in a delayed fashion like this as opposed to mods implementing it individually would reduce the amount of boilerplate

I agree, it can be a good idea. But I probably won't be working on it in the near-medium future as I have other things on my list. Also, it wasn't battle-tested in mods which do that manually, which can help understand the pros and cons, and the best way for Windhawk to provide an API for it.