I have an old game executable with a large section of debug symbols, apparently in the Codeview format. How can I view the contents of this section in a human-readable format?
Current Windows compilers do not put the content of the debug symbols into the image file itself, they only put a reference to an external symbols file into the image. They put the debug data into a separate symbols file with the PDB (Program Data Base) extension. As you mentioned it, this format is also named CodeView. In your case, it looks like (since the debug section is large) you might be confronted with a really old symbols format.
this article explains the different symbols formats.
Okay, given that this is for 32-bit Windows, I believe the normal Windows symbol handler API should be able to read the data. From there, it's pretty much a matter of deciding what data you want, and how you want it formatted.
Related
So, I primarily use VS IDE for debugging. I got a dump file and tried to do a postmortem on it. All of the DLLs loaded their respective PDBs except one and I don't know exactly why. This information would be helpful in determining if the dump file got corrupted in some way or if the client has a corrupted DLL.
I have also tried to use WinDbg to debug this, which I have some but not a lot of experience with. I updated the symbol paths to the directory that has the PDBs of the proper build and some others that it also might match up with as well. I loaded up the dump file and that same DLL is not having a matching PDB file found.
So the question is, what prevents a particular PDB not match with a dump file and how can I find out what that information is?
Symbols have a hash and a timestamp. Both need to match in order to load the symbols. In WinDbg, there's an option to force loading symbols that don't match (.symopt+ 0x40). Visual Studio doesn't have such an option, so you need to use chkmatch to make symbols match. Note that this is a dangerous operation, because it modifies the PDB file. You should create a backup copy and delete the modified file after you're done.
If you can't figure out what executable exactly is in the dump file, try .writemem <FileName> <Range> with the starting address of the executable and its size. See also How to retrieve assembly from a raw memory dump?.
For checking a dump file for corruption, I only know about DumpChk, which comes with WinDbg. AFAIK, the file format does not allow detection of single byte corruptions or similar.
I updated the symbol paths to the directory that has the PDBs
You should set up a symbol server. With a symbol server, there's no need to look for symbols or configure directories.
I'm currently doing an assignment that demonstrates the use of CVE-2015-0096. It is also known as 'LNK file vulnerabilty'. I tried to look it up and got some info (mainly involving .DLL files).
I'm a Mac user and I have very little knowledge about .DLL files which is why I couldn't completely understand this vulnerability and now I'm having a hard time to explain it in my document. I would really appreciate if someone can explain it to me precisely what it is in a easier way, considering my weak understanding of windows.
See this.
A windows DLL(dynamically linked library) file is equivalent to a linux/mac SO(shared object).
A DLL is a binary file containing libraries.
A LNK file(normal file link) can contain an image preview.
This preview can be a normal image or an image from some specific windows DLLs.
The problem is that the whitelisted of DLLs for that can be bypassed by adding a special header to the LNK file.
Then, the hacker sets the preview to his DLL.
When the preview is loaded, the arbituarry DLL is loaded and you have remote code execution.
I'm messing around with compilers, .obj files, assembly, etc. The .obj file contains info that eventually ends up in the PDB, but I can't find any reference to the format that's used within the debug sections of the .obj file. (I have, however, found a reference to the COFF file format -- so I already know about that).
So: What's the format of the .debug$S and .debug$T sections when the source C file is compiled with the /Zi flag?
This information isn't published (the format used for native PDBs). If you can link the object file into an executable using "link" there are windows "debugging apis" you can use to "interrogate" symbols in an image. However, the format used for object files is not made publicly available.
You could try and reverse engineer it. If you find any info, please share it.
As described in title, I think the pdb file is a superset of map file. The reason why I ask this question is due to the fact that i'm now taking charge of sustaining a old system which will produce pdb and map file at the same time. I wonder if the map file is unnecessary while pdb file is available!
Thanks
I've also wondered about this and decided to see what John Robbins has to say in his book "Debugging Applications". He says that map files are "the only textual representation of your program's global symbols and source and line number information" and can be read without any supporting program. He goes on to say that Microsoft changes the symbol table format on a regular basis and if you have a customer running a very old version of your program, it may be hard to find an old version of the symbol engine that can interpret the symbol table in the PDB files for that very old program. But since a map file is just a text file, you would easily be able to map a crash address to a symbol by simply opening the map file in notepad!
I am trying to understand how a debugger uses PDB file. It would probably be a small file system in itself. Could someone help me understand the structure of the PDB file?
According to this blog post, the actual file format is kept secret by MS. However, I recommend you read that post as it has a lot of useful information what a PDB file is and how it's used.
According to MSDN, its impractical:
Because the format of the .pdb file generated by the postcompiler
tools undergoes constant revision, exposing the format is impractical
A debugger would use the DIA SDK to access the data inside them, meaning you don't really need to know its structure.
As a matter of fact, the format of PDB is not documented, but you can collect very detailed information about the content of PDB files programmatically using the appropriate interfaces See Sample