ttyrpld is a kit to log any traffic and actions which go through any of your Kernel's tty devices. In common-term language, this is a Keylogger (and Screenlogger).

It supports any tty type (vc, bsd/unix98 pts, serial, isdn, etc.). Being implemented within the Kernel makes it incircumventable for the default user. Another benefit is that it runs with no overhead if the user-space logging daemon is not active. (Ok, I lied: two CPU instructions.)

This kit consists of a Kernel patch, a Kernel module, a user-space logging daemon and a [user-space] player.

The Kernel patch adds a few lines to provide the rpldev extension hooks, which (any) module can then get onto. The system was not directly written for black-hats who want to leave as little traces as possible, keep in mind. :-)

You can get a listing of what tty drivers the Kernel has currently loaded by looking at /proc/tty/drivers. Note that the rpldev hooks are placed in the last abstraction layer of the tty code (before it splits out into driver code), so we're really independent.

The Kernel-side module (rpldev) is responsible for grabbing the data off the tty line and providing a character device for the user-space logging daemon. Data grabbed of the tty is directly passed to the overlying daemons, so with the correct terminal settings you can get a 1:1 replay.

Having received the captured data, the logging daemon can store them in any format and/or facility, with or without compression, just as it likes, for this happens in user-space and thus you have all the fluffy libraries available. (That would not be the case from Kernel space.)

... which cause it to differ from existing solutions:

Most other solutions deploy the logging completely in userspace and make it dependent on the user to activate the logging. Definitely, an intruder does not start e.g. /usr/bin/script voluntarily. I have only seen two other kernel-based loggers. One of them is sadly outdated, the other is more complex (i.e. queries keyboard driver instead of tty lines) and only allows network logging, yet aims to be more hidden. To sum it up, there exist only very few solutions to which I could compare.