Re: [ntdev] Invoking a usermode function from the Kernel.

NTDEV
1

You need to rethink your design. The reason why there are no KM equivalents of these APIs is that these activities are inappropriate for KM components. Remember that the OS in general and KM specifically is intended to serve requests for applications and not to decide to create arbitrary threads or changing page protection.

Now to your specific problem: for this to work, you need to know some things about the process you are trying to 'protect’ and the type of attack you are trying to protect against. Most likely, your goals will be achieved by detecting the existence of a 'cheat’ rather than preventing all possible corruption. Your goal will probably be best served by creating a UM service to analyze the memory space of your target. This needs no driver at all, and will be just as accurate as any other method in the presence of arbitrary malware. Look at ReadProcessMemory (http://msdn.microsoft.com/en-us/library/windows/desktop/ms680553(v=vs.85).aspx)

Sent from Surface Pro

From: xxxxx@gmail.com
Sent: ‎Friday‎, ‎November‎ ‎28‎, ‎2014 ‎3‎:‎25‎ ‎PM
To: Windows System Software Devs Interest List

The main hurdle is that there are a handful of hooks placed on the WinAPI but also internally in the target process, which i can’t really do without making the page writable using VirtualProtect.
Pretty much the same for VirtualQuery, which also seems to have no driver equivalent.

There are also some procedures that are written against Direct3D.

There is quite a bit of other stuff, but most of that is replicatable on driver level.

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

2

One should also remember that as your software is clearly targeted at end user’s machines, they will be in control of what software will be installed - including drivers. That implies that the KM / UM boundary has little meaning for your problem domain because cheats can be installed arbitrarily and there is no way for any KM component to defend against another that has been coded by those who have revers engineered its functionality. A UM process will fair just as well against general and targeted attacks - general or known ones are okay, but targeted attacks sink you either way

The ultimate solution is a server side implementation. With that implementation, you can’t prove foul play, but you can demonstrate patterns of behaviour inconsistent with reasonable human play - like 1000 mouse clicks in a second or significant differences from the expected rate of 'drop’ or 'hit’ percentage.

Of course, with your implementation, you can’t prove foul play either; and you might not even be able to detect it - stupid requirements don’t obviate the need for sound judgement

Sent from Surface Pro

From: xxxxx@osr.com
Sent: ‎Saturday‎, ‎November‎ ‎29‎, ‎2014 ‎9‎:‎28‎ ‎AM
To: Windows System Software Devs Interest List

Hmmmm… The fact that it’s been done before doesn’t make it wise. Or stable.

The last time we (OSR) were approached to develop a powerful anti-cheat system for videogames, we declined to help due to the level of hideousness required. We just couldn’t stomach it. This was several years back. We flat-out told the company to find somebody else to do their hackery. Perhaps the requirements with which you are dealing are different.

OK, so… no bullshit: I am not aware of any architecturally appropriate way to do what you’re asking, short of NtCreateThread and friends. Then again, there should be no reason why that family of functions wouldn’t work for your purposes.

Be aware that these APIs are undocumented for a number of reasons, not the least of which are that they can have side effects you might not anticipate and the parameters can (and DO) change among OS versions (or even service packs). You can never be sure of the stability of these interfaces because their parameters or behaviors could change in a FUTURE service pack or hot fix. And that’s not just random scare tactics. (For one example: I just had a discussion with another dev here at OSR about an “internal use only” API that was exposed in a public header file but never documented… the NUMBER OF PARAMETERS the function took changed between OS versions. Seriously.).

OK, so enough lecturing from me. Understand I’m not just writing for you, Mr. Spanjer… I’m writing for other who read this (including the archives).

Short of doing what you want to do via a service in user-mode, which I would still encourage, these *are* the most architecturally appropriate functions for doing what you want.

I have no idea if any of the above will be useful to you,

Peter
OSR
@OSRDrivers

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer