[jchw]

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.

[intea]

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.

[jchw]

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.

[stevemk14ebr]

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.