OllyDbg完全教程 分析器［Analysis］

四，分析器［Analysis］

OllyDbg 整合了一個快速而強大的程式碼分析器。您可以從捷徑功能表，或者在CPU視窗的反組譯碼面板中按 Ctrl+A ，或者在可執行模組中選擇“分析全部模組［Analyze all modules］”，來使用它。

分析器有很高的啟發性。它能區分代碼和資料，標記入口和跳轉目的地址，識別轉換表［switch tables］，ASCII 和 UNICODE 串，定位函數過程，迴圈，高階轉換［
high-level switches］並且能解碼標準API函數的參數（樣本［example］）。OllyDbg 的其他部分也廣泛的使用了分析後的資料。

這是如何?的？我將為您揭開這一神秘面紗。第一遍，OllyDbg反組譯碼程式碼片段中所有可能的地址，並計算調用的每個目的地址的個數。當然，很多調用是假的，但不可能兩個錯誤的調用都指向了相同的命令，當然如果有三個的話，就更不可能了。因此如果有三個或者更多的調用指向了相同的地址，我可以肯定的說這個地址是某個頻繁使用的子程式的入口。從定位的入口出發，我繼續跟蹤所有的跳轉和函數調用，等等。按這種方法，我可能準確定位99.9% 的命令。但是，某些位元組並不在這個鏈條上。我再用20多種高效的啟發方法（最簡單的方法，比如“直接存取前64K記憶體是不允許的，像在MOV [0],EAX中”）來探測他們

有時，分析器在您感興趣的地方分析錯誤。有兩種解決方案：或者從選中的部分移除分析（快速鍵退格鍵），這樣 OllyDbg 將使用預設的解碼（反組譯碼）方式；或者設定
解碼提示［decoding hints］並重新分析。注意：在某些情況下，當分析器認為您的提示是不合適的，或者有衝突，則可能忽略您的設定。

探測程式的函數過程也很簡單。在分析器眼中看來，程式只是一個連綿不斷的代碼，從一個入口開始，可能達到（至少從理論上）所有的命令（除了NOP以及類似的用於填充間隙的命令）。您可能指定三個識別層級。嚴格的函數過程要求有準確的一個入口，並且至少有一個返回。在啟發層級下，分析器只要求過程有一個入口。而如果您選擇模糊模式，差不多連貫的代碼都會被識別為單獨的過程。現代編譯器進行全域代碼最佳化，有可能把一個過程分成幾個部份。在這種情況下，模糊模式非常有用。但是也會誤識別的機率也就更高。

同樣地，迴圈是一個封閉的連續的命令序列，並有一個到開始處的跳轉作為一個入口，還有若干個出口。迴圈與進階操作命令 do, while 和 for 相對應。OllyDbg 能夠識別任何複雜的嵌套迴圈。他們會在反組譯碼欄［Disassembly］中用長而粗括弧標記。如果入口不是迴圈的第一個命令，OllyDbg會用一個小三角進行標記。

為了實現一個轉換［switch］, 許多編譯器，讀取轉換變數［switch variable］到寄存器中，然後減它，像如下的代碼序列：

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

這個序列可能還包含一到兩階的轉換表、直接比較、最佳化和其他元素。如果在比較或跳轉的很深處，這就很難知道哪是一個分支［Case］。OllyDbg 會協助您，它會標記所有的分支，包括預設的，甚至嘗試分析每個分支的含義，如'A'、WM_PAINT 或者 EXCEPTION_ACCESS_VIOLATION。如果命令序列沒有修改寄存器（也就是僅僅由比較組成），那麼這可能不是轉換，而很有可能是選擇嵌套：

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

如果需要OllyDbg將選擇嵌套解碼成選擇語句，請在分析1［Analysis1］中設定相關選項。

OllyDbg包含多達1900條常用API函數，這些都作為內部預先處理資源。這個列表包含了KERNEL32, GDI32, USER32, ADVAPI32, COMDLG32, SHELL32, VERSION, SHLWAPI, COMCTL32, WINSOCK, WS2_32 和 MSVCRT。您可以添加自己的函數描述［add your own descriptions］。如果分析器遇到的調用，使用了已知的函數名（或者跳轉到這樣的函數），它將在調用之前立即解碼PUSH命令。因此，您只需略微一看就能明白函數調用的含義。OllyDbg還包含了大約400多種的標準C函數。如果您有原始的庫檔案，我推薦您在分析前掃描目標檔案。這樣OllyDbg將能解碼這些C函數的參數。

如果選項“猜測未知函數的參數個數”開啟，分析器將會決定這個調用函數過程使用的長度為雙字的參數個數。並且標記他們為參數1［Arg1］，參數2［ Arg2］，等等。注意：無論如何，寄存器參數是無法識別的，所以不會增加參數的數目。分析器使用了一種比較安全的方法。例如，它不能識別的沒有參數的函數過程，或者該過程POP
命令直接做返回前的寄存器恢複，而不銷毀參數。然而，識別出來的函數參數數目通常非常高，這大大加大了代碼的可讀性。

分析器能夠跟蹤整型寄存器的內容。現代最佳化編譯器，特別是奔騰系列，頻繁地使用寄存器讀取常量和地址，或使用盡量少的使用記憶體。如果某個常量讀取到寄存器中，分析器會注意它，並嘗試解碼函數和其參數。分析器還能完成簡單的算術計算，甚至可以跟蹤壓棧和出棧。

分析器不能區分不同類的名稱［different kinds of names］. 。如果您將某些函數指定為已知的名稱，OllyDbg將會解碼所有到該地址的調用。這是幾個預定義的特殊名稱
WinMain, DllEntryPoint and WinProc。您可能使用這些標籤標記主程式、DLL的的入口以及視窗過程（注意：OllyDbg不檢查使用者自訂的標籤是否唯一）。另外，假定預定義參數assume predefined arguments是一種更好的方法

不幸的是，沒有一般規則能夠做到100%的準確分析。在某些情況下，例如當模組包含了P-Code或程式碼片段中包換了大量的資料，分析器可能將一些資料解釋成代碼。如果統計分析顯示代碼部分很可能是壓縮包或者經過加密了，分析器會發出警告。如果您想使用Hit跟蹤［Hit trace］，我建議您不要使用模糊分析［fuzzy analysis］，因為設定斷點的地方可能正是資料部分。

自解壓檔案［Self-extractable files］ 通常有一個自提取器，在“正式”程式碼片段之外。如果您選擇自解壓選項［SFX option］中的“擴充程式碼片段，包含提取器［Extend code section to include self-extractor］”，OllyDbg將會擴充程式碼片段，形式上允許分析它，並可以使用Hit跟蹤［Hit］ trace和Run跟蹤［Run trace］。