HHOOK WINAPI SetWindowsHookEx(
_In_ int idHook,
_In_ HOOKPROC lpfn,
_In_ HINSTANCE hMod,
_In_ DWORD dwThreadId
);
On MSDN listed available idHook values, there are:
WH_CALLWNDPROC
WH_CALLWNDPROCRET
WH_CBT WH_DEBUG
WH_FOREGROUNDIDLE
WH_GETMESSAGE
WH_JOURNALPLAYBACK
WH_JOURNALRECORD
WH_KEYBOARD
WH_KEYBOARD_LL
WH_MOUSE
WH_MOUSE_LL
WH_MSGFILTER
WH_SHELL
WH_SYSMSGFILTER
So, what idHook should be used for hook DeviceIOControl function (for console application)? Or may i'd use some other hook method?
DeviceIOControl is for interacting with drivers, and non of the hooks windows provides in user mode allow hooking driver interaction, instead you best best would be to write a filter using the windows DDK/WDK/Windows SDK (depending what windows version you are targeting).
Related
If I want to intercept a win32 API call, specifically one of the win32 api calls listed at:
https://learn.microsoft.com/en-us/windows/win32/winmsg/window-functions
I presume I need to:
Get the explorer thread id, either from some win32 api call to get threadId by process name (or some special one that exists for explorer).
Call SetWindowsHookExA()
SetWindowsHookExA(WH_CALLWNDPROC, HookProc, GetModuleHandle(NULL), explorerThreadId)
After I call SetWindowsHookExA, I presume I then analyze the messages that are sent to my custom written HookProc to see which win32 api call i'm intercepting, to then react based on that? Are there any good examples out there for identifying which win32 api call the hookProc is being called for? Or examples where somebody has hooked one particular win32api call successfully?
My app1 PostMessage WM_LBUTTONDOWN and WM_LBUTTONUP to app2 (third-party) which is in different process.
How to make sure those message been handled by app2 in app1, the logic in app1 depends on the result of those messages after PostMessage.
Here's the pseudo code for app1
PostMessage(app2Handle, WM_LBUTTON_DOWN, 0, lParam);
PostMessage(app2Handle, WM_LBUTTON_UP, 0, lParam);
// How to ensure above messages has been handled by app2 here?
PostMessage() works asynchronously. It simply puts the message into the target window's message queue and then exits immediately. There is no notification when the message is processed. If you need to know that, you could try using a message hook from SetWindowsHookEx() to monitor the activity of the target window's message queue and/or window procedure. Or, maybe you could use SetWinEventHook() to receive events like EVENT_OBJECT_INVOKED, EVENT_OBJECT_SELECTION..., etc if the mouse messages are meant to cause such click/selection actions in the window.
I have a Bluetooth LE device with custom characteristics that send notifications to an android device just fine.
On Windows 8.1 however the notifications are not received. I can open a connection to the device using CreateFile(), enable notifications using BluetoothGattSetDEscriptorValue() and register a callback function using BluetoothGattRegisterEvent() without problems. However the used callback function is never called unless i continuously set a Characteristic value manually to keep the connection alive using something like this:
while(1){
Sleep(1000);
// Write characteristic using BLuetoothGattSetCharacteristicValue()
}
Is it supposed to work like this? How can i get the callback to be called when notifications are enabled without having to manually initiate the connection?
Under x11, how to install a hook procedure that monitors messages posted to a event queue. As we know we can use the func SetWindowsHookEx and WH_GETMESSAGE hook procedure under win32.
Most likely you need XSelectInput. When some event occurs server-side, xserver decides who to notify based on target window event mask. Unlike other window attributes, every client changing window event mask has its own copy and server notifies all clients who set window event mask. This way you can select, for example Exposure event mask for root window and receive events whenever root window rectangle is invalidated - similar to setting WM_PAINT hook in win32 api.
I have a window, and I am looking at the messages that are being sent to it using Spy++. Is it possible to determine which process sent my window a given message, if it indeed was sent from another process?
No, Win32 window messages do not contain information about where they were sent from (unless that information is specifically included as part of the message WPARAM and/or LPARAM components).