-
Notifications
You must be signed in to change notification settings - Fork 92
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
One hook for multiple targets - feature request #35
Comments
Adding a new argument is impossible without knowledge about number of original function's arguments and their types (integer or floating point number). Instead of it, thread-local storage is available for that purpose. Funchook hooks functions by replacing first few bytes at the beginning of the original functions. (See http://jbremer.org/x86-api-hooking-demystified/#ah-basic) On x86_64, the code size of jump instruction is 5 when the distance from source to destination is between 2 gigabytes. Otherwise it is 14 to jump to any address. Funchook uses 5-byte code when the distance from the original function to the hook function is less than 2 gigabytes. Otherwise, it allocates memory near the original function and uses 5-byte code to jump from the original to the newly allocated memory and 14-byte code to jump from the memory to the hook function. The code in the memory is called as "transit" in funchook. I think that the feature can be implemented.
|
Many thanks, works great for me. I think this can be closed with 2.0.0 release. |
Given a list of function addresses at runtime I need to log whenever any of them is called. I believe the best way to do this would be to hook the functions with a logger hook. After some discussion it looks like this ideally would be enabled by a hooking library.
However, with current API of this library, it is impossible to have one hook function for multiple targets, as the hook function does not have the information about the hooked function (in particular its address).
I would like to propose a feature, that would make it possible not only to write this:
but also this:
The address of the original function could be passed in any other way, not necessarily as the first argument.
Could this be implemented as part of this library? If so, what would be the best way to approach it?
The text was updated successfully, but these errors were encountered: