How to write a program in ollydbg. Basics of working with OllyDebug, using the example of “curing” an archiver
Introduction to cracking from scratch using OllyDbg - Chapter 1 - Archive WASM.RU
The purpose of this "Introduction to Cracking from Scratch Using OllyDbg" is to give those just beginning to master the art of cracking a basic knowledge, and at the same time, to do so in a way that this knowledge will allow them to later read and understand more advanced tutorials such as , which can be found in the “New Course from CracksLatinos”, which, of course, remains open to new additions and additions.
The idea for the course was born out of the fact that many of the tutorials in the New CracksLations Course were too difficult for beginners, and those who failed to reach the required level found themselves frustrated and in many cases, refused to continue. Therefore, the purpose of this “Introduction...” is not to repeat the excellent tutorials from the “New Course...”, the number of which has already exceeded 500, but to lay the foundation so that those who complete this course will be able to read more complex tutorials. This, like everything in our craft, requires considerable effort, and the main goal is to reduce this amount, providing basic knowledge and allowing further understanding of more complex material.
Why OLLYDBG?
We will not talk here about the eternal confrontation between Soft-Ice and OllyDbg; I think that even Soft-Ice fanatics admit that it is easier to start with OllyDbg, since there is a lot of information about it and it is easier to study. We need to enter the world of cracking through the door called "OllyDbg", and only then whoever needs it can switch to any other debugger that is required, since only their methods of use change, but the essence remains the same.
Start over
First you need to arm yourself with the tool that we are going to mainly use, for which click and download it.
Since we are starting from scratch, first we need to unpack the downloaded archive into a folder on your hard drive that can be easily reached. A good idea would be to create a folder on the C:/ drive. Although it will work in any other location, I will assume that the C:/ drive is selected.
After the file has been unpacked, go to the created folder and see:
It contains the executable file OLLYDBG.exe, which we need to run, and for which I made a shortcut on my desktop for convenience.
Ok, everything is ready to launch. Click on OllyDbg:
We see a message that the DLL located in the library is older than the same system DLL, and if we select “Yes”, then the old DLL will be erased from the folder, and the system one will be used. Although I don't see much difference between the two, I still prefer the one that comes with the distribution, so I always click "No".
This is pure OllyDbg, and the first program that we will open just to get acquainted with OllyDbg will be CrueHead’s famous CrackMe, which is attached to this tutorial.
To open a file in OllyDbg, go to File -> Open or click on the icon:
A window will open with which you can find the desired file, in this case it is CrueHead’s crackme.
The above-mentioned crackme will open, and at the moment it does not matter that it is completely unclear what the view that opens to us means - for now we will just go through the various parts and functions of OllyDbg and some settings, so that when in subsequent tutorials it says, say, “go to DUMP”, you at least knew where this option was.
Here we will look at the four parts of the OllyDbg main window:
1) Disassembled code
Also called listing. Here Ollie shows us the disassembled code of the program we are going to debug; By default, Ollie is configured to analyze the program when it is opened. This can be changed in Options -> DEBUGGING OPTIONS.
That is, if the “AUTO START ANALISIS OF MAIN MODULE” checkbox is checked, OllyDbg will analyze the program and show additional information about it.
This is the beginning of CrueHead's parsed crack listing, and if we open it without parsing, we can see the difference.
The analysis window contains a lot of information, which, despite the fact that it is not very clear to us yet, looks very interesting. At the same time, it’s nice to know that you can remove it at any time if the analysis turns out to be not very accurate or if some error has crept into it.
Often OllyDbg displays some parts of the program incorrectly because it mistakenly interprets the executable code as data, and then it displays something like this:
In this case, you can manually remove the analysis by right-clicking on the listing and selecting “ANALISIS -> REMOVE ANALYSIS FROM MODULE”.
And then the listing will be displayed correctly.
Another option that you can use to make things easier and which I personally don’t really like (but tastes vary) is jump and call highlighting - right-click on the listing and select “APPEARENCE -> HIGHLIGHTING - > JUMPS AND CALLS.”
You will get the following:
Here we see that calls are highlighted in azure, and transitions are highlighted in yellow.
The listing is now more readable, but we have no idea what that means yet, but it's good to have the tool ready for future use.
2) Registers
The second important window is the register window.
Recall that the register window is on the very right side of OllyDbg, and there is a significant amount of information displayed there.
There is much more information that we do not see, but you can set the display mode to three states (“VIEW FPU REGISTERS” – display FPU registers, “VIEW 3D NOW REGISTERS” – display “3D NOW” registers and “VIEW DEBUG REGISTERS” – display debug registers). By default, the first ones are displayed.
3) Stack or heap
Now let's move on to the “stack or heap”. There aren't too many configuration options here, other than the ability to display information regarding the ESP and EBP registers.
By default, the mode for displaying information related to ESP (and it is also the most useful), but it can be changed to the mode for displaying information related to EBP, for which you need to right-click in this window and select “GO TO EBP” , and further use of the “GO TO ESP” item will return us to the previous mode.
I'll explain the functionality of the stack in more detail in later chapters, but for now we'll only cover what can be changed through configuration.
4) Dump
The dump window has many display modes that can be changed by right-clicking in the dump window and selecting the one you need. The default mode is 8-byte Hex/ASCII.
The default mode is also the one most often used, but at the same time, we have the ability to change it to display disassembled code (DISASSEMBLE), text (TEXT) and other formats (SHORT, LONG, FLOAT).
And finally, the SPECIAL -> PE HEADER option, which, as we will see in the coming chapters, can be very useful.
Now we know the main parts of the OllyDbg main window, but there are also windows that are not directly accessible, but can be called either through the menu or through buttons on the control panel.
Let's look at each of them.
The L button or VIEW->LOG shows us what OllyDbg writes in the log window. It can be configured to display various types of information, and by default the log window stores all startup information, as well as information related to BREAKPOINTS CONDICIONAL LOGS. We will meet the latter much later, but for now let’s look at information about the running process (in our case, this is CrueHead’s crack) and the libraries that it loads.
One of the most important options in this window is logging to a file in case we want to save information in a text file. To activate this option, right-click and select "LOG TO FILE".
Button E or VIEW->EXECUTABLES shows us a list of modules that the program uses: exe, dll, ocx and others.
Here, too, the right mouse button brings up many options that we will not look at for now, but which we have already seen when exploring the main OllyDbg window.
The M or VIEW->MEMORY button displays the memory occupied by our program. Here we see sections of the application, libraries used by the process, the stack and various sections occupied by the system, and often programs occupy new sections of memory during execution.
By right-clicking, we can do a SEARCH in memory to find strings of various kinds (text, hexadecimal, unicode), there is also the ability to highlight breakpoints in sections, as well as the ability to change access rights to the latter (select SET ACCESS).
Button T or VIEW->THREADS shows us a list of threads (threads) of the program.
Although now we do not know what it is, and we will find out only in subsequent chapters, it will not be superfluous to familiarize yourself with each of the windows. We will learn how to use them later.
The W or VIEW->WINDOWS button displays the program windows, but since it is not running yet, the list of windows remains empty.
Button H or VIEW->HANDLES displays handles, later I will explain what they do.
Button C or VIEW->CPU returns us to the main OllyDbg window.
Button / or VIEW->PATCHES shows a list of applied patches if the program has been changed. Since no changes have been made yet, the window remains blank for now.
The K button or VIEW->CALL STACK displays the “call stack”, a list of calls that we have encountered up to the point where the program stopped.
Button B or VIEW->BREAKPOINTS brings up a list of normal breakpoints located in the program. There are no hardware breakpoints or memory breakpoints, just regular ones.
The R button or VIEW->REFERENCES shows a window of references that we received as a result of searching for references in Ollie.
The “…” or VIEW->RUN TRACE button displays the result of the RUN TRACE command. Here we can also select the LOG TO FILE option to save the trace results in a text file.
We've covered the panel with the most important buttons so that you'll be familiar with the capabilities they provide as we begin to delve deeper into them in later chapters.
How to configure OllyDbg to become JIT (JUST IN TIME DEBUGGER)
Of course, we will not use JIT all the time, but only in special cases, since if an error occurs with any running program on our machine, then we do not need Ollie to be used at all (by default, dr.watson is used as JIT ).
To make OllyDbg a JIT debugger, you need to go to OPTIONS->JUST IN TIME DEBUGGING
and press the MAKE OLLYDBG JUST IN TIME DEBUGGER and DONE buttons in sequence
To remove this function, you need to click on RESTORE JUST IN TIME DEBUGGER and DONE in the same place.
Connecting plugins in OllyDbg
OllyDbg allows you to connect plugins that may be useful for solving a particular problem. For now, we will limit ourselves to connecting the COMMAND BAR plugin to learn how to do this.
Download this plugin from here (the link indicated in the original article is dead, so I downloaded the plugin from the Internet and posted it on wasm.ru - approx.).
After that, unpack the plugin and look at the contents of the folder where this was done:
First of all, you need to create a folder for plugins. I'll create it in C:/ and call it PLUGINS.
Of course, plugins can be located anywhere, but I like to host everything in C. Anyway, now we need to configure OllyDbg so that it recognizes this folder as the location of all plugins.
To do this, go to OPTIONS->APPEARANCE.
And in the window that opens, open the DIRECTORIES tab.
We see that the path to the plugins is the directory where OllyDbg.exe itself is located, and we could put the plugins there, but I like to keep them separate, and then click on PLAGIN PATH->BROWSE to find the folder we created.
Select the PLUGINS folder and save the changes.
That is, you need to restart Ollie so that it recognizes the new folder with plugins, but first you need to copy the last downloaded plugin to it.
Copy the entire contents of the archive to the PLUGINS folder.
Now all the files of the “Command Bar” plugin are located in the PLUGINS folder, and the rest should also be placed in it (often you can copy not all the files in the archive, but only the dll).
Now close OllyDbg, if it was still closed, and launch it again. We see that the COMMAND BAR and its options have appeared in the PLUGINS menu.
At the bottom of OllyDbg we see the installed COMMAND BAR.
This is a text field for entering commands that can be useful to us in many cases, and later we will see their use, but for now it is important to learn how to connect plugins.
To uninstall PLUGIN, simply erase the corresponding dll from the PLUGINS folder and restart OllyDbg, and the plugin will disappear. However, it is prudent to always keep the COMMAND BAR on.
Let's open CrueHead's crack again in OllyDbg.
The most useful keys in OllyDbg are:
F7: Executes one line of code (if we are on CALL, then go inside the called section of code)
F8: Executes one line of code (if we are on a CALL, it simply executes the call without going inside and moves to the next line after the CALL).
These two types of manual tracing are very different and in what cases to use each of them we will consider later.
F2: Sets a normal breakpoint on the marked line. To remove this breakpoint, press F2 again.
For example:
We want to set the installation point at position 40101A, so we mark this line with the mouse.
With one click of the mouse it is marked and becomes gray as in the picture. Then press F2.
We see that the corresponding position in the first column turns red, which indicates that there is a breakpoint here. By pressing F2 again you can remove it.
F9: Runs a program that will run until it hits a breakpoint, throws an exception, or simply stops running for some reason. When the program is running, the word RUNNING is displayed in the lower right corner of OllyDbg.
When we launch CrueHead's crack, we will see the following:
To temporarily stop running the program, press F12 or DEBUG->PAUSE.
We see that OllyDbg displays the word PAUSED. You can continue running the program by pressing F9 or DEBUG->RUN.
To close the program being debugged, select DEBUG->CLOSE.
This has been a quick overview of OllyDbg, and we will continue to explore its many options and capabilities in more depth in subsequent chapters. The main thing is that you download the program, configure it, look again at everything that was discussed in this tutorial, also connect the plugin, start and stop CrueHead's crack, try to set breakpoints so that in the next chapter all these things do not cause problems. you hesitation and doubt. Ricardo Narvaja, trans. Aquila
Sandbox
new player January 7, 2016 at 01:36 pmBasics of working with OllyDebug, using the example of “curing” an archiver
- Assembler
Today I’ll show you how you can use “Olka” to “cure” one famous archiver. For this we need: OllyDBG, “CommandBar” plugin.
We install the archiver, after 40 days we see the picture:
The first thing that comes to mind is to change the license check or the check for the duration of use of the program. Let's take the easy way - look for a WinAPI function that receives the current GetLocalTime. In the context menu select
Search for -> Name (label) in current module.
We are looking for functions related to time, oh, there it is, we almost missed it.
Now you need to set a breakpoint on this function. In the CommandBar plugin window, enter
and now when we call this function, our debugger will stop at the place we need.
We start debugging, key F9. Our breakpoint was successfully executed and we found ourselves at the beginning of the GetLocalTime function, let's get to the exit point from this function (Ctr+F9), take one step (F7). Here we see that after receiving the time, the function at address 004B8C00 is called, I suggest you go into it and see what might be interesting there, we use the step with entry (F7).
We see favorable signs.
We trace the program through F8, before checking at address 004B8C26, observe TEST AL,AL.
Let me remind you that AL is the low register of EAX, we have it empty now. The TEST AL,AL command checks whether the AL register is equal to zero, if it is equal, then the ZF flag will be turned on. The next command JE SHORT 004B8C44, sends to address 004B8C44, if the ZF flag is turned on. Well, I propose to remove this transition check. Press the spacebar and enter nop, press Assemble several times until these two commands are worn out.
We start debugging (F9) and see that we have stopped at our breakpoint again, let's remove it (F2) and continue debugging again (F9). Now we see that nothing prevents us from working and in the registration field there is an inscription saying that the program is registered.
Tags: Reverse engineering, Assembler, OllyDebug
This article is not subject to comment, since its author is not yet a full member of the community. You will be able to contact the author only after he receives
OllyDbg is a 32-bit debugger that has achieved great popularity, which is used by beginners studying assembly language and fierce hackers for the sake of an idea and scoundrels to create new strains of computer viruses. This is a convenient and multifunctional tool for analyzing and modifying files compiled into machine code. With OllyDbg it is possible to hack a program, and vice versa - to improve protection against software hacking. When the source code is not available, the program can be disassembled and analyzed on the fly. The code analyzer implemented in the debugger recognizes procedures, constants, loops, tables, text and branches.
Debugger disassembler
OllyDbg recognizes and decodes over 2000 C language and Windows API functions. The debugger supports connecting additional plugins, performs heuristic analysis of the stack, works in step-by-step debugging mode, supports hex, ASCII, Unicode, 16/32 bit integers and 32/64/80 bit floating point numbers. A debugger with a simple and intuitive interface, code highlighting, great capabilities and open source.
Distribution composition
Catalog OllyDbg110 - distribution downloaded from the program website
Catalog OllyDbgHelpRus - official help for the OllyDbg debugger translated into Russian. Taken from the site http://cracklab.ru/
2. Description of the program (taken from the Help for the program)
OllyDbg- 32-bit debugger that analyzes at the assembler level, with an intuitive interface. Particularly useful if the source code is not available or when you are experiencing problems with the compiler.
Requirements. Works under Windows 95, 98, ME, NT or 2000, XP (not 100% tested), on any Pentium class computer, but for easy debugging you will need at least a 300 MHz processor. OllyDbg is memory intensive. If you are going to use additional gadgets (plugins), I recommend 128 MB or more of RAM.
Supported processors: OllyDbg supports all 80x86, Pentium, MMX, 3DNow! , including Athlon, SSE commands and related data formats. But it doesn't support SSE2.
Setup. More than 100 options control the program's operation.
Data Formats. Dump windows display data in all common formats: HEX, ASCII, UNICODE, 16-bit and 32-bit integer/non-integer/hex, 32/64/80-bit floating point, addressing, disassembly (MASM, IDEAL or HLA), PE header or stream of a data block.
Reference. This file contains the basic information needed to understand and use Ollydbg. If you have Windows API help (win32.hlp, not included for copyright reasons), you can attach it and get instant help about system calls.
Launch the application. You can select the executable on the command line, select from a menu, drag the file into Ollydbg, restart the last program you were debugging, or join an already running application. Ollydbg supports ongoing debugging. No installation required, you can run Ollydbg from a floppy disk!
DebuggingDLL. With Ollydbg you can debug dynamic link libraries (DLLs). Ollydbg automatically launches a small executable file into which it loads the library and allows you to call it to export.
Debugging files with debugging information. Ollydbg reads debugging information in MICROSOFT and Borland formats. This information includes source code and names of functions, labels, global and static variables. Support for dynamic (stack) variables and structures is very limited.
Code highlighting. The disassembler can highlight different types of instructions (jumps, conditional jumps, stack pushing and popping, procedure calls, returns, privileged and invalid) and different operands (general, FPU/SSE or segment/system registers, memory operands on the stack or in other memory , constants). You can also create custom lighting patterns.
Streams. Ollydbg is capable of debugging multi-threaded applications. You can switch from one thread to another, pause, resume, kill threads, or change their priority. The Threads Window displays errors for each thread (eg return call to GetLastError).
Analysis. The analyzer is one of the most significant parts of OllyDbg. It recognizes procedures, loops, switches, tables, constants and strings embedded in code, complex constructs, API function calls, number of function parameters, import sections, and so on. Analysis makes binary code more readable, easier to debug, and reduces the likelihood of misinterpretations and failures. It is not compiler-specific and works equally well with any PE program. You can improve your analysis results by setting hints.
Object scanner. OllyDbg scans object modules (files) or libraries (both in OMF and COFF formats), extracts code, segments it and locates it in the program being debugged.
Scanner for imported libraries. Some DLLs export their symbols only as ordinals, which are not very readable to the human eye. If you have the appropriate import library, OllyDbg translates ordinals back into symbolic names.
Full UNICODE support. Almost all operations available for ASCII strings are also available for UNICODE strings, and vice versa.
Names. OllyDbg shows all imported and exported symbols and names from debug information and in Microsoft and Borland formats. The Object Scanner allows you to recognize library functions. You can add your own values and comments. If the functions in some DLL are exported as ordinals, you can attach the import library and restore the original names. OllyDbg also knows the symbolic names of many constants, like message boxes, code errors, or bit fields, and decodes them into known function calls.
Known functions. OllyDbg recognizes more than 2,300 commonly used C and API Windows functions by name and decodes their parameters. You can add your own descriptions, or assign a specific decoding. You can set a write breakpoint on a known function and write the parameters to a file.
Challenges. OllyDbg can abort application execution when accessing the stack, even when debugging information is not available and routines use non-standard introductions and terminations.
Stack. In the Stack window, OllyDbg uses heuristics to recognize return addresses and record structure. Note, however, that they may be leftovers from previous calls. If the program is paused on a known function, the stack window decodes the actual parameters.
SEHchains. The stack traces and displays the chain of SE handles. The complete chain is available in a separate window.
Search. Lots of possibilities! Search for a command (exact or imprecise) or sequence of commands, for constants, a binary or text string (not necessarily continuous), for all commands that reference an address, constant or address interval, for all jumps to a selected location, for all functions that call some procedure, or whatever that procedure calls, for all referenced text strings, for all calls to various modules, for names, for masked binary sequences in the entire memory allocation. If multiple locations are found, you can quickly move between them.
Window. OllyDbg lists all windows created by the application being debugged and sets breakpoints to windows, a class, or even a selected message or group of messages.
Resources. If a Windows API function references a string resource, OllyDbg retrieves and displays it. Support for other types is limited to list of attached resources, dump and binary edit.
Checkpoints (breakpoints). OllyDbg supports all the usual types of breakpoints: simple interrupts, conditional interrupts, interrupts that write information (such as function parameters) to a log, write and memory access breakpoints, hardware breakpoints (ME/NT/2000 only). As a last resort for step-by-step debugging, an INT3 breakpoint can be set on each instruction in the module. On a 500 MHz processor under Windows NT, OllyDbg can process up to 5000 interrupts per second.
Observers and inspectors. Observers are expressions that are evaluated every time the program is paused. You can use registers, constants, address expressions, Boolean and algebraic operations of any complexity. You can compare ASCII and UNICODE strings. Inspectors are observers that contain up to 2 indexes and can be represented as a two-dimensional table that allows arrays and structures to be decoded.
Bypassing dynamic memory. On Win95-based systems, OllyDbg lists all allocated heap blocks.
Handles. On NT-based systems, OllyDbg lists all system Handles belonging to the application being debugged.
Performance. You can run the program step by step, enter subroutines, or run them in one step. You can execute the program until the next return or to a specified location, or animate the execution. While the application is running, you still have full control over it and can view memory, set breakpoints, and even change code on the fly. At any time, you can pause or restart the program being debugged.
Step by step debugging. Step-by-step debugging shows you which commands or procedures have been executed so far, allowing you to check all the branches of your code. Step-by-step debugging sets a breakpoint on each selected command and removes it when the command is reached.
Direct tracing (Run trace). Trace executes the program step by step and records its execution in a large circular buffer. This protocol contains all registers (except SSE), thread flags and errors, messages and decoded parameters of known functions. You can save the original commands, which will make it easier to debug self-modifying code. You can define a condition for stopping debugging by entering an address range, expression, or command. You can save debug information to a file and compare two independent executions of the program. Tracing allows you to reverse-analyze the execution history of millions of commands in detail.
Profiling. The profiler calculates how many times a certain command appears in the trace buffer. With a profiler, you will find out which part of the code takes the longest to execute.
Making corrections. The built-in assembler automatically selects the shortest possible code. The binary editor shows data in ASCII, UNICODE and hexadecimal forms simultaneously. Good old copy and paste is also available. Automatic backup allows you to undo changes. You can copy changes directly into the executable, OllyDbg even corrects installed errors. OllyDbg remembers all program fixes from previous debugging sessions. You can apply or remove them with a few keystrokes.
Self-extracting files. When debugging an SFX file, you usually want to skip the archiver and stop when entering the program directly. OllyDbg performs SFX debugging by trying to locate the actual input. SFX debugging usually fails on protected archives. Once the input is found (or defined), OllyDbg can run the unpacker more quickly and reliably.
Additions to the program. You can add a plugin to OllyDbg, or write your own plugin for the program. The program add-ons access all important data structures, add menus and shortcuts to existing OllyDbg windows, and use more than 100 additional API functions. The API plugins are well documented. The standard distribution includes two add-ons to the program: Command Line and Bookmarks.
UDD. OllyDbg saves all program - or module-related information in an individual file and restores it when the module is loaded again. This information includes labels, comments, breakpoints, observers, analysis data, conditions, and so on.
Setup. You can define custom fonts, colors and lighting schemes.
And much more! This list is by no means complete; there are many features that make OllyDbg a convenient and enjoyable debugger.
3. Program website
The purpose of this "Introduction to Cracking from Scratch Using OllyDbg" is to give those just beginning to master the art of cracking a basic knowledge, and at the same time, to do so in a way that this knowledge will allow them to later read and understand more advanced tutorials such as , which can be found in the “New Course from CracksLatinos”, which, of course, remains open to new additions and additions.
The idea for the course was born out of the fact that many of the tutorials in the New CracksLations Course were too difficult for beginners, and those who failed to reach the required level found themselves frustrated and in many cases, refused to continue. Therefore, the purpose of this “Introduction...” is not to repeat the excellent tutorials from the “New Course...”, the number of which has already exceeded 500, but to lay the foundation so that those who complete this course will be able to read more complex tutorials. This, like everything in our craft, requires considerable effort, and the main goal is to reduce this amount, providing basic knowledge and allowing further understanding of more complex material.
Why OLLYDBG?
We will not talk here about the eternal confrontation between Soft-Ice and OllyDbg; I think that even Soft-Ice fanatics admit that it is easier to start with OllyDbg, since there is a lot of information about it and it is easier to study. We need to enter the world of cracking through the door called "OllyDbg", and only then whoever needs it can switch to any other debugger that is required, since only their methods of use change, but the essence remains the same.
Start over
First you need to arm yourself with the tool that we are going to mainly use, for which click and download it.
Since we are starting from scratch, first we need to unpack the downloaded archive into a folder on your hard drive that can be easily reached. A good idea would be to create a folder on the C:/ drive. Although it will work in any other location, I will assume that the C:/ drive is selected.
After the file has been unpacked, go to the created folder and see:
It contains the executable file OLLYDBG.exe, which we need to run, and for which I made a shortcut on my desktop for convenience.
Ok, everything is ready to launch. Click on OllyDbg:
We see a message that the DLL located in the library is older than the same system DLL, and if we select “Yes”, then the old DLL will be erased from the folder, and the system one will be used. Although I don't see much difference between the two, I still prefer the one that comes with the distribution, so I always click "No".
This is pure OllyDbg, and the first program that we will open just to get acquainted with OllyDbg will be CrueHead’s famous CrackMe, which is attached to this tutorial.
To open a file in OllyDbg, go to File -> Open or click on the icon:
A window will open with which you can find the desired file, in this case it is CrueHead’s crackme.
The above-mentioned crackme will open, and at the moment it does not matter that it is completely unclear what the view that opens to us means - for now we will just go through the various parts and functions of OllyDbg and some settings, so that when in subsequent tutorials it says, say, “go to DUMP”, you at least knew where this option was.
Here we will look at the four parts of the OllyDbg main window:
1) Disassembled code
Also called listing. Here Ollie shows us the disassembled code of the program we are going to debug; By default, Ollie is configured to analyze the program when it is opened. This can be changed in Options -> DEBUGGING OPTIONS.
That is, if the “AUTO START ANALISIS OF MAIN MODULE” checkbox is checked, OllyDbg will analyze the program and show additional information about it.
This is the beginning of CrueHead's parsed crack listing, and if we open it without parsing, we can see the difference.
The analysis window contains a lot of information, which, despite the fact that it is not very clear to us yet, looks very interesting. At the same time, it’s nice to know that you can remove it at any time if the analysis turns out to be not very accurate or if some error has crept into it.
Often OllyDbg displays some parts of the program incorrectly because it mistakenly interprets the executable code as data, and then it displays something like this:
In this case, you can manually remove the analysis by right-clicking on the listing and selecting “ANALISIS -> REMOVE ANALYSIS FROM MODULE”.
And then the listing will be displayed correctly.
Another option that you can use to make things easier and which I personally don’t really like (but tastes vary) is jump and call highlighting - right-click on the listing and select “APPEARENCE -> HIGHLIGHTING - > JUMPS AND CALLS.”
You will get the following:
Here we see that calls are highlighted in azure, and transitions are highlighted in yellow.
The listing is now more readable, but we have no idea what that means yet, but it's good to have the tool ready for future use.
2) Registers
The second important window is the register window.
Recall that the register window is on the very right side of OllyDbg, and there is a significant amount of information displayed there.
There is much more information that we do not see, but you can set the display mode to three states (“VIEW FPU REGISTERS” – display FPU registers, “VIEW 3D NOW REGISTERS” – display “3D NOW” registers and “VIEW DEBUG REGISTERS” – display debug registers). By default, the first ones are displayed.
3) Stack or heap
Now let's move on to the “stack or heap”. There aren't too many configuration options here, other than the ability to display information regarding the ESP and EBP registers.
By default, the mode for displaying information related to ESP (and it is also the most useful), but it can be changed to the mode for displaying information related to EBP, for which you need to right-click in this window and select “GO TO EBP” , and further use of the “GO TO ESP” item will return us to the previous mode.
I'll explain the functionality of the stack in more detail in later chapters, but for now we'll only cover what can be changed through configuration.
4) Dump
The dump window has many display modes that can be changed by right-clicking in the dump window and selecting the one you need. The default mode is 8-byte Hex/ASCII.
The default mode is also the one most often used, but at the same time, we have the ability to change it to display disassembled code (DISASSEMBLE), text (TEXT) and other formats (SHORT, LONG, FLOAT).
And finally, the SPECIAL -> PE HEADER option, which, as we will see in the coming chapters, can be very useful.
Now we know the main parts of the OllyDbg main window, but there are also windows that are not directly accessible, but can be called either through the menu or through buttons on the control panel.
Let's look at each of them.
The L button or VIEW->LOG shows us what OllyDbg writes in the log window. It can be configured to display various types of information, and by default the log window stores all startup information, as well as information related to BREAKPOINTS CONDICIONAL LOGS. We will meet the latter much later, but for now let’s look at information about the running process (in our case, this is CrueHead’s crack) and the libraries that it loads.
One of the most important options in this window is logging to a file in case we want to save information in a text file. To activate this option, right-click and select "LOG TO FILE".
Button E or VIEW->EXECUTABLES shows us a list of modules that the program uses: exe, dll, ocx and others.
Here, too, the right mouse button brings up many options that we will not look at for now, but which we have already seen when exploring the main OllyDbg window.
The M or VIEW->MEMORY button displays the memory occupied by our program. Here we see sections of the application, libraries used by the process, the stack and various sections occupied by the system, and often programs occupy new sections of memory during execution.
By right-clicking, we can do a SEARCH in memory to find strings of various kinds (text, hexadecimal, unicode), there is also the ability to highlight breakpoints in sections, as well as the ability to change access rights to the latter (select SET ACCESS).
Button T or VIEW->THREADS shows us a list of threads (threads) of the program.
Although now we do not know what it is, and we will find out only in subsequent chapters, it will not be superfluous to familiarize yourself with each of the windows. We will learn how to use them later.
The W or VIEW->WINDOWS button displays the program windows, but since it is not running yet, the list of windows remains empty. 
Button H or VIEW->HANDLES displays handles, later I will explain what they do.
Button C or VIEW->CPU returns us to the main OllyDbg window.
Button / or VIEW->PATCHES shows a list of applied patches if the program has been changed. Since no changes have been made yet, the window remains blank for now.
The K button or VIEW->CALL STACK displays the “call stack”, a list of calls that we have encountered up to the point where the program stopped.
Button B or VIEW->BREAKPOINTS brings up a list of normal breakpoints located in the program. There are no hardware breakpoints or memory breakpoints, just regular ones.
The R button or VIEW->REFERENCES shows a window of references that we received as a result of searching for references in Ollie.
The “…” or VIEW->RUN TRACE button displays the result of the RUN TRACE command. Here we can also select the LOG TO FILE option to save the trace results in a text file.
We've covered the panel with the most important buttons so that you'll be familiar with the capabilities they provide as we begin to delve deeper into them in later chapters.
How to configure OllyDbg to become JIT (JUST IN TIME DEBUGGER)
Of course, we will not use JIT all the time, but only in special cases, since if an error occurs with any running program on our machine, then we do not need Ollie to be used at all (by default, dr.watson is used as JIT ).
To make OllyDbg a JIT debugger, you need to go to OPTIONS->JUST IN TIME DEBUGGING
and press the MAKE OLLYDBG JUST IN TIME DEBUGGER and DONE buttons in sequence
To remove this function, you need to click on RESTORE JUST IN TIME DEBUGGER and DONE in the same place.
Connecting plugins in OllyDbg
OllyDbg allows you to connect plugins that may be useful for solving a particular problem. For now, we will limit ourselves to connecting the COMMAND BAR plugin to learn how to do this.
Download this plugin from here (the link indicated in the original article is dead, so I downloaded the plugin from the Internet and posted it on wasm.ru - approx.).
After that, unpack the plugin and look at the contents of the folder where this was done:
First of all, you need to create a folder for plugins. I'll create it in C:/ and call it PLUGINS.
Of course, plugins can be located anywhere, but I like to host everything in C. Anyway, now we need to configure OllyDbg so that it recognizes this folder as the location of all plugins.
To do this, go to OPTIONS->APPEARANCE.
And in the window that opens, open the DIRECTORIES tab.
We see that the path to the plugins is the directory where OllyDbg.exe itself is located, and we could put the plugins there, but I like to keep them separate, and then click on PLAGIN PATH->BROWSE to find the folder we created.
Select the PLUGINS folder and save the changes.
That is, you need to restart Ollie so that it recognizes the new folder with plugins, but first you need to copy the last downloaded plugin to it.
Copy the entire contents of the archive to the PLUGINS folder.
Now all the files of the “Command Bar” plugin are located in the PLUGINS folder, and the rest should also be placed in it (often you can copy not all the files in the archive, but only the dll).
Now close OllyDbg, if it was still closed, and launch it again. We see that the COMMAND BAR and its options have appeared in the PLUGINS menu.
At the bottom of OllyDbg we see the installed COMMAND BAR.
This is a text field for entering commands that can be useful to us in many cases, and later we will see their use, but for now it is important to learn how to connect plugins.
To uninstall PLUGIN, simply erase the corresponding dll from the PLUGINS folder and restart OllyDbg, and the plugin will disappear. However, it is prudent to always keep the COMMAND BAR on.
Let's open CrueHead's crack again in OllyDbg.
The most useful keys in OllyDbg are:
F7: Executes one line of code (if we are on CALL, then go inside the called section of code)
F8: Executes one line of code (if we are on a CALL, it simply executes the call without going inside and moves to the next line after the CALL).
These two types of manual tracing are very different and in what cases to use each of them we will consider later.
F2: Sets a normal breakpoint on the marked line. To remove this breakpoint, press F2 again.
For example:
We want to set the installation point at position 40101A, so we mark this line with the mouse.
With one click of the mouse it is marked and becomes gray as in the picture. Then press F2.
We see that the corresponding position in the first column turns red, which indicates that there is a breakpoint here. By pressing F2 again you can remove it.
F9: Runs a program that will run until it hits a breakpoint, throws an exception, or simply stops running for some reason. When the program is running, the word RUNNING is displayed in the lower right corner of OllyDbg.
When we launch CrueHead's crack, we will see the following:
To temporarily stop running the program, press F12 or DEBUG->PAUSE.
We see that OllyDbg displays the word PAUSED. You can continue running the program by pressing F9 or DEBUG->RUN.
To close the program being debugged, select DEBUG->CLOSE.
This has been a quick overview of OllyDbg, and we will continue to explore its many options and capabilities in more depth in subsequent chapters. The main thing is that you download the program, configure it, look again at everything that was discussed in this tutorial, also connect the plugin, start and stop CrueHead's crack, try to set breakpoints so that in the next chapter all these things do not cause problems. you hesitation and doubt.