Recently, to a live, write a program for batch analysis and the corresponding pile dll PDB, you
In fact, work is very simple, it is based on a bunch offset by PDB file, find the corresponding dll inside the corresponding plaintext symbol position,
Simple needs, implement, usually very troublesome,
Microsoft's demo, there is a demo, called dia, this demo can provide similar functionality,
I am pleased to compile the project, but failed, failed to load symbol,
By stepping across a number of small problems (such as msdia120 not registered this), find the location of problems is on loadDataForExe this function,
This is the function prototype
virtual HRESULT STDMETHODCALLTYPE loadDataForExe( LPCOLESTR executable, LPCOLESTR searchPath, IUnknown *pCallback) = 0
As can be seen, the parameter 1 is the executable file to be parsed, parameter 2 is the target dll alive exe, parameter 3 is an interface that can be NULL, or in accordance with Microsoft's demo without modification.
But after performing a discovery, it gave me an error, saying the wrong path, unable to find the target pdb.
Specific details are not wrong to say, a waste of time.
Talk about how to solve this problem now.
Solution is relatively simple,
First determine ideas, this function can not be used, that it can not download their own symbols, then how to do,
The solution is to download our symbol, and then load it directly like, another function can be used loadDataFromPdb.
Determine the idea, then they would pave the way, how I how to download their own symbols,
The easiest way, in fact, use Windows own download function, in order to develop as little as possible, so you can use the internal WinDBG feature to automatically download symbol.
Thus, the symbol file with the loaded way there, how he sent the corresponding symbol files and executable files up, how correspondence.
Through analysis, we find that, in fact, after landing the symbol file is a special directory name, the name like a MD5, or like a GUID,
By analyzing the program, eventually found, the directory name is actually an executable file inside the GUID record, and then added something in the last 1 characters.
Specific point, that's it.
1 PCHAR pBuffer = (PCHAR)h; 2 PCHAR pTemp = pBuffer + 0x3C; 3 pTemp = pBuffer + *(DWORD *)pTemp; 4 if (!(pTemp[0] == 'P' && pTemp[1] == 'E' && pTemp[2] == '\0' && pTemp[3] == '\0')) 5 { 6 return NULL; 7 } 8 PVOID *pv; 9= PV (PVOID *) (PTEMP + 0xA8 ); // find the debugging section 10 PTEMP pBuffer + = (DWORD) * PV; // calculate the memory address specified debug sections . 11 PV = (PVOID *) (+ PTEMP . 4 * . 5 ); // find the offset 12 is PTEMP pBuffer + = (DWORD) * PV; // find the UUID of the base address 13 is IF ((PTEMP [! 0 ] == ' R & lt ' && PTEMP [ . 1 ] == ' S ' && PTEMP [ 2 ] == ' D ' && PTEMP [ . 3] == 'S')) 14 { 15 return NULL; 16 } 17 GUID tGuid = { 0 }; 18 memcpy_s(&tGuid, sizeof(tGuid), pTemp + 4, sizeof(tGuid));
According to the executable file, find the PE header, find the PE header from inside the debug section,
Debug sections inside to find GUID offset address,
GUID first four characters are the RSDS fixed offset address, after the determination, if there is no problem,
Then after is a GUID length,
Finally it formatted into this GUID string, and finally make a character '1' i.e. become assembly PDB file corresponding to the current directory name in the back,
This directory name can then piece together a complete directory, much like Windows dbghelp.dll spliced out of the directory,
Then go inside to be able to find their corresponding pdb.
The whole process ended narrative.
To sum up.
The solution can not load the pdb: download their own, independent of load.
method:
1: Use the command line WinDBG downloading an executable file corresponding PDB files.
2: The executable file path calculation PDB, PDB find the target.
3: After finding the target PDB, loadDataFromPdb loaded directly PDB just fine.