relocation beyond displacement size about polyhook_2_0 HOT 6 CLOSED

If you could post the output polyhook generates while hooking I'll take a look

from polyhook_2_0.

Here you man
https://hastebin.com/onajewebul.css

from polyhook_2_0.

'mov rcx, qword ptr [rip + 0xb3f63]'

This is not relocatable by polyhook, it's the bug you linked, it is too complex to JIT an equivalent load for the general case. Patch this manually yourself after polyhook is done, you will need to modify it so the lib ignores that

from polyhook_2_0.

Ok thank you for your time in looking into this I appreciate the fast response and explanation! cheers mate!

from polyhook_2_0.

sorry to reopen the issue but should this really fail on hooking simple things like setcursorposition?
const auto u32Dll = GetModuleHandle(L"User32.dll"); if (u32Dll != nullptr) { const auto setCursorPosAddress = GetProcAddress(u32Dll, "SetCursorPos"); if (setCursorPosAddress) { TestHook = dxGui::Hooks::CreateHook(reinterpret_cast<char*>(setCursorPosAddress), reinterpret_cast<char*>(&SetCursorPosHook), &GetMessageTramp); if(TestHook) std::cout << "hooked SetCursorPos at " << std::hex << setCursorPosAddress << std::endl; } }

It's basically failing to hook 90% of anything I try in x64 with this same error, I've never experienced any errors in x86 before that's why it feels like it is on my end. I'm not very experienced but my understand is that if the trampoline address size is > 4 bytes this error occurs

from polyhook_2_0.

The 'simple' ness of a fuction doesn't matter. What matters is that on x64 the assembly is very often position independent (uses RIP as a base for operations, such as that move). This is a problem because if we move these position independent code types we must fix them, so that the final destination they point to is the same (I.E re-encode the offset, to counter the movement of RIP).

Now usually this is fine, as long as we have space within the instruction for the new displacement. Unfortunatelly on x64 the address range is huge, and we can easily get an allocation beyond +-2GB, which takes 4bytes to encode. Most of these RIP instructions have a max value for displacement of 4 bytes, so if our allocated was too far we CANNOT fix it since there is literally no room to place a bigger displacement.

The option now is to generate a symantically equivalent operation. That mov for example could be re-done so that it fetches from an absolute location rather than RIP relative. But the new instruction will likely have a different width and so may overwrite more instructions before/after the one we try to fix. This creates absolute hell in the general case, where fixing one instruction will create more that need to be relocated...which may make more...recursive.

I tried to fix this. It's hard. I wasted 2 years doing it, so i decided to warn users instead. This is only hard in the general case. If you still want to hook these functions, then let polyhook do it's thing but modify it to ignore these special relocations. When it's done, manually fixup the instruction yourself, the hook is 95% of the way at this point just that one relocation is wrong.

I'd love a nice general fix, but i don't have to time to design that system let alone implement it. If anyone can create such a fix by all means tell me. I even already have AsmJit integrated so the work of runtime code generation is started.

from polyhook_2_0.