瀏覽代碼

test case branch

master
aaaaaa aaaaaaa 6 年之前
父節點
當前提交
28cbcfc003
共有 2 個檔案被更改,包括 37 行新增37 行删除
  1. +37
    -0
      README.md
  2. +0
    -37
      test_cases/README.md

+ 37
- 0
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
=====================
+----------+-----+------+------------+---+------+----+-------+

+ 0
- 37
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
==========

Loading…
取消
儲存