I write a C++ executable running on Windows 7 that calls
SetWindowsHookEx(WH_GETMESSAGE, pFunc, hDll, 0 /*dwThreadId*/)
This installs my hook procedure pFunc that monitors messages posted to a message queue.
As MSDN says, if parameter dwThreadId is 0, the hook procedure is associated with all existing threads. But what I see is, this hook procedure pFunc will hook future processes that launched after this hook process. Is this right?
Related
I want to write a program to detach dll injection or vulnerability exploit by creating a monitor thread for all processes.I want to do this in user level instead of inserting a driver.
I try to use AppInit_DLLs to create a thread at DllMain,but it's not work if a program don't load user32.dll.
I try to listen a new process creation event and suspend new process for loading my monitor dll,but it's not work well.
Is there any methods to hook all new processes before they start run?
Most programs are run via double click so explorer.exe is the process which uses CreateProcess to launch them
Hook explorer.exe and make CreateProcess and ShellExecute/Ex hook the created processes also and so on
You can do some more by hooking all the running processes with the same technique once your injector opens thus you absolutely are hooking all user mode processes
Make sure to have the proper rights if you aren't running as admin you won't be able to hook processes running as admin
The functions you need to hook are usually CreateProcess NtCreateProcess ShellExecuteInfo/Ex
You will be using NtSuspendProcess and NtResumeProcess to set your hooks before the process has a chance to defend itself but tls callbacks may be already called , and in case of NtCreateProcess , CreateProcess you can use CREATE_SUSPENDED then ResumeThread with the thread handle you get from the function
if you want to go deeper you can hook NtCrateFile as any attempt to execute exe or load a dll will need to open the file to allocate the image in the memory
I have to install some Window Hooks in order to monitor MOUSE messages for a limited number of processes.
As these processes are under my control I could make them collaborate, so I chose to code a simple DLL that installs a local WH_MOUSE hook, and the Hook procedure does a PostMessage to a specific Window Handle in a "controller" process.
This DLL will be loaded by each process I must monitor.
This way I don't need Low Level Hooks, Global Hooks or dll injection techniques.
Now I'm looking for maximum performance:
In the Hook Procedure, after message filtering I have to call PostMessage with a destination Handle that could potentially be invalid.
I can see 3 options:
Test everytime for if (IsWindow(myHWnd)): I think this puts an overhead on the hooked processes
Don't test, and let PostMessage gently fail: does this put any overhead on the entire system in case of failure?
Don't worry about that and go for (2) because hooking mouse messages IS itself the biggest overhead.
What do you think about that?
Thank you
I have a Process called "Agent" it spawns a new process called "Connect". This "Connect" process loads the service dll's. The "Connect" process start a sub process(cmd.exe), I would like to know if for some reasons the loaded dll's cause a hang or a crash, how to ensure that "cmd.exe" is terminated.
Use CreateProcess to spawn the new process. The involves setting up and passing in a PROCESS_INFORMATION structure: which will contain a handle to the new process (hProcess) if the call to CreateProcess works.
You can now do a WaitForSingleObject on this process handle to see when the process finishes. WaitForSingleObject allows you to timeout if the object does not trigger (i.e. process does not terminate), and hence take action (TerminateProcess I presume).
I want to create a window and show some image display (like animation based on SetTimer()) on window created using CreateWindow() function. But it should be created on separate thread and should remain alive until user closes this. I tried but was unsuccessful.
EDITED
I just googled I found this link How To Create Windows in a Multithreaded Application but one thing i want to know when Window Procedure get invoked. if it is invoked by system then how i can call it from my child thread.
Windows (represented by HWNDs) in Windows have a thread affinity. Their WindowProc is always invoked in the context of the thread they are created with.
As such, they are a convenient way to serialize calls between threads as the PostMessage and SendMessage APIs can be called from any thread in the application, but the WindowProc will get executed in the context of the original creating thread.
Because WM_TIMER messages posted to message queues are the mechanism by which SetTimer works, again you need to be careful when calling SetTimer in a multithreaded app - The timer messages will be processed by the calling thread (if the hwnd parameter is NULL) or the window's thread.
You also, as a result, have to be careful to put a message loop on every thread that might create windows, or want to process timers.
Keep your user-interface on the main Windows thread. Setting a timer using the Windows API doesn't require an additional thread (as your WndProc will get the timer message WM_TIMER).
Even if you have a long running task to perform that might necessitate the use of an additional thread, keep the window on the main thread, do your work in the worker-thread and post back to the main thread with updates.
When you create a DLL you can get notifications about new threads / exiting threads in the DllMain function (DLL_THREAD_ATTACH/DLL_THREAD_DETACH).
Is there a way to get these or equivalent notifications from Windows within an (non managed) Executable?
Yes - include a small stub DLL in your process that simply monitors DLL_THREAD_ATTACH and DLL_THREAD_DETACH in the way you want.