This rootkit is heavily based on an existing Linux stack overflow protection product called PaX (http://
pax.grssecurity.net/) and research published by Joanna Rutkowska.
Shadow Walker is a rootkit that hides its presence by creating “fake views” of system memory. The hypothesis behind this technique is that if a rootkit can fool a detection tool by making it thinkit is accurately reading memory, neither the program execution flow (i.e., hook, patch, or detour) nor the data structures in memory (DKOM) need to be altered. Essentially, all the other programs on the system will receive an inaccurate mapping of memory, and only the rootkit will know what truly exists. The authors refer to this technique as memory cloaking and the “fourth generation of rootkit technology”
(http://www.phrack.org/issues.html?issue=63&id=8#article). Typically the goal of memory cloaking is to hide the rootkit’s own code or some other module. We’ll refer to this code as the cloaked code.
This type of deception is achieved by distinguishing executionrequests (which would most likely be initiated by the rootkit itself needing to run its own code) for the cloaked code from read/write requests for the cloaked code (which could be initiated by a rootkit detector). Thus, the goal of Shadow Walker is to “fake” rootkit detectors that are scanning through memory looking for rootkit code, while still allowing the rootkit itself to execute.
As with many of the more advanced rootkit techniques, this technique is based on an architectural oddity of the underlying processor. In this case, Shadow Walker is able to distinguish between memory read/write operations and execution operations by leveraging a synchronization issue with the way the Pentium processor caches page mappings. A page mapping is how the processor maps a virtual address to a physical address.
x86 assembly instructions are made up of instructions(such as INT for issuing an interrupt) and data (the operand(s) accompanying the instruction). To save trips to memory, the processor stores recently used instructions and data in two parallel cache structures (a special type of storage location that’s faster than system RAM) called translation lookaside buffers (i.e., Instruction Translation Lookaside Buffer (ITLB) and Data Translation Lookaside Buffer (DTLB)). This organization of parallel instruction and data caches is called Split TLB.
Whenever the CPU has to execute an instruction data pair, it has to perform significant processing overhead to consult the page table directory for the virtual address and then calculate the physical address in RAM for the given data. This takes time that could be saved if it only had to look in the ITLB for recently used instructions and the DTLB for recently used data (operands). The processor has slight overhead to make sure both caches are synchronized and hold the same mappings of virtual to physical memory.
So how does Shadow Walker use this split TLB architecture to differentiate memory access requests? In short, it forces the instruction cache to be flushed but leaves the data cache alone, so the caches are desynchronized and hold different values for the same virtual to physical mapping for a given page. In this manner, rootkit detectors that are trying to read the cloaked memory page actually get garbage back (or maybe some data that says “no rootkit here!”) because they are reading the data TLB, while the rootkit itself, which is trying to executethe code at the protected memory page, is allowed to do so because it’s reading the instruction TLB.
The logic for what to place in the respective TLBs to achieve these “different views of the same physical page” is inside a custom fault handler. To initiate the fault handler and thus control access to the protected memory pages (i.e., the rootkit code), Shadow Walker flushes the instruction TLB entry of the memory page it wishes to filter access rights to (i.e., hide). This effectively forces any requests to go through the custom page fault.
Shadow Walker is implemented in two kernel drivers: mmhook.sys that does the split TLB trick and a slightly modified msdirectx.sys driver that holds the core of the FU rootkit. The mmhook driver hooks the Interrupt Dispatch Table (IDT) inside NTOSKRNL.
EXE. This installs the custom exception handler (at IDT entry 0x0E) that is crucial to making the technique work. No user-mode controller program is used, so you have to use InstDrv or some other loader program to get the drivers into kernel land (first load msdirectx.sys and then load mmhook.sys). Once they are loaded, the drivers take care of the rest by installing the exception handler in the IDT, so the rootkit is automatically kicked off when a page fault occurs.
You can see the technique working by trying to access the memory address of the msdirectx.sys driver. You should expect to get garbage back—this means the mmhook driver is tainting the view. In order to test this, you need to find the base address of misdirectx.sys using a tool such as DeviceTree. In the screenshot of DeviceTree shown in Figure 4-8, you might notice something very odd about the msdirectx driver: No major function codes or entry points are supported, nor does it have a device attached to it (every other driver does)! Hmm, or does it? Something is definitely up.
Using WinHex (or a similar tool that can read arbitrary physical memory, such as Sysinternals PhysMem), you can verify the memory pages for the FU rootkit are being hidden by mmhook driver by doing an in-memory byte-pattern search for an arbitrary sequence of bytes from the binary file msdirectx.sys. You would attempt this before and after loading the drivers. Before loading mmhook, you should be able to find the signature (and hence the rootkit code) in physical memory; however, after loading the driver, you should not find the code.
Shadow Walker is another example of a proof-of-concept rootkit that demonstrates a technique and does not attempt to hide itself. It also doesn’t support major architecture features such as multiprocessors, PAE, or varying page sizes. Perhaps the most limiting aspect of this rootkit is the restrictive requirements that are imposed on drivers that wish to use this technique to hide themselves. A readme file accompanies the rootkit that explains a “protocol” such drivers must follow, such as manually raising/lowering Interrupt Request Levels (IRQL) for hiding, flushing the TLBs, and other legwork.
However, this rootkit is a very good example of the kind of low-level, advanced rootkit that makes use of very low-level hardware devices.
Figure 4-8 DeviceTree shows us something is amiss with msdirectx.