Posts

Showing posts from March, 2009

Using Volatility for Introspection

This post could also be titled " Teaser ", part 2 :) As part of my research at GT, I've been looking at using Volatility to examine the state of running virtual machines. Using PyXa, a wrapper around Bryan Payne's XenAccess library (available in the tools directory of the latest XenAccess release), you can get access to the memory of Xen guest VMs in Python. From there, it's just a small step to create a new address space that Volatility can use to examine virtual machines just as if they were any other memory image. One application of this is using introspection to find out the state of windows on screen. This has advanced significantly since the last time I mentioned it, and it's now possible to track windows, including their z-order and some on-screen text, in near-real time. To demo this I used Volatility to examine the internal data structures of Win32k.sys and extract the locations and sizes of all visible windows, and then used PyGame to draw them

Quick Response to Guidance

Everyone's been (rightfully) beating up on Guidance for their recent FUD-laden e-mail about F-Response; you should check out the excellent rebuttals by Harlan Carvey and hogfly . I'm not going to address most of the e-mail, but I thought I should tackle some things that are simply factually wrong about Volatility. I'm hardly an unbiased party (being a developer on Volatility), but unlike Guidance, I'm going to provide verifiable information to back up my claims. From the Guidance mail: While these utilities [included in the Volatility Framework] can identify running processes, open files and registry handles for running processes and open network sockets and connections, they cannot identify hidden processes, injected DLLs and NIC information. There are three factual inaccuracies in this statement: Volatility cannot identify hidden processes. In fact, Volatility can list processes using multiple methods. The pslist module walks the list of active processess, and will f

Updates and a New Home for Plugins

As I've now released a number of plugins for Volatility, and some have gone through a couple revisions, I thought I'd put them all up on a single page , which can point to the latest versions and act as a sort of one-stop shop. I've also updated the registry tools yet again, to fix some bugs and add new functionality, and also made some enhancements to volshell. You can read about the changes below: Changes to VolReg : New command hivedump : dump keys and timestamps (and optionally value data) from all hives to a CSV file. Many improvements to robustness and error handling when reading key and value data. When checking the registry hive names, catch exceptions and try to continue anyway (reported by chris). Changes to volshell : A new command, dis , is available. If distorm is installed, it will disassemble bytes from a given memory address as x86 code. db no longer rounds length to a multiple of 4. Use a single profile object throughout all commands (speed improvement) dt

RegRipper and Volatility Prototype

When I first released the registry tools for Volatility , I discussed the possibility of interoperating with Harlan Carvey's excellent RegRipper . Now, thanks to Inline::Python and a bit of hackery, you can now run RegRipper against a memory image! Unfortunately, since Inline::Python only seems to work on Linux, you'll need to have a working Linux box around to use this (if anyone knows of a cross-platform way to use Python code from Perl, please let me know!). I'll get to the details of how this works later, but for now let's talk about how you actually use this stuff. First of all, since we depend on Inline::Python to manage the unholy union of Perl and Python, you'll need to get it from CPAN or your distribution's package manager. No need to install Parse::Win32Registry ; I've replaced it with my own registry code that will run against memory. Next, you should download the latest version of the registry tools [ tarball , zip ] (side note: I updated the