Feature Proposal: Implementing an interface to the object manager via shared memory

[Derek Lesho]

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.

[Alexandre Julliard]

Derek Lesho <dereklesho52(a)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
julliard(a)winehq.org