A brief analysis of Icesword&rootkit Unhooker Drive

IceSword version: 1.20CN Revision No.: 061022
----------------------------------------------------

0. The process
Slightly

1. Port
The IS call IoBuildDeviceIoControlRequest sends an IRP to the TCP device object and the UDP device object created by Tcpip.sys, which returns the structure array of the Port/ip/state/pid in the output buffer (DS is the same way, Just not associated with the process).

2. Drive
is to enumerate the kernel modules by calling NtQuerySystemInformation (systemmoduleinformation) in the driver section, and here, by the way, in the application section, The IS calls the Enumservicestatusexa function to enumerate all the running modules. Whenever you enumerate a module, find its ImagePath value in the registry, and compare the path to the corresponding module listed in the kernel section, if the path is the same, it is considered to exist, if different or not found, it is hidden module.

3. Registration Form
Registry processing in IceSword is simpler, that is, call Zwopenkey,zwquerykey,zwclose,zwenumeratekey,zwenumeratevaluekey to enumerate. The first dozens of bytes must be recovered before they are invoked.

4. File system
This is part of the focus, is also handled by the more ingenious place, that is, using the so-called raw FSD I/O to enumerate files and directories. In fact, call IoAllocateIrp, and then fill out their own fields (first hair irp_mj_create, then hair Irp_mj_directory_control (irp_mn_query_directory)), and finally "direct" Sent to Ntfs.sys/fastfat.sys's dispatchcreate and Dispatchdirecotrycontrol dispatch routines, but here are two issues to note:

A. Is the SL_RETURN_SINGLE_ENTRY flag is set up in the lower stack when populating the Irp_mj_directory_control IRP, which directly causes FSD to return only one file_both_directory at a time _information structure, not all returns (DS is all returned). Confirm enumeration when IoStatus.Status = = Status_no_more_files is completed.

B. Is there is a way to directly locate the address of the dispatch routines mentioned above (through feature search), the other people did not call IoCallDriver directly, but directly called the past, and will be abnormal constantly restore the dispatch routine of the first dozens of bytes, so you use what FSD dispatch Routine table hook, what FSD hook are all white pull.


Rku version: 3.30.150.400
------------------------------------------------

0. The process
Slightly

1. Drive
"Hidden Drivers Detection
Detection of drivers hidden from Windows API
Combines four different methods of detection and including special Five (c) Stealth Walker technology
and six (c) Kmse-kernel Memory scanning Engine "----Rku

As it says in the help document, the Rku does cost a certain amount of code to drive the enumeration module, which is almost crazy when parsing it, or is it a bar list:
A. Traverse the Type list (pobject_type->typelist) of the Iodriverobjecttype object type, so that you can obtain the object body information of all driver types, also known as the driver_object structure. Then take out: Pdriver_object->deviceobject, and then traverse Deviceobject->attacheddevice, get the corresponding driverobject information, these things usually do not duplicate all put into the output buffer.
B. Traversing the type of Iodeviceobjecttype object type linked list, the idea of ibid.

Of course A and B successful implementation of the enumeration is premised on the NTGLOBALFLAGS variable setting the Maintain Type list flag, otherwise the output buffer has nothing.

C. Call Zwopendirectoryobject to open the directory object to get the handle first, and then call Obreferenceobjectbyhandle to obtain a pointer to the directory object (its structure is object_directory), </