I'm writing a keylogger/mouse tracker for use in an opensource input heatmapping application basically identical to Razer's newest heatmapping software, but for use with any hardware/OS (using Qt's amazing cross platform SDK). As you would imagine, this involves intercepting keyboard and mouse messages from the kernal when the application is not the main process.
For Windows I was drawn to GetAsyncKeyState, but there's a note on the return value from MSDN about this function returning zero if "the foreground thread belongs to another process and the desktop does not allow the hook or the journal record."
Barging ahead regardless, I wrote a method for getting the keyboard state (that triggers every set interval of time via Qt's QTimer methods) and it just worked:
//The following executes every 100th of a second:
for (int i = 0; i < 256; ++i)
{
keyboardArray[i] = GetAsyncKeyState(i);
}
As I watch this array in the debugger, I can see the values in the array change as I type even when the application is not the main process. So, for my computer at least this function works at monitoring key states when the main thread is not focused on my application.
My question is: In what instances does Windows not allow hooks or the journal record? In other words, are there some versions of Windows and/or privileges a user could have/not have where this method could fail? I don't really have access to a bunch of different machines to test this on.
My specs are Windows 7 Home Premium 64 bit, Intel i7 930 (2.8 GHz, quad core hyper threaded), 12 GB DDR3 1333 MHz memory, 2x Nvidia 460 if any of that helps.
Best Regards,
- Weikardzaena
EDIT:
Hans Passant gave me an example of situations where this type of implementation would fail: mainly applications on Windows that include User Interface Privilege Isolation (UIPI). Basically if an application is really important to the operating system (like a command prompt) then this type of message intercept will not work. I even tested it and it's true: my application stops updating the keyboard array when a command prompt is the main thread.
This and what LoPiTaL said suggests that only specific applications will not allow this type of intercept to occur. I'm mainly aiming this application toward gamers who (like myself) would like to see key presses and mouse clicks for their gameplay, so maybe I don't care about this issue as much, but if I want to expand this to general use (including people who use CMD a lot) then it seems like there's actually no way to intercept key messages for those types of elevated applications.
Is that true, or can methods like SetWindowsHookEx still intercept messages to UIPI applications? I was trying to avoid implementing hooks directly because that might be viewed as a virus on people's home machines, and capturing and re-emitting every input message just slows down everything, which in gaming is pretty big deal.