基本信息
病毒和正常程式的區別可以體現在許多方面，比較常見的如通常一個應用程式在最初的指令是檢查命令行輸入有無參數項，清屏和保存原來螢幕顯示等，而病毒程式則從來不會這樣做，它通常最初的指令是直接寫盤操作、解碼指令，或搜尋某路徑下的可執行程式等相關操作指令序列。這些顯著的不同之處，一個熟練的程式設計師在調試狀態下只需一瞥便可一目了然。啟發式掃描技術 實際上就是把這種經驗和知識移植到一個查病毒軟體中的具體程式體現。
因此，在這裡，啟發式指的“自我發現的能力”或“運用某種方式或方法去判定事物的知識和技能。”
一個運用啟發式掃描技術的病毒檢測軟體，實際上就是以特定方式實現的動態高度器或反編譯器，通過對有關指令序列的反編譯逐步理解和確定其蘊藏的真正動機。例如，如果一段程式以如下序列開始：MOV AH ,5/INT,13h， 即調用格式化盤操作的BIOS指令功能，那么這段程式就高度可疑值得引起警覺，尤其是假如這段指令之前不存在取得命令行關於執行的參數選項，又沒有要求用戶互動性輸入繼續進行的操作指令時，可以有把握地認為這是一個病毒或惡意破壞的程式。 在具體實現上，啟發式掃描技術是相當複雜的。通常這類病毒檢測軟體要能夠識別並探測許多可疑的程式代碼指令序列，如格式化磁碟類操作，搜尋和定位各種可執行程式的操作，實現駐留記憶體的操作，發現非常的或未公開的系統功能調用的操作，等等，所有上述功能操作將被按照安全和可疑的等級可以排序，根據病毒可能使用和具備的特點而授以不同的加權值。 隨便舉個例子，格式化磁碟的功能操作幾乎從不出現在正常的應用程式中，而病毒程式中則出現的幾率極高，於是這類操作指令序列可獲得較高的加權值，而駐留記憶體的功能不僅病毒要使用，很多應用程式也要使用，於是應當給予較低的加權值。如果對於一個程式的加權值的總和超過一個事先定義的閾值， 那么， 病毒檢測程式就可以聲稱“發現病毒！”僅僅一項可疑的功能操作遠不足以觸發“病毒報警”的裝置，如果不打算上演“狼來了”的謊報和虛報來故意嚇人，最好把多種可疑功能操作同時並發的情況定為發現病毒的報警標準。
啟發式掃描通常應設立的標誌，為了方便用戶或研究人員直觀地檢測被測試程式中可疑功能調用的存在情況，病毒檢測程式可以顯示為不同的可疑功能調用設定標誌。例如，TbScan（參見注釋）這一病毒檢測軟體就為每一項它定義的可疑病毒功能調用賦予一個旗標，如F,R,A……， 這樣以來可以直觀地幫助我們對被檢測程式進行是否染毒的主觀判斷。
各標誌的含義
F= 具有可疑的檔案操作或能。有可疑進行感染的操作。R= 重定項功能。程式將以可疑的方式進行重定向操作。
A= 可疑的記憶體分配操作。程式使用可疑的方式進行記憶體申請和分配操作。
N= 錯誤的檔案擴展名。擴展名預期程式結構與當前程式相矛盾。
S= 包含搜尋定位可執行程式（如EXE或COM）的例程。
#= 發現解碼指令例程。這在病毒和加密程式中都是經常會出現的。
E= 靈活無常的程式入口。程式被蓄意設計成可編入宿主程式的任何部分，病毒極頻繁使用的技術。
L= 程式截獲其它軟體的載入和裝入。有可能是病毒為了感染被載入程式。
D= 直接寫盤動作。程式不通過常規的DOS功能調用而進行直接寫盤動作。
M= 記憶體駐留程式。該程式被設計成具有駐留記憶體的能力。
I= 無效操作指令。非8088指令等。
T= 不合邏輯的錯誤的時間標貼。有的病毒藉此進行感染標記。
J= 可疑的跳轉結構。使用了連續的或間接跳轉指令。這種情況在正常程式中少見但在病毒中卻很平常。
?= 不相配的EXE檔案。可能是病毒，也可能是程式設計失誤導致。
G= 廢操作指令。包含無實際用處，僅僅用來實現加密變換或逃避掃描檢查的代碼序列。
U= 未公開的中斷/DOS功能調用。也許是程式被故意設計成具有某種隱蔽性，也有可能是病毒使用一種非常規手法檢測自身存在性。
O= 發現用於在記憶體在搬移或改寫程式的代碼序列。
Z= EXE/COM辨認程式。病毒為了實現感染過程通常需要進行此項操作。
B= 這回程式入口。包括 可疑的代碼序列， 在完成對原程式入口處開始的代碼修改之後重新指向修改前的程式入口病毒極常見。
K= 非正常堆疊。程式含有可疑的或名其妙的堆疊。
例如對於以下病毒，TbScan將點亮以下不同標誌。 Jerusalum/PLO(耶路撒冷病毒) FRLMUZ Backfont/ 後體病毒 FRALDMUZK mINSK-gHOST FELDTGUZB Murphy FSLDMTUZO Ninja FEDMTUZOBK Tolbuhin ASEDMUOB Yankee-Doodle FN#ELMUZB
對於某個檔案來說，被點亮的標誌愈多，染毒的可能性就愈大。常規乾淨程式甚至很少會點亮一個標誌旗，但如果要作為可疑病毒報警的話，則至少要點亮兩個以上標誌旗。如果再給不同的標誌旗賦以不同的加權值，情況還要複雜得多。
關於虛警（謊報）
正如任何其他的通用檢測技術一樣，啟發式掃描技術有時也會把一個本無病毒的程式指證為染毒程式，這就是所謂的查毒程式虛警或謊報現象。原因很簡單。被檢測程式中含有病毒所使用或含有的可疑功能。例如，QEMM所提供的一個LOADHI.COM程式就會含有以下可疑功能調用。 LoadHi程式中確實含有以上功能調用，而這些功能調用足以觸發檢毒程式的報警裝置。因為LoadHi的作用就是為了分配高端記憶體，將駐留程式（通常如設備驅動程式等等）裝入記憶體，然後移入高端記憶體，等等……，所有這些功能調用都可以找到一個合理的解釋和確認，然而，檢毒程式並不能分辨這些功能調用的真正用意，況且這些功能調用又常常被套用在病毒程式中，因此，可憐的檢測程式只能判定Load Hi程式為“可能是病毒程式”。 虛警（謊報）的後果有多嚴重 如果某個基於上述啟發式代碼掃描技術的病毒檢測程式在檢測到某個檔案時彈出報警視窗“該程式可以格式化磁碟且駐留記憶體”而你自己確切地知道當前被檢測的程式是一個駐留式格式化磁碟工具軟體，這算不算虛警謊報呢？ 因為一個這樣的工具軟體顯然應當具備格式化盤以及駐留記憶體的能力。啟發式代碼檢測程式的判斷顯然正確無誤，這可算做虛警，但不能算做謊報（誤報）。問題在於這個報警是否是“發現病毒”， 如果報警視窗只是說“該程式具備格式化盤和駐留功能”，好，100%正確，但它如果說“發現病毒”，那么顯然是100%的錯了。關鍵是我們片怎樣看待和理解它真正的報警的含義。檢測程式的使命在於發現和闡述程式內部代碼執行的真正動機，到底這個程式會進行哪些操作，關於這些操作是否預期或合法，尚需要用戶方面的判斷。不幸的是，對於一個一的新手來說，要做出這樣的判斷仍然是有困難的。如何避免虛警和誤報
不管是虛警也好，誤報或謊報也好，拋開具體的名稱叫法不談，我們決不希望在每次掃描檢測的時候我們的檢測程式無緣由地狂喊“狼來了”，我們要盡力減少和避免這種人為的緊張狀況，那么如何實現呢？必須努力做好以下幾點：1、 對於病毒行為的準確把握而給定的關於可疑功能調用集合的精確的定義。除非滿足兩個以上的病毒重要特徵，否則不予報警。
2、 對於常規的程式代碼的和識別能力。某些編譯器提供運行時實時解壓或解碼的功能及服務例程，而這些情形往往是導致檢測時誤報警的原因，應當在檢測程式中加入認知和識別這些情狀的功能模組，以避免再次誤報。
3、 對於特定程式的識別能力。如上面涉及到的LoadHi及駐留式格式化工具軟體等等。
4、 類似“無罪假定”的功能，首先假定程式和電腦是不含病毒的。許多啟發式代碼分析檢毒軟體具有自學習功能，能夠記信那些並非病毒的檔案並在以後的檢測過程中避免再報警。
如何處理虛警謊報
不管採用什麼樣的措施，虛警謊報現象總是要存在的。因此不可避免地用戶要在某些報警信息出現時作出自己的抉擇：是真正病毒還是誤報？也許會有人說：“我怎么知道被報警的程式到底是病毒還是屬於無辜誤報？”大多數人在問及這個問題的第一反應，是“誰也無法證明和判斷。”事實上是有辦法作出最終判決的，但是這還要取決於套用啟發式代碼分析檢測技術的查病毒程式的具體解釋。 假如檢測軟體僅僅給出“發現可疑病毒功能調用”這樣簡單的警告，信息而沒有更多的輔助信息，對於用戶來說幾乎沒有什麼可資判斷是否真正病毒的實際幫助價值，換個說法，“可能是病毒”似乎永遠沒錯，不必擔負任何責任，而用戶不希望得到這樣模稜兩可的解釋。 相反地，如果檢測軟體把更為具體和實際的信息報告給用戶，比如“警告，當前被檢測程式含有駐留記憶體和格式化軟硬碟的功能”，類似的情況更能幫助用戶擴清楚到底會發生什麼？該採取怎樣應對措施。比如這種報警是出現在一個字處理編輯軟體中，那么用戶幾乎可以斷定這是一個病毒。當然如果這種報警是出現在一個駐留格式化盤工具軟體上，用戶大可不必緊張萬分了。這樣以來，報警的可疑病毒常用功能調用都能得到合理的解釋，因而也會得到圓滿正確的處理結果。 自然地， 需要一個有經驗的用戶從同樣的報警信息中推理出一個 “染毒”還是“無毒”的，結論並非每一個用機者可以完全勝任的。因此，如果把這類軟體設計成有某種學習記憶的能力，在第一次掃描時由有經驗的用戶逐一對有疑問的報警信息作好“是”與“非”的判斷，而在以後的各次掃描檢測時，由於軟體學習並記憶了第一次檢測時處理結果，將不再出現同樣的煩人的提示警報。因為不論在什麼情況下，偶爾請教一下某個有經驗的“高手”並不，難難堪的是每次就同樣的問題去麻煩別人。 不管怎樣的缺點和不足，和其它的掃描識別技術相比起來，啟發式代碼分析掃描技術幾乎總能提供足夠的輔助判斷，信息讓我們最終判定被檢測的目標對象是染毒的，亦或是乾淨的。啟發式代碼分析檢測技術的實用套用效果如何？啟發式掃描技術仍然是一種正在發展和不斷完善中的新技術，但已經在大量優秀的反病毒軟體中得到迅速的推廣和套用。按照最保守的估計，一個精心設計的算法支持的啟發式掃描軟體，在不依賴任何對病毒預先的學習和了解的輔助，信息如特徵代碼，指紋字串，校驗和等等的支持下，可以毫不費力地檢查出90%以上的對它來說是完全未知的新病毒。 可能會出現一些個虛報、謊報的情況，適當加以控制，這種誤報的機率可以很容易地被降低在0.1%以下。 傳統掃描技術與啟發式代碼分析掃描技術的結合運用 前面論述了簋多啟發式代碼分析技術的優點和長處，會不會引起某些人的誤解，以為傳統的檢測掃描技術就可以丟棄了呢？情況當然不是這樣。從實際套用的效果看來，傳統的手法由於基於對已知病毒的分析和研究，在檢測時能夠更準確，減少誤報；但如果是對待此前根本沒有見過的新病毒，由於傳統手段的知識庫並不存在該類（種）病毒的特徵數據，則有可能毫無瓜，產生漏報的嚴重後果。而這時基於規則和定義的啟發式代碼分析技術則正好可以大顯身手，使這類新病毒不至成為漏網之魚。傳統與啟發式技術的結合支用，可以使病毒檢測軟體的檢出率提高到前所未有的水平，而另一方面，又大大降低了總的誤報率。詳見以下測試實驗結果對比數據：
啟發式判定結果 傳統式判定結果 可能的真正結果 乾淨 乾淨 非常可能就是乾淨的 乾淨 有毒 很可能誤報 有毒 乾淨 很可能有毒 有毒 有毒 極有可能確實染毒 三種技術結合使用 虛報率 10% 1% 1% 漏報率 0.1% 0.001% 0.00001% 某種病毒能夠同時逃脫傳統和啟發式掃描分析的可能性是小的，如果兩種分析的結論相一，致那么真實的結果往往就如同其判斷結論一樣砍無，疑兩種不同技術對同一檢測樣分析的結果不一致的情況比較少見，這種情形下需藉助另外的分析去得出最後結論。 仍然以 TbScan 6.02為測試舉例，下面是分別使用不同技術和結合套用的測試結果： 測試用技術 總數為7210個樣本的病毒檢出數 檢出率 傳統的 7056 97.86% 啟發式 6465 89.67% 結合套用 7194 99.78% 啟發式反毒技術的未來展望 研究的逐步深入，使技術發展不斷進步。一方面絕大多數反病毒廠家的產品中還未能引入一個較為成功和可靠的啟發式檢測技術的核心，另一方面，即使是在少數依靠的知名反病毒產品中這項技術的運用也還需要經受不斷的完善和發展。任何改良的努力都會有不同程度的質量提高，但是不能企望在沒有虛報為代價的前提下使檢出率達到100%，或者反過來說，大約在相當長的時間裡虛報和漏報的機率不可能達到0%。 這聽上去或許有些不可思議，其實不難理解。100%正確的檢測結果只所以不存在，是因為有相當一部分程式（或代碼）介乎於病毒與非病毒之間，即便對於人腦來說，合乎邏輯又合乎病毒定義的結論往往會截然相反。隨便舉一個例子，如果依據廣為接受的病毒的定義：“病毒，就是複製自身的拷貝或改良的複本的一些程式。”那么，眾所周知的磁碟複製程式 DISKCOPY豈不是也落入病毒的分類中了嗎？但是，情況顯然並非如此…… 病毒技術與反病毒技術恰如“道”與“魔”的關係，也許用“道高一尺，魔高一丈”來形容這對矛盾的鬥爭和發展進程再為恰當不過了。當反病毒技術的專家學者在研究啟發式代碼分析技術對傳統的特徵代碼掃描法查毒技術進行改革的時候，也確實收到了很顯著的效果，甚至可以說，相對於病毒技術的加密變換(Mutation)，尤其是多形、無定形病毒技術(Polymorphsm) 對於傳統反毒技術的沉重打擊，殺了一個漂亮的回馬槍。但是，反毒技術的進步也會從另一方面激發和促使那些喪心病狂的病毒製作者的不斷研製出更新的病毒，具有某種反啟發式掃描技術功能，可以逃避這類檢測技術的新型病毒。但是，值得慶幸的是，即便能夠寫出具有這種能力的病毒，它所需要的技術水準和編程能力要複雜得多，絕不可能象對搞傳統的基於特徵值掃描技術的反毒軟體，那么容易，任何一個程式的新手只要將原有的病毒稍加改動， 哪怕只是一個位元組，只要恰 好改變了所謂“特徵位元組”， 就可使這種舊病毒的新變種從未經升級的傳統查毒軟體的眼皮底下逃之夭夭。
結論
拋開啟發式代碼分析技術實現的具體細節和不同手法不談，這種代表著未來反病毒技術發展的必然趨勢具備某種人工智慧特點的反毒技術，向我們展示了一種通用的、不需升級（較省需要升級或不依賴於升級）的病毒檢測技術和產品的可能性，由於諸多傳統技術無法企及的強大優勢，必將得到普遍的套用和迅速的發展。資料顯示，目前國際上最著名的排名在前五名的反病毒軟體產品均聲稱套用了這項技術，從來自不同機構和出處的評測結果來看，純粹的啟發式代碼分析技術的套用（不藉助任何事先的對於被測目標病毒樣本的研究和了解），已能達到80%以上的病毒檢出率， 而其誤報率極易控制在0.1%之下，這對於僅僅使用傳統的基於對已知病毒的研究而抽取“特徵字串”的特徵掃描技術的查毒軟體來說，是不可想像的，一次質的飛躍。 在新病毒，新變種層出不窮，病毒數量不斷激增的今天，這種新技術的產生和套用更具有特殊的重要意義。註：TbScan是ThunderBYTE的產品，The technology ThunderBYTE possessed was of course not lost, it was re-used in the design of the Norman Scanner Engine，已經併入Norman。
