this is for holding javascript data
Igor.Korkin deleted file 4.2. Analysis of Current Approaches to Rootkit Detection in Face of Oppositions.tex
over 9 years ago
Commit id: cefafd9ea8d1e7c428252e54132ec8d2d5dc0a47
deletions | additions
diff --git a/4.2. Analysis of Current Approaches to Rootkit Detection in Face of Oppositions.tex b/4.2. Analysis of Current Approaches to Rootkit Detection in Face of Oppositions.tex
deleted file mode 100644
index b9aa2a6..0000000
--- a/4.2. Analysis of Current Approaches to Rootkit Detection in Face of Oppositions.tex
+++ /dev/null
...
\subsection{Analysis of Current Approaches to Rootkit Detection in Face of Oppositions}
One of the most popular ways to detect rootkits at runtime is known as cross-view detection, which relies on the fact that there are several ways to collect the same information about OS objects. Cross-view detection typically utilizes both high-level and low-level mechanisms to collect information [78]. The high-level mechanism is based on standard system functions to enumerate OS objects.
The low-level mechanisms are based on data from some heuristic analyzers, additional object structure lists, signature scans and other heuristic [80].
We will analyze existing approaches according to a number of criteria, such as resilience to common rootkit tricks, portability to new versions of Windows and others.
Heuristic analyzer tracks programs activity, analyzes the collected data and blocks the program if its behavior is similar to a malicious one. The main disadvantage of this approach is that it blocks the program only after a certain amount of its activity has been collected during tracking. Another disadvantage is its vulnerability to rootkit countermeasures. Also heuristic analyzer must be started before malware, which is not always possible [81].
Information about running objects is often duplicated in different systems’ lists. It is possible to use this data for objects detection. Is this case hidden object detection is based on data comparison obtained from various lists. This method was implemented in Tuluka Kernel Inspector, TDSS killer by Kaspersky lab and others. To hijack this detection the malware is able to modify all the needed lists to hide its own presence. As a result malware activity will not be detected.
Signature scan is based on the fact that values of some fields are either known or exceed the constant, for example 0x8000_0000. This method uses byte to byte search of fragments of objects structures in memory. This method has been implemented in GMER, PowerTool, XueTr and others. It is important to point out that structure sizes and their content change in new Windows versions (after some updates, service packs) as for EPROCESS structure. To deal with that, this method needs adaptation, which is often difficult because it requires manual adjustments.
It is possible to prevent hidden object detection by signature scan. To achieve this malware may modify some structure values, which are used by signature scan [73]. These modifications cannot crash the system or stop malware activity but make signature scan useless. One reason for this is that the decision is based only on the signature coincidence for the whole structure. If at least one byte does not match, the signature scan will miss the structure.
A similar method to prevent hidden object detection was proposed by T.Haruyama, H.Suzuki in ‘One-byte Modification for Breaking Memory Forensic Analysis’ article [82]. The prevention is based on modification of systems’ structures values, which caused the situation when the detection tools were disabled.
Let us analyze the mentioned approaches with regard to processes structures (EPROCESS) and drivers structures (DRIVER_OBJECT) because they are often used in malware attacks.
