Precise Control of Messages

I have a program that needs very precise control of messages, but
user32.dll provides insufficient functionality. The program needs to be
able to intercept (almost) every message to a specific application
(including those to all of its threads, windows, and the controls on
each window, such as standard windows buttons), prevent the message
from having any affect on the application, exchange information about
the message with other parts of the program (which will involve
networking and thus latency measured in millisecs at least), and
possibly later send the message on as if it were never stopped. The
target OS is "Windows 2000 Professional" and both XP Pro and 2K Pro are
used on development machines.

How is this relevant to kernel-mode/driver development groups? (I would
have posted it to a single group if it were clear what each covers, but
I could find no such descriptions.) I'm wondering if some type of
driver (or other kernel-mode code) might be the best way to implement
complete control over the messaging system.

I currently know nothing about driver development, but recently I
became interested and ordered the 'Windows Server 2003 SP1 DDK CD' and
the book 'Windows Internals (ISBN: 0735619174)' as a place to start.
Just as both arrived, it occured to me that kernel-mode code might be
the solution I've been looking for. Searching through the book, the ddk
documentation, and the internet in general, I was unable to find
anything that seemed relevant one way or the other to this specific
problem, so I figured that a developer more experienced in this area
might be able to tell me whether this idea is feasible and/or could
point me towards directly relevant information.

I would appreciate any suggestions, pointers, or other assistance =-)

-Extrarius

P.S. Any email replies should include a relevant group name in the
subject so the email isn't filtered as junk.

Kellie
Fri Nov 25 00:17:52 CST 2005

Hi,

You need to use a system-wide hook, for example, WH_CALLWNDPROC to
monitor messages being sent, and WH_CALLWNDPROCRET to monitor the
messages handlers returning, and a hook procedure in a .DLL file.

Use the following API's to create/set/handle hooks in a windows
environment application:

SetWindowsHookEx()
CallNextHookEx()
UnhookWindowsHookEx()

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/windowing/hooks/hookreference/hookfunctions/setwindowshookex.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/windowing/hooks/hookreference/hookfunctions/callnexthookex.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/windowing/hooks/hookreference/hookfunctions/unhookwindowshookex.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/windowing/hooks/abouthooks.asp

Hope these information helps,

Kellie.

Extrarius
Fri Nov 25 01:28:14 CST 2005

Unfortunately, neither of the mentioned hook types allow the message to
be modified (to prevent it from reaching the target), which is one of
the requirements. As far as I can tell, no combination of hooks allows
all messages to be both intercepted and modified.

-Extrarius

Bernhard
Fri Nov 25 02:18:11 CST 2005

Extrarius wrote:
> I have a program that needs very precise control of messages, but
> user32.dll provides insufficient functionality. The program needs to be
> able to intercept (almost) every message to a specific application
> (including those to all of its threads, windows, and the controls on
> each window, such as standard windows buttons), prevent the message
> from having any affect on the application, exchange information about
> the message with other parts of the program (which will involve
> networking and thus latency measured in millisecs at least), and
> possibly later send the message on as if it were never stopped. The
> target OS is "Windows 2000 Professional" and both XP Pro and 2K Pro are
> used on development machines.
>
> How is this relevant to kernel-mode/driver development groups? (I would
> have posted it to a single group if it were clear what each covers, but
> I could find no such descriptions.) I'm wondering if some type of
> driver (or other kernel-mode code) might be the best way to implement
> complete control over the messaging system.
>
> I currently know nothing about driver development, but recently I
> became interested and ordered the 'Windows Server 2003 SP1 DDK CD' and
> the book 'Windows Internals (ISBN: 0735619174)' as a place to start.
> Just as both arrived, it occured to me that kernel-mode code might be
> the solution I've been looking for. Searching through the book, the ddk
> documentation, and the internet in general, I was unable to find
> anything that seemed relevant one way or the other to this specific
> problem, so I figured that a developer more experienced in this area
> might be able to tell me whether this idea is feasible and/or could
> point me towards directly relevant information.
>
> I would appreciate any suggestions, pointers, or other assistance =-)
>
> -Extrarius
>
> P.S. Any email replies should include a relevant group name in the
> subject so the email isn't filtered as junk.
>
Why don't you use the debug port of the application? You don't need
kernel mode code for accomplishing this. In order to use the debug port,
you must go through some native ntdll calls, but I'll give you some
hints if you want to know more.

Bernhard

P.S. For an introduction see http://undocumented.ntinternals.net

James
Fri Nov 25 02:27:17 CST 2005

In that case you could try hooking the GetMessage and PeekMessage API
calls within your target application using the Detours package from
Microsoft -
this would have you access to all messages being processed by all threads
in the application.

http://research.microsoft.com/sn/detours/

Installing the hook would allow you to either modify the message
before passing it onto the target app, or even "eating" the message
altogether.

You will need to write a DLL which you "inject" into the app - this DLL
should contain all of your hooking code. I think maybe Detours provides
this functionality as well, otherwise google for "dll injection".

James

--
www.catch22.net
Free win32 software, sourcecode and tutorials


"Extrarius" <filtered@psychosanity.com> wrote in message
news:1132903694.596413.45150@g49g2000cwa.googlegroups.com...
> Unfortunately, neither of the mentioned hook types allow the message to
> be modified (to prevent it from reaching the target), which is one of
> the requirements. As far as I can tell, no combination of hooks allows
> all messages to be both intercepted and modified.
>
> -Extrarius
>

Extrarius
Fri Nov 25 03:50:12 CST 2005

Bernhard Poess wrote:
> Extrarius wrote:
> > I have a program that needs very precise control of messages, but
> > user32.dll provides insufficient functionality. The program needs to be
> > able to intercept (almost) every message to a specific application
> > (including those to all of its threads, windows, and the controls on
> > each window, such as standard windows buttons), prevent the message
> > from having any affect on the application, exchange information about
> > the message with other parts of the program (which will involve
> > networking and thus latency measured in millisecs at least), and
> > possibly later send the message on as if it were never stopped. The
> > target OS is "Windows 2000 Professional" and both XP Pro and 2K Pro are
> > used on development machines.
> > [...]I would appreciate any suggestions, pointers, or other assistance =-)
> >
> > -Extrarius
> >
> > P.S. Any email replies should include a relevant group name in the
> > subject so the email isn't filtered as junk.
> >
> Why don't you use the debug port of the application? You don't need
> kernel mode code for accomplishing this. In order to use the debug port,
> you must go through some native ntdll calls, but I'll give you some
> hints if you want to know more.
>
> Bernhard
>
> P.S. For an introduction see http://undocumented.ntinternals.net

It sounds like your suggestion involves modifying the the application
that is to be monitored. While in the most urgent case, such
modifications are possible, the message-monitoring (and modifying)
program will need to work with applications that cannot be modified in
the future.

-Extrarius

Bernhard
Fri Nov 25 03:53:09 CST 2005

Extrarius wrote:
>*snip*
> It sounds like your suggestion involves modifying the the application
> that is to be monitored. While in the most urgent case, such
> modifications are possible, the message-monitoring (and modifying)
> program will need to work with applications that cannot be modified in
> the future.
>
> -Extrarius

No, it doesn't. You just write a new app, that acts somehow like a
debugger. But instead of reacting to every debug message you can filter
the messages you're interested in and handle them accordingly.

-Bernhard

Extrarius
Fri Nov 25 04:08:24 CST 2005

Unfortunately, notification messages (sent via WM_COMMAND to notify a
parent window of events such as button clicks) do not go through the
normal message processing procedure, so they never pass through
GetMessage or PeekMessage.

I was already fairly certain that this was the case, but to make
absolutely sure I made a simple windows program and made it log all
messages returned by GetMessage to a file, which resulted in messages
such as mouse down and mouse up messages to the button being logged,
but not the WM_COMMAND message carrying the BN_CLICKED notification.

-Extrarius

James Brown wrote:
> In that case you could try hooking the GetMessage and PeekMessage API
> calls within your target application using the Detours package from
> Microsoft -
> this would have you access to all messages being processed by all threads
> in the application.
>
> http://research.microsoft.com/sn/detours/
>
> Installing the hook would allow you to either modify the message
> before passing it onto the target app, or even "eating" the message
> altogether.
>
> You will need to write a DLL which you "inject" into the app - this DLL
> should contain all of your hooking code. I think maybe Detours provides
> this functionality as well, otherwise google for "dll injection".
>
> James
>
> --
> www.catch22.net
> Free win32 software, sourcecode and tutorials

Extrarius
Fri Nov 25 04:15:24 CST 2005

Bernhard Poess wrote:
> Extrarius wrote:
> >*snip*
> > It sounds like your suggestion involves modifying the the application
> > that is to be monitored. While in the most urgent case, such
> > modifications are possible, the message-monitoring (and modifying)
> > program will need to work with applications that cannot be modified in
> > the future.
> >
> > -Extrarius
>
> No, it doesn't. You just write a new app, that acts somehow like a
> debugger. But instead of reacting to every debug message you can filter
> the messages you're interested in and handle them accordingly.
>
> -Bernhard

I'm confused, then, about why you inlcuded the link to
http://undocumented.ntinternals.net . Was the link merely to help me
get started in kernel-mode development? The debugging API is well
documented in the Platform SDK, but I see no capability for
intercepting messages in any of the debugging functions.

Maxim
Fri Nov 25 07:41:04 CST 2005

> Unfortunately, notification messages (sent via WM_COMMAND to notify a
> parent window of events such as button clicks) do not go through the
> normal message processing procedure, so they never pass through
> GetMessage or PeekMessage.

Then hook the wndproc itself, by subclassing all windows, for instance.

Anyway: this product idea looks like a major paranoia :) remember - you will be
filtering most OLE/COM traffic too, not only UI.

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

Extrarius
Fri Nov 25 07:58:29 CST 2005

Maxim S. Shatskih wrote:
> > [...]they never pass through GetMessage or PeekMessage.
>
> Then hook the wndproc itself, by subclassing all windows, for instance.
>
> Anyway: this product idea looks like a major paranoia :) remember - you will be
> filtering most OLE/COM traffic too, not only UI.
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim@storagecraft.com
> http://www.storagecraft.com

The problem with subclassing is that in order for it to be effective, I
also need to know when new windows are created so they can be
subclassed. Is the best way to do that hooking CreateWindow A/W,
CreateWindowEx A/W, and any other functions that create windows? If so,
what other functions would need to be hooked, and what is the best
method for hooking?

-Extrarius

Maxim
Fri Nov 25 08:36:08 CST 2005

> Unfortunately, notification messages (sent via WM_COMMAND to notify a
> parent window of events such as button clicks) do not go through the
> normal message processing procedure, so they never pass through
> GetMessage or PeekMessage.

BTW - am I correct that CALLWNDPROC type of hook will hook this?

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

Scherbina
Fri Nov 25 15:35:11 CST 2005

I am not sure that you need to hook CreateWindow(Ex)(W|A) because you can't
get wndproc from it.
Hooking RegisterClass(Ex), AFAIR will be enough (you can get pointer to
wndproc function from WNDCLASS(EX) structure).

As for hooking techniques, take a look at
http://www.internals.com/articles/apispy/apispy.htm and
http://www.codeproject.com/system/hooksys.asp.

Good luck.

--
Scherbina Vladimir

"Extrarius" <filtered@psychosanity.com> wrote in message
news:1132927109.632396.23250@g43g2000cwa.googlegroups.com...
> Maxim S. Shatskih wrote:
>> > [...]they never pass through GetMessage or PeekMessage.
>>
>> Then hook the wndproc itself, by subclassing all windows, for instance.
>>
>> Anyway: this product idea looks like a major paranoia :) remember - you
>> will be
>> filtering most OLE/COM traffic too, not only UI.
>>
>> --
>> Maxim Shatskih, Windows DDK MVP
>> StorageCraft Corporation
>> maxim@storagecraft.com
>> http://www.storagecraft.com
>
> The problem with subclassing is that in order for it to be effective, I
> also need to know when new windows are created so they can be
> subclassed. Is the best way to do that hooking CreateWindow A/W,
> CreateWindowEx A/W, and any other functions that create windows? If so,
> what other functions would need to be hooked, and what is the best
> method for hooking?
>
> -Extrarius
>

Extrarius
Fri Nov 25 20:05:14 CST 2005

Maxim S. Shatskih wrote:
>> Unfortunately, notification messages (sent via WM_COMMAND to notify a
>> parent window of events such as button clicks) do not go through the
>> normal message processing procedure, so they never pass through
>> GetMessage or PeekMessage.
>
> BTW - am I correct that CALLWNDPROC type of hook will hook this?
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim@storagecraft.com
> http://www.storagecraft.com

You are correct that such a hook should receive notification about such
messages, but the hook would have no way to modify the message or
prevent it from being delivered to it's target.

-Extrarius

Extrarius
Fri Nov 25 20:28:15 CST 2005

Scherbina Vladimir wrote:
> I am not sure that you need to hook CreateWindow(Ex)(W|A) because you
> can't get wndproc from it. Hooking RegisterClass(Ex), AFAIR will be
> enough (you can get pointer to wndproc function from WNDCLASS(EX)
> structure).
>
> As for hooking techniques, take a look at
> http://www.internals.com/articles/apispy/apispy.htm and
> http://www.codeproject.com/system/hooksys.asp.
>
> Good luck.
>
> --
> Scherbina Vladimir

The reason to hook CreateWindow(*) and other functions such as
CreateDialog(*) is so that the hooking program knows of every window
that needs to be subclassed. Many windows, such as standard windows
buttons (window class "button"), are not be registered by applications
that use them.

Other than that, the only two problems are that this method only works
for window messages (no thread or system messages) and that it would be
very tedious to implement since I would have to look up every function
in User32.dll (and possibly other dlls also) to discover which functions
create a window.

-Extrarius

Maxim
Sat Nov 26 04:41:48 CST 2005

> You are correct that such a hook should receive notification about such
> messages, but the hook would have no way to modify the message or
> prevent it from being delivered to it's target.

Cal you forget calling the next hook? or call the next hook with modified
message code or parameters?

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

Maxim
Sat Nov 26 04:50:30 CST 2005

> Other than that, the only two problems are that this method only works
> for window messages (no thread or system messages)

They are not interesting anyway. They are usually the innerworkings of some
app.

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

Extrarius
Sat Nov 26 11:16:05 CST 2005

Maxim S. Shatskih wrote:
>> You are correct that such a hook should receive notification about
>> such messages, but the hook would have no way to modify the message
>> or prevent it from being delivered to it's target.
>
> Cal you forget calling the next hook? or call the next hook with
> modified message code or parameters?
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim@storagecraft.com
> http://www.storagecraft.com

Such things are possible, but they don't have the desired result. In
fact, they don't seem to have any result at all. Despite the PlatformSDK
specifically stating that WH_CALLWNDPROC hooks cannot modify the
message, I created a quick test program that both modified the CWPSTRUCT
that is passed by pointer to the hook function and also returned 0
(indicating that the hook function did not call CallNextHookEx) or
CallNextHookEX (with the modified or original parameters) and it
demonstrated that the documentation was correct on the issue.

-Extrarius

Extrarius
Sat Nov 26 12:51:14 CST 2005

Maxim S. Shatskih wrote:
>> Other than that, the only two problems are that this method only
>> works for window messages (no thread or system messages)
>
> They are not interesting anyway. They are usually the innerworkings
> of some app.
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim@storagecraft.com
> http://www.storagecraft.com


I'm sure that is generally the case, but I can't rely on it because it
isn't guaranteed. Actually, even if it were, intercepting those 'inner
workings' might be just as important as intercepting a window message. I
wouldn't be at all surprised to find an application that required such
unusual treatment. I sometimes have to work with software created for
government contracts and, if you haven't, you might be surprised at the
variety and depth of offenses committed in such software.

-Extrarius

Bernhard
Mon Nov 28 01:30:04 CST 2005

Extrarius wrote:
> I'm confused, then, about why you inlcuded the link to
> http://undocumented.ntinternals.net . Was the link merely to help me
> get started in kernel-mode development? The debugging API is well
> documented in the Platform SDK, but I see no capability for
> intercepting messages in any of the debugging functions.

By using the debug port, you get lots more messages than documented e.g.
in the Platform SDK, since I don't know your expertise level I sent the
link because PORT objects are explained there.

-bernhard

Extrarius
Mon Nov 28 16:03:07 CST 2005

Bernhard Poess wrote:
> Extrarius wrote:
>> I'm confused, then, about why you inlcuded the link to
>> http://undocumented.ntinternals.net . Was the link merely to help me
>> get started in kernel-mode development? The debugging API is well
>> documented in the Platform SDK, but I see no capability for
>> intercepting messages in any of the debugging functions.
>
> By using the debug port, you get lots more messages than documented e.g.
> in the Platform SDK, since I don't know your expertise level I sent the
> link because PORT objects are explained there.
>
> -bernhard
>

Could you perhaps give a more specific link? The only debug function I
see on the site you linked me to is 'dbgprint' and while I have found
some functions with Port in their name, the site only describes a few
paramters in each function without giving any indication of how they
could be used in any way. After some serious google searching, I have
found a tiny bit of code that uses the port functions, but they all use
the debug port in the exact same way that the PlatformSDK shows the
standard debugging functions being used. If you think debug ports are
the answer, I'd really appreciate some information that shows how I
could use them to intercept messages beyond those that the standard
debugging API supports.

-Extrarius

Extrarius
Wed Nov 30 16:59:25 CST 2005

Extrarius wrote:
> I have a program that needs very precise control of messages, but
> user32.dll provides insufficient functionality. The program needs to
> be able to intercept (almost) every message to a specific
> application (including those to all of its threads, windows, and the
> controls on each window, such as standard windows buttons), prevent
> the message from having any affect on the application, exchange
> information about the message with other parts of the program (which
> will involve networking and thus latency measured in millisecs at
> least), and possibly later send the message on as if it were never
> stopped. The target OS is "Windows 2000 Professional" and both XP Pro
> and 2K Pro are used on development machines.
>
> How is this relevant to kernel-mode/driver development groups? (I
> would have posted it to a single group if it were clear what each
> covers, but I could find no such descriptions.) I'm wondering if some
> type of driver (or other kernel-mode code) might be the best way to
> implement complete control over the messaging system.
>
> I currently know nothing about driver development, but recently I
> became interested and ordered the 'Windows Server 2003 SP1 DDK CD'
> and the book 'Windows Internals (ISBN: 0735619174)' as a place to
> start. Just as both arrived, it occured to me that kernel-mode code
> might be the solution I've been looking for. Searching through the
> book, the ddk documentation, and the internet in general, I was
> unable to find anything that seemed relevant one way or the other to
> this specific problem, so I figured that a developer more
> experienced in this area might be able to tell me whether this idea
> is feasible and/or could point me towards directly relevant
> information.
>
> I would appreciate any suggestions, pointers, or other assistance =-)

Many responses and attempts to help, but no actual solution yet. I would
greatly appreciate any further suggestions, pointers, or assistance =-)

-Extrarius

P.S. Any email replies should include a relevant group name in the
subject so the email isn't filtered as junk.