2. 相關研究
2.4. 程式分析相關
2.4.1. 程式分析工具
本論文使用的方法（於第三章詳述）需依賴程式分析工具的使用，但發展此類程式 並非此研究之重點，且目前已有相當多的分析架構可供使用，因此選擇使用或修改現有 的工具。我們選擇前幾節已使用的或常見的工具加以分析比較：
z GCC
GCC 為一 open-source compiler，目前普遍使用的程式語言，如 C、C++、JAVA 等皆 有支援，有一些研究以修改 GCC 的方式進行，而事實上 GCC 已提供了相當多的輔助功 能，以本研究相關的的功能來說，約數十行的程式撰寫量即能紀錄函式在執行時之呼叫 情形，然而本研究尚需變數之分析，而 GCC 並不提供，但由於 GCC 相當龐大，修改 GCC 將可預期到耗時過多，因此本研究不以 GCC 做為分析之工具，而只單純使用其編譯 (compiling)功能於 openssh 上。
z TXL[24]
由 Cordy 所發展之 TXL 主要用於程式分析與跨語言之轉換(language transformation) 上，可應用於各種程式語言上，其特點在於可針對程式 AST（Abstract Syntax Tree）中特 定之結構進行分析或轉換，在轉換目標明確的情況下，撰寫少量的 TXL 程式碼即可完 成工作，然而若需大量精細分析（fine-grained analysis)時，則 TXL 需針對各種不同之 AST 架構撰寫程式碼，其行數隨著分析所牽涉之 AST 複雜度呈指數(exponential)成長，由於本 研究需處理及分析變數(variable)，在 AST 中有相當多處可能會出現變數，若使用 TXL 則會需考慮各種變數在 AST 中情況，TXL 程式碼撰寫量將無法負擔，因此本研究在嘗 試使用後決定不使用 TXL。
z CIL[25]
CIL 全名為 C intermediate Language，主要用於分析 C 語言，該系統主要以 ML 撰寫，
其主要特點是運用 visitor 於 traverse AST 上，使用者可設定當 visitor 游走至 AST 某類 node 時對程式進行分析或修改，由於 ML 語言規範以及 CIL 本身之設定，其程式撰寫較 TXL 複雜，但由於其能處理 AST 中特定類別的 node，而不需考慮該 node 父節點之形式，此 點與 TXL 不同，故不會有需考慮的情況呈指數成長的情況，對本研究來說可符合需求，
且不造成程式撰寫耗時過多之情形，因此，本研究最後以 CIL 做為程式分析之工具。
2.4.2. 分析範圍
如同第一章研究前提中所說明，本研究的分析內容設定於 intra-procedural 而非 inter-procedural，這裡我們以下圖說明此二者之分別：
圖 5 程式分析範圍
上圖（A）為一虛擬碼，表示原始碼中函式呼叫之情形，而圖(B)或圖(C)表示程式實 際執行之情況，該樹中各節點（node）表示一函式，而實線之邊（edge）表示呼叫之情 形。
圖（B）為 intra-procedural 分析方法之示意，虛線表示為同一個 procedural 內的呼叫 先後次序，在此例中可看出於 A 函式中先後呼叫 B 函式及 C 函式，而 E 函式內先後呼 叫 A、C、D 函式，但是在 E 函式的呼叫中，我們並不去分析首先執行的 A 函式內部的 執行狀況。相對地，經由 inter-procedural 之分析方法可以了解程式中函式的執行序列以 及函式呼叫的深度，由圖(C)可以看出 H 函式內會呼叫 A、E 函式，而其中 A 函式又呼
2.4.3. 分析格式
在決定 inter-procedure 或 intra-procedure 及動態或靜態方法後，便可決定分析之格 式，常見的分析格式有以下幾種
圖 6 分析格式示例
說明： 圖(A)為一段未經編譯之虛擬程式碼，為求說明簡化，僅保留函式呼叫之 敍述。圖(B)為該程式碼之實際執行情形。圖中之各節點(node)皆為函式(procedure)，每 個邊(edge)皆為函式呼叫 (procedure call)，其呼叫順序為由左至右，由上至下，使用中 序表示法（infix）於此樹，即可得時序上之執行序列－如圖(C)
靜態分析分法常使用圖(B)之呼叫樹，分析的範圍若為 intra-procedure 則為該樹中各 子樹的不同層，而使用動能分析則常用圖(C)之方法，分析的範圍則可使用 intra-procedure 之方法，則圖(C)之 sequence 可分段成符合各 procedure 內容，此例中為{H}、{AÆE}、
{BÆC}、{AÆCÆD}、{BÆC}五類；或是使用固定長度的 sliding window－如 window size 為６時，其分析的項目為{HÆAÆBÆCÆEÆA}、{AÆBÆCÆEÆAÆB}、