Hit跟踪［Hit trace］
Hit trace gives you the possibility to check which parts of the code were executed and which not. The method implemented in OllyDbg is rather straightforward. It sets INT3 breakpoint on every command within the specified region. When breakpoint executes, OllyDbg removes it and marks command as hit. As each trace breakpoint executes only once, this method is very fast.

When using hit trace, special care must be taken not to set breakpoint on data, or with high probability application will crash. For this reason, you must analyze code to enable corresponding menu options. I recommend that you select strict or heuristical procedure recognition. Fuzzy option is too error-tolerant and often finds non-existing procedures.

When you set trace breakpoint even on a single command within the module, OllyDbg allocates trace buffers of twice the size of code section.

Note that when you remove hit trace, you simultaneously remove forced run trace.

See also: Disassembler menu, Run trace, Trace options

$#KRun跟踪［Run trace］
Run trace is the way to backtrace program execution that precedes some event. You can also use run trace for simple profiling. Basically, OllyDbg executes debugged program step-by-step, like in animation, but it doesn't redraw windows and - most important - logs addresses, contents of registers, messages and known operands to the run trace buffer. If debugged code is self-modified, you can save original commands. Start run trace by pressing Ctrl+F11 (run trace into, entering subroutines) or Ctrl+F12 (run trace over, executing calls at once), and stop it with F12 or Esc.

#You can specify a set of conditions that are checked on each step of the run trace (shortcut: Ctrl+T). Run trace stops if any condition is met. Conditions include:

•        Pause when EIP is in the address range;
•        Pause when EIP is outside the address range;
•        Pause when some condition is true;
•        Pause when next command is suspicious, i.e. potentially invalid (according to the rules set in Analysis 3), accesses non-existing memory, sets single-step trap flag or accesses stack beyond the actual ESP. Notice that this option can significantly (up to 20%) slow down the speed of run trace;
•        Pause after specified number of commands is traced (more precisely, added to run trace buffer). Note that counter doesn't autorestart. That is, if you set command count to 10, trace will pause once after 10 commands are executed, and not on every 10th command.
•        Pause when next command matches one of the specified patterns. You can use imprecise commands and operands and matching 32-bit registers RA and RB. Like R32, they substitute any general-purpose 32-bit register but have the same values within the command. RA and RB in this case must be different. For example, in program that consists of XOR EAX,EAX; XOR ESI,EDX, pattern XOR R32,R32 matches both commands; XOR RA,RA matches only the first one, and pattern XOR RA,RB matches only XOR ESI,EDX.

Of course, run trace requires plenty of memory, in average 16 to 35  bytes per command depending on the mode, and is very slow. On a 500-MHz processor under Windows NT it can trace up to 5000 commands per second. Windows 95 is slower: only 2200 commands per second. But in many cases, for example when program jumps to the non-existing address, this is the only way to find the reason. You can exclude quasi-linear sequences of commands (with sole exit at the end of the sequence) from the run trace. When OllyDbg encounters excluded sequence, it sets temporary breakpoint at the command that immediately follows excluded block and runs it at once. Of course, any return or jump to outside would make correct tracing impossible, so OllyDbg checks the piece of code you want to exclude and in hard cases asks you for confirmation.

In most cases you are not interested in tracing system API code. Trace option "Always trace over system DLLs" allows you to trace over API functions in trace/animation into modes. OllyDbg assumes that module is system if it resides in system folder. From the Modules window you can mark any DLL as system or non-system.

To make execution faster, you can limit run trace to selected commands or pieces of code by setting run trace breakpoints and running program. I call this "forced run trace". Basically, run trace breakpoints are non-removable hit trace breakpoints. If you delete hit trace, you simultaneously remove run trace.

Trace commands mentioned at the beginning of this topic automatically open trace buffer. You can specify its size (up to 64 MB) in Options. This buffer is circular and, when full, discards the oldest records.

You can explicitly open or clear run trace buffer by selecting 'Debug|Open or clear run trace' from the main OllyDbg menu. After run trace buffer is open, OllyDbg logs all pauses in execution, even those that were not caused by run trace. For example, you can step through the program by pressing F7 or F8 and then backtrace the execution using keys Plus and Minus. Notice that these keys browse through the history when run trace buffer is closed. If you step through the run trace, Registers and Information panes get grayed to emphasize that registers they display are not actual. Trace buffer doesn't save top of stack or contents of memory referenced by registers. Registers, Information and Stack use actual memory state to interprete registers from the run trace.

#OllyDbg can count how many times every command appears in the run trace buffer. In the Disassembler window, select 'View|Profile data'. This command replaces Comments column by Profile. Or, if bar is displayed, click it several times until it displayes Profile information. Notice that displayed count is dynamical and doesn't account for the old commands discarded from the trace buffer. You can also view profile data for the whole module, sorted by hit count, in a separate Profile window.

Special Disassembler command 'Run trace|Add entries of all procedures' allows to check how frequently each recognized procedure is called. Another command 'Run trace|Add branches in procedure' forces trace on all recognized jump destinations within the procedure. In this case, profile allows to find the most frequently executed branch and optimize it for speed.

Option 'Search for|Last record in run trace' in Disassembler pop-up menu finds whether and when given command was executed for the last time.

Run trace window displays the contents of trace buffer. For each command, there is the contents of integer registers that were changed by the command (more precisely, changed from given record to next). If you doubleclick some command, window selects all occurences of the command in the trace buffer and you can quickly browse them by pressing Plus and Minus. If option 'Trace|Synchronize CPU and Run trace' is set, Disassembler will follow Run trace window.

Notice that when you remove hit trace, you simultaneously remove forced run trace.

See also: Disassembler menu, Hit trace, Trace options
------------------------翻译完后，把译文跟在后面-------------

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课