Ollydbg full tutorial single-step execution and automatic execution [step-by-step execution and animation] Hit trace [hit trace]

20. Single-step execution and automatic execution [step-by-step execution and animation]

You can perform one-step debugging on the program by pressing F7 (step-by-step) or F8 (step-by-step. The main difference between the two single-step operations is that if the current command is a sub-function, press F7 and it will enter the sub-function and stop it on the first command of the sub-function; press F8 to run the subfunction at a time. If a child function contains a breakpoint or other debugging event, the execution will be paused, but ollydbg will automatically start a breakpoint on the next command of the Child function, you will encounter this breakpoint sooner or later.

If the program to be debugged stops at an exception, you can skip it and go to the handle created by the program to be debugged. You only need a simple shift key and any single-step command.

If you need to press F7 or F8 for hundreds of times consecutively, you can use the automatic execution (CTRL + F7 or Ctrl + F8) function. In this case, ollydbg will automatically repeat F7 or F8 operations and update all windows in real time. This process will be stopped in the following situations:

-Press ESC or issue any one-step command

-Ollydbg encounters a breakpoint

-An exception occurred in the program to be debugged.

Use the "+" and "-" buttons to review the previous execution history [execution history].

Note: When the execution is stopped, ollydbg refreshes most windows. If the dynamic execution process is very slow, you can try to close or minimize useless windows.

In addition, the faster way to find the previously executed command is to run the trace [run trace]. It will create an execution protocol and inform you of the execution time and number of specified commands

 

 

 

Ii. Hit trace [hit trace]

Hit tracing allows you to identify which part of the code is executed and which part is not. The ollydbg implementation method is quite simple. It sets an int3 breakpoint for each command in the selected area. When the interrupt occurs, ollydbg removes it and marks it as hit [hit]. This method is very fast because each tracing breakpoint is executed only once.

When using hit tracking, be sure not to set breakpoints in the data, otherwise the application is very likely to crash. Therefore, you must open relevant menu options for code analysis [analyze]. I recommend that you select strict or heuristic function recognition [strict or heuristical procedure recognition]. Fuzzy [Fuzzy] may cause many intolerable errors, and the code segment that is not a function is often recognized as a function.

As long as you set a tracing breakpoint in the module, even if you only set one, ollydbg will allocate a buffer twice the size of the code segment.

Note: When you exit the hit trail, the run trail also exits.

Run trace [run trace]
Run tracking is a method of tracking program execution in the opposite direction. You can understand previous events. You can also use the run trace to learn the simple running statistics [Profile]. Basically, ollydbg executes the program to be debugged step by step, just like the animation [animation] demo, but does not refresh the window in real time, the most important thing is that it records the address, register content, messages, and known operands into the run trace buffer. If the code to be debugged is self-modified, you can save the original command. You can press Ctrl + F11 (run trace to step into the sub-function) or Ctrl + F12 (run trace step, once the sub-function is executed) to start the run trace, stop the trail with the F12 or ESC key.

You can specify the condition set for each step during the run trace (shortcut: Ctrl + T ). If the conditions are met, the run trace is paused. The conditions include:

? When the EIP is within a certain address range, [pause when EIP is in the address range] is suspended;
? When the EIP is out of a specific address range, [pause when EIP is outside the address range] is suspended;
? When a condition is true, [pause when some condition is true] is paused.
? When the next command is suspicious, suspend [pause when next command is suspicious]. For example, the command may be invalid (depending on the rules set in analysis 3 [Analysis 3 ), access to memory that does not exist. The single-step trap flag is set to [single-step trap flag] or the ESP access stack. Note that this option will obviously (about 20%) Slow down the run trace speed;

? [Pause after specified number of commands is traced] is paused when the command execution reaches the specified number of times (more specifically, the number of commands added to the buffer of the run trace). Note that the counter cannot be auto-zeroed. That is to say, if you set the number of commands to 10, the command is paused when the command is executed for 10th times, not once every 10 times.

? When the next command meets the specified style, pause [pause when next command matches one of the specified patterns]. You can use fuzzy commands and operands [imprecise commands and operands] and match 32-bit registers RA and Rb. Like R32, these two registers can replace any common 32-bit registers, however, the value of a command cannot be changed. And Ra and Rb
In the same command, it must be different. For example, the program contains the XOR eax, eax; xor esi, EDX commands, both of which comply with the style XOR R32, R32; the First Command conforms to the style XOR Ra, RA
And wait for two commands, xor esi, and EDX conforms to the style XOR Ra, Rb.

There is no doubt that the run trace requires enough memory, each command occupies 16 to 35 bytes on average, and the speed is also very slow. In a 5000-MHz processor and Windows NT environment, it can track commands per second.
Slower Windows 95: There are only 2200 commands per second. However, in many cases, for example, when a program jumps to a non-existent address, this is the only way to find the cause. You can skip the quasi-linear command sequence (that is, the sequence tail only has a unique exit) during the run trace. When ollydbg encounters these command sequences that need to be skipped, it sets a temporary breakpoint and then follows up to the sequence and runs it once. Of course, if the returned or redirected address in the exclusion command is out of the tracking range, an error may occur in the tracking; therefore, ollydbg will check the code block you want to skip. If the preceding situation exists, will ask you.

In most cases, you are not interested in tracing system API code. The trace option always follows the system DLL [always trace over system DLLs], allowing you to follow API functions in tracking/automatic mode. If the module is in the system directory, ollydbg assumes that the module is a system. You can mark any dll as a system or non-system in the module [modules] window.

To make the execution faster, you can set the run trace breakpoint to limit the run trace to the selected command or code block before running the program. I call this method "forced run tracing ". Generally, deleting a run trace breakpoint does not remove the hit trace breakpoint. However, if you delete the hit tracing breakpoint, you also remove the run tracing breakpoint.

The trace command is saved to the trace buffer, which is automatically created at the beginning of the trace. You can specify the size (up to 64 MB) in the options ). This buffer zone is a cyclic queue. When it is full, old records will be discarded.

You can enable or clear the run trace buffer by selecting debug [debug] | open or clear run trace [open or clear run trace] from the main menu of ollydbg. After the run trace buffer is opened,
Ollydbg records all pauses during execution, even those that are not caused by the run trace. For example, you can execute a program by pressing F7 or f8. then, you can use the + key and-Key to track program execution in reverse directions. Note: If the run trace buffer is disabled, these keys are used to browse history [history] records. When you view the run trace records, the registers and information panel become grayed out to emphasize that the registers they display are not actually registers. The Trace Buffer does not store the content at the top of the stack or pointed by registers. Registers, information, and stack use the actual memory status to explain changes in registers during run tracking.

The ollydbg can write down the number of times each command appears in the run trace buffer. In the Disassembly window shortcut menu, select view [view] | statistics as comment [profile as comments]. This command replaces the comment bar with statistics. Alternatively, if the column title bar is visible, you can click it several times until it displays statistics. Note that the displayed numbers are dynamic and do not calculate the discarded commands from the trace buffer. In the separate statistical window [profile window], you can sort the data by the number of triggers to view the statistics of the entire module.

Select "run trace [run trace] | add to all function entrances [add entries of all procedures]" in the shortcut menu of the Disassembly window. in this way, you can check the number of calls to each identifiable function. The other command "run trace [run trace] | add branches in procedure] to all branches of the function" forcibly traces the content of all recognized jump destination addresses in the function. In this case, the statistical function can find the branch with the most frequent execution, and you can optimize this part of Code to increase the speed.

In the Disassembly window, select "Search [search for] | the latest run trace [last record in run trace]" from the shortcut menu to find whether the command is executed. pass, if the execution is completed, where is the last execution.

The run trace window displays the content of the trace buffer. For each instruction, the content of the integer register changed by the instruction is included (more accurately, the change of the given record into the next record ). If you double-click a command, the window Selects all records containing the command in the trace buffer, and you can quickly browse by pressing the + and-keys; if you set "trace [trace] | synchronize CPU and
Run trace [synchronize CPU and run trace] ". Double-click the record to track the position in the corresponding Disassembly window.

Note: When you exit the hit trail, you also forcibly exit the run trail.