Hello, I have been doing some work with anti-cheat drivers recently, and I've run into a problem with winedevice's design. Right now, since winedevice is just a normal user-space process, drivers can only access the address space of this process, and not that of the client process. This also means that drivers which rely on certain addresses being above the system address space start or below the user address space end, such as EasyAntiCheat.sys, may not work as intended.
I have a few ideas on how to solve this issue, and I'm curious whether you guys have any opinions on them or other solutions I haven't thought of.
1) Set the highest bit in certain pointers to satisfy the driver at hand, this may help EAC get farther, but it's hard to tell since a lot of the code is obfuscated well with virtualization.
2) Capitalize on the fact that on windows 7, the user-space addresses only go up to 2^43, not 2^48 like on Linux. We could reserve the top 5 bits for winedevice processes, and set up a vectored exception in instr.c to handle reads/writes to the client process's address space by a driver.
3) Run winedevice.exe in a VM environment to allow usage of the higher bits. This is the solution I've thought about the least, but I just wanted to mention it.
Am 24.03.19 um 03:26 schrieb Derek Lesho:
- Run winedevice.exe in a VM environment to allow usage of the higher
bits. This is the solution I've thought about the least, but I just wanted to mention it.
I remember that years ago we had an issue with a copy protection driver figuring out that it was running in Ring 3 by just using Ring 3 instructions (so we could not fake it by handling the ILLOPs). I do not remember the details though, but the conclusion was we might need a CPU emulator for this.
-
Derek Lesho -
Stefan Dösinger