About debuggers

[felipe]

Why debuggers like olly and dbg start the debug session of every program you load, with some sequence of instructions before the entry point of your program? What kind of code is that? I mean, i supose is windows code doing something, but doing what?
And it is possible to go directly to the entry point of the program loaded for debug, at the start of the debug session with those debuggers?  (I mean without the need of stepping until you find the entry point of your program).
I know i have to investigate by my own count (learn the debuger manuals) and i do, but i want to ask to you too, because one good way of learning is to go to more than one base of information.
Thanks.

[jj2007]

Just go to Olly's options/options/debugging/start

[aw27]

With Windbg:

Make a small script (a text file) like this:

Sxd bpe;
bp $exentry;
g;

Save it to a file called myFantasticScript.txt

Now, launch the application and when it stops the first time, paste the following on the command line and press enter:

$$>a< pathto\myFantasticScript.txt

With Windbg things are always easy   

[mineiro]

hello felipe;
You can insert at start of your source code instruction "int 3". This is a hint to debug do a stop on that place.
When you load your program inside debug you can type "go" and when breakpoint is reached debugger stops. So you need change instruction pointer (eip) to go to next byte or next address. Some debuggers do this automatic but others need be manual.

I forgot to say, remember to remove that breakpoints from source code while releasing your program.

[jj2007]

As meneiro wrote, an int 3 is a good way to start debugging - see Integrated Debugging

Just go to Olly's options/options/debugging/start

Among these options, there is also "No pause", meaning Olly jumps directly to the int 3 and stops.
My personal preference is "Entry point of main module", then I hit F9 to jump to the int 3.

[felipe]

  Great help from you guys, thank you very much.  :icon14:

[felipe]

With Windbg:

Make a small script (a text file) like this:

Sxd bpe;
bp $exentry;
g;

Save it to a file called myFantasticScript.txt

Now, launch the application and when it stops the first time, paste the following on the command line and press enter:

$$>a< pathto\myFantasticScript.txt

With Windbg things are always easy   

I do all that but windbg tells me that is an unknown command. :(  Why?
Here are the details:

The inside of the file  named dbgscript.txt:

Code Select Expand


Sxd bpe;
bp $exentry;
g;


and the command line:

Code Select Expand


$$>a< C:\Users\felipe\Desktop\dbgscript.txt


[felipe]

My personal preference is "Entry point of main module".

This did the job fine. Without an int 3 in the source, enabling this option in olly (or even the winmain option) and then the "Run" command from the menu, directs the debugger to the entry point of my program. 

I will see how to do it in windbg too, but if you know, you can tell me   .
Thanks again.  :icon14:

[aw27]

I do all that but windbg tells me that is an unknown command. :(  Why?

I don't know. 1st line disables first chance exceptions, 2nd line sets break point on entry point, 3rd line resumes running.  :idea: . All old and well known commands.

[Raistlin]

Being a novice (forever) on assembly language programming, I do however believe I have a reasonable feel for 32-bit
- BUT my education is lacking on the debugging side of the art.

I know the basics re: int3, step-in, step over, checking registers

ON the Other hand, I'am reasonably sure that a better use of the debugger would speed up development exponentially,
I wonder if there's an integrated debugging tutorial for assembly language anywhere or the obligatory
YouTube video series.

[felipe]

I do all that but windbg tells me that is an unknown command. :(  Why?

I don't know. 1st line disables first chance exceptions, 2nd line sets break point on entry point, 3rd line resumes running.  :idea: . All old and well known commands.

I'm sorry aw27, i just realized than windbg and x32dbg or x64dbg are two differents debuggers. :redface:
:lol:
Thanks anyway for your help, i will actually try now the windbg too! 

[felipe]

I wonder if there's an integrated debugging tutorial for assembly language anywhere or the obligatory
YouTube video series.

I think  that better than youtube series, would be to read the manuals of the debuggers and, also  see the assembly code they show. But i guess that is only my personal choice.  ;)

[aw27]

i will actually try now the windbg too! 

Beware, Windbg is not for the faint of heart.  :redface:

[jj2007]

OllyDbg does a brilliant job, especially if you know how to create symbols.

In practice, however, I use 90% deb in the console, and only if I get really stuck, I put that int 3 and launch Olly.

[aw27]

ON the Other hand, I'am reasonably sure that a better use of the debugger would speed up development exponentially,

Probably the best debugging experience can be achieved by developing Masm inside Visual Studio and profit from the excellent debugging it provides.
See here how to
I just don't use it that much because I am addicted to Notepad++.