I have a keylogger on my Win8 box. Nothing sinister: it performs some useful extra work. Actually it is so useful that I want to trigger some of its functions when I am afk. Naturally AutoIt and such does not work (I've checked): the logger is hooked to a low-level keyboard hook (I guess), and real keyboard hooks are not triggered by virtual keyboard events (I believe).
Basically I need a virtual keyboard with real-look-alike keypresses.
(Edit: I've deleted my own "idea" how to solve this, it was bad anyway, and I have more understanding now)
Trying SendInput and why it does not work.
People suggested to try SendInput. In short: it does not work, because I've managed to raise integrity level of my pythonw.exe only to High, but the "keylogger" runs on System level, and, as said in SendInput doc
Applications are permitted to inject input only into applications that
are at an equal or lesser integrity level.
I've found a very nice python SendInput implementation at Python simulate keydown, in comments.
To check "integrity level" of the process you can use ProcessExplorer, View / Select Columns, check "Integrity Level".
ProcessExplorer shows my pythonw.exe which I "Run as Admin" at the IL "High", but AcrossServer, AcrossService and a spawned conhost.exe all have the IL "System". (Yes, I am trying to inject keys into the very nice Bluetooth keyboard simulator Across).
Next possible steps.
Raising the integrity level of my app to System:
make it a windows service;
make it a device(less) driver;
anything easier? or
Lowing the integrity level of AcrossService to (at least) High:
is it possible? Edit: it is possible, Control Panel / Services, change logon account to myself. Unfortunately, Accross stops working when lowered.
Create a Python equivalent of Across Server on Windows.
Number 3 seem the most socially useful and seems easier than creating a specialized device driver :) But am I missing some simpler possibilities?
Related
I'm looking for a script or a program that runs in background and blocks special keys on my keyboard (calculator, mute, etc) I have searched a lot on this on the internet but didn't found anything useful or working for me, I tried sharpkeys but didn't detected those keys on my keyboard, key id is 173 for mute on my keyboard and I can get others IDs if I find anything to block them with IDs.
P.S. I don't know much about programming and most likely don't know what I am doing, I'm looking for basic help from anyone. thank you!
TL;DR To disable all "special keys" you could change the Human Interface Device Access Windows service startup type from Automatic to Manual (or Disabled in case there is some other software installed that causes it to still start when set to Manual). Caution: this may break other input devices if present, such as IR remote controls, or Airplane mode radio management.
For background, those "special keys" are technically called "consumer control buttons (CCB)" (see for example Keyboard Enhancements in Windows 8 and the linked .docx - nevermind that CCBs long predate Windows 8).
The CCBs are handled by the Human Interface Device Access Windows service, as described at Human Interface Device Access:
This service provides generic access to specific functions contained within controls collections on HID (Human Interface Devices). It enables the use of predefined hot buttons on keyboards, remote controls and other multimedia devices.
If the service is stopped or disable, the buttons on USB keyboards will not function (i.e., back, forward, volume up, down, previous track, next track), nor will the volume buttons on USB speakers.
To change the Human Interface Device Access (HidServ) startup mode, navigate to My Computer / Manage / Services and Applications / Services, double-click the Human Interface Device Access in the list, and change the Startup type to Manual or Disabled.
To disable special keyboard keys via registry on Windows 10 go to HKLM:\SYSTEM\CurrentControlSet\Services\hidserv and change "Start" DWORD value to 4. Once you restart the system, special function keys should be disabled.
I just bought a new keyboard, and I'm interested in tracking exactly how many keypresses/strokes I make during the entire life of the keyboard. (I would want to just record keyUp, as I don't care about repeats)
I've been googling around for the best way to do this, but I don't even know what approach to take, so I'm having trouble searching intelligently.
Also, the only language I've really worked with is C#. Haven't done anything with C/C++ or WinAPI
Is it difficult to modify the Win 7 drivers directly?
I do want to be able to record keystrokes from the moment the computer boots, but this may not be easily done.
I would prefer to use an existing driver or hook, as I really don't care to get into learning device drivers right now.
I've looked briefly at Ctrl2Cap, but I don't know how to modify something like that to suit my case.
Other questions I looked at,
Writing a keyboard device driver
Low level keyboard Hook not at UI thread
This one indicates writing a USB Filter driver may work, but I have no clue where to start on that.
Disabling the keyboard in windows c++?
It is not necessary to go the driver route, which is not for the faint of heart. You can use use a low level keyboard hook which will work fine from .NET.
I did a quick bing and found the following on codeplex
http://globalmousekeyhook.codeplex.com/
It should get you going
If you want to do that you need to use Kernel Level Keylogger. It's grabs the keystrokes before the operating system takes effects and this one 99% invisible for detection techniques. Then you can grab the Windows Log On screen typed things like password/username etc.
#ChrisTaylor's key logger not work for WinLog-on Screen I reckon. If you can install the keyboard driver filter before the system keyboard device driver take a action you can handle windows user login screen also. But In order to install this driver level key hook you need to have administrator privileges.
I found Unix and Windows Keyloggers from Github. Free to play with this https://www.adlice.com/kernelmode-rootkits-part-3-kernel-filters/ and have fun!
That, what you want is dangerous!
With the same code everyone can create keylogger*
But if you not a virus creator then I recommend you to search "hotkeying in C/C++" or something like that and hook keyboard with hotkeys!
I have written HotKey Maker in VB6 which can make hotkey from every button of keyboard.
But I really not interested in viruses :)
Good Luck !
*Virus which hooks your keyboard and send all what you wrote in keyboard to Virus owner
I try to send a WM_LBUTTONDOWN and WM_LBUTTONUP messages to a window( simulating mouse clicks without moving the cursor ).
My program is working very good on many windows, but there are a few that don't work :(
Like Registry Editor, Yahoo Messenger, some Firefox sites, etc...
How can I make to work with those from above ??
NOTE#1: I use Win7
NOTE#2: My code is just calling the api and functions and aply them on the specific window handle. Its working ok but not on all windows :(
It is another aspect of UAC, called UIPI or User Interface Privacy Isolation that could cause this trouble. Designed to prevent a program that run un-elevated from hijacking the capabilities of an elevated one. That certainly explains the trouble with Regedit.exe, clearly UAC would be ineffective if a program could commandeer it to poke stuff into the registry. You'd have to run your program elevated to bypass this restriction.
Another one is that SendMessage() doesn't properly simulate mouse input. The messages you are sending are normally posted to the message queue. You need to use PostMessage() instead. You should also emulate WM_MOUSEMOVE.
The proper way to simulate mouse input is through SendInput(). That one exactly emulates the mouse driver behavior, there's no way for a program to tell the difference. But with the added requirement that you have to make sure that whatever program you are trying to automate runs in the foreground. That's very difficult, SetForegroundWindow() isn't reliable enough. So only consider SendInput() if you actually only want to send mouse messages to the foreground window, whatever it might be.
You can call SwitchToThisWindow instead of SetForegroundWindow, which is much better and it works most of the times, and then either call SendInput or mouse_event, which is much more comfortable, because you're not dealing with structs at all.
Related to my question here, is it possible to create a window hook that will monitor if an application has been opened or not?
Most that I have found about hooks seem to focus on user input (keyboard press, mouse events), but I could not confirm if it is possible to know that the "double click" the user made is to open an application, or just to highlight a word.
Thank you.
Indeed, window hooks would not be sufficient. In fact for the task you are asking about you could use various strategies, such as:
enumerating the processes to find the one you're looking for (Tool Help API or PSAPI)
enumerating the top-level windows on the desktop (but you're limited to your desktop then)
check for a global or local event, mutex (or other kernel object) to deduce from that that some instance of the application is running
... or even from kernel PsSetCreateProcessNotifyRoutine
probably there are variations on the above plus some more.
In essence the question is whether you want to check for the process or for some other indicator that signifies whether the program you want to check for has been started.
I have been working on windows automation and monitoring.
What exactly happens when I lock the screen of a windows machine?
I am working with Windows 7 at the moment, are there big differences to the behavior if I switch to Vista or the server versions?
Is there still a desktop that can be accessed via api's?
I know that i can still send key strokes and mouse clicks to specific windows (via ControlSend and ControlClick), but there seems to be no "desktop" itself.
Could someone shed some light on this whole thing or point me at a readable source where I could get an overview over the topic?
Basically what happens is that Windows switches to the secure desktop, makes it the current one, so input is now associated with it.
The old desktop remains where it was: all the HWNDs on the desktop are still there, and any thread attached to that desktop can still access those HWNDs, get their location, and so on. You can still send messages to windows on this desktop, so long as the thread sending the message is also on that desktop.
However, since the desktop is now inactive, it cannot receive input. GetForegroundWindow will return NULL (IIRC), and you can't use SendInput any longer, since input now belongs to [a thread on] a different desktop; no controls on that inactive desktop can receive focus.
Note that sending keypress messages to a control that doesn't have focus can sometimes cause unexpected behavior, since the app or control generally never expects to receive keyboard input without getting the focus first. (This can be problematic for controls that set up some sort of input context in WM_SETFOCUS and clear it up in WM_KILLFOCUS, for example.)
In short, the UI is still there: you can do certain queries against it, but you can no longer automate it as you could on a regular desktop by sending input, and some other functions that relate to focus or input may fail.
I'm not super familiar with AutoHotKey, but the name and description of functionality suggests that it's heavily reliant on the underlying Win32 SendInput API. This won't work at all for keyboard input when a desktop is inactive.
For a reasonable overview of how desktops work and how they relate to winstations, the locked desktop, and so on, check out the Desktop article on MSDN.
One issue that I've run into in the past with desktops and automation is: how to I leave a long-running test that's using some form of user input automation (mouse, keyboard simulation), but still lock my PC so that someone can't just walk by and interfere with it. Once you lock the PC, the desktop is inactive, and so the automation stops working. A similar issue happens if the screensaver kicks in: the desktop switches, and the automation fails.
One solution is to use two PCs: let's call them Main and Test: from Main, open a remote terminal services client onto the Test machine, and then run the automated test on the test machine, but from a terminal services client window on the Main machine. Now the cool part: you can minimize that TSC window, or even lock the Main machine (or let the screensaver kick in), and that virtual session will continue working, thinking that it is still active - it's just that nobody is paying it any attention. This is one way to create a "connected" session with an active desktop, but one that no-one can interfere with, because it's protected behind the locked desktop of the Main machine.
I don't know the details, but I believe the lock screen constitutes a separate "desktop" and maybe also a separate "window station" (as I understand it a window station is merely a container for desktops). The MSDN section on window stations should hopefully be useful: http://msdn.microsoft.com/en-us/library/windows/desktop/ms687098%28v=vs.85%29.aspx
In order to access a desktop, you will need to use the regular windows api's from a thread that is on that desktop. SetThreadDesktop would probably be the easiest way to do that in C, as long as the desktop isn't on a different window station.
Unfortunately, this is already difficult for a regular privileged application, and using AutoHotkey complicates it even more. Since you don't have control over threads or over process initialization, you will probably have to create a new process in the other desktop (you can do this using the CreateProcess API, which appears to have a wrapper available for AHK to which you can supply a desktop name: http://www.autohotkey.com/forum/topic1952.html). Your process will need special privileges to do this; I'm not sure that even running as Administrator is enough.