一種狀態跟蹤方法及系統的製作方法

2023-09-20 14:38:10

專利名稱：一種狀態跟蹤方法及系統的製作方法
技術領域：
本發明涉及作業系統中運用遠程過程調用協議領域，具體地說，涉及一種狀態跟蹤方法及系統。
背景技術：
主動防禦是基於程序行為自主分析判斷的實時防護技術，不以特徵碼作為判斷惡意程序的依據，而是從最原始的定義出發，直接將程序的行為作為判斷惡意程序的依據，其中衍生出在本地使用特徵庫、在本地設置行為閾值以及在本地啟發式殺毒的方式來判別、攔截惡意程序的行為，從而一定程度上達到保護用戶個人電腦或計算機的目的。現有的主動防禦系統包括 l、HIPS(Host_based Intrusion Prevention System,基於主機的入侵防禦系統)、沙箱等防禦型產品需要對危險操作進行攔截，但是windows作業系統十分靈活，有多種進程間通信(IPC, Inter-Process Communication)機制，一旦惡意代碼通過IPC利用系統進程來進行危險操作，那麼對這種操作就難以攔截，需要改，而攔截惡意代碼是通過IPC向系統服務發出的惡意請求。尤其是RPC (Remote Procedure Call Protocol,遠程過程調用協議)方式就是最難以攔截的IPC機制之一。RPC是一種通過網絡從遠程電腦程式上請求服務，而不需要了解底層網絡技術的協議。RPC協議假定某些傳輸協議的存在，如TCP或UDP，為通信程序之間攜帶信息數據。在OSI網絡通信模型中，RPC跨越了傳輸層和應用層。RPC使得開發包括網絡分布式多程序在內的應用程式更加容易。2、Windows作業系統下對RPC攔截需要識別發起請求的目的，即請求的是什麼接口(含⑶ID (Global unique identifier,全局唯一標識符)標識)、什麼函數、什麼參數等內容。Windows作業系統下RPC的載體有很多，例如本地過程調用(LPC)、命名管道(NamedPipe)、TCP/IP網絡等。在本機系統(不跨網絡時)上最常見的是LPC與NamedPipe。客戶向伺服器發起RPC請求首先會先對接口進行綁定(binding),隨後才能發出請求(Request)調用指定的程序(Procedure)(通過指明ProcNum或API number)。現有的RPC攔截都是針對請求(Request)階段的，即只能獲得ProcNum和參數，並不能獲得⑶ID標識(這時僅能獲得由binding時的數字標識)，這樣就難以獲得完整的請求信息。現有技術中，針對RPC攔截(狀態跟蹤)僅僅知道ProcNum和參數，然後根據一些條件(如port名稱、棧回朔參數等內容)去猜測來判斷客戶端發送的是否為惡意的請求程序是不準確的。RPC採用客戶端/伺服器模式，實際上請求程序就是一個客戶端，而服務提供程序就是一個伺服器。首先，客戶端調用進程發送一個有進程參數的調用信息到服務進程，然後等待答覆信息。在伺服器端，服務進程保持睡眠狀態直到調用信息的到達為止。當一個調用信息到達，伺服器獲得進程參數，計算結果，發送答覆信息，然後等待下一個調用信息，最後，客戶端調用進程接收答覆信息，獲得進程結果，然後調用信息繼續進行。
所以當客戶端為一惡意的請求程序，調用伺服器完成惡意操作時，攔截程序(狀態跟蹤程序)在調用階段介入攔截，攔截獲得調用參數，但是現有技術中並不知道調用過程中所使用的調用指令的含義，所以也無從知曉這個調用指令是要執行什麼操作，也就不能判斷出操作是否為惡意。現在技術中，可以根據攔截程序在調用階段介入攔截到的一些其它信息，去猜測調用指令的含義，當調用指令僅涉及少量函數功能時，這種猜測是具備一定操作基礎的。但是往往一個調用指令中會涉及很多個功能，此時根據一個調用指令無法準備獲知客戶端具體要調用伺服器完成什麼操作。綜上所述，如何準確地獲取客戶端與伺服器之間進行RPC調用時，調用的接口和函數號的準確含義，從而就可以判定客戶端發送的是否為惡意的請求程序，這樣就能夠進行防禦操作，所以上述問題便成為亟待解決的技術問題。

發明內容
鑑於上述問題，提出了本發明以便提供一種克服上述問題或者至少部分地解決或者減緩上述問題的一種狀態跟蹤方法及系統。根據本發明的一個方面，提供了一種狀態跟蹤方法，用於遠程過程調用協議，其包括攔截客戶端進程與服務端進程之間相互綁定時交換的數據包，從所述數據包中獲取並保存兩個進程相互約定的調用規則；當監測到客戶端進程運用遠程過程調用協議，請求服務端進程提供服務的數據包時或響應另一進程的數據包時，解析該數據包並獲取該數據包裡面含有的調用指令；根據所述調用規則判斷該調用指令所完成的業務行為；其中，攔截客戶端進程與服務端進程之間相互綁定時交換的數據包，從所述數據包中獲取並保存兩個進程相互約定的調用規則，還包括攔截客戶端進程與服務端進程之間相互綁定時交換的請求和響應的數據包，從所述數據包中獲取並保存兩個進程相互約定的調用規則，其中所述調用規則包括接口及所配置的接口的代號的對應關係和/或，所述接口中包括的各應用程式編碼接口及所配置的接口標識的對應關係。進一步地，其中，根據所述調用規則判斷該調用指令所完成的業務行為，還包括根據所述調用規則判斷該調用指令所完成的業務行為，通過判斷所述業務行為是否為惡意來判定所述客戶端進程是否為惡意；如判定所述業務行為為正常，繼續監測下一請求或響應的數據包；如判定所述業務行為為惡意，則進而判定所述客戶端進程為惡意，攔截該數據包。進一步地，其中，當監測到客戶端進程運用遠程過程調用協議，請求服務端進程提供服務的數據包時或響應另一進程的數據包時，解析該數據包並獲取該數據包裡面含有的調用指令，還包括當監測到客戶端進程運用遠程過程調用協議，請求服務端進程提供服務的數據包時或響應另一進程的數據包時，解析該數據包並獲取該數據包裡面含有的調用指令；其中，所述數據包為本地過程調用的請求報文，所述調用指令攜帶接口的代號和/或接口標識。
進一步地，其中，根據所述調用規則判斷該調用指令所完成的業務行為，還包括根據所述調用規則，對該調用指令中攜帶的接口的代號和/或接口標識進行判斷，從而識別出所述客戶端所調用的接口和函數。進一步地，其中，所述數據包為採用本地過程調用、命名管道、UDP協議網絡消息或TCP/IP網絡消息的數據包。進一步地，其中，所述調用規則，包括所述調用指令與業務行為的對應關係；所述調用指令，包括伺服器根據客戶端的請求所配置的接口的代號、以及伺服器為接口中包含的應用程式編碼接口配置的接口標識；所述業務行為，包括客戶端請求的接口、以及客戶端請求的接口中包含的應用程式編碼接口。進一步地,其中，所述接口的代號為通過表達上下文欄位PresentationContext來表示；所述接口標識為通過函數號ProcNum來表示。根據本發明的一個方面，還提供了一種狀態跟蹤系統，用於遠程過程調用協議，其包括攔截模塊、監測模塊和判斷模塊；其中，所述攔截模塊，用於攔截客戶端進程與服務端進程之間相互綁定時交換的數據包，從所述數據包中獲取並保存兩個進程相互約定的調用規則；所述監測模塊，用於當監測到客戶端進程運用遠程過程調用協議，請求服務端進程提供服務的數據包時或響應另一進程的數據包時，解析該數據包並獲取該數據包裡面含有的調用指令；

判斷模塊，用於根據所述調用規則判斷該調用指令所完成的業務行為；其中，所述攔截模塊還用於攔截客戶端進程與服務端進程之間相互綁定時交換的請求和響應的數據包，從所述數據包中獲取並保存兩個進程相互約定的調用規則，其中所述調用規則包括接口及所配置的接口的代號的對應關係，和/或，所述接口中包括的各應用程式編碼接口及所配置的接口標識的對應關係。進一步地，其中，所述判斷模塊，還用於根據所述調用規則判斷該調用指令所完成的業務行為，通過判斷所述業務行為是否為惡意來判定所述客戶端進程是否為惡意；如判定所述業務行為為正常，繼續監測下一請求或響應的數據包；如判定所述業務行為為惡意，則進而判定所述客戶端進程為惡意，攔截該數據包。進一步地，其中，所述監測模塊，還用於當監測到客戶端進程運用遠程過程調用協議，請求服務端進程提供服務的數據包時或響應另一進程的數據包時，解析該數據包並獲取該數據包裡面含有的調用指令；其中，所述數據包為本地過程調用的請求報文，所述調用指令攜帶接口的代號和/或接口標識。進一步地，其中，所述判斷模塊，還用於根據所述調用規則，對該調用指令中攜帶的接口的代號和/或接口標識進行判斷，從而識別出所述客戶端所調用的接口和函數。進一步地，其中，所述數據包為採用本地過程調用、命名管道、UDP協議網絡消息或TCP/IP網絡消息的數據包。進一步地，其中，所述調用規則，包括所述調用指令與業務行為的對應關係；所述調用指令，包括伺服器根據客戶端的請求所配置的接口的代號、以及伺服器為接口中包含的應用程式編碼接口配置的接口標識；所述業務行為，包括客戶端請求的接口、以及客戶端請求的接口中包含的應用程式編碼接口。
進一步地,其中，所述接口的代號為通過表達上下文欄位PresentationContext來表示；所述接口標識為通過函數號ProcNum來表示。與現有的方案相比，本發明所獲得的技術效果I)完全準確地獲取客戶端與伺服器之間進行RPC調用時，調用的接口和函數號的準確含義，從而還可以判定是否為惡意程序；2)通過本發明能夠進行有效的防禦操作，從而避免惡意請求程序的攻擊，達到保護用戶個人電腦或計算機的目的。上述說明僅是本發明技術方案的概述，為了能夠更清楚了解本發明的技術手段，而可依照說明書的內容予以實施，並且為了讓本發明的上述和其它目的、特徵和優點能夠更明顯易懂，以下特舉本發明的具體實施方式
。


通過閱讀下文優選實施方式的詳細描述，各種其他的優點和益處對於本領域普通技術人員將變得清楚明了。附圖僅用於示出優選實施方式的目的，而並不認為是對本發明的限制。而且在整個附圖中，用相同的參考符號表示相同的部件。在附圖中圖1示意性示出了客戶端與伺服器在發生運用遠程過程調用協議調用之前預先進行綁定的過程流程
圖2示意性示出了根據本發明一個實施例所述狀態跟蹤方法流程圖；圖3是示意性示出了根據本發明另一個實施例所述狀態跟蹤方法流程圖；圖4示意性示出了根據本發明一個實施例所述狀態跟蹤系統結構框圖。
具體實施例方式下面結合附圖和具體的實施方式對本發明作進一步的描述。如圖1所示，在客戶端與伺服器之間發生RPC調用之前，會預先進行綁定(binding),其過程為步驟101，客戶端向伺服器發送綁定請求，告知伺服器自己要使用哪個Interface(接口);其中，每個Interface劃分出一類服務函數集合。所謂Interface是面向對象程式語言中接口操作的關鍵字，功能是把所需成員組合起來，以封裝一定功能的接口 ；步驟102,伺服器為Interface配置一個ID,並為這個Interface所包括的所有API (Application Programming Interface,應用程式編程接口)均配置一個標識 number ;其中，該Interface可能包含一個或多個的API，完成各種功能；這裡因為Interface可能是一個非常複雜而且冗長的名字，因此配置一個簡單的標識ID以方便之後的交互，而且標識ID也更為機器可讀，API number也是同理，即API (ApplicationProgramming Interface,應用程式編程接口)的編號；步驟103，伺服器向客戶端發送綁定請求的響應，告知客戶端所配置的Interface的標識ID以及API的編號(即API number)；步驟104，客戶端記錄Interface對應的標識ID以及API對應的編號(APInumber)；步驟105，客戶端向伺服器發送ID和API number，從而告知伺服器自己需要調用哪個接口的哪個函數；此時因為步驟102已經完成配置約定，所以客戶端僅向伺服器發送ID和APInumber 即可；步驟106，伺服器解析ID和API number，從而獲知客戶端需要調用地埠和函數，也即哪個接口的哪個函數。現有技術中RPC攔截都是針對步驟105之後的階段，僅僅能夠捕獲ProcNum，並沒有捕獲請求過程中對於RPC狀態追蹤有用的完整的請求信息，比如PresentationContext ；其中 ProcNum 即接口編號 API number 中的一種，PresentationContext是表徵一個接口的代號(句柄)，其他人拿到這個句柄並不知道其含義(即代表哪個接口)，所以只能去進行推測或者猜或是棧回朔進行猜。因此現有技術只能利用不完整的捕獲信息ProcNum，根據如port名稱、棧回朔參數等去猜測捕獲到的ProcNum的含義，狀態分析的準確性相對較低。而本發明首先確認了 PresentationContext參數對於解析所追蹤的狀態的重要意義，追蹤了上述的整個過程(主要是之前的綁定過程)，通過監控請求的通訊過程捕獲完整的請求信息，所以可以清楚的解釋這個句柄代表了哪個接口。這樣通過監控請求的通訊過程捕獲完整的請求信息從而完全掌握PresentationContext和ProcNum的含義,保證了狀態分析的準確性。

如圖2所示，本發明一個實施例所述的狀態跟蹤方法，其中，該方法包括步驟201，攔截客戶端進程與服務端進程之間相互綁定時交換的數據包，從所述數據包中獲取並保存兩個進程相互約定的調用規則；步驟202，當監測到客戶端進程運用遠程過程調用協議，請求服務端進程提供服務的數據包時或響應另一進程的數據包時，解析該數據包並獲取該數據包裡面含有的調用指令；步驟203，根據所述調用規則判斷該調用指令所完成的業務行為。如圖3所示，為了實現本發明所要解決的技術問題，同時通過判斷業務行為是否為惡意來判定所述客戶端進程是否為惡意，本發明另一個實施例所述的方法，包括步驟301，攔截客戶端進程與服務端進程之間相互綁定時交換的數據包，從所述數據包中獲取並保存兩個進程相互約定的調用規則；步驟302，當監測到客戶端進程運用遠程過程調用協議，請求服務端進程提供服務的數據包時或響應另一進程的數據包時，解析該數據包並獲取該數據包裡面含有的調用指令；步驟303，根據所述調用規則判斷該調用指令所完成的業務行為，通過判斷所述業務行為是否為惡意來判定所述客戶端進程是否為惡意；如判定所述業務行為為正常，繼續監測下一請求或響應的數據包；如判定所述業務行為為惡意，則進而判定所述客戶端進程為惡意，攔截該數據包。如下以一個基於LPC (本地過程調用)媒介(數據包)的RPC部分數據包格式(本地過程調用的請求報文LPC_REQUEST_MESSAGE)為例，在Vista系統中的一些系統數據包定義，說明採用上述實施例所述的狀態跟蹤方法中「根據所述調用規則判斷該調用指令所完成的業務行為」這個操作過程，請注意看裡面的開頭都是LPC_PACKET_HEADER，而這個結構的開頭又是一個標準的PORT_MESSAGE (LPC消息包頭)。

權利要求
1.一種狀態跟蹤方法，用於遠程過程調用協議，包括 攔截客戶端進程與服務端進程之間相互綁定時交換的數據包，從所述數據包中獲取並保存兩個進程相互約定的調用規則； 當監測到客戶端進程運用遠程過程調用協議，請求服務端進程提供服務的數據包時或響應另一進程的數據包時，解析該數據包並獲取該數據包裡面含有的調用指令； 根據所述調用規則判斷該調用指令所完成的業務行為； 其中，攔截客戶端進程與服務端進程之間相互綁定時交換的數據包，從所述數據包中獲取並保存兩個進程相互約定的調用規則，還包括 攔截客戶端進程與服務端進程之間相互綁定時交換的請求和響應的數據包，從所述數據包中獲取並保存兩個進程相互約定的調用規則，其中所述調用規則包括接口及所配置的接口的代號的對應關係，和/或，所述接口中包括的各應用程式編碼接口及所配置的接口標識的對應關係。
2.如權利要求1所述的狀態跟蹤方法，其特徵在於，根據所述調用規則判斷該調用指令所完成的業務行為，還包括 根據所述調用規則判斷該調用指令所完成的業務行為，通過判斷所述業務行為是否為惡意來判定所述客戶端進程是否為惡意； 如判定所述業務行為為正常，繼續監測下一請求或響應的數據包；如判定所述業務行為為惡意，則進而判定所述客戶端進程為惡意，攔截該數據包。
3.如權利要求1或2所述的狀態跟蹤方法，其特徵在於，當監測到客戶端進程運用遠程過程調用協議，請求服務端進程提供服務的數據包時或響應另一進程的數據包時，解析該數據包並獲取該數據包裡面含有的調用指令，還包括 當監測到客戶端進程運用遠程過程調用協議，請求服務端進程提供服務的數據包時或響應另一進程的數據包時，解析該數據包並獲取該數據包裡面含有的調用指令；其中，所述數據包為本地過程調用的請求報文，所述調用指令攜帶接口的代號和/或接口標識。
4.如權利要求3所述的狀態跟蹤方法，其特徵在於，根據所述調用規則判斷該調用指令所完成的業務行為，還包括 根據所述調用規則，對該調用指令中攜帶的接口的代號和/或接口標識進行判斷，從而識別出所述客戶端所調用的接口和函數。
5.如權利要求1至2中任一所述的狀態跟蹤方法，其特徵在於，所述數據包為採用本地過程調用、命名管道、UDP協議網絡消息或TCP/IP網絡消息的數據包。
6.如權利要求1所述的狀態跟蹤方法，其中， 所述調用規則，包括所述調用指令與業務行為的對應關係； 所述調用指令，包括伺服器根據客戶端的請求所配置的接口的代號、以及伺服器為接口中包含的應用程式編碼接口配置的接口標識； 所述業務行為，包括客戶端請求的接口、以及客戶端請求的接口中包含的應用程式編碼接口。
7.如權利要求1或2或6所述的狀態跟蹤方法，其中， 所述接口的代號為表達上下文欄位PresentationContext ； 所述接口標識為函數號ProcNum。
8.一種狀態跟蹤系統，用於遠程過程調用協議，包括攔截模塊、監測模塊和判斷模塊;其中， 所述攔截模塊，用於攔截客戶端進程與服務端進程之間相互綁定時交換的數據包，從所述數據包中獲取並保存兩個進程相互約定的調用規則； 所述監測模塊，用於當監測到客戶端進程運用遠程過程調用協議，請求服務端進程提供服務的數據包時或響應另一進程的數據包時，解析該數據包並獲取該數據包裡面含有的調用指令； 判斷模塊，用於根據所述調用規則判斷該調用指令所完成的業務行為； 其中，所述攔截模塊還用於 攔截客戶端進程與服務端進程之間相互綁定時交換的請求和響應的數據包，從所述數據包中獲取並保存兩個進程相互約定的調用規則，其中所述調用規則包括接口及所配置的接口的代號的對應關係，和/或，所述接口中包括的各應用程式編碼接口及所配置的接口標識的對應關係。
9.如權利要求8所述的狀態跟蹤系統，其特徵在於， 所述判斷模塊，還用於根據所述調用規則判斷該調用指令所完成的業務行為，通過判斷所述業務行為是否為惡意來判定所述客戶端進程是否為惡意； 如判定所述業務行為為正常，繼續監測下一請求或響應的數據包；如判定所述業務行為為惡意，則進而判定所述客戶端進程為惡意，攔截該數據包。
10.如權利要求8或9所述的狀態跟蹤系統，其特徵在於，所述監測模塊，還用於 當監測到客戶端進程運用遠程過程調用協議，請求服務端進程提供服務的數據包時或響應另一進程的數據包時，解析該數據包並獲取該數據包裡面含有的調用指令；其中，所述數據包為本地過程調用的請求報文，所述調用指令攜帶接口的代號和/或接口標識。
11.如權利要求10所述的狀態跟蹤系統，其特徵在於，所述判斷模塊，還用於 根據所述調用規則，對該調用指令中攜帶的接口的代號和/或接口標識進行判斷，從而識別出所述客戶端所調用的接口和函數。
12.如權利要求8至9中任一所述的狀態跟蹤系統，其特徵在於，所述數據包為採用本地過程調用、命名管道、UDP協議網絡消息或TCP/IP網絡消息的數據包。
13.如權利要求8所述的狀態跟蹤系統，其特徵在於， 所述調用規則，包括所述調用指令與業務行為的對應關係； 所述調用指令，包括伺服器根據客戶端的請求所配置的接口的代號、以及伺服器為接口中包含的應用程式編碼接口配置的接口標識； 所述業務行為，包括客戶端請求的接口、以及客戶端請求的接口中包含的應用程式編碼接口。
14.如權利要求8或9或13所述的狀態跟蹤系統，其特徵在於， 所述接口的代號為表達上下文欄位PresentationContext ； 所述接口標識為函數號ProcNum。
全文摘要
本發明公開了狀態跟蹤方法及系統，其中，該系統包括攔截模塊、監測模塊和判斷模塊；其中，所述攔截模塊還用於攔截客戶端進程與服務端進程之間相互綁定時交換的請求和響應的數據包，從所述數據包中獲取並保存兩個進程相互約定的調用規則，其中所述調用規則包括接口及所配置的接口的代號的對應關係，和/或，所述接口中包括的各應用程式編碼接口及所配置的接口標識的對應關係。本發明解決了在現有客戶端與伺服器之間進行RPC調用時，獲取調用的接口和函數號的準確含義。
文檔編號H04L29/06GK103036895SQ20121055998
公開日2013年4月10日 申請日期2012年12月20日 優先權日2012年12月20日
發明者潘劍鋒, 王宇 申請人:北京奇虎科技有限公司, 奇智軟體(北京)有限公司