Keyloggers: Thinking behind one

Before we start, I would like to tell you that, if you need to use this knowledge for any mischief or any *educational purpose*, do it at your own risk. Even if it was for mischief, be smart about it.

In this article, I’m not going to put codes a lot, rather I will explain what would be my fundamental approach building one. At the end of this article, will be a URL for my GitHub repository where you can download and use which I explain throughout this article.

(To understand and to continue working with this sourcecode will require some good knowledge in .Net)

Choosing the technology

Technology for things like this depends on just one thing. “Who is your victim?” My feasibility study led to a Microsoft Windows computer with .Net Framework 3.5 installed. So I choose to use .Net for this. Not only because it was a Windows computer, I love coding in C#.

Such applications need to be discreet at OS runtime. So it is obvious the applications cannot be a Windows Forms application. So I used a windows console application with the console suppressed. The application will be running on the background without raising any alarms of virus guars or the actual user.

I won’t be having continuous access to the victim’s computer so, reading the data has to be done remotely. Let’s think of a way…. maybe emailing a log as an attachment to an anonymous email? should do the trick. So, SMTP to the rescue. I would set a background worker for a set time, maintain a log and push it via an email periodically and delete the sent logfile from the victim’s computer.

The core of a logger

By default, C# does not come with hardware-level hooks or event listening in the language, as a workaround, we can use Interoperability Assemblies for this job, where we can use windows resource dll files to hook a hardware level event in our application. We are going to make use of some dlls as following.

• wininet.dll
• user32.dll
• kernel32.dll

Above Interop Assemblies will let us tap some valuable windows resources such as keyboard hooks, mouse hooks, and their events. Once you include and register a keyboard hook, it will start listening to your keyboard and start giving you keypress/up events. Some of these keys will not come as with the friendly key value with it. for example, hitting the ‘0’ on your number pad won’t necessarily give you a 0 in keyboard value in a hook. Rather it will give you a value of “NumPad0”. So make sure you do your homework before building and deploying a logger otherwise you will receive garbage values that don’t make any sense.

Like I mentioned, periodically, you need to push a keylog outside of the victim’s computer so having a reliable way to check for the internet connection is critical. The following are some critical Interop functions we are going to uses in this.

• InternetGetConnectionState – Check internet often
• SetWindowsHookEx – Use to register a hook and get a handle
• UnhookWindowsHookEx – Release a hook you registered
• CallNextHookEx – Keep getting next hooks
• GerModuleHandle – Need this object to be passed as a parameter to register a hook

With all these thinking and technology, we can build a discreet keylogger that would get you data periodically as you define in your application. However, when you do through the written application source, you will realize why and how things are done.

However, planting this bug on your victim’s playground is your own creativity and risks.

Happy Hunting!

GitHub Repository Here