-
-
Notifications
You must be signed in to change notification settings - Fork 227
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
Calling the original function fails after hooking the same function twice or more #177
Comments
Can you create a self contained reproduction case using like a winapi call as the hook target? I'd have to debug your target at the assembly level to figure out the specific issue. I've just tried this on CreateMutexA myself and it worked fine |
Hey sorry for the late reply. I tried to recreate my error in a controlled environment but just cannot do it. I tried for multiple hours. I was hoping my initial log would raise some eyebrows. PLH::x64Detour *glfwSwapBuffers_hook = nullptr;
uint64_t glfwSwapBuffers_addr;
PLH::x64Detour *getFov_hook = nullptr;
uint64_t getFov_addr;
std::thread *thread;
void my_glfwSwapBuffers(void *window)
{
static bool setup = false;
if (!setup)
{
getFov_hook->unHook(); //normally executed by a module manager
// wait some time
getFov_hook->hook(); //normally executed by a module manager
false = true;
}
PLH::FnCast(glfwSwapBuffers_addr, my_glfwSwapBuffers)(window);
}
std::string my_getFov(class LevelRendererPlayer *base, float param_1, bool flag)
{
return PLH::FnCast(getFov_addr, my_getFov)(base, param_1, flag);
}
void main()
{
getFov_hook = new PLH::x64Detour((uint64_t)0x7fc456275930, (uint64_t)my_getFov, &getFov_addr);
glfwSwapBuffers_hook = new PLH::x64Detour((uint64_t)0x79e6c0, (uint64_t)my_glfwSwapBuffers, &glfwSwapBuffers_addr);
auto error_log = std::make_shared<PLH::ErrorLog>();
PLH::Log::registerLogger(error_log);
getFov_hook->hook();
glfwSwapBuffers_hook->hook();
}
I found out a few things though.The first hook didn't crash my game as it was activated by an independent thread (sth like the main function). The hooks after that have been activated inside of a hooked function (glfwSwapBuffers) which causes the Trampoline to get generated in the wrong place. [Speculation: it looks like the trampoline gets generated close to the location of glfwSwapBuffers (maybe because it is generated while in glfwSwapBuffers?) This is really far away from the actual getFov method and we cannot jump there or sth like that. Could this make sence? :-|] if I wrap the hook and unhook method in their own thread the problem disappears and the process doesn't crash. like this: void test()
{
getFov_hook->unHook();
getFov_hook->hook();
}
void my_glfwSwapBuffers(void *window) // replace
{
static bool setup = false;
if (!setup)
{
std::thread t1(test);
t1.join();
}
PLH::FnCast(glfwSwapBuffers_addr, my_glfwSwapBuffers)(window);
}
Any new ideas or comments? |
Hey, this might be a linux specific problem but whenever I hook a function, unhook it and hook it again the process will crash when calling the original trampoline function. This is some pseudo code that will generate the following output:
The code will output this.
After "rehooking" the detour will work fine but calling the tram function will crash the process.
The Trampoline (with m_trampoline) is in a completely diffrent location and it's instructions wont ever get called.
0x5e94030 is somewhere close the entry process/executable. The function i hook is in an libary allocated far away from that address.
I would love to know why this happends. Sometimes "rehooking" the function works fine but most of the time it will crash the process. I Never actively encountered this error on the first hook. After using dlclose and dlopen again (to uninject and inject my custom code again) the hook will work fine again.
The text was updated successfully, but these errors were encountered: