_xeroxz
64193b0703
|
3 years ago | |
---|---|---|
bin | 3 years ago | |
dependencies | 3 years ago | |
include | 3 years ago | |
src | 3 years ago | |
.clang-format | 3 years ago | |
.gitignore | 3 years ago | |
.gitmodules | 3 years ago | |
LICENSE | 3 years ago | |
README.md | 3 years ago | |
vmhook-eac.sln | 3 years ago | |
vmhook-eac.vcxproj | 3 years ago | |
vmhook-eac.vcxproj.filters | 3 years ago | |
vmhook-eac.vcxproj.user | 3 years ago |
README.md
This is a small POC to show an interesting design weakness in VMProtect 2 which aids an attacker in such a way that reading memory can be manipulated in a centralized way.
These vm handler indexes are for EasyAntiCheat.sys 6/23/2021, when the driver gets re-vmprotected these vm handler indexes need to be updated.
//
// vm handler indexes for READQ...
//
inline u8 g_readq_idxs[] = { 247, 215, 169, 159, 71, 60, 55, 43, 23 };
//
// vm handler indexes for READDW
//
inline u8 g_readdw_idxs[] = { 218, 180, 179, 178, 163, 137, 92, 22, 12 };
//
// vm handler indexes for READB
//
inline u8 g_readb_idxs[] = { 249, 231, 184, 160, 88, 85, 48, 9, 2 };
EAC_VM_HANDLE_OFFSET
contains the offset from the module base to the vm handler table, as of right now EAC only uses a single virtual machine in their VMProtect config so there is only a single vm handler table...
EAC_SHA1_OFFSET
contains the offset from the module base to the sha1 function...
you can locate this function by searching for SHA1 magic numbers: 0x67452301
, 0xEFCDAB89
0x98BADCFE
, 0x10325476
, 0xC3D2E1F0
. These crypto functions should be virtualized so their constant values cannot be located using IDA --> search "immidate values".
EAC_IMAGE_BASE
contains the "ImageBase" value inside of the OptionalHeaders field of the NT
headers... This value gets updated with the actual module base of the driver once loaded into
memory... I didnt want to read it off disk so I just made it a macro here...
#define EAC_VM_HANDLE_OFFSET 0xE93D
#define EAC_SHA1_OFFSET 0x4C00
#define EAC_IMAGE_BASE 0x140000000