This is the problem with starting with a “requirement” and inferring a
precise implementation. You are heading down the wrong path here. You have
the wrong “requirement”, that is, a requirement that says “hide the mouse
position for windows except mine”, when the correct requirement would have
been written “prevent other applications from seeing the mouse position
within my application”. The first requirement contains an implementation
specification, and therefore is not actually a “requirement” in the formal
sense. It specifies *how* to achieve a goal, instead of specifying the
goal.
In general, if you need to prevent classic malware from intercepting mouse
positions, the trick is to do it in a separate “desktop” at the application
level. Go read about desktops.
The issue here is that you can’t hook across desktops, so if your login
screen is on its own desktop, classic malware, which is running in the
user’s default login session, can’t see this other desktop and can’t hook
it. If someone has figured out how to install a rootkit or other kernel
malware, it is unlikely you will be able to lock them out, desktop or not.
So the usual limited assumption is classic malware, some application-level
program that does a mouse hook (SetWindowsHookEx) call.
But you have taken a poorly-written security “requirement” (if it is
possible to dignify such a sloppily-written specification as a
“requirement”) and inferred the implementation it suggests, which is
probably the wrong solution because it doesn’t really solve the problem you
are trying to solve. The problems you are seeing are the consequence of
trying to solve the problem using the wrong technique. You have gotten
caught up in the idea that filter drivers are somehow going to magically
solve this problem, and I’m reasonably certain this is not going to work.
The reason is that you have tried to couple kernel behavior to incidental
application level state (a particular window). It is not clear why you have
chosen this complex solution without investigating the use of desktops, but
strongly suggest you look at desktops first. There is an entire subculture
of desktop programming that exists at user level, and while I am not an
expert, I have seen lenghty discussions of these techniques, and code
samples. I suggest a google search for the topic, plus reading about
desktop and window station APIs.
joe
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Thursday, November 18, 2010 2:09 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Hook mouse based on WDK moufiltr.
I have a requirement for hook mouse driver, to hide mouse position for
windows except mine.
I started from wdk example: moufiltr.
The comments said, I should do something in MouFilter_ServiceCallback, But I
also noticed that there is a function called MouFilter_IsrHook. I start from
here.
I get each MOUSE_INPUT_DATA in MouFilter_IsrHook, and add 4 to LastX, It
works. my mouse will always move to right quickly even if you move it to
left.
Since the lastX/lastY are set relative to the previous location, so what I
do is:
First, set current cursor position to control device, saved in a global
value (x, y).
Second, in MouFilter_IsrHook, all LastX/LastY is added to (x, y).
Last, return (x, y) to user mode app through IOCTL.
All these changes do work, but the location from my driver is different with
system (get by GetCursorPos). Looks like it moves faster than system.
I think maybe caused the system setting of mouse speed, so I change the
motion setting to fast, It’s same.
My question:
-
what’s wrong with my implement? should I do it in
MouFilter_ServiceCallback? (At first I do some DbgPrint in
MouFilter_ServiceCallback and MouFilter_IsrHook, looks like after invoke 4
MouFilter_IsrHook, 1 MouFilter_ServiceCallback is invoked.)
-
If driver motion only faster, then when I move back to the original point
(where I set it to kernel), the value should be same, but in my test, it
isn’t. How can I correct it ?
NTDEV is sponsored by OSR
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
–
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.