Functional Specification (part 3)

Section 5:                                System Architecture

5.1 Simple Use-Case

  1. Attacker gains unauthorized root access to victim host machine.

  2. Installs rootkit and removes evidence of attack.

  3. Administrator or owner of victim host continues activity on machine as normal. Assuming they haven’t detected the attack or found the rootkit. They carry out their regular usage (Example: Distributing Illegal movies).

  4. After a week of collecting evidence, our attacker sends a crafted packet to the victim machine. In response of this crafted packet being detected, a remote shell is returned to the attacker. Victim owner is still left unaware.

  5. Attacker retrieves all the evidence collected and either uninstalls the rootkit, or furthers the attack, based on the data they received. Victim is still clueless.

Below you will find some context diagrams based on this use case.

Step 1:


Step 2:


Step 3:


Step 4:


Step 5:


Section 5:                                System Architecture

5.2 Rootkit and OS Architecture

The Rootkit and Operating system have an interesting architectural layout when combined. I feel this is important to include in the functional specification as it demonstrates how our Rootkit module and Operating system entities interact with each other from an easy to understand higher level view. This interaction is critical to the project and without it, the method of implementing a rootkit I am investigating would not be possible. I will be developing this rootkit on a 32bit linux kernel architecture of the 2.6* variety. I will also investigate how I could possibly extend this to other newer kernels.

In the first diagram below you will see how the operating system separates our user space from the kernel space. This diagram outlines the regular functionality of how our operating system eventually progresses to making system calls from a process. This initial high-level view will be investigated to a much greater extent in future documentation. Our process needs to call the write system call. Through an interface this request is handled, the location of the write function is found in the system call table and we can see that write is then executed.


In the following diagram you will notice you can see our loadable kernel module (the rootkit). Hopefully it should be clear that the kernel module needs to first store the original address of the write system call, then it needs to overwrite the address with an evil function. This evil function would then pass the value it received to the regular system call after carrying out it’s evil task. Basically the rootkit allows us to intercept any system call.


This sequence is a fundamental concept in understanding how a LKM rootkit works. We can see from this example that it is possible to intercept the write system call. The same is true for any of the other system calls. There are a few issues such as the system call table not being writeable and other such protections put in place to mitigate rootkits. Methods to bypass these restrictions do exist and will  be demoed at a later stage.

Section 5:                                System Architecture

5.3 Systemtap Architecture

Systemtap has a very interesting architecture. It translates the systemtap language into raw kernel level C code and then into a compiled kernel object (.ko). It also has the ability to insert raw C code directly into the kernel using its “Guru-mode”. All of this takes place on-the-fly or during runtime. This is possible thanks to the kprobe debugging interface.


Above we can see the architectural layout of the kprobe interface. Most of the work is done in the architecture dependant layer. Each different architecture has it’s own debug symbols and must be dealt with individually. We place a pre-handler kprobe before the position we want to debug, then one straight after. The pre-handler executes, then the probed instruction, then the post-handler. These handlers carry out functions in our higher layers.

The architecture independent layer in the middle is our kprobe manager, this manages the registering and unregistering of kprobes. The user can then provide handlers for the kprobes within their kernel module. They use the middle layer to register these handlers.

Systemtap provides a Higher layer above this again. It translates it’s own language and libraries into kprobe compliant code to carry out many different functions within the kernel.

Section 6:                                High-Level Design

6.1 Data Flow Diagram: kprobe execution


6.2 Data Flow Diagram: Systemtap flow


Section 7:                                Schedule

7.1 Simple Schedule

The schedule for this project can be found here


Section 8:                                    Appendices

Below you will find a collection of Links relating to my project & research areas. It is possible more will be included in later documentation or added to my blog posts as I need them. This should not be considered the full list of appendices. I will also properly reference these articles/books in later documentation.


I will keep them in the format:

LINK    :    Brief description    :

The Systemtap language reference

The Linux Kernel Programming book            :

An E-zine containing many useful techniques for many of the areas I’ll be investigating.        :

Many relevant techniques (Author wrote some related phrack articles)            :     Some useful information

“Systemtap: Instrumenting the Linux Kernel for analysing performance and functional problems”. A very useful guide full of tips for using Systemtap.                :

The Linux Programming Interface. This has a lot of detailed information about how the linux kernel works.    :

Additional help with C programming.