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.
Related
I created 2 hooks in my host application. 1st is WH_MOUSE set specifically for Taskbar's thread. 2nd is global WH_KEYBOARD_LL hook (dwThreadId is set to 0).
As you can see in Process Explorer, the "local" hook actually injected my dll into specific explorer.exe thread. However, there is no indication that my 2nd global hook got injected into any other processes, yet it still works perfectly... Moreover, it also works for all the new processes I start, even after the hook was set! How SetWindowsHookEx manages that?
I read that it only applies to processes that load user32.dll. My weak suspicion is that in a case of global hook, Windows somehow injects my custom dll code into user32.dll "hook-chain". And then, when new process that loads user32.dll is started, it automatically loads my hook with it? Is this correct or is there some other mechanism at work?
_LL (low-level) hooks are not injected anywhere, win32k (the kernel part of the window manager) calls the hook callback function directly. This is why that thread needs a message loop. Low-level hooks are always "global".
MSDN says:
Be aware that the WH_MOUSE, WH_KEYBOARD, WH_JOURNAL*, WH_SHELL, and low-level hooks can be called on the thread that installed the hook rather than the thread processing the hook.
You should think of hooks as having 3 modes:
Low-level (keyboard and mouse only)
Thread specific
All threads
The last two might require Windows to inject the .dll.
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
Do all events / callbacks registered via common Win32 APIs such as RegisterHotKey etc. get cleaned up after the process that created them dies?
I suppose that yes but just want to be 100 % sure that there's nothing left after my App closes even in cases when my own cleanup didn't finish properly.
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 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.