Klimax – A tool for memory and execution profiling at kernel level

Malwares are of various kinds. Privacy breaching malwares are those that attempt to steal confidential data. For eg:- Keyloggers are those malwares that eavesdrop and harvest user issued keystroke. Klimax is a behavior based detection model tailored to detecting privacy-breaching malware containing any form of keylogging activities. It is a kernel level infrastructure for memory and execution profiling. The system supports proactive and reactive detection and can be transparently deployed online on a running Windows platform.  Proactive detection is activated directly by the user. In reactive mode, the behavior analysis is automatically activated on demand whenever a candidate malicious application is recognized at runtime.

The basic idea is to analyze the correlation between the distribution of user-issued keystrokes and the resulting memory writes performed
by the malware to harvest sensitive data. Following this intuition, we inject a carefully chosen keystroke stream and observe the memory write patterns of the analyzed application. High correlation values translate to immediate detection.

Components of Klimax

The main idea is to ascertain the correlation between the stream of issued keystrokes and the memory writes a process exhibits.  In case a high correlation between those is found, the monitored process is flagged as malware with key-logging behavior.

The three components are the monitor, the injector, and the detector, of which only the first two are designed to run in kernel space. The monitor exposes a memory write performance counter to the injector, and is divided into two sub-components, the shadower and the classifier.

Detection Technique

We assume that a process is given to be analyzed for keylogging activity.

The detector instructs the monitor to intercept the memory writes of the target process. The classifier classifies the memory regions of interest. Based on the instructions of the monitor, the shadower intercept memory access. The detector establishes the nature and pattern to be used. After that, it send stream representation to the injector. The injector has now knowledge of the number of keystrokes it has to inject for each time interval. The detection process can now start: for each sample the injector issues the determined number of keystrokes to system, and notifies the monitor that the sample has been injected. The monitor then replies with the memory writes that took place.


Once all the samples are injected, the injector replies to the detector with all the memory write counters.  The detector transforms the write counters into patterns, and it computes their respective correlations against the pattern previously injected. If any of the correlations is statistically significant, the process is flagged as a keystroke-harvesting malware.


Generating a pattern is the major task of the detector. Once the injection is completed, the detector  receives a detailed report of the memory writes the process performed. The report includes a set of write patterns classified per code segment and thread. Each of these patterns is further categorized basing on the written memory regions (data, stack, or heap). The detection process terminates with a correlation test against all the output patterns found. The process is then flagged as malicious when at least one of those shows a value above minimum threshold.


The injector consists of a set of samples that are injected as data similar to streams of keystrokes. It is run in kernel space to keep a limited TCB and high priority injection. Another component called the monitor, which will be discussed later, will keep track of write counters that are retrieved my injector to inject sample code. Once the whole injection is terminated, the output results are transmitted to the detector.


A monitor consists of a shadower as well as a classifier. The shadower implements the memory protection and handles all the memory accesses. Memory access are monitored by manupulating interrupts, like page fault interrupt (0X0E) and debug interrupt (0x01). KLIMAX installs two customized interrupt handlers for both 0x0E and 0x01 interrupts by modifying the processor’s Interrupt Descriptor Table. (IDT) . These two handlers are the only entry points needed to selectively unprotect and protect the accessed memory regions. As soon as we instruct KLIMAX to monitor a process, the shadower asks the classifier which memory regions shall be protected, and hence mon-
itored. The classifier reports back the corresponding set of page table entries (PTEs). The shadower creates a shadow copy of all the PTE’s Owner bit, i.e. it sets their bit to 0. It then flushes the translation look aside buffer (TLB). This is mandatory in order to cope with the TLB caching address linear-to-physical resolutions.

The classifier is invoked in two different courses of action: when the shadower needs to determine whether a PTE shall be protected, and to update the performance counters after a write took place.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s