談論殺毒軟體的引擎

[psac]

為防止誤解，特作如下聲明：

1.鑒於個人能力有限，文中大量借用了業已在病毒界獲得公認的兩篇文章：先進殺毒引擎的設計原理 ，流行殺毒軟體的引擎設計 。

2.為便於理解，文中很多詞語未使用嚴格的工業研發用語。比如殺毒引擎的前端正式名稱為『關於初步預掃瞄的（文件）對像匯入工程部分「。

很多工業用語聽起來很拗口，自己變通了一下，感興趣者可查閱L.Felly:系統的安全與防護 中的有關章節。
3.我認為現今在全球流行的幾款殺毒軟體在技術上並不存在誰的技術遠遠領先的問題，沒有必要過與讚揚那一款殺毒軟體，自己用著高興就好。

文中對某些殺軟的介紹比較詳細，主要是因為它的資料較多，有東西可寫，沒有其餘的意思。

4.到現在為止，我已經用過幾乎所有的殺毒軟體（論壇上提到的）

5. 我個人非常不喜歡設計病毒，私下寫過的幾個純粹是寫著玩，大部分時候是MM生氣的時候寫個玩笑程序讓她高興用的

6.很長時間不在專業病毒論壇上走動了。我認為如果因為喜歡程序設計看一下病毒的程式碼是可以的，當出於其他目的的時候，還是收手吧。

7.鑒於個人能力原因，有一部分是MM寫的，MM很漂亮，也很嬌氣，但對我基本上言聽計從，必經一起走過了十幾年了。原帖子中有一部分是錯誤的，已經由她修改過。

8.文中有一部分內容來自一個朋友提供的殺毒軟體公司的開發我的文件，我已經大幅改動過。

9.本人是學生，且正在忙於考G，上網的時間並不怎麼多，因此很多問題可能並不能及時作出解答，還望原諒。


10.我一直在使用的殺毒軟體（其餘的半路都卸了）：SAV9.0，KV2004（兩套系統）。在我看來殺毒軟體就只是一款軟體罷了，沒必要大家為用什麼爭來爭去，自己感覺好就行了，爭論的時間還不如用來多陪陪女友呢。
正文部分
文章比較長，加之本人寫作水準有限和某些技術我的文件需要核實，只能寫一段發一段，還望大家原諒。

有誤之處，敬請指出，謝謝！
（各段數值標出,每次均對該檔案進行編輯.
1.什麼是殺毒軟體引擎，與病毒庫的關係？

首先必須指出殺毒軟體的引擎與其病毒庫並沒有什麼直接的關係。殺毒引擎的工作和功能非常簡單，就是對於給定的文件或者程序工作判斷其是否是合法程序（對應於殺毒軟體廠商自己定義的正常和非異常程序規範而言。


正常的程序規範是指在程序所在系統平台上操所繫統本身洗淨有定義的或者業界已經公認的程序行為程序，比如操作系統正常執行就必須要求應用程式與系統核心進行工作回應並與交換相關資料。


非異常程序活動是指可能存在非法程序操作結果但能夠以較高的置信度確定其非非法程序活動規範的。一般情況下，相關文件的複製，移動，移除等都奔包括在該界定範圍內）。


我們知道病毒的最終目的有些是與合法活動很類似的，在這種情況下，要求軟體廠商必須自己有一個行為規範界定規則，在一個給定的範圍和置信度下，判斷相關操作是否為合法。


在這方面，各個廠商的界定是有區別的，一般而言非美國廠商界定是非常嚴格的，只有有很高的置信水準的程序行為，他們才判別為非病毒操作。

記得前一陣論壇上有人給了四段簡單的程式碼，很多殺毒軟體將其判為病毒或有病毒性質的文件行為，實際上看那幾段程式碼可以知道，其結果並不足以視之為病毒。


美國廠商一般判斷比較複雜，這主要由於美國市場上的殺毒軟體引擎來源比較複雜，比如諾頓，有足夠的技術資料確信它的殺毒軟體引擎是自成體系的，而mcafee則存在一定的外界技術引進（收購所羅門）。


用簡單的話說，殺毒引擎就是一套判斷特定程序行為是否為病毒程序（包括可疑的）的技術機制。一個完整的技術引擎遵守如下的行為程序：


1.非自身程序行為的程序行為捕獲。

包括來自於記憶體的程序執行，來自於給定文件的行為虛擬判斷，來自於網路的動態的資訊等等。一般情況下，我們稱之為引擎前端。


捕捉的方法非常多，除諾頓以外的殺毒軟體採用的都是行為規範程式碼化的方法。

諾頓由於與微軟有這遠遠高於其它廠商合作關係，其實現程序比較獨特，另有敘述。


2.關於引擎機制的規則判斷。

這個環節代表了殺毒引擎的品質水準，一個好的殺毒引擎應該能在這個環節發現很多或者稱之為相當規模的病毒行為，存而避免進入下一個判斷環節。

傳統的反病毒軟體引擎使用的是關於特徵碼的靜態掃瞄技術，即在文件中尋找特定十六進制串，如果找到，就可判定文件感染了某種病毒。


但這種方法在當今病毒技術迅猛發展的形勢下已經起不到很好的作用了。為了更好的發現病毒，相繼開發了所謂的虛擬機，既時監控等相關技術。



這個環節被叫做殺毒軟體引擎工作的核心層。

3.引擎與病毒庫的交互作用。


這個程序往往被認為是收尾階段，相對於前兩個環節，這個階段速度是非常慢的，殺毒引擎與要將非自身程序行為程序轉化為殺毒軟體自身可識別的行為標幟符（包括靜態程式碼等），然後與病毒庫中所儲存的行為資訊進行對應，並作出相應處理。

當然必須承認，當前的殺毒軟體對大量病毒的識別都是在這個階段完成的。因此一個足夠龐大的病毒庫往往能夠彌補殺毒軟體引擎的不足之處。
但是必須意識到，如果在核心層階段就可以結束並清除病毒程序，那麼殺毒軟體的工作速度將會大幅提升。


「很可惜的是，當前我們沒有足夠聰明的殺毒引擎來完成這個程序」，這就是為什麼有病毒庫的原因。
諾頓是微軟最進階的安全方面核心合作廠商，因此它的殺毒軟體在某些方面工作比較特殊。

比如在殺毒軟體的安裝，使用和功能實現方面，大部分廠商採用的是中間件技術，在系統底層與非自身應用程式之間作為中間件存在並實現其功能；
另有一些廠商使用的是應用程式或者嵌入技術，相對而言這種方法安全性較低；
諾頓和 mcafee實現方式比較相似，諾頓採用了關於系統最底層的系統核心驅動，這種實現方式是最安全的或者說最進階的實現方式，當然這需要微軟的系統來源碼級的支持（要花許多money），業界公認，這是最穩定的實現方法，但從目前而言，只諾頓一家。Mcafee實現方式與諾頓很接近，一般稱之為軟體驅動。


相當於在系統中存在一個虛擬「硬體」，來實現殺毒軟體功能。這些實現方式關係著殺毒引擎對程序行為進行捕捉的方式。


我們使用的intel系的處理器有兩個 ring層，對應兩個層，微軟的操作系統將系統中的所有行為分為如下幾個層：


1.最底層：系統核心層，這個層的所有行為都由操作系統已經內裝的指令來實現，所有外界因素（即使你是系統管理員）均不能影響該層的行為。諾頓的核心層既工作在這個層上。


2.硬體虛擬層，一般稱之為HAL。為了實現硬體無關性，微軟設計了該層。

所有的外部工作硬體（相對於系統核心而言）都進入HAL，並被HAL處理為核心層可以相應的指令。

我們所使用的硬體的驅動程式既工作在該層上。

當外界硬體存在指令請求時，驅動程式作出相關處理後傳給核心層。如果無與之對應的驅動相應，那麼將按照預設硬體進行處理。好像安全模式下硬體的工作就被置於預設硬體模式。Mcafee被認為工作與該層上。


3.用戶層（分為兩個子層，不詳細敘述，感興趣的可以查閱《windows xp入門到精通》（有中文版），第二部分四節有敘述）。我們所知的大部分殺毒軟體既工作與該層上。


一個完整的程序行為請求是如下流程：位於3戶層上的應用程式產生指令行為請求，被傳遞至2HAL進行處理，最後進入1最底層後進入CPU的指令處理循環，然後反向將軟體可識別的處理結果經1－2－3再回應給應用程式。


對於諾頓而言，其整個工作程序如下：3-2-1，完成；mcafee：3-2-1-1-2，完成：其餘：3-2-1-1-2-3，完成；這個環節代表了殺毒軟體引擎的前端行為規範的獲得。只從這個程序而言，諾頓和mcafee是比較先進的。


（具體的系統與CPU的ring()的對應，記不清楚了。

WinNT時代，微軟的NT系統被設計有與四個ring()層相對應，RISC系列的處理器有四個ring。因此現在的大部分殺毒軟體是不能工作與NT上的。

具體的CISC和RISC的ring()數我記得可能有誤，反正是一個2ring(),一個4ring().）。


儘管比較先進的工作方式給諾頓和mcafee帶來了較高的系統穩定性（HAL層很少出現問題，最底層出問題的幾率接近於零），較快的回應速度（減少了環節），但同時也帶來了一些問題：1.資源佔用比較厲害。


在mcafee上體現的不是很明顯，在諾頓上表現非常明顯。

因為對於越底層的行為，硬體資源分配越多。

最好資源的是什麼？當然是操作系統。應為它最最底層。

2.卸載問題。卸載底層的元件出問題的概率是相對比較高的，因此諾頓的卸載比較慢，偶爾還出問題。
有人質疑由於微軟操作系統的不穩定性是否會拖累諾頓，想開發人士詢問後得知，微軟操作系統的內核層設計是非常優秀的，很多時候操作系統的不穩定性來源於以下幾個方面：

1.應用程式設計不合理，許多程序設計者根本就未讀過微軟的32位程序設計指南，所設 計的程序並不嚴格符合微軟規範。


我們看到很多軟體多年前設計還能執行於最新的xp平台，原因很簡單：這個軟體在設計時完全遵循了微軟的程序設計規範。


2. 驅動程式的編寫有問題，與HAL層有衝突。

因此認為微軟的操作系統將會影響諾頓的穩定性是不合理的。


注:剛才問了一下偶MM,她告訴我應該是CISC有四個ring(),RISC有兩個ring().對應於系統的最低層而言，工作在ring0()上。

應用程式工作在ring3()上 。偶的記憶力比較差，文中可能有部分技術錯誤，請原諒。

業界有人認為，先進殺毒軟體的引擎設計已經日趨複雜，類如諾頓這一類的廠商其產品的引擎應該已經覆蓋了操作系統的各個層級，以提高防護能力。


在一篇我的文件中有程序員提出有足夠的資訊認為諾頓，mcafee，趨勢的產品自己修改了標準的系統相關傳輸協定，比如TCP/IP等，以達到所謂的完整防護的目的。


NOD32的一篇官方我的文件（說實話，我沒有看到過）指出有必要全面更新（說白了就是修改）系統的諸多傳輸協定，以達到最快的速度和殺毒效果。

[psac]

要討論怎樣反病毒，就必須從病毒技術本身的討論開始。正是所謂「知己知彼，百戰不殆」。

很難想像一個毫無病毒寫作經驗的人會成為殺毒高手。目前國內一些著名反病毒軟體公司的研發隊伍中不乏病毒寫作高手。

只不過他們將同樣的技術用到了正道上，以『毒』攻『毒』。


當今的病毒與DOS和WIN3.x時代下的從技術角度上看有很多不同。


最大的轉變是：啟始區病毒減少了，而指令碼型病毒開始氾濫。

原因是在當今的操作系統下直接改寫磁牒的啟始區會有一定的難度（DOS則沒有保護，允許使用INT13直接寫入磁碟），而且啟始區的改動很容易被發現，並且微軟在設計操作系統時加強了對啟始區的程序行為管理，寫一個完美的啟始區病毒難度很大，所以很少有人再寫了；而指令碼病毒以其傳播效率高且容易編寫而深得病毒作者的青睞。


但是最最落後的殺毒引擎也就是只關於靜態程式碼的殺毒引擎都能幹掉該種病毒（病毒庫搞好就行）。


要討論的技術主要來自於二進制外殼型病毒（感染文件的病毒），並且這些技術大都和操作系統底層機制或386以上CPU 的保護模式相關，值得研究。

DOS下的外殼型病毒主要感染 16位的COM或EXE文件，由於DOS沒有（文件和啟始區）保護，它們能夠輕鬆地進行駐留，減少可用記憶體（通過修改MCB鏈），修改系統程式碼，攔截系統服務或中斷。


而到了WIN9X和WINNT/2000時代，搞個執行其上的32位WINDOWS病毒變得難了點。


由於存在頁面保護，你不可能修改系統的程式碼頁（如果你強到連操作系統程式碼都能改，偶無話可說）。


由於I/O許可位圖中的規定，你也不能進行直接連接阜訪問（29A的一個美女[聽說叫 Mercy.Chan]可以通過彙編方法直接訪問連接阜的目的，但是沒有見過指出事例程式碼。

知道得給介紹一下她的程序程式碼）WINDOWS中你不可能像在 DOS中那樣通過截獲INT21H來攔截所有文件操作。


總之，你以一個用戶態權限執行，你的行為將受到操作系統嚴格的控制，不可能再像DOS下那樣為所欲為了（在xp中，這種權限管理極為嚴格，大致分成了4-8個等級）。


WINDOWS下採用的可執行文件格式和DOS下的 EXE截然不同（普通程序採用PE格式，驅動程式採用LE），所以病毒的感染文件的難度增大了（PE和LE比較複雜，中間分了若干個節，如果感染錯了，將導致文件不能繼續執行）。

當今病毒的新技術太多，隨便介紹幾個。

1.系統核心態病毒

386及以上的CPU實現了4個特權級模式（WINDOWS只用到了其中兩個），其中特權級0（Ring0）是留給操作系統程式碼，設備驅動程式程式碼使用的，它們工作於系統核心態；而特權極3（Ring3）則給普通的用戶程序使用（我想知道一個問題，ring1,2是幹什麼的？），它們工作在用戶態。


執行於處理器核心態的程式碼不受任何的限制，可以自由地訪問任何有效位址，進行直接連接阜訪問。


而執行於用戶態的程式碼則要受到處理器的諸多檢查，它們只能訪問映射其位址空間的頁表項中規定的在用戶態下可訪問頁面的虛擬位址，且只能對工作狀態段（TSS）中I/O許可位圖（I/O Permission Bitmap）中規定的可訪問連接阜進行直接訪問（此時處理器狀態和控制標誌暫存器EFLAGS中的IOPL通常為0，指明當前可以進行直接I/O的最低特權等級是Ring0）。


以上的討論只限於保護模式操作系統，像DOS這種真真實模式操作系統則沒有這些概念，其中的所有程式碼都可被看作執行在核心態。既然執行在核心態有如此之多的優勢，那麼病毒當然沒有理由不想得到Ring0。


處理器模式從Ring3向Ring0的切換發生在控制權轉移時，有以下兩種情況：
訪問使用門的長轉移指令CALL，訪問中斷門或陷阱門的INT指令。具體的轉移細節由於涉及複雜的保護檢查和堆疊切換，不再贅述，請參閱相關資料。


現代的操作系統通常使用中斷門來提供系統服務，通過執行一條陷入指令來完成模式切換，在INTEL X86上這條指令是INT，如在WIN9X下是INT30（保護模式回調），在LINUX下是INT80，在WINNT/2000下是INT2E。


用戶模式的服務程序（如系統DLL）通過執行一個INTXX來請求系統服務，然後處理器模式將切換到核心態，工作於核心態的相應的系統程式碼將服務於此次請求並將結果傳給用戶程序。


在即將發佈的xp-sp2中採用所謂增強的記憶體頁面保護將會更為嚴格的控制用戶權限，據說在訪問記憶體位址時得到的將是經過系統映射處理的對應記憶體範圍，在記憶體實位址與用戶層之間，搞了一個類似於轉換傳輸協定的東西，害的很多軟體都不能執行，應為他們總是試突按照原有的HAL層訪問規則進行工作。


2.駐留病毒

駐留病毒是指那些在記憶體中尋找合適的頁面並將病毒自身拷貝到其中且在系統執行期間能夠始終保持病毒程式碼的存在。


駐留病毒比那些直接感染（Direct- action）型病毒更具隱蔽性，它通常要截獲某些系統操作來達到感染傳播的目的。


進入了核心態的病毒可以利用系統服務來達到此目的，如CIH病毒通過使用一個由VMM匯出的服務VMMCALL _PageAllocate在大於0xC0000000的位址上分配一塊頁面空間。

而處於用戶態的程序要想在程序結束後仍駐留程式碼的部分於記憶體中似乎是不可能的，因為無論用戶程序分配何種記憶體都將作為工作佔用資源的一部分，一旦工作結束，所佔資源將立即被釋放。所以我們要做的是分配一塊工作結束後仍可保持的記憶體。



病毒寫作小組29A的成員GriYo 運用的一個技術很有創意：
他通過CreateFileMappingA 和MapViewOfFile新增了一個區域對象並映射它的一個視口到自己的位址空間中去，並把病毒體搬到那裡，由於文件映射所在的虛擬位址處於共享區域（能夠被所有工作看到，即所有工作用於映射共享區內虛擬位址的頁表項全都指向相同的物理頁面），所以下一步他通過向Explorer.exe中注入一段程式碼（利用WriteProcessMemory來向其它工作的位址空間寫入資料），而這段程式碼會從Explorer.exe的位址空間中再次申請開啟這個文件映射。


如此一來，即便病毒結束，但由於Explorer.exe還對映射頁面保持引用，所以一份病毒體程式碼就一直保持在可以影響所有工作的記憶體頁面中直至Explorer.exe結束（我直接試過該種方法，在xp下注意要寫一個空循環語句，以免被踢出處理佇列）。



另外還可以通過修改系統動態連接模組（DLL）來進行駐留。


WIN9X下系統DLL（如Kernel32.dll 映射至BFF70000）處於系統共享區域（2G-3G），如果在其程式碼段空隙中寫入一小段病毒程式碼則可以影響其它所有工作。

但Kernel32.dll 的程式碼段在用戶態是只能讀不能寫的。


所以必須先通過特殊手段修改其頁保護內容；而在WINNT/2000/xp系統DLL所在頁面被映射到工作的私有空間（如 Kernel32.dll 映射至77ED0000）中，並具有寫時拷貝內容，即沒有工作試突寫入該頁面時，所有工作共享這個頁面；
而當一個工作試圖寫入該頁面時，系統的頁面錯誤處理程式碼將收到處理器的異常，並檢查到該異常並非訪問違例，同時分配給引發異常的工作一個新頁面，並拷貝原頁面內容於其上且更新工作的頁表以指向新分配的頁。


這種共享記憶體的最佳化給病毒的寫作帶來了一定的麻煩，病毒不能像在WIN9X下那樣僅修改Kernel32.dll一處程式碼便可一勞永逸。


它需要利用 WriteProcessMemory來向每個工作映射Kernel32.dll的位址寫入病毒程式碼，這樣每個工作都會得到病毒體的一個副本，這在病毒界被稱為多工作駐留或每工作駐留（Muti-Process Residence or Per-Process Residence ）。


文中列舉方法在xp－sp1下略作修改即可使用 ，大部分為在程式碼段內加入空循環 。


在sp2下，很多時候報如下檔案檔案類型的錯誤不可訪問的記憶體位址段.........。

[psac]

在原來的帖子中我援引了另一篇我的文件中的例子，但經MM告知那些掛鉤-元件服務等方法在如今的設計中並不是很受歡迎，原因在於新的操作系統許多函數規則是不可預知的，也就是所謂的」黑箱「設計使得設計人員更加偏愛系統層次的執行緒元件服務或者更加直接的接管權限控制的方法，採用最複雜的執行緒元件服務技術甚至可以使殺毒軟體和防火牆得不到足夠的資訊來區分一個程序是否合法。

更進階別的搶奪權限控制甚至可以結束所有殺毒軟體的工作，包括卡巴斯基所採用的受保護的記憶體執行緒技術。

儘管微軟隱藏了很多系統函數，但是經過很多高手的努力，許多隱藏的系統函數已經被找出，並且微軟也有意識的減少隱藏函數的數量。


在前段時間網上洩漏的2000的部分程式碼中，其中關於磁牒文件讀寫的部分（大小為700M的那個壓縮包裡標號為115BH的那個文件其中的第三節子程式碼）其中有很多工作是微軟的開發我的文件中是沒有指出介紹的，不知道以後會不會有人利用這些東西寫病毒。


對病毒稍微有些常識的人都知道，普通病毒是通過將自身附加到宿主尾部（如此一來，宿主的大小就會增加），並修改程序入口點來使病毒得到擊活。


但現在不少病毒通過使用特殊的感染技巧能夠使宿主大小及宿主文件頭上的入口點保持不變。附加了病毒程式碼卻使被感染文件大小不變聽起來讓人不可思議，其實它是利用了PE文件格式的特點：

PE文件的每個節之間留有按簇大小對齊後的空洞，病毒體如果足夠小則可以將自身份成幾份並分別插入到每個節最後的空隙中，這樣就不必額外增加一個節，因而文件大小保持不變。著名的CIH病毒正是運用這一技術的典型範例（它的大小只有1K左右）。


病毒在不修改文件頭入口點的前提下要想獲得控制權並非易事：入口點不變意味著程序是從原程序的入口程式碼處開始執行的，病毒必須要將原程序程式碼中的一處修改為導向病毒入口的跳轉指令。


原理就是這樣，但其中還存在很多可討論的地方，如在原程序程式碼的何處插入這條跳轉指令。

一些查毒工具掃瞄可執行文件頭部的入口點域，如果發現它指向的地方不正常，即不在程式碼節而在資源節或重定位節中，則有理由懷疑文件感染了某種病毒。


所以剛才討論那種病毒界稱之為EPO（入口點模糊）的技術可以很好的對付這樣的掃瞄，同時它還是反虛擬執行的重要手段。


另外值得一提的是現在不少病毒已經支持對壓縮檔案的感染。


如Win32.crypto病毒就可以感染ZIP，ARJ，RAR，ACE，CAB 等諸多檔案檔案類型的壓縮檔案。

這些病毒的程式碼中含有對特定壓縮檔案檔案檔案類型解壓並壓縮的程式碼段，可以先把壓縮檔案中的內容解壓出來，然後對合適的文件進行感染，最後再將感染後文件壓縮回去並同時修改壓縮檔案頭部的校驗和。

目前不少反病毒軟體都支持查多種格式的壓縮檔案，但對有些染毒的壓縮檔案無法殺除。


原因我想可能是怕由於某種緣故，如解壓或壓縮有誤，校驗和計算不對等，使得清除後壓縮檔案格式被破壞。病毒卻不用對用戶的文件損壞負責，所以不存在這種擔心。


個人看來，目前的殺毒軟體在對待加殼病毒的時候表現比較差的為瑞星，懷疑瑞星的殺毒引擎對加殼的東西放映不靈敏，因此瑞星自己加殼了很多病毒放到病毒庫裡，我曾使用一些很少用的加殼方式對某些普通病毒加殼，結果瑞星沒查出來，有待改進。


以上關於病毒的相關文字均來源於 某病毒論壇的文章 ，我個人作了少量修改 。再往下為引擎部分的實現 。

[psac]

殺毒引擎目前主流有兩種實現方式：

1.虛擬機技術

2.既時監控技術

3.智能碼標幟技術


4.行為攔截技術

3.4.為最近兩年搞出來的技術。

3的目的是提高殺毒速度並且預防未知病毒，但就現實而言，除了東方衛士試驗了一下（並且不成功），其餘廠商未開發完全關於該技術的引擎，諾頓的開發人員認為：

「沒有足夠的技術手段來實現文中所提出的殺毒理念（翻譯的可能有不準確之處。『文中』是指智能碼標示技術的理論基礎：


IBM :Another way to the end (實現目的的另一種方式)，在該文中提出了關於預定規則的智能殺毒技術）」。

行為攔截技術（或者別的什麼智能殺毒技術）也是一種預防未知病毒的方法，與虛擬機技術相似，通過對程序行為的分析來判斷其是否為病毒。


對於未知病毒的判斷實際上代表著殺毒軟體廠商在引擎研究方面的最高能力。業界公認，防止未知病毒是「代表研究水準的」。

平心而論，非美國廠商在這方面能力較差。業界對於防止未知病毒能力是按照如下方法衡量的：

以評測當日的殺毒軟體最新版本為該廠商的供測試版本，未知病毒由如下而來：
1.病毒作者提供。


有些病毒作者在將自己的病毒發佈以前總愛送給一些業界的安全雜誌供其評測（最佩服這種人）2.大部分真正的業界安全雜誌都有自己的研究實驗室，他們自己的研究人員會根據最新的趨勢和技術手段及工具寫一些病毒。


一般情況下，這些病毒是不會流到網上去的。3.假病毒。

一些很類似於病毒行為的文件，程序等。

測試的時候病毒庫被置空（就是殺毒軟體試突使用病毒庫時採用程序方法向其返回一個空結果），在這種情況下進行測試。

如果有人有興趣，可以到病毒論壇上搞點新手寫的小病毒（一般也就100-200行），弄上幾十個拿自己的殺毒軟體試一試，就會發現在平均狀態下諾頓病毒庫被置空時起對未知病毒判斷能力還是挺強的，怎麼著也到了x%,(x為兩位數)，很多殺毒軟體結果挺慘的，尤其在對付比較複雜的蠕蟲病毒時，某廠商的產品近乎全軍覆沒。


下面對虛擬機和既時監控進行介紹。由於大家認為在文中加入程序程式碼看著很累，因此不再指出技術實現程式碼，其實根據原理你自己也可以寫出來。



虛擬機，在反病毒界也被稱為通用解密器，已經成為反病毒軟體中最重要的部分之一虛擬機的概念和它與諸如Vmware和WIN9X下的VDM（DOS虛擬機，它用來在32位保護模式環境中執行16真實模式程式碼）是有區別的。其實這些虛擬機的設計思想是有淵源可尋的，都來自於IBM的一批研究人員搞的一套東西。


Vmware作為原操作系統下的一個應用程式可以為執行於其上的目標操作系統新增出一部虛擬的機器，目標操作系統就像執行在單獨一台真正電腦上，絲毫察覺不到自己處於Vmware的控制之下。


當在Vmware中按下電源鍵（Power On）時，視窗裡出現了機器自我檢驗畫面，接著是操作系統的載入，一切都和真的一樣。


而WIN9X為了讓多個程序共享CPU和其它硬體資源決定使用VMs（所有Win32應用程式執行在一部系統虛擬機上；而每個16位DOS程序擁有一部DOS虛擬機），winxp是採用區域記憶體訪問來實現16位程序支持的。

VM是一個完全由軟體虛構出來的東西，以和真實電腦完全相同的方式來回應應用程式所提出的需求。從某種角度來看，你可以將一部標準的PC的結構視為一套 API。



這套API的元素包括硬體I/O系統，和以中斷為基礎的BIOS和MS-DOS。WIN9X常常以它自己的軟體來代理這些傳統的API元素，以便能夠對珍貴的硬體多重發訊。


在VM上執行的應用程式認為自己獨佔整個機器，它們相信自己是從真正的鍵盤和滑鼠獲得輸入，並從真正的螢幕上輸出。稍被加一點限制，它們甚至可以認為自己完全擁有CPU和全部記憶體。



查毒的虛擬機並不是象某些人想像的：如Vmware一樣為待查可執行程序新增一個虛擬的執行環境，提供它可能用到的一切元素，包括硬碟，連接阜等，讓它在其上自由發揮，最後根據其行為來判定是否為病毒。


當然這是個不錯的構想，但考慮到其設計難度過大（需模擬元素過多且行為分析要借助人工智能理論），因而只能作為以後發展的方向。


就目前可以知道的資訊而言，卡巴斯基在這方面做得還可以，mcafee的新產品中加入了一種溢出保護技術，本質上而言也是一種所謂的虛擬技術。


查毒的虛擬機是一個軟體模擬的CPU，它可以像真正CPU一樣取指，譯碼，執行，它可以模擬一段程式碼在真正CPU上執行得到的結果。



給定一組機器碼序列，虛擬機會自動從中取出第一條指令操作碼部分，判斷操作碼檔案類型和尋址方式以確定該指令長度，然後在相應的函數中執行該指令，並根據執行後的結果確定下條指令的位置，如此循環反覆直到某個特定情況發生以結束工作，這就是虛擬機的基本工作原理和簡單流程。


設計虛擬機查毒的目的是為了對付加密變形病毒，虛擬機首先從文件中確定並讀取病毒入口處程式碼，然後以上述工作步驟解釋執行病毒頭部的解密段（decryptor），最後在執行完的結果（解密後的病毒體明文）中尋找病毒的特徵碼。



這裡所謂的「虛擬」，並非是新增了什麼虛擬環境，而是指染毒文件並沒有實際執行，只不過是虛擬機模擬了其真實執行時的效果。


這就是虛擬機查毒基本原理。


曾經跟搞殺毒的技術人員探討是否可以採用模擬實際執行的方法來搞一套殺毒軟體，回答是微軟可以，因為微軟可以在系統底層搞一套硬體虛擬層，來實現硬體虛擬。


我忽然想到，如果微軟真的搞殺毒軟體，其實無論別的殺毒軟體公司多麼強，大家都得徹底玩完。



早期病毒沒有使用任何複雜的反檢測技術，如果拿反彙編工具開啟病毒體程式碼看到的將是真正的機器碼。


因而可以由病毒體內某處一段機器程式碼和此處距離病毒入口（注意不是文件頭）偏移值來唯一確定一種病毒。查毒時只需簡單的確定病毒入口並在指定偏移處掃瞄特定程式碼串。



這種靜態掃瞄技術對付普通病毒是萬無一失的。



隨著病毒技術的發展，出現了一類加密病毒。


這類病毒的特點是：其入口處具有解密子（decryptor），而病毒主體程式碼被加了密。


執行時首先得到控制權的解密程式碼將對病毒主體進行循環解密，完成後將控制交給病毒主體執行，病毒主體感染文件時會將解密子，用隨機密鑰加密過的病毒主體，和儲存在病毒體內或嵌入解密子中的密鑰一同寫入被感染文件。


由於同一種病毒的不同傳染實例的病毒主體是用不同的密鑰進行加密，因而不可能在其中找到唯一的一段程式碼串和偏移來代表此病毒的特徵，似乎靜態掃瞄技術對此即將失效。


但仔細想想，不同傳染實例的解密子仍保持不變機器碼明文（從理論上講任何加密程序中都存在未加密的機器碼，否則程序無法執行），所以將特徵碼選於此處雖然會冒一定的誤報風險（解密子中程式碼缺少病毒特性，同樣的特徵碼也會出現在正常程序中），但仍不失為一種有效的方法。


由於加密病毒還沒有能夠完全逃脫靜態特徵碼掃瞄，所以病毒寫作者在加密病毒的基礎之上進行改進，使解密子的程式碼對不同傳染實例呈現出多樣性，這就出現了加密變形病毒。



它和加密病毒非常類似，唯一的改進在於病毒主體在感染不同文件會構造出一個功能相同但程式碼不同的解密子，也就是不同傳染實例的解密子具有相同的解密功能但程式碼卻截然不同。


比如原本一條指令完全可以拆成幾條來完成，中間可能會被插入無用的垃圾程式碼。


這樣，由於無法找到不變的特徵碼，靜態掃瞄技術就徹底失效了。


在這種情況下，虛擬機技術將會派上用場。
既時監控技術其實並非什麼新技術，早在DOS編程時代就有之。


只不過那時人們沒有給這項技術冠以這樣專業的名字而已。



在WINDOWS下要實現既時監控決非易事，普通用戶態程序是不可能監控系統的活動的，這也是出於系統安全的考慮。

病毒既時監控（For WIN9X&WINNT/2000）都使用了驅動編程技術，讓工作於系統核心態的驅動程式去攔截所有的文件訪問。

當然由於工作系統的不同，驅動程式無論從結構還是工作原理都不盡相同的，當然程序寫法和編譯環境更是千差萬別了，上面提到的病毒既時監控其實就是對文件的監控，說成是文件監控應該更為合理一些。

除了文件監控外，還有各種各樣的既時監控工具，它們也都具有各自不同的特點和功用。

現在流行的什麼網路監控，郵件監控基本上是對文件監控的改進，革命性的改動沒有。

[psac]

病毒既時監控其實就是一個文件監視器，它會在文件開啟，關閉，清除，寫入等操作時檢查文件是否是病毒攜帶者，如果是則根據用戶的決定選項不同的處理方案，如清除病毒，禁止訪問該檔案，移除該檔案或簡單地忽略。


這樣就可以有效地避免病毒在本地機電腦上的感染傳播，因為可執行文件裝入器在裝入一個文件執行時首先會要求開啟該檔案，而這個請求又一定會被既時監控在第一時間截獲到，它確保了每次執行的都是乾淨的不帶毒的文件從而不給病毒以任何執行和發作的機會。

以上說的僅是病毒既時監控一個粗略的工作程序，病毒既時監控的設計主要存在以下幾個難點：


其一是驅動程式的編寫不同於普通用戶態程序的寫作，其難度很大。寫用戶態程序時你需要的僅僅就是使用一些熟知的API函數來完成特定的目的，比如開啟文件你只需使用CreateFile就可以了；但在驅動程式中你將無法使用熟悉的CreateFile。


在NT/2000下你可以使用 ZwCreateFile 或NtCreateFile（native API），但這些函數通常會要求執行在某個IRQL（中斷請求級）上，如果你對如中斷請求級，延遲/異步程序使用，非分頁/分頁記憶體等概念不是特別清楚，那麼你寫的驅動將很容易導致顯示藍色當機（BSOD），Ring0下的異常將往往導致系統崩潰，因為它對於系統總是被信任的，所以沒有相應處理程式碼去捕獲這個異常。在NT下對KeBugCheckEx的使用將導致顯示藍色的出現，接著系統將進行轉儲並隨後重啟。



另外驅動程式的偵錯不如用戶態程序那樣方便，用象VC ++那樣的偵錯器是不行的，你必須使用系統級偵錯器，如softice,kd,trw等。



其二是驅動程式與ring3下客戶程序的通信問題。這個問題的提出是很自然的，試想當驅動程式截獲到某個文件開啟請求時，它必須通知位於ring3下


的查毒模組檢查被開啟的文件，隨後查毒模組還需將查毒的結果通過某種方式傳給ring0下的監控程序，最後驅動程式根據返回的結果決定請求是否被允許。


這裡面顯然存在一個雙向的通信程序。


寫過驅動程式的人都知道一個可以用來向驅動程式傳送設備I/O控制資訊的API使用DeviceIoControl，它的接頭在MSDN中可以找到，但它是單向的，即ring3下客戶程序可以通過使用DeviceIoControl將某些資訊傳給ring0下的監控程序但反過來不行。



既然無法找到一個現成的函數實現從ring0下的監控程序到ring3下客戶程序的通信，則我們必須採用迂迴的辦法來間接做到這一點。


為此我們必須引入異步程序使用（APC）和事件對象的概念，它們就是實現特權級間喚醒的關鍵所在。

現在先簡單介紹一下這兩個概念，具體的用法請參看後面的每子章中的技術實現細節。


異步程序使用是一種系統用來當條件合適時在某個特定執行緒的上下文中執行一個程序的機制。當向一個執行緒的APC佇列排隊一個APC時，系統將發出一個軟體中斷，當下一次執行緒被調度時，APC函數將得以執行。

APC分成兩種：

系統新增的APC稱為內核模式APC，由套用程式新增的APC稱為用戶模式APC。另外只有當執行緒處於可報警（alertable）狀態時才能執行一個APC。


比如使用一個異步模式的ReadFileEx時可以指定一個用戶自訂的回調函數FileIOCompletionRoutine，當異步的I/O操作完成或被取消並且執行緒處於可報警狀態時函數被使用，這就是APC的典型用法。


Kernel32.dll中匯出的QueueUserAPC函數可以向指定執行緒的佇列中增加一個APC對象，因為我們寫的是驅動程式，這並不是我們要的那個函數。



很幸運的是在Vwin32.vxd中匯出了一個同名函數QueueUserAPC，監控程序攔截到一個文件開啟請求後，它馬上使用這個服務排隊一個ring3下客戶程序中需要被喚醒的函數的APC，這個函數將在不久客戶程序被調度時被使用。


這種APC喚醒法適用於WIN9X，在 WINNT/2000下我們將使用全局共享的事件和信號量對象來解決互相喚醒問題。有關WINNT/2000下的對象組織結構我將在3.4.2節中詳細說明。

NT/2000版監控程序中我們將利用KeReleaseSemaphore來喚醒一個在ring3下客戶程序中等待的執行緒。



目前不少反病毒軟體已將驅動使用的查毒模組移到ring0，即如其所宣傳的「主動與操作系統無縫連接」，這樣做省卻了通信的消耗，但把查毒模組寫成驅動形式也同時會帶來一些麻煩，如不能使用大量熟知的API，不能與用戶既時交互，所以我們還是選項分析傳統的反病毒軟體的監控程序。
其三是驅動程式所佔用資源問題。


如果由於監控程序頻繁地攔截文件操作而使系統效能下降過多，則這樣的程序是沒有其存在的價值的。本論文將對一個成功的反病毒軟體的監控程序做徹底的分析，其中就包含有分析其用以提高自身效能的技巧的部分，如設定歷史記錄，內裝檔案檔案類型過濾，設定等待超時等。


這段文字也是從關於病毒工作原理那篇文章裡搞出來的，由於那是一片老文章，因此其中的很多觀點可能在現在已經不再適用，很多加密方式已經變得很強。


本人並不非常贊同文章關於既時監控技術的解釋。MM告訴我，現在的關於NT內核的操作系統套用程式文件-套用程式－操作系統之間的回應關係與原9x時代還是有一定區別的，特別是加入了很多執行緒級的權限控制，殺毒軟體現在可以採用既時記憶體監控的方法來影射套用程式的活動。

為什麼歐美的軟體廠商沒有搞出那麼多的監控方式像什麼「網頁監控，聊天軟體監控等」,原因很簡單，因為病毒能夠起作用，就必須在記憶體中執行，因此良好的文件監控和記憶體監控足以解決病毒，國內搞出那麼多名堂更多的是出於市場商業考慮。



毋庸置疑，現在的殺毒軟體引擎都是虛擬機技術和既時監控技術的復合體。由於各家研發人員所研究的方向不同，各產品的殺毒品質也非常迥異。


比如諾頓的殺毒理念就是在確保系統正常執行的前提下，控制最終消除可能影響系統穩定的因素；而另有些廠商則認為殺毒軟體應該最快的消除有害程序。


業界一種獲得公認的設計底線是殺毒軟體絕對不能因為殺毒導致系統崩潰，可惜的是現在很多廠商屢屢撞線。

[psac]

以下為各家廠商的殺毒引擎簡介，文中有一部分來源於業已公開的技術資料，有一部分來源於在病毒論壇上被奉為傳統的反編，還有一部分來源於廠商技術人員的介紹（官方和私下的都有）。


1.諾頓：這個最熟悉了，諾頓的殺毒軟體實際上防止偵測方面做得並不是很好，很多病毒程序在子程序段中經常借鑒搞崩諾頓的程式碼，希望在新版本中諾頓可以採用更強的自身防護技術。


諾頓的引擎應該是完全自成封閉體系的，沒有資料證實諾頓曾經購買或者借鑒過別的殺毒引擎。

傳聞很多公司都在設計時參考過卡巴斯基的洩漏版引擎設計，因此曾經在微軟社區在線聊天時，問過這個問題。回貼一致認為諾頓借鑒卡巴斯基的殺毒引擎毫無必要，它自己的引擎搞得挺好的。


有一個叫fenssa的傢伙甚至回貼說不考慮病毒庫因素，諾頓的殺毒引擎相當先進，綜合防護效能很好。


在微軟，除了用mcafee的就使用諾頓的（這一點我比較相信，很少見到別的殺軟在微軟被使用）。


從諾頓的技術我的文件描述和在病毒論壇上流傳的29A的一個傢伙搞的一篇叫虛擬機環境下諾頓工作程序的步進追蹤和反編的文章來看，諾頓的殺毒引擎應該是傳統的靜態程式碼對應與既時監控的完美結合，應該有一些改進的虛擬機技術在裡面（諾頓的人並不怎麼推崇虛擬機技術）。諾頓的殺毒速度慢，應該源於諾頓採用了較多的靜態程式碼這種傳統的檢查方式有關。


我個人非常喜歡諾頓的隔離機制，我認為在沒有確定完全正確的處理方式之前，移除是不應該被採用的。


一個高手寫的病毒應該能盡可能的與系統工作相關，在這種情況下，隔離的優勢立刻顯現。諾頓資源佔用量比較大，但實現了如下設計目標：
能識別的病毒和被識別為病毒的工作完全可以正確處理，對已經不可能產生破壞作用的』病毒屍體『不會產生誤判，更不會出現出現一次又一次的在處理完某病毒後又檢測其為病毒的狀況。



很多人認為諾頓企業版和個人板採用的引擎完全一致這種理解不很正確。實際上企業版在個人板的技術上還是有改進的。

zdnet上刊登過一篇文章指出：
企業版和個人版引擎的核心規則完全一樣，但在前端文件匯入部分企業版是優於個人版的，企業版使用了更多的API接頭。


文章中說，在大規模文件掃瞄時，企業版明顯優於個人版。


並且由於使用了負載技術，企業版資源佔用還好一點。

另外據說企業版支持關於網路的多重負載技術。


卡巴從去年已經是微軟安全軟體的金牌合作夥伴吧！

微軟的各層次的合作夥伴滿天飛，只有那種能獲得」來源碼級「系統底層支持的合作夥伴才是微軟所真正給與最強大技術支持的。諾頓和mcafee很少宣傳自己是什麼層次的合作夥伴，關鍵在於能給多少支持。

反彙編過norton，就知道它在ring0。

另外，其實網頁的監控還是比較必要的，網頁的指令碼在記憶體中執行，文件監控無法做到攔截。

當然如果有很好的記憶體監控可以解決這個問題。但是真正的記憶體監控比較難實現。

[psac]

Mcafee:記得看過一篇報道說mcafee收購過別的殺毒軟體引擎設計公司，據回貼可知為所羅門。


在網上很少能看到關於對mcafee的殺毒引擎進行過份析的技術我的文件，但從他自己宣傳的資料看，mcafee對虛擬機技術和既時監控研究的都挺徹底的。

比如他最近宣傳防止應用程式溢出（大致這個名字）的技術，應該是在不考慮硬體平台的情況下虛擬機技術和既時監控技術結合的上乘之作，儘管經常出現錯誤的溢出偵測（軟體層面的放溢出技術確實不很穩定）。

在處理大量的文件時，mcafee有一定的速度優勢（微軟社區中有這個問題的論述）。

有來自於mcafee論壇的消息說，mcafee 正在研究更先進的智能碼掃瞄技術，估計肯定比東方衛士搞得要好。

根據組長的回貼，McAfee自發佈VSE8.0i以來就著重於「前懾防範」這一新型的安全領域，並且NORTON也在超這一方向邁進。


「前懾防範」一共分為兩個部分，其一為運用部分防火牆技術外加其入侵檢測技術有效的阻斷病毒的傳播源，以至於病毒在傳染的初期無法得到大面積的傳播降低了危害性；其二為依靠其強大的特徵碼檢測技術（Extra.dat）對病毒的行為方式、特徵程式碼等進行檢測，依靠它強大的研發團隊以及原則聯盟夥伴使其在這一領域獨樹一幟。諾頓能在其新版產品中也加入了一些原本屬於防火牆的功能。


發郵件詢問諾頓的研究人員為什麼沒有採用特徵碼殺毒技術，回應說一個完美的特徵碼掃瞄技術應該能夠達到根據用戶的指定加入特定文件為病毒的目的，也就是當用戶指定某個活動程序為病毒時，殺毒軟體的引擎能夠根據自身的規則為該活動程序定義一個特徵碼，並且在控制該活動程序時，能夠有效地斷絕其與系統正常工作的關聯。


在沒有這個水準之前，諾頓不會大規模採用特徵碼技術。

從mcafee的技術我的文件來看，mcafee也只是有限度的試驗性的研究該技術，並在比較有把握的地方套用。實際上兩家公司在這方面還有很長的路要走。

[psac]

卡巴斯基：本論壇上被過度神話的殺毒軟體。我個人非常尊重卡巴斯基的高水準，但說句實話，在不考慮資源佔用的情況下，卡巴斯基並沒有什麼足夠的理由能夠讓我放棄諾頓，二者的水準並沒有什麼差異。在穩定性上，卡巴斯基比諾頓要差一些。


由於早些年卡巴斯基的引擎曾經洩漏（實際上洩漏的並不是初始來源碼，只是洩漏的引擎可以比較容易的反編），因此網上可以找到很多關於卡巴斯基引擎的非常詳細的技術分析，尤其是德國的病毒高手寫的關於如何最佳化卡巴斯基殺毒引擎的文章，被認為是所有採用卡巴斯基引擎的殺毒軟體廠商必看的文章之一，就像美國人寫的那篇VB100到底怎麼測試殺毒軟體（裡面作者綜合近幾年的測試結果推測了VB100在測試時可能使用的病毒檔案檔案類型，相關比例等）是殺毒軟體廠商在將自己的軟體送測前必看的文章一樣。


從網上大量的分析我的文件看卡巴斯基的虛擬機技術是很優秀的，但是去年有人發帖認為卡巴斯基的良好的效能來源於它非常龐大的病毒庫和良好的昇級速度，其殺毒引擎設計水準並不高於其餘的公司。


卡巴斯基的引擎採用了所謂的單一形式的規則判斷，眾所周知諾頓是關於分類的規則處理。


卡巴斯基的引擎在文件標幟比對病毒庫的時候被認為有著很好的效能，充分利用了處理器的處理能力，「但令人擔憂的是，該公司對最新出現的技術並不充分重視」（英國的電腦雜誌去年年末的評論），究竟是對原有引擎進行徹底改進還是大量使用新技術，估計誰都不知道。


卡巴斯基的引擎存在叫做所謂的「過與簡短的文件碼」問題，說白了就是有時候會鞭屍，它的研究人員說正在改進。

前段時間有人發帖子中指出病毒編寫者只認可卡巴斯基，說實話看了很多論壇我的文件，好像沒有哪個強人這麼說過。卡巴斯基走的是與美國廠商有很大區別的研發道路，卡巴斯基很少引用別的公司開發的技術，而是在不斷的深化，改進自身的殺毒引擎，單從某些方面評論，卡巴斯基的引擎代表著業界最高水準，但並不是全部。


卡巴斯基是一款很好的殺毒軟體，但並不是神。應該說它與諾頓，mcafee一樣都站在殺毒軟體的頂峰水準上。



在大陸的國內，一直有江民的殺毒軟體採用卡巴斯基引擎的傳聞，說句實話業界相當一部分殺毒軟體都參考了其引擎設計，即使在大陸國內也沒有足夠的資訊證實只是江民參考了其引擎設計。很多人都使用各種各樣的病毒包對卡巴斯基和江民進行測試，測試結果是完全一樣。

說句實話，這種測試並沒有什麼可信性，對化石孢的檢測各種殺毒軟體結果幾乎都一樣。

只有兩種方法能夠說兩者的引擎如何：

1.將兩款軟體送至VB100或者類似的權威機構進行測試，如果兩者對其中未知病毒的測試結果（這個結果並不公佈，廠商自己去買）完全一樣，那什麼都沒說的。


兩個不同的引擎機制在對待同樣大規模的未知病毒庫時出現相同的檢測結果近乎是不可能的。可惜的是，江民沒有參加過VB100測試，好像也不大可能個人有足夠龐大的未知病毒庫來進行檢測。

2.採用類似於破解的方法進行反編，分析整個軟體的工作機制，工作量有多大相信都能猜出來，也沒有見過有人搞過這種研究。

因此我個人只能認為江民可能（較大程度的）參考了卡巴斯基的殺毒引擎設計，但從兩款殺毒軟體的靈敏程度，殺毒速度等諸多方民看，即使江民採用了卡巴斯基的引擎，江民也應該進行了很大程度的來源碼修改或者最佳化，另外也有消息說江民在引擎中加入了一些自己開發的技術，在實現方法上類似於數位碼技術。

霏凡下載網站上曾有高手指出假如公佈兩款軟體的來源碼，可能並不會有人能看出二者有什麼關係。實際上，當發現江民的軟體並不能使用卡巴斯基的病毒庫的時候，我們就應該知道即便曾經借鑒過，二者也已經可以被認為是不同的殺毒引擎。


可能在win3.x平台下，二者曾經很相近；但是今天我們在使用winxp.即使江民確實採用過卡巴斯基的引擎，那麼可以說江民在某些方面發展了這套引擎，儘管這種發展未必與原始的研發方向相符。


但無論關於何種角度考慮，我認為江民的殺毒軟體還是有優秀之處的。畢竟你回頭看一看大陸的國內的殺毒軟體廠商，在真正的技術研發領域只有這麼一面旗幟偶爾飄揚。


一步步走下來，江民還是有技術進步的。

只就純技術因素而論，假如江民採用了卡巴斯基的引擎，那麼今天兩家廠商在不同的方向上發展著那套原始的引擎，這未必是壞事，只要不故步自封，我們好像沒什麼必要爭論兩家廠商是否一個原始祖先，怕的就是在別人都往前跑的時候自己停下來，這跟自取滅亡沒什麼區別。

儘管市場是殺毒軟體廠商的第一要素，但別忘了技術是一個殺毒軟體能否基業常青的決定性力量。

有人問趨勢採用什麼引擎，現在我個人只知道它的引擎是自己研發的，屬於純規則分析型引擎，在技術上套用中間件技術。

但是趨勢公司的病毒庫好像有點小，僅是傳聞而已。
因為在日本與台灣使用較多...大陸較少...防弊的盜版也少..鮮少接屬技術資料層面....或許由它人補充說明...................
能夠看到的關於它的評論如下:"在不考慮病毒庫因素的情況下，趨勢的產品擁有優秀的引擎技術和防護效能（翻譯大致意思）」。
全文完。