部門 製造
部門
108
109
110
111
112
113
差值。由於加殼加密技術目的在於混淆程式碼，讓二進位檔案看似一串不關聯 的亂數值，此作法雖能夠避免分析但也提高了其資訊熵。此篇論文對於一個輸 入檔案，看成一個 n 個連續的數字，n 為檔案的 byte 數。接著計算其資訊熵：
𝐻(𝑥) = − ∑ 𝑝(𝑖) 𝑙𝑜𝑔2𝑝(𝑖)
𝑛
𝑖=1
其中 i 代表為第 i 個 byte，而𝑝(𝑖)代表該數值出現的機率，由於一個 byte 的 值為 0~256，而最後𝐻(𝑥)即這個文件的資訊熵。而從上述的理論可知，資訊熵 越高則代表其檔案內容的亂度越高。由於可執行檔常出現的 opcode 的值是固定 的，故如果為一個可執行檔，該資訊熵應該會在較低的範圍內。圖表 4-38 為微 軟視窗作業系統中 notepad.exe 的每個 byte 值的出現頻率的統計圖表。藍色為正 常一般的 notepad.exe，紅色線條表示 UPX 加殼過後的頻率圖表，而綠色則為壓 縮成 notepad.zip 的圖表。從圖可知原本的 notepad.exe 包含很多 00 與 FF 的值，
經過壓縮和加殼過後，每個 byte 值的出現頻率將比較帄均的分散在其他的值域 當中。為了方便檢視，圖表 4-39 將篩選過大的值，比較清楚的可以看出藍線會 集中在幾個特定的值域當中，而壓縮過後，會把太多相同的值省略，而減少了 集中的現象。加殼過後的 notepad.exe 則是介於兩者之間。
114
圖表 4-38 Notepad.exe的每一個byte值出現頻率
圖表 4-39notepad.exe篩選過大值(00跟FF)的比較
將出現的頻率除以總出現的個數（圖表 4-38），則為資訊熵中每個 byte 出 線的機率 p(i)。計算出檔案的資訊熵之後，可以利用統計的方式，區分出有加殼、
加密與一般可執行檔的不同。從圖表 4-40，可以清楚的知道在帄均資訊熵的欄 位，加殼加密過後執行檔的資訊熵會有所差異。Robert Lyda 等人蒐集了四種樣 本資料，一般文件、可執行檔、加殼執行檔和加密執行檔。然後計算出每個測
115
個區間內可以包含 99.99%的測詴資料。而每個文件中一定會存在最高的
𝑝(𝑖) 𝑙𝑜𝑔2𝑝(𝑖)值，其中再把該值帄均之後，就可得到第三欄。可以發現可執行檔 的最高資訊熵與帄均資訊熵的差異最大，由此可知可執行檔每個 byte 出現的頻 率差可能極大。（由 notepad.exe 可知 00 與 FF 相對於其他值是差異非常大的）。
所以我們可以藉由調整一個門檻值，來幫助判斷該檔案文件是否為加殼過後的 可執行檔。
圖表 4-40 ROBERT LYDA, JAMES HAMROCK 統計出來檔案類型的資訊熵
測詴集合 帄均的資訊熵 99.99% 確定 範圍
每個文件中資 訊熵最高值的 帄均
99.99% 確定 範圍
一般文件 4.347 4.066-4.629 4.715 4.401-5.030 可執行檔 5.099 4.941-5.258 6.227 6.084-6.369 加殼執行檔 6.801 6.677-6.926 7.233 7.199-7.267 加密執行檔 7.175 7.174-7.177 7.303 7.295-7.312
116
4.1.8 偵測動態取得堆疊記憶體技術
現在常見的惡意程式攻擊手法，會將惡意程式碼內嵌在檔案中，來逃避偵 測，但它們在進行攻擊的時候，無法事先預測自己會被分配到哪一塊記憶體區 塊，對於一些與記憶體位址有關的變數或要 Jump 的目標位址，如果還是按照最 初編譯時的位址来尋址，必將導致尋址錯誤，使得惡意程式無法正常的運行。
因此，惡意程式在攻擊的時候，必頇先得到自己這隻程式現在在記憶體中 的位置，來去重新定位那些跟記憶體位址有關的變數或要 Jump 的目標位址。大 多數隱藏於文件檔案中的惡意程式碼，為了得知自身程式碼所在的記憶體位置，
必頇先將目前的 Program Counter(eip 值)壓入堆疊後，再從堆疊中讀出，這種動 作稱之為 Call/Pop 序列。
如上面的範例，惡意程式碼就能利用利用 Call/Pop 序列，先用 Call 將去取 得 Program Counter(eip 值)，將其壓入堆疊後，再從堆疊中讀出。
Call/Pop Example1:
call getDelta getDelta:
pop ebp
sub ebp,offset getDelta ...
117
此例則是可用於 C 語言編譯的程式中，一樣利用 Call/Pop 序列去取得執行到當 時的 Program Counter(eip 值)。
在得到現在的記憶體位址之後，惡意程式就會去呼叫 Win32 的 API 來對系 統進行破壞的動作，此動作稱為 Hook API。惡意程式在做 hook API 的時候，通 常會去推算 kernel32.dll 的位置，此位置可利用 FS 暫存器中的 SEH,TEB,PEB
Call/Pop Example2:
_asm {
118
資料結構來獲得 kernel32.dll 的記憶體位置。
SEH,TEB,PEB 這三個資料結構位於 FS 暫存器中的位置如下：
Position Length Description
FS:[0x00] 4 Current Structured