May 1, 2011 at 14:18Theory of process hiding rootkits (DKOM)
In this article we will try to consider in theory one of the most serious methods of hiding information by rootkits, namely direct manipulation of kernel objects (Direct Kernel Object Manipulation, DKOM ), used to hide processes from the operating system as a whole. If you are a script kiddie , then read "hide processes in Windows!". Let's start from the beginning:
In our case, the rootkit is the kernel module (in the case of Windows , the driver) used to expand the capabilities of managing the operating system (in the end, root and kit). We will not distinguish between an administrator or an attacker. The rootkit runs on the zero ring (the so-called ring0) operating system. In the case of Windows, it requires the correct (not necessarily documented methods) installation on the system, which, as a rule, requires administrator rights. Note that by objects we mean structures in RAM that describe one process in the operating system (I will transfer the blame for the confusion in terms to the documentation from Microsoft). In RAM, information about running processes is stored in a doubly linked list of these same objects.
Closer to the code
Actual for WinXP, on the rest that are older than NT, I think the same way.
And so, we are already in ring0 (how we got here is another story). We are a processor that follows the code of the implemented driver and we got into the function of hiding the process with one argument - pid using DKOM. To get on the legendary doubly linked list of processes, we need to find at least one element from this list. Search by brute force is not rational, especially when we can find a pointer to our own process. Let's see how we will do it. In the course of the code, we encounter the function PsGetCurrentProcces. Fortunately, we are a processor and we know that this is nothing more than In the fs register at offset 0x124 nothing more than an ETHREAD structure
current thread, in which at offset 0x44 lies a pointer to the structure of the process-owner of this thread. Thus we get a pointer to our process. The rest is simple. Each structure has a pointer to the previous and next process in the process chain. We follow the pointers to the process with the necessary pid. When performing trivial manipulations on pointers that exclude a process from a doubly linked list, it makes the OS forget about the existence of the process (at least while it looks with its ordinary methods). Ares for the hidden process can be remembered, in case we want to return it to operation.
Anticipating the question, I answer: a hidden process continues to function normally because the OS allocates processor time not to processes but to threads.
Conclusions
In principle, the detection of this fraud is not an impossible task. Nevertheless, most of the antiviruses come in peace both when contemplating the driver itself and during its execution.
This is not the only method for hiding processes with rootkits. But DKOM stands out among them as one of the most inconspicuous (probably not for long), as it works directly on the processed data, and not on the means of processing it. Also note that DKOM is relevant not only for processes.
PS
Everything is pretty abstracted in order to convey information to the widest possible range. It would not be pleasant for everyone to load technical details, but for those who are interested, they will be easily google.
For a long time I thought about which blog to include, I chose between system programming and this. But the topic of programming is hardly disclosed here, so I chose this one as information on how it happens ...
If it is interesting, I’ll talk about other popular methods.
In our case, the rootkit is the kernel module (in the case of Windows , the driver) used to expand the capabilities of managing the operating system (in the end, root and kit). We will not distinguish between an administrator or an attacker. The rootkit runs on the zero ring (the so-called ring0) operating system. In the case of Windows, it requires the correct (not necessarily documented methods) installation on the system, which, as a rule, requires administrator rights. Note that by objects we mean structures in RAM that describe one process in the operating system (I will transfer the blame for the confusion in terms to the documentation from Microsoft). In RAM, information about running processes is stored in a doubly linked list of these same objects.
Closer to the code
Actual for WinXP, on the rest that are older than NT, I think the same way.
And so, we are already in ring0 (how we got here is another story). We are a processor that follows the code of the implemented driver and we got into the function of hiding the process with one argument - pid using DKOM. To get on the legendary doubly linked list of processes, we need to find at least one element from this list. Search by brute force is not rational, especially when we can find a pointer to our own process. Let's see how we will do it. In the course of the code, we encounter the function PsGetCurrentProcces. Fortunately, we are a processor and we know that this is nothing more than In the fs register at offset 0x124 nothing more than an ETHREAD structure
mov eax, fs:0x00000124
mov eax, [eax + 0x44]
retcurrent thread, in which at offset 0x44 lies a pointer to the structure of the process-owner of this thread. Thus we get a pointer to our process. The rest is simple. Each structure has a pointer to the previous and next process in the process chain. We follow the pointers to the process with the necessary pid. When performing trivial manipulations on pointers that exclude a process from a doubly linked list, it makes the OS forget about the existence of the process (at least while it looks with its ordinary methods). Ares for the hidden process can be remembered, in case we want to return it to operation.
Anticipating the question, I answer: a hidden process continues to function normally because the OS allocates processor time not to processes but to threads.
Conclusions
In principle, the detection of this fraud is not an impossible task. Nevertheless, most of the antiviruses come in peace both when contemplating the driver itself and during its execution.
This is not the only method for hiding processes with rootkits. But DKOM stands out among them as one of the most inconspicuous (probably not for long), as it works directly on the processed data, and not on the means of processing it. Also note that DKOM is relevant not only for processes.
PS
Everything is pretty abstracted in order to convey information to the widest possible range. It would not be pleasant for everyone to load technical details, but for those who are interested, they will be easily google.
For a long time I thought about which blog to include, I chose between system programming and this. But the topic of programming is hardly disclosed here, so I chose this one as information on how it happens ...
If it is interesting, I’ll talk about other popular methods.