Push the Red Button

Over the past few weeks, I've been continuing to investigate the structure of the Types stream (stream 2) in Microsoft PDB files with the help of Sven Schreiber's PDB parsing code . Some issues with getting approval to publish research came up at work, but I think they're mostly ironed out now, so I'm going to devote this entry to going through some of the trickier bits involved in parsing the Types stream. Some code also accompanies this entry: a python script to parse and print out the types contained in a stream. It works on streams that have alrady been extracted from a PDB file (see this earlier entry); if you don't have one around you can try it out on the Types stream from ntoskrnl.exe on Windows XP SP2. The Type Stream Header The types stream begins with a header that gives a few pieces of useful information. The first dword represents the version number, of the PDB file, and is generally determined by the version of the compiler that created the PDB file.

As I've mentioned to a few people, the past two posts have been the start of what I hope will become a trend: posting at least one piece of new, technically interesting content per week. With any luck, new posts will come out on Mondays (I cheated a bit this week and took Labor Day off). Topics covered will center around memory analysis, as this is my primary area of research, but I have a few posts planned on topics like network-based exploitation and cryptography. I hope any readers of this blog will enjoy the sudden influx of new content; don't hesitate to contact me with comments, criticisms, or ideas for new posts.

As I mentioned last week, I moved to a new apartment this week, and as a result I didn't have a lot of time to do any serious work. Still, I didn't want to let the entire week go to waste, so I decided to try and tackle a problem that I thought would be relatively simple: extracting a copy of the binary registry hives out of memory. As it turned out, this was actually a bit more difficult than I expected, and I'll have to get back to the problem at a later date, but I thought in the meantime I'd write about what steps I took, where I ran into trouble, and describe the approach I hope to take when I revisit the issue. There were several reasons to suspect that one might find at least partial copies of the registry in memory: the registry stores all of the configuration data for the Windows operating system, and its contents are referred to and updated quite often during normal operation (let Sysinternals' Regmon run for few minutes and look at the output if you hav

I've been taking a look at the structure of PDB files recently. PDB files are Microsoft's proprietary file format for storing debug information. They are generated by the Visual Studio family of products, and Microsoft has been kind enough to provide a full set of PDB files for its own operating system files since Windows 2000, which means that we get access to a whole bunch of great information like function symbols and type information. These can provide an excellent insight into the internals of the Windows operating system. Naturally, the file format is undocumented and proprietary (there used to be a page on MSDN stating as much, but I can't seem to find it now). However, Sven Schreiber, in his book Undocumented Windows 2000 Secrets: A Programmer's Cookbook , provides details on the format and some sample code for reading the information in such files. Although the original code only deals with PDB files created with Visual Studio 6.0 and below, he has recently r

As promised, I've posted the VAD tools. I'm hosting them on SourceForge right now. Anyone who's interested in memory forensics is encouraged to download the tools and play with them. Suggestions, bug reports, and code contributions would also be greatly appreciated. Links: Project home page Project page on SourceForge

David Litchfield of NGS Software has put up several excellent articles on Oracle Database Forensics. Litchfield is generally considered to be the most knowledgeable person in the field of database security, so his thoughts on database forensics carry a lot of weight. So far four articles have been posted: Oracle Forensics Part 1: Dissecting the Redo Logs Oracle Forensics Part 2: Locating Dropped Objects Oracle Forensics Part 3: Isolating Evidence of Attacks Against the Authentication Mechanism Oracle Forensics Part 4: Live Response I haven't read through them in detail yet, but it looks like they have a ton of awesome information about the binary format of the redo logs and recovering information that has been deleted (dropped) from the database.

I've just had my first paper accepted to a conference! The paper, titled The VAD Tree: A Process-Eye View of Physical Memory, describes how to use the Virtual Address Descriptor structure of the Windows kernel to do a variety of nifty things, including list DLLs loaded by the process and categorize a process's memory allocations into shared regions, mapped files, and private allocations. I'll be presenting it at the 7th annual Digital Forensics Research Workshop in Pittsburgh this August. Here's the abstract: This paper describes the use of the Virtual Address Descriptor (VAD) tree structure in Windows memory dumps to help guide forensic analysis of Windows memory. We describe how to locate and parse the structure, and show its value in breaking up physical memory into more manageable and semantically meaningful units than can be obtained by simply walking the page directory for the process. Several tools to display information about the VAD tree and dump the memory re

Despite my earlier bold claims that I'd be doing more analysis of "Big Yellow," I'm going to have to renege for now. At work, we recently came across a user who was trying to connect to an external IP upwards of a thousand times per day; some investigation showed that his machine had been compromised by a trojan, and so we started in on incident response. This has left me with very little time to look at Big Yellow, but it did give me something new to write about--Windows memory forensics. Our first response was to get the user to run a cool little bundle that my friend Andy and I have been working on that collects as much forensically important information from the user's system as possible and uploads it to a server using Webjob . The package includes a bunch of Sysinternals tools, ftimes to get file hashes and search for specific strings, and a version of dd from the Forensic Acquisition Utilities that can dump physical memory. This last bit is what we'l