You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
lolno 37db06f918 readme & issues 5 vuotta sitten
libudis86 inital commit. currently all winapi 8 vuotta sitten
x64 inital commit. currently all winapi 8 vuotta sitten
hook.c inital commit. currently all winapi 8 vuotta sitten
hook.h inital commit. currently all winapi 8 vuotta sitten
issues.md readme & issues 5 vuotta sitten
list.c inital commit. currently all winapi 8 vuotta sitten
list.h inital commit. currently all winapi 8 vuotta sitten
main.c inital commit. currently all winapi 8 vuotta sitten
misc.c inital commit. currently all winapi 8 vuotta sitten
misc.h inital commit. currently all winapi 8 vuotta sitten
readme.md readme & issues 5 vuotta sitten
udis86.h inital commit. currently all winapi 8 vuotta sitten
x64Hook.vcxproj inital commit. currently all winapi 8 vuotta sitten
x64Hook.vcxproj.filters inital commit. currently all winapi 8 vuotta sitten

readme.md

x64hook is a hooking library for x64 code that aims to be able to patch everything!

The general problems with hooking general functions are: 1) The code to be overwritten with the jump to your code has relative jumps (forward) or calls. Those need to be fixed in the trampoline. As the trampoline is probably out of reach for 32bit jumps all the fixed jumps need to be x64 RIP relative jumps.

Conditional jumps are also handled - there are no jcc rel64 instructions though. That means that the condition is inverted as to jump, over the fixup code, further in the trampoline. The fixup code then is a unconditional 64bit jump.

2) The functions loops back into the code that has to be overwritten - that happens for functions with a loop (duh!) but also in case of tail-recursion optimization.

Currently hooking such functions is not supported and in fact this is not even detected. Detection: Search for the end of the function (which has its own problems), keep track of all jumps into the first few bytes.

3) Other threads might try to execute the code as it is overwritten - if that happens shit hits the fan and the normal working of the application will be disrupted. There are two methods of overcoming that problem: a) “The stop-the-world approach” stops all threads to hinder them from executing.

  That makes the hooking time intensive and easily detectable.

b) Writing all the problematic modifications atomically. That’s not doable for > 8bytes.

  How is that write reflected in the instruction cache?
  Instruction fetches follow a different memory model (no lock/unlock & µOp Caches)

c) The approach described in “Living on the edge: Rapid-toggline probes with cross modification on x86”

  Firstly writing a INT3 to the code which lets all other threads who execute that code jump into an newly
  installed execution handler with a spin loop until the hooking is done - i.e. execution can be safely
  resumed.
  Then the code is overwritten atomically with respect to cache lines.
  Lastly the exception handler is deactived.

As this is a x64 hooking library running on x64 the overwritten code is fairly long, making the occurence of the problems detailed above very likely.