News for hackers. Stuff that matters.
Re:x86 API Hooking Demystified (2012) by intea on Wednesday July 10, 2019 @02:58AM (#20399734)
jmp [rip] .dq 0xCCCCCCCCCCCCCCCC

works too

Re:x86 API Hooking Demystified (2012) by jchw on Wednesday July 10, 2019 @03:17AM (#20399819)
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.

Re:x86 API Hooking Demystified (2012) by intea on Wednesday July 10, 2019 @05:58AM (#20400532)
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.
Re:x86 API Hooking Demystified (2012) by jchw on Wednesday July 10, 2019 @10:22AM (#20402188)
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.
Re:x86 API Hooking Demystified (2012) by stevemk14ebr on Wednesday July 10, 2019 @09:59PM (#20408506)
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.