因为我更喜欢用普通WinDbg（而不是与IDA集成的WinDbg），我希望WinDbg能够识别IDA（和我）给这些地址指定的名称。这样，a）我可以按名称中断这些函数，按名称更改变量，b）WinDbg的输出和视图将更好地读取（在堆栈跟踪等中）。
，不幸的是，IDA没有“创建PDB”功能，我什至没有看到将地址导入WinDbg的非PDB方法。
想法，有人吗？
#1 楼
此页面包含一个IDC脚本和一个用于转储名称的Windbg扩展，以及一个用于将这些名称加载到WinDbg中的WinDbg扩展。编辑
通过@OzgurH发表评论因为AddSyntheticSymbol实际上很慢，所以从idc获取名称列表和边界是很乏味的
（这也是在idafree 5中完成的，它已经有一段时间不可用了，现在只有ida free7可用，只有64位）
所以我没有做很多检查
，但是我只是写了另一个windbg扩展，并利用windbg脚本执行命令行添加了正确的名称和大小
也可以使用这种方法来获得可重用的数据库反转符号
我已将源代码/编译设置/预编译二进制文件放在这里的github中
评论
当二进制文件超过几千字节时，idc脚本的运行速度似乎非常慢，可以有人对其进行审查并评论提高速度，或者建议采用另一种方法来加快其速度，以得到相同的输出格式
– blabb
2014年4月12日在7:20
就我而言（内核驱动程序调试），我必须设置为subsub = FirstSeg（）
–伊利亚
14年5月13日在17:28
一个以相当快的速度获取名称的插件（已使用get_nlist_size（），name，函数将其目标添加到ida free 5中，该功能比脚本看的速度快了几个数量级）
– blabb
14年5月13日在18:52
我找不到顺便说一句，我改进了代码以包含函数大小。调用堆栈对我来说非常有趣，并且当大小始终为4时，它们无法正确显示-这是一个很小的变化：gist.github.com/ikonst/ebae548dac7934dc0bdf
–伊利亚
14年5月13日在21:41
谢谢您的评论我从来没有必要合成标签这么大的数字，所以我从来没有看过也运行过IDC并且生成地图也太慢了，所以我求助于编写一个labeller扩展名并使用脚本文件来手动标记该区域。 a
– blabb
9月20日1:08
#2 楼
因为这与原始查询无关，并且是我在第一个答案中编辑的labeller windbg扩展的一种实验
我将其添加为新答案，而不是编辑我的原始答案
由于批量添加的AddSyntheticSymbol的性能问题出现了，所以我制作了一个小的6位数长的windbg脚本文件，可以用来测试性能
，看来所需时间在对数增长添加符号
如果windbg在第一轮中可以在11秒内添加500个符号
接下来的500个元素将花费13秒，而第三轮500个符号则需要16秒
当我添加第20轮符号时，我切断了测试，将符号9500加载到10000大约花费了50秒。 >这会使用100200个windbg命令创建一个文件，该命令使用！label extcmd
buff = []
j=0
k=1
for i in range(0,100000,1):
j=j+1
buff.append("!label str_%s %08x 1 xul\n" % ( str(i).rjust(8,'0') , i ) )
if(j == 500):
buff.append("%s %d symbols added\n" % (".echotime;.echo ",j*k))
j = 0
k = k+1
with open ("lab100k.txt","w") as txt:
txt.writelines(buff)
加载标签扩展名和e对这个windbg脚本执行xecute，并在标记10000地址后将其切断，时间范围如下所示。
wc -l lab100k.txt
100200 lab100k.txt
grep -c echotime lab100k.txt
200
tail -n 3 lab100k.txt
!label str_00099998 0001869e 1 xul
!label str_00099999 0001869f 1 xul
.echotime;.echo 100000 symbols added
符号结果如下所示
0:021> $$>a< lab100k.txt
Debugger (not debuggee) time: Tue Sep 22 23:58:52.053 2020
500 symbols added
Debugger (not debuggee) time: Tue Sep 22 23:59:03.468 2020
1000 symbols added
Debugger (not debuggee) time: Tue Sep 22 23:59:16.983 2020
1500 symbols added
Debugger (not debuggee) time: Tue Sep 22 23:59:32.546 2020
2000 symbols added
Debugger (not debuggee) time: Tue Sep 22 23:59:50.225 2020
2500 symbols added
Debugger (not debuggee) time: Wed Sep 23 00:00:10.133 2020
3000 symbols added
Debugger (not debuggee) time: Wed Sep 23 00:00:32.502 2020
3500 symbols added
Debugger (not debuggee) time: Wed Sep 23 00:00:57.303 2020
4000 symbols added
Debugger (not debuggee) time: Wed Sep 23 00:01:23.955 2020
4500 symbols added
Debugger (not debuggee) time: Wed Sep 23 00:01:52.593 2020
5000 symbols added
Debugger (not debuggee) time: Wed Sep 23 00:02:22.930 2020
5500 symbols added
Debugger (not debuggee) time: Wed Sep 23 00:02:55.546 2020
6000 symbols added
Debugger (not debuggee) time: Wed Sep 23 00:03:30.068 2020
6500 symbols added
Debugger (not debuggee) time: Wed Sep 23 00:04:06.521 2020
7000 symbols added
Debugger (not debuggee) time: Wed Sep 23 00:04:45.134 2020
7500 symbols added
Debugger (not debuggee) time: Wed Sep 23 00:05:25.709 2020
8000 symbols added
Debugger (not debuggee) time: Wed Sep 23 00:06:08.456 2020
8500 symbols added
Debugger (not debuggee) time: Wed Sep 23 00:06:53.301 2020
9000 symbols added
Debugger (not debuggee) time: Wed Sep 23 00:07:40.663 2020
9500 symbols added
Debugger (not debuggee) time: Wed Sep 23 00:08:29.967 2020
10000 symbols added
评论
再次感谢您的努力，谢谢！..我注意到运行缓慢后，我将另一个WinDbg实例附加到运行扩展的实例上，并且调用堆栈包括dbghelp的调用！vsAddSymbol（最终）到ucrtbase！qsort（ref）（它是通过传入的自定义比较器执行此操作的：dbghelp！vsCompareAddrs）。因此，“快速排序”具有一些n确实有意义。 log（n）此处发生的计时。
– OzgurH
9月22日22:42
评论
它不太适合添加符号的“列表”，但是（在看到下面提到的扩展中对IDebugSymbols3 :: AddSyntheticSymbol的引用之后），我做了一些研究，并遇到了另一个扩展（synexts），该扩展允许添加命令窗口中的符号：Blog（博客中还提到该方法也在pykd中公开）