Once upon a time in days of yore, a young hobbit created a Windbg extension of great value and mystery, forged in hardship and sacrifice, and was all but forgotten.
This is to be a retelling of that tale and where it takes us today.
It begins with a blog post by Blabberer six years ago and ends with my rebuilding of the extension in Visual Studio 2013 and the results.
viewtopic.php?f=46&t=15503-addsym-windb ... to-windbg)
I think this extension is a great idea, I'd like to see it evolve. I'm having a problem, some of the symbols are loaded into Windbg but not all and not correctly.
The extension was borrowed by at least two others, with credit, one with a few minor changes and another released as an IDAPython script
Adds IDA symbols as WinDbg synthetic symbols
https://gist.github.com/ikonst/ebae548dac7934dc0bdf
IDAScript to create Symbol file which can be loaded in WinDbg via AddSyntheticSymbol
https://github.com/siberas/IDA2Sym
---------------------------------------
I started with the EngExtCpp-style extension sample project extcpp.cpp provided in the Windows Kits 8.1 x64, and popped it into VisualStudio 2013. First step was to Upgrade VC++ Compilers
changing Platform Toolset to 'v120' (was 'v110').
Then I copied Blabs extension code (ikonst updated) and added it to the sample project as another export EXT_COMMAND_METHOD(addsym);
The only compile issue I really had was this one
extcpp.cpp(96): error C2678: binary '!=' : no operator found which takes a left-hand operand of type
'std::basic_istream<char,std::char_traits<char>>' (or there is no acceptable conversion)
The error was underlined on the != character on 2 similar lines:
while (getline(ifs, inbuff) != NULL);
The error code doc is here
https://docs.microsoft.com/en-us/cpp/er ... ew=vs-2019
Something to do with the left hand side being a const object, a function declared in <string>, and the value != NULL on the right hand side.
This is wacky C++. I read various solutions involving namespaces, overloading, nothing I wanted to hear or understood. Finally realized that in this case at least, the while{} statement could be changed to eliminate the comparison completely with
} while (getline(ifs, inbuff));
What the hell, the return value NULL is no good with strings?
Anyway, that pretty much fixed it and I could compile the Windbg extension as x32 or x64.
-------------------------------------------
Next step was to create the .idasym file from the IDC script. It's purpose is to transfer the Names ida generated to windbg. I also took that as meaning to include user-defined functions and perhaps variable names. The EngExtCpp extension uses AddSyntheticSymbol to accomplish that.
The idc script itself parses names as such:
symname = Name( segstart+i ) ;
It works as expected, though the code could be modified to exclude certain segments from analysis for example. I don't think it picks up user-defined variable names. The python version above only picks up name changes that you prefix with something, so it limits the symbols to only what you might want.
I did make one change, rather than hardcoding the directory where the .idasym file will be created I used this to just create it in the same IDA exe/database folder:
symfile = GetInputFilePath() + ".idasym";
The .idasym file seems to be correct in producing a list of "names", but the problem seems to be that not all of them are imported into Windbg.
-------------------------------------------
As an example, I disassembled Strings64.exe and renamed the first 2 functions to see if they would be transferred to Windbg.
Code: Select all
.load myextcpp.dll
0:000> .chain
Extension DLL search Path:
C:\Program Files (x86)\Windows Kits\8.1\Debuggers\x64\winext
Extension DLL chain:
myextcpp.dll: image 6.3.9600.17336, API 1.0.0, built Mon Apr 27 00:44:48 2020
[path: C:\Program Files (x86)\Windows Kits\8.1\Debuggers\x64\winext\myextcpp.dll]
0:000> !addsym /? // btw I didn't know that's how you called the damned built in EngExtCpp help!!
!addsym <MODULE> <path>
<MODULE> - An expression or address like nt / 0x804d7000
<path> - path to idasym file
viz c:\idasym\MODULE.EXT.idasym (consumes remainder of input string)
windbg extension to use names that are generated by ida
do .reload /f MODULE.ext=base,size prior to using this extension
// .reload [Options] [Module [= Address [, Size [,
0:000> .reload /f image00000001_3f420000.exe=000000013f420000,29000
*** ERROR: Module load completed but symbols could not be loaded for image00000001_3f420000.exe
Note that Strings64.exe is called 'image00000001_3f420000' by Windbg, for some reason it doesn't recognize the process name and uses its base address as an image name.
0:000> lm
start end module name
00000001`3f420000 00000001`3f449000 image00000001_3f420000 (no symbols)
0:000> !myextcpp.addsym image00000001_3f420000 C:\Utilities\Strings\Strings64.exe.idasym
total symbols in idasym file is 1321 press ctrl+break to interrupt symbol resolving
500 symbols resolved
1000 symbols resolved
total 1321 symbols resolved
done
0:000> x image00000001_3f420000!*
00000001`3f4313e8 image00000001_3f420000!_positive = <no type information>
00000001`3f433000 image00000001_3f420000!RegQueryValueExW = <no type information>
00000001`3f433008 image00000001_3f420000!RegQueryValueExA = <no type information>
Here are the first 5 lines from the .idasym file, where it should have started to import symbols:
00000000-0000016b,_MyFunctionSymbol1
00000170-000002f8,_MyFunctionSymbol2
00000490-0000061a,DialogFunc
00002310-000026ff,main
00002700-00002706,GetFileVersionInfoSizeA
I had a similar problem with a compiled x32 extension on a win32 app, it only began importing names from the .idata section
0:000> x winid!*
00436000 winid!RegQueryValueExA = <no type information>
OK, that's too much writing for now, but I wanted to go over everything I did, and figure out what I did wrong.
Kayaker
