unfere.blogg.se

That is why Windows hooks can be used to inject code into another process's address space. Windows will map the entire DLL, not just the hook procedure. The system then maps the DLL containing the hook procedure into the address space of the hooked thread. If the hooked thread belongs to another process (cases 2a & 2b), your hook procedure must reside in a dynamic-link library (DLL).

Local hooks, where you monitor the message traffic of any thread belonging to your process.The primary role of windows hooks is to monitor the message traffic of some thread. Windows Hooks Demo applications: HookSpy and HookInjEx A detailed description of this technique can be found here. Instead of writing a separate DLL, copy your code to the remote process directly - via WriteProcessMemory - and start its execution with CreateRemoteThread.Put your code into a DLL and map the DLL to the remote process using the CreateRemoteThread & LoadLibrary technique.Put your code into a DLL then, map the DLL to the remote process via windows hooks.In general, there are three possibilities to solve this problem:

::SendMessage( hPwdEdit, WM_GETTEXT, nMaxChars, psBuffer ) Įxecuted in the address space of another process. So, our problem reduces to the following: How to get Only the process that "owns" the password control can get its contents via WM_GETTEXT. If the edit control belongs to another process and the ES_PASSWORD style is set, this approach fails.

This also applies to edit controls, except in one special case.

To "read" the contents of any control - either belonging to your application or not - you generally send the WM_GETTEXT message to it. But first, let me review the problem briefly, just to make sure we're all on the same page. Is there any other way to make such a utility? Yes, there is. Several password spy tutorials have been posted to The Code Project, but all of them rely on Windows hooks.