0x00 背景

---

about me：寫過外掛，做過破解，對電腦管家也有比較長時間的逆向分析積累，現在整理下投出來，求邀請碼和WB。

TAV有自己的優勢和特點的，比如防毒之後能夠還原一部分被病毒破壞的登錄檔和檔案。另外它的記憶體查殺也不錯，可以掃描記憶體、建立和病毒一樣的互斥，防止病毒再次執行。

TAV相比其他防毒軟體還是有很多不足，最明顯的缺陷是免殺比較簡單，由於TAV引擎用的是字串明文檢測，很容易透過分析病毒庫或者是MYCCL等進行黑盒免殺。另一方面，TAV的效率比較低，包括特徵資料結構弱, 特徵複用等方面的問題，後面會有詳細分析。

值得一說的是，逆向TAV的特徵庫可以看到，外掛特徵比病毒、後門特徵都多，排在了特徵數量的第二名，說騰訊電腦管家是“外掛殺手”一點都不誇張。盜號木馬則是TAV另一個重點打擊的物件，在特徵庫佔比也不低。至於感染型病毒、後門、下載者、蠕蟲、惡意指令碼等其它型別的木馬病毒，還需要OEM的小紅傘引擎或者雲引擎來補位，否則單靠TAV肯定是無能為力的。

0x01 結構與功能初析

---

引擎結構和功能如下。不難看出，TAV引擎屬於基礎的傳統特徵引擎。特徵數量較少，與主流殺軟相比還處於初級階段。

1. 引擎內部功能一覽

---

記憶體掃描

匹配指定的程式和記憶體串，如果匹配到就終止程式

匹配檔案是否存在

建立一個和病毒相同的互斥體，防止病毒再次執行

記憶體清理

解包

字串多模式匹配

 

虛擬機器:

模擬了ntdll、kernel32、gdi32、user32、advapi32、shell32、wsock32、ole32、oleaut32、msvcrt、version、urlmon這幾個系統DLL

對於不常用的API採用同一個函式統一處理：

對於關鍵函式，使用單獨的模擬程式碼實現：

2. 病毒庫分析：

---

A).病毒庫演算法:

只是簡單的ZLIB。

解密後內容如下：

B). 病毒庫結構:

virinfo.def：名稱表，包括殼名、包名、特徵名 c++ structVirInfo { DWORD dwID; BYTE btLength; char VirName[btLength]; };

C). 病毒庫規模:

特徵數量整體非常少，以PE為例只有8135條特徵。分佈見下圖。從特徵分佈和型別來看，TAV主要查殺目標為外掛、盜號程式。對於動輒百萬級規模的惡意程式家族其實只覆蓋了冰山一角，遠遠達不到一個防毒引擎的程度，僅僅停留在外掛、盜號專殺的層面。更讓人捉急的是TAV維護了大量的脫殼解包特徵，直接暴露了開發者框架設計方面的缺陷。與此形成鮮明對比的是國際知名的卡巴和BD引擎，通常在一個“膨脹”的過程中，維護較多的同家族特徵，隨後再在“收縮”過程中，用一條obj通殺，顯得章法自如、張弛有度。

D). 病毒庫更新：

病毒庫的更新有2種方式：

1 直接更新副檔名為.def的病毒庫，適用於查殺現有引擎可以支援的木馬和病毒。

2 更新替換tpktt.dll，適用於現有引擎無法解決的複雜樣本，將特徵和查殺方法透過分析員寫程式碼實現，然後整個引擎更新替換，類似於專殺方式。

0x02 PE查殺過程逆向分析：

---

1.病毒庫描述：

---

virpeXX.def：（PE庫）

#!c++
struct VirpeHeader
{
　WORD wUnknown;
　DWORD dwHeadSize;
　DWORD dwSize;
　WORD wTable1Count;
    WORD wdMaskCount;//表示共有多少條PE特徵
    WORD wdUnknown4;
    DWORD dwTable1Off;
    DWORD dwTable2Off;
    DWORD dwTable3Off;
    DWORD dwTable4Off;
    DWORD dwTable5Off;//傳統特徵
    DWORD dwTable6Off //多模式特徵
};

---

#!c++
struct Sig //特徵結構
{
    DWORD dwRecordID;//特徵ID，用於關聯特徵名
    DWORD dwOffset;//特徵偏移，用於定位病毒程式碼具體位置
    BYTE btLength;//特徵長度，用於掃描匹配病毒程式碼長度
    BYTE btOffsetBaseAddress;//特徵基地址，用於定位特徵起始位置
BYTE btVirMask[btLength];//病毒特徵具體內容
};

2. 靜態查殺方式：

---

a). 二進位制全文匹配。（二進位制特徵存放在virpe01.def庫解密後的tbl5中）

將數十位元組的病毒程式碼二進位制，記錄在病毒庫中，與待檢測樣本進行全文匹配。

b). 多模匹配。（多模特徵存放在tbl6中）

將惡意程式的明顯字串資訊提取出，記錄在病毒庫中，與待檢測樣本進行多模匹配。

3. 靜態掃描流程：

---

見下圖

4. 設計缺陷分析：

---

傳統殺軟最容易出現的幾個問題：效率低、體積龐大、對抗門檻低。這幾個問題在TAV身上尤為明顯。只是現階段TAV特徵數量極低，暫時未大規模展現而已。

a) 體積大。

現有的查殺方式設計會導致病毒庫臃腫，龐大的二進位制資料和字串資料記錄在病毒庫中，隨著特徵增加，病毒庫體積會急速膨脹。在同等特徵數量的情況下，TAV病毒庫將會比卡巴、BD等殺軟大上數十倍。

b) 效率低。

逐個匹配特徵的方式，會隨著病毒庫膨脹而使得效率變得越來越低。卡巴、BD等殺軟為解決此問題，設計出了多索引的方式，只有在最後一層才匹配幾個特徵，效率非常高。

c) 對抗門檻低。

匹配程式碼在記憶體中明文存在。

使得無論木馬作者透過分析病毒庫來免殺還是透過MYCCL等駭客工具進行黑盒免殺都極為容易。

d) 特徵無複用。

下圖為TAV的TOP50特徵，可見出現大量重複二進位制。特徵之間基本無複用。

例：Virus.Win32.DiskGen

以此家族為例，描述TAV設計缺陷導致的效率問題。

TAV查殺Virus.Win32.DiskGen病毒從a變種到最後的an變種，多次匹配了這條特徵：

18 8B 8E 30 0A 00 00 03 C8 40 40 8A 11 F6 D2 88 11 3B 05 3F 3F 3F 3F 7C

特徵含義是病毒自解密程式碼

儘管使用了索引複用，但並沒有最佳化。從病毒庫中可以看到，這條相同的特徵出現了20次。也就意味著，為了匹配這個家族的所有變種，當前待掃描檔案需要掃描20次才行。因為目前TAV特徵只有數千條，效率低下的問題感受不明顯，倘若哪天TAV特徵達到競品平均水平的數百萬條，不難想象掃描一個檔案將會是何等的慢。

0x03 其他型別分析：

---

virscrXX.def：指令碼庫，直接儲存的字串，用於掛馬的查殺。為了避免誤報自身記憶體，採用了異或的方式，將特徵載入到記憶體中。

virdexXX.def：安卓特徵庫

virsrcXX.def：指令碼庫，用於查殺HTML\JAVA\PDF\OLE\JS\NSIS

vircmpinfo.def：殼、編譯器識別

 

0x04 實戰對抗

---

1.TAV虛擬機器對抗

---

當檔案被加UPX殼後，會呼叫GetProcAddress動態獲得API地址，TAV可以模擬GetProcAddress的結果，並且可以執行到下一條EIP所在位置，使得程式能夠正常模擬下去，而不至於觸發異常返回。

檔案的真實除錯結果：

不過TAV的虛擬執行能力比較弱，比較適用於對壓縮殼進行脫殼，如常見的UPX殼，而對於動態行為查殺卻無能為力。

比如某個非常簡單的Downloader木馬，作者呼叫了URLDownloadToFileW下載一個木馬，然後呼叫WinExec執行木馬。整個過程非常簡單，只用到2個Windows API，並且沒有額外的程式碼來對抗虛擬機器，而TAV引擎卻無法查殺：

同樣的樣本，掃描對比國外知名殺軟，則可以透過虛擬機器動態檢出

2.MYCCL黑盒對抗：

---

以某盜QQ木馬測試。

特徵碼地址如下：

使用C32ASM檢視特徵碼：

隨便改改：