As far as I know, everything you've said is 100% correct. I've experienced the same issues. In fact, I was working on this exact problem in the background when a friend sent me a link to this post.
There are actually three related issues here. First, prior to IDA 7.2, IDA's type system did not have a concept of a virtual function table per se. Meaning, ...
You can find some information about PDB on the blog of PDBParse's author:
This article is a good resource about PDB :
Other link on the subject :
Given that you don't already have the .obj files, it doesn't make sense to try to generate the .obj files from the .exe and .pdb files and then reverse engineer the generated .obj files. If you were to do this then the .obj files wouldn't have any information in them that was not already in the .exe or .pdb files. As such, you're better off just working with ...
dynamic_cast requires a runtime check that the cast is valid at execution time and the usual implementation uses RTTI (Run-time type information) attached to all classes participating in the casts. However, since it's not easy to narrow down the classes that may be possibly casted, in practice the compiler emits RTTI for all polymorphic classes (i.e. those ...
If you purpose to reverse engineer the game is order to learn the way it was made you will most likely end up having C/C++ files recreated (at least of major components). I am afraid there is no way you can reverse something and have full understanding of internal workings without firm grip on assembly. There are several tool that could aid you in your work....
I finally solved my problem.
DIA stands for Debug Interface Access and is the component used to correctly read PDB files.
The msdia90.dll used doesn't seem to have been installed with the VS 2013 redistributables.
I had to install the 2008 redistributables to get the correct dll.
I solved my problem thanks to http://download.tuxfamily.org/...
Since the format is internal to Microsoft you likely won't find any official documentation. The best bet is various reverse engineering efforts on the format:
PDB Parser (the one you found)
PDBparse (in Python)
Wine project has a partial implementation of dbghelp.dll, including PDB parsing.
P.S. I just remembered that there is an open-source Microsoft ...
This is what I've found:
Exploring Symbol Type Information with PdbXtract - from Mendiat.
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 ...
If you are interested in really digesting the PE format, you definitely want to have a look at the references available here: http://blog.dkbza.org/2012/08/pe-file-format-graphs.html
Those diagrams are wonderfully complete and will absolutely give you an enormous leg up when it comes to analyzing an unknown file in PE format, even if the headers have been ...
You can use PDB downloader which doesn’t require any installation https://docs.microsoft.com/en-us/archive/blogs/webtopics/pdb-downloader. Or you could use its source below to see how you could recreate with PowerShell or some other method.
You can also just copy the WinDBg files from a machine where it’s ...
While sdb files was created to translate imports that are referenced by ordinal instead of by name (see "Exporting Functions from a DLL by Ordinal Rather Than by Name"), pdb files are something entirely different.
Program Database (PDB) file or DBG file are produced by the compiler. PDB files are used by developers to debug their program ...
Old versions of link.exe supported the /debugtype argument that used these options:
use COFF format
use CodeView or Program Database format (depends on /pdb option)
use both COFF and CodeView/Program Database formats
According to the MSDN docs for Visual Studio 2008's linker, that option was no ...
While PDBs will certainly help in decompilation (e.g. with you may be able to recover names of functions, classes, and maybe even local variables), they don't contain the original source code and other things unnecessary for debugging (such as comments).
pdb is self contained so you can drag and drop it and the debugger can utilize it
but src files are just path references
either relative or absolute paths
so either you have to copy them to a local directory
(think about feasibility of this with a project that has thousands of src files) or
set up the directory structure ( a bit easier if you did not compile ...