From Bauman National Library
This page was last modified on 18 June 2016, at 15:04.

Rootkit is a set of software tools (eg, executable files, scripts, configuration files), for masking objects (processes, files, directories, drivers), management (events occurring in the system), data acquisition (system parameters). In Windows, the term "rootkit" is considered to be a program that is being implemented in the system and intercepts system functions, replaces or system libraries. Interception and modifying low-level API functions primarily allows a program qualitatively enough to mask its presence in the system, protecting it from the user detection and anti-virus software.

In addition, many "rootkits" can mask the presence of any of the system described in its configuration processes, files and folders on the disc in registry keys. Many rootkits install in their own drivers and services (of course they are also "invisible").

Classification rootkits

Conventionally, all of the rootkit technology can be divided into two categories:

  • Rootkits running in user mode (user-mode)
  • Rootkits running in kernel mode (kernel-mode)

The first category is based on the interception of functions the user mode libraries, the second - on the driver installation in the system kernel level to intercept functions. Also, rootkits can be classified according to the principle of action and persistence of existence. By the principle of action:

  • Change the algorithm perform system functions
  • Modify system data structures

In recent years, the threat RootKit is becoming increasingly important, because the developers of viruses, Trojans and spyware are beginning to embed RootKit-technology into their malware. One classic example is the Trojan Trojan-Spy.Win32.Qukart, which masks its presence in the system using RootKit-technology (the program is interesting because it RootKit-mechanism works fine in Windows 95 \ 98 \ the ME \ 2000 \ XP). To effectively combat RootKit requires an understanding of the principles and mechanisms for its operation. Conventionally, all RootKit-technology can be divided into two categories - operating:

  1. In user mode (user-mode)
  2. Kernel mode (kernel-mode).

The first category is based on the RootKit interception functions the user mode libraries, the second - on the driver installation in the system kernel level to intercept functions.

Methods of interception API functions in user mode (user mode)

Interception functions allows RootKit modify the results of their work - for example, intercepting the file search function on the drive allows to exclude from the search results masked files, and interception functions ntdll.ZwQuerySystemInformation type mask allows running processes and loaded libraries.

Principle call API functions

Before considering the principles of user-mode RootKit is necessary to briefly review the principle and simplified calling features, housed in DLL. We know two basic ways:

Early binding (statically imported functions)

This method is based on what is known to the compiler program list of imported functions. Based on this information, the compiler generates the so-called import table EXE file. import table - a special structure (its location and size are described in the header of EXE file), which contains a list of libraries used by the program and the list of imported functions from each library. For each function in the table there is a field for storing the address, but at compile time address is not known. In the process of loading EXE file, the system analyzes the import table, all loads listed in the DLL and it makes entry in the table import addresses real functions of these DLL. In early binding, there is a significant plus - at the time of starting the program all necessary DLL are loaded, the import table is full - and all this is done by the system, without the participation of the program. But the absence of the boot process specified in its DLL import table (or the absence of the desired function in the DLL) will lead to an error loading the program. In addition, very often there is no need to download all application DLL program at the time of starting the program. The figure shows a process of early binding - at boot time filling takes place addresses in the import table (step 1), at the time of the function call from the import function address table is taken (step 2), and there is actually a function call (step 3);


Late Binding

It differs from early binding in order that the DLL load is done dynamically using the API LoadLibrary function. This feature is in kernel32.dll, so if you do not resort to hacking techniques, you have to download kernel32.dll statically. If LoadLibrary assistance program can load its interesting library at any time. Accordingly, to obtain the address of a function applied kernel32.dll GetProcAddress function. Figure 4 corresponds to step loading of the library using LoadLibrary and definition addresses using GetProcAddress. Then you can call DLL functions (step 5), but of course at the same time the import table is not needed. In order not to cause GetProcAddress before each function call from DLL once the programmer can define the addresses of interest to its functions and store them in an array, or some of the variables. Regardless of the binding method, the system needs to know which functions are exported DLL. To this end, each DLL has export table - a table that lists the exported DLL functions, their numbers (ordinals) and relative functions of address (RVA).

Modification of native code application


In this case, the modified machine code corresponding to the application program for a particular call API functions. This technique is difficult to implement, since there are many programming languages, compilers, and the programmer can implement the API calls different methods. But this is possible in theory, provided that the introduction will go to a predetermined program known version. In this case, it is possible to analyze the machine code and develop the interceptor.

Modification of the import table


This technique is described in the book of Richter and is one of the classic. Method The idea is simple - RootKit is in memory import spreadsheet program and corrects addresses of interest of its functions to the addresses of their interceptors (of course, he previously somewhere in their stores the correct address). At the time of calling the API function program reads its address from the import table and passes this address management. The technique is universal, but it has a significant drawback (and it can be clearly seen in the diagram) - intercepted only statically imported functions. But there is a plus - the technique is very simple to implement, and there are many examples that demonstrate its implementation. Search import table in memory is not particularly difficult, as there are specialized for this API function, allowing to work with the image of the program in memory.

Interception LoadLibrary function and the GetProcAddress

Rootkit4.png </ center>

Interception LoadLibrary and GetProcAddress functions can be performed by any method used in the classical implementation of the method 2 - modification of the import table. methodology idea is simple - if the GetProcAddress to intercept, at the request address, you can give out the program does not address the real interest of its functions, and the addresses of their interceptors. As in method 2 program "did not feel" the difference. When you call the GetProcAddress it receives an address and performs a function call. In this method there is a minus - it does not allow intercept statically imported functions.

Method, a technique combining 2 and 3

<Center> Rootkit5.png

This procedure is modified import table, with mandatory intercepted by the LoadLibrary and GetProcAddress kernel32.dll library. In this case, when you call a statically imported functions garbled addresses are taken from the import table for dynamic determination of the address is called the intercepted the GetProcAddress function, which returns the address of functions interceptors. As a result, the program is not likely to know the correct address of the function.

Modification code API functions


These methods are more difficult to implement than substitution addresses. The technique consists in the fact that the RootKit is in memory of his interest to native code API function and modify it. With this method of interception function is no longer necessary to import the table modification of running programs and transfer programs distorted addresses when calling GetProcAddress. From the point of view of the function call, everything remains "as is" with one exception - now on the "correct" address inside a DLL is native code RootKit "correct". The most common intervention in the machine code of intercepted functions minimal. At the beginning of the function located no more than 2-3 machine instructions transfers control to the main function of the interceptor. To make a call, the modified functions RootKit should keep the original machine code for each modified its function (of course, there remains not all native code functions and modified at interception bytes). [1]

Modification DLL libraries disk

This technique consists in the fact that the system library is modified on the disk. Modification techniques similar to those described above, but no changes are made in memory and on disk. This technique is not widespread.

Interception functions in kernel mode (kernel mode)

For an understanding of the typical techniques to intercept functions in kernel mode should consider the principles of interaction of the user mode libraries and kernel. Consider this interaction in the simplified scheme:


The main interaction with the nucleus is made through ntdll.dll, most of the functions which are adapters accessing the kernel through an interrupt INT 2Eh (it should be noted that the application, nothing prevents INT 2Eh called directly). A further appeal to core functions based on a structure called KeServiceDescriptorTable (abbreviated SDT), located in the ntoskrnl.exe. SDT - is a table containing the NT kernel service entry point addresses. Functions and interception techniques can be found in the book Sven Schreiber's "Undocumented in Windows 2000", there is shown a diagram of interaction that served as a prototype for the circuit given here. Simplistically we can say that for the interception want to write a driver that will produce a modification of SDT table. Before modifying the driver needs to keep the addresses of intercepted functions and record to the table SDT addresses of their handlers. This method is somewhat similar to the interception of interrupts in MSDOS or 2 methodology described above. This method is often referred to as interception Native API and of course it only works in the NT (and consequently W2K, XP, W2003). It should be noted that the interception of Native API is carried out not only rootkits - there are many useful programs intercepting function by editing the SDT - as an example can serve as a popular RegMon utility from SysInternals or Process Guard program. It should be noted that the described method is the simplest, but not the only one. There are a number of ways, such as creating filter driver. Driver-filter can be used both for solving monitoring tasks (the classic example - FileMon utility from SysInternals), and for active intervention in the operation of the system. In particular, the filter driver may be used to mask the files and folders on the disc. The principle of operation of the driver based on the manipulation of the bags IO request (IRP).

Methods RootKit detection system

The basic search techniques RootKit:

  1. Comparison of two "snapshots" of the system (eg, a list of files on the disc). The first picture is on the tested system, the second - after booting from CD or HDD to connect the test known clean computer. This technique allows to detect any guaranteed RootKit, which disguises its files on the disk.
  2. Compare the data returned by the API functions of the different levels and (or) received low-level methods (eg, direct-drive reading and analysis of the registry files). This method does not require rebooting the PC and the test is implemented in RootkitRevealer free utility from SysInternals ( Another example happened KLister ( utility to build a list of running processes, which consists of a driver and a command line program that uses this driver;
  3. Analysis of the main functions of memory libraries for the presence of changes in their machine code. This method is most effective for combating RootKit in user mode. This technique makes it possible not only to detect the interception of functions, but also to restore the normal operation of the damaged functions. In addition, a comparison of "snapshots" of the system, before and after recovery of API functions, in many cases, can detect masquerading processes, services and drivers. This technique does not require a reboot, and one of the options implemented in my utility AVZ;
  4. Analysis and ServiceDescriptorTable recovery. This technique allows to deal with a number of interceptors, working in the kernel mode (in fact, with interceptors based on SDT editing). Practical implementation - SDTRestore utility ( However, recovery of SDT will have an impact on the entire system and can lead to very unpleasant consequences (in the simplest case - a complete system hang with access to a BSoD, at worst - unpredictable malfunction applications intercepting NativeAPI for the implementation of its functions).


Anti-rootkit (AntiRootkit) - This is a utility or a resident modules that detect in the presence of rootkits and system (in varying degrees) to remove them. There are many competing funds for this purpose - both paid and free, but they all use similar principles of operation.


Cite error: Invalid <references> tag; parameter "group" is allowed only.

Use <references />, or <references group="..." />


  • It is this intercept technique is implemented in widely known HackerDefender and AFX Rootkit library -