« Propeller Projects | Main | Rants »

Saturday, January 14, 2012

Key and mouse logger program (KMH)

I don't think there's a single person who's used a computer who hasn't had the experience of entering a large amount of text into a word processing program or a web browser data field and had the program crash losing the work forever. Eliminating that experience was just one of the reasons that I wrote a keylogger program. The primary reason to have a keylogger is to determine how much time I spend in front of a computer and what I'm doing during that time. The other ability I added to the program was logging of mouse movements; this can be either the insane mode where every single mouse movement is logged or the more reasonable mode where just mouse clicks are logged along with the title of the window in which the mouse was clicked.

Keyloggers seem to have a bad reputation and the first programming site where I attempted to post this code got the discussion thread shut down with a curt "we don't approve of keyloggers". Yes, keyloggers can be used to acquire peoples passwords and spy on people but we don't ban automobiles because they can be used to commit murder, facilitate driveby shootings and make escaping from a bank robbery much easier than on foot. Keyloggers are just a tool and the user of a tool is responsible for any actions they do while using the tool. The program I've written makes absolutely no effort to hide itself and has a window that shows how many keystrokes have been logged as well as the number of mouse interrupts.

This program will be of interest to people who want a means of text backup beyond what is provided by most modern word processors periodic document save abilities, people who engage in life-logging and people who are curious about how much time they spend in front of a computer. I have this program running on all of my home and work machines and am hoping that someone will make the necessary modifications to make this program even more useful.

The program is written in VB6 and has been tested on WinXP and W7. Users of W7 should be warned that W7 has a very bad habit of unhooking keyboard and mouse without any warning to the user. This is a very annoying W7 bug and there are workarounds for this but the only way to ensure that keyboard and mouse are hooked is to periodically look at the KeyMouseHook (KMH) program window and see if the # of mouse interrupts is updated as one moves the mouse around the screen. The output of this program is incredibly inefficient as I basically wrote a test program and decided that it was good enough for what I wanted and stopped development. All output is in the form of text strings to a log file and, be warned, the logfiles can quickly get large. This means that every week or less (depending on how much typing one does), the program has to be stopped and restarted to create a new log file. It's a relatively trivial operation to make KHM log to a binary file but I don't have the time for it right now and can live with the limitations of KMH. I'm hoping there's someone out there who finds these limitations intolerable and will take the program to the next level of usability.

To analyze the logfiles, program KMH_logfile_list3 is provided. This program has a hard coded input filesize of 25 Mb (which can be readily changed by anyone who still programs in VB6) and it outputs data in 3 forms:

(a) Keyboard events and mouseclicks vs time

This feature allows one to track when user activity on a computer occurs and the data is output in csv format so that it can be readily read by DPlot.

(b) Mouseclick data

Here every mouseclick and the window title in which the mouse was clicked is output. The primary use I make of this data is in keeping up my CME hours which are now a requirement of the BC College of Physicians and Surgeons. It lets me know whenever I'm on the BC College full text journal site and which paper titles I've reviewed. I never remember to keep track of my online CME and KMH allows me to do so. Employers can use this printout as a means of finding how much time their employees are spending on Facebook or porn sites (someone using an office computer as an employee has no expectation of privacy while they do so).

(c) Text string data

The final mode of KMH_logfile_list3 provides a listing of every keystroke entered by the program as a textfile and, for someone that makes a lot of mistakes while typing, it can be a rather messy output file. For someone who's spent 2 hours entering a document only to see the word processor window disappear with all their data, this file can be immensely helpful.

After some frustrating sessions retrieving some files that were lost in program crashes I finally had enough and added another option: DecodeBackspace.

What that option does is to use {BS} character to delete the character that preceded it. There are some bugs which are explained in detail in the Readme file which is part of the .zip distribution file.

Of course every password that one has entered will be available as a text string in this form of logfile output and users have to get into the habit of stopping text logging before they enter any sensitive passwords. Another useful feature some motivated person can add would be a key command, say {cntrl}{alt}P which would disable logging of text until the same key combination was entered again. It might be better to just disable keystroke logging for say 1 minute as people will likely forget to re-enable logging.

These two programs are available for download at this link. They are provided with full source code and no support as the source code should be self-explanatory. They are licensed under the GPL. I won't be responding to any emails of the form "how do I <some aspect of program>". There are instructions given on how to run the programs in the zip file which contains the binary windows .exe files and VB6 source code. If something is unclear, I would like to hear about it but the target audience for these programs is software developers who aren't afraid to delve into the source and start hacking it. These are quite trivial programs which just hook keyboard and mouse at a low level. There is a M$ warning that such hooking can slow the system down as all keyboard and mouse input now goes through the KMH program. In order to prevent any system slowdowns, absolutely minimalist coding was used to grab the mouse and keyboard messages before passing the message to the next hook in the chain. All messages are stuffed into a FIFO with a depth of 256 messages.

This program comes with the obvious warnings of not installing it on a computer which one doesn't own or which is shared by a number of people without first telling everyone who is using that computers that every keystroke and mouseclick is being monitored.

KMH is distributed under the GPL. Specifically, KMH is released under GPLv3 or any subsequent version of the GPL. For reasons to do this, the reader is directed to Richard Stallman's discussion of why GPLv3 will better protect this rights of programmers Releasing my software under the GPL means people are free to do what they want with the source code but I'd appreciate being informed of changes people have made and my email address is given in pseudo-code form in the source code. The only restriction on use of my email address is that people are prohibited from posting the decrypted version of my email address anywhere on the internet.

Posted by Boris Gimbarzevsky at 1:37 AM
Edited on: Saturday, January 21, 2012 9:53 PM
Categories: Pure software

Wednesday, December 14, 2011

TDSS infection

Not really an electronics post but details my problems in getting rid of a TDSS infection. TDSS is a rather elegant (or nasty depending on how you feel after being infected) rootkit. I figured it out rather easily once I had become infected which was likely as a result of reading a paper about TDSS in April of 2010. What happened was that I was visiting a rather shady site and my Firefox download page appeared but nothing appeared to be downloaded. I left the computer a few minutes later and when I returned in an hour or so, my laptop was in the middle of a reboot. This was very annoying as I had no way of stopping the disk check that had started. Considering that this process needed to be done I left it alone for another couple of hours to finish the disk check. When I returned, it gave a cryptic disk failure error and wasn't able to boot.

This is where I got worried as I've had SMART information from my HDD telling me that it's getting old and time for a replacement. First order of business was to copy all information to a USB disk drive and so I rebooted the machine into safe mode with DOS. This it did just fine (the DOS part) but then the C: drive appeared to be empty. This was somewhat disconcerting, especially as the USB drive I was going to copy files to was also empty but had no free disk space. For some obscure reason I typed in:

dir c: /a:h

and suddenly all the files in root directory appeared. I still hadn't clued into the fact that I'd been infected with malware at this point and decided to remove the hidden tags on files with:

attrib C:\ -H /S /D

what the command above does is to remove the hidden attribute from all files and directories. Actually I forgot about the directory bit initially and had to run the command twice which was very annoying. Once I was able to find my copy of Restorer 2000 (a very usefull program that has saved my ass more than once) I initiated an image copy of my C: drive to a file image on the USB hard drive.

While waiting for this image copy to finish, I started poking around my laptop and found that Task Manager was disabled. This was very odd. I did manage to launch Process Explorer and there didn't appear to be anything amiss in the minimalist system that runs in safe mode. Out of curiousity I launched WinHex to take a look at my hard drive and this is when I first became aware that I was infected. I have an 80 Gb HDD on my TC4400 laptop which, for some unknown reason, has an unused 10 Mb of disk space at the end of the drive. What WinHex showed me was that I had an extra drive on my system of 10 Gb in size. This appeared to have an NTFS boot sector but was only about 750 Kb in size which I found out when I copied with with WinHex.

This was when I went to the internet and found out that the disappearing icons and files were a symptom of a TDSS rootkit infection. This was somewhat discouraging, especially as TDSS has a nasty habit of presenting a perfectly normal system picture to the user while it controls the system.

Perhaps my response to infections of this nature is a bit different than other peoples as I view them as an interesting problem to be solved. Once I had backed up my system to an image file and verified that all of my files were safe, I undertook the process of engaging in combat with TDSS. The removal of hidden attributes from all files made my XP system bootable except I was presented with a blank blue screen and a task bar. Using cmd.exe, I launched all of the programs that I needed for my assault on TDSS. This version of TDSS didn't terminate Process Explorer. The first order of business was to also launch regedit to find out where this piece of malware was hiding. The program was quickly found as one that was to be run at startup and I neutralized it by changing the file extension. I had my WiFi card turned off as whenever it was turned on there would suddenly be a stream of packets to and from my machine.

I started up Wireshark to capture all packets sent to and from my machine and then enabled WiFi. What was curious was that I suddenly had a lot of cookie setting requests and there was no web browser running. Tracking down where these were coming from led to Explorer and terminating explorer would cause a cessation of the internet activity. Then it was a matter of launching explorer and terminating threads one by one until the internet activity stopped (or Explorer crashed). It didn't take long to narrow the internet activity to Flash related threads as killing these threads resulted in total silence on the internet.

Things still weren't back to normal as the rogue process would appear periodically sending out huge amounts of network traffic which I watched with TCPview. Killing Explorer stopped this process. When I'd finally neutralized Explorer takeover by renaming all Flash related files to *.vir, I had a system which was almost back to normal. I thought I'd dealt with the infestation as things seemed quiet but then suddenly network activity started up again. This resulted in a second search for what might be involved and found an internet related thread which was killed. Note: there were two threads one of which was WININET.dll!InternetLockRequestFile+0x17f9 and another which was similar but I think ended in wait for object. The latter thread was left alone and the first one was killed and this resulted in TDSS going to sleep for the rest of the night as there was only normal network activity picked up by Wireshark.

I hadn't rebooted yet and didn't feel like manually editing my partition table yet so I thought I'd try Firefox and, sure enough, lots of internet activity besides what I was doing started up. TDSS is intelligent enough to not interfere with normal browsing but when I did a Google search, suddenly I was being redirected to ad sites. At this point I'd had enough and ran TDSSKiller program which really only fixed the boot sector leaving the infection behind on the partition that TDSS had created. The version of the program that infected my machine was Rootkit.boot.SST.b

Looking at my image disk copy reveals that TDSS grabbed the 10 Mb of unallocated space at the end of my hard drive and created an NTFS partition there. It loaded its own bootloader and modified the disk MBR to boot from the partition it created. I was able to see this partition in the XP Disk Management tool but had to launch the tool via the command line a TDSS deleted all references to it from both the programs menu and control panel. Haven't run IDAPro on the boot code yet, but it's clear that when the infected system is rebooted the TDSS bootloader program is started which presumably executes code which modifies XP disk drivers so that TDSS is hidden from the OS. I haven't experienced this form of TDSS as it revealed itself so obviously when it hid all of the files on my disk. Whether this is deliberate or a bug I have no way of knowing. Maybe the average user, when faced with this situation, will just reboot again and it may be that one more reboot was required to create a system where TDSS is completely hidden. My response to a system which appears to be malfunctioning is to reboot into safe mode with DOS and do an immediate backup to an external drive before I do anything else.

TDSS left a couple of potentially usefull DLL's behind whose entry point names suggest that they're capable of executing low-level disk operations. When I have more time will play with these tools as well as disassembling the .tmp file that TDSS dropped into my temp directory. From what I've read thus far on the internet about TDSS, apparently it's capable of evading most anti-viral programs. That's probably why I caught it as I use no antiviral software. All of the antiviral programs I use run in my wetware and, whenever a computer starts to behave strangely, I start using my hacking tools to see WTF is going on with it. What's concerning is that the Kaspersky TDSSKiller program just changed pointers in the MBR and dumping out the end of my HDD with WinHex revealed that the TDSS created NTFS partitiion is still there will all of the TDSS boot code. Most of the TDSS code is encrypted as running the WinHex AnalyzeBlock function on the TDSS created partition shows that every byte has almost equal occurrence probability which means that whatever encryption/compression function TDSS uses does a damn good job of simulating white noise.

Being able to almost kill TDSS just from the command line is something that feels good. I expect that if I'd manually edited the MBR to boot from the primary NTFS filesystem that TDSS would be history as all references to the services that TDSS needed were extirpated from the registry. I might be fooling myself as TDSS is good enough to modify windoze sys files and fudge the checksums so that the windoze system respore process won't replace them with pristine copies. There's some very interesting material on this rootkit and it's modifications on the following site. I've already spent far too much time on this problem but it's the type of thing I do enjoy doing. NOTE: how TDSS depends very much on the details of each individual system and you can't count on being as lucky as I was in being able to play around with the rootkit like I did.

Last edited 15/12/2011 T:=00:19

Posted by Boris Gimbarzevsky at 8:14 PM
Categories: Pure software

Monday, July 04, 2011

Keeping track of electronics projects

One of the things I rarely get enough time for is electronics and, if medicine didn't pay so well, I'd work in the area again (at least until I got fed up with it and did something else). Still, it's something I really love doing. One of the problems I've found with my electronics projects is that I'll work on something for a weekend or two, get it partially working, and then leave it for 6 months. When I return to it I find that I haven't made any notes because everything seemed so obvious at the time and I essentially have to start over again. Then it occurred to me that I've got this great piece of software, Thingamablog, which can be used to store the information in a blog format.

There is a considerable difference in how I document stuff for when I think I'm the only person who's going to be looking at the documentation and when I document it for a project I've been asked to do by someone. In the former case, there might be a few quickly scribbled schematics and terse notes about unexpected things that happened but I still suffer from the delusion that if something is so clear in my head at the time I'm doing it, the clarity will return in months to years time. In the case of a project that I'm doing for someone else, I document obsessively as I hate being pestered with simple questions. This type of documentation I find personally much more usefull in the future when I return to the project. Hence, if I document anything I put on this blog in that manner, then I'll have produced documentation that will be much more likely to prevent me from rediscovering the same quirks about a circuit or program in the future. Also, as I'm not the only person with the same fascination for things electrical, then other people might benefit from my experiences. Hence, putting it out as a blog. I've lost track of the number of times that I've stumbled upon the solution to a problem that was perplexing me on someones personal web page after fruitless searches on the device manufacturers web site.

This blog will be updated intermittently and is basically whenever I get a chance to get away from medicine from a while and indulge in my lifes most long-lasting passion.

Posted by Boris Gimbarzevsky at 9:07 PM
Edited on: Friday, July 08, 2011 1:55 AM
Categories: Pure software