Menu
homeInternet

We select the most interesting plugins for OllyDbg. Olly Debugger from A to Z Ollydbg in games menu selection

Many reversers are familiar with OllyDbg, a free 32-bit user-mode debugger (ring 3). The main advantages of this debugger: free, small size, intuitive interface, ease of management and support for plugins that significantly expand its functionality. Today there are over 500 plugins, and among this variety we tried to highlight the most interesting ones for you.

OllyDumpEx

When solving various problems related to reverse engineering, or more precisely, when working with malicious software that actively uses various obfuscators and packers, quite often it is necessary to dump the memory of a process for its subsequent analysis. Since the process is active, most of its packers and obfuscators have already worked and you can see almost the true face of the scoundrel. So a process memory dumper is an irreplaceable thing in such tasks. Each researcher prefers one or another debugger, for example, because of the set of plugins, but sometimes it is necessary to vary them, and I would like to have the same interface and capabilities of the plugins, regardless of the debugger. OllyDumpEx Plugin solves this problem - it allows you to dump memory very flexibly and supports several of the most popular debuggers: OllyDbg 1/2, Immunity Debugger 1.7/1.8, IDA Pro, WinDbg. Tool Features:

Selecting an EXE file, DLL or other module for the dump; - search for MZ/PE signatures in memory; - support for PE32+; - support for native 64-bit processes (currently only in IDA Pro); - dump any address space as a section (even if it is not in the section header); - adding empty sections; - editing RVA in DataDirectory for subsequent changes in ImageBase; - automatic calculation of a large number of parameters (RawSize, RawOffset, VirtualOffset and others).

The project is actively being developed and is constantly tested by the author for compatibility with the latest versions of supported debuggers.

How to install plugins?

First, you need to create a folder in the program directory called Plugins. This will allow you to avoid littering the main directory in the future, and if necessary, you can easily find an inoperative/conflicting plugin. Next, copy the plugin DLL file to the created directory, then launch the debugger and specify the path to this folder:

  • OllyDBG v1.10: select Options -> Appearance and the Directories tab. In the Plugin path item, specify the path to the folder with plugins.
  • OllyDBG v2.01h: select Options -> Options and the Directories section. In the Plugin directory item, specify the path to the folder with plugins.

Restart the debugger and look for the item that appears in the Plugins menu.

OllyMigrate

  • For: OllyDbg 1.10/2.01, ImmunityDbg 1.7/1.8, IDA Pro, WinDbg 6

Each debugger has both strengths and weaknesses, and each one has its own - there is no perfect tool. In one it is convenient to bypass anti-debugging techniques, in another you can use a huge arsenal of ready-made plugins, and in the third you write your own scripts. Recently, it has become possible to work sequentially in OllyDbg, Immunity Debugger, WinDbg and IDA Pro. How? Meet OllyMigrate Plugin - this plugin allows you to transfer the debugging process to another debugger without restarting the application under study. So we can leverage only the strengths of each debugger by using migration from one to the other. For example, we can start with OllyDbg to bypass anti-debugging techniques and find OEP (Original Entry Point), and then transfer control to Immunity Debugger and, thanks to its support for Python scripts, edit the obfuscated Import Table. As you already understand, the plugin supports: OllyDbg 1/2, Immunity Debugger 1.7/1.8, IDA Pro, WinDbg. Peculiarities:

Multithreading and the ability to pause threads; - transferring software breakpoint settings (while maintaining the enabled/disabled status).


Setting up the graphic scheme

The standard OllyDbg color scheme is quite boring and not very informative. Of course, you can get used to it over time, but it is better to customize the appearance so that the eye can instantly navigate the assembly listing. Ultimately, productivity depends on this. You can customize the color scheme in two ways: directly from the “Options -> Appearance -> Colors” menu or by editing the ollydbg.ini file. You look for a section in the file and play with the color settings as you wish. This process is described in detail on the official website bit.ly/1cGR2zr.

OllySocketTrace

  • For: OllyDbg v1.10

Plugin for tracing all socket operations performed by a process. During program execution, records all buffers sent and received, as well as all parameters passed to network functions and the values ​​returned by those functions.

The following socket operations are currently supported: WSASocket, WSAAccept, WSAConnect, WSARecv, WSARecvFrom, WSASend, WSASendTo, WSAAsyncSelect, WSAEventSelect, WSACloseEvent, listen, ioctlsocket, connect, bind, accept, socket, closesocket, shutdown, recv, recvfrom, send and sendto.

Just run the plugin whenever you want to monitor socket operations. OllySocketTrace will automatically place all necessary breakpoints and record all necessary information as soon as they are triggered. To view the resulting result, you need to select the OllySocketTrace Log menu item.


OllyHeapTrace

  • For: OllyDbg v1.10

Plugin for tracing heap manipulations. Intended primarily for debugging heap overflows when it is necessary to control the location of the heap while rewriting a specific structure, such as a block header, critical section structure, or other application data. When activated, the plugin automatically creates breakpoints (RtlAllocateHeap, RtlFreeHeap, RtlCreateHeap, RtlDestroyHeap, RtlReAllocateHeap, RtlSizeHeap, GetProcessHeap and RtlInitializeCriticalSection, RtlDeleteCriticalSection) and writes the necessary information when it reaches them. Peculiarities:

  • view heap trace;
  • Highlighting each individual heap trace in different colors;
  • filtering “extra” information for a specific heap.

Pyllow

  • For: OllyDbg v2.01

Why do so many reversers use Immunity Debugger? Yes, because it, like IDA, has built-in Python support. This scripting language allows you to greatly simplify the task of studying binary code, allowing you to quickly write a small script that automates one or another routine task. Unfortunately, naked OllyDbg only supports its assembly-like language for writing automation scripts. Fortunately, a guy under the nickname Pablo Escobar decided not to put up with this state of affairs and wrote a plugin for OllyDbg that integrates Python support into it - Pyllow. Now you can write scripts that automate the routine work of the reverser, which will run inside the debugger and have access to most of the OllyDbg API. The plugin is distributed in source code, so I’ll say a few words about its assembly. To compile it you will need Visual Studio 2010, the Boost library, compiled Boost.Python, and a 32-bit version of Python 3.x (tested on 3.2). Depending on your OS settings, you may have to tell Boost all versions of Python installed on your system and then select the one you want during build. This can be done by adding lines like this to the /boost-dir/tools/build/v2/user-config.jam file:

Using python: 3.2: "C:/Program Files (x86)/Python32/python.exe" # path to your Python setup: : : 32 # x86-32 only ;

The main thing here is to indicate the correct path to the interpreter. Then build Boost.Python using the command:

Bjam --toolset=msvc-10.0 --build-type=complete --with-python python=3.2 address-model=32

If any difficulties arise, the official Boost manual should help bit.ly/14FU7xP

OllyGraph

  • For: OllyDbg v2.01

One of the features that particularly appeals to me about IDA Pro is the ability to represent a function as a graph. This makes it much more convenient to analyze the code; it immediately becomes clear how we got to this or that section, what conditions worked and how they worked. Plus, you can also look at the call graph to understand from which places in the program the function under study is called. Fortunately, this feature is now available in OllyDbg, you just need to install the OllyGraph plugin. It allows you to present the program in the form of block diagrams, similar to those built in IDA Pro. Moreover, the wingraph32 tool, which is part of the ida, is used for visualization. For version 1.10 there is an alternative plugin OllyFlow bit.ly/14lNtpb - a slightly improved version of OllyGraph from the same author.


InjectHookLib

  • For: OllyDBG v1.10

Quite an interesting extension that allows you to intercept system calls from user mode. The interception technique is interesting, so I recommend that you read it on the author’s blog (bit.ly/OjxUMj for Windows XP, bit.ly/NZW6Ci for Windows 7). All that is required from the user is to install the plugin and write your own DLL library in which handlers for intercepted functions will be implemented. How to implement it, you can look at the links or study the source code of the example bit.ly/168kcF2, which was kindly provided by the author of this extension. Such a plugin can be useful for solving various tasks, for example, when analyzing malware and unpacking.


uberstealth

  • For: OllyDbg v2.01, IDA Pro

What lengths will program developers go to in order to protect their brainchild from research! Various packagers especially abound with such gifts, although among ordinary programs there are also quite often individuals packed with anti-debugging techniques. Manually bypassing all these protections will simply get boring - just editing the value returned by the IsDebuggerPresent function will not do. So you have to use special tools in the form of this plugin. It comes in source code, so you have to assemble it manually. To do this, you will need the Boost library>=1.48.0, WTL (Windows Template Library)>=8.1, Windows Driver Kit>=7.0, DDKBuild. Yes, yes, your eyesight has not failed you - WDK & DDK, since the debugger uses drivers to hide itself. And of course, Visual Studio 2008. Interestingly, the plugin works not only in OllyDbg, but also in IDA Pro.

Essential plugins

In addition to advanced plugins that may not be used very often, you also need to have a gentleman's set for every day. Typically this set includes the following extensions:

  • Command Bar bit.ly/14GHQcr - an analogue of the built-in Command Line plugin. Adds a command line panel for entering debugger control commands, which allows you to speed up the debugging process.
  • PhantOm Plugin bit.ly/qyNqJO - anti-debugging plugin from a Russian developer to hide OllyDbg and fix debugger vulnerabilities exploited by the protector. Helps against most common detection methods.
  • The Chinese plugin StrongODbit.ly/gzazAd has similar functionality. There were even rumors about ripped code from PhantOm found in it.
  • Anti-debugging properties are also present in Olly Advanced bit.ly/14GI0An. This is a kind of Swiss Army knife that, among other things, expands the functionality of OllyDbg and eliminates some annoying things and bugs of this debugger.
  • An equally important plugin is ODBGScript bit.ly/17Is2AM, which allows you to write and execute scripts to automate the necessary process, such as unpacking files.
  • Last on the list is OllyDump bit.ly/17Is4si - an excellent process dumper with a built-in import table reconstructor.

OllyMSDN

  • For: OllyDbg v1.10, Immunity Debugger 1.7/1.8

The number of WinAPI functions is huge, and knowing them all like the back of your hand is simply unrealistic. Therefore, sometimes you have to look at the documentation to clarify/find out what a particular function returns or what parameters it takes as input. Unfortunately, the standard help file can't provide all the information you need, so you have to fire up your browser and go to MSDN. So why not completely replace this file with online documentation? To do this, you just need to install the OllyMSDN plugin, make sure that we have the WIN32.HLP file as help (Help -> Select API help). If there is no such file, then you need to create an empty one with the same name and point it to Olly. Now, when you try to access the help file in the debugger, the plugin will intercept the WinHelp() API function and open the MSDN site for you instead of the old file. And to get information about a specific function during debugging, you need to right-click on the call instruction and select Help on symbolic name or just click .


DetachMe

  • For: OllyDbg v1.10

One of the useful features that appeared in the second version of OllyDbg was the Detach function, which made it possible to “detach” the debugger from the process under investigation so that the process could continue to work independently. Unfortunately, version 1.10, beloved by many, does not have such a function - you can only join the process under study. But this can be fixed by installing the DetachMe plugin, which allows you to detach the debugged programs from OllyDbg at any time and continue to exercise external control over the debugger. In addition, disabling software and processor breakpoints will not affect the corresponding udd files.

OllyDbg PDK

There are no plugins for all occasions, so sooner or later there may come a time when you have to “make an outfit” for Olya yourself in order to solve the next ambitious task. In this case, you will need PDK - Plugin Development Kit, which can be downloaded from the official website bit.ly/18oD7t6.

Ollydbg-backup

  • For: OllyDbg v1.10 / v2.01

While working on the next binary, the reverser has to add quite a lot of his own information: write comments to the reversed functions, so that the next day he does not have to re-learn the algorithm of their operation and input parameters, set breakpoints, and so on. All this service information is automatically saved by the debugger in a UDD file. But it happens that when the debugger crashes or is reinstalled again, these files are lost. And we need to start the analysis again. To avoid such a sad situation, you can use the ollydbg-backup plugin, which allows you to backup this information by saving it to a CSV file, from which it can be easily loaded back into the debugger. The CSV file has the following structure:

RVA,label,comment

Conclusion

OllyDbg is a very popular debugger; there are quite a lot of plugins for it, and you can talk about them for a long time. Our goal was not to consider them all, we only tried to select the most interesting “outfits” for our fighting friend Olya. I hope we succeeded.

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 convenient 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 does not support SSE2.

Setup. More than 100 options control the operation of the program.

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

TO How to start a debugging session

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 have 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. After 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 .udd. .udd files save breakpoints, marks, comments, observers, analysis, and so on between debugging sessions. OllyDbg automatically creates a .udd file when the module is unloaded.

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 for an 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 at the same time.

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.

Basically, I have always used the debugger of all times OllyDbg for debugging. This is a chic debugger that is very convenient and simple and at the same time has very powerful functionality. But lately I have been increasingly faced with x64 programs, and my home computer is running on an x64 operating system, and OllyDbg version 1.10 does not work correctly on such an operating system, it loses its entry point and everything is generally sad. Attempts to use the newer version 2.01a were also unsuccessful, since it freezes at an unexpected moment and stops responding. Of course, you can roll out a bunch of patches from Chinese friends and more or less revive the debugger, but there are still a huge number of bugs and it looks like development has stopped (since August 2011, no progress) made me look towards Interactive Disassembler, abbreviated IDA. This is a powerful tool for debugging and researching programs that has a bunch of necessary and not so unnecessary tricks and tricks.
But it also has some disadvantages that always stopped me from studying this powerful tool:
1. There is little sane documentation, of course there are books from the respected Mr. K. Kaspersky, but they are so ancient that there is a sense in reading them, but in current realities it is not very much, mainly for general development.
2. The price of this product from X-Rays is a starting license of more than 500 Australian dollars, and this does not include X-Rays Decompiler, which costs quite an inadequate amount of money.
But OllyDbg's disappointment prevailed over my toad and common sense, and I decided to start studying IDA after all.


A small digression - don’t ask me where to download IDA for free and without SMS, or rather you can ask, but I don’t know and I’ll send it to this website.

First of all, I looked for information about manuals and was somewhat disappointed, there is quite a bit of information and it is outdated, there are forums where people exchange all sorts of useful things about IDA, but first I had to take at least the young male course. A video guide from TiGa helped me with this, you can take it. After spending almost the whole weekend and drinking half a box of beer, I watched all the video tutorials. After which I had an idea, why not try to understand IDA with the help of good old articles from Ricardo Navaja entitled “Introduction to cracking from scratch using OllyDbg”, you can read them in Russian, for example, a question may arise, what does OllyDbg and IDA, but because the articles are very detailed and I will look for similar elements in IDA, which will give me a basic understanding of working with IDA.

So, I will not describe the basic skills when working with assembler as in the articles of Ricardo Navaja, since I think those who switch to IDA already understand a little what a stack is, registers, how memory works and what a conditional and non-conditional jump is, but let’s immediately start researching programs that are described in Ricardo's articles. I'll try to go through all his articles analyzing the crackme he mentions.

The first article in which crackme is already being analyzed is chapter number 9, but for me it will be the first chapter.
Download the necessary file that will be examined, for example from the site wasm.ru
Launch IDA and open the file in it via File->Open. Then we see the following picture:

All settings can be left at default, since they basically don’t tell me anything special at the moment. Click OK and see the main IDA window:


The following positions are highlighted by circles with numbers:
1. Information about the base, entry point, size of the virtual and real code section and other useful information about the section.
2. Functions that are found in the program, functions that are imported from external libraries are indicated in pink. start- most often this is a function that comes at the entry point, by the way, look at the options Entery Point you can press the hotkey CTRL+E.
3. Actually, the assembly code itself of the current open function, if you don’t want to look in graphical mode, you can switch it to a text continuous sheet by space, right-click switches back to graphic in the Graph view listing.
4. A minimap of functions with all the transitions and such is very useful for orientation in the code.

In order to be able to run an application in a debugger, you must select the debugger itself, since listing code is not debugging.
Click F9 or select the option at the top Debugger- a window called Select a debugger in which we select Local Win32 debugger For starters, this debugger will be enough for us, and we will deal with the rest later.

Click again F9 and the program starts without stopping at Entery Point as in OllyDbg. This can be corrected if you want to constantly stop at the very beginning, go to the bookmark again Debugger and there we choose Debugger Options in the window that opens, you can check the box Stop on process entry point and we get the same reaction as in OllyDbg; when we start debugging, we stop at the entry point. But you can also immediately set a breakpoint manually if necessary by looking at the ASM listing and stop there.

Now let's look at the debugger window:


The arrows show the main elements of the interface, they are not very different from the same OllyDbg, although there are some additions, for example, display not in the form of a listing, but in a graphical form, do not forget that we can always switch to the listing from the graphical mode by space and most often also back. There is a panel with a log and a graphic display map.

What else do we need here? The main tools are shown in the following picture:


Disassembly- actually calls up a window with a disassembled program.
Hex Dump- opens a window with a dump.
Pseudocode- this function tries to convert ASM code into a pitiful semblance of C.
Exports- what the program or library exports.
Imports- what the program or library imports.
Names- a list of API names found in this executable.
Functions- a list of functions found in the program.
Strings- text strings detected in the program.
Segments- segments that are detected in memory.
That's enough for a start, since the purpose of the other functions is not yet very clear, and the current one will be needed to study the first crackme program.

Now a little about the debugger, the main keys remain standard
F9- execute the program
F8- trace without going into the function
F7- trace going into functions
F2- remove/install a breakpoint on the line where the cursor is currently located.

How to distinguish in IDA where we are now in the program that we are debugging or are already rummaging through the import dll - you can look in text form to the left of the position number and see a description, for example like this:
kernel32.dll:764FD8F3 mov edi, edi
Well, according to the word kernel32. It immediately becomes clear that we are now in the kernel.

Well now, anyway, let's return to our long-suffering crackme.
Let's launch it and try to enter some kind of name and serial number, a message box will appear that will say “No luck there, mate!” This means we didn’t guess the name and user. Let's try to catch this message and see how we can force it to produce the correct message that the name and serial number are correct. It is known that the failure message output uses a standard API function MessageBoxA, so we need to put a breakpoint on it.
Let's go to View->Open SubViews->Functions or pressing Shift+F3 and here we see all the functions that we were able to determine IDA.
Select the function we need MessageBoxA and using the right-mouse drop-down menu, set a breakpoint on the function. Something like this:

OK. Installed, we will continue executing the program and try to enter the wrong name and serial number again. (By the way, you can most often return to the default debugging window with the button ESC)
Debugging stopped at the output of a message about incorrect login and password, great, let's see what useful information we can extract.
We find ourselves at the entrance to the MessageBoxA function, the function itself is not interesting to us, so we click CTRL+F7 which means, execute the code until the first ret is detected, that is, the function exits. After all the manipulations, the main window of the disassembled code looks like this:

Yeah! This is a procedure that passes arguments to MessageBoxA which displays a message about the wrong serial number and name. Since the purpose is clear, you can immediately rename the function by right-clicking (right mouse button) on sub_401362 and selecting the item there Rename or using the hot button N. I'll call this function AHTUNG! :)

Let's look further at where the legs of this procedure come from and what lies behind it. Let's click F8 and we will reach the top level. And there you can immediately see some kind of check with arrows, one arrow to the left leads to a harmful procedure AHTUNG, but the second one is not very clear, but it’s visible there CALL and address sub_40134D, it’s very interesting to see what’s there. Option 2 in principle, 1 is to click 2 times LMB (left mouse button) on sub_40134D and get into this function, and the second one is just hover your mouse over the same sub_40134D and wait half a second, which will show a piece of this function, something like this:

It’s already very interesting, it looks like another verification option leads to the correct window. Let's call this procedure GOOD.
We remove the old breakpoint on MessageBoxA, we don't need him, let's go to Debugger->Breakpoints->Breakpoint List and delete the old breakpoint in the window that opens.
Now you need to put a breakpoint on jz check over these procedures AHTUNG And GOOD either by RMB and selecting the appropriate option or hotkey F2. Let's restart the program and take a look around.
We will get the following window:

Unfortunately, it’s not visible in the static picture, but take my word for it, at the moment the arrow that leads towards the procedure is blinking AHTUNG and this is not very good. It would be nice for us to have a green arrow blinking in the direction of the procedure that we called GOOD. To do this, you need to set the ZF flag to 1. RMB on the flag and select the option Increment Value or select the flag and click on the button +(plus) numeric keypad. Of course, it’s better to watch it in dynamics, it’s hard to see in static pictures, but now the arrow is blinking to the side GOOD procedure in the listing it looks like this:

Here it is more clear in static terms, when ZF = 0, the transition does not take place and looks like a dotted line, accordingly we end up on the AHTUNG procedure, and when it does, we can see a thick green arrow and it leads to the GOOD procedure.
Well, let's finally press F9 and enjoy the result: Great work, mate. Now try the next CrackMe.


True, if you close the program and open it again in the debugger, the flag will of course disappear, you need to come up with something to patch it and no longer pervert with flags, the simplest option, this is the place JZ do JNZ, so that, on the contrary, any incorrect serial number, except the correct one, will be accepted.
Hex code JZ - 74 , and the JNZ code is 75, it means we need to change the byte, go to the line we want to change, go to Edit->Patch program->Change Byte.
A panel with a set of bytes will appear:
74 07 E8 18 01 00 00 EB 9A E8 FC 00 00 00 EB 93
it is necessary to correct the first digit by 75 to make it work
75 07 E8 18 01 00 00 EB 9A E8 FC 00 00 00 EB 93
You will be able to see the changes in the disassembled code.
Thus, any serial number except the correct one will now pass correctly, although I think that this is a dirty trick, it is better to either know the serial number or make an unconditional one J.M.P.

Let's save the result of the patch, File->Produce File, a bunch of possible saves will fall out, even in EXE, but for some reason it doesn’t work, so let’s save it as banal DIF.
Let's look at the file to see what happened:

Just what you need.

Well, that's all for today, the next part, I think, will be in a week.

Sandbox

new player January 7, 2016 at 01:36 pm

Basics 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 following 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