Push the Red Button

I've posted about this before ( twice !), but somehow never gotten around to releasing functioning code. Here (click) , for your downloading pleasure, is a set of plugins designed to extract information about on-screen (graphical) windows from Windows XP SP2/3 memory images. This includes: window_list - give a text listing of the window hierarchy, with each window's on-screen coordinates, current style, and its class (Button, Window, etc.). Here's some example output to whet your appetite . screenshot - save a wireframe "screenshot" of the on-screen windows in a memory image. See later in this post for some examples. Requires PIL . wndmon - continuously monitor a memory image and provide an updating view of the on-screen windows. Works best in a live environment, e.g. with XenAccess and PyXa . Requires PyGame . (This is what I used for the video demo ). All three plugins require the distorm disassembly library to work. I had a bit of trouble getting it to wor...

It's pretty well known, in memory forensics circles, that there are two common ways of finding processes in memory images: list-walking , which traverses the kernel's linked list of process data structures, and scanning , which does a sweep over memory, looking for byte patterns that match the data found in a process data structure. Having two different ways of finding processes can be very handy, especially when we suspect that someone may be trying to hide processes. One common way of hiding processes in Windows is called DKOM (Direct Kernel Object Manipulation) ; this technique works by just unlinking the process you want to hide from the kernel's list, like so: This makes it invisible from programs such as the task manager, as well as memory forensic tools that use list-walking (including Volatility's pslist). However, such hidden processes can still be found by scanning memory using a signature for the process data structure; this is what psscan2 does. Unfortunatel...

I've been too busy to do any longer entries recently, but I wanted to note a couple things quickly. First up, Andreas Schuster has just released a wonderful set of slides on using Volatility to do memory forensics. The slides include: Great background material on the how, what, and why of memory acquisition and forensics. A refresher on some OS basics you need to really understand memory analysis. An amazing and comprehensive walkthrough on how to use a number of Volatility modules plugins in an investigation (including a few of my own tools, like ssdt.py and VolReg ). Great information on the internals of Volatility, including a tutorial on creating your own plugins. This is really awesome stuff, and I highly recommend it to anyone looking to learn more about Volatility or even start contributing to the community with new plugins! Many thanks to Andreas! Second, I wanted to let everyone know once again that I'm going to be speaking at the SANS WhatWorks Summit in Forensics a...

If you follow Matthieu Suiche's blog (and if you don't, you really should!), you probably saw his post about an undocumented type of registry value -- CM_BIG_DATA. This is a registry optimization introduced by Microsoft with Windows XP that allows for more efficient storage of large amounts of data in the registry. You can read more about the details of this new way of storing large values in his post , but I wanted to announce the release of a new version of VolReg with experimental support for BIG_DATA values. As always, you can get the latest version of VolReg from my Volatility plugin page . This release also fixes a bug found by AAron Walters where an exception would be raised if the data returned for a value is less than the required amount for that type (e.g., only two bytes being available for a REG_DWORD). I also updated Volshell , fixing a regression found by J. Hewlett that broke the ability to use the "dt" command to examine a data structure without overl...

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...

I've found a couple bugs in the registry code I released recently, and at least one is significant enough that a new release is warranted. Teach me to release code I wrote in a couple hours on a plane ;) The list of fixes is: Fix a bug that prevented any volatile subkeys from appearing when using the subkeys() function. Add a check for None when using lsadump (reported by Paul Bobby, thanks!) Add appropriate license statements at the top of each file (thanks AAron!). For the record, the license is the GNU General Public License (GPL). You can download the new version as a zip or tarball , and install it exactly as the previous version, by extracting it into your Volatility directory. If you have a previous version installed, this should just overwrite it (though you may have to tell your unzip program that's okay). As before, PyCrypto is required for the credential extraction modules. One final note: I have seen some crashes when people attempt to use the hash extraction code...

In which window messages are explored, a new plugin is created, and we learn the importance of reading messages sent to you regularly. In Windows, the GUI system is event-driven –actions occur in response to various events generated by the system. When you press a key on the keyboard, Windows generates a window message (specifically, WM_KEYDOWN ) and sends it to the thread that owns the window that's in focus. That thread then call's the window's event handling procedure (the so-called WindowProc ) to process the message. There are many such messages , covering input events such as keyboard and mouse actions, system-level events such as notification of a time change or a change in the system's power state , and events related to the windowing system, such as resizing or moving a window. How can these be forensically relevant? Well, as it turns out, some threads in buggy applications aren't always good at processing their messages, and messages they receive pi...

When malicious, kernel-level code is installed on the system, one action it may take is to hook various system services. What this means is that it takes some standard piece of operating system functionality and replaces it with its own code, allowing it to alter the way all other programs use the OS. For example, it may hook functions involved in opening registry keys, and modify their output so as to hide registry keys the rootkit uses. As system calls are the primary interface between user and kernel mode, the system call table is a popular place to do such hooking. It's worth noting that many security products also make heavy use of hooking. One common example is antivirus software; among the many functions it hooks is NtCreateProcess (used, as the name suggests, to start a new process) so that it can do its on-demand scanning of any newly launched programs. For this reason, it's not safe to assume that any hooking of system calls is malicious; in fact, some of the most su...

This one's for all the command line lovers out there: I'm happy to release volshell , an interactive shell built on Python and designed with memory analysis research in mind. I gave a demo of this at my OMFW talk, "Interactive Memory Exploration with Volatility"; since it was more of a live demo, I don't have slides from that, but you can find my notes here . You should be able to follow the notes as a sort of walkthrough that will get you up and running with volshell, and introduce some of the more advanced features. Briefly, here are some of the features of volshell: Shell is a full Python interpreter, so all the power of Python can be leveraged. Uses Volatility 1.3 object model for easy access to data structures in memory. Can use iPython for the underlying shell if available, which enables some nice features. Commands modelled after WinDbg. Works with any memory image format that Volatility supports (dd, crash, vmem, hibernation file) To use it, just downlo...

In the course of an investigation, it may be critical to be able to link up a process that's running to a particular user account. Particularly in a multi-user environment such as Windows Terminal Server, this isn't always as easy as checking who was logged in at the time. Luckily, each process in Windows has an associated token , a chunk of metadata that describes what Security Identifier (SID) owns the process and what privileges have been granted to it. As Larry Osterman explains , A SID is essentially a unique ID that is assigned to a user or group, and is broken into several parts: the revision (currently always set to 1), the identifier authority (describing what authority created the SID, and hence how to interpret the subauthoriries), and finally a list of subauthorities . In general, when users see SIDs (which they rarely do), they are in what's called the Security Descriptor Definition Language (SDDL) form. This is a string that looks like: S-1-5-21-1957994488...

After tons of hard work by a lot of people (including me), Volatility 1.3 has been released to the world at large. AAron has a blog post up with all the juicy details, including a list of new features. For my part, I want to take this opportunity focus on a couple new things that I think are really cool. They're mostly developer-focused, so if you have no interest in adding new capabilities to Volatility, you can skip the rest of this entry and just head over to AAron's post to see all the new modules and functionality. The first feature I want to point out is the new plugin system. Basically, rather than creating a new module and then editing vmodules.py to add new commands to Volatility, you can now just create a class extending forensics.commands.command with the code you want to run, drop it into a file, and put that file into the memory_plugins directory, and Volatility will pick it up and see it as a new command that can be run. This means that anyone can just give out ...

It's been quite a while since I wrote any new blog posts. This isn't entirely because I've been lazy; rather, I've picked up and relocated to sunny (and often hot and humid) Atlanta, Georgia to start the PhD program at Georgia Tech . I'm going to be working on lots of cool stuff with the Georgia Tech Information Security Center . Now that I'm here and starting to get settled in, you can expect the blog posts to start up again. Particularly with the forthcoming release of Volatility 1.3, I'm going to have a lot of new plugins and functionality to blog about. As a teaser, here are some of the things I've got in the works: getsids.py -- get the SID (kind of like a user ID in unix) that owns each process moddump.py -- extract loaded kernel modules from memory unloaded_modules.py -- list recently unloaded kernel modules ssdt.py -- show the System Service Descriptor Table, along with the kernel module that owns the memory. This can be used to detect hookin...