Hacker News Reader

Comment by stevemk14ebr | Hacker News Reader

I wrote a hooking library that implements the methods talked about, plus a bunch more it doesn't. As well as handle a bunch of edge cases not mentioned: https://github.com/stevemk14ebr/PolyHook_2_0

View on HN

Thanks for linking, this is really cool. Also nice to see AMD64 support, I never figured out how it can be done. (Is there an absolute jmp without destroying registers in x64?)

yes there is. \x25\xff\x00\x00\x00\x00 where 0 is a 32 bit displacement to a memory location that contains a 64 bit constant is what i use: jmp [disp] but you need to be able to place the constant +- 32bits. This is really hard for x64 on windows, since VirtualAlloc gives you no guarantees, i used to walk pages manually now i just new/delete in a loop and hope for the best.

There's also:

push rax

mov rax, 0xDEADBEEFDEADBEEF

xchg qword ptr ss:[rsp], rax

ret

but i dont like it as much since it touches stack (technically more detectable since you overwrite stuff at rsp - 8). RSP & RAX are original values after that gadget though.

Also fun fact. My library supports JIT-ing, so you can create the stub that the hook jmps to at runtime and it will JIT translation logic for the calling convention and pack the args + ret value into a structure that can be modified. So you can hook unknown functions at runtime.

Interesting.

I am guessing the length of the jump itself is probably important for some reason. But if you could afford to overwrite ~16 bytes, maybe you can store the address inside the imm64 of another instruction. Length issues aside, it shouldn’t break nested hooking at least.

jmp [rip] .dq 0xCCCCCCCCCCCCCCCC

works too

Mixing code and data, right? I think the downside here is if you tried to install another hook it’d fail because the LDE wouldn’t be able to make heads or tails of the address. I suggest embedding the value into something with an imm64 argument (mov?) so that LDEs can handle it.

I guess also though, at ~16 bytes its probably deep enough into the function that it may no longer be position independent, or hell, maybe the function isn’t even that long to begin with.

If you're writing a hooking library / a hook you should be keeping track of where they are. It's a big hook, that is true but it's also one that doesn't spoil a register and is pretty straightforward to add. It's a tradeoff.

Well the bigger problem imo is other hook engines that might also be roaming around the process space. I think all you need is two extra bytes to make it valid instructions, and in theory then nested hooking should work fine. Though it only exacerbates the length issue.

if you place the data at the end of the trampoline it avoids these issues of mixing data and code, it's like a little custom data segment you make since you have to allocate the trampoline anyways. This is what i do in my lib. The disp is after the jmp the trampoline uses to jmp back to the original. The original function only has the jmp [disp] and no data is mixed.

Reply on news.ycombinator.com