Why I see ntdll disassembly, not my assembly code in WinDbg? - debugging

Question

I want to analyze my first assembler program. Look at registers, execute step by step etc. It's for learning purposes.
I have a problem. Disassembly is strange. I can't find my code. I step through some ntdll functions. There is no my MessageBoxA, no ExitProcess etc.
I have used OllyDbg (32-bit) before and OllyDbg starts executing from normal entry of the program. Disassembly in OllyDbg was very similar to my MASM code.
What I am doing wrong? Why there is different disassembly? How to step through my code, not ntdll?

Answer 1

ollydbg interpreted the Address of Entry Point in the Pe Header and set a temporary BreakPoint and continued execution until that address Which Normally would be main if it was an assembler program or WinMainCrtStartup if it was compiler generated binary
Windbg will not do that it will stop at the system BreakPoint ( the default behavior of the Debug Apis)
you have two options
if it is your own assembler program and you have symbols for it
do
.reload /f
bp [your exe]![Your EntryPoint]
bl to confirm if it is right
g to continue execution and break in your code
if it is a third party program for which you do not have source
lmm [name of third party binary]
!dh [start address of the third party binary] ( see lm results to know the address)
look for Address of Entry Point
bp [start address of the third party binary] + [Address of entrypoint]
g
windbg will stop in the user code
a sample for method 2 on calc.exe under win7 sp1
0:000> lm m calc
start end module name
00210000 002d0000 calc (deferred)
0:000> !dh 210000
---------------------
12D6C address of entry point
0:000> bp 210000+12d6c
0:000> bl
0 e 00222d6c 0001 (0001) 0:**** calc!WinMainCRTStartup
0:000> g
calc!WinMainCRTStartup:
00222d6c e84bfdffff call calc!__security_init_cookie (00222abc)

Answer 2

Short answer: bu $exentry; g
Long answer:
A process starts its user mode execution in OS code found in ntdll which does all sorts of initialization and finally calls the entry point stored in the PE header.
WinDbg breaks in what's called the initial breakpoint (or ibp in WinDbg parlance). OllyDbg continues running after this breakpoint and sets a breakpoint on the PE entry point. That's nice, except when it screws you. For example, a well-known anti-debugging trick against olly was creating a binary with custom TLS callbacks, a rather esoteric feature. These callbacks are called before the PE entry point and thus go undetected by olly.
What you want to do is indeed set a breakpoint on the PE entry point.
The hard way is doing it like blabb did - using !dh to dump the module header and setting a breakpoint on the address noted there. Even the hard way can be a little easier, as there's no need to lm before running !dh. In WinDbg module names are interpreted at their base addresses. For example:
0:000> !dh -f notepad
File Type: EXECUTABLE IMAGE
FILE HEADER VALUES
14C machine (i386)
5 number of sections
55BEBE90 time date stamp Sun Aug 02 18:06:24 2015
...
OPTIONAL HEADER VALUES
10B magic #
12.10 linker version
15400 size of code
1F000 size of initialized data
0 size of uninitialized data
159F0 address of entry point
1000 base of code
And then it's simply a matter of:
0:000> bu notepad+159F0
0:000> bl
0 e 002259f0 0001 (0001) 0:**** notepad!WinMainCRTStartup
But the easy way is to use one of WinDbg's builtin pseudo-registers ("automatic pseudo-registers" is their term, in contrast to user-defined pseudo-registers), namely the aformentioned $exentry.
0:000> ? notepad + 159F0 == $exentry
Evaluate expression: 1 = 00000001
0:000> ? $exentry
Evaluate expression: 2251248 = 002259f0
You can see that 002259f0 is the same address as the one we calculated by hand.
For completeness I note that there's the $iment(address) operator that gives the entry point of any module, not just the main module (the EXE):
0:000> ? $iment(winspool)
Evaluate expression: 1889096272 = 70995250
0:000> ln $iment(winspool)
Browse module
Set bu breakpoint
(70995250) WINSPOOL!_DllMainCRTStartup | (7099526b) WINSPOOL!__CppXcptFilter
Exact matches:
WINSPOOL!_DllMainCRTStartup (<no parameter info>)