javascript指令碼混淆

標籤：amp   大致   blog   運用   user   正則   長度   時間長度   title   

javascript指令碼混淆 指令碼病毒是一個一直以來就存在，且長期活躍著的一種與PE病毒完全不同的一類病毒類型，其製作的門檻低、混淆加密方式的千變萬化，容易傳播、容易躲避檢測，不為廣大網民熟知等諸多特性，都深深吸引著各色各樣的惡意軟體製作者 …

小到一個不起眼的lnk捷徑，大到一個word文檔，都是指令碼的載體。本文主要以 js指令碼為例(特指JScript，下同 )，具體結合實際樣本，講述混淆方式及其混淆類型檢測相關知識，文章受限於樣本個數及其種類，存在一定的局限性，但大致情況應當不會相差太大。本系列首先會對jscript及其指令碼進行簡單介紹，之後對採用不同混淆操作的樣本進行分析以及總結，後續系列會引入指令碼動態評鑑技術即 虛擬執行行為檢測技術的介紹與實現。

前言

jscript是由微軟公司開發的指令碼語言，是對ECMAScript文法規範的實現，最初是隨著 IE 3.0於1996年8月發布，和其所開發的其他指令碼語言一樣，後來被 Windows ScriptHost(WSH)和Active Server Pages所支援，其典型的副檔名稱為.js 。Windows上的.js檔案運行是這樣的( 實際尾碼還有可能是.jse,.wsf, .wsh)，在你雙擊這類檔案時，通常的操作是由代理程式傳給宿主進程作為參數運行，這個宿主進程也通常為 wscript.exe或者cscript.exe(實際根據註冊表中 HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.js\OpenWithList中給定的值)。 wscript與cscript的區別就在於前者是在視窗中運行，後者是在命令列中運行。那麼是不是所有js 的指令碼必須要有尾碼？當然不是，你可以使用wscript //e:jscript 檔案名稱的形式執行。是不是還要問 jscript和javascript是不是同一個？當然不是! 但他們確實屬於同一類語言，因為都是對ECMAScript文法規範的不同實現版本，大體文法都一樣，但各自的實現卻也存在著很多差異，具體差異可在網上查閱資料進行瞭解。

本文

jscript不知是什麼時候被微軟開始邊緣化的技術產品(或許是javascript 太強了)，隨著老一批的微軟開發人員的淡出，jscript也離開了人們的視線。但也可能正是如此，它獲得了惡意軟體編寫者的青睞。

什麼是混淆

混淆:指迷惑，將一樣東西誤認為另一樣東西(本解釋來自百度百科 )。由於指令碼語言絕大多數是基於解譯器的運行方式，所以其在進入解譯器之前多為原始碼形式存在，通過原始碼可以清楚知道指令碼的意圖，所以為了對抗分析，採用了各種方式將原始碼進行 混淆操作(當然也可能是正常功能的指令碼不想被輕易看穿的不得已之為)。通過金山毒霸安全實驗室對全球非 PE樣本的監控資料來看，目前對jscript指令碼的混淆方式變化如下:

下面通過不同混淆操作的特點，結合實際樣本案例進行分析總結，最後給出針對不同混淆方式的檢測思路。

指令碼混淆

指令碼混淆的方式比較繁多，常採用編碼、加密、 變形，切分等操作進行

編碼: 將資訊從一種形式或格式轉換為另一種形式的過程

加密: 通過某種特殊演算法，改變資訊的原有結構

變形: 改變原來形態的過程

切分: 通常為拆分操作

上述操作是常見混淆的採用的技術操作，但實際上，對這些操作運用的載體，通常是變數 ，字串，函數(或方法，統稱函數)、數組、對象， eval等。下文針對這些不同的載體，具體結合樣本進行分析討論。

1. 變數的混淆

變數混淆，通常針對變數的名稱、個數進行操作，目的是去掉變數名稱的詞義。這種操作的極端情況有個數極少、個數極多、名稱長度普遍較短(<6)、名稱長度普遍較長(>41) 、隨機名稱等特性。通常，單一的針對變數的混淆都是配合其他形式同時出現的，例如:

這個指令碼的特點很明顯，就是變數名稱都是e構成的，而且超級多，其後續執行的代碼如下:

具體含義就是根據變數名稱中e的長度從低到高的順序，通過this 訪問當前環境變數，之後拼接完整代碼塊，使用eval進行動態執行。通過這個規律可輕易寫出代碼還原工具(但可能適用的範圍很小 )。針對變數的混淆檢測，主要從變數的個數 、名稱長度分布及名稱字串特徵這三個維度去檢測。上述例子中，很明顯的發現，這裡對代碼進行了 變形，代碼塊切分技術。

2. 字串操作的混淆

字串，很大程度上能夠協助代碼閱讀人員快速定位關鍵程式碼片段，從而加快分析。當然，惡意指令碼也會更加註意對字串的保護 。對字串的常見混淆操作有加密、編碼、替換等操作。常見的針對字串的操作函數有substr、substring、 unescape、fromcharcode、replace 、split以及Regex等操作。如下程式碼片段就是使用了字串解密函數 exq在運行時對字串進行瞭解密。

當然，也有如下這種通過字串常用操作進行字串解密的

實際運行後b的值是

還有比較常見的編碼方式的

通過收集到的樣本來看，其中使用Regex的樣本也是比較多的，限於篇幅長度，這裡就不一一列舉了。

針對字串混淆，大多數都會有字串操作函數(或正則對象 )的使用，通過對這些函數(對象)的追蹤，統計其出現的次數，能從一方面說明這類混淆的特性，當然如果不對文法進行深層次的分析，很容易將 迴圈中的操作個數統計為一次，而實際可能執行了好多次操作。

3. 函數、數組、對象的混淆

正常指令碼中函數、數組、對象的個數都是有一個上限的，但混淆後的指令碼往往會超過這個上限，從而變的異常。例如:一個指令碼中出現了1000次函式宣告以及函數運算式操作，一個數組的索引超過了 10000，以及一個對象中都是number:string。針對數組的混淆，看這個例子，

其中BOql這個數組，最大索引竟然達到19027，人工編寫的代碼一般來說是不能達到如此程度的，所以極有可能是通過代碼產生的。實際運行後 eval傳入的UTf程式碼片段如下:

當然，對函數的混淆也是比較多的，比如直接作為數組中的元素

或是返回對象中的某個元素

總體來講，函數的混淆通常結合對象與數組同時進行。對於對象來說，比較意外，這種混淆通常是針對number，string 進行，很少發現裡面有函數的出現，比如下面這個

同函數一樣，對象的混淆大多數也是與數組一同出現的，核心原理是代碼切分，這類混淆後的代碼很明顯的體現了這個概念 ，儘可能多的減少資訊彙總，當然這也構成了這類混淆的檢測特徵索引過多但實際內容很少。

4. eval的混淆

eval函數可以動態執行一段代碼，基於這個特性，可以說，很受惡意指令碼的喜愛。常常是拼接程式碼片段 + eval的方式執行完整指令碼，也會被用來執行某一段代碼。比較典型的 packed混淆屬於第一種情況，如下：

實際執行的代碼在p變數中。也有執行某一段代碼的

eval的這類混淆，並不能作為一種獨立特徵來評判某指令碼是否被混淆，通常是作為一種輔助特徵而存在。

5. 其他類型混淆

上文講了4種常見混淆方式，當然，很多特殊指令碼，會使用一些其他技巧繞過檢測，例如:直接使用 eval可能會被檢測，那麼轉而使用this[e + val ]也是能達到相同特點的，這是this的一種特性，能訪問當前環境的全部變數。或者，如下代碼可能會被檢測到存在風險

var sh = WScript.CreateObject("wscript.shell" )sh.run(‘cmd‘)


但通過如下混淆

var o = this[‘e‘ + ‘val‘]( ‘th‘+‘is‘)var sh = o[‘WS‘+ ‘cript‘][‘Create‘ + ‘Ob‘ + ‘ject‘]("wsc" + "ript" + "." + "shELl" )sh[‘R‘+‘un‘ ](‘C‘ + ‘m‘ + ‘d‘ )


是不是很難被檢測到了？當然，沒有絕對檢測不到的混淆，但是一定程度上，這種已經不能輕易從靜態(代碼執行之前)特徵上進行判定，關於這些的檢測判定會在本系列的第二篇中進行介紹。

環境檢測

一個指令碼的行為特性，有時會受到當前運行環境影響，比如說，去下載一個檔案，但連結檔案不存在，通常做法是直接提示然後結束，又或者說，去建立一個檔案，之後去判斷是否建立成功，成功之後做剩餘操作，失敗則直接提示後結束。所以總體來講，指令碼的行為會受到環境的影響。所以，惡意軟體也會去嘗試進行環境判斷，從而判定當前的環境是否正常，例如是否允許在查殺引擎 中，下面列出了幾種常見的對抗檢測技術。

1. 時間檢測

在一般情況下，查殺引擎對一個指令碼的掃描時間長度都會限定在一個範圍之內，沙箱也是如此。惡意指令碼會通過順延強制的方式，從使檢測程式逾時退出，達到對抗的效果，例如:

這段代碼出現在指令碼的最前端，保證在延遲大於6s後繼續運行。

2. 執行結果檢測

現在對嚴重混淆指令碼的檢測大多是基於虛擬執行技術(詳見本系列的第二篇 )，由於引擎自身對實際環境的虛擬程度有限，往往存在某些對象、函數的類比不到位，導致在惡意指令碼執行時觸發異常(或直接崩潰) ，從而發生流程轉移，例如:

實際xuzydfej9函數執行的代碼如下:

var luzpal9 = WScript.CreateObject(‘WScript.Shell’);

var pniwinosu8 = luzpal9.CreateShortcut(‘\qvertyd.lnk’);

if(pniwinosu8.TargetPath == ”) return 1;

通過探測是否成功建立lnk檔案來判斷是否處於真實環境，與這種類似，還有一些是通過設定時間來進行探測，總之這類統稱為執行結果檢測。

3. 其他

/*@cc_on @*/形式的條件編譯，只有支援jscript文法的宿主中才會執行，所以如果某 虛擬執行引擎不支援這類文法規則的話，則會直接以/**/注釋的形式跳過這段代碼，從而對指令碼實際行為出現錯覺 。

最後

本文是<從jscript指令碼混淆說起 >的系列文章第一篇，主要目的是以科普為主，簡單介紹jscript的背景、常見混淆方式以及環境檢測相關的內容。通過這些的介紹，希望能讓大家對jscript 惡意指令碼，非PE病毒目前的發展趨勢有一個初步瞭解，本系列的後續文章將繼續深入探討通過虛擬執行技術來檢測惡意指令碼。最後，感謝閱讀本文。

javascript指令碼混淆