About debuggers

[felipe]

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

[jj2007]

'Abandonware' can also be dangerous, researchers find

According to the article, which is full of half-truths , the danger is not Olly itself but rather an obscure StrongOD plugin that 'calls home'.

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

[aw27]

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.

[jj2007]

Olly 2, normally. It seems better and more stable. The only drawback is that it can't handle local symbols.

[aw27]

Thanks.  :t

[mikeburr]

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)