Re: [GD-Windows] Hijacking application

[brian s. <pud...@po...>]

Under NT/2k/XP, you can't set a new WndProc on a window that you don't 
own (specifically, a window that wasn't created by a thread in your 
process).  So you can't get your code into an app that way. 

SetWindowsHookEx will get you there though.  All you have to do is put 
your code into a DLL that can be loaded as a hook, and then you can 
party all over the app in question.

Which, as far as getting anything useful done, probably means very 
little.  Although maybe someone will write a Notepad plugin and prove me 
wrong.

--brian

p.s. If you lack the necessary privileges to install a hook, there's 
always http://security.tombom.co.uk/shatter.html :)

Colin Fahey wrote:

>Doing GetWindowLong(...) with the handle acquired by FindWindow(...)
>can give you the address of the WndProc() for that window.  I can't
>remember the details, but you can essentially do SetWindowLong(...)
>to replace the existing WndProc() function pointer with your own.
>
>Your WndProc() can essentially be a pass-through function that 
>calls the previous WndProc() function with the same arguments;
>totally transparent.
>
>However, you can monitor, filter, record, process, augment, etc,
>the stream of messages.  And there is a LOT you can do with plain
>messages!  Forget about undocumented functions that you MIGHT 
>discover using "dumpbin" on the EXE file; just interact with the
>application at the same level as the user.
>
>Of course you don't need to insert your own WndProc() between the
>OS and the real WndProc() if all you are doing is ADDING messages
>to the queue; you just do PostMessage() from any separate application
>to the target window handle.
>
>But by hooking your own WndProc() in to the application's message
>processing you can do cool things, like draw your own controls
>or annoying, animated "assistants" after all other painting of
>the client area is complete, or mess with keystrokes and mouse
>messages.  Maybe add your own shortcuts to apps that cannot by
>default have new key bindings -- and you can even have a whole mess
>of key and mouse macros that activate when you bring up the load
>or save dialog boxes!  (I was too cheap to buy the full Photoshop,
>but Photoshop LE apparently does not have any automation, so I
>have been tempted to fix this.  For example, I hate having to 
>always change the file extension from "JPG" to "jpg" when doing
>a "Save As...", and unchecking "[x] Save thumbnail" (Does that 
>even have anything to do with JPG?)  So, perhaps hooking in my
>own WndProc(), or having a separate app do PostMessage()s, 
>would make my $99 investment go a little further!)
>
>I don't remember details, but this stuff is documented in MSDN,
>probably in relation to common control "subclassing" in the 
>days before C++ and MFC!
>
>I guess your pass-through WndProc() would be free to do its
>own CreateWindow() calls to add child windows or controls to
>the application.
>
>Here's the weird part:  It MIGHT be tricky to get your WndProc()
>in the address space of the target application at run-time,
>if that's how you're doing things.  One non-runtime option is to
>append your WndProc() hijacking code to the tail of the application
>somehow (both your WndProc() and the function that does the stuff
>with GetWindowLong() and SetWindowLong() to perform the hijack),
>and then it is just a matter of arranging for your code to be 
>called by the real WinMain().  Maybe it would be better to put
>the hijack code in a DLL and somehow get the app to implicitly
>load it, and in your DllInitialize() function (or DllEntry() or
>whatever function is called when the DLL first loads), start a 
>thread that sleeps for a while, checks for the existence of
>the main app window, and either returns to sleep or does the
>hijack.
>
>There are probably much cleaner ways!  For all I know, external
>apps can trivially hijack WndProc()s of other apps without 
>doing anything special to get the "interceptor" or "new" WndProc()
>in to the target address space.
>
>  
>