What is ollydbg?

Full ollydbg tutorial

1. What is ollydbg?

Ollydbg is a 32-bit assembly-analysis debugger with a visualized interface. It can solve the problem when no source code is available, and can solve the problem that other compilers cannot solve.

Version 1.10 is the final release version. This project has been stopped and I no longer support this software. But don't worry: The New ollydbg 2.00 will be available soon!

Operating Environment: The ollydbg can work in any Windows 95, 98, me, NT or XP (not fully tested) Operating System Using the Pentium processor, however, we strongly recommend that you use a-MHz or above Pentium processor to achieve the best effect. Also, ollydbg occupies a very high percentage of memory. Therefore, if you need extended functions such as tracing debugging [trace], we recommend that you use a memory of over MB.

Supported processors: ollydbg supports all 80x86, Pentium, MMX, and 3 dnow! And athlon extended instruction sets, SSE instruction sets, and related data formats. However, sse2 instruction sets are not supported.

Configuration: there are as many as a hundred (days !) Options are used to set the appearance and running of the ollydbg.

Data format: All data formats displayed in the ollydbg data window: hex, ASCII, Unicode, 16/32-bit/unsigned/Hex integer, 32/64/80-bit floating point number, address, disassembly (MASM, ideal or HLA), PE file header or thread data block.

Help: This file contains necessary information about understanding and using ollydbg. If you still have a Windows API help file (win32.hlp is not included due to copyright issues), you can link it to the ollydbg to quickly obtain help from system functions.

Start: You can specify the executable file in the form of a command line, select from the menu, or drag and drop it to ollydbg, or restart the last program to be debugged, or [Attach] A running program. Ollydbg supports instant debugging. The ollydbg does not need to be installed at all. It can be run directly on a floppy disk!

Debug DLLs: You can use ollydbg to debug the standard dynamic link library (DLLs ). Ollydbg automatically runs an executable program. This program loads the Linked Library and allows you to call the output function of the Linked Library.

Source code-level debugging: ollydbg can identify debugging information in all Borland and Microsoft formats. The information includes source code, function name, Tag, global variable, and static variable. Limited support for dynamic (stack) variables and structures.

Code highlighting: The ollydbg anti-assembler can highlight different types of commands (such as jump, conditional jump, inbound stack, outbound stack, call, return, special or invalid commands) and different operands (General [general],
FPU/SSE, segment/system register, operand in stack or memory, constant ). You can customize a personalized highlight solution.

Thread: ollydbg can debug multi-threaded programs. Therefore, you can switch between multiple threads to suspend, resume, terminate, or change the thread priority. In addition, the thread window will display errors of each thread (just like the error returned when getlasterror is called ).

Analysis: one of the biggest features of ollydbg is analysis. It analyzes function procedures, cyclic statements, selection statements, table [Tables], constants, strings in the code, fraudulent instructions [tricky constructs], API calls, and number of parameters in the function, import table and so on .. These analyses increase the readability of binary code and reduce the possibility of errors, making debugging easier.

Object scan. Ollydbg can scan the object file/Library (including the OMF and coff formats), decompress the code segment [code segments], and specify its location.

Implib scan. The index numbers used by the output functions of some DLL files have no actual meaning for people. If you have an input Library [import library] corresponding to the DLL, ollydbg can convert the serial number into a symbolic name.

Full support for Unicode: almost all operations that support ASCII also support Unicode, and vice versa.

Name: ollydbg displays the input/output symbols and names based on debugging information in Borland and Microsoft formats. The object scanner can recognize database functions. You can add any name or comment. If some functions in the DLL are output by the index number, you can restore the original function name by attaching the input Library [import library. Furthermore, ollydbg can recognize a large number of constant Symbol names (such as window messages, error codes, bit domains [bit fields]…). And can be decoded into known function calls.

Known functions: ollydbg can recognize more than 2300 common functions in C and Windows APIs and their parameters. You can add description information and pre-defined decoding. You can also set log breakpoints in known functions and record parameters.

Function call: The ollydbg can trace back a recursive call without debugging information or when the function process uses a non-standard start part [Prolog] and the end part [epilog.
Note:
004010d0 push EBP/
004010d1 mov EBP, esp |
004010d3 sub ESP, 10 h | PROLOG
004010d6 push EBX |
004010d7 push ESI |
004010d8 push EDI /......
004010c5 pop EDI/
004010c6 pop ESI |
004010c7 pop EBX | epilog
004010c8 mov ESP, EBP |

004010ca pop EBP |
004010cb RET/
STACK: In the Stack window, ollydbg can intelligently identify the return address and stack framework [stack frames]. And some previous calls will be left. If the program stops on a known function, the Stack window will analyze and decode its parameters.

Note: The stack framework [stack frames] refers to a memory area used to store function parameters and local variables.

Seh chain: trace the stack and display the structured exception handling chain. All links are displayed in a separate window.

Search: there are too many methods! You can perform exact and fuzzy search for commands or command sequences, search for constants, binary and text strings, search for all command addresses, search for all constants or address fields [address range], search for all the functions that can jump to the selected address, search for all called and called functions, search for all reference strings, and search for all called and searched function names in different modules, search for binary sequences in all allocated memory. If multiple results are found, you can perform quick operations on them.

Window: The ollydbg can list various windows in the debugging program and set breakpoints in windows, classes, and even selected messages.

Resource: If the Windows API function uses a reference resource string, the ollydbg can display it. The supported display types are limited to the List, data display, and binary editing of the attached resource [attached resources ,.

Breakpoint: ollydbg supports various breakpoints: General breakpoints, conditional breakpoints, recording breakpoints (such as recording function parameters to record windows), memory read/write breakpoints, and hardware breakpoints (only applicable to me/NT/2000). In the case of hit tracking, you can set int3 breakpoint on each command of the module. In Windows NT with a 5000-MHz processor, the ollydbg can handle up to interrupts per second.

Monitor and monitor: Each monitor is an expression and can display the expression value in real time. You can use registers, constants, address expressions, Boolean values, and any complex algebra operations. You can also compare ASCII and Unicode
String. The monitor [inspectors] is a monitoring [Watches] that contains two index sequences. It is presented in the form of a two-dimensional table and can decode and analyze arrays and structures.

Heap walk.: IN Win95-based systems, ollydbg can list all allocated heaps.

Handle: In an NT-based system, ollydbg can list all system handles of the program to be debugged.

Execution: You can perform, step into, or step through a subroutine in one step. You can also execute the program until the function returns and the specified address. It can also be automatically executed. When the program runs, you can still manipulate the program and view the memory, set breakpoints, or even modify the code. You can also pause or restart the program to be debugged.

Hit tracking: The. Hit tracking shows the currently executed commands or function processes, helping you verify the branches of the Code. The hit trace sets a breakpoint before the specified command arrives, and the breakpoint is cleared after the command is executed.

Note: Hit means "hit" in English. If a command runs, it indicates that the command is "hit". If no command is executed, it means "not hit ", in this way, we can easily see which parts of the program to be debugged are running and which ones are not.

Run trace: The run trace can be used to execute a program in one step. It simulates the program running in a large loop buffer. This simulator contains parameters for registers, logos, thread errors, messages, and functions except the SSE instruction set. You can save the command so that you can easily debug the self-modified code (for example, shell program ). You can set conditional interruptions, including address ranges, expressions, and commands. You can
Save the trace information to a file to compare the differences between the two operations. The run trace can trace and analyze the details of millions of commands that have been executed.

Statistics: [profiler] can be used to calculate the number of times certain commands appear during tracking. Therefore, you can understand which part of the code is frequently executed.

Patch: the built-in assembler can automatically find the modified Code segment. The binary editor synchronously displays the modified data in ASCII, Unicode, or hexadecimal format. The modified data is the same as other data and can be copied and pasted. The original data is automatically backed up for data recovery. You can copy the modified part to the execution file, and the ollydbg automatically fixes the modification. Ollydbg also records all patches used during previous debugging. You can activate or disable a patch by using the space key.

Self-extracting files: When debugging self-extracting files, you often want to skip the decompression part and directly stop at the original entry point of the program. The self-extracting tracking of ollydbg will enable you to achieve this goal. If it is a protected self-extracting segment, the self-extracting tracking often fails. Once ollydbg finds the entry point, it will skip the decompression part and arrive at the entry point accurately.

Plug-in: you can add your plug-in to ollydbg to add new features. The ollydbg plug-in can access the structure of almost all important data, add menus and shortcuts in the ollydbg window, and use more than 100 plug-in API functions. The plug-in API functions are described in detail. By default, the installation includes two plug-ins: the command line plug-in and the bookmarks plug-in.

UDD: ollydbg saves all program or module-related information to a separate file and continues to be used when the module is reloaded. The information includes tags, comments, breakpoints, monitoring, data analysis, and conditions.

More: The functions described here are only some of the ollydbg functions. Because of its rich features, ollydbg can become a very convenient debugger!