The PS/2 keyboard protocol
If you were to cut a PS/2 keyboard cable through, you would probably find 6 wires within. Only 4 of these are meaningful. Two of these are power lines: ground (GND) and +5 volts (VCC) from the computer power supply. The other two wires are asynchronous transmission lines: the data line (DATA) and the clock line (CLK). You can see how these lines correspond to DIN (a) and miniDIN (b) connector pins on the figure to the right. Transmission is bi-directional, however the keyboard is superior. The keyboard sends information about keys which have been pressed and released. The data chunk consists of only one byte, preceded with a starting bit, and followed by a parity and stop bit. The keyboard puts successive bits on the DATA line, and clocks them with negative impulses on the CLK line. Clock frequency is 10...30 kHz. This would be a very nice serial protocol if it wasn't for the computer, which occasionally wants to send information to the keyboard. In such cases, the PC pulls the CLK line low for some time and waits for the keyboard to start generating impulses. When these impulses start, it clocks it's own character in on the DATA line. You can see state diagrams of keyboard to host (a) and host to keyboard (b) transmission on the figure below. This protocol has of course a few exceptions, like interrupting a transmission, character repeat etc. However, these are very rare cases.
So what is actually transmitted through the keyboard lines? On startup both the keyboard and the computer send initialization data, informing that they are OK. When the computer is running normally, only the keyboard sends data. This is data about every event that took place. An event is considered a key being pressed or released. If a standard key is pressed, it's so called "scancode" is sent. Every key has exactly one scancode, creating a map of scancodes
. If a key is released, first the special byte 240 (F0 hex) is sent , then the keys scancode is sent. So a standard keystroke causes 3 characters to be sent down the line. If a key is held down for some time, it's scancode will be generated constantly with the set repetition delay. When it's finally released, the 240 (F0 hex) character will be sent, followed by the scancode.
This would still be a nice protocol if it wasn't for some special keys present on the standard PC keyboard, like Home, End, the arrows, etc. When a special key is pressed, the byte 224 (E0 hex) is generated, followed by the scancode. When a special key is released, the sequence 224, 240 is fired (E0, F0), followed by the scancode. Normal and special keys are common for all national keyboard layouts with regard to the map of scancodes
. To make to story a bit more complicated, two super-special keys exist, Print Screen and Pause, which cause a whole sequence of scancodes to be transmitted. For a keyboard interfacer, it's best to pretend these keys do not exist.
The microcontroller monitors the DATA and CLK lines all the time, acquiring all data. Data is logged to non-volatile EEPROM memory as it goes down the line. Thanks to this, the user can later find out about every event on the keyboard.
When the user decides recording is over and presses the button, the hardware keylogger switches to playback mode. The keyboard should be disconnected, otherwise it will interpret the data flow. The keylogger starts simulating key data from internal hardware memory. The KeyGrab
application has to be active, to process the flow of data from the keylogger hardware. Normal keys are simulated as they were written in memory, and special keys are transmitted using a two-byte hex code.