Can I/O accesses be hooked?

NTDEV
1

I have an ExpressCard parallel port that uses PCI Express. It installs
properly as a PnP device. The problem is that I have customers with
brain-dead software that expects to access a parallel port at legacy
addresses. Generally, these people have custom applications that they have
written using an I/O proxy ActiveX control. The control exposes an
interface to the app to do INs and OUTs, and the control talks to a driver
that does the dirty work. Effectively, the application is bypassing the
driver that I supply. This works fine on the PCMCIA version of the card,
which can be forced into legacy I/O address ranges. On PCI Express,
however, we can’t obtain a legacy address.

What I would like to do is grab control of the rogue INs and OUTs to legacy
addresses and redirect them to the actual addresses used by my card. Is
there a way to hook the I/O access?

Chris Myers

2

There’s no reasonable way to intercept a driver that issues in/out
directly. To do this, assuming that you may not modify their software
and that they are indeed writing directly to some port with OUT, you’d
have to resort to something rather extreme like virtualization, unless
your chipset has something very specific and fortuitous. If you
absolutely can not modify their software, then the best thing that I
could think of is to either intercept their application in user mode,
their driver in kernel mode or filter it. Of these, the first would
certainly be the easiest, but it would be complicated, and it does beg
the question as to why they don’t just modify their software to use an
alternate configuration. The second would really suck and may not even
be possible, depending on what they do and except.

I just reread your post, and I’m now unclear: does the application
actually issue the IN/OUT? I don’t imagine so, but if so, then this is
very different. If the app does not run under an NTVDM, then the IO
instruction will cause a fault which you could handle, translate as
necessary. This would not be easy, but it is possible, assuming that
you can replace the handler without something like PatchGuard getting in
the way. If this executes under an NTVDM, then it is also is possible,
but quite different, as standard LPT1 access is, I believe handled
automatically, but I believe can be addressed by a VDD, if they still
exist. On this last scenario, I’m pretty much guessing, as I can’t say
that I have ever had the pleasure of working with a VDD or with NTVDM
much at all.

I have to ask: what on earth are they doing/why are they doing this? I
realize that this is not your choice, but this is the strangest setup I
have heard of in a while: an Active X control & driver to allow IO port
access. I figured this was going to be some old VDD or something like
that to support a HASP or whatnot.

All in all, this sounds a bad idea with a Capital B.

Good luck,

mm

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Chris Myers
Sent: Tuesday, September 04, 2007 17:04
To: Windows System Software Devs Interest List
Subject: [ntdev] Can I/O accesses be hooked?

I have an ExpressCard parallel port that uses PCI Express. It installs
properly as a PnP device. The problem is that I have customers with
brain-dead software that expects to access a parallel port at legacy
addresses. Generally, these people have custom applications that they
have written using an I/O proxy ActiveX control. The control exposes an
interface to the app to do INs and OUTs, and the control talks to a
driver that does the dirty work. Effectively, the application is
bypassing the driver that I supply. This works fine on the PCMCIA
version of the card, which can be forced into legacy I/O address ranges.
On PCI Express, however, we can’t obtain a legacy address.

What I would like to do is grab control of the rogue INs and OUTs to
legacy addresses and redirect them to the actual addresses used by my
card. Is there a way to hook the I/O access?

Chris Myers

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

3

Well, ActiveX control cannot deal wiith the hardware directly, can it??? Instead, it submits an IOCTL to a driver that does the actual job. What you have to do here is to attach your filtering device to the target one. At this point you will be able to modify the parameters that the target driver receives - there is no need to hook anything here…

Anton Bassov

4

Let me try again. After I hit send, I realized that my answer kind of
went all over the place, I’m not sure it makes any sense, and I think a
few things I said might just be wrong.

So, I have few questions:

  1. Where are the in/out instructions issued? The application? Their
    Driver? Your Driver.

  2. Are they replacing the standard port driver for the parallel port;
    filtering it; or just pretending that it isn’t there and dumping
    directly via IN/OUT (or via the HAL)?

  3. This beast consists of their application (16 or 32 bit?); their
    driver; and you driver? What does each do?

mm

From: Martin O’Brien
Sent: Tuesday, September 04, 2007 18:00
To: ‘Windows System Software Devs Interest List’
Subject: RE: [ntdev] Can I/O accesses be hooked?

There’s no reasonable way to intercept a driver that issues in/out
directly. To do this, assuming that you may not modify their software
and that they are indeed writing directly to some port with OUT, you’d
have to resort to something rather extreme like virtualization, unless
your chipset has something very specific and fortuitous. If you
absolutely can not modify their software, then the best thing that I
could think of is to either intercept their application in user mode,
their driver in kernel mode or filter it. Of these, the first would
certainly be the easiest, but it would be complicated, and it does beg
the question as to why they don’t just modify their software to use an
alternate configuration. The second would really suck and may not even
be possible, depending on what they do and except.

I just reread your post, and I’m now unclear: does the application
actually issue the IN/OUT? I don’t imagine so, but if so, then this is
very different. If the app does not run under an NTVDM, then the IO
instruction will cause a fault which you could handle, translate as
necessary. This would not be easy, but it is possible, assuming that
you can replace the handler without something like PatchGuard getting in
the way. If this executes under an NTVDM, then it is also is possible,
but quite different, as standard LPT1 access is, I believe handled
automatically, but I believe can be addressed by a VDD, if they still
exist. On this last scenario, I’m pretty much guessing, as I can’t say
that I have ever had the pleasure of working with a VDD or with NTVDM
much at all.

I have to ask: what on earth are they doing/why are they doing this? I
realize that this is not your choice, but this is the strangest setup I
have heard of in a while: an Active X control & driver to allow IO port
access. I figured this was going to be some old VDD or something like
that to support a HASP or whatnot.

All in all, this sounds a bad idea with a Capital B.

Good luck,

mm

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Chris Myers
Sent: Tuesday, September 04, 2007 17:04
To: Windows System Software Devs Interest List
Subject: [ntdev] Can I/O accesses be hooked?

I have an ExpressCard parallel port that uses PCI Express. It installs
properly as a PnP device. The problem is that I have customers with
brain-dead software that expects to access a parallel port at legacy
addresses. Generally, these people have custom applications that they
have written using an I/O proxy ActiveX control. The control exposes an
interface to the app to do INs and OUTs, and the control talks to a
driver that does the dirty work. Effectively, the application is
bypassing the driver that I supply. This works fine on the PCMCIA
version of the card, which can be forced into legacy I/O address ranges.
On PCI Express, however, we can’t obtain a legacy address.

What I would like to do is grab control of the rogue INs and OUTs to
legacy addresses and redirect them to the actual addresses used by my
card. Is there a way to hook the I/O access?

Chris Myers

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

5

You can just use the Debug Registers to hook IN/OUT.

This is available since Pentium (formerly the IN/OUT mode was not available).

Inaki.

De: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] En nombre de Martin O’Brien
Enviado el: mi?rcoles, 05 de septiembre de 2007 0:00
Para: Windows System Software Devs Interest List
Asunto: RE: [ntdev] Can I/O accesses be hooked?

There’s no reasonable way to intercept a driver that issues in/out directly. To do this, assuming that you may not modify their software and that they are indeed writing directly to some port with OUT, you’d have to resort to something rather extreme like virtualization, unless your chipset has something very specific and fortuitous. If you absolutely can not modify their software, then the best thing that I could think of is to either intercept their application in user mode, their driver in kernel mode or filter it. Of these, the first would certainly be the easiest, but it would be complicated, and it does beg the question as to why they don’t just modify their software to use an alternate configuration. The second would really suck and may not even be possible, depending on what they do and except.

I just reread your post, and I’m now unclear: does the application actually issue the IN/OUT? I don’t imagine so, but if so, then this is very different. If the app does not run under an NTVDM, then the IO instruction will cause a fault which you could handle, translate as necessary. This would not be easy, but it is possible, assuming that you can replace the handler without something like PatchGuard getting in the way. If this executes under an NTVDM, then it is also is possible, but quite different, as standard LPT1 access is, I believe handled automatically, but I believe can be addressed by a VDD, if they still exist. On this last scenario, I’m pretty much guessing, as I can’t say that I have ever had the pleasure of working with a VDD or with NTVDM much at all.

I have to ask: what on earth are they doing/why are they doing this? I realize that this is not your choice, but this is the strangest setup I have heard of in a while: an Active X control & driver to allow IO port access. I figured this was going to be some old VDD or something like that to support a HASP or whatnot.

All in all, this sounds a bad idea with a Capital B.

Good luck,

mm

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Chris Myers
Sent: Tuesday, September 04, 2007 17:04
To: Windows System Software Devs Interest List
Subject: [ntdev] Can I/O accesses be hooked?

I have an ExpressCard parallel port that uses PCI Express. It installs properly as a PnP device. The problem is that I have customers with brain-dead software that expects to access a parallel port at legacy addresses. Generally, these people have custom applications that they have written using an I/O proxy ActiveX control. The control exposes an interface to the app to do INs and OUTs, and the control talks to a driver that does the dirty work. Effectively, the application is bypassing the driver that I supply. This works fine on the PCMCIA version of the card, which can be forced into legacy I/O address ranges. On PCI Express, however, we can’t obtain a legacy address.

What I would like to do is grab control of the rogue INs and OUTs to legacy addresses and redirect them to the actual addresses used by my card. Is there a way to hook the I/O access?

Chris Myers

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

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

6

This is true; it is one the things that I filed under “not reasonable.” Halting the machine to facilitate the insanity this dev’s client perpetrates is, in my opinion, not a very good idea. Debugging would also be interesting.

mm

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of I?aki Castillo
Sent: Wednesday, September 05, 2007 05:25
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Can I/O accesses be hooked?

You can just use the Debug Registers to hook IN/OUT.

This is available since Pentium (formerly the IN/OUT mode was not available).

Inaki.

De: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] En nombre de Martin O’Brien
Enviado el: mi?rcoles, 05 de septiembre de 2007 0:00
Para: Windows System Software Devs Interest List
Asunto: RE: [ntdev] Can I/O accesses be hooked?

There’s no reasonable way to intercept a driver that issues in/out directly. To do this, assuming that you may not modify their software and that they are indeed writing directly to some port with OUT, you’d have to resort to something rather extreme like virtualization, unless your chipset has something very specific and fortuitous. If you absolutely can not modify their software, then the best thing that I could think of is to either intercept their application in user mode, their driver in kernel mode or filter it. Of these, the first would certainly be the easiest, but it would be complicated, and it does beg the question as to why they don’t just modify their software to use an alternate configuration. The second would really suck and may not even be possible, depending on what they do and except.

I just reread your post, and I’m now unclear: does the application actually issue the IN/OUT? I don’t imagine so, but if so, then this is very different. If the app does not run under an NTVDM, then the IO instruction will cause a fault which you could handle, translate as necessary. This would not be easy, but it is possible, assuming that you can replace the handler without something like PatchGuard getting in the way. If this executes under an NTVDM, then it is also is possible, but quite different, as standard LPT1 access is, I believe handled automatically, but I believe can be addressed by a VDD, if they still exist. On this last scenario, I’m pretty much guessing, as I can’t say that I have ever had the pleasure of working with a VDD or with NTVDM much at all.

I have to ask: what on earth are they doing/why are they doing this? I realize that this is not your choice, but this is the strangest setup I have heard of in a while: an Active X control & driver to allow IO port access. I figured this was going to be some old VDD or something like that to support a HASP or whatnot.

All in all, this sounds a bad idea with a Capital B.

Good luck,

mm

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Chris Myers
Sent: Tuesday, September 04, 2007 17:04
To: Windows System Software Devs Interest List
Subject: [ntdev] Can I/O accesses be hooked?

I have an ExpressCard parallel port that uses PCI Express. It installs properly as a PnP device. The problem is that I have customers with brain-dead software that expects to access a parallel port at legacy addresses. Generally, these people have custom applications that they have written using an I/O proxy ActiveX control. The control exposes an interface to the app to do INs and OUTs, and the control talks to a driver that does the dirty work. Effectively, the application is bypassing the driver that I supply. This works fine on the PCMCIA version of the card, which can be forced into legacy I/O address ranges. On PCI Express, however, we can’t obtain a legacy address.

What I would like to do is grab control of the rogue INs and OUTs to legacy addresses and redirect them to the actual addresses used by my card. Is there a way to hook the I/O access?

Chris Myers

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

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

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

7

Martin O’Brien wrote:

This is true; it is one the things that I filed under “not
reasonable.” Halting the machine to facilitate the insanity this
dev’s client perpetrates is, in my opinion, not a very good idea.
Debugging would also be interesting.

I’m not sure why you would say that. The mechanism he is talking about
is exactly the same mechanism used by the WinDbg “br” command. It
doesn’t “halt the machine” – it just fires an interrupt.

It wouldn’t be easy, but it’s not unreasonable.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

8

My product is supplied with an INF to install using the standard built-in
parallel port driver.

The “beast” is the customer’s application, using an ActiveX control that
exposes APIs to do port I/O. The control calls into its own driver, and
that is where the IN/OUT instructions are issued. The application is
bypassing the parallel port driver.

The case at hand is using this:
http://www.jspayne.com/io/interface.html#Out
http: . I’ve seen other similar
third-party libraries to do this kind of thing. The right way to access the
port, of course, would be to open it and use standard APIs to read/write.
Unfortunately, I’m dealing with customers using brain-dead applications
written more like DOS bitbanging programs.

This was ok with PCMCIA cards, where we could put configuration overrides
into the INF file to force the card into legacy addresses. With PCI
Express, however, the bridge won’t allow our card to reside at legacy
addresses. The problem is these applications expecting the parallel port to
be sitting at 0x378 or 0x278.

Chris Myers



From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Tuesday, September 04, 2007 6:06 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Can I/O accesses be hooked?

Let me try again. After I hit send, I realized that my answer kind of went
all over the place, I’m not sure it makes any sense, and I think a few
things I said might just be wrong.

So, I have few questions:

1. Where are the in/out instructions issued? The application? Their
Driver? Your Driver.

2. Are they replacing the standard port driver for the parallel port;
filtering it; or just pretending that it isn’t there and dumping directly
via IN/OUT (or via the HAL)?

3. This beast consists of their application (16 or 32 bit?); their driver;
and you driver? What does each do?

mm

From: Martin O’Brien
Sent: Tuesday, September 04, 2007 18:00
To: ‘Windows System Software Devs Interest List’
Subject: RE: [ntdev] Can I/O accesses be hooked?

There’s no reasonable way to intercept a driver that issues in/out directly.
To do this, assuming that you may not modify their software and that they
are indeed writing directly to some port with OUT, you’d have to resort to
something rather extreme like virtualization, unless your chipset has
something very specific and fortuitous. If you absolutely can not modify
their software, then the best thing that I could think of is to either
intercept their application in user mode, their driver in kernel mode or
filter it. Of these, the first would certainly be the easiest, but it would
be complicated, and it does beg the question as to why they don’t just
modify their software to use an alternate configuration. The second would
really suck and may not even be possible, depending on what they do and
except.

I just reread your post, and I’m now unclear: does the application actually
issue the IN/OUT? I don’t imagine so, but if so, then this is very
different. If the app does not run under an NTVDM, then the IO instruction
will cause a fault which you could handle, translate as necessary. This
would not be easy, but it is possible, assuming that you can replace the
handler without something like PatchGuard getting in the way. If this
executes under an NTVDM, then it is also is possible, but quite different,
as standard LPT1 access is, I believe handled automatically, but I believe
can be addressed by a VDD, if they still exist. On this last scenario, I’m
pretty much guessing, as I can’t say that I have ever had the pleasure of
working with a VDD or with NTVDM much at all.

I have to ask: what on earth are they doing/why are they doing this? I
realize that this is not your choice, but this is the strangest setup I have
heard of in a while: an Active X control & driver to allow IO port access.
I figured this was going to be some old VDD or something like that to
support a HASP or whatnot.

All in all, this sounds a bad idea with a Capital B.

Good luck,

mm

_____

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Chris Myers
Sent: Tuesday, September 04, 2007 17:04
To: Windows System Software Devs Interest List
Subject: [ntdev] Can I/O accesses be hooked?

I have an ExpressCard parallel port that uses PCI Express. It installs
properly as a PnP device. The problem is that I have customers with
brain-dead software that expects to access a parallel port at legacy
addresses. Generally, these people have custom applications that they have
written using an I/O proxy ActiveX control. The control exposes an
interface to the app to do INs and OUTs, and the control talks to a driver
that does the dirty work. Effectively, the application is bypassing the
driver that I supply. This works fine on the PCMCIA version of the card,
which can be forced into legacy I/O address ranges. On PCI Express,
however, we can’t obtain a legacy address.

What I would like to do is grab control of the rogue INs and OUTs to legacy
addresses and redirect them to the actual addresses used by my card. Is
there a way to hook the I/O access?

Chris Myers

—
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

—
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</http:>

9

Chris,

It might be a PITA but you might see if you could create a filter
driver that attaches to libraries driver and finagles things. Not nice,
and as you indicated there are a bunch of these libraries out there, all of
which will need handling.

Start with a generic filter that debug prints the actions then passes
them on. I suspect you can get a decent read on the interface with a
little work. Then start creating a filter, that if things are going to the
“parallel port” you intercept the calls and do the work.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

“Chris Myers” wrote in message
news:xxxxx@ntdev…
> My product is supplied with an INF to install using the standard built-in
> parallel port driver.
>
> The “beast” is the customer’s application, using an ActiveX control that
> exposes APIs to do port I/O. The control calls into its own driver, and
> that is where the IN/OUT instructions are issued. The application is
> bypassing the parallel port driver.
>
> The case at hand is using this:
> http://www.jspayne.com/io/interface.html#Out
> http: . I’ve seen other similar
> third-party libraries to do this kind of thing. The right way to access
> the
> port, of course, would be to open it and use standard APIs to read/write.
> Unfortunately, I’m dealing with customers using brain-dead applications
> written more like DOS bitbanging programs.
>
> This was ok with PCMCIA cards, where we could put configuration overrides
> into the INF file to force the card into legacy addresses. With PCI
> Express, however, the bridge won’t allow our card to reside at legacy
> addresses. The problem is these applications expecting the parallel port
> to
> be sitting at 0x378 or 0x278.
>
> Chris Myers
>
>
>
>
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
> Sent: Tuesday, September 04, 2007 6:06 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Can I/O accesses be hooked?
>
>
>
> Let me try again. After I hit send, I realized that my answer kind of
> went
> all over the place, I’m not sure it makes any sense, and I think a few
> things I said might just be wrong.
>
>
>
> So, I have few questions:
>
>
>
> 1. Where are the in/out instructions issued? The application? Their
> Driver? Your Driver.
>
> 2. Are they replacing the standard port driver for the parallel port;
> filtering it; or just pretending that it isn’t there and dumping directly
> via IN/OUT (or via the HAL)?
>
> 3. This beast consists of their application (16 or 32 bit?); their
> driver;
> and you driver? What does each do?
>
>
>
> mm
>
>
>
>
>
>
>
> From: Martin O’Brien
> Sent: Tuesday, September 04, 2007 18:00
> To: ‘Windows System Software Devs Interest List’
> Subject: RE: [ntdev] Can I/O accesses be hooked?
>
>
>
> There’s no reasonable way to intercept a driver that issues in/out
> directly.
> To do this, assuming that you may not modify their software and that they
> are indeed writing directly to some port with OUT, you’d have to resort
> to
> something rather extreme like virtualization, unless your chipset has
> something very specific and fortuitous. If you absolutely can not modify
> their software, then the best thing that I could think of is to either
> intercept their application in user mode, their driver in kernel mode or
> filter it. Of these, the first would certainly be the easiest, but it
> would
> be complicated, and it does beg the question as to why they don’t just
> modify their software to use an alternate configuration. The second
> would
> really suck and may not even be possible, depending on what they do and
> except.
>
>
>
> I just reread your post, and I’m now unclear: does the application
> actually
> issue the IN/OUT? I don’t imagine so, but if so, then this is very
> different. If the app does not run under an NTVDM, then the IO
> instruction
> will cause a fault which you could handle, translate as necessary. This
> would not be easy, but it is possible, assuming that you can replace the
> handler without something like PatchGuard getting in the way. If this
> executes under an NTVDM, then it is also is possible, but quite
> different,
> as standard LPT1 access is, I believe handled automatically, but I
> believe
> can be addressed by a VDD, if they still exist. On this last scenario,
> I’m
> pretty much guessing, as I can’t say that I have ever had the pleasure of
> working with a VDD or with NTVDM much at all.
>
>
>
> I have to ask: what on earth are they doing/why are they doing this? I
> realize that this is not your choice, but this is the strangest setup I
> have
> heard of in a while: an Active X control & driver to allow IO port
> access.
> I figured this was going to be some old VDD or something like that to
> support a HASP or whatnot.
>
>
>
> All in all, this sounds a bad idea with a Capital B.
>
>
>
> Good luck,
>
>
>
> mm
>
>
> _____
>
>
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Chris Myers
> Sent: Tuesday, September 04, 2007 17:04
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Can I/O accesses be hooked?
>
>
>
> I have an ExpressCard parallel port that uses PCI Express. It installs
> properly as a PnP device. The problem is that I have customers with
> brain-dead software that expects to access a parallel port at legacy
> addresses. Generally, these people have custom applications that they
> have
> written using an I/O proxy ActiveX control. The control exposes an
> interface to the app to do INs and OUTs, and the control talks to a
> driver
> that does the dirty work. Effectively, the application is bypassing the
> driver that I supply. This works fine on the PCMCIA version of the card,
> which can be forced into legacy I/O address ranges. On PCI Express,
> however, we can’t obtain a legacy address.
>
>
>
> What I would like to do is grab control of the rogue INs and OUTs to
> legacy
> addresses and redirect them to the actual addresses used by my card. Is
> there a way to hook the I/O access?
>
>
>
> Chris Myers
>
>
>
>
> —
> 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
>
>
> —
> 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
>
></http:>

10

> You can just use the Debug Registers to hook IN/OUT.

What can you possibly make out of debug registers (apart from BSOD, of course) without hooking INT 1 handler??? If execution reaches system-provided INT 1 handler when kernel code generates INT 1 exception and no kernel debugger is around, the system is going to bugcheck. Therefore, the above solution requires IDT hooking, and there is no need to resort to IDT hooking if the whole thing can get done “properly” by attaching a filter to the target device…

Anton Bassov

11

xxxxx@hotmail.com wrote:

> You can just use the Debug Registers to hook IN/OUT.
>

What can you possibly make out of debug registers (apart from BSOD, of course) without hooking INT 1 handler??? If execution reaches system-provided INT 1 handler when kernel code generates INT 1 exception and no kernel debugger is around, the system is going to bugcheck. Therefore, the above solution requires IDT hooking, and there is no need to resort to IDT hooking if the whole thing can get done “properly” by attaching a filter to the target device…

This is true, IF the user/kernel interface for this thing maps each I/O
port request to an ioctl. However, some of the “portio” solutions
modify the I/O permission map to allow in and out instructions directly
from user space. In that case, the filter solution won’t help.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

12

Tim,

However, some of the “portio” solutions modify the I/O permission map to allow
in and out instructions directly from user space. In that case, the filter solution won’t help.

To be honest, it just did not get into my head that the target driver may go for so stupid and insecure solution. However, if it does, a filter will *probably* be of no help - it depends on when and how the above modification is applied. If it is done in response to IOCTL, then your filter can block just it. Otherwise, you are, indeed, out of luck - you have no option other than hooking INT 1 handler…

Anton Bassov

13

Chris Myers escribió:

I have an ExpressCard parallel port that uses PCI Express. It installs
properly as a PnP device. The problem is that I have customers with
brain-dead software that expects to access a parallel port at legacy
addresses. Generally, these people have custom applications that they
have written using an I/O proxy ActiveX control. The control exposes an
interface to the app to do INs and OUTs, and the control talks to a
driver that does the dirty work. Effectively, the application is
bypassing the driver that I supply. This works fine on the PCMCIA
version of the card, which can be forced into legacy I/O address
ranges. On PCI Express, however, we can’t obtain a legacy address.

What I would like to do is grab control of the rogue INs and OUTs to
legacy addresses and redirect them to the actual addresses used by my
card. Is there a way to hook the I/O access?

Chris Myers

After reading the entire thread, I would suggest a different aproach.
The problem could be solved rewriting the ActiveX (if it is only a I/O
proxy the ActiveX will have a little number of methods and no events.)
If you write an ActiveX with the same UID, the same methods and method
names and the same method parameters, their custom applications will use
your new ActiveX as if it is the old one. In this new ActiveX you can
make anything you need to achieve I/O access in a natural way.

HTH.

14

>> In this new ActiveX you can make anything you need to achieve I/O access in a natural way

This would also my preferred solution. Problem is however if the makers of the origianl ActiveX would allow this ( license
violation ? ). The “customer” of the OP could however ask the makers of the ActiveX to develop a variant of their ActiveX that talks
with the driver of the OP. The OP may however need to implement some additional interfaces to let talk the ActiveX control to the
driver. So , less effort for the OP , all costs for the “customer” :-).

C.

----- Original Message -----
From: “Julián Rodríguez Bajo”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Thursday, September 06, 2007 9:47 AM
Subject: Re:[ntdev] Can I/O accesses be hooked?

Chris Myers escribió:
> I have an ExpressCard parallel port that uses PCI Express. It installs properly as a PnP device. The problem is that I have
> customers with brain-dead software that expects to access a parallel port at legacy addresses. Generally, these people have
> custom applications that they have written using an I/O proxy ActiveX control. The control exposes an interface to the app to do
> INs and OUTs, and the control talks to a driver that does the dirty work. Effectively, the application is bypassing the driver
> that I supply. This works fine on the PCMCIA version of the card, which can be forced into legacy I/O address ranges. On PCI
> Express, however, we can’t obtain a legacy address. What I would like to do is grab control of the rogue INs and OUTs to legacy
> addresses and redirect them to the actual addresses used by my card. Is there a way to hook the I/O access?
> Chris Myers
>

After reading the entire thread, I would suggest a different aproach.
The problem could be solved rewriting the ActiveX (if it is only a I/O
proxy the ActiveX will have a little number of methods and no events.)
If you write an ActiveX with the same UID, the same methods and method
names and the same method parameters, their custom applications will use
your new ActiveX as if it is the old one. In this new ActiveX you can
make anything you need to achieve I/O access in a natural way.

HTH.

—
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

15

>> In this new ActiveX you can make anything you need to achieve I/O access in a natural way

This would also my preferred solution.Problem is however if the makers of the
origianl ActiveX would allow this ( license violation ? ).

Then just hook CoCreateInstance() in the target app. When it returns, you will have a pointer to the beginning of the object, so that you will be able to hook its QueryInterface() - it is the first function in the first vtable. . When a component returns a pointer to the target interface as a result to QueryInterface() call , hook the vtable of interest. Therefore, whenever its target method receives
a call that supplies IO ports as parameters, you will be able to modify these parameters right on the stack. As a result, the target driver will receive the parameters that you have supplied…

Anton Bassov

16

Wrapping a COM interface pointer inside another hooker COM interface object
is a more clean way of COM hooking then hooking the VMT itself.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntdev…
> >> In this new ActiveX you can make anything you need to achieve I/O access
in a natural way
>
> > This would also my preferred solution.Problem is however if the makers of
the
> > origianl ActiveX would allow this ( license violation ? ).
>
> Then just hook CoCreateInstance() in the target app. When it returns, you
will have a pointer to the beginning of the object, so that you will be able to
hook its QueryInterface() - it is the first function in the first vtable. .
When a component returns a pointer to the target interface as a result to
QueryInterface() call , hook the vtable of interest. Therefore, whenever its
target method receives
> a call that supplies IO ports as parameters, you will be able to modify these
parameters right on the stack. As a result, the target driver will receive the
parameters that you have supplied…
>
> Anton Bassov
>

17

> Wrapping a COM interface pointer inside another hooker COM interface object

is a more clean way of COM hooking then hooking the VMT itself

It depends on what you are up to…

In this context all the OP has to do is just to modify parameters on the stack, so that vtable hooking will work just fine. However, if you need to monitor/modify operations that may involve multiple calls that require the state to be maintained across the calls, then indeed, writing a wrapper component is a better option…

Anton Bassov

18

He he. Anton you are so funny sometimes.
Of course he does need to hook the IDT if it decides to use debug registers!
Should I warn also that he needs to compile the program before he runs it ?

-----Mensaje original-----
De: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] En nombre de xxxxx@hotmail.com
Enviado el: jueves, 06 de septiembre de 2007 2:57
Para: Windows System Software Devs Interest List
Asunto: RE:[ntdev] Can I/O accesses be hooked?

You can just use the Debug Registers to hook IN/OUT.

What can you possibly make out of debug registers (apart from BSOD, of course) without hooking INT 1 handler??? If execution reaches system-provided INT 1 handler when kernel code generates INT 1 exception and no kernel debugger is around, the system is going to bugcheck. Therefore, the above solution requires IDT hooking, and there is no need to resort to IDT hooking if the whole thing can get done “properly” by attaching a filter to the target device…

Anton Bassov

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

19

You are very right, but chances are you have been reading NTDEV long enough
to know people’s reaction to this kind of thing.

Unfortunately, there’s a level of programming that goes beyond what well
contained standards like the standard Microsoft driver development
environment can offer; when one needs to move a bit upstream, you often have
to take things in your own hands and manage the machine underneath and
sometimes in spite of the OS, and the real difficult thing is how to keep
the OS from sticking its dirty fingers where you don’t want it to.

It seems to me that the OS today is intent to block any attempt to more
advanced programming. But try for example to write a virus checker without
machine level code, or a debugger, or a profiler. It should be a matter of
fact that one could write such code and compete with the powers that be, but
all you have to do is to look at the recent history to figure out that the
real thing is, the OS often leaves no alternative but to use the Microsoft
product.

It shouldn’t be that way - ideally, the techniques used to write things such
as Windbg should be available to everyone, for example, in the form of a
publicly specified Bios Extension. And if I look at it with a cold eye,
I cannot escape the conclusion that every time I need to bypass the
Operating System, that happens because it has failed to give me the
functionality I need - from a sensible interface to use Debug Registers, to
the unavailability of a synchronization call to allow hardware-level access
to PCI configuration registers, and believe me, the list is long, and it
keeps getting longer.

Alberto.

----- Original Message -----
From: “Iñaki Castillo”
To: “Windows System Software Devs Interest List”
Sent: Friday, September 07, 2007 5:56 AM
Subject: RE: [ntdev] Can I/O accesses be hooked?

He he. Anton you are so funny sometimes.
Of course he does need to hook the IDT if it decides to use debug registers!
Should I warn also that he needs to compile the program before he runs it ?

-----Mensaje original-----
De: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] En nombre de
xxxxx@hotmail.com
Enviado el: jueves, 06 de septiembre de 2007 2:57
Para: Windows System Software Devs Interest List
Asunto: RE:[ntdev] Can I/O accesses be hooked?

> You can just use the Debug Registers to hook IN/OUT.

What can you possibly make out of debug registers (apart from BSOD, of
course) without hooking INT 1 handler??? If execution reaches
system-provided INT 1 handler when kernel code generates INT 1 exception and
no kernel debugger is around, the system is going to bugcheck. Therefore,
the above solution requires IDT hooking, and there is no need to resort to
IDT hooking if the whole thing can get done “properly” by attaching a filter
to the target device…

Anton Bassov

—
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

—
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

20

Damn Alberto … it’s good to have you back … Or was it me that was
gone!?!? :slight_smile:

–
The personal opinion of
Gary G. Little

“Alberto Moreira” wrote in message news:xxxxx@ntdev…
> You are very right, but chances are you have been reading NTDEV long
> enough to know people’s reaction to this kind of thing.
>
> Unfortunately, there’s a level of programming that goes beyond what well
> contained standards like the standard Microsoft driver development
> environment can offer; when one needs to move a bit upstream, you often
> have to take things in your own hands and manage the machine underneath
> and sometimes in spite of the OS, and the real difficult thing is how to
> keep the OS from sticking its dirty fingers where you don’t want it to.
>
> It seems to me that the OS today is intent to block any attempt to more
> advanced programming. But try for example to write a virus checker without
> machine level code, or a debugger, or a profiler. It should be a matter of
> fact that one could write such code and compete with the powers that be,
> but all you have to do is to look at the recent history to figure out that
> the real thing is, the OS often leaves no alternative but to use the
> Microsoft product.
>
> It shouldn’t be that way - ideally, the techniques used to write things
> such as Windbg should be available to everyone, for example, in the form
> of a publicly specified Bios Extension. And if I look at it with a cold
> eye,
> I cannot escape the conclusion that every time I need to bypass the
> Operating System, that happens because it has failed to give me the
> functionality I need - from a sensible interface to use Debug Registers,
> to the unavailability of a synchronization call to allow hardware-level
> access to PCI configuration registers, and believe me, the list is long,
> and it keeps getting longer.
>
>
> Alberto.
>
>
>
>
> ----- Original Message -----
> From: “Iñaki Castillo”
> To: “Windows System Software Devs Interest List”
> Sent: Friday, September 07, 2007 5:56 AM
> Subject: RE: [ntdev] Can I/O accesses be hooked?
>
>
> He he. Anton you are so funny sometimes.
> Of course he does need to hook the IDT if it decides to use debug
> registers!
> Should I warn also that he needs to compile the program before he runs it
> ?
>
>
>
> -----Mensaje original-----
> De: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] En nombre de
> xxxxx@hotmail.com
> Enviado el: jueves, 06 de septiembre de 2007 2:57
> Para: Windows System Software Devs Interest List
> Asunto: RE:[ntdev] Can I/O accesses be hooked?
>
>> You can just use the Debug Registers to hook IN/OUT.
>
> What can you possibly make out of debug registers (apart from BSOD, of
> course) without hooking INT 1 handler??? If execution reaches
> system-provided INT 1 handler when kernel code generates INT 1 exception
> and no kernel debugger is around, the system is going to bugcheck.
> Therefore, the above solution requires IDT hooking, and there is no need
> to resort to IDT hooking if the whole thing can get done “properly” by
> attaching a filter to the target device…
>
> Anton Bassov
>
>
> —
> 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
>
>
>
> —
> 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
>