Currently, two apps/drivers that I know of, Battleye (BEDaisy.sys) and EasyAnticheat (EasyAntiCheat.sys) utilize the object manager. Right now, we can only emulate this by setting the object pointers to handle values, and interpreting the pointers as such when app passes it to another function. The problem is, not all object pointers are opaque, and some apps (EAC) try to read the contents of the structure even when they documented as being opaque. To get around this, we could try filling in dummy data on a case-per-case basis, but this solution may not hold up on rapidly changing software like anti-cheat software.
My proposal is that we utilize shared memory, written to by the object manager in wineserver, and mapped as read only in all of the winedevice processes to implement the kernel's object manager interface. Wineserver would update data in the object structures as necessary, and when an driver calls something like ObReferenceObjectByHandle, we would request a pointer to the simulated structure.
I haven't worked out all of the kinks on how practical this would be, and am only getting started with my implementation, but I'm curious what you guys think of this idea. I know shared memory is generally not supposed to be used, but I can't think of anything else that would retain the accuracy.
Derek Lesho dereklesho52@gmail.com writes:
Currently, two apps/drivers that I know of, Battleye (BEDaisy.sys) and EasyAnticheat (EasyAntiCheat.sys) utilize the object manager. Right now, we can only emulate this by setting the object pointers to handle values, and interpreting the pointers as such when app passes it to another function. The problem is, not all object pointers are opaque, and some apps (EAC) try to read the contents of the structure even when they documented as being opaque. To get around this, we could try filling in dummy data on a case-per-case basis, but this solution may not hold up on rapidly changing software like anti-cheat software.
My proposal is that we utilize shared memory, written to by the object manager in wineserver, and mapped as read only in all of the winedevice processes to implement the kernel's object manager interface. Wineserver would update data in the object structures as necessary, and when an driver calls something like ObReferenceObjectByHandle, we would request a pointer to the simulated structure.
I haven't worked out all of the kinks on how practical this would be, and am only getting started with my implementation, but I'm curious what you guys think of this idea. I know shared memory is generally not supposed to be used, but I can't think of anything else that would retain the accuracy.
I suspect you'll find that it adds a lot of complexity to the server, for only a small gain in accuracy compared to the dummy data approach. There would still be many things that can't be done that way, and I'd be surprised if the subset that you can support would be enough to make copy protection apps happy.
But of course it's hard to tell what copy protection apps actually need, so don't let me discourage you from trying a prototype implementation and see how far you can get...
-
Alexandre Julliard -
Derek Lesho