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

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

I don't have time for a full post right now, but I thought I'd offer a fun product of some things I've been working on recently. The work involves getting information about the windows on screen at the time a memory image was taken. One of the things you can extract is the position and size of each widget (called a "window", though I find this terminology a little confusing). Since I don't have time to go into the data structures and so on involved, I thought I'd give you all two "screenshots" that I reconstructed from the NIST XP SP2 memory images. Basically it's a white canvas as large as the screen resolution, with rectangles drawn on for each window on the screen. Without further ado: From the 6/25 image: From the 7/4 image: More details to come :)

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