Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SetWinEventHook and SetWindowsHookEx does not provide a way to pass user data #28

Open
sylveon opened this issue Aug 5, 2020 · 0 comments

Comments

@sylveon
Copy link

sylveon commented Aug 5, 2020

Currently, these methods have no way for users to provide user data parameters if the hook is ran in the hooker process (in process). This can be problematic in advanced scenarios, where multiple hooks can be desired (I scope my hooks as much as possible because hooking all events can cause system slowdowns).

Currently, none of the possible solutions are pretty:

  • Generate thunks, which involves dynamic codegen (a security can of worms) and is not portable at all. I even have a whole project that I started due to this problematic API: https://github.com/sylveon/member_thunk
  • Store a static pointer and have the callback access this pointer. This results in a great loss of flexibility because you cannot "create" static variables at runtime to accommodate the need for dynamically created hooks.
  • Use something like std::unordered_map<HWINEVENTHOOK, std::function<...>>, pass the same callback to all hooks and have that callback lookup the map. This is frankly just janky and results in increase memory usage and increased callback execution time, which is critical for system responsiveness.

As far as I know, these two functions are some of the only callback-based functions having this limitation. Even window procedures have a way to store a custom user data pointer.

Additionally, adding this feature for out of process hooks would also be useful as it would allow the hooker process to pass information like a handle acquired with DuplicateHandle, or the handle of a window to use for communication with, to the callback running in the hooked process. Currently, I rely on Detours' DetoursCreateRemotePayload to transfer this information but this solution is far less than ideal, and does some pretty questionable things to the target process (like create a memory allocation that's practically not freeable because Detours never gives you the base pointer and doesn't have an API to free such payloads).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant