Signature Pad(HID) and RDP

> So the only way is, I have to write an application which will open the
> 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.

--
Maxim S. Shatskih
Windows DDK MVP

http://www.storagecraft.com

HID shows up in the global namespace so they are accessible from any session

d

--

This posting is provided "AS IS" with no warranties, and confers no rights.


"Maxim S. Shatskih" <> wrote in message
news:#...
>> So the only way is, I have to write an application which will open the
>> 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.
>
> --
> Maxim S. Shatskih
> Windows DDK MVP
>
> http://www.storagecraft.com
>

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


--

This posting is provided "AS IS" with no warranties, and confers no rights.


"Sri" <> wrote in message
news:0DDC1357-9ACB-4A2F-8245-...
> Ray,
>
> 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?
>
> Sri
>
> "Ray Trent" wrote:
>
>> Well, yes, the workaround I suggested was a filter driver with a
>> 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.
>>
>> Sri wrote:
>> > Ray,
>> > 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" wrote:
>> >
>> >> Well, obviously one could write a filter driver that provides a
>> >> separate
>> >> 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
>> >>
>>
>>
>> --
>> Ray
>>

Doron to the rescue again.

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

You are right Doron. The UsagePage is 0x0D and the usage is 0x01.

Thank you very much. This solution works!!

"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
>
>
> --
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>
> "Sri" <> wrote in message
> news:0DDC1357-9ACB-4A2F-8245-...
> > Ray,
> >
> > 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?
> >
> > Sri
> >
> > "Ray Trent" wrote:
> >
> >> Well, yes, the workaround I suggested was a filter driver with a
> >> 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.
> >>
> >> Sri wrote:
> >> > Ray,
> >> > 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" wrote:
> >> >
> >> >> Well, obviously one could write a filter driver that provides a
> >> >> separate
> >> >> 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
> >> >>
> >>
> >>
> >> --
> >> Ray
> >>
>

Ray,
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" wrote:

> Doron to the rescue again.
>
> 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
>

Glad you're concerned. Do be careful how you test it. I've found it
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.

Sri wrote:
> Ray,
> 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" wrote:
>
>> Doron to the rescue again.
>>
>> 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
>>


--
Ray

Doron,
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

"Sri" wrote:

> You are right Doron. The UsagePage is 0x0D and the usage is 0x01.
>
> Thank you very much. This solution works!!
>
> "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
> >
> >
> > --
> >
> > This posting is provided "AS IS" with no warranties, and confers no rights.
> >
> >
> > "Sri" <> wrote in message
> > news:0DDC1357-9ACB-4A2F-8245-...
> > > Ray,
> > >
> > > 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?
> > >
> > > Sri
> > >
> > > "Ray Trent" wrote:
> > >
> > >> Well, yes, the workaround I suggested was a filter driver with a
> > >> 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.
> > >>
> > >> Sri wrote:
> > >> > Ray,
> > >> > 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" wrote:
> > >> >
> > >> >> Well, obviously one could write a filter driver that provides a
> > >> >> separate
> > >> >> 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
> > >> >>
> > >>
> > >>
> > >> --
> > >> Ray
> > >>
> >

the registry value I indicated below works on vista and later, not on XP. I
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" <> wrote in message
news:E98979A7-4FD2-48DE-81F6-...
> Doron,
> 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
>
> "Sri" wrote:
>
>> You are right Doron. The UsagePage is 0x0D and the usage is 0x01.
>>
>> Thank you very much. This solution works!!
>>
>> "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
>> >
>> >
>> > --
>> >
>> > This posting is provided "AS IS" with no warranties, and confers no
>> > rights.
>> >
>> >
>> > "Sri" <> wrote in message
>> > news:0DDC1357-9ACB-4A2F-8245-...
>> > > Ray,
>> > >
>> > > 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?
>> > >
>> > > Sri
>> > >
>> > > "Ray Trent" wrote:
>> > >
>> > >> Well, yes, the workaround I suggested was a filter driver with a
>> > >> 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.
>> > >>
>> > >> Sri wrote:
>> > >> > Ray,
>> > >> > 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" wrote:
>> > >> >
>> > >> >> Well, obviously one could write a filter driver that provides a
>> > >> >> separate
>> > >> >> 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
>> > >> >>
>> > >>
>> > >>
>> > >> --
>> > >> Ray
>> > >>
>> >

Doron,
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:

> the registry value I indicated below works on vista and later, not on XP. I
> 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" <> wrote in message
> news:E98979A7-4FD2-48DE-81F6-...
> > Doron,
> > 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
> >
> > "Sri" wrote:
> >
> >> You are right Doron. The UsagePage is 0x0D and the usage is 0x01.
> >>
> >> Thank you very much. This solution works!!
> >>
> >> "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
> >> >
> >> >
> >> > --
> >> >
> >> > This posting is provided "AS IS" with no warranties, and confers no
> >> > rights.
> >> >
> >> >
> >> > "Sri" <> wrote in message
> >> > news:0DDC1357-9ACB-4A2F-8245-...
> >> > > Ray,
> >> > >
> >> > > 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?
> >> > >
> >> > > Sri
> >> > >
> >> > > "Ray Trent" wrote:
> >> > >
> >> > >> Well, yes, the workaround I suggested was a filter driver with a
> >> > >> 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.
> >> > >>
> >> > >> Sri wrote:
> >> > >> > Ray,
> >> > >> > 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" wrote:
> >> > >> >
> >> > >> >> Well, obviously one could write a filter driver that provides a
> >> > >> >> separate
> >> > >> >> 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
> >> > >> >>
> >> > >>
> >> > >>
> >> > >> --
> >> > >> Ray
> >> > >>
> >> >
> .
>