Open fligger opened 1 year ago
stevemk14ebr
commented
1 year ago 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
fligger
commented
1 year ago 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. The code below is closer to my actual setup but it still isn't reliably crashing my game :).
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();
}
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? :-|] glfwSwapBuffers is part of the entry process while getfov is part of a .so libary. Those distances seem to be normal.
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.