[Vol-dev] Simplifying address translation

Hi everybody, We might be able to simplify the virtual to physical address translation in the Volatility framework. While it's not always wise to mess with something that works already, making this code clearer would help people trying to learn the framework and about memory forensics in general. The code in question is all in forensics/x86.py. I've attached a drop-in replacement for forensics/x86.py to illustrate the kind of changes I'm proposing [1]. Right now it only works for non-PAE system (e.g. xp-laptop-2005-*). If you like this I can expand it work on PAE systems as well. I was reading the Intel Architectures Software Developer's Manual [2] and took particular note of how they described the lookups for PDEs and PTEs. Using PDEs, for example, Volatility uses the value in CR3 as a base address and add to it an index number multiplied by a size value. The index comes from shifting bits around in the original virtual address. It looks like this: address = [Cr3] + (([vaddr] >> shift) & ((ptrs - 1)) * pointer_size) This calculation is broken into two functions and uses three magic values. The Intel manual takes a different approach. To them the PDE offset just a series of bits grabbed from various sources. In their words: <snip> A PDE is selected using the physical address defined as follows: — Bits 39:32 are all 0. — Bits 31:12 are from CR3. — Bits 11:2 are bits 31:22 of the linear address. — Bits 1:0 are 0. </snip> In other words: address = ([Cr3] & mask) & ([vaddr] & mask >> shift) In Volatility it would look like: pgd_addr = (self.pgd_vaddr & 0xfffff000) | ((vaddr & 0xffc00000) >> 20) I've even included a helper function, bitmask(), that computes bitmasks on the fly. Avoid it might take slightly longer to execute, it would hopefully avoid coding errors. pgd_addr = (self.pgd_vaddr & bitmask(12,31)) | ((vaddr & bitmask(22,31)) >> 20) What do you think? [1] Warning! This code *only* works on non-PAE systems for now. It also contains some code to make Volatility work on big endian machines. [2] http://www.intel.com/products/processor/manuals/index.htm -- Jesse research(a)jessekornblum.com