Avian’s Blog

I'm currently trying to repair two Sinclair ZX Spectrums from Cyberpipe's computer museum.

I was told this one was connected to a wrong type of a power supply. After a quick look inside I kind of agree with that. It looks like a small explosion happened in the voltage regulator.

Nothing else on the board appears to be obviously damaged. With some luck replacing the regulator will bring this machine back to life.

I'm currently experimenting with this CMOS image sensor array made by ST Microelectronics. Raw image data is read from it through a 10 bit parallel bus while various settings (like exposure time, etc.) can be adjusted through a standard I²C bus.

These chips are quite hard to come by in shops with electronic components, but are common in (very) cheap web cams and digital cameras (the chip on the picture is from Aiptek Pencam Trio).

The image quality isn't impressive. The sensor has 640x480 pixels and poor light sensitivity characteristic for CMOS sensors.

I've finally finished my keylogger project yesterday.

Actually I finished writing the firmware sometime in December, but it took me a month to find and fix all bugs. Still it doesn't work with all computers and keyboards out there. Old Compaqs are especially problematic and I haven't been able to figure out why they simply refuse to work when the keylogger is connected. Also some keyboards seem to use a different scan code set, since the keylogger will work fine with them in transparent mode but it won't recognize the access password (which is internally stored as a sequence of scan codes).

The final keylogger firmware consists of 1758 lines of C code and uses 4080 bytes of code memory (which leaves exactly 16 bytes of FlashROM free).

I've also made a screencast (Ogg Theora) of the keylogger in use.

Finished circuit board front:

and back:

I also found out that overtone 24MHz quartz crystals don't work here since they tend to oscillate at their fundamental frequency instead of their 3rd overtone. When I used an overtone quartz the keylogger stopped working because the microcontroller ran at 1/3 of the correct clock frequency.

Almost finished with PCB design. Here's a nice composite picture of my current draft.

Schematic editing and capture done with XCircuit, board design with PCB and pretty picture with GIMP.

Success!

The software part of the keylogger is now almost finished. The only part that is missing is the serial EEPROM driver for which I need to make a new prototype board that has the actual EEPROM chip on it. I can't add it to the current board because the EEPROM is in a SMD package that can't be soldered to the breadboard.

It took me two days to debug the software for the transparent logging mode, but now it is working without problems. As far as I can tell it isn't detectable from software. The Linux kernel will still report that an ordinary AT keyboard is attached to it and the LEDs on the keyboard work as usual.

A simple menu is accessible by entering a correct (configurable) sequence of 8 keystrokes. Alphanumeric keys and also modifier keys like ALT and CONTROL can be used in this password, because the key logger saves it as sequence of raw scan codes. Of course all sorts of weird things happen if you activate the menu when some application other than a simple text editor has the keyboard focus. Because the keylogger has no way of getting feedback from the computer it will blindly type the menu text for example in a Firefox window which will then interpret the keystrokes as keyboard shortcuts and you will end with a messed up browser.

The bad news is that all this fancy code takes around 1800 bytes of code memory. This leaves only 200 bytes for the EEPROM driver and playback code, which most likely won't be enough. I guess it's time to look for a bigger 8051 compatible microcontroller. AT89C4051 looks promising since it's pin and code compatible with AT89C2051 I'm using now. I just hope I can get it in Slovenia for a reasonable price.

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.

Unfortunately not :)

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.

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.

Board design in pcb:

Final result:

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.

After all complications with the payment (6 GBP got lost in the international money transfer, go figure) I've received the mini-PCI to PCI adapter I've ordered. Now I'll finally be able to have some fun with the Atheros-based wireless card I've got at What The Hack from the friendly Meshnode people.

This chipset includes a dual-band (2.4GHz and 5GHz) diversity transceiver, supports IEEE 802.11 a/b/g standards, can operate in AP, ad-hoc and monitor modes and, best of all, has free software drivers for Linux and FreeBSD available.

The only problem is that the antenna connectors are of the U.FL type and it is almost impossible to find a coax cable with that connector already attached. I've only bought one adapter from U.FL to RP-SMA at What The Hack because I didn't notice the second antenna connector for the diversity mode.

The sad thing is that I paid 5€ for it at WTH and if I would order it now from Farnell it would cost me some 25€ plus postage.

I think I'll wait until 22C3 and see if I can get another adapter there.

I'm seriously considering making me one of these. I've seen these displays at 21C3 and What The Hack and they look great.

Full circuit schematic is available and 144 LEDs really don't cost that much.