The easiest way is to launch OllyDbg, select File -> Open and select the program you want to debug. If this program requires any command line parameters, type them in the box at the bottom of the dialog box, or select one of the parameter lines you have used in previous sessions.
OllyDbg can do debugging of standalone DLLs. In this case, OllyDbg creates and runs a small application that loads the library and, at your request, calls the exported functions.
If you want to restart the last program you were debugging, simply press Ctrl+F2 (this is the hotkey for restarting the program) and OllyDbg will launch it with the same parameters. Alternatively, select the File menu and then the program from history. You can also drag an executable file or DLL from Windows Explorer and drop its icon onto OllyDbg.
Of course, you can specify the name of the program being debugged and its parameters on the command line when starting OllyDbg. For example, you can create a desktop shortcut pointing to OllyDbg, select Properties, go to Program Shortcut, and add the program name to the command line. Every time you double-click this shortcut, OllyDbg will automatically launch your program. Please note that DLLs do not support the command line.
You can attach OllyDbg to a running process. Select File -> Attach, and select a process from the list. Note, however, that once you close OllyDbg, this process will also exit. Never try to attach to a system process; this may result in the operating system crashing. (To be fair, in most cases the OS will not allow you to attach to a sensitive process).
OllyDbg can act as a just-in-time JIT debugger. This requires registration in the system registry. Select Options -> Just-in-time debugging, and in the dialog that appears, select "Make OllyDbg just-in-time debugger" ). Now, whenever an application crashes, you will be asked if you want to debug that application. Then the operating system will launch OllyDbg, which will stop directly at the point where the failure occurred. Or, if you chose to join without confirmation, OllyDbg will launch without any questions. To restore the previous “just-in-time” debugger, click the corresponding button in the mentioned dialog and that’s it.
There is also another option to add OllyDbg to the context menu associated with executables in Windows Explorer. (This idea belongs to JochenGerster). From the OllyDbg main menu, select “Options|Add to Explorer”, then click “Add OllyDbg to menu in Windows Explorer”. Afterwards, you can right-click on the executable file, or DLL, and select OllyDbg from the menu. This option creates 4 keys in the system registry:
HKEY_CLASSES_ROOT\exefile\shell\Open with OllyDbg
HKEY_CLASSES_ROOT\exefile\shell\Open with OllyDbg\command
HKEY_CLASSES_ROOT\dllfile\shell\Open with OllyDbg
HKEY_CLASSES_ROOT\dllfile\shell\Open with OllyDbg\command
OllyDbg can debug console applications (text based).
OllyDbg cannot debug .NET applications. .NET programs consist of pseudocode that Windows interprets or assembles on the fly into native "86 commands.
Note that if you are using Windows NT, 2000 or XP, you will probably need to have administrator rights to debug programs.
Breakpoints (control points)
OllyDbg supports several types of breakpoints:
- Regular breakpoint, the first byte of the command you want to stop at is replaced with a special INT3 (Debugger Trap) command. You can set this breakpoint by selecting the required command in the Disassembler panel and pressing F2, or from the context menu. When you press F2 a second time, the breakpoint will be cleared. Note that the program stops before executing the command with the breakpoint set. The number of INT3 breakpoints you can set is unlimited. When you close the program you are debugging, or the Debugger, OllyDbg automatically saves the breakpoints to disk. Never try to set this type of breakpoint on data or in the middle of a command! OllyDbg will warn you if you try to set a breakpoint outside of a code section. You can turn off this warning in the Security options. In some cases, the Debugger may insert its own temporary INT3 breakpoints.
- Conditional breakpoint(Shift+F2) - a regular INT3 breakpoint with an associated condition. When the Debugger encounters this breakpoint, it evaluates the condition and if the result is non-zero or the condition is invalid, it stops the program being debugged. However, the likelihood of an overflow caused by an incorrect conditional breakpoint is very high (mainly due to operating system latency). On a PII 450 under Windows NT, OllyDbg processes up to 2500 false conditional breakpoints per second. An important case of a conditional breakpoint is stopping at Windows messages (like WM_PAINT). For this purpose, you can use the pseudo variable MSG along with the proper interpretation of the parameters. If the window is active, see the message breakpoint described below.
- Conditional Breakpoint with recording(Shift+F4) - a conditional breakpoint with the ability to register the value of some expression or parameters of a known function every time the breakpoint is triggered or when a set condition is met. For example, you can set a write breakpoint on some window procedure to log all calls to this procedure (CALL), or only the identifiers of received WM_COMMAND messages, or set it on the CreateFile call and record the names of read-only files, etc. A logging breakpoint is just as fast as a conditional breakpoint, and it's certainly much easier to look through a few hundred messages in a log window than to press F9 a few hundred times. This way you can choose a more appropriate interpretation for your condition.
You can set a pass counter - a counter that is decremented each time a stop condition is met. If the pass count before decrement is not zero, OllyDbg will continue execution. Consider a loop that runs 100 (decimal) times. Let's put the breakpoint in the middle and set the value to 99. (Decimal). OllyDbg will abort on the last iteration.
In addition, a conditional logging breakpoint allows you to issue one or more commands to plugins. For example, this could be a request to the command line plugin to change the contents of the register and continue.
- Breakpoint messages- the same as a breakpoint with a write condition, except that OllyDbg automatically generates a condition that allows you to break on some message (like WM_PAINT) at the entry point to the window procedure. You can install it in Windows box.
- Trace breakpoint(Trace breakpoint) - a critical case of INT3 breakpoints set on each specified command. If you are doing a hit trace, the breakpoint will be removed and the address will be marked as passed after the command is reached. If you are using a run trace, OllyDbg will add an entry to the trace log and the breakpoint will remain active .
- Breakpoint for Memory. OllyDbg allows you to set only one breakpoint per memory. You select some portion of memory in the Disassembler or Dump panels of the CPU window and use the context menu to set a breakpoint on the memory. The previous memory breakpoint, if there was one, will be automatically deleted. You have two options available: abort on memory access (read, write, or execute in memory) or abort on write only. To set this breakpoint, OllyDbg modifies the attributes of the memory blocks containing the allocation. On 80x86-compatible processors, memory is distributed and protected in 4096-byte blocks. If you select even a single byte, OllyDbg will have to protect the entire block. This can lead to many false alarms with huge overflow. Use this type of breakpoint with caution. Some system functions (especially under Windows 95/98) cause the program being debugged to hang instead of generating a debug event when accessing protected memory.
- Hardware breakpoint(only available under Windows ME, NT, 2000 or XP). 80x86-compatible processors allow you to set 4 hardware breakpoints. Unlike a memory breakpoint, hardware breakpoints do not slow down execution speed, but only cover up to 4 bytes. OllyDbg can use hardware breakpoints instead of INT3 when executing or scanning code.
- Single memory access interrupt(Single-shot break on memory access) (available only under Windows NT, 2000 and XP). You set it in the Memory window on a whole block of memory from the context menu or by pressing F2. This breakpoint is especially useful if you want to catch a call or return to some module. Once the stop is performed, the breakpoint is removed.
- Stopping normal tracing(Run trace pause) (Ctrl+T) - setting conditions that are checked at each step of the run trace process. You can stop a run trace when the EIP enters or leaves another range, or when a condition is true, or when a command matches one of the specified patterns, or when a command is suspicious, or after a specified number of commands have been traced. Please note that this option can significantly (up to 20) slow down the run trace speed.
OllyDbg can also stop program execution on certain debugging events, like loading or unloading a DLL, starting or killing a thread, or when the program sends a debugstring.
Dump
The Dump window displays the contents of memory or a file. You can choose from several specific formats: byte, text, integer, float, address, disassembly or PE Header.
All dump windows support backup, search and editing functions. The Dump window area of the CPU window allows you to define marks, set breakpoints on memory, find data references in executing code, and an open image of the selected memory in an executable file (.exe or .dll). The Dump menu displays only a relative set of available commands.
If backup is available, click Address/Backup in the panel to switch the display mode between backup and normal view. Other buttons on the panel allow you to change dump modes.
Like the Disassembler window, Dump stores a long history of visited memory locations. You can move through the history by pressing the "+" or "-" buttons.
To scroll through the data, hold down the Ctrl key and press the Up/Down arrows.
Modules
The Running Modules window (keyboard shortcut: Alt+E) lists all modules currently loaded by the process being debugged. This window also displays useful information like module size, entry address, module version, or executable path. Some information, such as the decimal module size, the symbolic name of the entry point, etc., is usually hidden by the system. To see this data, increase the width of the corresponding columns. The context menu supports the following options:
Actualize - rescans modules and removes highlighting from new modules. Most of the time, OllyDbg takes care of itself.
View memory - Opens the Memory window and scrolls to the first memory block belonging to the module being displayed.
View code in CPU - opens the executable code of the module in the Disassembler.
Follow entry - Follows the entry point of a module in the Disassembler
Dump data in CPU - opens the module data section in CPU Dump.
View names (Ctrl+N) - Displays a table containing all names (export, import, library, user-defined) defined or used in the current module.
Mark as system DLL
Mark as non-system DLL - Marks the selected module as system or non-system. By marking a module as system, you exclude it from the Trace, significantly speeding up its execution. By default, system modules are modules that are permanently located in the system directory (usually c:\windows\system on Windows 95/98, c:\winnt\system32 on NT/2000/XP).
Update .udd file now - writes all data dependent on this module to a file
View executable file - Displays a dump of the executable file.
View all resources - Displays a list of all resources defined in the module along with brief information. OllyDbg does not support resources as a separate object; all you can do is dump the resource and edit it in binary form.
View resource strings - Displays a list of string resources and their IDs.
View run trace profile - Calculates the profile for this module. See also Run trace.
Analyze all modules - allows you to analyze all modules at once. The analysis extracts useful information from the loaded code; Debugging is usually faster and much more reliable once the code has been analyzed.
By double-clicking on a line, you will go to the code running in the module in the Disassembler panel.
Memory card
The Memory Map window displays all memory blocks used by the program being debugged. There are no standard tools to accomplish this task, so it may happen that OllyDbg combines several pieces of distributed memory into one large memory block. However, in most cases there is no need for precise resolution. To get a list of memory blocks requested by an application through calls to GlobalAlloc(), LocalAlloc(), etc., use Heap list.
If the memory block is a section of some executable module, OllyDbg will tell you what kind of data the block contains: code, data, resources, etc.
There are some differences between Windows 95/98 and Windows NT/2000. Under Windows 95/98, OllyDbg is not able to show the names of displayed files. Also, Windows 95/98 limits the allowed types of memory access: read and write. Consider also that Windows NT/2000 has a much wider range of capabilities, including execute access, copy-on-write, and the guard flag. OllyDbg ignores the copy-on-write attribute.
If OllyDbg recognizes that the program has allocated a new or reallocated an existing memory block, then OllyDbg highlights the corresponding entry in the memory map window. To reset all highlighting, select Actualize from the context menu.
You can bring up the Memory window by pressing Alt+M.
The following context menu items are available:
Actualize - Updates the allocated memory list and de-allocates new memory blocks.
View in Disassembler - Opens a memory block in the Disassembler. This option is only available when the memory block contains executable code or a self-extractor of some module.
Dump to CPU - Displays the contents of a memory block in the CPU Dump window area.
Dump - dumps the contents of a memory block in a separate window. If the memory block type is known, OllyDbg automatically selects the dump format.
View all resources - If the block contains resource data, a list of all resources and associated data. OllyDbg does not support resources as a separate object; all you can do with the resources is dump them and edit them in binary format.
View resource strings - If the block contains resource data, then Ollie lists all resource strings with their IDs.
Search - Allows you to search through all blocks of memory, starting with the allocated one, before encountering a binary string. If the string is found, OllyDbg shows a dump of the found memory block. The Memory Map and the dump window share the same search pattern, so you can immediately continue searching until the next occurrence in the dump that appears. You can close the dump window by pressing Esc.
Set break-on-access (F2; available only under Windows NT/2000) - protects an entire block of memory. After a breakpoint, OllyDbg stops the program being debugged and removes the breakpoint. This breakpoint is especially useful if you want to catch a call or return to some module.
Remove break-on-access (F2) - Removes an installed break-on-access from a memory block.
Set memory breakpoint on access(Set breakpoint on memory access) - sets a breakpoint on memory access on the entire memory block. The program will be interrupted every time the program being debugged accesses this memory block. OllyDbg only supports one breakpoint per memory. Under Windows 95/98, the program being debugged may hang when system routines access memory blocks containing a breakpoint. Use it as a last resort.
Set memory breakpoint on write(Set breakpoint to write to memory) - sets a breakpoint on the entire memory block. The program will interrupt every time it writes to this memory block. Under Windows 95/98, the program being debugged may hang when system routines access memory blocks containing a breakpoint. Use it as a last resort.
Remove SFX memory breakpoint - stops the search at the actual entry point into the packaged program (SFX). This search uses a special type of memory breakpoint.
Set access- sets the desired memory protection attribute to the entire memory block.
Possible options:
No access
Read only
Read / write
Execute
Execute / read
Full access
Copy to clipboard
Whole line - copies the selected entry to the clipboard as multi-line text with explanations. To exclude a column from copying, reduce its width to the minimum (the rest of the column will turn gray).
Entire table - copies the entire memory card to the clipboard as multiline text. The first line of this text contains the window title (“MemoryMap”), the second line contains the column headings, and all subsequent lines contain memory data records. The copy maintains the width of the columns. To exclude a column from being copied, reduce its width to the minimum (the rest of the column will turn gray).
Observers and inspectors
The Observer window contains several expressions. It displays their values in the second column. OllyDbg saves expressions in the main module's .udd file so they will be available the next time you debug.
The inspector is a stand-alone window that can show the contents of a variable, a 1- or 2-dimensional array, or even selected elements of an array of structures. The expression is basically the same as the Observer, but can include two parameters: %A and %B. When you install Inspector, you can define limits for these parameters. OllyDbg then calculates all possible combinations of %A and %B into an expression starting from 0 up to the limit (not including), and displays the results in a table. The limit for %B (number of columns) cannot exceed 16.
Call stack
The Call Stack window (Alt+K) attempts to trace the sequence of calls on the selected thread's stack and displays it, along with the known or suggested parameters of the functions being called. This task is easy when the functions being called create standard stack frames (PUSH EBP; MOV EBP,ESP). Modern optimizing compilers don't bother with stack frames, so OllyDbg uses various tricks. For example, OllyDbg tries to trace the code to the next return and calculates any push, pop or ESP changes. If this doesn't help, OllyDbg takes a more dangerous and time-consuming approach: OllyDbg scans the stack, trying to find all possible return and test addresses where the function was called by the corresponding statement, including parsed commands. There are also other, rather dubious heuristics. Stack browsing can be really slow. OllyDbg only produces it if the Call Stack window is open.
The Call Stack window contains 5 columns: Address, Stack, Procedure, Called from, Frame.
The Address column contains the address on the stack, Stack displays the value of the corresponding return address or parameter.
Procedure (or Procedure / arguments) - displays where the Call Stack window places the address of the called function on the stack. In some cases, OllyDbg is not sure if this address is correct and adds one of the following markers:
The found entry point is not reliable
Maybe OllyDbg could not find a reliable entry point, the found address needs to be checked using heuristics
Includes OllyDbg, couldn't find the entry point and only knows that this procedure includes the display address
By clicking a button on the panel or selecting “Hide/Show arguments” from the menu, you can turn function parameters on or off.
Called from is the address of the command that is called by this procedure.
The last column, Frame, is hidden by default and displays the value of the frame pointer (EBP register) if known.
It is more reliable and much faster to scan the stack when all called functions are analyzed.
Call tree
The call tree (CALL) (Ctrl+K key in Disassembler) uses the results of the analysis to prepare a list of functions called by a given procedure, directly or indirectly, and a list of all known calls to that function. Side effect - recognizes whether the selected procedure is explicitly recursive. "Explicitly" means that it cannot trace requests with an unknown address, like CALL EAX. If the procedure makes unknown calls, Call Tree adds "Unknown destination(s)" markers.
Some of the called functions are commented with one of the following words:
Leaf Does not call any other functions
Pure Does not call any functions, has no side effects
RETN Consists of a single RETN command
Sys Function in a system DLL. By definition, a system DLL is a DLL that resides permanently in the system directory
To navigate through the Call Tree, double-click the address in the Called from column or the Calls/Calls directly column. The "Call Tree" window saves the history of your actions (the "-" and "+" keys).
If the program you are debugging consists of several modules, I recommend analyzing all of these modules. Call Tree does not attempt to handle system functions.
Self-extracting (SFX) files
An SFX file consists of an unpacker and a packaged original program. When examining compressed files, you usually want to skip the packer and stop at the program's entry point (the "real entry"). OllyDbg contains several features that make this task easier.
Usually the unpacker is loaded into addresses that are outside the original program section. In this case, OllyDbg recognizes the file as SFX.
When the SFX option requires real input tracing, OllyDbg sets a memory breakpoint on the entire code section. It is usually empty or contains compressed data. When a program tries to execute some command within a protected area that is neither RET nor JMP, OllyDbg reports the real input. This is how byte-by-byte extraction works.
This method is very slow. There is another, faster method. Every time an exception occurs while reading data, OllyDbg reads from that 4K block of memory, and disables the previous read window. On each data write exception, it allows writing to this block and prohibits writing to the previous one. When a program executes commands in an unprotected area, OllyDbg reports the real input. However, if the real input is inside a read or write window, its location will be reported incorrectly.
You can correct the login address manually. Select the new entry address and in the context menu of the Disassembler window, select Breakpoint-> Set real SFX entry here. If the appropriate SFX option is enabled, OllyDbg will skip the unpacker quickly and reliably next time.
You walk through the program you are debugging by pressing F7 (step with entry) or F8 (step with bypass). The main difference between these methods is that if the current command is CALLing some function, F7 will enter the function and stop at its first command, while F8 will immediately try to execute the function. If you bypass a function, any breakpoint or debugging event within the function will pause the execution of the main program, but the temporary breakpoint after the procedure call will remain active, and you will reach it sooner or later.
If the program being debugged stops on an exception, you can pass that exception to a handler installed with the program being debugged. Just press Shift along with any advance command.
Instead of pressing F7 or F8 several hundred times, you can use animation (Ctrl+F7 or Ctrl+F8). In this case, OllyDbg automatically repeats F7 or F8 after the previous step is completed and all windows are modified. The process stops when:
- You press Esc or run any other advance command, or
- OllyDbg will meet a previously set breakpoint, or
- The program being debugged will throw an exception.
Using the "+" and "-" keys, you can rewind the execution history.
Note that OllyDbg draws most windows whenever execution is paused. If the animation appears to be very slow, try closing or at least minimizing all unused windows.
Another, faster way to backtrace program execution is Run trace. In this case, OllyDbg creates an execution log and tells you when and how many times this command was executed.
Step-by-step tracing
Step-by-step tracing gives you the ability to note which parts of the code were executed and which were not. The method implemented in OllyDbg is quite simple. It sets an INT3 breakpoint on every team within the specified area. When a breakpoint is executed, OllyDbg removes it and marks the command as passed. Since each trace breakpoint is executed only once, this method is very fast.
When using incremental tracing, care must be taken not to set a breakpoint on the data, as this will cause the application to make an error. For this reason, you must parse the code to enable the appropriate menu options. I recommend that you choose strict or heuristic procedure recognition. The fuzzy option is too error-tolerant and often finds non-existent procedures.
When you set a trace breakpoint, even on a single command within a module, OllyDbg sets a trace buffer twice the size of the code section.
Note that when you delete step trace data, you also delete the forced trace.
Direct tracing
Forward tracing is a way to reverse program execution, which is necessary in some cases. You can also use direct tracing for simple profiling. Basically, OllyDbg executes the program being debugged step by step, like an animation, but does not change windows and - most importantly - stores addresses, register contents, messages and known operands in a trace buffer. If the code you are debugging is self-modifying, you can keep the original commands. Start a forward trace by pressing Ctrl+F11 (input trace) or Ctrl+F12 (bypass trace). Stop tracing - F12 or Esc keys.
You can define a set of conditions that are checked at each step of the forward trace execution (hotkey: Ctrl+T). Forward tracing stops when it encounters a condition. Terms include:
Of course, direct tracing requires a lot of memory, averaging 16 to 35 bytes per instruction depending on the mode, and is very slow. On a 500 MHz processor running Windows NT, this process can trace up to 5000 instructions per second. Under Windows 95 it is slower: only 2200 commands per second. But in many cases, for example when a program jumps to a non-existent address, this is the only way to find a solution to the problem. You can exclude quasi-linear instruction sequences (with a single output at the end of the sequence) from the forward tracing process. When OllyDbg encounters an excluded sequence, OllyDbg sets a temporary breakpoint on the command that immediately follows the excluded block and executes it immediately. Of course, any return or jump to external code makes proper review impossible, so OllyDbg checks the part of the code you want to exclude, and in difficult cases asks you for confirmation.
In most cases, you do not need to trace system API code. The "Always trace over system DLLs" option allows you to trace without entering functional APIs when tracing and animation with entry. OllyDbg assumes that the module is system if it is permanently located in the system folder. In the Modules window, you can mark any library as system or non-system.
To make execution faster, you can limit the direct tracing procedure to selected commands or parts of code by setting breakpoints to start tracing and running the program. I call this "forced run trace". Basically, routing breakpoints are non-removable step-trace breakpoints. If you delete a step trace, you also delete the forward trace.
The trace commands mentioned at the beginning of this section automatically open the trace buffer. You can define its size (up to 64 MB) in Options. This buffer is circular and when it is full, the oldest entries are overwritten.
You can open or clear the run trace buffer by selecting Debug -> Open or clear run trace from the OllyDbg main menu. Once the trace buffer is open, OllyDbg will log all pauses in execution, even those that were not caused by a direct trace. For example, you can step through the program by pressing F7 or F8 and then backtrack through the code using the Plus and Minus keys. Note that these keys view history when the trace buffer is closed. If you trace a program, the Registers and Information areas of the window turn gray, emphasizing that the register data they display is not actual data. The trace buffer does not store the top of the stack or the memory contents used by registers. Registers, Information, and Stack use the actual memory state to interpret registers from the trace buffer.
OllyDbg can count the number of times each command appears in the forward trace buffer. In the Disassembler window, select “View -> Profile data”. This command replaces the Comments column with the Profile column. Or, if a panel is displayed, click it several times until it displays Profile information. Note that the counter displayed is dynamic and does not count old commands removed from the trace buffer. You can also view profile data for an entire module, sorted with a few clicks, in a separate Profile window
A special command in the Disassembler window “Runtrace -> Add entries of all procedures” allows you to check how often each recognized procedure is called. Another command, Runtrace -> Add branches in procedure, forces all recognized branch destinations within the procedure to be traced. In this case, the profile allows you to find the most frequently executed transitions and optimize them to increase speed.
The “Search for -> Last record in run trace” option in the context menu of the Disassembler window finds when the marked command was executed, and whether it was executed at all, for the last time.
The live trace window displays the contents of the trace buffer. For each command, there are certain register contents that were changed by the command (more precisely, changed between the entry in the source and the updated one). If you double-click on a command, a pop-up window will select all references to that command in the trace buffer and you can quickly view them by pressing the Plus or Minus keys. If the "Trace -> Synchronize CPUandRuntrace" option is checked, the Disassembler will go to the forward trace window.
Note that when you delete a step trace, you are also deleting a forced forward trace.
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
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.
Button R or VIEW->REFERENCES shows a window of links received by us as a result of searching for links 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.
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.
By launching CrueHead's crackme, 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.
This article is provided for informational purposes only. The DAXA project team does not bear any responsibility.
"Cracking lesson with OllyDbg"
I think many people are interested in how programs break?, how can you bypass registration, or how to bypass the limitation of a program? In this article I will give a simple example of bypassing registration, I will try to explain everything very simply so that everyone can understand. It is advisable to have at least a rough idea of what assembler is, but if you don’t have this knowledge, don’t worry, I think after this experience, you will definitely learn the basics of assembler.
After downloading all the necessary software, install it wherever you want. All programs do not require installation. First of all, we launch our debugger OllyDbg, when you first launch it will ask you to specify the paths to UDD and Plugins, let’s help it by going to Options->Appearance->Directories and registering both paths (just specify the folder where OllyDbg is located). Don’t be intimidated by the many windows, we only need 3 to work.
1.CPU
2.Breakpoints
3.Patches
I recommend closing all other windows so that they do not disturb us. Now I’ll explain our task, we need to either make the program accept any key or not display a registration message at all and forget about it forever :). So let’s get started, I’ll try to describe everything step by step.
1.Open our program in the debugger. To do this, open the File->Open menu and select our test program. After loading, we will see this picture in the CPU window.
This is the assembly code of our program.
Now let me explain some lines a little:
PUSH EBP ; Start of another function
CALL TestP.00405С60; Calling a function
This will be enough for us for now.
2.Now we need to find a function that displays a window asking you to enter a key. To do this, execute the program step by step by pressing the F8 key until a window appears asking for input. After several clicks, an input window appears.
Now we know that somewhere in this function (TestP.004523B8) our window will be displayed. We need to get to the bottom of the function that displays the window; for this we need to go into this function. Now before this line CALL TestP.004523B8 we need to put a breakpoint. To do this, select the line in front of it and press F2 and see that this line has been added to the Breakpoints window.
Next, click on this button to download our program again. Now we need to reach the breakpoint, to do this we click to execute our program and we see that execution has stopped at our breakpoint. To enter the function, press the F7 key. I think you understand the difference between F8 and F7, the first traces the program without entering functions, the second with entering functions. We see this picture.
We need to continue until we find a function that displays a window and processes pressing the OK button and determines whether we entered the key correctly or not. Let's continue, also press F8 until the window appears.
Again we set a breakpoint in front of it.
We press and again, we see that execution has stopped at our first breakpoint, but we need to go to the second, to do this we press again, execution will reach the second breakpoint. We go into the function with the F7 key, we see the following.
Again we set a breakpoint and return here, go into the function, I think you already understand how this is done. After entering the function we see the following.
We continue searching by pressing F8. When we press F8, we see that API functions begin to appear, 
So we are already close. Press slowly and watch when the window appears. This is what happened, while tracing the program, our window appeared in the task tray,
It came out on this line,
But when you click on it with the mouse, the window does not appear, which means we are where we need it, it is this function that draws the window and somewhere here the key we entered is checked. We continue to trace the program further (F8!) and see that at this place
Some kind of cycle that constantly repeats, it already hurts our finger to hold F8 , but it just won’t end, to do this we set a breakpoint on the first line after the cycle (MOV DWORD PTR SS:,EAX)
And we press the button and see that the window has completely drawn, it is waiting for input from us, the program has stopped here, in the loop. Next, enter any key and click OK.
The window closed and we returned to the debugger window, execution stopped at our breakpoint. Now we need to find a function that displays a window with a notification that the key was entered incorrectly. To do this, trace (F8) our program until a notification window appears.
Here we will figure out what's what. The first line that catches your eye is this is our correct key, but don’t expect that you will find it so easily in other programs, usually keys don’t just lie in memory, so our task will be to make sure that the program accepts any key! Now let's analyze the code before calling the function (CALL TestP.00427294) which displays a window with an error notification. First of all, we look at the registers window, which is located in the window
And we see that the EAX register contains the address of the key we entered in memory and, accordingly, what we entered (I entered 23). Here everything is a little more complicated and you need to have at least a little knowledge of the basic assembler operators. We think that the program must compare our key with some other one or check its correctness in any other way, but for this it must call a function that will do all this. So we are looking for approximately the following structure
MOV EAX, ... //writes the address of our line into EAX
...................
CALL... //calling a function that will check the correctness of our function
JNZ(or JE) ...// conditional jump (read about them!)
A little about the conditional jump, using this operator you can go to a specific line of code, the address is indicated after the operator. This means that after calling the function, if the key was entered correctly after calling this operator, it will go to the line after which our program will start. If not, then the code after it will be executed. So we are looking, this code immediately catches our eye
MOV EAX,DWORD PTR SS:
MOV EDX,TestP.00453BA4
CALL TestP.00404258
JE SHORT TestP.00453B4A
Now re-execute this piece of code step by step and you will see that this operator
JE SHORT TestP.00453B4A is skipped and doesn’t throw us anywhere, which means this is our function that checked our code and it turned out to be incorrect, which is why the JE operator didn’t throw us anywhere. I will explain to you how this operator checks for correctness, we do everything “rigidly” right through :). This means that if the code is entered, this operator will send us to the address 00453B4A and everything will be ok :). We replace this operator with an unconditional jump (JMP), which in any case will transfer us to this address. Look where this address is located (highlighted line in blue). 
We see that the call to the function that displays a notification that the key is incorrect is skipped.
In order to replace a line, select it and press Space and replace it 
on this. 
We see that the line JE SHORT TestP.00453B4C replaced in the window Patches line added.
Now we check whether it works. Press the button, in the Breakpoints window, right-click and select Disable All from the menu. Next, in the Patches window, right-click on our line and select Apply Patch from the menu. After that, press the button, a window will appear asking for a key, enter any key, press ok and our program is registered. This particular program will always ask for the key, since this is just a test, and a real program would record to itself that you entered the key correctly.
3. The last step is to embed the patch into the program; for this we need a Hex editor. So we open it and select our program, a cloud of hexadecimal digits will open. We need to find the string JE SHORT TestP.00453B4A in hexadecimal and mark it with ours. I think you noticed that in the CPU(OllyDbg) window, its hexadecimal form is written opposite each line. In order to accurately find this line, we search like this, don’t just enter search 74 2B, and take the previous line of code and search like this E8 3B 07 FB FF 74 2B
In the exe file, the code goes in a chain, which is why we take the previous line. Why are we doing this? It’s just that such a small line as 74 2B can be repeated several times, so we take the previous line to find exactly what we need. Next we look at how our modified string JMP SHORT TestP.00453B4A looks like in hexadecimal code, it looks like this EB 2B so we replace the found string with ours, to do this we press the button and replace the strings like this 
Save the changes and close the editor. That's all, this program will accept any key, which is what was required. I suggest you try to make sure that the program does not prompt you to enter the key at all.
IMPORTANT!! Before you start manipulating programs, you need to check whether the *.exe file was packed. To do this you will need the PEiD utility. How this is all done is the topic of a separate article, I suggest you figure it out for yourself.Hi all. Today I will be describing OllyDebugger. OllyDebugger (hereinafter Olly) is a superb debugger (ring-3). The popularity of this debugger is growing by leaps and bounds :). For beginners, this debugger is just the thing; for professionals who know how to use it very well, it is an indispensable tool. This article will describe everything that I can do in Olly.
1. What is Olly Debugger
Taken from the reference: Olly is a 32-bit assembler-level debugger with an intuitive interface. Particularly useful if the source code is not available or when you are experiencing problems with your compiler.Supported processors. Olly supports all 80x86, Pentium, MMX, 3DNow!, including Athlon extensions, SSE commands and related data formats.
Data formats. Dump windows display data in all common formats: hexadecimal, ASCII, Unicode, 16- and 32-bit signed/unsigned/hexadecimal integers, disassemblers (MASM, IDEAL or HLA).
Launch. You can define an executable on the command line, select from a menu, drag a file into Olly, restart the last program you were debugging, or attach to an already running process. No installation required, you can run Olly from a floppy disk!
Debugging DLLs. With Olly, you can debug standalone dynamic link libraries (DLLs). Olly automatically launches a small executable that loads the library and allows you to call its exported functions.
Analysis. The analyzer is one of the most significant parts of Olly. It recognizes procedures, loops, tables, constants and strings embedded in code, tricky constructs, API function requests, function parameter numbers, import sections, and so on. Analysis makes double code much more readable, makes debugging easier, and reduces the likelihood of crashes. The analyzer is not compiler-oriented and works equally well with all Windows programs.
Object scanner. Olly scans object files or libraries (OMF AND COFF formats), extracts code from them, segments them, and locates them in the program being debugged.
Full Unicode support. Almost all operations available for ASCII strings are also available for Unicode strings, and vice versa.
2. Hot keys
It is with the “hot keys” that I want to start the story, because... Without them, you will have to spend a lot of time crawling through the menu and the debugger will immediately lose its convenience. Let's start with the control panel:The first button is to open the file (horizontal key F3)
The second button is to restart the file (horizontal key Ctrl+F2)
The third button is to close the file (horizontal key Alt+F2)
The fourth button is to start the program (horizontal key F9)
The fifth button is to pause the launch (horizontal key F12)
The sixth button is to trace with entry into subroutines (horizontal key F7)
The seventh button is to trace without entering subroutines (horizontal key F8)
The eighth button is to start automatic tracing by entering subroutines (horizontal key Ctrl+F11)
The ninth button is to start automatic tracing without entering subroutines (horizontal key Ctrl+F12)
The tenth button is to execute the program before exiting the subroutine (horizontal key Ctrl+F9)
Eleventh button – go to the address (horizontal key Ctrl+G)
All other buttons on the control panel will be discussed later.
Required commands:
Ctrl+A – analyze the code
Ctrl+C – copy data
Ctrl+F7 – enable the mode where the code will be executed as if you pressed and did not release the F7 button
Ctrl+F8 – enable the mode where the code will be executed as if you pressed and did not release the F8 button
Shift+F8 – continue program tracing even if an exception occurs
Shift+F9 – continue running the program even if an exception occurs
Ctrl+T – auto-tracer settings
Ctrl+F11 – Start automatic tracing with entering subroutines
Ctrl+F12 – Start automatic tracing without entering subroutines
F2 – Place a breakpoint on the selected line
3. Plugins
You probably began to be indignant at why I’m talking about everything, but not about the debugger itself. In response, I will say: “I’ll see how you debug the program, at least without the CommandBar plugin.” Yes, it’s true that it’s much more difficult to debug a program without plugins. Now I will give a list of the plugins I have installed and along the way I will explain what’s what:1. IsDebuggerPresent – Hides the debugger from detection using the IsDebuggerPresent function.
2. Hide Debugger – Hides the debugger from detection using the IsDebuggerPresent function.
3. Olly Script – allows you to write scripts to help with debugging. I don't use this plugin because... I don't think it's necessary to automate debugging.
4. Olly Dump – allows you to dump the process being debugged and at once restores its import. Super plugin. I advise everyone.
5. Command Bar - allows you to work wonders. A line appears in the debugger where you can enter very smart commands. IMHO without this plugin debugging is not possible :). I translated the certificate from the plagia and will provide it in addition No. 1.
4. First acquaintance
As I said, the debugger is very easy to work with. Here is a standard view of the main window with the program loaded for debugging:I said it was a standard window, I lied, I changed the colors :). Now everything is in order. In order of description: Main window, Register window, Stack panel, Menu panel.
Main window: This window is where the actual debugging takes place. All instructions are provided in disassembled form. You can move the index line using the cursor. Using the index line, you can choose which data to copy (everything is much simpler here than in SoftIce. Selected. Ctrl+C, went to the right place Ctrl+V), which command to change, where to put a breakpoint, etc. The address that should be executed next is highlighted on the side. Between the addresses column and the disassembled listing column there is a column with machine code instructions. The very last column contains comments.
Register Window: The Register Window displays all 32-bit registers, flag registers, and various other registers. In order to change a register, you need to click on its value 2 times and enter a new value. You can reverse the register of a flag by double-clicking on one of them.
Stack panel: In the stack panel, you can change the bytes you need in memory, set breakpoints, and look for the correct regs. codes, etc.
Menu Bar: The menu bar will be covered in a larger chapter because... this topic is very important.
5. Getting to know the main menu
Let's start with a menu called File. This menu has tabs: Open, Attach, Exit. Open – open a file for debugging, Attach – join an already running process for debugging, Exit – exit.
View
Log – View log about file download, etc. (hotkey: Alt+L)
Executable modules – View all modules that the application being debugged uses. (hotkey: Alt+E)
Memory – View the memory card. Here is its approximate appearance:
The first column is the address where various sections of the file, DLL libraries, are loaded. The second column is the size in memory of the section. The third column is usually the name of the module. The fourth column is the name of the sections. The fifth column is what is contained in the section. All other columns are not important, because they reflect the attributes of sections in memory. (hotkey: Alt+M)
Threads – View all program threads, freeze them, p`glnpnghr| them, change their priority, kill them.
Windows – View up to x.. information about windows, classes, etc. used by the program.
Handles – View Handles.
CPU – Open the main window. (hotkey: Alt+C)
SEH Chain – Look, put a breakpoint on all announced Seh's.
Patches – View a list of all the changes you have made to the program, undo all changes, etc. (hotkey: Ctrl+P)
Call Stack – View all calls running code in the stack. (hotkey: Alt+K)
Breakpoints – View all breakpoints, disable, delete them. (hotkey: Alt+B)
Run Trace – View the trace log.
File – Hexadecimal file editor.
Debug
Run – Launch the application.
Pause – Pause application execution.
Restart – Restart the program being debugged.
Close – Closing the program being debugged.
Step into – Equivalent to F7.
Step over – Equivalent to F8.
Animate into – Equivalent to constantly pressing F7.
Animate over – Equivalent to constantly pressing F8.
Execute till return – Execute the program before exiting the subroutine.
Trace into – Auto tracing with entry into subroutines.
Trace over – Auto tracing without entering subroutines.
Set condition – Assign a condition for auto tracing.
Close run trace – Stop auto tracing.
Hardware breakpoints – View hardware breakpoints.
Everything else in this menu is not important.
Options
Appearance – Debugger interface settings. I will not dwell on these settings, because... They are not mandatory and you can figure them out yourself.
Debugging options (horizontal key – Alt+O) – Debugger settings. This is the most interesting thing; I will devote the next chapter to this menu item.
Just-in-time debugging – In these settings, you can assign Olly as a debugger that will be launched when some application causes a serious error.
Add to Explorer – add an item for debugging the program to the Explorer context menu.
6. Main program settings
I will only explain the most important options.Security
Warn when breakpoint is outside the code section – Report if you want to place a breakpoint outside the code section. Of course, this option should not be selected.
Warn when terminating active process – Ask: “Do you really want to terminate the process?” This option must be selected.
Warn if not administrator – To pester you if you are not an administrator. This option is for sadomasochism :)
Debug
Set high priority when tracing debugged process – Set b(qnjhi) priority for the application when tracing. This option should be selected “to taste” (I have it selected).
Events
Make first pause at – Make the first stop at. In this case, three options are offered: System breakpoint, Entry point to the main module, Main window. Again, you all need to choose the best option. I selected the entry point to the main module.
Break on new module DLL – stop at each new loaded library.
Break on module unloading – Stop when unloading DLL libraries from memory.
Break on new thread – Stop when creating a new thread.
Break on thread end – Stop when the thread ends.
Exceptions
Ignore memory access violations in KERNEL32 – Ignore memory errors in Kernel32.
Int3 breaks - Don't stop at int3 commands. This option is VERY helpful when unpacking some protectors. Read my unboxing article for more details.
Trace
Size of run trace buffer – Size of the trace buffer. It is better to set the maximum value.
Log commands – Keep a log of the tracer’s operation. This option slightly slows down tracing, so it should be set when there is a need.
Always trace over system DLLs – Always trace past system libraries. This option must be selected for everyone.
After Executing till RET, step over RET – This option allows you to stop when pressing Ctrl+F9 not on RET, but after it is executed. I find this option very convenient, so I advise you to select it.
SFX
When main module is self-exetractable - Here we are asked to choose one of three options: Stop at the beginning of the unpacker code, Trace to OEP in blocks, Trace to OEP by byte. Well, what can I say, options for freeloaders. Auto search OER! True, sometimes Olly does not correctly determine whether the program is packaged or not.
Strings
Well, everything is clear here. Decoding various characters.
Addresses
These options are not important, because they determine how addresses will be displayed.
Commands
These options are only needed for people who really love very beautiful ACM listings.
Disasm
Disassembler settings. You can click on all the options and see how the asm listing will look. All other settings are not important in my opinion.
7. First debugging
We will debug Fant0m crackme 4. You can download it from here: http://fant0m.cjb.net/. From this crackme we will try to get the correct reg. number for your name. Load crackme under the debugger and press F9 to run. Enter the name of the person for whom we want to register this crackme. Enter any password. So, now we need to set a breakpoint to read the name and password. Switch to Olly and in the command qrpnje write bpx GetDlgItemTextA . Click Check. We immediately found ourselves in Olly in this place:00401217 E8 62010000 CALL
It is immediately clear that in the procedure at the address 004012F9 a registration check is being carried out. We reach its call using F8 and enter it using F7. What we see:
004012F9 55 PUSH EBP 004012FA 8BEC MOV EBP, ESP 004012FC 56 PUSH ESI 004012FD 57 PUSH EDI 004012FE 8D3584304000 LEA ESI, DWORD PTR DS: 00401304 8D3D84324 000 LEA EDI, DWORD PTR DS: 0040130A 33C0 XOR EAX, EAX 0040130C 33C9 XOR ECX, ECX 0040130E B31A MOV BL, 1A 00401310 803E00 CMP BYTE PTR DS:, 0 00401313 7415 JE SHORT 0040132A 00401315 8A06 MOV AL, BYTE PTR DS: 00401317 02C1 ADD AL, CL 00401319 32C 1 XOR AL, CL 0040131B F6F3 DIV BL 0040131D 66C1E808 SHR AX, 8 00401321 0441 ADD AL, 41 00401323 8807 MOV BYTE PTR DS:, AL 00401325 47 INC EDI 00401326 46 INC ESI 00401327 41 INC ECX 00401328 EBE6 JMP SHORT 00401310 0040132A C 60700 MOV BYTE PTR DS:, 0 0040132D 33C0 XOR EAX, EAX 0040132F 83F900 CMP ECX , 0 00401332 741A JE SHORT 0040134E 00401334 6884324000 PUSH 00403284 ; /String2 = "" 00401339 6884314000 PUSH 00403184 ; |String1 = "qwerty" 0040133E E8A1000000 CALL
From this code it is clear that at address 0040133E your code is compared with the correct one. Place a breakpoint at this address and press F9. The comment String2 = "" will change to something like this String2 = "ODMZAMHN". So, for the place ODMZAMHN you will have your reg. code for your name. Press F9, enter the correct code, press Check, remove all breakpoints, press F9 and rejoice.
Appendix No. 1
Help with Command Bar. Explanation of Command Bar commands. All commands that I considered unnecessary were removed from this list.Expressions
CALC [expression] - Calculate the value of an expression
Disassembler
AT [expression] - Go to address in disassembler
FOLLOW [by expression] - Go to the address in the disassembler
ORIG - Go to current address (EIP)
* - Go to current address (EIP)
Dump and stack
D [expression] - Go to the address in the dump
DUMP [expression] - Go to the address in the dump
DA [expression] - Dump in assembler format
DB [expression] - Dump in hexadecimal
DC [expression] - Dump in ASCII encoding
DD [expression] - Dump as addresses (stack format)
DU [expression] - Dump in UNICODE encoding
DW [expression] - Dump in hexadecimal word format
STK [expression] - Go to address on stack
Broadcast
A [expression] [, command] - Disassemble address
Tags and comments
L expression, label - Associates a symbolic label with an address
C expression, comment - Sets a comment for an address
Breakpoints
BP [expression] [,condition] - Set breakpoint
BPX [function name] - Set breakpoints on all instructions in the module that call [function name]
BC [address] - Delete a control point at address
MR expression1 [,expression2] - Set a breakpoint on memory for access to a specific area
MBT expression1 [, expression2] - Set a breakpoint in memory to write to a specific area
MD - Delete breakpoint from memory
HR [address] - Set Hardware breakpoint to one byte per access to address
HW [address] - Set Hardware breakpoint to one byte per write at address
HE [address] - Set Hardware breakpoint to execute command at address
HD [breakpoint number] - Delete Hardware breakpoint number
Trace Commands
STOP - Pause the trace
PAUSE - Pause tracing
RUN - Run the program
G [address] - Execute to address
GE - Execute to address
S - Equivalent to F7
SI - Equivalent to F7
SO - Equivalent to F8
TR - Execute the program until exiting the subroutine
OllyDbg windows
LOG - Log view window
MOD - View executable modules
MEM - Open memory card window
CPU - Open the main program window
BRK - Open breakpoint viewing window
OPT - Settings
Various teams
EXIT - Exit Olly
QUIT - Quit Olly
OPEN [file name] - Open file for debugging
CLOSE - Close the program being debugged
RST - Restart the program being debugged
HELP - show help (this text, but untranslated)
HELP - Olly show Oll help
HELP APIfunction - help on API functions
Appendix No. 2
Breakpoints. Olly supports several types of breakpoints:- Regular breakpoint, where the first byte of the command at which you want to break is replaced by INT3 (Trap to Debugger). You can place a breakpoint by selecting a command in the disassembler and pressing F2, or through the pop-up menu. When you press F2 a second time when a breakpoint is already set, it will be removed. The number of INT3 breakpoints is unlimited. When you close the program you are debugging, or the debugger, Olly automatically saves the breakpoints. Never try to set a breakpoint on data or in the middle of a command! Olly will warn you if you try to set a breakpoint outside of a code section. You can turn off this warning in your protection settings. In some cases, the Debugger may insert its own temporary INT3 breakpoints.
Conditional breakpoint (horizontal key Shift+F2) - a regular INT3 breakpoint with a condition. Each time the debugger encounters such a breakpoint, it evaluates its expression and, if the result is non-zero or the expression is invalid, stops the program being debugged.
Conditional breakpoint with logging (horizontal key Shift+F4) - a conditional breakpoint with logging to log the value of an expression or parameters of a known function each time the breakpoint is executed.
Breakpoint for memory. Olly allows you to set a single breakpoint in memory at a time. You select some portion of memory in the disassembler or CPU dump and use the pop-up menu to set the breakpoint to o`lr|. The previous memory breakpoint, if any, will be automatically deleted. You have two options: stop on memory access (read, write or execute) and write only. To set a breakpoint, Olly modifies the attributes of the memory blocks containing the data.
Hardware breakpoint (available only when using a debugger under Windows ME, NT, 2000 or XP). 80x86-compatible processors allow you to set 4 hardware breakpoints. Unlike a memory breakpoint, hardware breakpoints do not slow down execution speed, but only cover up to 4 bytes.
Single stop on memory access (available only under Windows NT, 2000 and XP). You can set it in the Memory window to an entire memory block via the pop-up menu or by pressing F2. This breakpoint is especially useful if you want to intercept requests to a certain module.
Autotrace – You must specify a condition (horizontal key Ctrl+T) under which the debugger will stop the program. Please note that this option can significantly (up to 20%) slow down the program execution speed.
OllyDbg can also stop program execution on certain events, such as when a DLL is loaded or unloaded, or a thread is spawned or terminated.
Appendix No. 3
My debugger settings.If you want to use my settings, replace all data with this text in the ollydbg.ini file, which is located in the same folder where the debugger is installed.
Check DLL versions=0 Show toolbar=1 Status in toolbar=0 Use hardware breakpoints to step=1 Restore windows=104191 Scroll MDI=1 Horizontal scroll=0 Topmost window=0 Index of default font=1 Index of default colors=0 Index of default syntax highlighting=0 Log buffer size index=0 Run trace buffer size index=7 Group adjacent commands in profile=1 Highlighted trace register=-1 IDEAL disassembling mode=0 Disassemble in lowercase=0 Separate arguments with TAB=0 Extra space between arguments=1 Show default segments=1 NEAR jump modifiers=0 Use short form of string commands=0 Size sensitive mnemonics=1 SSE size decoding mode=0 Top of FPU stack=1 Always show memory size=1 Decode registers for any IP =0 Show symbolic addresses=1 Show local module names=0 Gray data used as filling=1 Show jump direction=0 Show jump path=0 Show jumpfrom path=0 Show path if jump is not taken=0 Underline fixups=1 Center FOLLOWed command=0 Show stack frames=1 Show local names in stack=1 Extended stack trace=0 Synchronize source with CPU=1 Include SFX extractor in code=1 SFX trace mode=0 Use real SFX entry from previous run=1 Ignore SFX exceptions =1 First pause=1 Stop on new DLL=0 Stop on DLL unload=0 Stop on new thread=0 Stop on thread end=0 Stop on debug string=0 Decode SSE registers=0 Enable last error=1 Ignore access violations in KERNEL32=1 Ignore INT3=1 Ignore TRAP=0 Ignore access violations=0 Step in unknown commands=1 Ignore division by 0=0 Ignore illegal instructions=0 Ignore all FPU exceptions=0 Warn when frequent breaks=0 Warn when break not in code=0 Autoreturn=1 Save original command in trace=1 Show traced ESP=1 Animate over system DLLs=1 Trace over string commands=1 Synchronize CPU and Run trace=0 Ignore custom exceptions=1 Smart update=1 Set high priority= 1 Append arguments=1 Use ExitProcess=1 Allow injection to get WinProc=0 Sort WM_XXX by name=0 Type of last WinProc breakpoint=0 Snow-free drawing=1 Demangle symbolic names=0 Keep ordinal in name=1 Only ASCII printable in dump=0 Allow diacritical symbols=1 String decoding=0 Warn if not administrator=0 Warn when terminating process=1 Align dialogs=1 Use font of calling window=0 Specified dialog font=0 Restore window positions=1 Restore width of columns= 0 Highlight sorted column=0 Compress analysis data=1 Backup UDD files=1 Fill rest of command with NOPs=1 Reference search mode=0 Global search=0 Aligned search=0 Allow error margin=0 Keep size of hex edit selection=0 Modify tag of FPU register=1 Hex inspector limits=1 MMX display mode=0 Last selected options card=15 Last selected appearance card=6 Ignore case in text search=1 Letter key in Disassembler=1 Looseness of code analysis=1 Decode pascal strings=1 Guess number of arguments=1 Accept far calls and returns=0 Accept direct segment modifications=0 Decode VxD calls=0 Accept privileged commands=0 Accept I/O commands=0 Accept NOPs=1 Accept shifts out of range=0 Accept superfluous prefixes=0 Accept LOCK prefixes=0 Accept unaligned stack operations=1 Accept non-standard command forms=1 Show ARG and LOCAL in procedures=0 Save analysis to file=1 Analyze main module automatically=1 Analyze code structure=1 Decode ifs as switches=0 Save trace to file=0 Trace contents of registers=1 Functions preserve registers=0 Decode tricks=0 Automatically select register type=1 Show decoded arguments=1 Show decoded arguments in stack=1 Show arguments in call stack= 1 Show induced calls=1 Label display mode=0 Label includes module name=0 Highlight symbolic labels=0 Highlight RETURNs in stack=1 Ignore path in user data file=1 Ignore timestamp in user data file=1 Ignore CRC in user data file =1 Default sort mode in Names=1 Tabulate columns in log file=0 Append data to existing log file=0 Flush gathered data to log file=0 Skip spaces in source comments=1 Hide non-existing source files=1 Tab stops= 8 File graph mode=2 Show internal handle names=0 Hide irrelevant handles=0 Use RET instead of RETN=0 Show traced flags=1 Number of lines that follow EIP=0 Save out-of-module user data=0 CPU=194,324,812,360 ,3 CPU subwindows=327,798,321,798,537,771,479,909 OllyTest=0,0,1024,746,1 References=256,420,256,210,1 Breakpoints=75,248,626,168,1 Run trace=246,391,432,176,1 Patches= 0,210,256,210,1 Executable modules=263,41,636,175,1 Memory map=357 ,41,519,274,1 Bookmarks=110,145,624,175,1 Profile=132,174,624,182,1 Windows=132,177,614,179,1 Threads=155,204,492,124,1 Log data=421,107,378,221,1 Source=256,2 10,256,210,1 Handles=196,325,647,175,1 Source files=205,268,473,168,1 Call stack=0,420,256,210 ,1 Call tree=132,132,791,175,1 SEH chain=0,0,256,210,1 Watch expressions=256,0,256,210,1 CPU scheme=0 CPU Disassembler=7,0,0,0,0 CPU Dump=7,0,1,0 ,4353.0 CPU Stack=7,0,0,0 CPU Info=7,0,0,0 CPU Registers=7,0,0,0 References=7,0,1,0,0 Breakpoints=1,0 ,1,0,0 Run trace=1,0,1,0,0 Patches=1
Completion
This is the end of your acquaintance with the wonderful debugger OllyDebugger. Of course, it is impossible to describe all the capabilities of this debugger in the article, but I tried, and I hope it worked. Some possibilities are beyond the scope of this article, but I am sure that you will discover these opportunities for yourself. I taught Olly absolutely without any articles, and you will be able to continue familiarizing yourself with the debugger without anyone's help. If you have questions, suggestions, curse words, etc. send them all to [email protected].P.S. Be sure to read my article about unboxing using Olly.
