Mandiant is introducing a new free tool today, PdbXtract™, which allows you to browse and search PDB-type information.

PdbXtract allows you to explore symbolic type information as extracted from Microsoft PDB files. This tool is primarily designed for reverse engineering Windows-based applications and for exploring the internals of Windows kernel components. You can download PdbXtract.

A programming database (PDB) file is a binary file containing program debug information in a Microsoft-proprietary format. This file is produced by the compiler/linker when a program is built. The information it contains is used by debuggers to debug a program and can greatly assist a developer in debugging program issues by resolving function pointers to symbolic names, for example.

Perhaps the most useful and richest source of debugging information contained in PDBs is type data which holds detailed information about data structures, constants, and other named symbols. While this information is primarily used to debug program components, it can also be used to gain insight into how core operating system components work by observing both the format of the data structure and how the structure is used.

PdbXtract is not a pure PDB parser. It only extracts type information using Microsoft's DebugInterface Access (DIA) COM. If you are interested in just parsing/dumping raw PDB information, there are a few alternatives out there to DIA, including Volatility's open source pdbparse (http://code.google.com/p/pdbparse/) or the PDB utility that comes with the Undocumented Windows 2000 Secrets book. However, most of the practical tools I have seen that operate on PDB's use DIA, including Microsoft's own Dia2dump, this one http://www.codeproject.com/Articles/37456/How-To-Inspect-the-Content-of-a-Program-Database-P and this one http://www.ishani.org/web/articles/obsolete/pdb-cracking-tool/, to name a few. To reiterate, PdbXtract does not parse or capture the wealth of other information available in a PDB, including: functions, debug streams, modules, publics, globals, files, section information, injected sources, source files, OEM specific types, compilands, and others.

The tools mentioned above are fine for inspecting the contents of a single PDB. However, often times as part of my job in R&D, we have to use knowledge of type information across all supported Windows operating systems to implement features. For example, if you are dealing with partially undocumented or "opaque" types (example: you need to walk the PEB's InInitializationOrderModuleList to obtain a list of loaded modules in a process) or have full source type information but do not want to tie your program to a specific version of those types as implemented in the headers of the SDK you are compiling against, you probably want to just use static offsets such as:

PVOID NextMod=(PVOID ((DWORD_PTR)PebPtr+InInitOrderModList_Offset+Flink_Offset);

The problem has always been: how do I get the value of InInitOrderModList_Offset for all platforms we support, taking into account 32-bit/64-bit variations? The answer has always been: useWinDbg (or if you are interested in possibly-correct kernel symbols only, you might use Matt Suiche's Moonsols library (http://msdn.moonsols.com )). Launch a VM for each OS you want to support, attach with a debugger, and use the power of WinDbg to extract the type information. Well, WinDbg's magical "dt" command just relies on the PDB information for the corresponding binary (after retrieving the necessary symbol files from your local symbol store and optionally the Microsoft public symbol server), so it stands to reason that we should be able to do the same. The end goal is to make a searchable database for all the exported types of OS binaries we care about, so that we don't have to constantly relive the tedium of doing this in WinDbg.

Features

PdbXtract has two main features: exploring a single PDB (PDB Explorer) and searching a library of PDBs for one or more operating systems. PDB Explorer opens the PDB, parses type information using DIA, and displays a list of all structs, unions and enums. If you click on one of the types, a C-style struct (with offsets) definition will be displayed in the text area to the right, as shown below for the type IMAGE_FILE_HEADER.

The library tab allows you to create and search a library of PDB type information. I have created a library for *most* of the operating systems we support for the following important system binaries: kernel (ntoskrnl.exe, ntkrpamp, ntkrnlpa, ntkrnlmp),ndis.sys, win32k.sys and hal (hal.dll, halaacpi.dll, halmacpi.dll). You might ask why other system DLLs were not included, such askernel32, user32, advapi32, etc.The answer to that being the corresponding PDBs for those binaries you get off the symbol server are stripped of type information. Why? Because Microsoft expects you to use their headers when you compile your application, and thus your program'sPDB will have the necessary type information.

The library included with PdbXtract covers several of Microsoft's major operating system releases, but you can easily add more symbols. PdbXtract includes a utility, called PdbFetch, that simply runs Microsoft's symchk utility to grab the symbols for the file names you supply (usage: pdbfetch, where is a text file that contains a list of full paths to system binaries you want to retrieve symbols for). Pdbfetch creates a "PDB set" which consists ofthe directory structure with containing PDBs as created by symchkplus a manifest.xml file which summarizes the OSplatform information. To use a PDB set in PdbXtract, go to the library tab and click "new" if you want to create a new library from the PDB set or "add" if you want to add them to an existing library. Once you create/add a PDB set to a library you can delete them - the only thing that matters is the sqlite .pdbx database that's created.

Perhaps someone out there will find this useful and maybe create a searchable web front end with the resulting SQLite database? The sky is the limit. Let me know if you do by commenting below.

As a final note, you might wonder why you can't just download the entire symbol packages from Microsoft, which include every symbol file on the MS Symbol server, and create a ginormous library. Why is there a requirement to acquire the PDBs using pdbfetch? The answer is - you could do that - but it is data overload(several GB of PDBs) when you will not care about 99% of them. Plus it is easier to capture OS platform/build info at run time rather than guessing at it from the name of the symbol package installer (PDBs give no indication of what OS the corresponding binary originated from).