Winedevice address space discussion / request for feedback

Derek Lesho dereklesho52 at gmail.com
Sat Mar 23 19:26:28 CDT 2019


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.



More information about the wine-devel mailing list