[Raheel]

I want to ask when we remove reference to our process using DKOM, then process is hidden as there is no reference but how can the process be executed when there is no reference to that and why processor does not reclaim memory as pointer to that part is removed?

[Vrtule]

Hello,

if you only remove the process from the list of active processes (the list is called PspActiveProcessLinks IIRC), you are not doing enough. The scheduler is mainly based on threads, not processes (there is a list of ready thredas, wainting threads, a list of standby threads and possible some more; I have never studied scheduler internals in Windows 8 and newer versions of the OS).

The list of active processes is traversed only in several cases since it is not a cheap operation in terms of complexity (O (n) ). The kernel stores an extra reference to a process object in places where a direct (and quick) access is desirable.

The old FU rootkit is known for hiding processes by removing them from the active process list. I experimented with this in the past and it seemed to me that there is no noticeable impact, in terms of hidden process' execution.

If you employ some other tricks to hide the process, put them here and we will see.

Vrtule

[Raheel]

You have said that

The kernel stores an extra reference to a process object in places where a direct (and quick) access is desirable.

Do you have any idea where those references are stored? Any help will be grateful. Thanks.

[Vrtule]

Well, AFAIR list of waiting/standby and possibly ready threads scheduled on certain processor are stored in its Processor Control Block. But this information is probably very dependent on OS version.

For processes, an extra reference is present for example in their handle table structures. Additionally, each open handle to a process also keeps a reference to it (the reference is stored within the structure representing the handle in process' handle table). And there will be many more places I expect.

The problem with removing these extra process references is that the process being hid, and/or the operating system itself, begins to malfunction when you attempt to remove them. The level of malfunctioning depends on which references you remove. For example, the FU rootkit removes the target process only from the list of active processes which is a "reference" used quite rarely (and not in critical circumstances), so the process and the system works quite nicely. The FUTO rootkit also unlinks a handle table of the target process from the handle table list. From that moment, the target process does not work as nicely as before – AFAIR it is unable to create child processes (it is terminated at that point).

Also, you can look at the old phide2 rootkit. IIRC it hides the target process' threads also from the thread scheduler. This bypasses some antirootkit techniques (like hooking of the SwapContext internal routine responsible for context switches). On the other hand, the hidden threads are never scheduled on any processor. Phide2 solves this problem by stealing some code from the scheduler and executing it in certain moments.

To sum up, you should be very careful when trying to hide a process, a thread or something else. You should look at some old rootkit samples, such as FU, FUTO, phide2 and possibly some more (phide_ex, if you have enough courage and time to reverse engineer it). You should also examine various operating system structures to determine where references to processes and threads are stored. Also remember, that the linked list is not the only data structure in the world. There are also hash tables (handle tables), (AVL) trees and some other.

[Raheel]

Thanx alot for such an information. Just one more question... Can we bypass thread scheduler to run my thread after some time? If yes then can you give me any link regarding that.

[Vrtule]

AFAIK, phide2 does what you want (but probably for XP only). Look at its source code (should be in this topic - http://www.kernelmode.info/forum/viewto ... ide2#p4354).