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:
Just go to Olly's options/options/debugging/start
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:
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.
As meneiro wrote, an int 3 is a good way to start debugging - see Integrated Debugging (http://masm32.com/board/index.php?topic=5314.msg63302#msg63302)
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.
:greenclp: Great help from you guys, thank you very much. :icon14:
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
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:
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.
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.
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:
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. ;)
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:
OllyDbg does a brilliant job, especially if you know how to create symbols.
In practice, however, I use 90% deb (http://www.webalice.it/jj2006/MasmBasicQuickReference.htm#Mb1019) in the console, and only if I get really stuck, I put that int 3 and launch Olly.
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 (https://scriptbucket.wordpress.com/2011/10/19/setting-up-visual-studio-10-for-masm32-programming/)
I just don't use it that much because I am addicted to Notepad++. :badgrin:
Btw, for those interested in the x32dbg debugger: Once the program is loaded with this debugger, with f10 key will go to the entry point of the program being debugged. :t
'Abandonware' can also be dangerous, researchers find (https://www.itwire.com/security/75163-abandonware-can-also-be-dangerous,-researchers-find.html)
According to the article, which is full of half-truths :biggrin:, the danger is not Olly itself but rather an obscure StrongOD plugin that 'calls home'.
QuoteOllyDBG is a 32-bit assembly level analysing debugger for Windows. Written by Oleh Yuschuk in 2000, the source code for this tool was bought between 2004 ad 2008 by the security company Immunity which is headed by Dave Aitel, an ace security pro who has worked for the NSA. Aitel included it in his company's Immunity Debugger.
...
The class of person who would use OllyDBG were roughly grouped into malware reverse engineers, defensive researchers, students, academic researchers, malware authors, DRM crackers and offensive researchers.
I guess that 'offensive researcher' fits best for myself :icon_mrgreen:
For your offensives do you use Olly 1.1 or 2? I tried both ages ago and found 1.1 better but can't remember now the reasons.
Olly 2, normally. It seems better and more stable. The only drawback is that it can't handle local symbols.
Thanks. :t
dear felippe
im going to give you some advice that differs from those offered . its not better or worse as like many things in life its experience and preference .
I dont use a debugger such as Olly or Ida Free which i think is very good in a visual way and are marvelous products by very very clever people.
They do however cloud the issue . No debugger is going to make your program work properly if you want your program to work properly ...
1) take a little time out and think clearly how you are going to structure your program. There are bound to be some tricky bits in there and its often useful
to either draw up a diagram outlining the rough flow of the program. I have seen innumerable often very experienced people trying to correct large programs because they
got the design wrong in the first place ... usually for the reason stated above
2) if you are writing the same type of program often then take a bit of time to make a skeleton program as exampled by the many fine tutorials you have probably seen amalgamating th things you might use into a series of test beds .. this gets both easier [ and deceptively worse for reason 1) above] as you get more of them so always be prepared to archive things
3) it is very easy to put a series of message boxes and a list box into your program that will display both the data areas and the memory .. also by displaying the offset of the
name of your presumably invoked procedures you will know exactly where you are [use dw to hex so you can find the place should you wish to view the exe running without converting dec to hex etc ...]
4) always put a lot of comments next to the lines of code you create ... you have no idea how easy it is to forget what you were trying to do ... i notice that comments in code are sparse in things ive downloaded
5) try and make regular backups relabeling the code as working at a particular date as you go ..also back them onto another media such as a dvd occasionally its very easy to screw up a large anc complex program especially if you are copying bits in from elsewhere ...
6) its very difficult to test your own programs thats because you wrote them and you know what they should do .. assumption is the enemy of sound thought .. so you need to try and plan your testing so that you test the main features first I have worked with people much more careful and thorough than myself who looked at many of the branches in a program and drew up elaborate test plans accordingly ... if youve got a punctillious friend like that certainly trust them to help you test your program
You also asked about the junk in your program that enables it to run ... this is going to have to be very brief ..
There are 4 or 5 variants on the type of program a loader will run in the MS op system briefly the program must begin MZ .. remove this and it will think youve got either a non std or ancient dos program [ ie not 32 or 64 bit] the bit that follows the MZ used to be used as as whats termed a STUB .. When your op sys Win 7-10??? loads it uses a boot loader which uses a small program to put the image onto the computer .. Your program has a series of locations which are known to this loader program [CMD.EXE is an example of a loader] these are found after the original STUB and you will find an indication of its location if you look at the prpgram in a hex viewer or OLLY after some text which says "this program cannot be run in Dos" ... at hex d8 [ie 14 lines on most hexed down ] is a very visible PE ... there are at least three variants on this [LE NE being 2] that indicate to the loader what its got to do to enable the environment to run the program .Each of these is different ... Iczhelion did a very good series of tutorials on some of the structures in a PE [your sort of program} as has Mikl who did the 64 bit tutorials .. the original descriptions are those of the legendary Matt Pietrek at this site https://msdn.microsoft.com/en-us/library/ms809762.aspx
Once the loader has established where the relevant parts of your code are it then begins to make the image in storage ... this does not mean it resides either in the processor or even on the thin sticks you call memory necessarily. The software running on th computer has to run a lot more programs than just yours For a start it has to be resident itself as well as looking to see what messages are coming in from keyboards , mice etc . It tries to use as little processing resource as it can to best effect . Over the years this has resulted in an elaborate scheme of bringing data in and out from subsidiary areas considered part of the main cpu called cache [read buffer ] , and various paging schemes which are divisions of memory or disk space of a suitable size to make them large enough to bring in a lot of information [code and data] .. and small enough that moving the information doesnt take too long or has to be done unnecessarily often. The page size on my machines is 4k the internal caches smaller .. The speed and frequency with which this happens is mind boggling ... .. to return to your program .. as you see it in storage is not as it was when it was loaded .. the paging compromises the load of most programs such that if you saved the image it would not subsequently run on the computer .. realignment to make the program fit into neat pages causes the insertion of cavities and the MS OP wisely has checks on the consistency of the image
.... so when you asked your question there was quite a lot of information there most of which i expect you already know
regards mike b
ps this was written quickly and off the top of my head disregarding rule 1)