News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

About debuggers

Started by felipe, July 17, 2017, 03:09:42 PM

Previous topic - Next topic

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.
:biggrin:


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   :greensml:



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.
I'd rather be this ambulant metamorphosis than to have that old opinion about everything

jj2007

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

Quote from: jj2007 on July 17, 2017, 04:45:36 PM
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

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

felipe

Quote from: aw27 on July 17, 2017, 10:34:40 PM
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   :greensml:

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:

Sxd bpe;
bp $exentry;
g;


and the command line:

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

felipe

Quote from: jj2007 on July 17, 2017, 11:51:14 PM

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.  :bgrin:

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

aw27

Quote from: felipe on July 18, 2017, 05:48:33 AM
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.
Are you pondering what I'm pondering? It's time to take over the world ! - let's use ASSEMBLY...

felipe

Quote from: aw27 on July 18, 2017, 03:14:45 PM
Quote from: felipe on July 18, 2017, 05:48:33 AM
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!  :bgrin:

felipe

Quote from: Raistlin on July 18, 2017, 03:23:36 PM
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

Quote from: felipe on July 18, 2017, 03:40:44 PM
i will actually try now the windbg too!  :bgrin:

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

Quote from: Raistlin on July 18, 2017, 03:23:36 PM
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++.  :badgrin: