Greetings,

i have some annotations/requests regarding ollydbg's use of symbol files (.pdb, .dbg) with operating system binaries.

Ollydbg seems to load both, the (older) imagehlp.dll and newer versions of dbghelp.dll (in start directory) to fetch symbolic information.
I assume "set symbols path" option in ollydbg corresponds with appropriate "SymSetSearchPath" or "SymInitialize" stuff.

This doesnt work at all if i feed my symbol store to ollydbg.
Even with latest dbghelp.dll in ollydbg directory (from "debugging tools for windows" it is not clear to me how and when symbolic information is used.
In fact i can't see much use (no dbghelp API getting initialized) in ollydbg.

I wrote a simple console program (proof of concept) which loads "dbghelp.dll" and initializes the debug symbol API using "SymInitialize".
I can see the symbol server dll loaded and the dynamic symbol file fetch mechanism works.

I would like to gain more information from ollydbg when specific symbols for a module are correctly loaded and when not.
Like the VS.NET 200X "modules" list where is a column "symbols" which displays the state.
Or like windbg's commandline output.
There is even an "reload symbols" option which i would like to see too.
Additionally i would like to customize symbol options before the symbol load process with "SymSetOptions"-like dialog:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/debug /base/symsetoptions.asp
("http://msdn.microsoft.com/library/default.asp?url=/library/en-us/debug/base/symsetoptions.asp
")

The showstopper is the use of the new "symbol server" technology.
I mainly use VS.NET 2003 for source level debugging which is able to fetch symbols for every binary on demand (if available).
No more need to download symbol files separately/for each service pack.
I can even remotely debug another system which is different to my host system and symbol server will fetch debug symbols for the remote system, allowing me to see "informational" callstacks.

Symbol server tech:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/debug /base/symbol_servers_and_symbol_stores.asp
("http://msdn.microsoft.com/library/default.asp?url=/library/en-us/debug/base/symbol_servers_and_symbol_stores.asp
")

The debugging symbols interface of ollydbg could be polished up a bit (more user friendly, more information).
Support of symbol server would improve usability much.

Regards,

A. Focht

Dear Focht ,
Greets
i wanted to look at some symbols from ntdll.dll
so i was poking around and i saw ollydbg wasnt loading symbols like you say in this thread
so i digged in little deep to look at .symopt params
and i saw olly was using 0x1212 as the default param
whereeas the windbg help file (version 6.02.007) was stating that
that the default value for windbg is 0x30337 and for kd.exe it is 0xb0227

so i kinda patched ollydbg to take these params
replaced the old dbghelp.dll with the one from windbg

and i notice ollydbg is now able to load the symbols from
c:\symbols ( this was originally set by livekd environment variable _nt_symbol_path)

if time permits could you please look at this and reply back
the patch is as follows

fc ollydbg.exe ollydbgmodsymold1.exe
Comparing files OLLYDBG.EXE and OLLYDBGMODSYMOLD1.EXE
00090709: 10 27
0009070A: 12 02
0009070B: 00 0B

rva here
00491107 |> \81CA 27020B00 OR EDX, 0B0227 (i use kd.exe default as it suppresses dialogs and sets enum source off by default ie it differs from windbg default by +0x80000 -0x10

i am not using the view-->debug-->select path for symbols it is blank in ollydbg.ini

Thanks and Regards

default folders for symbols
c:> tree C:\WINNT\system32\Symbols

C:\WINNT\system32\Symbols
├───16bit
├───8bf
├───8bi
├───acm
├───ax
├───cfm
├───cnv
├───com
├───cpl
├───dll
├───drv
├───ds
├───exe
├───flg
├───ime
├───io
├───mll
├───noexport
│ ├───dll
│ ├───exe
│ └───sys
├───ocx
├───scr
├───sys
├───tsp
├───uniproc
│ ├───dll
│ └───sys
├───usa
├───winnt32
│ ├───dll
│ └───exe
└───wpc

example:
copy winmine.dbg & winmine.pdb in favor of winmine.exe into directory C:\WINNT\system32\Symbols\exe

Lord_looser i can copy all those .pdb and .dbg files one by one into ollydbg folder itself and they work fine without any patch etc
that way it doesnt need the symsrv.dll and doesnt need to download
anything it would use the files that was fetched by windbg without problems
i was loking for a some way which uses the functionality automatically

but it seems i have dig a litle more
with the above patch olly just seems to find the same symbols that are already available in view names and just embeds them in the .udd file
and updates the log window with a message saying
debugging info available in microsoft format
if i use view names i just see a duplicate list of same names
but the title says Library instead of Export

and the disassembly details are certainly different than with windbg
after posting the first post
i made a concurrent session with windbg and ollydbg at the same time
and olly didnt load the symbols so it is back to square one
for now

Hi,


and olly didnt load the symbols so it is back to square one
for now


thats what i tried to tell in initial post ... i debugged ollydbg itself in that case, verifying its use of dbghlp api - it doesnt work the way one would expect (sym init sequences, sym api queries) ;(

I guess we have to wait til V2 to see if situation improved.

Regards

Dear Focht,
Greets ,
a little more pestering form me
hope you get some time to check it up


it seems after DBGHELP.dll sets the symsearchpath to default
_nt_symbol_path + _nt_alt_symbolpath+ systemroot coz olly pushes
0 to syminitialize
olly sets the symsearchpath again to just the exe directory
which just overrides the default searchpath

so i kinda patched olly again not to set the default search path
this patch below skips the msvcrt_fnmerge() and SymSetSearchPath()
004911EC . /EB 2E JMP SHORT OLLmodsy.0049121C

this now successfully fetches the symbols but works kinda too slow to my liking (syn_sent for all plugins and failing to fetch the dbg and pdb files for all the plugins that are loaded makes it too slow at the starting
like ida analysis you run the exe and go have a coffee,get your lungs polluted a little and then gossip with the receptionist piss off and come back and you will still find it thinking
but that may be because i compare ollydbg on ollydbg on debugges time
i suppose it wouldnt be the same case in ollydbg on debuggee
anyway i dint check

anyway focht would you please check it out and tell if this works or it creates some other problems ???

my latest patches

C:\TC\odbg110>fc ollydbg.exe ollmodsym.exe

Comparing files OLLYDBG.EXE and OLLMODSYM.EXE
00090709: 10 37
0009070A: 12 02
0009070B: 00 03
0009070C: 00 80
000907EC: 74 EB

C:\TC\odbg110>

1)for .symopt i use 80030237 (windbgs default+ !sym noisy + !sym on)
and the patch at 907ec is to jump directly without setting the symsearchpath()

2) symsrv.dll dbghelp.dll and srcsrv.dll in ollydbg directory

without srcsrv.dll initialized files with source dont work i think
didnt check it (but if there is srcsrv in ollydbg directory
i see it getting initialised so it is a better option in my opininion to put it there

3)_nt_symbol_path == symsrv blah blah (default of livekd) which points to c:\symbols in my case

call stack shows this for icztutes\03 == win.exe

Procedure / arguments
? USER32.NtUserFindExistingCursorIcon (doesnt exist in plain )
Arg1 = 0012FCBC
Arg2 = 0012FCCC
Arg3 = 0012FF04
? USER32.FindExistingCursorIcon (doesnt exist in plain)
Arg1 = 77E69318
Arg2 = 00007F00
Arg3 = 0012FF04
USER32.LoadIcoCur
Arg1 = 77E10000
Arg2 = 00007F00
Arg3 = 00000003
Arg4 = 00000000
Arg5 = 00000000
Arg6 = 00008040
USER32.LoadIconW
hInst = NULL
RsrcName = IDI_APPLICATION
<JMP.&USER32.LoadIconA>
hInst = NULL
RsrcName = IDI_APPLICATION
WIN.00401031
Arg1 = 00400000
Arg2 = 00000000
Arg3 = 00132330 ASCII ""C:&#92;masm32&#92;ICZTUTES&#92;TUTE03&#92;WIN.EXE""
Arg4 = 0000000A
0012FFC4 77E87903 Maybe WIN.<ModuleEntryPoint>


in names window i see

lot of xxx names
Names in USER32, item 3297
Address=77E357AD
Section=.text
Type=Library
Name=xxxCBSizeHandler

Names in ntdll, item 1581
Address=77FB0BB8
Section=.text
Type=Library
Name=RtlpDebugPageHeapSearchAvailableMemListForBestFit

Names in GDI32, item 2277
Address=77F49758
Section=.text
Type=Library
Name=vOutlineTextMetricWToOutlineTextMetricA


Names in RPCRT4, item 3623
Address=77D41E7B
Section=.text
Type=Library
Name=TransportProtocol::SetStateToLoadedAndMonitorProtocolIfNecessary



Names in ADVAPI32, item 1005
Address=77DB1200
Section=.text
Type=Library
Name=_imp__NtAccessCheckByTypeResultListAndAuditAlarmByHandle

hope you could point out some problems with using the above patch
and confirm if it really works the way it should work
i normally dont work with symbols so i cant say if there are problems

i saw some access violation in dbghelp.dll during
SymLoadModule() but after trying to ascertain causes i couldnt find some thing credible so uses add last exception and it seems to wrok well
any comments corrections problems are welcome


thanks and regards

Hello,

actually i'm very pleased
I applied your patch and voila symbol server setup works as expected.

2) symsrv.dll dbghelp.dll and srcsrv.dll in ollydbg directory

Yes i already had them there, copied from latest windbg package ("debugging tools for windows" which is quite nice itself.
Windbg is steady getting better over time...

nt_symbol_path == symsrv blah blah (default of livekd) which points to c:&#92;symbols in my case

Yes, mine is similar:

_NT_SYMBOL_PATH=symsrv*symsrv.dll*e:&#92;symbols*http://msdl.microsoft.com /download/symbols

hope you could point out some problems with using the above patch
and confirm if it really works the way it should work
i normally dont work with symbols so i cant say if there are problems


As i said above .. it seems to work.
I have a local web proxy and can watch symbol server queries going out for missing/mismatched pdb's.

i saw some access violation in dbghelp.dll during
SymLoadModule() but after trying to ascertain causes i couldnt find some thing credible so uses add last exception and it seems to wrok well
any comments corrections problems are welcome


Didnt see any here (all exceptions unchecked, loaded ollydbg in ollydbg and simple debuggee).

Its a very useful patch because variable names/data structures in usermode system dlls are now displayed correctly (though not as good as IDA does but well ... )

Nice work.

Regards

Dear Focht,

thanks for confirming that it work as expected did you load any debuggee
that has source files and tried to look if sources load too properly
i mean .pdb files of compiled exes in a complex project that has its
.pdb .dbg .map files in some of thier default directories
does the srcsrv.dll find them properly

ida also identifies flirt signatures as far as i know so it may be showing some more details but i think godup plugin can also load the
flirt signatures from ida signatures

anyway i put ollydbg on ida and created a map file and converted that map file by mapconv plugin that is how i found out that the call above is
fnmerge()


the access violation i am talking about happens here in dbghelp.dll

Log data, item 0
Address=0283BCEE
Message=Access violation when reading [00000011]

disassembly window
0283BCEE MOVZX EAX, WORD PTR DS:[EDX+12]

edx+12 ==

DS:[00000011]=???
EAX=0620A2AC


callstack
Call stack of main thread, item 0
Address=0012ABDC
Stack=0283A74D
Procedure / arguments=DBGHELP.0283AEC0
Called from=DBGHELP.0283A748
Frame=0012ABD8

this violation may be because i was using the unpatched ollydbg on patched ollydbg but it would be better if some one independantly
corraborates the result

also did you try changing the symbolpath to come new directory
and see if ollyfetches it on its own ?? and also extracts the .pd_files
to.pdb files etc

ill check these points but it would be better if i get a corraborated
results so that i can concentrate on patching it more

Thanks and Regards