Keylogger project, 4

30.10.2005 21:47

I'm still experimenting with the prototype board I've made last week. Today I've attached two cables to the board: one for the computer and one for the keyboard. Since proper PS/2 connectors are hard to come by, I've simply bought a cheap keyboard extension cord and cut it in half. You can see the board connected to my computer on the picture below.

At the moment it looks like I've chosen the right software approach. I've been able to put code that reads scan codes from the keyboard to one buffer, code that sends scan codes from a second buffer to the computer and code the copies data between two buffers into 971 bytes of machine code (or 417 lines of C). That leaves more than a kilobyte of space for the code that sends data in the opposite direction and serial EEPROM driver code.

Even though the current prototype is only capable of moving data from the keyboard to the computer and not vice-versa it seems to work surprisingly well (I'm writing this post through the key logger). Regarding the complexity of the PS/2 protocol I didn't expect that the keyboard would be usable if it wasn't able to receive commands from the PC. Caps lock LED and other LEDs aren't working of course.

One interesting thing I noticed is that the keyboard will send a packet containing hex 0xAA to the PC as soon as it is turned on. If I let this packet through, the computer (running Linux) will ignore any key presses. I'm guessing it has sent some command to the keyboard (which won't currently reach the keyboard) and is waiting for an answer. The quick and dirty fix was that I simply added a filter to the key logger code that won't let a 0xAA through.

Posted by Tomaž | Categories: Digital | Comments »

Bad capacitors

29.10.2005 10:42

I've just got my first case of bad electrolytic capacitors.

I am trying to reuse an old 486 as a wireless bridge. Since this computer served as my ADSL router and web server for four years I thought it was going to work without problems. I only inserted a new wireless ethernet card into a free PCI slot and turned it on. I've heard a small click and thought something got into the CPU fan. I turned the computer off, cleared cables from the vicinity of the fan and tried again. This time there was a series of loud bangs coming from the power supply and a strong smell of burning plastics and simultaneously all LEDs on the computer went on.

It currently looks like the two large high-voltage 330µF capacitors in the power supply blew. They were both too hot to touch when I opened the PSU and one of them has an opened top.

I just hope nothing else got fried in the computer.

Posted by Tomaž | Categories: Life | Comments »

One click opensourcing?

27.10.2005 18:23

Unfortunately not :)

Posted by Tomaž | Categories: Digital | Comments »

Pipin link

26.10.2005 20:50

What are we going to do tonight, Brain?

Same thing we do every night, Pinky. Try and take Cyberpipe's link down!

Posted by Tomaž | Categories: Life | Comments »

Keylogger project, 3

26.10.2005 20:43

This is a simple prototype I've made for testing. It has two diagnostic LEDs that won't be there in the final version and it is currently missing connectors for the keyboard and computer.

I'm currently working on the second software approach. I've managed to pack a simple function that is capable of sending some data with proper timings into approx. 300 bytes of code. I think this leaves enough space for the serial EEPROM driver and the data receiving functions, but the fancy menus in the control mode are definitely out of the question. I also think that I have enough processing power available so that transmission delays shouldn't be noticeable.

Posted by Tomaž | Categories: Digital | Comments »

Spam crashes OS X Mail?

20.10.2005 8:53

I've been getting some strange spam lately. While Thunderbird doesn't seem to have problems, it crashes my Mac OS X Mail. Each time I open the Junk mail box, the application crashes with Sorting messages displayed on the status line. It doesn't respond to the Quit command and I have to use the Force quit from the Apple menu.

The solution I found at this time is to ctrl-click on Junk mailbox and select Delete junk mail. Mail will crash anyway, but next time I open it, the Junk mailbox is empty and the nasty mails are gone.

I'll see if I can find the specific message that causes this.

Posted by Tomaž | Categories: Code | Comments »

Keylogger project, 2

19.10.2005 11:03

I want my key logger to work in the same basic way as the KeyKatcher. This means that it must operate in two distinct modes: In the logging mode, it must only monitor the communication between the keyboard and the computer. In the ideal case it should not modify or affect the communication in any way. In the control mode, it should appear as a computer to the keyboard and as a keyboard to the computer. It receives commands from the keyboard interface and prints information (menu choices, stored data, etc.) to the computer interface.

The problem here is that PS/2 is a pretty complicated two-way two-wire protocol that is not very easy to emulate with a 801 microcontroller. The biggest problem that appeared so far is how to implement the transparent logging mode. I'm currently considering three approaches:

 <-- to keyboard          to computer -->
                 _______
 CLK  ---o------|       |------o---- CLK
         |      |switch |      |
 DATA ---+---o--|_______|--o---+---- DATA
         |   |      |      |   |
         |   |      |      |   |
         |   |   _______   |   |
         |   +--|       |--+   |
         |      | 8051  |      |
         +------|       |------+
                |_______|

This is the hardware approach. When the key logger is in logging mode, the electronic switch directly connects keyboard to the computer and the 8051 is only pasively monitoring the communication. In control mode, 8051 turns the switch off and communicates with keyboard and computer separately. Good sides: key logger is undetectable in logging mode. Low processing and code memory requirements for the 8051 in logging mode, since we are only monitoring the bus. Simple 8051 code (no hard real-time code required). Bad sides: requires an additional chip which means a bigger device.

 <-- to keyboard          to computer -->
                 _______
 CLK -----------|       |------------ CLK
                | 8051  |       
 DATA ----------|       |------------ DATA
                |_______|

This is the first software approach. When the key logger is in logging mode, the 8051 software mirrors signals from the keyboard to the computer side and signals from the computer to the keyboard side. Because the PS/2 bus heavily exploits the properties of the open-collector outputs (the bus line works as a wired-or), the coupling code needs to be pretty complicated (as far as I see, a state machine with 3 states) and must use polling instead of hardware interrupts. Good sides: Low code memory and RAM requirements for the 8051 in logging mode, since we do not need to decode the protocol and/or buffer data on the fly but are only mirroring the bus. Bad sides: Hard real-time code required. CPU intensive in logging mode (not sure if even feasible with 24 MHz CPU clock and 10kHz PS/2 bus clock). Detectable in logging mode since software bus coupling introduces delays and glitches.

The second software approach. The key logger always emulates the computer on the keyboard side and keyboard on the computer side. In logging mode it, for example, receives data from the keyboard, decodes it, puts it into buffer and (when possible) transmits the data on the computer side. The receiving and transmitting code can work from interrupt service routines. Good sides: Low processing requirements for the 8051 in logging mode, since we do not need polling of inputs and state machine emulation. Real-time code contained in interrupt service routines. Undetectable if the computer side fully implements the PS/2 protocol. Bad sides: Large RAM requirement because of buffering. Large code memory requirement because of all decoding and buffering logic.

Basically, the first software approach hits the processing limit of the 8051 and the second approach hits the code memory limit.

Posted by Tomaž | Categories: Digital | Comments »

I hate MMX

17.10.2005 22:48

Do you want your code to be fast? Take my advice and don't even try hand optimizing it for these fancy SIMD instruction sets like MMX, SSE and similar. In fact, don't even google for "mmx optimization" or you'll be deceived by pretty numbers and benchmarks and you'll forget what you've read here. You will spend hours writing optimized memcpy() functions, parallelizing loops in your code and putting those damned PREFETCHes everywhere. And in the end (if you're anything like me), you'll rm -rf everything in frustration because no matter how you look at things, your cool assembly MMX optimized code will always run slower than plain dumb unoptimized C.

Or perhaps I'm doing something wrong here? Perhaps not. (No, I'm not mixing floating point and MMX!) Even AMD's optimization guide says that in most cases you should use scalar instructions instead of vector ones. Instead of parallelization it recommends some (in my opinion very ugly) hacks that enable you to take for example some control over what is stored in processor cache, how instructions are pipelined and how successful branch predictions will be. Those video software guys must be practicing black magic or something if they really get that 200% boost from MMX.

The problem I see here is that today's CPUs have too much internal logic that thinks it is smarter than you and reorders instructions, renames registers, controlls cache, ... I agree that's good for those 99.9% of the code that you don't want to bother optimizing, but for the few loops that need to be hand optimized, this is a nightmare. Instead of simply instructing the CPU to store this and that in its cache, I have to perform some weird sequence of reads from memory (take a look at some of the examples in that optimization guide if you don't believe me) so that I'll trick CPU's internal logic into thinking that perhaps it is a good idea after all to store that in the cache. And if I don't do it just right, the wrong things will end up in cache and that latest CPU will start emulating a 486. It would be nice if CPUs would have a mechanism to turn all this mess off and let me be in control for a while.

I miss the days when I could count the exact number of cycles the CPU needed to execute a function instead of having to measure it with 10% uncertainty.

Posted by Tomaž | Categories: Code | Comments »

PCB layout goodness

16.10.2005 10:32

Board design in pcb:

PCB screenshot

Final result:

PCB screenshot

Posted by Tomaž | Categories: Digital | Comments »

Microsoft press

14.10.2005 16:34

A quote from Visual C# .NET Step by step, page 262, chapter 14:

If you want to continue to the next chapter
  • Keep Visual Studio .NET running and turn to Chapter 15.
If you want to exit Visual Studio .NET now
  • On the File menu, click Exit. If you see a Save dialog box, click Yes.

This suggests that there are people who have already read 260 pages about C#, understand "properties to access attributes" and who have to be explicitly told to turn the page of this book if they want to continue reading. Obviously the average Windows programmer must be in even worse shape than I thought if the instructions on how to exit Visual Studio must be repeated for him at the end of each chapter.

Posted by Tomaž | Categories: Life | Comments »

Keylogger project, 1

12.10.2005 20:28

I have to design, implement and document a simple electronic device that uses some kind of a microcontroller as a term project at the Faculty. Since I didn't find any of the proposed projects particularly interesting (why should I need another temperature controller or another digital thermometer?), I decided I will try to copy ThinkGeek's KeyKatcher.

It is critical for this device to be small (it should be handy, since you never know when you'll have to troubleshoot some software :) so I'm going to use a microcontroller that requires a minimum number of external components and a single high-density Flash or EEPROM chip.

I'm currently thinking of a combination of Atmel's AT89C2051 microcontroller and 24C1024 serial EEPROM. 2051 is a 8051-compatible chip that only needs an external quartz crystal for a clock generator. It has 2kb of internal read-only FlashROM for code, 128 bytes of RAM and runs at maximum clock frequency of 24 MHz, which should be more than enough for simple keylogging. 24C1024 would give my device the same memory capacity as the KeyKatcher, is both physically small (DIP8 or smaller package), has a large capacity and is simple to use.

FlashROM is cheaper then EEPROM and comes in even higher densities, but has two big problems: it mostly requires 3.3V or lower supply voltage (it's designed for cell-phones, etc. where power consumption is critical - keyboard supply voltage is 5V) and requires that a block of 128 or more bytes is written at once. Since 2051 only has 128 bytes of RAM, I don't have enough space there for a buffer that large. That means that I would have to either add some external RAM to 2051 or switch to a more powerfull CPU. First option means a bigger circuit and the second one means I would have to work with a CPU I don't know as well as 2051.

I guess 2051 won't be able to perform all of the functions KeyKatcher does (like searching through the stored data, recognizing URLs, etc.), but I don't think that should be a problem. You can always play with the captured keystrokes later once you download them to a PC.

Posted by Tomaž | Categories: Code | Comments »

Cool things

10.10.2005 18:12

I've discovered two incredibly cool wireless-network-related things today:

First, I found out that my old Toshiba Satellite 1410 laptop has a mini-PCI port and integrated antennas that I can use with my dual-band wireless card. I bought this laptop years ago when wireless cards were still prohibitively expensive, so I chose a model without wireless capabilities. Now it turned out that this cheaper model also included everything the more expensive did, short of the actual wireless adapter card.

Second, somebody obviously succeeded in hacking the Nokia D211 binary-only driver to work with Linux 2.6 kernel. Nokia D211 is a multimode radio card that supports 802.11b, GSM, GPRS, and HSCSD. I've tried to use it under Linux several times, but unfortunately the source of the official Nokia driver isn't available and the binary only worked with some 2.4 kernels. Unfortunately, Toshiba Satellite 1410 (my only computer with a PCMCIA interface) is only usable with newer 2.6 kernels, so I've been forced to use Windows if I wanted to use D211. I'm definitely going to try this as soon as I'll find some time to install Debian again on this laptop.

Posted by Tomaž | Categories: Digital | Comments »

Thoughts on data recovery

06.10.2005 11:39

Yesterday I spent five hours moving files from my old 40GB IBM DeathStar hard disk. After 4 years of service in my desktop it developed random bad sectors on the root and home partitions.

I found out that traditional Unix tools I used aren't really convenient for this task. I've read somewhere that the safest way to move a lot of data from one disk to the other is with tar like this:

$ cd /olddir
$ tar -c . | tar -C /newdir -x

This turned out to be a really bad idea. First, tar didn't restore hard links. I used hard links a lot in some hacks a while a ago and the copy of my home directory used far more disk space than the original. Second, tar has a weird idea of when to stop if it encounters a file it can't read. It will kind of continue after the error but won't copy everything it should. It will skip files that are perfectly OK.

The ordinary cp -a turned out to preserve hard links, but had the annoying property to stop at each corrupted file.

In the end the best solution I found was to use mv on each top level directory on the partition. It copied all files, skipped those that could not be read, but didn't delete anything from the source drive.

Posted by Tomaž | Categories: Code | Comments »