Signature Pad(HID) and RDP
Sri
I'm working on a Signature pad device (USB HID device) on XP SP3 . This has
one top level collection (usage=1, usagepage=13). There is an application
which waits for the device notification and once the device is plugged in, it
opens a handle by the symbolic link and then issues a ReadFile request to
read the reports. This works fine on a standalone pc.
Now if I do an RDP to the same pc and then run this application, then the
data never reaches the application!! There is only a RAW Pdo created by
HidClass for this device and no one on top of this pdo. So does it mean that
HidClass is doing some additional checks on, may be the file object or
something else, and restricting the data only to console session?
Any inputs are welcome.
Thanks in advance
Sri
Doron Holan [MSFT]
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Sri" <S...@discussions.microsoft.com> wrote in message
news:F307FA54-9235-4291...@microsoft.com...
Sri
Createfile succeeds. There is absolutely no problem. But my ReadFile waits
"forever". Even though the device is giving data (I just have to scratch
something on the signature pad), my ReadFile does not get signalled. The only
possibile reason I could think of is that the HidClass.sys is validating the
file handle (or something else??) and when it finds out that this handle is
for an application running in an RDP session, it does not complete the
IRP_MJ_READ (even though data is available in HidClass's internal queue).
Is my understanding correct? If so, how can I overcome this? I'm basically
targetting non-Mouse/Keyboard devices in TS environment.
Any inputs are welcome
Thanks,
Sri
Maxim S. Shatskih
> targetting non-Mouse/Keyboard devices in TS environment.
I can hardly imagine how this can be solvable even in theory.
RDP protocol does not know your device, so, if the device is connected to the RDP client machine, then the RDP apps will not have its input.
And, the RDP server is usually the headless box in a locked closet, so, connecting the device to it is useless too.
--
Maxim S. Shatskih
Windows DDK MVP
ma...@storagecraft.com
http://www.storagecraft.com
Sri
> RDP protocol does not know your device, so, if the device is connected to the RDP client machine, then the RDP apps will not have its input.
>
device. So the data from this device does not go to the RIT (and its data
queue). So why does not the app launched in RDP session able to read data by
issuing a ReadFile?
> And, the RDP server is usually the headless box in a locked closet, so, connecting the device to it is useless too.
>
I agree. There is no point connecting the device to a server and then do an
RDP connection. Actually this device has been redirected to the XP machine
using usb-over-network. So this device is enumerated on a virtual usb bus.
Just to keep things simple, I gave the example of a standalone pc (as the
behavior is same).
Am I wrong somewhere?
Thanks,
Sri
Doron Holan [MSFT]
the request's session ID does not match the current active console session,
it will not complete the request. this is so an app in a non console
session cannot snoop in on the data of a device being used by the console.
I don't think there is a workaround, I will look though
d
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Sri" <S...@discussions.microsoft.com> wrote in message
news:BCA7C052-32CF-433D...@microsoft.com...
Ray Trent
control device object that an app from any session could query for the data.
However, as Doron points out, this is a security hole. That's not great
for any input device, but it seems especially egregiously *bad* for a
signature capture device.
Doron Holan [MSFT] wrote:
> hidclass does indeed look at the session ID when processing IO
> requests. if the request's session ID does not match the current active
> console session, it will not complete the request. this is so an app in
> a non console session cannot snoop in on the data of a device being used
> by the console.
>
> I don't think there is a workaround, I will look though
>
> d
>
--
Ray
Sri
Actually the application can directly open (using CreateFile) the RAW pdo.
So I do not need a filter driver and a control device object. The point here
is, after opening a handle to the device, the application issues ReadFile and
these are not completed by HIDClass if the app is running in a non-console
session.
Any suggestions/work arounds for this?
Thanks,
Sri
Ray Trent
secondary control device that you send IOCTLs (or Reads) to.
As far as I can tell (assuming Doron is right... and he usually is :-),
that would be the only way to get around this.
What I was pointing out is that *any* way you do this will end up being
a security hole, which is probably a bad idea for a signature capture
device.
--
Ray
Sri
Thanks for your reply.
I'm not sure I understood the filter driver suggestion. My understanding is
that you are suggesting an upper filter driver to the raw pdo that HIDClass
creates. Thats fine. Now, there should be someone who would issue IRP_MJ_READ
request(s). In case of mouse and keyboard, the RIT thread does it (as I
understand). But this is a non-mouse/keyboard device. So there is no one to
issue IRP_MJ_READ request(s).
So the only way is, I have to write an application which will open the
device (CreateFile) and starts issuing IRP_MJ_READs (ReadFile). But the catch
here is, these read requests are from a RDP session. So the HIDClass does not
complete the requests. So whats the point in having an upper filter driver?
The read IRPs are never completed!
According to my understanding, if the HIDClass had not checked for session
id, then my application would have worked for RDP session as well.
Is it possible to issue read requests from an upper filter driver (as I
assume this would be treated as a kernel mode handle) directly to the raw
pdo? Will these requests be completed by the HIDClass? If this is possible,
then it would solve my problem.
Please correct me if my understanding is wrong.
Any suggestions?
Maxim S. Shatskih
> device (CreateFile) and starts issuing IRP_MJ_READs (ReadFile).
To access non-keyboard and non-mouse HID devices from user mode, there is some HID-related DLL with API. Also I think DirectInput can help.
>But the catch
> here is, these read requests are from a RDP session.
You cannot access custom HID devices from RDP session. For RDP session, only a tiny subset of the devices are emulates - video, keyboard, mouse, and probably redirected file system (\\tsclient), redirected printers and audio.
But not HID.
Doron Holan [MSFT]
d
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Maxim S. Shatskih" <ma...@storagecraft.com.no.spam> wrote in message
news:#9txGlF2...@TK2MSFTNGP05.phx.gbl...
Doron Holan [MSFT]
session checking security on a usage page of 0x0D (digitizer) with usages of
pen/digitizer/light pen/touch screen (1-4). I am assuming you have hit this
special case. You can turn off session security checking by adding the
following value to the PDO devnode's Device Parameter
"SessionSecurityEnabled" : REG_DWORD : 0x0
and then restart the device (disable/enable or unplug/replug). You can
write an INF to match against the PDO's hwid and set the value in the INF as
well
d
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Sri" <S...@discussions.microsoft.com> wrote in message
news:0DDC1357-9ACB-4A2F...@microsoft.com...
Ray Trent
However, I'll still say: Be very careful if you're going to do this!
If you enable reading that device from the RDP session, then it can
equally be opened by a background process running in a different user's
session (e.g. either via Terminal Services, or via Fast User Switching,
or by other methods).
The practical effect is that one user could silently intercept another
user's signature data. This is probably a very bad idea. There's a real
reason why Windows has this session security check and also opens
keyboard and mouse devices for exclusive access.
It might be possible to have your app open the device for exclusive
access, which I believe would fail if someone else is snooping on it
from another session, and prevent someone from doing the same. However,
that will take careful research, design, and testing. And I'm not sure
it's possible.
Doron Holan [MSFT] wrote:
> what is the usage page and usage for your device? currently you only
> get session checking security on a usage page of 0x0D (digitizer) with
> usages of pen/digitizer/light pen/touch screen (1-4). I am assuming you
> have hit this special case. You can turn off session security checking
> by adding the following value to the PDO devnode's Device Parameter
>
> "SessionSecurityEnabled" : REG_DWORD : 0x0
>
> and then restart the device (disable/enable or unplug/replug). You can
> write an INF to match against the PDO's hwid and set the value in the
> INF as well
>
> d
>
>
--
Ray
Sri
Thank you very much. This solution works!!
Sri
That's correct. Doron to the rescue again (as usual :-)
I totally agree with the concerns about security here. First of all, the
device is opened in an exclusive mode by the app. And secondly, this is used
only on XP without fast user switching enabled as of now. We definitely do
not want to take this on TS compromising on the security. We are looking at
other possibilities to take it on to TS.
Thanks for your replies. It's very much appreciated.
Ray Trent
tricky to predict under exactly what happens when you open a file
exclusively, depending on exactly what flags you specify, and whether
someone else has the file opened in shared mode at the time.
Note, however, that not having fast user switching enabled doesn't
protect you here. That was just one example of alternate sessions. Any
task running from the Task Scheduler gets its own session. Another user
can run a scheduled task that stays in the background forever and snoops
on things like this.
It's probably possible to make it secure... but you should design it
while assuming that someone will be able to attack it this way.
--
Ray
Sri
I found that this works ONLY till Win xp. Is there a different way to
achieve the same on Vista, Win Server 2008 and Win 7 ?
Thanks,
Sri
Doron Holan [MSFT]
am a little confused as to what you are saying works on XP but not on vista
and later
d
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Sri" <S...@discussions.microsoft.com> wrote in message
news:E98979A7-4FD2-48DE...@microsoft.com...
Sri
Thanks for your inputs. I was testing the same device on different platforms
and that is the reason for this delay. (setting up different platforms was
time consuming!).
These are the platforms that I tested and the corresponding results. The
device I considered is a USB signature pad device (with usage = 0x01,
usagepage = 0x0D).
1. XP SP3
-->Without the "SessionSecurityEnabled" (0), device does not work over RDP.
-->WIth "SessionSecurityEnabled"(0), device works over RDP.
2. Win Server2003
-->Without the "SessionSecurityEnabled" (0), device does not work over RDP.
-->WIth "SessionSecurityEnabled"(0), device works over RDP.
3. Win Vista (Ultimate, SP1)
With or without "SessionSecurityEnabled" , the device does not work over RDP.
4. Win 7 (Ultimate)
The application provided by the vendor has compatibility issues. This
application works well as long as it is opened in the console. The moment I
open the same application in an RDP session, it simply crashes! So I could
not test the device.
Any thoughts? Am I missing something?
Thanks for your interest.
Sri
"Doron Holan [MSFT]" wrote:
> .
>
Toby
>
> - Show quoted text -
Hi Sri,
I have tried your recommendation but it didn't work. May be I was in
the wrong path, do you mind to advise the registry path for the above
entry?
Thanks,
Toby
Toby
>
> - Show quoted text -
Dear Sri
I have the same situation, but what is the path of the registry should
be put in ?