Hi
I dug up the Message hook doc and source by Stone that Fake51 talked about. The explanation in the original tut in the old Fravia database (stone1.htm in the Academy300 section) is missing, but Stone did include it at his website before it closed down. I have a copy of the entire Stone's website, which is very interesting reading, and actually uploaded the 1.2Mb file to the REKML site a long time ago. You can probably get it there (REKML still active??), or it might have been included in the RCE CD (don't know).
In any case, for posterity here it is.
Kayaker
---------------------------------------------------------------------------
In Memory Patching - The MessageHook Approach
by Stone
I'll skip relatively lightly over the in-depth technical issues of this method.
It is simply far beyond this text to go into it. Maybe someday I'll write a
book or something
sorry..
The above method has it's advantages - and disadvantages. It's cumbersome.
Indeed in many instances access to foreign addressing spaces can be gained
easier. I will now examine one such method. The method was first described
in MSJ 1994. I first noticed the potency of this method examing Grudge's crack
for SubSpace. My sourcecodes and approach as such bares many resemblances with
Grudge's initial work.
Most likely you've all encountered Windows Messageing system at one point or
another. Breakpoints on "BMSG", HWND command in Winice is indeed breakpoints
on messages and list possible recievers of messages. The whole idea behind
messages goes back to the fact that we have a multitasking operating system.
Several tasks needs to share equipment that can only be used by one at the time.
The obvious example is the mouse - the user will have only ONE mouse total, not
one for each thread. Another is the keyboard, keyboard input is often ment for
only one of the running threads. A total breakdown of the windows messageing
and windowing system is far far beyound the scope of this small text. It'll
suffice to say that any window made by any thread in any process is controlled
thru messages from the Windows operating system.
Again we'll exploit that Windows is an overbloated operating system - or well
as I would rather put it - a very potent equipped OS. The feature we'll be
exploiting here is that of a Hook in the message system. For many reasons
Microsoft decieded that even at ring 3 people should be able to intercept
messages send to windows. Because they wanted this hook to be usuable for
Computer Based Training they decieded that a hook would be no good if it did
not have direct access to the addressing space of the process belonging to the
thread it captured a message for. So they decieded that a MessageHookHandling
procedure should be loaded into any process in which it captured a message.
Further developers must've felt generous the day they designed this. They
allowed a hook not just to one process - but to all!
Let's get a bit more technical on this. The API that installs the hook is:
User32!SetWindowsHookExA
The first problem about using this API to hook windows messages globally is
the way it gain access to the address space of the thread which it intercepted
a message to. To get real deep on this issue is again far beyound the scope
of this text, but it has to do with how modules is mapped in pages thru out
the various memory contexts (Process addressing spaces).
The result is that you cannot have the hook within the EXE file that installs
the hook - rather you need to have it in a DLL.
In other words we start out by loading the DLL in which we have our hook, then
find the address of our hook procedure in it and feed this to SetWindowsHookExA.
The next problem we encounter is that of designing a messagehandling system.
Since a LOT of messages is send out to windows system wide all the time it's
important that we design our hook to be relatively fast or we'll be slowing the
system. The easist way of doing this is only acting upon messages of a specific
type. Choosing type depends on how you wish to time your patch. You can in
this way time it to hit on keyboard activity in a window, mouse activity,
windows being put to background and so on and so forth.
I've choosen the real simple hook type intended for ComputerBasedTraining. This
hooks a large number of messages related to windows giving us plenty of things
to act on without intercepting everything. Further in the hook procedure I
test weather the message send was one that is supposed to create a window.
This allows me to patch right after the "main" window of the program is created.
Without intercepting too much and even when intercepting I only run a few bytes
of my code unless ofcause it happens that the program is creating a window.
Obviously I might end up patching more than since this message type can be
send many times. Other strategies could be hooking the keyboard, all messages
etc. I very much believe that which type of hook and the exact design of your
hook-handler is an issue that should be solved in relation to the specific
problem you're dealing with. For instance in training hooking the keyboard
and only acting on specific keys would be a good idea instead of acting on
the window.
Mammon/HCU suggest a boolean variable to see if you already applied a patch.
This can be a very good idea. Even better would be if you shut down your
hook-installing process (program) and the hook along with it after you've
patched. You should however be aware that this method has a caveat if your user
deciedes to run multiple versions of the program you patched or if you're
patching kernel32.dll in memory since this DLL might need to be patched more
than once because an unpatched version might later on be mapped into your
target's addressing space. Thanks to Mammon/HCU for a beneficial suggestion.
The next problem is that we need to hinder that we patch all processes. Again
I abuse the concept of modules. By getting the current module filename and
compareing it to the filename of the file we desire to patch I can identify
weather this message was send to the target or to another program windows.
And the last problem is ofcause that we cannot keep messages from the target's
windows and expect it to perform like it's supposed to. What we do is that we
chain other possible hooks using the neatly provided API:
user32!CallNextHookEx
One final things is worth noting Exiting the process who "owns" the hook will
destroy it - in other words we cannot shut down until we're sure we've patched
the program and we cannot shut down if need multiple patches (as patching
e.g. kernel32.dll (which is a bad idea anyway) would require. The good thing
about it is that we can simply call ExitProcess when we're done and windows
will take down the hook for us with no further adue... Pretty clever MS!
Since we in the hook-procedure have direct access to the addressing space
of the target process we wouldn't need to use WriteProcessMemory, however
it's a very good idea to do so. First and foremost WPM as described earlier
overrides pageprotection. Second and also important - there is a difference
in how pages in a process is handled between Windows 95 and Windows NT. If
you patch a program's pages in Win NT (if it's not shared) it'll be copied
and then the copy will be patched - thus the patch will not affect other
processes utillizing the same module. In windows 95 this is not so. However
WriteProcessMemory in Windows 95 has build in this mechanism ensuring that
if you use WriteProcessMemory you'll not suffer differences between NT and
95. (This is not true if you patch above the 2g limit - which I btw cannot
see why you'd do)
Here at the end I'll shortly describe the caveats of this method. It requires
a window. Without a window in the target process you can't do didly with this
method. However you can use this method to inject a DLL into the address space
after the window has disappeared and then patch the IAT to make a API-hook of
it like in the Debug-approach section.
Sourcecode - stnmsgh.zip
-------------------------------------------------------------------------
