|Informative Information for the Uninformed
The question of what to do after potentially identifying an executive object through a signature depends on what the underlying goal is. For the purpose of a the sample utility included with this paper, the goal may be to simply display some information about the objects as it finds them.
In the context of a rootkit detector, however, there may be many more steps that need to be taken. For example, consider a detector looking for EPROCESS blocks which have been unlinked from the process linked list or a driver module hidden from the system service API. In order to determine this, some cross-view comparisons of the raw objects detected and the output from an API call or a list enumeration is needed. Detectors must also take into consideration the race condition of an object being created or destroyed in between the memory enumeration and the acquisition of the "known to the system" data.
Additionally, it may be desired that some additional sanity checks be performed on these objects in addition to the signature. Do the object fields x,y,z contain valid pointers? Is field c equal to b? Does this object appear to be valid however has signs of tampering in order to hide it? Does the number of detected objects match up with a global count value such as the one maintained in an OBJECT_TYPE structure? The following sections will briefly mention some random thoughts of what to do with a suspected object of the four types previously mentioned in this paper in Chapter .