4 ms·

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:/

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 https://github.com/stevemk14ebr/PolyHook_2_0

jchw 7y ago
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?)
- stevemk14ebr 7y ago
  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.
  - jchw 7y ago
    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.
  - intea 7y ago
    jmp [rip] .dq 0xCCCCCCCCCCCCCCCC works too
    - jchw 7y ago
      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 7y ago
        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 7y ago
        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 7y ago
        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.

jchw 7y ago

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?)

stevemk14ebr 7y ago
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.
- jchw 7y ago
  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.
- intea 7y ago
  jmp [rip] .dq 0xCCCCCCCCCCCCCCCC works too
  - jchw 7y ago
    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 7y ago
      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 7y ago
        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 7y ago
        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.