本公開涉及移動終端技術領域，尤其涉及一種用于檢測惡意代碼的方法和裝置。

背景技術：

隨著移動終端技術的發(fā)展，越來越多的用戶選擇使用移動終端下載的各種應用程序來完成日常生活乃至工作相關的各種事項，例如繳費、購物、安排日程計劃等等。相應地，也有越來越多的商家選擇提供應用程序來為用戶提供各種各樣的服務，例如新聞、社交、外賣等等。在使用例如Android(安卓)等開放式操作系統(tǒng)的終端上，應用程序可能被惡意代碼侵入而產生不良影響。例如，有些用戶為了實現(xiàn)搶票、刷單等目的，會故意下載安裝第三方非法提供的外掛程序(例如基于xposed架構)，這些外掛程序會與應用一起運行，模擬用戶操作與應用程序的后臺服務器通信，從而對服務器產生不必要的負擔。

外掛程序可能是為了幫助用戶進行注冊、登錄等自助操作(例如搶票)，或者可能是為了引入不必要的廣告，但也有可能會在后臺抓取用戶移動終端上的隱私數(shù)據(jù)，對用戶造成重大的安全隱患。另一方面，部分用戶故意使用帶有外掛的應用程序進行搶票、刷單等惡意操作，也會給應用程序的原始提供方帶來不可預估的損失。

為此，目前市場上已開發(fā)出一些能夠進行惡意代碼/外掛程序的檢測等常規(guī)安全操作的防護軟件。然而，由于應用程序的數(shù)目繁多，相應的外掛程序種類也十分龐雜，惡意代碼的侵入原理也層出不窮，造成防護軟件即使頻繁更新也無法徹底杜絕外掛程序的侵入。如何從根源上精確地消除外掛程序的危害便成為業(yè)內急需解決的問題。

技術實現(xiàn)要素：

本公開的目的是提供一種用于檢測惡意代碼的方法和裝置，以解決現(xiàn)有技術中存在的上述問題。

根據(jù)本公開的一個方面，提供一種用于檢測惡意代碼的方法，應用于終端上運行的客戶端程序中，該方法包括：響應于所述客戶端程序接收的操作請求執(zhí)行選自以下群組中的一個或多個步驟來確定是否存在惡意代碼：檢測啟動所述終端的操作系統(tǒng)的系統(tǒng)應用文件是否合法；檢測所述操作系統(tǒng)提供的安裝包管理器中是否存在非法的程序包名；檢測所述操作系統(tǒng)的進程空間內加載的文件中是否存在預設黑名單中的文件名；以及遍歷所述終端上當前所運行進程中的關鍵應用程序接口API，檢測所述關鍵API的方法類型標識是否合法。

根據(jù)本公開的另一個方面，提供一種用于檢測惡意代碼的裝置，應用于終端上運行的客戶端程序中，該裝置包括：操作請求響應模塊，設置為響應于所述客戶端程序接收的操作請求觸發(fā)選自以下群組中的一個或多個模塊來確定是否存在惡意代碼：系統(tǒng)文件檢測模塊，設置為檢測啟動所述終端的操作系統(tǒng)的系統(tǒng)應用文件是否合法；安裝包檢測模塊，設置為檢測所述操作系統(tǒng)提供的安裝包管理器中是否存在非法的程序包名；進程檢測模塊，設置為檢測所述操作系統(tǒng)的進程空間內加載的文件中是否存在預設黑名單中的文件名；以及標識檢測模塊，設置為遍歷所述終端上當前所運行進程中的關鍵應用程序接口API并檢測所述關鍵API的方法類型標識是否合法。

根據(jù)本公開用于檢測惡意代碼的方法和裝置，通過響應于操作請求來觸發(fā)不同的檢測手段，可以實現(xiàn)針對特定類型外掛程序的精確判斷。

附圖說明

圖1為根據(jù)本公開一實施例的用于檢測惡意代碼的方法流程圖；

圖2為根據(jù)本公開另一實施例的用于檢測惡意代碼的方法流程圖；

圖3為根據(jù)本公開另一實施例的用于檢測惡意代碼的方法流程圖；

圖4為本公開用于檢測惡意代碼的方法中系統(tǒng)文件檢測步驟的實施例流程圖；

圖5為本公開用于檢測惡意代碼的方法中安裝包檢測步驟的實施例流程圖；

圖6為本公開用于檢測惡意代碼的方法中進程檢測步驟的實施例流程圖；

圖7為本公開用于檢測惡意代碼的方法中標識檢測步驟的實施例流程圖；

圖8為根據(jù)本公開又一實施例的用于檢測惡意代碼的方法流程圖；

圖9為根據(jù)本公開一實施例的用于檢測惡意代碼的裝置示意圖；

圖10為根據(jù)本公開另一實施例的用于檢測惡意代碼的裝置示意圖。

具體實施方式

下面將詳細描述本公開的具體實施例。應當注意，這里描述的實施例只用于舉例說明，并不用于限制本公開。

以下實施例用于說明本公開，但不用來限制本公開的范圍。

在本公開說明書中，惡意代碼是指應用程序初始提供方之外的一切第三方未經授權添加的與應用程序綁定運行的代碼，而不論該部分代碼的添加目的如何。另一方面，外掛程序是指惡意代碼隨原始應用程序一起或單獨運行時的表現(xiàn)形式，以下說明中除非特別說明否則外掛程序和惡意代碼可互換使用。

如上文所述，現(xiàn)有技術中針對種類層出不窮的外掛程序無法實現(xiàn)有針對性的準確檢測，也無法滿足不同層次的檢測需求。為此，本公開提供一種用于檢測惡意代碼的方法。圖1為根據(jù)本公開一實施例的用于檢測惡意代碼的方法流程圖，其可應用于終端上運行的客戶端程序中。在一個實施例中，本公開的方法可以SDK(Software Development Kit，軟件開發(fā)工具包)或源代碼的形式集成到現(xiàn)有客戶端程序的代碼中，從而達到在根源上消除外掛程序的目的。如圖1所示，本實施例的方法包括以下步驟S101-S105。

在步驟S101中，響應于客戶端程序接收的操作請求執(zhí)行選自以下S102-S105中的一個或多個步驟來確定是否存在惡意代碼。

客戶端程序在收到用戶發(fā)起的操作請求時，可根據(jù)系統(tǒng)默認設置或用戶定制設置來選擇執(zhí)行以下S102-S105中的一個或多個步驟來確定是否存在惡意代碼。如圖1所述，步驟S101后的步驟S102-S105之間用無箭頭的線條連接，以此來表示這些步驟之間是任意選擇且無特定順序的要求。

在步驟S102中，檢測啟動終端的操作系統(tǒng)的系統(tǒng)應用文件是否合法。

許多外掛程序會對用于啟動終端操作系統(tǒng)的系統(tǒng)應用文件進行替換，以達到例如隨系統(tǒng)一同啟動的目的。因此，在本步驟中，可以通過判斷該系統(tǒng)應用文件(可能為多個)是否合法來確定是否存在惡意代碼侵入。本步驟的詳細流程可進一步參見圖4所示實施例。

在步驟S103中，檢測操作系統(tǒng)提供的安裝包管理器中是否存在非法的程序包名。

本步驟中可以通過判斷終端操作系統(tǒng)中是否存在非法的程序包名來確定是否存在惡意代碼侵入，詳細流程可進一步參見圖5所示實施例。

在步驟S104中，檢測操作系統(tǒng)的進程空間內加載的文件中是否存在預設黑名單中的文件名。

對于某段時間內傳播量較大的外掛程序，可針對這些外掛程序的后門文件整理出預設的黑名單，并通過檢測操作系統(tǒng)的進程空間內是否加載了該黑名單中的文件來確定是否存在惡意代碼侵入。本步驟的詳細流程可進一步參見圖6所示實施例。

在步驟S105中，遍歷終端上當前所運行進程中的關鍵API(Application Program Interface應用程序接口)，檢測關鍵API的方法類型標識是否合法。

在一個實施例中，檢測的目標API均設置有方法類型標識。該方法類型標識對應的標志位在正常情況下均呈現(xiàn)為默認設置，例如設置為指示java方法，而外掛程序出于攔截并修改系統(tǒng)API返回值的需要會修改目標API的方法類型標識。因此，在本步驟中可以通過檢測關鍵API的方法類型標識是否合法來確定是否存在惡意代碼，詳細流程可進一步參見圖7所示實施例。

根據(jù)上述本公開用于檢測惡意代碼的方法實施例，通過響應于操作請求來觸發(fā)不同的檢測手段，可以實現(xiàn)針對不同的操作請求設置靈活的檢測策略；通過遍歷當前進程中關鍵API的合法性來確定是否存在惡意代碼侵入，可以實現(xiàn)針對特定類型外掛程序的精確判斷。

圖2為根據(jù)本公開另一實施例的用于檢測惡意代碼的方法流程圖，其可應用于終端上運行的客戶端程序中。如圖2所示，本實施例的方法包括以下步驟S201-S203。

在步驟S201中，響應于客戶端程序接收的操作請求判斷操作請求的安全級別。

根據(jù)客戶端程序的種類不同，可針對各種操作請求設置不同的安全級別。以支付類程序為例，出于對用戶及其終端安全性的考慮，例如可將用戶通過客戶端發(fā)起的登錄、支付和修改個人資料等操作請求設置為較高的安全級別，而將瀏覽、查詢等其他操作請求設置為較低的安全級別。又以提供外賣服務的平臺類程序為例，出于防止第三方惡意刷單的考慮，在需要嚴格禁止刷單(即不考慮檢測的準確性)時可將注冊、登錄等所有操作均設置為較高的安全級別，而在需要精確禁止刷單(即要優(yōu)先考慮檢測的準確性)時可將所有操作均設置為較低的安全級別。

客戶端程序在收到用戶發(fā)起的操作請求時，首先根據(jù)接收的操作請求種類并基于預設的安全策略來判斷當前操作請求對應的安全級別。

在步驟S202中，當判斷操作請求的安全級別為較低時，遍歷終端上當前所運行進程中的關鍵應用程序接口。

當步驟S201的判斷結果指示當前操作請求的安全級別較低時，說明此時無需輕易觸發(fā)檢測到惡意代碼的警告。換言之，此時可優(yōu)先考慮惡意代碼檢測的準確性，而無需考慮檢測所花費的時間。在本實施例中，針對較低的安全級別所設置的準確性較高的檢測手段通過遍歷當前終端上所運行進程中的關鍵API來完成，具體檢測流程可參見步驟S203和圖7實施例所述。在一個實施例中，這里的關鍵API可根據(jù)當前應用所涉及的具體業(yè)務來指定。例如，在當前應用程序所涉及的業(yè)務需要采集用戶安裝應用的情況下，可將“PackageManager.getInstalledPackages()”預設為關鍵API。

在步驟S203中，檢測關鍵API的方法類型標識是否合法以確定是否存在惡意代碼。

在一個實施例中，所有檢測的目標API均設置有方法類型標識。該方法類型標識對應的標志位在正常情況下均呈現(xiàn)為默認設置，例如設置為指示java方法，而外掛程序出于攔截并修改系統(tǒng)API返回值的需要會修改目標API的方法類型標識。因此，在本步驟中可以通過檢測關鍵API的方法類型標識是否合法來確定是否存在惡意代碼。具體而言，如果檢測到所有關鍵API的方法類型標識均呈現(xiàn)為默認設置，則判斷這些方法類型標識合法，從而確定不存在惡意代碼，即當前客戶端程序未被外掛程序侵入。反之，如果檢測到任意關鍵API的方法類型標識經過了修改，則判斷該方法類型標識不合法，從而確定存在惡意代碼，即當前客戶端程序已被外掛程序侵入。

上述實施例用于檢測惡意代碼的方法，在判斷出當前操作請求的安全級別較低時，通過采用檢測關鍵API的方法類型標識來確定是否存在惡意代碼，可以消除誤判的可能性，能夠實現(xiàn)對外掛程序的精確檢測。

圖3為根據(jù)本公開另一實施例的用于檢測惡意代碼的方法流程圖，其可應用于終端上運行的客戶端程序中。如圖3所示，本實施例的方法包括以下步驟S301-S308。

在步驟S301中，響應于客戶端程序接收的操作請求判斷操作請求的安全級別。

在步驟S302中，當判斷操作請求的安全級別為較低時，遍歷終端上當前所運行進程中的關鍵API。

在步驟S303中，檢測關鍵API的方法類型標識是否合法以確定是否存在惡意代碼。

上述步驟S301-S303分別對應于前述實施例的步驟S201-S203，此處不再贅述。

在步驟S304中，當判斷所述操作請求的安全級別為較高時，執(zhí)行步驟S303和S305-S307中的一個或多個步驟來確定是否存在惡意代碼。

當步驟S301的判斷結果指示當前操作請求的安全級別較高時，說明此時應將觸發(fā)惡意代碼警告的條件降低。換言之，此時可將惡意代碼檢測花費時間的考慮優(yōu)先級設置為大于檢測的準確性，也即，越快檢測出可能存在惡意代碼的結果越好。在本實施例中，針對較高的安全級別提供了步驟S305-S307和步驟S303共四種檢測手段，具體的檢測流程可參見步驟S305-S307和圖4-圖6實施例以及步驟S203和圖7實施例所述。需要說明的是，具體應用中可根據(jù)客戶端程序的特點從上述四種檢測手段中選擇其中的任意一種或多種來完成是否存在惡意代碼的判斷。例如，當選擇步驟S303來進行檢測時，說明此時針對不同的安全級別都使用準確性較高的方法類型標識來完成判斷。又例如，當同時選擇步驟S305-S307和步驟S303這四種檢測手段來完成是否存在惡意代碼的判斷時，可按一定的順序來進行檢測(具體例如可參見圖8所示實施例)，這時可兼顧考慮到惡意代碼檢測的時間開銷和準確性。在圖3中，步驟S304后的步驟S305-S307和步驟S303之間用無箭頭的線條連接，以此來表示這些步驟之間是任意選擇且無特定順序的要求。

在步驟S305中，檢測啟動終端的操作系統(tǒng)的系統(tǒng)應用文件是否合法。

許多外掛程序會對用于啟動終端操作系統(tǒng)的系統(tǒng)應用文件進行替換，以達到例如隨系統(tǒng)一同啟動的目的。因此，在本步驟中，可以通過判斷該系統(tǒng)應用文件(可能為多個)是否合法來確定是否存在惡意代碼侵入。在一個實施例中，系統(tǒng)應用文件是否合法的判斷具體可通過將當前文件的特征碼(如MD5碼)與已知合法版本的文件特征碼進行比對來進行，若發(fā)現(xiàn)二者不一致則說明該系統(tǒng)應用文件可能已被替換，從而確定存在惡意代碼侵入。本步驟的詳細流程可進一步參見圖4所示實施例。

在步驟S306中，檢測操作系統(tǒng)提供的安裝包管理器中是否存在非法的程序包名。

一些外掛程序不僅以惡意代碼的形式嵌入在應用程序中，而且還可能會隨著該應用程序首次啟動而以單獨程序或插件的形式安裝在終端的操作系統(tǒng)中。對此，在本步驟中可以通過判斷終端操作系統(tǒng)中是否存在非法的程序包名來確定是否存在惡意代碼侵入。在一個實施例中，非法程序包名的判斷具體可通過操作系統(tǒng)提供的安裝包管理器來進行，將安裝包管理器中的所有已安裝程序包名逐一與已知的非法程序包名進行比對，若發(fā)現(xiàn)非法的已安裝程序包則確定存在惡意代碼侵入。本步驟的詳細流程可進一步參見圖5所示實施例。

在步驟S307中，檢測操作系統(tǒng)的進程空間內加載的文件中是否存在預設黑名單中的文件名。

對于以相似侵入原理或框架工作的同一類外掛程序，通常會在終端的操作系統(tǒng)中植入相同的關鍵文件。由于這類文件通常以進程的方式隨操作系統(tǒng)長期運行，并為外掛程序的植入方進一步侵入終端操作系統(tǒng)(例如進行數(shù)據(jù)竊取)提供入口，因此通常被稱為后門文件。對于某段時間內傳播量較大的外掛程序，可針對這些外掛程序的后門文件整理出預設的黑名單，并通過檢測操作系統(tǒng)的進程空間內是否加載了該黑名單中的文件來確定是否存在惡意代碼侵入。若檢測發(fā)現(xiàn)操作系統(tǒng)的進程文件內加載的文件中存在黑名單中的文件名，則確定存在惡意代碼侵入。本步驟的詳細流程可進一步參見圖6所示實施例。

綜上所述，雖然描述步驟S303和S305-S307，但利用這些步驟來確定是否存在惡意代碼侵入并不存在順序的限制，而且可以并行處理。在一個實施例中，各步驟的判斷結果均輸出為布爾值，最終通過預設的規(guī)則來確定綜合的判斷結果。

在步驟S308中，將確定是否存在惡意代碼的結果附在操作請求中，以使終端的操作系統(tǒng)根據(jù)該結果返回對操作請求的響應。

在經過前述步驟得出是否存在惡意代碼的判斷結果后，可進一步將該判斷結果附在步驟S301中述及的操作請求中，從而使終端的操作系統(tǒng)根據(jù)該結果返回對操作請求的響應。在另一個實施例中，返回響應的操作可由應用運行時所連接的后臺服務器來進行。例如，在確定存在惡意代碼侵入時，返回拒絕該操作請求的提示，并警示用戶切換至更安全的系統(tǒng)環(huán)境(例如切換網絡、運行安全防護軟件等等)繼續(xù)操作。

圖4為本公開用于檢測惡意代碼的方法中系統(tǒng)文件檢測步驟的實施例流程圖。如前述步驟S305所述，本步驟的原理在于通過判斷用于啟動終端操作系統(tǒng)的系統(tǒng)應用文件是否被修改來確定是否存在惡意代碼侵入。在終端操作系統(tǒng)是基于安卓(Android)系統(tǒng)的情況下，本實施例具體可包括以下步驟S401-S404。

在步驟S401中，在操作系統(tǒng)的系統(tǒng)文件夾中定位app_process文件。

app_process文件作為啟動android process(安卓應用進程)的系統(tǒng)應用文件，也是例如基于xposed的外掛程序的替換對象。因此，在本實施例中，以操作系統(tǒng)/system/bin目錄下的app_process文件作為檢測對象來判斷惡意代碼的侵入。

在步驟S402中，提取app_process文件的特征碼。

在步驟S403中，將提取的特征碼與已知的合法特征碼進行對比校驗。

在步驟S404中，在提取的特征碼與合法特征碼一致時確定不存在惡意代碼，不一致時確定存在惡意代碼。

由步驟S402-S404可見，本實施例中使用app_process文件的特征碼來判斷其是否發(fā)生了變動。在一個實施例中，特征碼可通過md5或shal校驗運算來得到。具體而言，步驟S402中可對當前/system/bin目錄下定位到的app_process文件進行md5或shal校驗來得到其特征碼；步驟S403中則將提取的特征碼與預存的已知特征碼進行對比校驗，如果二者一致則判斷當前的app_process文件是未經過修改的原始文件，反之，如果二者不一致則判斷當前的app_process文件已被替換，從而確定存在惡意代碼侵入。在一個實施例中，合法特征碼可在當前應用運行的任意時刻通過對系統(tǒng)的app_process文件進行md5或shal校驗運算來得到。

圖5為本公開用于檢測惡意代碼的方法中安裝包檢測步驟的實施例流程圖。如前述步驟S306所述，本步驟的原理在于通過判斷終端操作系統(tǒng)中是否存在非法的程序包名來確定是否存在惡意代碼侵入。在終端操作系統(tǒng)是基于Android系統(tǒng)的情況下，本實施例具體可包括以下步驟S501-S503。

在步驟S401中，調用操作系統(tǒng)提供的與安裝包管理器PackageManager相關的API來遍歷已安裝程序包。

Android操作系統(tǒng)通常會預裝默認的安裝包管理器PackageManager，以方便用戶對當前終端上所有的已安裝程序包進行管理。同時，Android操作系統(tǒng)還會開放一部分與PackageManager有關的API，以方便第三方程序通過調用該部分API來輔助用戶對已安裝程序包的高級管理(例如進行分類、使用頻率排序、卸載清理等操作)。相應地，為了排除存在安全隱患的安裝程序包，本步驟首先通過調用與PackageManager有關的API來遍歷當前終端上安裝的所有程序包名。

在步驟S502中，將已安裝程序包逐一與已知的非法程序包名進行比對。

在步驟S503中，在已安裝程序包中未發(fā)現(xiàn)與非法程序包名匹配的程序包時確定不存在惡意代碼，發(fā)現(xiàn)與非法程序包名匹配的程序包時確定存在惡意代碼。

程序包名是對于應用程序唯一的字符串，因此本實施例中可基于已安裝程序包的包名來確定是否存在非法的已安裝程序包。在一個實施例中，非法程序包名可基于已知的外掛程序來分析收集并存在于客戶端程序的源代碼中。另外，在一個實施例中，由于一些外掛程序會以“未知(Unknown)”作為程序包名呈現(xiàn)在PackageManager中，因此可將“未知(Unknown)”添加在上述預存的非法程序包名中。步驟S502將當前的安裝程序包逐一與預存的非法程序包名進行比對，如果發(fā)現(xiàn)與非法程序包名匹配的程序包時則確定存在惡意代碼，反之，如果未發(fā)現(xiàn)與非法程序包名匹配的程序包時則確定不存在惡意代碼。

圖6為本公開用于檢測惡意代碼的方法中進程檢測步驟的實施例流程圖。如前述步驟S307所述，本步驟的原理在于通過判斷操作系統(tǒng)的進程空間內是否加載了預設黑名單中的文件來確定是否存在惡意代碼侵入。在終端操作系統(tǒng)是基于Android系統(tǒng)的情況下，本實施例具體可包括以下步驟S601-S603。

在步驟S601中，遍歷進程空間內加載的文件。

Android操作系統(tǒng)提供了相關接口，使得第三方應用程序(例如此處的客戶端程序)能夠通過該接口來訪問系統(tǒng)的進程空間，從而遍歷進程空間內加載的所有文件。

在步驟S602中，將加載的文件逐一與預設黑名單中的特征文件進行比對。

在步驟S603中，在加載的文件中未發(fā)現(xiàn)與特征文件匹配的文件時確定不存在惡意代碼，發(fā)現(xiàn)與特征文件匹配的文件時確定存在惡意代碼。

如前所述，外掛程序區(qū)別于客戶端程序獨立運行，因此在進程空間中可能表現(xiàn)加載了若干個文件，而某一類外掛程序加載的文件都相同。以基于xposed的外掛程序為例，會加載xposedbridge.jar等特征文件。如此一來，便可通過判斷操作系統(tǒng)的進程空間中是否加載了某些文件來確定是否存在惡意代碼入侵。與程序包名類似，這些文件也可以黑名單的形式基于已知的外掛程序來分析收集并存在于客戶端程序的源代碼中。步驟S602將當前進程空間中加載的文件逐一與預設黑名單中的特征文件進行比對，如果發(fā)現(xiàn)與特征文件名匹配的加載文件時則確定存在惡意代碼，反之，如果未發(fā)現(xiàn)與特征文件名匹配的加載文件時則確定不存在惡意代碼。由于同屬于文件名的比對，在一個實施例中，步驟S602中也可與圖4所示實施例類似通過md5、shal等校驗計算并比對文件名的特征碼來實現(xiàn)加載文件與特征文件的比對。在一個實施例中，可進行文件名的整體校驗，也可進行文件名局部的關鍵字校驗。

圖7為本公開用于檢測惡意代碼的方法中標識檢測步驟的實施例流程圖。如前述步驟S203所述，本步驟的原理在于通過判斷關鍵API是否被修改來確定是否存在惡意代碼侵入。在終端操作系統(tǒng)是基于Android系統(tǒng)的情況下，本實施例具體可包括以下步驟S701-S703。

在步驟S701中，檢測關鍵API的方法類型標識；

在步驟S702中，在檢測到方法類型標識指示為java方法時，確定不存在惡意代碼；以及

在步驟S703中，在檢測到方法類型標識被修改為native類型時，確定存在惡意代碼。

由上述步驟可見，本實施例中需要檢測目標API方法的c struct(c結構)。這里，c struct是指當前方法在虛擬機運行時的數(shù)據(jù)結構映射。一般而言，Method(方法)結構體中對應的方法類型標識在正常情況下應標記為java方法，而例如基于xposed等架構的外掛程序會將該方法類型標識修改為native類型。這里，Method結構體是指Java方法在虛擬機運行時對應的數(shù)據(jù)結構。因此，步驟S603中如果檢測到關鍵API的方法類型標識已被修改為native類型，則認為該方法已被侵入并攔截，通過該方法讀取的內容不再可靠。

現(xiàn)有的惡意代碼檢查方式主要通過收集設備系統(tǒng)參數(shù)并與正常系統(tǒng)參數(shù)和自定義規(guī)則進行匹配，來判斷用戶系統(tǒng)參數(shù)是否已被外部程序篡改，而保證采集數(shù)據(jù)有效性的措施更多是通過增加字段和代碼混淆來實現(xiàn)。相應地，目前業(yè)內仍集中于通過增加采集系統(tǒng)參數(shù)和增加加密手段的方式來保護采集的數(shù)據(jù)用于校驗合法用戶。然而，這種收集并匹配設備系統(tǒng)參數(shù)的方式一旦被成功反編譯而使采集數(shù)據(jù)暴露，外掛程序的設計者便能夠通過采用規(guī)避數(shù)據(jù)的方式來阻止成功匹配，由此使得整個檢查方式失效。相比之下，采用上述圖4-圖7所示的實施例來進行惡意代碼的檢測，數(shù)據(jù)結構采集結果可與檢測結果同步上傳，由后臺服務器根據(jù)檢測結果來分析用戶采集數(shù)據(jù)所用的API是否被篡改，如果被篡改則認為數(shù)據(jù)是不安全的，因此，即使在當前全部采集數(shù)據(jù)已經暴露的情況下，仍舊能夠有效保證所采集數(shù)據(jù)的正確性。

另一方面，xposed作為目前Android操作系統(tǒng)上唯一一種開源且不必修改原應用程序的外掛程序侵入框架，已經有多種外掛程序構建于xposed之上。對于xposed架構的外掛程序，上述收集并匹配設備系統(tǒng)參數(shù)的傳統(tǒng)方式極難檢測，造成Android操作系統(tǒng)上的各種刷單、刷量等非法手段在此基礎上大量應用，通過模擬新用戶和新設備來獲取利益，使各大移動互聯(lián)網公司深受其害，給移動互聯(lián)網應用開發(fā)者也帶來大量損失。相比之下，采用上述圖4-圖7所示的實施例來進行惡意代碼的檢測，針對基于xposed架構的外掛程序能夠實施有效的檢測。

除此之外，現(xiàn)有的各種反外掛及安全程序往往由于晚于系統(tǒng)進程啟動，造成自身也被侵入而失去檢測能力，而應用程序自身并無root權限，通常手段也無法有效檢測，容易被外掛程序偽造的數(shù)據(jù)所蒙蔽。相比之下，采用上述圖4-圖7所示的實施例來進行惡意代碼的檢測，能夠在無需獲取root權限的情況下，通過對app_proccess文件、自身進程空間和app應用環(huán)境進行掃描來確定是否存在惡意代碼侵入。

圖8為根據(jù)本公開又一實施例的用于檢測惡意代碼的方法流程圖，如圖所示，本實施例的方法包括以下步驟S801-S807。

在步驟S801中，響應于客戶端程序接收的操作請求判斷該操作請求的安全級別。

本步驟可參見前述步驟S201的說明，此處不再贅述。

在步驟S802中，當判斷操作請求的安全級別為較高時，轉入步驟S803；當判斷操作請求的安全級別為較低時，轉入步驟S806。

本步驟可參見前述步驟S202和S302的說明，此處不再贅述。

在步驟S803中，檢測啟動終端操作系統(tǒng)的系統(tǒng)應用文件是否合法，如果合法則轉入步驟S804，不合法則確定存在惡意代碼侵入。

在步驟S804中，檢測操作系統(tǒng)提供的安裝包管理器中是否存在非法的程序包名，如果不存在則轉入步驟S805，存在則確定存在惡意代碼侵入。

在步驟S805中，檢測操作系統(tǒng)的進程空間內加載的文件中是否存在預設黑名單中的文件名，如果不存在則轉入步驟S806，存在則確定存在惡意代碼侵入。

在步驟S806中，遍歷終端上當前所運行進程中的關鍵API，檢測該關鍵API的方法類型標識是否合法，如果合法則確定當前終端系統(tǒng)安全，不合法則確定存在惡意代碼侵入。

步驟S803-S806可分別參見前述圖4-圖7所示實施例的說明，此處不再贅述。

在步驟S807中，將確定是否存在惡意代碼的結果附在操作請求中，以使終端的操作系統(tǒng)根據(jù)該結果返回對該操作請求的響應。

由以上步驟S801-S807可見，本實施例中在操作請求的安全級別較低時，直接采用方法類型標識的檢測手段來確定是否存在惡意代碼侵入，此時優(yōu)先考慮了惡意代碼檢測的準確性；在操作請求的安全級別較高時，則順序執(zhí)行系統(tǒng)應用文件(例如app_process文件)、已安裝程序包名、進程空間加載文件和方法類型標識這四種檢測手段，其中任一檢測手段確定存在惡意代碼則返回確定存在惡意代碼的結果，而只有通過四種檢測手段都確定不存在惡意代碼才確定系統(tǒng)安全，這四種檢測手段可簡單理解為是按照檢測速度由高到低、檢測精度由低到高排序，因此此時是將惡意代碼檢測花費時間的考慮優(yōu)先級設置為大于檢測的準確性。

本領域技術人員能夠理解，步驟S801-S807僅為示例，本公開的范圍并不僅限于此。如前文實施例所述，系統(tǒng)應用文件、已安裝程序包名、進程空間加載文件和方法類型標識這四種檢測手段可任選其中若干種實施，并且既可按任意順序實施也可并行實施。另外，步驟S807也僅為示例，本公開的其他實施例還可視客戶端程序的設計需求而任意改動，例如可在確定存在惡意代碼時通過終端的操作界面對用戶進行警示，這些改動都屬于本公開的保護范圍內。

圖9為根據(jù)本公開一實施例的用于檢測惡意代碼的裝置示意圖，如圖所示，本實施例的裝置包括操作請求響應模塊91及選自以下群組的一個或多個模塊：系統(tǒng)文件檢測模塊92、安裝包檢測模塊93、進程檢測模塊94和標識檢測模塊95。其中：

操作請求響應模塊91設置為響應于客戶端程序接收的操作請求觸發(fā)選自系統(tǒng)文件檢測模塊92、安裝包檢測模塊93、進程檢測模塊94和標識檢測模塊95的一個或多個模塊來確定是否存在惡意代碼；

系統(tǒng)文件檢測模塊92設置為檢測啟動終端的操作系統(tǒng)的系統(tǒng)應用文件是否合法；

安裝包檢測模塊93設置為檢測操作系統(tǒng)提供的安裝包管理器中是否存在非法的程序包名；

進程檢測模塊94設置為檢測操作系統(tǒng)的進程空間內加載的文件中是否存在預設黑名單中的文件名；

標識檢測模塊95設置為遍歷終端上當前所運行進程中的關鍵應用程序接口API并檢測關鍵API的方法類型標識是否合法。

圖10為根據(jù)本公開另一實施例的用于檢測惡意代碼的裝置示意圖，如圖所示，本實施例的裝置在圖9的基礎上還包括安全級別判斷模塊96。該安全級別判斷模塊96設置為判斷操作請求的安全級別，在判斷操作請求的安全級別為第一級別時，觸發(fā)標識檢測模塊95來確定是否存在惡意代碼；并在判斷操作請求的安全級別為高于第一級別的第二級別時，按順序觸發(fā)系統(tǒng)文件檢測模塊92、安裝包檢測模塊93、進程檢測模塊94和標識檢測模塊95，其中任一模塊確定存在惡意代碼則返回確定存在惡意代碼的結果。

上述裝置中各個模塊的功能和作用的實現(xiàn)過程具體詳見上述方法中對應步驟的實現(xiàn)過程，在此不再贅述。

對于裝置實施例而言，由于其基本對應于方法實施例，所以相關之處參見方法實施例的部分說明即可。以上所描述的裝置實施例僅僅是示意性的，其中所述作為分離部件說明的模塊可以是或者也可以不是物理上分開的，作為模塊顯示的部件可以是或者也可以不是物理單元，即可以位于一個地方，或者也可以分布到多個網絡單元上?？梢愿鶕?jù)實際的需要選擇其中的部分或者全部模塊來實現(xiàn)本公開方案的目的。本領域普通技術人員在不付出創(chuàng)造性勞動的情況下，即可以理解并實施。

根據(jù)上述本公開用于檢測惡意代碼的方法和裝置，通過響應于對操作請求安全級別的判斷來觸發(fā)不同的檢測手段，可以實現(xiàn)針對不同安全級別的操作請求設置不同速度和精度的檢測策略；通過遍歷當前進程中關鍵API的合法性來確定是否存在惡意代碼侵入，可以實現(xiàn)針對特定類型外掛程序的精確判斷。另外，采用本公開的實施例來進行惡意代碼的檢測，即使在當前全部采集數(shù)據(jù)已經暴露的情況下，仍舊能夠有效保證所采集數(shù)據(jù)的正確性；針對基于xposed架構的外掛程序能夠實施有效的檢測；并且能夠在無需獲取root權限的情況下，通過對app_proccess文件、自身進程空間和app應用環(huán)境進行掃描來確定是否存在惡意代碼侵入。

雖然已參照幾個典型實施例描述了本公開，但應當理解，所用的術語是說明和示例性、而非限制性的術語。由于本公開能夠以多種形式具體實施而不脫離申請的精神或實質，所以應當理解，上述實施例不限于任何前述的細節(jié)，而應在隨附權利要求所限定的精神和范圍內廣泛地解釋，因此落入權利要求或其等效范圍內的全部變化和改型都應為隨附權利要求所涵蓋。