GetMsg hook

[Samuel]

Ok, ive been trying to make an app that catches messages in other processes.

1. I forces the target process to load a dll
2. When the dll is loaded, it uses the SetWindowsHookEx api to set a hook
3. All messages sent to the target process are interpreted through the GetMsgProc proc

I assume this is correct. Ive written the executable in C++ and the dll in MASM. I know that the exe works because when I inject the dll, the dll displays a message box. The problem is, I dont seem to be receiving messages in GetMsgProc.

Here is the Dll code. If you want, ill post a link to the .exe

Code Select Expand


.386
.model flat,stdcall
option casemap:none
include \masm32\include\windows.inc
include \masm32\include\kernel32.inc
includelib \masm32\lib\kernel32.lib
include \masm32\include\user32.inc
includelib \masm32\lib\user32.lib

GetMsgProc proto :BYTE, :DWORD, :DWORD

.const
.data
hInstance dd 0
Text db "Loaded!", 0
Procname db "GetMsgProc", 0
RetValue db 0, 0

.data?
hHook dd ?
hWnd dd ?
hThreadId HANDLE ?

.code

DllEntry proc hInst:HINSTANCE, reason:DWORD, reserved1:DWORD
      .IF reason==DLL_PROCESS_ATTACH
           invoke MessageBox, NULL, addr Text, addr Text, MB_OK
           invoke GetProcAddress, hInst, addr Procname
           mov RetValue, al
           invoke SetWindowsHookEx, WH_GETMESSAGE, RetValue, hInst, 0
           mov hHook, eax
      .ENDIF
      .IF reason==DLL_PROCESS_DETACH
      .ENDIF
      mov eax, TRUE
      ret
DllEntry Endp

GetMsgProc proc code:BYTE, wParam:DWORD, lParam:DWORD
     invoke MessageBox, NULL, addr Text, addr Text, MB_OK
     .IF code < 0
         invoke CallNextHookEx, hHook, code, wParam, lParam
         ret
     .ENDIF
     invoke MessageBox, NULL, addr Text, addr Text, MB_OK
     invoke CallNextHookEx, hHook, code, wParam, lParam
     ret
GetMsgProc Endp

End DllEntry


My knowledge of MASM is a bit shaky, so dont crit it to hard  :wink

[hutch--]

Samuel,

I have locked the topic because it appears to be breaking the forum rules. Admin will listen to what you want to do with it but unless we are completely happy with the response, this posting will go to the scrap heap.

LATER : I have reopened the topic because Samuel explained that it is a SPY++ style app. Make sure it remains that way or it will be removed permenantly.

[MusicalMike]

I shudder to think what might happen if madMASM gets his hand on the above code, mainly because there are plenty of nasty things that you can do with get message hooks, such as removing messages from the ques of other windows apps there by crippling them, and thats just to start with. In light of this fact though, I was thinking, that a special subforum should be created for such dangerous topics as hooks and stuff like that. To make things doubly secure, a given moderator keep a list of names that are "approved" to do so much as view the content. It seems that every time the word "hook" appears in a posting, everyone upgrades to maximum alert. Even though I am not a moderator, I myself have been keeping tabs on this problem. Anyway, its just a thought. I also feel that it is the responsibility of the honest users of this forum to make sure they are not unknowingly giving dangerous information to dangerous people. The code you have posted is dangerous code, and I feel that having it in plain site for anyone to look at is a security risk.

[hutch--]

Mike,

Understand that policy and forum rules are not made on the fly in this forum. Collectively between our membership and the team that runs the forum, there is literally hundreds of years of experience on a massive number of areas available.

I have stuck my neck out and re-opened this topic, even though I know that Samuel has some strange stuff posted on his web site that will never see the light of days here but he responded quickly to me locking the topic and told me what he was doing with it and a SPY++ application is a perfectly reasonable application to write.

Our members regularly point out any suspicious looking posts and you can be sure that the team that runs the forum well know what is going on with anything that even vaguely looks suspicious.

[Samuel]

Thank you Hutch! This problem has been bothering me for months and I really apprectiate you sticking your neck out.

[Synfire]

Samuel,

Just a few things off the top my head, make sure you are making the .data? section shared (ie /SECTION:.bss,S in LINK.EXE's arguments). Also, rather than using SetWindowsHookEx, you could (if you are able to get the window handle) subclass the window so that you can monitor messages using your own wndproc. If you feel SetWindowsHookEx is warranted for your project, make sure hInstance isn't NULL (this will cause SetWindowsHookEx to fail and I myself have made this mistake several times) and check the return value from SetWindowsHookEx (and use GetLastError to find out why). I have a feeling, call it intuition or whatnot, that SetWindowsHookEx is probably failing on ya for one of the above reason. Hope this helps.

Regards,
Bryant Keller

[MusicalMike]

One question of curiousity, from what I see here, your dll seems to be designed to shadow the host process, would that be correct?

Ps. Hutch, I have great faith that you made the right decision  :thumbu. After all, there ARE definitely lagitimate purposes for low level code like this. :dazzled: I was mearly trying to segway into my subforum suggestion, which again is only a suggestion which again is only a suggestion.  :U