test case branch

README.md

@@ -85,6 +85,43 @@ _small:
 	ret
 ```
 
+Test case: Branch
+=================
+Instead of the FASM code I'll show the disassembled version, so you can see the
+instruction lengths & offsets.
+```ASM
+0026 | 48 83 E0 01 | and rax,1
+002A | 74 17       | je test_cases.0043 ----+
+002C | 48 31 C0    | xor rax,rax            |
+002F | 90          | nop                    |
+0030 | 90          | nop                    |
+0031 | 90          | nop                    |
+0032 | 90          | nop                    |
+0033 | 90          | nop                    |
+0034 | 90          | nop                    |
+0035 | 90          | nop                    |
+0036 | 90          | nop                    |
+0037 | 90          | nop                    |
+0038 | 90          | nop                    |
+0039 | 90          | nop                    |
+003A | 90          | nop                    |
+003B | 90          | nop                    |
+003C | 90          | nop                    |
+003D | 90          | nop                    |
+003E | 90          | nop                    |
+003F | 90          | nop                    |
+0040 | 90          | nop                    |
+0041 | 90          | nop                    |
+0042 | 90          | nop                    |
+0043 | C3          | ret  <-----------------+
+```
+
+This function has a branch in the first 5 bytes. Hooking it detour-style isn't
+possible without fixing that branch in the trampoline. The NOP sled is just so
+the hooking engine can't cheat and just put the whole function into the
+trampoline. Instead the jump in the trampoline needs to be modified so it jumps
+back to the original destinations
+
 (Preliminary) Results
 =====================
 +----------+-----+------+------------+---+------+----+-------+

test_cases/README.md

@@ -1,37 +0,0 @@
-Introduction
-============
-
-This project aims to give a simple overview on how good various x64 hooking
-engines (on windows) are. I'll try to write various functions, that are hard to
-patch and then see how each hooking engine does.
-
-I'll test:
-* [EasyHook](https://easyhook.github.io/)
-* [PolyHook](https://github.com/stevemk14ebr/PolyHook)
-* [MinHook](https://www.codeproject.com/Articles/44326/MinHook-The-Minimalistic-x-x-API-Hooking-Libra)
-* [Mhook](http://codefromthe70s.org/mhook24.aspx)
-
-(I'd like to test detours, but I'm not willing to pay for it. So that isn't
-tested :( )
-
-There are multiple things that make hooking difficult. Maybe you want to patch
-while the application is running -- in that case you might get race conditions,
-as the application is executing your half finished hook. Maybe the software has
-some self protection features (or other software on the system provides that,
-e.g. Trustee Rapport)
-
-Evaluating how the hooking engines stack up against that is not the goal here.
-Neither are non-functional criteria, like how fast it is or how much memory it
-needs for each hook. This is just about the challenges the function to be
-hooked itself poses.
-
-Namely:
-* Are jumps relocated?
-* What about RIP adressing?
-* If there's a loop at the beginning / if it's a tail recurisve function, does
-  the hooking engine handle it?
-* How good is the dissassembler, how many instructions does it know?
-* Can it hook already hooked functions?
-
-Test cases
-==========