Rootkit (5) anti-rootkit

Now the struggle between rk (rootkit) and ark (Anti-rootkit) has been going on for a long time. In my mind, the earliest Ark tool was icesword ), from the beginning of the ice blade to the present, the struggle between rk and Ark has continued. Currently, the ice blade is still popular, I feel like the ice blade has driven the fight between the popular rk and ark. Now, many virus and Trojan horses are widely driven, some rk technologies and methods are used to make yourself more powerful at the underlying layer. Currently, popular Ark tools mainly include: hidden Process detection, kernel driver detection, ssdt detection, and code hook detection, registry hidden detection, hidden file detection, and other functions. Let's talk about some of the functions below:
Hey.

About Process Detection: in fact, the earliest method to hide processes under R3 has become popular for a long time and various software have been used. In r0, such as breaking the activeprocesslinks chain and erasing the handle table, step-by-step development is gradually becoming more powerful. Some techniques and methods are beginning to emerge and become popular, such as futo and phide_ex ......

The method of checking and testing hidden processes can combine some popular methods. First, you can scan one side by using the process activity linked list activeprocesslinks in the eprocess structure of the process, you can use the handle_table and handletablelis linked list in the handle_table structure of eprocess to scan one side to obtain some eprocesses. You can locate pspcidtable in pslookupprocessbyprocessid code to scan and obtain some eprocesses, pspcidtable enumeration in different systems is not the same, you can also find out
KiWaitInListHead, KiWaitOutListHead, and KiDispatcherReadyListHead are linked lists and then scanned to obtain some eprocesses. The above implementation code can be implemented by GOOGLE online, in addition, you can find the number of SwapContext function switches from the thread in the kernel for HOOK. In the self-implemented SwapContext function, find the EPROCESS structure of the process based on the thread offset, to collect all the eprocesses obtained above, you also need to determine whether the current process is truly alive. You can use Flags (such as XP) in EPROCESS.
0x248) when judging by some signs, you should also note that there will be repeated processes for the above linked list collection, in your own collection function, I think it is enough to implement some of the above methods to deal with general hidden processes, but the great RK is still available, now there are RK that can escape these methods. In the EPROCESS structure of the process, the offset 0x1f8 (under XP SP2) has a struct MMSUPPORT Vm structure:

Struct _ MMSUPPORT
{
/* Off 0x00000000 */union LARGE_INTEGER LastTrimTime;
/* Off 0x00000008 */struct MMSUPPORT_FLAGS Flags;
/* Off 0x0000000C */unsigned long PageFaultCount;
/* Off 0x00000010 */unsigned long PeakWorkingSetSize;
/* Off 0x00000014 */unsigned long WorkingSetSize;
/* Off 0x00000018 */unsigned long MinimumWorkingSetSize;
/* Off 0x0000001C */unsigned long MaximumWorkingSetSize;
/* Off 0x00000020 */struct _ MMWSL * VmWorkingSetList;
/* Off 0x00000024 */struct LIST_ENTRY WorkingSetExpansionLinks;
/* Off 0x0000002C */unsigned long Claim;
/* Off 0x00000030 */unsigned long NextEstimationSlot;
/* Off 0x00000034 */unsigned long NextAgingSlot;
/* Off 0x00000038 */unsigned long EstimatedAvailable;
/* Off 0x0000003C */unsigned long GrowthSinceLastEstimate;
};

In this structure, + 0x24 has a WorkingSetExpansionLinks, which is also a LIST_ENTRY linked list. In this example, he can obtain the EPROCESS of the process, as shown in figure
PEPROCESS eprocess, eprocess2
Eprocess = PsGetCurrentProcess ();
Lp = (PLIST_ENTRY) (* (PVOID) (PUCHAR) eprocess + 0x1f8 + 0x24 + 4 ));
Cur = lp-> Flink;
For (; cur! = Lp; cur = cur-> Flink)
{
Eprocess2 = (PEPROCESS) (ULONG) cur-0x1f8-0x24 );
PVOID session = (PVOID) (* (PULONG) (PCHAR) eprocess2 + 0x170 ));
If (MmIsAddressValid (session )){
AddProcess (eprocess2 );
}
}

In the EPROCESS structure of the process, there is a struct _ LIST_ENTRY SessionProcessLinks structure at the offset 0x0b4 (in XP SP2). It is also a linked list :) You can also obtain some eprocesses through the examples. Another point is that there is a struct _ KAPC_STATEApcState structure in each thread object (ETHREAD) offset 0x34 offset 0x10 in the _ KAPC_STATE structure, in addition, you can use the example memory to find hidden processes. From the memory MmSystemRangeStart to the System process's EPROCESS address, you can determine whether the address is a valid process, there are many methods, such as determining whether the address is a process object. If it is EPROCESS, check whether the PID, ThreadListHead, and ReadyListHead are correct and valid. Many methods should be combined to determine whether they must be in progress.
You can also HOOK some functions such as KeUpdateRunTime and KeDispatchInterrupt to detect hidden processes, you can also set pssetcreateprocesspolicyroutine to insert an APC thread during each process creation for statistical detection. In fact, I think there are still many methods and techniques for detecting hidden processes, we still need to explore the great WINDOWS. To terminate a process, you can call ZwTerminateProcess or call an undisclosed PspTerminateProcess function. This function is already widely used on the Internet and can be called by every thread of the process
PspTerminateThreadByPointer ends each thread. These undisclosed functions need to be searched and located in advance. You can also use RKU (RkUnhooker) to switch to the process and then reset the process memory RtlZeroMemory. In addition, you can insert APC to each thread of the process to end the process, finally, if you have time, you can watch the 2K code to end the process.

For kernel driver detection, You can first enumerate the kernel driver through the SystemModuleInformation function number of ZwQuerySystemInformation. Then, you can open the directory object and enumerate the code to GOOGLE, you can also enumerate the types of IoDriverObjectType and IoDeviceObjectType objects, and enumerate their DeviceObject and AttachedDevice. Then you can find PsLoadedModuleList to enumerate the chain, you can search for "\ Driver" on one side of the directory object ". By enumerating the above methods, you can
I have found many drive objects. I believe you have enough linked lists of drive objects. Hey, tired enough. Next, you can search for the above-found drive object's 0x38 offset MajorFunction to see if its address is within the known drive address range. If you do not know what to do, find the address of each routine in MajorFunction from 0 to 28 and check whether their address is within the known driver address range. Finally, let's talk about another method, you can also enumerate memory like a process, and start to enumerate from MmSystemRangeStart like a process to determine whether there are several key PE features in the PE file, such as MZ and PE, check whether the PE File Header exists,
Check whether the address is the driver address you have detected and avoid duplication. Check whether the MajorFunction [X] and DriverStartIo of all the driver objects you have detected are in this address, if there is an address that has not been detected and is not repeated, it is likely to be an unknown driver. In fact, the key is to judge the address, which is the same as the process memory lookup, you must be right. You must be sure that he is an object and then you can add him to your own linked list. Finally, you can record the esp + 0x24 address in the self-implemented functions of some key function hooks such as ExAllocatePool and ExAllocatePoolWithTag, and then judge these addresses.
To see if these addresses are included in some kernel modules, you also need to determine whether they are PE driver files. This method is used by RKU. Let's talk about the driver.

I 've talked too much about it. I 'd like to talk about it later.

With regard to SSDT hookdetection, we can compare each service function by locating the KeServiceDescriptorTable in the ntoskrnl.exe disk file with the KeServiceDescriptorTable in the memory. There are a lot of code online.

For code hookdetection, I can scan some sections in the ntoskrnl.exe release PE file in the memory, and scan the import and export functions of some key files, in addition, each routine in MajorFunction of some key drivers (such as file system drivers) is scanned, and IDT and GDT are scanned.

For registry hiding detection, we can first use the SSDT hooks of some registry-related functions, INLINE hooks, to restore them and then use the so-called irrelevant functions, for example, badrkdemo HOOK the ObOpenObjectByName function to view the specific access to the registry. Haha, you can also use cmseries functions for some undisclosed functions, in addition, you can analyze the HIVE file to display the items in the registry. It is not very difficult to analyze the HIVE file. I learned about the HIVE file structure and the organization of HIVE files, you can read the information. You can read the HIVE file to display the current registration information.
The items in the table are acceptable, but I do not recommend that you rewrite the HIVE file of the system. For example, if you provide delete modife and other functions, I think the modification is not good or the structure is not completely clear, writing to the HIVE file is incorrect. It is difficult for the system to read the HIVE file when it is started again. I am a bit confused. If you are strong enough, of course, there is no problem.

For the detection of hidden files, there are many popular hidden files, such as Unreal. a, AK922, etc. You can build an IRP package in the driver and send it to the file driver. In addition, you can restore some key functions like the registry, recover the inlinehook ssdt hook, which is used to HOOK the key file driver routines. Currently, the HOOK kernel completion routines are popular. The HOOK is hard to prevent. Pay attention to some filtering drivers attached to the file system, in addition, some special IoControlCode control code is sent to the file system by using DeviceIoControl. This requires familiarity with the file system and self-analysis.
Disk Files are analyzed by file systems in FAT32, NTFS, and other formats to find files. There are also a lot of online information and materials for analyzing disk files by yourself, first, you can determine which file system it belongs to, and then analyze it by yourself based on the specific file system format. In fact, the key to these methods is how to read and write, reading and writing are at the lowest level, and reading and writing are good. I think it is powerful to detect files.

Enough. Some ARK functions are enough. I hope that after reading the functions of RK and ARK, you will make a lot of amazing and powerful things, I hope this will be helpful to you a little later. I hope that we can update more powerful things in the popular RK and ARK to encourage us to learn and move forward, quoting a friend, "now I feel like most Trojans are infected with viruses. What is SSDT HOOK of old things ......, we hope that some new technologies will emerge. "In fact, some RK are very good now. In fact, they all aim to keep improving technology and knowledge.
Hey. A person without a future: Let's talk about the future development of RK and ARK at a lower level, and the development of ARK at a lower level. The fight between RK and ARK will continue, RK will appear in a certain file, it will exist after the system is reinstalled, and will be written to the hardware ......, ARK also needs to pay attention to these issues.