Compare commits

...

4 Commits

Author SHA1 Message Date
_xeroxz f5503c91a6 Update README.md
3 years ago
_xeroxz ced98231c7 Update README.md
3 years ago
_xeroxz 44ce3a92a8 Merge branch 'master' into 'master'
3 years ago
oxygxn 7bc7b532f2 Update README.md
3 years ago

@ -1,10 +1,12 @@
# If you are looking for multi-vm support please [refer to this branch](https://githacks.org/_xeroxz/vmhook-eac/-/tree/multi-vm)
![](https://githacks.org/_xeroxz/vmhook-eac/-/raw/a2e38c76b1fb9a53527c2441b06bb25b768d9959/bin/running-with-patch.png)
### About
### About - Hooking Into The VMProtect 2 Virtual Machine And Spoofing Memory Reads
This is a small POC to show an interesting design weakness in VMProtect 2 which can aid an attacker in such a way that reading memory can be manipulated in a centralized way. In this POC all `READQ/DW/B` virtual instructions are hooked, when virtualized integrity check routines try and read unwriteable sections, the pointer is changed to an untouched clone of the driver. This means all inlined virtualized integrity checks can be bypassed with a few lines of code. This is not possible without the aid of VMProtect 2's design... So im refering to having reusable vm handlers as a design weakness...
***This is less about EasyAntiCheat and more about a design weakness in VMProtect 2... EasyAntiCheat is mearly used for a real world example, in addition, nothing released here is undetected, it has plenty of detection vectors...***
***This is less about EasyAntiCheat and more about a design weakness in VMProtect 2... EasyAntiCheat is merely used for a real world example, in addition, nothing released here is undetected, it has plenty of detection vectors...***
```
00000603 67.09356689 [vmhook-eac [core number = 20]] READ(Q/DW/B) EasyAntiCheat.sys+0x1000
@ -18,7 +20,7 @@ This is a small POC to show an interesting design weakness in VMProtect 2 which
#### SHA1 Integrity Checks
Integrity checks outside of the VMProtect 2 virtual machine are not effected by my POC. In particular, a SHA1 hash of both `.text` and `.eac0` is computed, the SHA1 hash function itself is not virtualized so it is not effected by my `READQ/DW/B` hook.
Integrity checks outside of the VMProtect 2 virtual machine are not effected by my POC. In particular, a SHA1 hash of both `.text` and `.eac0` is computed, the SHA1 hash function itself is not virtualized so it is not affected by my `READQ/DW/B` hook.
```
00126334 68.50553894 [vmhook-eac [core number = 13]]sha1 hash data = 0xFFFFF80061B91000, len = 0x51d28, result = 0xFFFFFE8158E60BF0

Loading…
Cancel
Save