用于检测恶意代码的方法和装置与流程

本公开涉及移动终端技术领域，尤其涉及一种用于检测恶意代码的方法和装置。

背景技术：

随着移动终端技术的发展，越来越多的用户选择使用移动终端下载的各种应用程序来完成日常生活乃至工作相关的各种事项，例如缴费、购物、安排日程计划等等。相应地，也有越来越多的商家选择提供应用程序来为用户提供各种各样的服务，例如新闻、社交、外卖等等。在使用例如Android(安卓)等开放式操作系统的终端上，应用程序可能被恶意代码侵入而产生不良影响。例如，有些用户为了实现抢票、刷单等目的，会故意下载安装第三方非法提供的外挂程序(例如基于xposed架构)，这些外挂程序会与应用一起运行，模拟用户操作与应用程序的后台服务器通信，从而对服务器产生不必要的负担。

外挂程序可能是为了帮助用户进行注册、登录等自助操作(例如抢票)，或者可能是为了引入不必要的广告，但也有可能会在后台抓取用户移动终端上的隐私数据，对用户造成重大的安全隐患。另一方面，部分用户故意使用带有外挂的应用程序进行抢票、刷单等恶意操作，也会给应用程序的原始提供方带来不可预估的损失。

为此，目前市场上已开发出一些能够进行恶意代码/外挂程序的检测等常规安全操作的防护软件。然而，由于应用程序的数目繁多，相应的外挂程序种类也十分庞杂，恶意代码的侵入原理也层出不穷，造成防护软件即使频繁更新也无法彻底杜绝外挂程序的侵入。如何从根源上精确地消除外挂程序的危害便成为业内急需解决的问题。

技术实现要素：

本公开的目的是提供一种用于检测恶意代码的方法和装置，以解决现有技术中存在的上述问题。

根据本公开的一个方面，提供一种用于检测恶意代码的方法，应用于终端上运行的客户端程序中，该方法包括：响应于所述客户端程序接收的操作请求执行选自以下群组中的一个或多个步骤来确定是否存在恶意代码：检测启动所述终端的操作系统的系统应用文件是否合法；检测所述操作系统提供的安装包管理器中是否存在非法的程序包名；检测所述操作系统的进程空间内加载的文件中是否存在预设黑名单中的文件名；以及遍历所述终端上当前所运行进程中的关键应用程序接口API，检测所述关键API的方法类型标识是否合法。

根据本公开的另一个方面，提供一种用于检测恶意代码的装置，应用于终端上运行的客户端程序中，该装置包括：操作请求响应模块，设置为响应于所述客户端程序接收的操作请求触发选自以下群组中的一个或多个模块来确定是否存在恶意代码：系统文件检测模块，设置为检测启动所述终端的操作系统的系统应用文件是否合法；安装包检测模块，设置为检测所述操作系统提供的安装包管理器中是否存在非法的程序包名；进程检测模块，设置为检测所述操作系统的进程空间内加载的文件中是否存在预设黑名单中的文件名；以及标识检测模块，设置为遍历所述终端上当前所运行进程中的关键应用程序接口API并检测所述关键API的方法类型标识是否合法。

根据本公开用于检测恶意代码的方法和装置，通过响应于操作请求来触发不同的检测手段，可以实现针对特定类型外挂程序的精确判断。

附图说明

图1为根据本公开一实施例的用于检测恶意代码的方法流程图；

图2为根据本公开另一实施例的用于检测恶意代码的方法流程图；

图3为根据本公开另一实施例的用于检测恶意代码的方法流程图；

图4为本公开用于检测恶意代码的方法中系统文件检测步骤的实施例流程图；

图5为本公开用于检测恶意代码的方法中安装包检测步骤的实施例流程图；

图6为本公开用于检测恶意代码的方法中进程检测步骤的实施例流程图；

图7为本公开用于检测恶意代码的方法中标识检测步骤的实施例流程图；

图8为根据本公开又一实施例的用于检测恶意代码的方法流程图；

图9为根据本公开一实施例的用于检测恶意代码的装置示意图；

图10为根据本公开另一实施例的用于检测恶意代码的装置示意图。

具体实施方式

下面将详细描述本公开的具体实施例。应当注意，这里描述的实施例只用于举例说明，并不用于限制本公开。

以下实施例用于说明本公开，但不用来限制本公开的范围。

在本公开说明书中，恶意代码是指应用程序初始提供方之外的一切第三方未经授权添加的与应用程序绑定运行的代码，而不论该部分代码的添加目的如何。另一方面，外挂程序是指恶意代码随原始应用程序一起或单独运行时的表现形式，以下说明中除非特别说明否则外挂程序和恶意代码可互换使用。

如上文所述，现有技术中针对种类层出不穷的外挂程序无法实现有针对性的准确检测，也无法满足不同层次的检测需求。为此，本公开提供一种用于检测恶意代码的方法。图1为根据本公开一实施例的用于检测恶意代码的方法流程图，其可应用于终端上运行的客户端程序中。在一个实施例中，本公开的方法可以SDK(Software Development Kit，软件开发工具包)或源代码的形式集成到现有客户端程序的代码中，从而达到在根源上消除外挂程序的目的。如图1所示，本实施例的方法包括以下步骤S101-S105。

在步骤S101中，响应于客户端程序接收的操作请求执行选自以下S102-S105中的一个或多个步骤来确定是否存在恶意代码。

客户端程序在收到用户发起的操作请求时，可根据系统默认设置或用户定制设置来选择执行以下S102-S105中的一个或多个步骤来确定是否存在恶意代码。如图1所述，步骤S101后的步骤S102-S105之间用无箭头的线条连接，以此来表示这些步骤之间是任意选择且无特定顺序的要求。

在步骤S102中，检测启动终端的操作系统的系统应用文件是否合法。

许多外挂程序会对用于启动终端操作系统的系统应用文件进行替换，以达到例如随系统一同启动的目的。因此，在本步骤中，可以通过判断该系统应用文件(可能为多个)是否合法来确定是否存在恶意代码侵入。本步骤的详细流程可进一步参见图4所示实施例。

在步骤S103中，检测操作系统提供的安装包管理器中是否存在非法的程序包名。

本步骤中可以通过判断终端操作系统中是否存在非法的程序包名来确定是否存在恶意代码侵入，详细流程可进一步参见图5所示实施例。

在步骤S104中，检测操作系统的进程空间内加载的文件中是否存在预设黑名单中的文件名。

对于某段时间内传播量较大的外挂程序，可针对这些外挂程序的后门文件整理出预设的黑名单，并通过检测操作系统的进程空间内是否加载了该黑名单中的文件来确定是否存在恶意代码侵入。本步骤的详细流程可进一步参见图6所示实施例。

在步骤S105中，遍历终端上当前所运行进程中的关键API(Application Program Interface应用程序接口)，检测关键API的方法类型标识是否合法。

在一个实施例中，检测的目标API均设置有方法类型标识。该方法类型标识对应的标志位在正常情况下均呈现为默认设置，例如设置为指示java方法，而外挂程序出于拦截并修改系统API返回值的需要会修改目标API的方法类型标识。因此，在本步骤中可以通过检测关键API的方法类型标识是否合法来确定是否存在恶意代码，详细流程可进一步参见图7所示实施例。

根据上述本公开用于检测恶意代码的方法实施例，通过响应于操作请求来触发不同的检测手段，可以实现针对不同的操作请求设置灵活的检测策略；通过遍历当前进程中关键API的合法性来确定是否存在恶意代码侵入，可以实现针对特定类型外挂程序的精确判断。

图2为根据本公开另一实施例的用于检测恶意代码的方法流程图，其可应用于终端上运行的客户端程序中。如图2所示，本实施例的方法包括以下步骤S201-S203。

在步骤S201中，响应于客户端程序接收的操作请求判断操作请求的安全级别。

根据客户端程序的种类不同，可针对各种操作请求设置不同的安全级别。以支付类程序为例，出于对用户及其终端安全性的考虑，例如可将用户通过客户端发起的登录、支付和修改个人资料等操作请求设置为较高的安全级别，而将浏览、查询等其他操作请求设置为较低的安全级别。又以提供外卖服务的平台类程序为例，出于防止第三方恶意刷单的考虑，在需要严格禁止刷单(即不考虑检测的准确性)时可将注册、登录等所有操作均设置为较高的安全级别，而在需要精确禁止刷单(即要优先考虑检测的准确性)时可将所有操作均设置为较低的安全级别。

客户端程序在收到用户发起的操作请求时，首先根据接收的操作请求种类并基于预设的安全策略来判断当前操作请求对应的安全级别。

在步骤S202中，当判断操作请求的安全级别为较低时，遍历终端上当前所运行进程中的关键应用程序接口。

当步骤S201的判断结果指示当前操作请求的安全级别较低时，说明此时无需轻易触发检测到恶意代码的警告。换言之，此时可优先考虑恶意代码检测的准确性，而无需考虑检测所花费的时间。在本实施例中，针对较低的安全级别所设置的准确性较高的检测手段通过遍历当前终端上所运行进程中的关键API来完成，具体检测流程可参见步骤S203和图7实施例所述。在一个实施例中，这里的关键API可根据当前应用所涉及的具体业务来指定。例如，在当前应用程序所涉及的业务需要采集用户安装应用的情况下，可将“PackageManager.getInstalledPackages()”预设为关键API。

在步骤S203中，检测关键API的方法类型标识是否合法以确定是否存在恶意代码。

在一个实施例中，所有检测的目标API均设置有方法类型标识。该方法类型标识对应的标志位在正常情况下均呈现为默认设置，例如设置为指示java方法，而外挂程序出于拦截并修改系统API返回值的需要会修改目标API的方法类型标识。因此，在本步骤中可以通过检测关键API的方法类型标识是否合法来确定是否存在恶意代码。具体而言，如果检测到所有关键API的方法类型标识均呈现为默认设置，则判断这些方法类型标识合法，从而确定不存在恶意代码，即当前客户端程序未被外挂程序侵入。反之，如果检测到任意关键API的方法类型标识经过了修改，则判断该方法类型标识不合法，从而确定存在恶意代码，即当前客户端程序已被外挂程序侵入。

上述实施例用于检测恶意代码的方法，在判断出当前操作请求的安全级别较低时，通过采用检测关键API的方法类型标识来确定是否存在恶意代码，可以消除误判的可能性，能够实现对外挂程序的精确检测。

图3为根据本公开另一实施例的用于检测恶意代码的方法流程图，其可应用于终端上运行的客户端程序中。如图3所示，本实施例的方法包括以下步骤S301-S308。

在步骤S301中，响应于客户端程序接收的操作请求判断操作请求的安全级别。

在步骤S302中，当判断操作请求的安全级别为较低时，遍历终端上当前所运行进程中的关键API。

在步骤S303中，检测关键API的方法类型标识是否合法以确定是否存在恶意代码。

上述步骤S301-S303分别对应于前述实施例的步骤S201-S203，此处不再赘述。

在步骤S304中，当判断所述操作请求的安全级别为较高时，执行步骤S303和S305-S307中的一个或多个步骤来确定是否存在恶意代码。

当步骤S301的判断结果指示当前操作请求的安全级别较高时，说明此时应将触发恶意代码警告的条件降低。换言之，此时可将恶意代码检测花费时间的考虑优先级设置为大于检测的准确性，也即，越快检测出可能存在恶意代码的结果越好。在本实施例中，针对较高的安全级别提供了步骤S305-S307和步骤S303共四种检测手段，具体的检测流程可参见步骤S305-S307和图4-图6实施例以及步骤S203和图7实施例所述。需要说明的是，具体应用中可根据客户端程序的特点从上述四种检测手段中选择其中的任意一种或多种来完成是否存在恶意代码的判断。例如，当选择步骤S303来进行检测时，说明此时针对不同的安全级别都使用准确性较高的方法类型标识来完成判断。又例如，当同时选择步骤S305-S307和步骤S303这四种检测手段来完成是否存在恶意代码的判断时，可按一定的顺序来进行检测(具体例如可参见图8所示实施例)，这时可兼顾考虑到恶意代码检测的时间开销和准确性。在图3中，步骤S304后的步骤S305-S307和步骤S303之间用无箭头的线条连接，以此来表示这些步骤之间是任意选择且无特定顺序的要求。

在步骤S305中，检测启动终端的操作系统的系统应用文件是否合法。

许多外挂程序会对用于启动终端操作系统的系统应用文件进行替换，以达到例如随系统一同启动的目的。因此，在本步骤中，可以通过判断该系统应用文件(可能为多个)是否合法来确定是否存在恶意代码侵入。在一个实施例中，系统应用文件是否合法的判断具体可通过将当前文件的特征码(如MD5码)与已知合法版本的文件特征码进行比对来进行，若发现二者不一致则说明该系统应用文件可能已被替换，从而确定存在恶意代码侵入。本步骤的详细流程可进一步参见图4所示实施例。

在步骤S306中，检测操作系统提供的安装包管理器中是否存在非法的程序包名。

一些外挂程序不仅以恶意代码的形式嵌入在应用程序中，而且还可能会随着该应用程序首次启动而以单独程序或插件的形式安装在终端的操作系统中。对此，在本步骤中可以通过判断终端操作系统中是否存在非法的程序包名来确定是否存在恶意代码侵入。在一个实施例中，非法程序包名的判断具体可通过操作系统提供的安装包管理器来进行，将安装包管理器中的所有已安装程序包名逐一与已知的非法程序包名进行比对，若发现非法的已安装程序包则确定存在恶意代码侵入。本步骤的详细流程可进一步参见图5所示实施例。

在步骤S307中，检测操作系统的进程空间内加载的文件中是否存在预设黑名单中的文件名。

对于以相似侵入原理或框架工作的同一类外挂程序，通常会在终端的操作系统中植入相同的关键文件。由于这类文件通常以进程的方式随操作系统长期运行，并为外挂程序的植入方进一步侵入终端操作系统(例如进行数据窃取)提供入口，因此通常被称为后门文件。对于某段时间内传播量较大的外挂程序，可针对这些外挂程序的后门文件整理出预设的黑名单，并通过检测操作系统的进程空间内是否加载了该黑名单中的文件来确定是否存在恶意代码侵入。若检测发现操作系统的进程文件内加载的文件中存在黑名单中的文件名，则确定存在恶意代码侵入。本步骤的详细流程可进一步参见图6所示实施例。

综上所述，虽然描述步骤S303和S305-S307，但利用这些步骤来确定是否存在恶意代码侵入并不存在顺序的限制，而且可以并行处理。在一个实施例中，各步骤的判断结果均输出为布尔值，最终通过预设的规则来确定综合的判断结果。

在步骤S308中，将确定是否存在恶意代码的结果附在操作请求中，以使终端的操作系统根据该结果返回对操作请求的响应。

在经过前述步骤得出是否存在恶意代码的判断结果后，可进一步将该判断结果附在步骤S301中述及的操作请求中，从而使终端的操作系统根据该结果返回对操作请求的响应。在另一个实施例中，返回响应的操作可由应用运行时所连接的后台服务器来进行。例如，在确定存在恶意代码侵入时，返回拒绝该操作请求的提示，并警示用户切换至更安全的系统环境(例如切换网络、运行安全防护软件等等)继续操作。

图4为本公开用于检测恶意代码的方法中系统文件检测步骤的实施例流程图。如前述步骤S305所述，本步骤的原理在于通过判断用于启动终端操作系统的系统应用文件是否被修改来确定是否存在恶意代码侵入。在终端操作系统是基于安卓(Android)系统的情况下，本实施例具体可包括以下步骤S401-S404。

在步骤S401中，在操作系统的系统文件夹中定位app_process文件。

app_process文件作为启动android process(安卓应用进程)的系统应用文件，也是例如基于xposed的外挂程序的替换对象。因此，在本实施例中，以操作系统/system/bin目录下的app_process文件作为检测对象来判断恶意代码的侵入。

在步骤S402中，提取app_process文件的特征码。

在步骤S403中，将提取的特征码与已知的合法特征码进行对比校验。

在步骤S404中，在提取的特征码与合法特征码一致时确定不存在恶意代码，不一致时确定存在恶意代码。

由步骤S402-S404可见，本实施例中使用app_process文件的特征码来判断其是否发生了变动。在一个实施例中，特征码可通过md5或shal校验运算来得到。具体而言，步骤S402中可对当前/system/bin目录下定位到的app_process文件进行md5或shal校验来得到其特征码；步骤S403中则将提取的特征码与预存的已知特征码进行对比校验，如果二者一致则判断当前的app_process文件是未经过修改的原始文件，反之，如果二者不一致则判断当前的app_process文件已被替换，从而确定存在恶意代码侵入。在一个实施例中，合法特征码可在当前应用运行的任意时刻通过对系统的app_process文件进行md5或shal校验运算来得到。

图5为本公开用于检测恶意代码的方法中安装包检测步骤的实施例流程图。如前述步骤S306所述，本步骤的原理在于通过判断终端操作系统中是否存在非法的程序包名来确定是否存在恶意代码侵入。在终端操作系统是基于Android系统的情况下，本实施例具体可包括以下步骤S501-S503。

在步骤S401中，调用操作系统提供的与安装包管理器PackageManager相关的API来遍历已安装程序包。

Android操作系统通常会预装默认的安装包管理器PackageManager，以方便用户对当前终端上所有的已安装程序包进行管理。同时，Android操作系统还会开放一部分与PackageManager有关的API，以方便第三方程序通过调用该部分API来辅助用户对已安装程序包的高级管理(例如进行分类、使用频率排序、卸载清理等操作)。相应地，为了排除存在安全隐患的安装程序包，本步骤首先通过调用与PackageManager有关的API来遍历当前终端上安装的所有程序包名。

在步骤S502中，将已安装程序包逐一与已知的非法程序包名进行比对。

在步骤S503中，在已安装程序包中未发现与非法程序包名匹配的程序包时确定不存在恶意代码，发现与非法程序包名匹配的程序包时确定存在恶意代码。

程序包名是对于应用程序唯一的字符串，因此本实施例中可基于已安装程序包的包名来确定是否存在非法的已安装程序包。在一个实施例中，非法程序包名可基于已知的外挂程序来分析收集并存在于客户端程序的源代码中。另外，在一个实施例中，由于一些外挂程序会以“未知(Unknown)”作为程序包名呈现在PackageManager中，因此可将“未知(Unknown)”添加在上述预存的非法程序包名中。步骤S502将当前的安装程序包逐一与预存的非法程序包名进行比对，如果发现与非法程序包名匹配的程序包时则确定存在恶意代码，反之，如果未发现与非法程序包名匹配的程序包时则确定不存在恶意代码。

图6为本公开用于检测恶意代码的方法中进程检测步骤的实施例流程图。如前述步骤S307所述，本步骤的原理在于通过判断操作系统的进程空间内是否加载了预设黑名单中的文件来确定是否存在恶意代码侵入。在终端操作系统是基于Android系统的情况下，本实施例具体可包括以下步骤S601-S603。

在步骤S601中，遍历进程空间内加载的文件。

Android操作系统提供了相关接口，使得第三方应用程序(例如此处的客户端程序)能够通过该接口来访问系统的进程空间，从而遍历进程空间内加载的所有文件。

在步骤S602中，将加载的文件逐一与预设黑名单中的特征文件进行比对。

在步骤S603中，在加载的文件中未发现与特征文件匹配的文件时确定不存在恶意代码，发现与特征文件匹配的文件时确定存在恶意代码。

如前所述，外挂程序区别于客户端程序独立运行，因此在进程空间中可能表现加载了若干个文件，而某一类外挂程序加载的文件都相同。以基于xposed的外挂程序为例，会加载xposedbridge.jar等特征文件。如此一来，便可通过判断操作系统的进程空间中是否加载了某些文件来确定是否存在恶意代码入侵。与程序包名类似，这些文件也可以黑名单的形式基于已知的外挂程序来分析收集并存在于客户端程序的源代码中。步骤S602将当前进程空间中加载的文件逐一与预设黑名单中的特征文件进行比对，如果发现与特征文件名匹配的加载文件时则确定存在恶意代码，反之，如果未发现与特征文件名匹配的加载文件时则确定不存在恶意代码。由于同属于文件名的比对，在一个实施例中，步骤S602中也可与图4所示实施例类似通过md5、shal等校验计算并比对文件名的特征码来实现加载文件与特征文件的比对。在一个实施例中，可进行文件名的整体校验，也可进行文件名局部的关键字校验。

图7为本公开用于检测恶意代码的方法中标识检测步骤的实施例流程图。如前述步骤S203所述，本步骤的原理在于通过判断关键API是否被修改来确定是否存在恶意代码侵入。在终端操作系统是基于Android系统的情况下，本实施例具体可包括以下步骤S701-S703。

在步骤S701中，检测关键API的方法类型标识；

在步骤S702中，在检测到方法类型标识指示为java方法时，确定不存在恶意代码；以及

在步骤S703中，在检测到方法类型标识被修改为native类型时，确定存在恶意代码。

由上述步骤可见，本实施例中需要检测目标API方法的c struct(c结构)。这里，c struct是指当前方法在虚拟机运行时的数据结构映射。一般而言，Method(方法)结构体中对应的方法类型标识在正常情况下应标记为java方法，而例如基于xposed等架构的外挂程序会将该方法类型标识修改为native类型。这里，Method结构体是指Java方法在虚拟机运行时对应的数据结构。因此，步骤S603中如果检测到关键API的方法类型标识已被修改为native类型，则认为该方法已被侵入并拦截，通过该方法读取的内容不再可靠。

现有的恶意代码检查方式主要通过收集设备系统参数并与正常系统参数和自定义规则进行匹配，来判断用户系统参数是否已被外部程序篡改，而保证采集数据有效性的措施更多是通过增加字段和代码混淆来实现。相应地，目前业内仍集中于通过增加采集系统参数和增加加密手段的方式来保护采集的数据用于校验合法用户。然而，这种收集并匹配设备系统参数的方式一旦被成功反编译而使采集数据暴露，外挂程序的设计者便能够通过采用规避数据的方式来阻止成功匹配，由此使得整个检查方式失效。相比之下，采用上述图4-图7所示的实施例来进行恶意代码的检测，数据结构采集结果可与检测结果同步上传，由后台服务器根据检测结果来分析用户采集数据所用的API是否被篡改，如果被篡改则认为数据是不安全的，因此，即使在当前全部采集数据已经暴露的情况下，仍旧能够有效保证所采集数据的正确性。

另一方面，xposed作为目前Android操作系统上唯一一种开源且不必修改原应用程序的外挂程序侵入框架，已经有多种外挂程序构建于xposed之上。对于xposed架构的外挂程序，上述收集并匹配设备系统参数的传统方式极难检测，造成Android操作系统上的各种刷单、刷量等非法手段在此基础上大量应用，通过模拟新用户和新设备来获取利益，使各大移动互联网公司深受其害，给移动互联网应用开发者也带来大量损失。相比之下，采用上述图4-图7所示的实施例来进行恶意代码的检测，针对基于xposed架构的外挂程序能够实施有效的检测。

除此之外，现有的各种反外挂及安全程序往往由于晚于系统进程启动，造成自身也被侵入而失去检测能力，而应用程序自身并无root权限，通常手段也无法有效检测，容易被外挂程序伪造的数据所蒙蔽。相比之下，采用上述图4-图7所示的实施例来进行恶意代码的检测，能够在无需获取root权限的情况下，通过对app_proccess文件、自身进程空间和app应用环境进行扫描来确定是否存在恶意代码侵入。

图8为根据本公开又一实施例的用于检测恶意代码的方法流程图，如图所示，本实施例的方法包括以下步骤S801-S807。

在步骤S801中，响应于客户端程序接收的操作请求判断该操作请求的安全级别。

本步骤可参见前述步骤S201的说明，此处不再赘述。

在步骤S802中，当判断操作请求的安全级别为较高时，转入步骤S803；当判断操作请求的安全级别为较低时，转入步骤S806。

本步骤可参见前述步骤S202和S302的说明，此处不再赘述。

在步骤S803中，检测启动终端操作系统的系统应用文件是否合法，如果合法则转入步骤S804，不合法则确定存在恶意代码侵入。

在步骤S804中，检测操作系统提供的安装包管理器中是否存在非法的程序包名，如果不存在则转入步骤S805，存在则确定存在恶意代码侵入。

在步骤S805中，检测操作系统的进程空间内加载的文件中是否存在预设黑名单中的文件名，如果不存在则转入步骤S806，存在则确定存在恶意代码侵入。

在步骤S806中，遍历终端上当前所运行进程中的关键API，检测该关键API的方法类型标识是否合法，如果合法则确定当前终端系统安全，不合法则确定存在恶意代码侵入。

步骤S803-S806可分别参见前述图4-图7所示实施例的说明，此处不再赘述。

在步骤S807中，将确定是否存在恶意代码的结果附在操作请求中，以使终端的操作系统根据该结果返回对该操作请求的响应。

由以上步骤S801-S807可见，本实施例中在操作请求的安全级别较低时，直接采用方法类型标识的检测手段来确定是否存在恶意代码侵入，此时优先考虑了恶意代码检测的准确性；在操作请求的安全级别较高时，则顺序执行系统应用文件(例如app_process文件)、已安装程序包名、进程空间加载文件和方法类型标识这四种检测手段，其中任一检测手段确定存在恶意代码则返回确定存在恶意代码的结果，而只有通过四种检测手段都确定不存在恶意代码才确定系统安全，这四种检测手段可简单理解为是按照检测速度由高到低、检测精度由低到高排序，因此此时是将恶意代码检测花费时间的考虑优先级设置为大于检测的准确性。

本领域技术人员能够理解，步骤S801-S807仅为示例，本公开的范围并不仅限于此。如前文实施例所述，系统应用文件、已安装程序包名、进程空间加载文件和方法类型标识这四种检测手段可任选其中若干种实施，并且既可按任意顺序实施也可并行实施。另外，步骤S807也仅为示例，本公开的其他实施例还可视客户端程序的设计需求而任意改动，例如可在确定存在恶意代码时通过终端的操作界面对用户进行警示，这些改动都属于本公开的保护范围内。

图9为根据本公开一实施例的用于检测恶意代码的装置示意图，如图所示，本实施例的装置包括操作请求响应模块91及选自以下群组的一个或多个模块：系统文件检测模块92、安装包检测模块93、进程检测模块94和标识检测模块95。其中：

操作请求响应模块91设置为响应于客户端程序接收的操作请求触发选自系统文件检测模块92、安装包检测模块93、进程检测模块94和标识检测模块95的一个或多个模块来确定是否存在恶意代码；

系统文件检测模块92设置为检测启动终端的操作系统的系统应用文件是否合法；

安装包检测模块93设置为检测操作系统提供的安装包管理器中是否存在非法的程序包名；

进程检测模块94设置为检测操作系统的进程空间内加载的文件中是否存在预设黑名单中的文件名；

标识检测模块95设置为遍历终端上当前所运行进程中的关键应用程序接口API并检测关键API的方法类型标识是否合法。

图10为根据本公开另一实施例的用于检测恶意代码的装置示意图，如图所示，本实施例的装置在图9的基础上还包括安全级别判断模块96。该安全级别判断模块96设置为判断操作请求的安全级别，在判断操作请求的安全级别为第一级别时，触发标识检测模块95来确定是否存在恶意代码；并在判断操作请求的安全级别为高于第一级别的第二级别时，按顺序触发系统文件检测模块92、安装包检测模块93、进程检测模块94和标识检测模块95，其中任一模块确定存在恶意代码则返回确定存在恶意代码的结果。

上述装置中各个模块的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本公开方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

根据上述本公开用于检测恶意代码的方法和装置，通过响应于对操作请求安全级别的判断来触发不同的检测手段，可以实现针对不同安全级别的操作请求设置不同速度和精度的检测策略；通过遍历当前进程中关键API的合法性来确定是否存在恶意代码侵入，可以实现针对特定类型外挂程序的精确判断。另外，采用本公开的实施例来进行恶意代码的检测，即使在当前全部采集数据已经暴露的情况下，仍旧能够有效保证所采集数据的正确性；针对基于xposed架构的外挂程序能够实施有效的检测；并且能够在无需获取root权限的情况下，通过对app_proccess文件、自身进程空间和app应用环境进行扫描来确定是否存在恶意代码侵入。

虽然已参照几个典型实施例描述了本公开，但应当理解，所用的术语是说明和示例性、而非限制性的术语。由于本公开能够以多种形式具体实施而不脱离申请的精神或实质，所以应当理解，上述实施例不限于任何前述的细节，而应在随附权利要求所限定的精神和范围内广泛地解释，因此落入权利要求或其等效范围内的全部变化和改型都应为随附权利要求所涵盖。