9

When I have a kernel module without symbols, I'd typically first open it in IDA and give names to some of the subroutines (those I'm interested in).

Since I prefer my kernel debugging with plain WinDbg (and not the IDA-integrated WinDbg), I'd like WinDbg to recognize the names IDA (and me) gave to those addresses. That way, a) I could break on those functions by name, change variables by name, and b) WinDbg's output and views would read better (in stack traces etc.).

Unfortunately, IDA has no "create PDB" feature, and I don't even see a non-PDB way of importing addresses into WinDbg.

Ideas, anyone?

Improve this question
1
  • It's not quite suitable for adding a "list" of symbols, but (after seeing the reference to IDebugSymbols3::AddSyntheticSymbol in the extension mentioned below), I've researched a bit, and run into another extension (synexts) which allows adding a symbol through the command window: Blog (The blog also mentions that the method is exposed in pykd as well)
    – OzgurH
    Commented Sep 4, 2020 at 20:36

2 Answers 2

Reset to default
7

This page contains an IDC script And a Windbg Extension to dump the names and a WinDbg extension to load those names into WinDbg.

Edit To Address the comment by @OzgurH

yes the idc as well as AddSyntheticSymbol are slow in fact getting a list of Names along with the boundaries from idc is tedious (also it was done in idafree 5 which isn't available for some time now only ida free7 is available which is only 64 bit

so i havent checked it much

but i simply wrote another windbg extension and leveraged the windbg script execution command line to add correct name and sizes also by using this method i can have a reusable database of reversed symbol

i have put the source / compile settings / precompiled binary in github here

Improve this answer
13
  • the idc script seems to work very very slow when the binary is above a few kilobytes can some one review it and comment on improving its speed or suggest alternative method to speed it up that results in same output format
    – blabb
    Commented Apr 12, 2014 at 7:20
  • In my case (kernel driver debugging), I have to set tosubtract = FirstSeg()
    – Ilya
    Commented May 13, 2014 at 17:28
  • a plugin that fetches the names in pretty fast (targeted to work in ida free 5 has been added to the thread using get_nlist_size(),name, functions it is several magnitudes faster than the script take a look
    – blabb
    Commented May 13, 2014 at 18:52
  • I can't find it. btw, I've improved the code to include function sizes. Call stacks are very interesting to me, and they weren't displaying correctly when the size was always 4 -- here's the change, pretty trivial: gist.github.com/ikonst/ebae548dac7934dc0bdf
    – Ilya
    Commented May 13, 2014 at 21:41
  • 1
    Thank You For The Comment i never had the necessity to Synthetically label such huge numbers so i never looked also running the idc and generating a map was also too slow so i resorted to writing a labeller extension and label the area manually using scriptfile $$>a< foo.wds where foo.wds contained a series of space delimited !label somename rva size base like !label _some_spooky_function 000a05a6 2e ntdll but that also used AddSyntheicSymbol
    – blabb
    Commented Sep 20, 2020 at 1:08
1

since this has nothing to do with original query and
is an experiment of sorts with the labeller windbg extension that i edited in in my first answer
i am adding this as a new answer and not editing my original answer
since the question of performance of AddSyntheticSymbol for bulk Addition Came up i cooked up a small 6 figure long windbg script file that i could use to test the performance

it appears there is a logarithmic increase in the time required to add symbols
if windbg could add 500 symbols in 11 seconds on the first round
it would take 13 seconds for next 500 and
16 seconds for the third round of 500 symbols
i cut off the test when i added the 20 th round of symbols it took about 50 seconds to load the symbols 9500 to 10000

here is the small python script to cook up a windbg scriptfile

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)

this creates a file with 100200 windbg commands that uses !label extcmd

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

loaded the label extension and executed this windbg script and cut it off after labelling 10000 address the timeframe isas follows

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

the result of symbols are as follows

0:021> x xul!str_000100*
50462710          xul!str_00010000 = <no type information>
50462711          xul!str_00010001 = <no type information>
50462712          xul!str_00010002 = <no type information>
50462713          xul!str_00010003 = <no type information>
50462714          xul!str_00010004 = <no type information>
50462715          xul!str_00010005 = <no type information>
50462716          xul!str_00010006 = <no type information>
50462717          xul!str_00010007 = <no type information>
50462718          xul!str_00010008 = <no type information>
50462719          xul!str_00010009 = <no type information>
5046271a          xul!str_00010010 = <no type information>
5046271b          xul!str_00010011 = <no type information>
5046271c          xul!str_00010012 = <no type information>
5046271d          xul!str_00010013 = <no type information>
5046271e          xul!str_00010014 = <no type information>
5046271f          xul!str_00010015 = <no type information>
50462720          xul!str_00010016 = <no type information>
50462721          xul!str_00010017 = <no type information>
50462722          xul!str_00010018 = <no type information>
50462723          xul!str_00010019 = <no type information>
50462724          xul!str_00010020 = <no type information>
50462725          xul!str_00010021 = <no type information>
50462726          xul!str_00010022 = <no type information>
50462727          xul!str_00010023 = <no type information>
50462728          xul!str_00010024 = <no type information>
50462729          xul!str_00010025 = <no type information>
5046272a          xul!str_00010026 = <no type information>
5046272b          xul!str_00010027 = <no type information>
5046272c          xul!str_00010028 = <no type information>
Improve this answer
1
  • Again, your efforts are very appreciated, thanks!.. Once I've noticed the slowness, I've attached another instance of WinDbg, to the one running the extension, and the call stack included a call from dbghelp!vsAddSymbol (eventually) to ucrtbase!qsort(ref) (and it was doing this with a custom comparator passed in: dbghelp!vsCompareAddrs). So, it does make sense that Quick Sort has some n . log(n) kind of timing happening here.
    – OzgurH
    Commented Sep 22, 2020 at 22:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.