[發(fā)明專利]一種狀態(tài)跟蹤方法及系統(tǒng)

有效

• 申請?zhí)枺?/td>: 201210559987.1
• 申請日: 2012-12-20
• 公開（公告）號: CN103036895A
• 公開（公告）日: 2013-04-10
• 發(fā)明（設(shè)計）人: 潘劍鋒;王宇
• 申請（專利權(quán)）人: 北京奇虎科技有限公司;奇智軟件（北京）有限公司
• 主分類號: H04L29/06
• 分類號: H04L29/06
• 代理公司: 北京國昊天誠知識產(chǎn)權(quán)代理有限公司 11315
• 代理人: 許志勇

技術(shù)領(lǐng)域

本發(fā)明涉及操作系統(tǒng)中運用遠程過程調(diào)用協(xié)議領(lǐng)域，具體地說，涉及一種狀態(tài)跟蹤方法及系統(tǒng)。

背景技術(shù)

主動防御是基于程序行為自主分析判斷的實時防護技術(shù)，不以特征碼作為判斷惡意程序的依據(jù)，而是從最原始的定義出發(fā)，直接將程序的行為作為判斷惡意程序的依據(jù)，其中衍生出在本地使用特征庫、在本地設(shè)置行為閾值以及在本地啟發(fā)式殺毒的方式來判別、攔截惡意程序的行為，從而一定程度上達到保護用戶個人電腦或計算機的目的。

現(xiàn)有的主動防御系統(tǒng)包括：

1、HIPS（Host-based?Intrusion?Prevention?System，基于主機的入侵防御系統(tǒng)）、沙箱等防御型產(chǎn)品需要對危險操作進行攔截，但是windows操作系統(tǒng)十分靈活，有多種進程間通信（IPC，Inter-Process?Communication）機制，一旦惡意代碼通過IPC利用系統(tǒng)進程來進行危險操作，那么對這種操作就難以攔截，需要改，而攔截惡意代碼是通過IPC向系統(tǒng)服務(wù)發(fā)出的惡意請求。尤其是RPC（Remote?Procedure?Call?Protocol，遠程過程調(diào)用協(xié)議）方式就是最難以攔截的IPC機制之一。RPC是一種通過網(wǎng)絡(luò)從遠程計算機程序上請求服務(wù)，而不需要了解底層網(wǎng)絡(luò)技術(shù)的協(xié)議。RPC協(xié)議假定某些傳輸協(xié)議的存在，如TCP或UDP，為通信程序之間攜帶信息數(shù)據(jù)。在OSI網(wǎng)絡(luò)通信模型中，RPC跨越了傳輸層和應(yīng)用層。RPC使得開發(fā)包括網(wǎng)絡(luò)分布式多程序在內(nèi)的應(yīng)用程序更加容易。

2、Windows操作系統(tǒng)下對RPC攔截需要識別發(fā)起請求的目的，即請求的是什么接口（含GUID（Global?unique?identifier，全局唯一標識符）標識）、什么函數(shù)、什么參數(shù)等內(nèi)容。Windows操作系統(tǒng)下RPC的載體有很多，例如本地過程調(diào)用（LPC）、命名管道（NamedPipe）、TCP/IP網(wǎng)絡(luò)等。在本機系統(tǒng)（不跨網(wǎng)絡(luò)時）上最常見的是LPC與NamedPipe。客戶向服務(wù)器發(fā)起RPC請求首先會先對接口進行綁定（binding），隨后才能發(fā)出請求（Request）調(diào)用指定的程序（Procedure）（通過指明ProcNum或API?number）。現(xiàn)有的RPC攔截都是針對請求（Request）階段的，即只能獲得ProcNum和參數(shù)，并不能獲得GUID標識（這時僅能獲得由binding時的數(shù)字標識），這樣就難以獲得完整的請求信息。

現(xiàn)有技術(shù)中，針對RPC攔截（狀態(tài)跟蹤）僅僅知道ProcNum和參數(shù)，然后根據(jù)一些條件（如port名稱、棧回朔參數(shù)等內(nèi)容）去猜測來判斷客戶端發(fā)送的是否為惡意的請求程序是不準確的。

RPC采用客戶端/服務(wù)器模式，實際上請求程序就是一個客戶端，而服務(wù)提供程序就是一個服務(wù)器。

首先，客戶端調(diào)用進程發(fā)送一個有進程參數(shù)的調(diào)用信息到服務(wù)進程，然后等待答復信息。在服務(wù)器端，服務(wù)進程保持睡眠狀態(tài)直到調(diào)用信息的到達為止。當一個調(diào)用信息到達，服務(wù)器獲得進程參數(shù)，計算結(jié)果，發(fā)送答復信息，然后等待下一個調(diào)用信息，最后，客戶端調(diào)用進程接收答復信息，獲得進程結(jié)果，然后調(diào)用信息繼續(xù)進行。

所以當客戶端為一惡意的請求程序，調(diào)用服務(wù)器完成惡意操作時，攔截程序（狀態(tài)跟蹤程序）在調(diào)用階段介入攔截，攔截獲得調(diào)用參數(shù)，但是現(xiàn)有技術(shù)中并不知道調(diào)用過程中所使用的調(diào)用指令的含義，所以也無從知曉這個調(diào)用指令是要執(zhí)行什么操作，也就不能判斷出操作是否為惡意。

現(xiàn)在技術(shù)中，可以根據(jù)攔截程序在調(diào)用階段介入攔截到的一些其它信息，去猜測調(diào)用指令的含義，當調(diào)用指令僅涉及少量函數(shù)功能時，這種猜測是具備一定操作基礎(chǔ)的。但是往往一個調(diào)用指令中會涉及很多個功能，此時根據(jù)一個調(diào)用指令無法準備獲知客戶端具體要調(diào)用服務(wù)器完成什么操作。

綜上所述，如何準確地獲取客戶端與服務(wù)器之間進行RPC調(diào)用時，調(diào)用的接口和函數(shù)號的準確含義，從而就可以判定客戶端發(fā)送的是否為惡意的請求程序，這樣就能夠進行防御操作，所以上述問題便成為亟待解決的技術(shù)問題。

發(fā)明內(nèi)容

鑒于上述問題，提出了本發(fā)明以便提供一種克服上述問題或者至少部分地解決或者減緩上述問題的一種狀態(tài)跟蹤方法及系統(tǒng)。

根據(jù)本發(fā)明的一個方面，提供了一種狀態(tài)跟蹤方法，用于遠程過程調(diào)用協(xié)議，其包括：

攔截客戶端進程與服務(wù)端進程之間相互綁定時交換的數(shù)據(jù)包，從所述數(shù)據(jù)包中獲取并保存兩個進程相互約定的調(diào)用規(guī)則；

當監(jiān)測到客戶端進程運用遠程過程調(diào)用協(xié)議，請求服務(wù)端進程提供服務(wù)的數(shù)據(jù)包時或響應(yīng)另一進程的數(shù)據(jù)包時，解析該數(shù)據(jù)包并獲取該數(shù)據(jù)包里面含有的調(diào)用指令；