9. breakpoint [breakpoints]
Ollydbg supports several different types of breakpoints:
-Generally, the breakpoint [ordinary breakpoint] replaces the first byte of the command you want to interrupt with a special command int3 (debugger trap. In the Disassembly window, you can select the command line for breakpoint setting and press f2 to set a breakpoint of this type. You can also set it in the shortcut menu. When you press the F2 key again, the breakpoint will be deleted. Note that the program will be interrupted before the command is executed.
There is no limit on the number of int3 breakpoint settings. When you close the debugged program or debugger, ollydbg automatically saves these breakpoints to the hard disk and never tries to set these breakpoints in the middle of the data segment or command, if you try to set a breakpoint outside the code segment, ollydbg will warn. You can always disable this prompt in the security option [Security Options]. In some cases, the debugger inserts the built-in temporary int3
Breakpoint.
-Conditional breakpoint [conditional breakpoint] (shortcut key shift + F2) is a normal int3 breakpoint with a conditional expression. When a debugger encounters such a breakpoint, it calculates the value of the expression. If the result is non-zero or the expression is invalid, the program to be debugged will be suspended. Of course, the overhead caused by a breakpoint with false conditions is very high (mainly due to the OS response time ). In a Windows NT, Pentium II/450 processor Environment
Ollydbg processes a maximum of 2500 false breakpoints per second. A typical usage of conditional breakpoints is to set breakpoints (such as wm_paint) on Windows messages ). Therefore, you can use the pseudo-variable MSG together with the appropriate parameter descriptions. If the window is activated, refer to the Message breakpoint description.
-The condition record breakpoint [conditional logging breakpoint] (SHIFT + F4) is a condition breakpoint. Whenever such a breakpoint is encountered or meets the condition, it records the values of known function expressions or parameters. For example, you can set a record breakpoint on some window procedure functions to coordinate all calls to the function. Or, you can only disconnect the received wm_command message identifier, or disconnect the createfile function, and record the file name opened in read-only mode, the speed of recording breakpoints is the same as that of the condition breakpoint, and browsing hundreds of messages from the record window is much easier than following hundreds of F9 times. You can select a pre-defined explanation for the expression.
You can set the number of times that pass-each time the pause condition is met, the counter will be reduced by one. If the count is not equal to zero before the minus one, the ollydbg continues to run. If a cycle is executed for 100 times (decimal), set a breakpoint in the loop body and set the number of passes to 99 (decimal ). The ollydbg will be paused during the last execution of the loop body.
In addition, the condition record breakpoint allows you to pass one or more commands to the plug-in [plugins]. For example, you need to use the command line plug-in to change the content of a register and then continue to execute the program.
-The message breakpoint [Message breakpoint] is basically the same as the condition recording breakpoint. Except for ollydbg, a condition is automatically generated, which allows you to set certain messages (such as wm_psint) at the entrance of the window process, you can set it in [windows.
-The trace breakpoint [trace breakpoint] is a special int3 breakpoint set on each selected command. If you have set the hit trace [hit trace], the breakpoint will be removed after the command is executed, and a mark will be made at this address. If you are using the run trace [run trace], ollydbg adds the trace data record and the breakpoint remains active.
-Memory breakpoint [Memory breakpoint] ollydbg allows only one memory breakpoint at a time. You can select a part of memory in the Disassembly window, CPU window, and data window, and then use the shortcut menu to set the memory breakpoint. If there is a previous memory breakpoint, it will be automatically deleted. You have two options: Memory Access (read, write, execution) is interrupted, or memory write is interrupted. When this type of breakpoint is set, ollydbg will change the attribute of the memory block of the selected part. 4096 bytes of memory will be allocated and protected on a x compatible processor. Even if you select only one byte, The ollydbg protects the entire memory block. This will cause a large number of error warnings. Please use such breakpoints with caution. Some system functions (especially in Windows 95/98) not only do not generate debugging events when accessing the protected memory, but cause the program to crash.
-Hardware breakpoint [hardware breakpoint] (only available in Windows ME, NT or 2000) is on an 80x86 compatible processor. You can set four hardware breakpoints. Unlike the memory breakpoint, the hardware breakpoint does not reduce the execution speed, but can only cover up to four bytes. Ollydbg can use hard breakpoint to replace int3 breakpoint when executing or tracking code in a single step.
-Memory Access one-time breakpoint [single-shot break on Memory Access] (only available in Windows NT or 2000 ). You can set the breakpoint for the entire memory block through the shortcut menu (or press F2) in the memory window. This type of breakpoint is particularly useful when you want to capture calls or return to a module. When an interruption occurs, the breakpoint is deleted.
-Pause the run trace [run trace pause] (shortcut: Ctrl + T). It is a condition set to be checked during each run trace [run trace. you can suspend an EIP when it enters a certain range or exceeds a certain range. If a condition is true, it is paused when the command matches the specified mode, or when the command is suspicious. Note that this option greatly reduces the running trace speed (up to 20%.
Ollydbg can also suspend program execution on some debugging events [debugging events. For example, when the DLL is loaded or uninstalled, the thread is started or terminated, or the program sends a debug string.
10. Data window [dump]
The data window is used to display the memory or file content. You can select a display mode from the following pre-processing format [predefined formats]: byte [byte], text [text], integer [integer], floating point [float
], Address [address], disassembly [disassembly], PE Header [PE Header].
All dump Windows support backup [Backup], search, and editing. The CPU window [dumppanel of the CPU windowless allows you to perform the following operations on memory ing of executable code data and executable file (.exe, or. dll): define the Label [labels] And set memory breakpoint [Memory breakpoints]. For details, refer to [references]. Data menu [dump menu] Only displays commands related to the selected part.
If the backup [Backup] is available, click the title bar of the first column to switch between the display modes of Address [address]/backup [Backup. Click the title bar of another column to change the dump mode.
Like the Disassembly window, the data window also stores a large number of historical records for viewing memory addresses. You can use the "+" and "-" keys to access the data address space you have viewed in the past.
To flip a byte of data, press Ctrl L and press the up/down arrow key.
Executable module window [executable modules window]
The executable module window (shortcut: Alt + E) Lists All executable modules loaded by the current debugging process. It also displays a lot of useful information, such as the module size, entry address, module version, and executable file path. Some information, such as the module size displayed in decimal format, the entry address symbol name, and whether it is a system module, is usually hidden. If you want to see it, you can increase the width of the corresponding column. The shortcut menu supports the following operations:
Refresh the [actualize]-re-scan the module and remove the highlighted display of the new loaded module. In most cases, ollydbg automatically performs this operation.
View memory [view memory]-Open the memory window and locate the first memory block that belongs to the module image.
View the code in the CPU window [view code in CPU] (shortcut: Enter key)-display the executable code of the module in the Disassembly window.
Follow up to the entry [follow entry]-Follow up to the entry of the module in the Disassembly window.
View data in the CPU window [dump data in CPU]-display the data segment of the module in the data panel of the CPU window. Block Code segment.
Display name [view names] (shortcut: Ctrl + n) -Display All names defined or used by the current module [names] (including output tables, import tables, link libraries, and user-defined ).
Mark as system DLL [Mark as system DLL],
Mark as non-system DLL [Mark as non-system DLL]-mark the selected module as a system or non-system attribute. If it is set to a system attribute, this module is directly executed (not tracked) during run trace [run trace], which greatly speeds up tracking. By default, all reside in the system directory (usually C:/Windows/System in Windows 95/98 and C:/winnt/system32 in winnt/2000/XP) all modules are considered as system modules.
Update now. UDD file [update. UDD file now]-to the file "<Module name>. UDD writes all data related to the module. The UDD file stores the breakpoint, Tag, comment, monitoring, analysis, and other information set during debugging. When the module is uninstalled, ollydbg automatically creates the. UDD file.
View the executable file [view executable file]-displays all the content of the executable file.
View all resources [view all resources]-displays all resources defined by the module in a list with a brief information. Ollydbg does not support resources as separate entities. You can extract [dump] and edit it in binary format.
View resource string [view resource strings]-display the resource string and its identifier in the form of a list.
View run trace statistics [view run trace Profile]-calculate statistics in this module [Profile]. Related information: run trace [run trace].
Analyze all modules [analyze all modules]-allow simultaneous analysis of all modules. Analysis extracts a large amount of useful information from the code. After the code is analyzed, debugging is usually very fast and reliable.
Double-click a line to display the code executed by the module in the Disassembly window.