Hi all, I develop anti-cheat solutions for games, and I was wondering if anybody had any insight into new process security measures that might become available in Longhorn. Currently, the major obstacle to stopping cheating on Windows is the fact that any user-level process can gain authority to read and/or modify the contents of another user-level process'' memory via ReadProcessMemory and WriteProcessMemory. These functions are also used quite often in virii and other exploits. Basically what I was wondering is if Longhorn is going to introduce any level of security whereby an application can protect the integrity of it''s memory and code, at the application level. Doing it at the system level would be pointless, as the players will almost always have system-level controls. Such a mechanism would be invaluable in stopping cheaters, although it is pretty certain they will find a way around it, atleast it will make their job much harder and free up processor time for the anti-cheat solutions to monitor other things. Any insight, or links to where I can read about Longhorn''s process security features would be great. THanks, Krippy

I think MS are running a Longhorn Dev Center with a whole load of articles on Longhorn apis etc. (I think it might be on MSDN?). For safety''s sake I''d assume that memory will be accessible - I guess if I wanted to do something like that & found that user mode access to other processes was blocked I''d look into a solution with a ring 0 driver; MS will have to have a well defined api for that kind of thing & obviously that would have access to anything on the system & more to the point could be contacted by user-mode (ring 3) processes (suddenly I''m seized by a want to know: are .NET apps sort of ring 4 processes or something ... there''s another sandbox in the way ). All that said, I think I''d be supprised if that kind of thing actually actively disappeared, if nothing else I imagine that those kind of things are used by user mode debuggers - which implies that either they will exist in longhorn, or that there must be an equivelent that will be introduced.

Well, I wouldn''t expect them to make it so that user level processes cannot communicate with other user-level processes at all. But what would be nice, not only from an anti-cheat perspective which I am sure is low on the MS totem-pole of priorities, but also in general security issues, is that an application be able to specify that level of security for it''s own process. If you want to debug an application that you engineered, you can have it allow process communication. When you go live, you should be able to disable it.

I know that they are enhancing the ''application domain'' paradigm, whereby related applications have another method of intercommunication besides process-to-process. But what about applications that are running outside of the application domain?

I can live with cheaters being able to do it via a ring-0 driver, as that would be well beyond the scope of 99.999% of kiddie cheat-makers out there. As it stands now, it is way too easy. It only takes a few hours from the time a title is released to the time cheats are being spread across the internet.

I''ll be scouring the MS website about this stuff in the coming days.

Thanks for the response

Peace

MS needs to replace the registery system.

Umm.. what does the registry system have to do with interprocess communications?

Theory: MS pledged to support all previous Windows apps. Some of them probably use other processes'' memory for legitimate purposes, so I doubt that this will be blocked. Furthermore, for these non-.Net app, the permission levels will probably be all-or-nothing. So my guess would be no.

Cédric

I am mainly concerned about managed apps, I understand that win32 apps will require the legacy features. I am one of those that believe that managed code will be well viable for most games by the time Longhorn is released, we should be pushing atleast 6 or 7 Ghz by the time it is released if Moore stays true to his word.

Allowing unrestricted interprocess communication on managed apps, combined with the whole Smart Client technology, sounds like a major recipe for a security disaster the more I think about it.

I just downloaded about a gig and a half worth of ''The Dot Net Show'', with a couple episodes on security features and architecture, and a couple of episodes on Longhorn, so maybe they will shed some light.

Peace