分析器［Analysis］
OllyDbg 整合一个快速而强大的代码分析器。integrates quick yet powerful code analyzer. To launch it, use pop-up menu or press Ctrl+A in the Disassembler pane of the CPU window or select "Analyze all modules" in Executable modules.

The Analyzer is highly heuristical. It distinguishes code from data, marks entry points and jump destinations, recognizes switch tables, ASCII and UNICODE strings, locates procedures, loops, high-level switches and decodes arguments of standard API functions (see example). Other parts of OllyDbg make extensive use of analysis data.

How is it possible? I'll open a piece of this Geheimniss to you. On the first pass OllyDbg disassembles every possible address within the code section and counts all found calls to every destination. Of course, many of these calls are artefacts, but it's unlikely that two wrong calls will point to the same command, and almost impossible that there are three of them. So if there are three or more calls to the same address, I'm sure that this address is entry point to some frequently used subroutine. Starting from located entries, I trace all jumps and calls, and so on. In this way I locate commands that are 99.9% sure. Some bytes, however, are not in this chain. I probe them with around 20 highly efficient heuristical methods (the simplest looks like: "Direct access to first 64 K of memory, like in MOV [0],EAX, is not allowed").

Sometimes analysis fails at the point of your interest. There are two workarounds in this situation: either remove analysis from selection (shortcut BkSpc) and OllyDbg will use default decoding (disassembly). Or, set decoding hints and repeat analysis. Note that in some rare cases, when Analyzer is sure that your hint does not apply or is conflicting, it may ignore your suggestion.

Detection of procedures is also simple. Procedure, from the Analyzer's point of view, is a contiguous piece of code where, starting from the entry point, one can reach (at least theoretically) all other commands (except for NOPs or similar spaceholders that fill alignment gaps). You can specify one of three recognition levels. Strict procedure has exactly one entry point and at least one return. On heuristical level, Analyzer tries to assume entry by itself. And if you select fuzzy mode, any more or less consistent piece of code will be considered separate procedure. Modern compilers perform global code optimizations that split procedure in several parts. In such case fuzzy mode is especially useful. The probability of misinterpretation, however, is rather high.

Similarly, loop is a closed continuous sequence of commands where last command is a jump to the first with a single entry point and any number of exits. Loops correspond to high-level operators do, while and for. OllyDbg recognizes nested loops of any complexity. They are marked by long fat parenthesis in the disassembly. If entry is not the first command in the loop, OllyDbg marks it with a small triangle.

#To implement a switch, many compilers load switch variable into register and then subtract parts of it, like in the following sequence:

     MOV EDX,<switch variable>
     SUB EDX,100
     JB DEFAULTCASE
     JE CASE100        ; Case 100
     DEC EDX
     JNE DEFAULTCASE
     ...               ; Case 101

This sequence may also include one- and two-stage switch tables, direct comparisons, optimizations and other stuff. If you are deep enough in the tree of comparisons and jumps, it's very hard to say which case is it. OllyDbg does it for you. It marks all cases, including default, and even attempts to suggest the meaning of cases, like 'A', WM_PAINT or EXCEPTION_ACCESS_VIOLATION. If sequence of commands doesn't modify register (i.e. consists of comparisons only), then this is probably not a switch, but a cascaded if operator:

     if (i==0) {...}
     else if (i==5) {...}
     else if (i==10) {...}

To let OllyDbg decode cascaded if's as switches, select corresponding option in Analysis1.

OllyDbg contains, as an internal precompiled resource, the descriptions of more than 1900 frequently used API functions. This list includes KERNEL32, GDI32, USER32, ADVAPI32, COMDLG32, SHELL32, VERSION, SHLWAPI, COMCTL32, WINSOCK, WS2_32 and MSVCRT. You can add your own descriptions. If Analyzer encounters call to the function with known name (or call to jump to such function), it tries to decode PUSH commands that immediately precede this call. Consequently, you can interprete the meaning of calls at a glance. OllyDbg has also descriptions of about 400 standard C functions. If you posess original libraries, I recommend that you scan object files before analysis. In this case, OllyDbg will decode arguments of known C functions too.

If option "Guess number of arguments of unknown functions" is set, Analyzer tries to determine number of doublewords that calling procedure pushes onto the stack, and marks them as arguments Arg1, Arg2 and so on. Notice that register arguments, if any, remain unrecognized and are not included in this count. Analyzer goes a secure way. For example, it doesn't recognize procedures without parameters or cases where POP may restore registers before return instead of discarding arguments. Nevertheless, the number of recognized functions is usually very high, strongly improving the readability of code.

#Analyzer can trace the contents of integer registers. Modern optimizing compilers, especially Pentium-oriented, frequently load constants or addresses into registers for repeated use or to minimize memory latencies. If some constant is loaded into register, Analyzer notices it and uses to decode functions and their arguments. It is also able to perform simple arithmetical calculations and even traces pushes and pops.

Analyzer doesn't distinguish between different kinds of names. If you assign known name to some function, OllyDbg will decode all calls to this address as if there were original routine. There are special predefined names WinMain, DllEntryPoint and WinProc. You can use these labels to mark entry to the main program, optional DLL entry point and window procedures (notice that OllyDbg does not check user-defined labels for uniqueness). Another, better way to do this is to assume predefined arguments.

Unfortunately, there are no general rules allowing to perform 100% accurate analysis. In some cases, for example when module contains p-code or large amounts of data embedded in the code section, analyzer may interpret parts of this data as a code. If statistical analysis shows that code is probably packed or encrypted, Analyzer will warn you. If you want to use hit trace, I recommend that you don't use fuzzy analysis, otherwise the chances are high that breakpoint will be set on the misinterpreted data.

Self-extractable files usually have extractor outside the "official" code section. If you select the SFX option "Extend code section to include self-extractor", OllyDbg will, er, extend code section, formally allowing to analyze it and apply hit trace and selective run trace.

See also: Object scanner, Analysis options - part 1, Analysis options - part 2, Analysis options - part 3, Call tree

[培训]《安卓高级研修班(网课)》月薪三万计划，掌握调试、分析还原ollvm、vmp的方法，定制art虚拟机自动化脱壳的方法