debugging CRT startup code in OllyDbg

Hello, gentlemen!
I wonder if somebody would be kind enough to explain how to step through startup code of VC++ program in OllyDbg.
I am particularly interested in exploring the area around

0012f828 780011b3 msvcrt!__CxxSetUnhandledExceptionFilter+0xb

but do not know how to do that in OllyDbg 1.10.

xxxxx@aol.com wrote:

Hello, gentlemen!
I wonder if somebody would be kind enough to explain how to step through startup code of VC++ program in OllyDbg.
I am particularly interested in exploring the area around

0012f828 780011b3 msvcrt!__CxxSetUnhandledExceptionFilter+0xb

but do not know how to do that in OllyDbg 1.10.

Odd that you would ask this in a Windbg forum.

You can certainly set a breakpoint at that address (Ctrl-G to enter the
address, F2 to toggle breakpoint), then single step once you get there.
However, you aren’t going to find very much of interest there. All it
does is forward immediately to SetUnhandledExceptionFilter in kernel32.

What leads you to wonder about this?


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Tim, thanks for your answer!

Odd that you would ask this in a Windbg forum.
– Yes, this is true.
What leads you to wonder about this?
Pretty much pure curiosity. I used !__CxxSetUnhandledExceptionFilter just as an example.
But in reality I’d like to step through the whole start up code and see what happens there. So if I did not know the address, how would I do that in Olly?

xxxxx@aol.com wrote:

> What leads you to wonder about this?
Pretty much pure curiosity. I used !__CxxSetUnhandledExceptionFilter just as an example.
But in reality I’d like to step through the whole start up code and see what happens there. So if I did not know the address, how would I do that in Olly?

Ollydbg starts up pointing at the C runtime entry point, because that’s
the first byte of code that your process executes. Just start
single-stepping.

Remember that you have the source code for most of the C runtime
library, including the startup code, in your Visual Studio directory, in
vc\crt\src. Look for “crt0.c”.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Is there an easy way to identify a point where my program gets control (a call to WinMain or main) in Olly? Because I cannot find it…
Also, I put BP at kernel32.SetUnhandledExceptionFilter, which I expected to be called by the start up code, but this BP is never hit and this call is not referenced…

> Odd that you would ask this in a Windbg forum.

Not that odd, given that all (items 2-3 in below list) of OllyDbg
support sites are offline.

Even the support forum for ImmyDbg, Immunity Debugger, the GPL fork of
OllyDbg, is offline.

To the OP, I’d suggest asking on StackExchange. AFAIK, that’s the only
active support mechanism for OllyDbg.
http://stackoverflow.com/questions/tagged/ollydbg

Or try asking Olly, like he mentions in his FAQ (below).

Or read the ImmyDbg source code, as it is available.

Or switch to a debugger with an active community. :slight_smile:

From the OllyDbg FAQ:
----snip----
Do you have any questions concerning OllyDbg? There are at leas four
good possibilities to get an answer:

Ask the author, Oleh Yuschuk (also known as Olly) at
xxxxx@t-online.de. Usually, I answer your mails within 1-3 days.
Visit OllyDbg forum at http://ollydbg.win32asmcommunity.net. This
forum is created and moderated by TBD.
If you speak Spanish, send your question to spanish OllyDbg board
at http://ollydbg.cjb.net, moderated by uNO mAS.
Create your own newsgroup :slight_smile:

Uh-oh, how many times have I promised to update this list? Enough, no
more promises!
----snip----

xxxxx@aol.com wrote:

Is there an easy way to identify a point where my program gets control (a call to WinMain or main) in Olly? Because I cannot find it…

Part of the problem with OllyDbg is that it doesn’t recognize
Microsoft’s symbol files, so it can’t find your main or WinMain without
outside help. In a C program, main is usually first, and so will be
located at 0x401000. Alternatively, you can generate a link map (using
the /map switch) and look for main or WinMain there.

Or, you could use WinDbg, which is free…


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Thanks a lot, Tim! You’ve been of really great help!
Best regards, David.

I have seen very few C programs where main() is first. It usually starts
out being last, to avoid having to do forward declarations to all the
functions it calls, and in general the call tree is flattened out to avoid
any forward declarations at all, so the root, main, is almost always at
the end.

I find it odd that it doesn’t use the symbol libraries which are part of
the Windows SDK.
joe

xxxxx@aol.com wrote:
> Is there an easy way to identify a point where my program gets control
> (a call to WinMain or main) in Olly? Because I cannot find it…

Part of the problem with OllyDbg is that it doesn’t recognize
Microsoft’s symbol files, so it can’t find your main or WinMain without
outside help. In a C program, main is usually first, and so will be
located at 0x401000. Alternatively, you can generate a link map (using
the /map switch) and look for main or WinMain there.

Or, you could use WinDbg, which is free…


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.


WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

xxxxx@flounder.com wrote:

I find it odd that it doesn’t use the symbol libraries which are part of
the Windows SDK.

Well, it was written in Borland C++ by a Borland fanatic. It
understands Borland’s symbol format. There is a symbol converter
available, but it’s inconvenient. Now that Windbg has grown so much
better, I don’t run Olly any more.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

On 7/31/12, Lee Fisher wrote:

> Not that odd, given that all (items 2-3 in below list) of OllyDbg
> support sites are offline.
> Visit OllyDbg forum at http://ollydbg.win32asmcommunity.net. This
> forum is created and moderated by TBD.

the above forum is relocated to

http://www.woodmann.com/forum/forumdisplay.php?37-OllyDbg-Support-Forums

you can try asking your ollydbg question here

@ David

ollydbg usually knows the WinMainCrtStartup

check out where ollydbg is configured to make its first pause

alt+o -> events tab

if system breakpoint is configured

or you can normally land at WinmainCrtStartup() if you set up a
conditional breakpoint BreakPoint @ ntdll!ZwContinue

Log data, item 0
Address=7C90120E
Message=System startup breakpoint

Breakpoints, item 1
Address=7C90D05E ntdll.ZwContinue
Module=ntdll
Disassembly=MOV EAX,20

use shift+f4 (conditonal log bp ) and pause this command to plugin
when paused on
.bp [[esp+4]+0xb8] (note teh dot in front) esp+4 is pointer to context
0xb8 is eip setting a bp at ie (ntdll!_context->Eip) when paused on
ntdll!ZwContinue

this will lead you to which will contain an indirect call to WinMainCrtStartup

Log data, item 0
Address=7C810705
Message=Breakpoint at kernel32.BaseProcessStartThunk

7C817074 |. FF55 08 CALL DWORD PTR [EBP+8] ; VC8TEST.

EDI=7C910228 (ntdll.7C910228)
crtexe.c:393.

from here you can utilize run trace logging too which will log all the
instruction executed to a file which you can view at leisure to
understand all that hppens in crt init stage

ollydbg also can load ms pdb files (with 1.10 you need a plugin like
loadpdb with v 2 support is inbuilt

raj r writes:

“use shift+f4 (conditonal log bp ) and pause this command to plugin
when paused on…”

Could you please explain what plugin you are talking about?

ollydbg 1.10 package comes along with two default plugins
1)bookmark plugin
2)commandline plugin

you can invoke commandline plugin in ollydbg with alt+f1 shortcut
this command line plugin has this callback implemented

// OllyDbg calls this optional function each time the execution is paused on
// breakpoint with attached list of commands, separately for each command.
// Function must return 1 if command is processed (in this case it will not
// be passed to other plugins) and 0 otherwise.
extc int _export cdecl ODBG_Plugincmd(int reason,t_reg *reg,char *cmd) {
char answer[TEXTLEN];
// Command-line plugin accepts only commands that start with point (.)
if (cmd==NULL || cmd[0]!=‘.’ || cmd[1]==‘\0’)

so if you pass .bp [[esp+4]+0xb8] in the dialog box which pops up on
shift+f4 (notice dot in front)

ollydbg will automatically set a bp on kernel32!BaseProcessStartThunk()

for example windbgs .apply_dbp (apply data breakpoint command ) does
something similar
on context Switch _ on createprocess

setting a bp like this in ollydbg is equivalent to this in windbg
syntax without the pc 3 at the end

0:000> bu ntdll!ZwContinue “bu @@C++(((ntdll!_CONTEXT *)@@masm(
(poi(@esp+4) )))->Eip) "bl;pc 3";g;”

0:000> bl
0 e 7c90d05e 0001 (0001) 0:**** ntdll!NtContinue “bu
@@C++(((ntdll!_CONTEXT *)@@masm( (poi(@esp+4) )))->Eip) "bl;pc
3";g;”

0:000> g
ModLoad: 76390000 763ad000 C:\WINDOWS\system32\IMM32.DLL

0 e 7c90d05e 0001 (0001) 0:**** ntdll!NtContinue “bu
@@C++(((ntdll!_CONTEXT *)@@masm( (poi(@esp+4) )))->Eip) "bl;pc
3";g;”

1 e 7c810705 0001 (0001) 0:**** kernel32!BaseProcessStartThunk “bl;pc 3”
kernel32!BaseProcessStart+0x7:

7c81705b e876b4feff call kernel32!_SEH_prolog (7c8024d6)
kernel32!BaseProcessStart+0x1a:

7c81706e ff15b013807c call dword ptr
[kernel32!_imp__NtSetInformationThread (7c8013b0)]
ds:0023:7c8013b0={ntdll!ZwSetInformationThread (7c90dcae)}

kernel32!BaseProcessStart+0x20:
7c817074 ff5508 call dword ptr [ebp+8]
ss:0023:0006fff8={windbg!wmainCRTStartup (01058c77)}

On 8/1/12, xxxxx@aol.com wrote:
> raj r writes:
>
> “use shift+f4 (conditonal log bp ) and pause this command to plugin
> when paused on…”
>
> Could you please explain what plugin you are talking about?
>
> —
> WINDBG is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

Ah, now it is clear! Thank you RAJ R!