From: xxxxx@heinostenkoti.com Sent: Thursday, October 15, 2015 6:49 AM To: Windows System Software Devs Interest List Subject: RE:[ntdev] Mouclass upper filter with RDP
I cannot install anything to the client: InvisaPC?KVM extension, switching, and remote desktop solutions.
Anyway when I test it with my windows 10, something happens in remote desktop connection. Mouse clicks are not received…
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-593361- xxxxx@lists.osr.com] On Behalf Of xxxxx@heinostenkoti.com
Sent: 15 October 2015 14:49
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Mouclass upper filter with RDP
I cannot install anything to the client: InvisaPC?KVM extension,
switching, and remote desktop solutions.
Anyway when I test it with my windows 10, something happens in remote
desktop connection. Mouse clicks are not received…
Windows 8+ provides a separate PnP stack for each input device in the
RDP sessions. Therefore if you write a PnP filter correctly you will
able to intercept keystrokes and mouse moves in the RDP sessions by
exactly same method as for “normal” console input devices.
No additional code needed.
Windows 7 has two non-PnP stacks for RDP input that are managed by
the termdd.sys. The activity in these stacks is invisible to the
normal PnP filters. if you need to support Windows 7 and earlier
versions look at the following solution:
How to enable a third-party driver to intercept and disable
the SAS keyboard sequence in Remote Desktop Protocol (RDP)
sessions for Windows 7, Windows Server 2008 R2, Windows 8
and Windows Server 2012
That is the news I wanted to hear! I remember reading that in Windows 8.1 and Windows Server 2012 R2 it should work.
Aleh can you give me some help how to enable it? I have used moufiltr example and installed the service and then added upper filter for mouclass…
The “moufiltr” sample from the Windows SDK was designed to work with PS/2 devices only.
Try to create mouse class filter driver. This is a more generic and more simple way
and you will able to filter PS/2, USB, RDP and all other mouse devices.
See “Keyboard and mouse class drivers”, “Mouclass Driver Reference” and other related
topics in the MSDN. This is a documented way and all information is publicly available.
I started this discussion with: “I have managed to create my first upper filter driver for mouclass and it is working fine in WS2012R2.” And it works for for USB mouse devices… But with RDP it disables mouse clicks and is not changing the mouse moves as I wanted, so I think it is not working at all.
> The “moufiltr” sample from the Windows SDK was designed to work with PS/2 devices only.
At least “kbdfiltr” from the samples have the code both for generic PnP keyboard filter (between kbdclass and the port driver), as also for PS/2 i8042prt plugin callbacks.
Don’t remember about “moufiltr”, it is probably the same.
1 moufilyr has ps2 specific code in it, but it will run on any mouse stack
2 for the vast majority of people, you want your filter before mouclass. After is not the best place for it. The amount of complexity you deal with being before is much smaller than after
From: xxxxx@mail.ru Sent: Friday, October 16, 2015 6:25 AM To: Windows System Software Devs Interest List Subject: RE:[ntdev] Mouclass upper filter with RDP
Heinis wrote: > > I think it is not working at all.
Just try to hook mouclass!IRP_MJ_READ handler on Windows 8 or higher and you will capture the RDP mouse “traffic”.
> My setting is for class is > UpperFilters=moufiltr mouclass > is that ok?
It is better to load filter after mouclass: UpperFilters = mouclass MyFilter
At least “kbdfiltr” from the samples have the code both for generic PnP keyboard
filter (between kbdclass and the port driver), as also for PS/2 i8042prt plugin
callbacks.
I mean the following:
WDK 7.1/moufiltr/Moufiltr.htm:
“The .inf file included in this sample is designed to filter a PS/2 mouse”.
Doron Holan wrote:
for the vast majority of people, you want your filter before mouclass. After
is not the best place for it. The amount of complexity you deal with being
before is much smaller than after
The code (when I was last looking into it years ago) contains both i8042prt plugin (PS/2 only) and the generic PnP mouse filter, below mouclass and above the port.
You only filter only the “register callback” IRP and wrap a decorator around the callback.
The callback sees the array of mouse message structures and head/tail pointers in it.
From: xxxxx@heinostenkoti.com Sent: Monday, October 19, 2015 10:05 AM To: Windows System Software Devs Interest List Subject: RE:[ntdev] Mouclass upper filter with RDP
I am using SC CREATE moufiltr binPath=C:\windows… type= kernel to install the service. Then I added UpperFilters=moufiltr mouclass to registry.
Now I get message: “Trying to disable physical device not enabled in this session” and the mouse is not working in rdp.
Please help… I am new to driver programming… I will buy you a beer if you come to Finland!
What specific operation is returning the “Tryng to disable…” message? Neither adding the registry value or SC registration will result in that type of message.
I am using SC CREATE moufiltr binPath=C:\windows… type= kernel to install the service. Then I added UpperFilters=moufiltr mouclass to registry. Now I get message: “Trying to disable physical device not enabled in this session” and the mouse is not working in rdp. Please help… I am new to driver programming… I will buy you a beer if you come to Finland!
That is what I saw in debugview. I thought it was telling me something went wrong.
Is it enough, if I just use SC CREATE and then add my filter to UpperFilters section?
I am using windows driver frameworks sample to do this… I am trying to fing how I can debug my source.
I think I have seen my _DeviceAdd entry but nothing more after that…
That is what I saw in debugview. I thought it was telling me something went wrong.
Is it enough, if I just use SC CREATE and then add my filter to UpperFilters section?
Copy the driver into place, create the service, add the filter to
UpperFilters, then restart the device. That’s what it takes.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
FIlter driver is running in rdp fine. Now I should know the username of the rdp connection to be sure that this user is the one with the touchpad that needs to be corrected. It should do nothing for users with normal windows remote desktop connection.
LookupAccountName SID->name resolution sometimes requires an RPC/XML/SOAP query to the AD domain controller, which is surely out of the scope of the kmode code.
DriverEntry/DeviceAdd, even for RDP input stack, run in a system thread, and you cannot get any user SIDs there.
In kmode, you can get the IRP’s originating thread, and then thread’s token object, and then query the SID from the token.
Also note that the same logon/UI session can continue across several RDP connections from different clients, or switch from RDP to physical display/input and back. Do not forget this in your design.
wrote in message news:xxxxx@ntdev… > FIlter driver is running in rdp fine. Now I should know the username of the rdp connection to be sure that this user is the one with the touchpad that needs to be corrected. It should do nothing for users with normal windows remote desktop connection. > > Any api to get user in DriverEntry/DeviceAdd ? >