Signature Pad(HID) and RDP

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

what part fails? finding the device or CreateFile?

--

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


"Sri" <> wrote in message
news:F307FA54-9235-4291-AFE9-...
> Hi,
> 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
>
>

Thanks for your reply Doron.

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

"Doron Holan [MSFT]" wrote:

> what part fails? finding the device or CreateFile?
>
> --
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>
> "Sri" <> wrote in message
> news:F307FA54-9235-4291-AFE9-...
> > Hi,
> > 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
> >
> >
>

> Is my understanding correct? If so, how can I overcome this? I'm basically
> 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

http://www.storagecraft.com

Maxim,

> 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.
>
I did not follow this. The device I'm talking about is a non-mouse/keyboard
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

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

--

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


"Sri" <> wrote in message
news:BCA7C052-32CF-433D-B756-...
> Thanks for your reply Doron.
>
> 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
>
> "Doron Holan [MSFT]" wrote:
>
>> what part fails? finding the device or CreateFile?
>>
>> --
>>
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>>
>> "Sri" <> wrote in message
>> news:F307FA54-9235-4291-AFE9-...
>> > Hi,
>> > 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
>> >
>> >
>>

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

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,

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
>