As far as I know, there are two general types of keyloggers in Windows - hook-based keyloggers and hardware interrupt based keyloggers. I can see no feasible way of detecting or fooling an interrupt-based keylogger; however, I think I might have an idea how to mess up a hook-based one. Since Windows won't allow enumerating all existing hooks in the system (which, to me, seems like a security fault), the only way to detect if a keylogger is active, is by monitoring RAM and HDD access/usage. However, if the aim weren't to detect the keylogger, but simply assume that one was running, it should be possible to obfuscate the data that it captures. Since a system-wide hook-based keylogger handles all keyboard events and interprets them as text as seen in the Windows message pipeline, sending key events to a window that cannot process them should also register in the keylogger while not using up almost any CPU time or intruding the system in any other way. If this is so, then it should be easy to obfuscate any logged text by responding in a separate system-wide hook to any given keyboard messages and sending a number of "dummy" key messages down the pipeline as a response (NOTE: this could also work if the keylogger was only logging events meant for a specific window if it were possible to make sure that a separate hook were to be guaranteed to be the last one in the chain and cancel all of the dummy messages; if anyone knows if this is possible, let me know). Also note that if the actual text is obfuscated with segments from real words, deobfuscation will be impossible. NOTE: keylogger detection seems to be far more difficult than obfuscation (not to mention much more error prone), which leaves only the issue of whether you're content with not knowing whether a keylogger is running on your computer as opposed to whether you're content with assuming that you're tricking it in case one is running on your computer. I haven't tested this - so far it's just an idea. My question is: would this work and how easy would it be to cheat it? This is an open discussion, so feel free to expand on the topic (of anti-keylogging) and provide any insight you might see suitable. Cheers! [Edited by - irreversible on October 9, 2006 4:12:13 PM]

Wouldn't sending lots of fake key press messages cause apps to start diaplying randem keys?

Quote:Original post by Smit
Wouldn't sending lots of fake key press messages cause apps to start diaplying randem keys?

The idea is to send a small number of dummy keypress notifications in response to each keypress. If you're typing fast, you're probably not typing faster than 4-6 characters per second (multiply by two for key-up and key-down events). Obfuscation would pump this to up to 12-16 keypress notifications (24-32 messages in total) per second. These are sent to a dummy window (which probably doesn't even have to be visible and is never active). I don't think you could hang or screw up the system in any way by doing that.

EDIT: few people type faster than 1-2 charaters/second on average (this assumes you think about what you're typing).

What about ones that call GetAsyncKeyState? I don't know this works exactly, so I'm not sure what could be done about them.

Well, I'm not trying to write an anti-keylogger, but I have been fondling the idea of writing an obfuscator (for the heck of it, really). As I mentioned, it has the (so far, admittedly, potential) great advantage of being completely foolproof against hook-based keyloggers. I'll probably test this soon, but it'd interesting to see if it's also effective against GetAsyncKeyState() (thanks for the tip, MrEvil).

As for code injection and rootkitting - I don't want to do that (I'm not writing a commercial application, so I get to choose what I do and what I don't do). First of all, as far as I know, that would require driver-level access, which is way out of the scope of what I'm trying to accomplish. Secondly, there are probably utilities out there that already do that.

A hook-based obfuscator would be suitable when chatting or writing emails in a home environment with no "real computer nerds" about, who'd run something inbred enough to not be detectable anyway.

Although... is there a more hardware-driven approach of invoking a keyboard interrupt (such as one would expect to encounter when a key is actually pressed on the keyboard)? That is, can hardware interrupts be faked? I'm aiming for Win2000 and up.

It's the same with hiding processes - if someone really wanted to do that, they could take up the task and hide the process so that it wouldn't have any fingerprints in the system at all (apart from being run), thus being undetectable by any means other than monitoring the raw kernel thread chain. But again, that's a little hardcore for me.

kSquared - thanks for the pointer; although, I think the easy fix would be to broadcast certain (if not all) elements randomly. Sending five key notifications a seconds at random intervals should increase the average load only a little (which should thus remain insignificant) and flood the keylogger with up to 99% garbage.

What you are talking about is called Winnowing and Chaffing. There might even be some work done for this very problem, I dont know.