Developing a Keylogger: Hardware vs. Software Techniques
Published at – 6 min read – 1114 words
To celebrate 400+ visits to my blog after just 10 days (not bad, come on), I managed in my spare time to write another, very interesting article on another popular category of malware: keyloggers.
Keyloggers are a particularly insidious form of malware: they are software designed to monitor every key pressed on the keyboard of any device.
Unlike other malicious programs, therefore, they do not pose a danger to the system per se, but they can become a treacherous source of threat to users, since they can be used to intercept passwords, PINs, account numbers, and confidential information.
There are different types of keyloggers: hardware and software. Software keyloggers are easier to detect than hardware keyloggers; in fact, most antiviruses should block many keyloggers.
Hardware type keylogger
Modified firmware at the system bios level handles keyboard controller events and logs them when they are processed. One must necessarily have physical access to the computer or at least administrator-level access in order to load the modified firmware into the BIOS, which is created specifically for the specific keyboard in use.
Sniffing a wireless keyboard
A sniffer is exploited to intercept data packets transferred between a wireless keyboard or mouse and its receiver . When the communication between the devices is encrypted, an attack is required to decrypt it or exploit any security holes to gain access to the data. Once the attack is successful, it is possible not only to read the information but also to directly control the computer by sending commands.
A common keyboard, like any other electronic device, emits electromagnetic radiation. It is possible to capture these emissions up to the distance of 20 meters, without being physically connected to it.
At the kernel level
A program on the machine gains root access (i.e., with administrator privileges) and hides within the operating system, starting to intercept keystroke signals on the keyboard that pass through the kernel. A keylogger residing at the kernel level is difficult to detect, especially for applications that do not have administrator rights. It is often implemented as a rootkit that sabotages the operating system kernel to gain unauthorized access to computer hardware. It then becomes very powerful, being able to act like a keyboard driver and gaining access to any typed information that is sent to the operating system.
Use of User Level APIs.
A keylogger that hooks into the keyboard API within a running application. It then records events from the keyboard as if it were a component of a legitimate application. The keylogger receives an event each time the user presses or releases a key, so it can log it. Windows APIs such as
GetForegroundWindow() and the like are used to actively capture keyboard state or register to these events. Polling from the BIOS of pre-boot authentication codes not yet cleared from memory may also be performed.
The keylogger developed by me uses a special technique called Hooking; this mechanism allows messages to be intercepted before they are used by the application in question. In this case I will use a keyboard hook. For the complete list of these hooks, you can visit MSDN-644959. Whenever a key is pressed, the message/event “key pressed” is intercepted before the application receives it.
Before explaining the technical details, we should point out that there are two types of codes used in keyboard hooking:
Virtual Key Code: the Virtual Key Code is a code independent of the keyboard used, used by the operating system itself. For each key there is a unique key, for example for the Shift key, the key for
Scan Code: The scan code is a code dependent on the keyboard used, meaning that each keyboard has its own different scan code. When we press a key on the keyboard, the keyboard generates a scan code which the operating system then translates into Virtual Key Code.
SetWindowsHookEx(WH_KEYBOARD_LL,(HOOKPROC)LowLevelKeyboardProc, hExe, 0);
|Installs a hook procedure that monitors keyboard input events.|
|A pointer that is called when a keyboard event happens|
|Link to the DLL that contains the Hook procedure|
|The Hook procedure is associated with all services on the system|
|Link to the hook that is to be removed|
Determines whether a character is associated with another character such as SHIFT. In our case, it will be used to know whether a key will be uppercase or lowercase.
|Virtual Key Code for SHIFT, this parameter can be changed. More information here: https://msdn.microsoft.com/en-us/library/ms646293(VS.85).aspx|
Returns a string representing the name of the key pressed.
|dwMsg||Contains the scan code|
|Key||The buffer that will receive the key name|
|CchSize||The maximum number of characters of the key name, including the last null character that determines the end of the string (must be less than 15).|
Passes information about the current hook to any subsequent hooks
CallNextHookEx( NULL, nCode, wParam, lParam );
|nCode||The next hook procedure|
|wParam||The value of wParam passed to the current hook|
|lParam||The value of lParam passed to the current hook|
- Create a thread to initiate the “Keylogger” event.
CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE) KeyLoggerStart, (LPVOID) argv, 0, NULL);
- Install the keyboard hook with SetWindowsHookEx.
SetWindowsHookEx(WH_KEYBOARD_LL,(HOOKPROC) LowLevelKeyboardFun, hInstance, 0);
- Check the virtual key for each button pressed and write it to a file
- Call CallNextHook to pass the hook to the application
CallNextHookEx(NULL, nCode, wParam, lParam);
- Register a key for program exit
RegisterHotKey(NULL, 1, MOD_CONTROL, 0x39);
- Free up resources for the next hook
After implementing the algorithm, I was curious if the system would block it for me; The result? No, Windows does not block any program with such behavior. I did not quite understand why Microsoft engineers did not block some functions for programs outside the system like mine.
After all, is it possible to actually recognize a malicious program from a non-malicious one? In this case it is difficult to discriminate what is malicious and what is not. You might say that to identify them you only need to see which programs access the keyboard, yet every program accesses the keyboard, even to do trivial tasks (how does a program respond to a key prompt?). It is not permissible to block every access to the keyboard.
Hoping that some antivirus would block it for me, I tried running a scan on Virus Total, but surprise: no antivirus blocked me. How is it possible that in 2017 there are still no antivirus that can block keyloggers? What’s more, developed by yours truly, so not even perfect.