Finding Hidden Keylogger Through Forcing a Computation Error

Question

It must be possible to detect keylogging by close scrutiny of timing between physical keystroke execution and the character's eventual occurrence on the screen.

I've had a friend show me this with his camera. The camera can record at 16,000 frames per second. He recorded himself typing the letter 'a' in program 1, then -- in the slow motion playback -- the amount of time that elapsed between character occurrence to the screen differed in program 2 or program 3 and so on.

This made me think. Perhaps a keylogger could be detected quickly without having to deal with the malicious design of an intelligent keylogger that can detect when it's being detected if these kinds of data were analyzed. If one knows the expectations, and there is a slight time difference on this kind of scale without other processes running perhaps something can be gleaned from such data.

I'm not sure whether this question is clear, but I'd like to know if there is any merit to being able to detect keyloggers through off-device analysis; that is, like a sophisticated camera of this caliber being used to time character occurrence.

Perhaps a physical device could be made to press keys on the keyboard faster than what a human hand can perform to generate an error which could be analyzed. Perhaps this error could be useful.

It's hard to gauge I grant you because you've probably never come in contact with a camera like this, and seen the results as I have. Anyway, maybe someone has something to offer.

Answer 1

The big problem you're going to run into if you're trying to find a keylogger by analyzing keypress latency is the monitor's refresh rate: most monitors only update 60 times per second. A good keylogger is only going to add a few microseconds of latency, so even before you take other sources of noise (such as scheduler randomness) into account, you're handicapped by what is essentially a 1:10000 signal-to-noise ratio. Yes, it's possible to find a signal that far below the noise floor (see Shannon limit), but it's not easy.

Answer 2

Practically, this won't work. There are too many other things going on in a computer. When you press a key, the OS interprets the key press and then sends notifications to any applications that are paying attention to key presses. The problem is that at any given time, your computer is doing numerous different background activities. There is no particular way to judge how long it should take for the key press to be registered as it may take different amounts of time for the OS to process and send out the event for the key press because it is working on unrelated things.

Similarly, the amount of effort it will take a key logger to be notified and record the event is minuscule and can be run on a different thread from the OS. A more effective tactic would be to monitor how many services are being notified of key events and look for a mismatch between the number expected and the number actually occurring, but this wouldn't allow for you to simply tell from timing. Timing is going to intrinsically be too variable with too little delay caused by the logger. You couldn't even use a program that would simply measure CPU time of the process you are concerned with since the delay induced by the key logger will be on the OS side of things while the process is in a wait state.

(Also as was mentioned in another answer, trying to do it visually won't do the trick as the monitor refresh is far too slow.)

Answer 3

Maybe this is something a bit higher than what most people on this site are able to answer because they have a weak background...

This is going places...

It must be possible to detect keylogging by close scrutiny of timing between physical keystroke execution and the character's eventual occurrence on the screen.

No, that assertion is invalid. Key loggers don't have to introduce a delay, and even for the ones that do, the delay is likely so small that it's well within the many introduced delays of other parts of the system, which will be impossible to isolate out.

So, no. This type of device can't detect all (any?) keyloggers; for background physical keyloggers can be made to just parasitically read the signals going directly from keyboard to computer without having to introduce any delay. What do you expect of your device in this scenario?

Introduced delay of an inline device in any case is going to be fiendishly difficult to reliably pick up on anyway - your 16k fps camera isn't the problem, and is relatively redundant given a gopro will be fast enough to keep up with the refresh rate of screens.

Software keyloggers are going to be equally impossible to try and measure since there are so many processes kicked off as part of a modern OS that can introduce timing delays that it's impossible to isolate and blame a suspected software keylogger: Keyloggers and Performance Benchmarks

Answer 4

Depending on the keylogger technology, yes, there is a particular situation where timing information might be able to yield that something changed. A USB keylogger that is implemented as a composite device or hub will add a delay when compared against the same system with no keylogger. You need to measure the timing in the host computer, though: keypress-to-screen time is so unreliable as to be meaningless.

As another answer said, you can't detect a parasitic keylogger using timing information. And a software keylogger would be better exposed through a system scan and stack trace.

The best answer is to say "not reliably."

Answer 5

In theory, you are correct, you can compare hit time and appearance time and determine if it's legit or not.

In reality however, you will face so many reasons for this timing to fluctuate that it will be impossible to ohtain a decent detection ratio.

Answer 6

Perhaps a physical device could be made to press keys on the keyboard faster than what a human hand can perform to generate an error which could be analyzed. Perhaps this error could be useful.

No. You in fact can create such a device for about $2. Just connect an ATTiny45 and a few passives to your USB port and you can bit-bang USB over the GPIO pins. From there, implementing an HID keyboard is pretty trivial. Code exists.

But you're not going to get anything meaningful out of it. The error you get when keystrokes come in faster than the machine can process -- you've probably seen it when your computer was overly busy -- is a single beep per keystroke. That's the windows event loop discarding the keypress event and moving on.

Perhaps a keylogger could be detected ... if one knows the expectations, and there is a slight time difference on this kind of scale without other processes running perhaps something can be gleaned from such data.

It's an interesting idea, and may be workable in a carefully-controlled laboratory setting, perhaps in a one-off setup. But it's fundamentally a signal-to-noise problem. There's a lot that happens between a keypress and when a character is displayed, and the speed of that process depends on all sorts of factors. It isn't going to be consistent between machines or even on a single machine from minute-to-minute.

Detecting a delay caused by a keylogger might be possible if you can keep the rest of the delay constant, but on a real-world computer, you can't. And even if you could, a keylogger could be trivially modified to simply queue up keystroke events in a buffer and process them in batches, effectively eliminating the per-keystroke delay. The one I wrote 15 years ago did just that.

Answer 7

Another answer to add to the chorus of "It won't work:"

Its possible to create a keylogger that runs as the system user that simply acts as a separate daemon: a separate program that listens to all keypresses. Since the OS is ostensibly the first actor to "hear" a keypress and forwards that signal on to any listening program, any keylogger that doesn't place itself in-between the OS and the process will neatly avoid performance hits.

UPDATED

I started looking into a way to persist malware on a GPU... and then got the idea "Well what if we installed a keylogger in GPU memory space>" GPUs use hardware drivers, so they run in kernel space... hence elevated. Sounds like a good rootkit tool!

And then I came along this paper. Damn. Someone thought of it a year ago!

Here's how the program works: process scans memory for where the usb keyboard driver code is located, then passes that address to the malware invoked on the GPU, and then uses Direct Memory Access (DMA) to simply inspect the memory where the keyboard driver stores its buffer for keypresses... I hate to tell you this, but because of multithreading, you can never be certain that a kernel process can't watch those memory buffers where the keystrokes are coming in, and it completely bypasses the standard OS API that watches keystrokes... this attack effectively removes itself from any kind of timing detection. It also directly argues as to why its a bad idea that our computing is limited to a two-state machine, but that's a different gripe for another day...

Answer 8

Looking into keystroke delays is not the correct way to identify a keylogger.

Use process Explorer and review the existing processes.

http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

select columns - process timeline

identify which process is starting with the computer that may be rouge. They often will highlight in various colors process of suspect.

You can also check with Virus total.

select columns - autostart location - if this is not normal then this also may give insight.

you can use this type of malware anlysis to seek this rouge keylogger process which runs in the background and more then likley hooked into Svchost.

if this is beyond your skill level you can run malware bytes and other similar scanners to help identify this type of software which was installed and has backdoored your PC.