CN110610083A - 对监控数据进行污染判断的方法及相应装置 - Google Patents

Abstract

本发明实施例公开了一种对监控数据进行污染判断的方法、装置、计算机设备和计算机存储介质，涉及系统监控技术领域。其中污染判断方法包括：对至少一个预监控敏感行为发生时调用的各个API对应设置主监控点，每个主监控点用于在API被调用时生成调用信息；当某个API被第一应用调用而触发与对应的主监控点时，获取该主监控点生成的调用信息；根据利用各个主监控点生成的调用信息确定出的第一应用触发各个主监控点的顺序和/或一定时间内触发各个主监控点的次数，判断第一应用的监控数据是否存在数据污染。本方法能准确判断主监控点的数据是否由恶意应用伪造而来，确保监控系统的监控质量，保证应用后续敏感行为判断的真实性，提前感知可能的异常和入侵。

Description

对监控数据进行污染判断的方法及相应装置

技术领域

本发明涉及系统监控技术，具体涉及判断被监控的应用的监控数据是否被污染的方法及其装置、计算机设备和计算机存储介质。

背景技术

随着以手机为代表的移动终端的迅速普及和发展，移动终端已经成为人们生活和工作中不可或缺的一部分，因此人们对于手机的安全性的要求也越来越高，其中采用行为监控的动态防护方案越来越成为主流。

现有的行为监控方法都是在系统层加入一些监控点(也被称为hook点或者插桩点)，每个应用在运行过程中若触发对应的监控点，监控点会搜集该应用运行时的相关信息，这些应用运行相关信息包括触发该监控点的应用进程的UID(即用户标识，在Linux平台上每个用户都有唯一标示UID用于区别其他用户)和PID(即进程ID，在Linux平台上每个进程都有唯一标示PID用于区别其他进程)、监控点MID(即监控点标识，每个监控点都有唯一标识MID，知晓MID就能知晓是系统中哪处API、库函数、服务等被触发)、以及触发该监控点的应用在调用哪个API，调用哪个服务，以及调用这个服务的什么接口等信息。监控点将这些应用运行相关信息实时地通过异步或者同步方式发送给一个独立的监控模块。监控模块可以是一个服务，也可以是一个单独的应用，或者系统守护进程等。监控模块根据每个应用在运行过程中触发监控点时发送过来的应用运行相关信息，进行汇总、整理、统计、匹配，进而对该应用的行为进行判定，通常是对应用行为的恶意性或者病毒性进行判定，将判定结果发送给处理模块。然后处理模块可以根据监控模块的判定结果对应用进行处理，如果判定为非恶意，则不做任何处理；如果判定为恶意，则可以根据具体方案的实现进行后台静默处理、向用户弹出提示请求用户决策、或交由其他模块决策和处置，例如杀死恶意应用进程、禁用、卸载恶意应用等。。

然而上述现有的行为监控方案具有如下缺陷：

1)如果监控方案的实现被攻击者通过逆向工程而得知其细节，攻击者可以编写恶意应用来主动调用监控点处的代码逻辑，来产生虚假的监控事件，这些假信息会对监控模块产生干扰，甚至会让监控模块产生误判，最终做出错误的判定，错误的判定包括将好的应用判定为有恶意性的和将具有恶意性的应用判定为好的应用；

2)在某些设计存在缺陷的防护方案上，恶意应用可能会通过伪造自己的身份，例如伪造PID和UID信息，并将“陷害”应用对象的UID和PID替换为自己的UID和PID，然后构造监控事件，发送给监控模块，让监控模块误认为某正常应用正在执行恶意操作。

因此，如果监控点产生的监控数据已通过上述1)和2)方式虚假构造，则监控模块接收到的监控数据会存在虚假问题，致使后续所有基于监控数据的应用行为恶意性或者病毒性判定和处理都会发生异常，这至少表现在，不但无法识别异常的行为或是恶意的行为，还可能会将正常的行为判定为异常的。

因此，有必要提供一种判断被监控的应用的监控数据是否被污染的方法，确保监控系统的监控质量，提前感知可能的异常和入侵。

发明内容

本发明实施例提供了一种对监控数据进行污染判断的方法及其装置、计算机设备和计算机存储介质，用以解决现有技术中所存在的上述技术问题。

第一方面，本发明实施例提供了一种对监控数据进行污染判断的方法。

具体地，所述对监控数据进行污染判断的方法包括：

对至少一个预监控敏感行为发生时调用的各个API对应设置主监控点，每个主监控点用于在对应的API被调用时生成调用信息，所述调用信息包括对应的主监控点的标识、触发所述对应的主监控点的应用的用户标识，以及所述应用触发所述对应的主监控点的时间；

当某个API被第一应用调用而触发与所述某个API对应的主监控点时，获取与所述某个API对应的主监控点生成的调用信息；

根据利用各个主监控点生成的调用信息确定出的所述第一应用触发各个主监控点的顺序和/或所述第一应用在一定时间内触发各个主监控点的次数，判断所述第一应用的监控数据是否存在数据污染。

第二方面，本发明实施例提供了一种对监控数据进行污染判断的装置。

具体地，所述对监控数据进行污染判断的装置包括：

主监控点设置模块，用于对至少一个预监控敏感行为发生时调用的各个API对应设置主监控点，每个主监控点用于在对应的API被调用时生成调用信息，所述调用信息包括对应的主监控点的标识、触发所述对应的主监控点的应用的用户标识，以及所述应用触发所述对应的主监控点的时间；

调用信息获取模块，用于当某个API被第一应用调用而触发与所述某个API对应的主监控点时，获取与所述某个API对应的主监控点生成的调用信息；

第一污染判断模块，用于根据利用各个主监控点生成的调用信息确定出的所述第一应用触发各个主监控点的顺序和/或所述第一应用在一定时间内触发各个主监控点的次数，判断所述第一应用的监控数据是否存在数据污染。

第三方面，本发明实施例提供了一种计算机设备。

具体地，所述计算机设备包括：

处理器；以及

用于存放计算机程序的存储器，

其中，所述处理器用于执行所述存储器上所存放的计算机程序，以实现上述第一方面所述的对监控数据进行污染判断的方法。

第四方面，本发明实施例提供了一种计算机存储介质。

具体地，所述计算机存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现上述第一方面所述的对监控数据进行污染判断的方法

本申请实施例对监控数据进行污染判断的方法、装置、计算机设备和存储介质，通过设置获取每个API调用情况的主监控点，当某应用在运行过程中触发主监控点时，根据获取的所有主监控点的调用信息，确定该应用触发所有主监控点的顺序和/或在一定时间内触发主监控点的次数，进而判断该应用的监控数据是否存在数据污染，解决了现有技术中当虚假构造监控数据时，直接利用监控数据判断应用是否恶意所存在的恶意行为无法识别和恶意行为判定不准确问题，能准确判断主监控点的数据是否由恶意应用伪造而来，确保监控系统的监控质量，保证应用后续敏感行为判断的真实性，提前感知可能的异常和入侵。

本发明的这些方面或其他方面在以下实施例的描述中会更加简明易懂。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要使用的附图作一简单的介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明方法实施例1的对监控数据进行污染判断的方法的流程图；

图2是本发明方法实施例2的对监控数据进行污染判断的方法的流程图；

图2A是图2对监控数据进行污染判断的方法中涉及的监控事件的组织结构示意图；

图3是本发明装置实施例1的对监控数据进行污染判断的装置的示意图；

图4是本发明装置实施例2的对监控数据进行污染判断的装置的示意图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述。

在本发明的说明书和权利要求书及上述附图中的描述的一些流程中，包含了按照特定顺序出现的多个操作，但是应该清楚了解，这些操作可以不按照其在本文中出现的顺序来执行或并行执行，操作的标号如102、104等，仅仅是用于区分开各个不同的操作，标号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可以按顺序执行或并行执行。需要说明的是，本文中的“第一”、“第二”等描述，是用于区分不同的消息、设备、模块等，不代表先后顺序，也不限定“第一”和“第二”是不同的类型。

下面将结合附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域技术人员在没有付出创造性劳动的前提下所获得的所有其他实施方式，都属于本发明保护的范围。

【方法实施例1】

本实施例提供了一种对监控数据进行污染判断的方法，用于判断应用的监控数据是否出现数据污染，该方法适用于所有的计算机系统，特别是移动终端。参考图1，该方法包括：

步骤S101，对至少一个预监控敏感行为发生时调用的各个API设置对应的主监控点，每个主监控点用于在对应的API被调用时生成调用信息，该调用信息包括对应的主监控点的标识(MID)、触发该对应的主监控点的应用的用户标识(UID)和该应用触发该对应的主监控点的时间；

以Linux平台为例，UID是指Linux平台上的用户ID，PID是指Linux平台上的进程ID。在Linux平台上每个用户有唯一标示UID来区别其他用户。每个运行的进程都所属某一用户，且每个进程都有唯一标示PID用于区别其他进程，即，每个进程会有对应的UID和PID。UID和PID本身是对监控事件的来源进行标示。UID和PID相当于“谁”，只要UID和PID是真实可靠的，那么基于UID和PID就可以确定是“谁”触发了事件；每个主监控点(也称为hook点或插桩点)用唯一的MID来标示，知道了MID就可以知道是系统中的哪处API、库函数、服务等被触发了，即MID相当于干了什么。

其中，一个主监控点对应一个API，当系统中的任一应用调用了某API，则与该某API对应的主监控点就会被触发。

作为示例，如果要监控应用是否会产生资费，那么需要监控应用是否发短信和打电话这两个行为，该两个行为发生时调用的所有API都需要对应设置主监控点；如果要监控应用是否泄漏隐私数据，那么需要监控应用是否读取联系人、是否读取短信、是否读取照片等行为，这些行为发生时调用的所有API都需要对应设置主监控点。

作为本实施例的一种优选的实施方式，主监控点的设置规则包括：对于任一API的主监控点，当既能在对应的应用进程中插桩，又能在对应的服务进程中插桩时，或者仅能在对应的服务进程中插桩时，主监控点的插桩点位于对应的服务进程；当仅能在对应的应用进程中插桩时，主监控点的插桩点位于对应的应用进程。以下对主监控点的设置规则进行详细说明。

一方面，在应用进程中插桩的主监控点生成的监控数据不具有可靠性，这是因为，应用进程可以对产生监控数据的逻辑进行修改，使得1)监控数据不产生；2)产生不实的监控数据；3)产生多余的监控数据。即应用进程可以篡改监控数据的来源，即篡改触发该主监控点的应用的进程标识PID、用户标识UID。

另一方面，在服务进程中插桩的主监控点生成的监控数据具有可靠性。这是因为，操作系统可以保证进程空间的隔离性，使得低权限的应用进程无法直接篡改高权限的服务进程空间的数据，这确保了应用进程无法篡改监控事件的来源，保证了在服务进程中产生的监控数据的来源是安全可靠的。也就说恶意应用的开发者即使知道了监控系统的实现，也没有办法通过修改本进程的代码逻辑和数据来篡改UID和PID。因为生成监控事件的代码不在本应用进程内。以Android为例，服务进程通过Binder.getCallingUid()和Binder.getCallingPid()可以获取调用IPC的应用进程的UID和PID，并且PID和UID都是在服务进程中产生的，是真实的，应用进程无法篡改和伪造。基于可靠监控事件中的UID和PID，监控模块就可以正确地识别出监控事件的来源。

例如，以访客为例，若一个陌生访客要进入某国家单位办事，但是在进门时要接受安检。访客相当于应用进程；安检人员相当于服务进程；安检的过程相当于监控过程；安检过程产生的信息，例如行李里有没有炸药，有没有易燃物，人身上有没有携带刀具，人的身份证号是多少等相当于监控事件。如果监控事件由应用进程产生而非服务进程产生，这就相当于，访客直接告诉安检人员“我没有带违禁物品，我的身份是xxx，请放我过去”。此时如果安检人员仅基于访客告知的信息做出判断，很显然是存在严重安全问题的。因此，监控事件必须由安检人员检查访客后产生，并做出是否放行的决定。上述以“访客”为例，仅是为了方便本领域的技术人员能够了解本发明的思想，不能作为对本发明的具体限定。基于此，可以理解地，计算机系统中，监控事件由服务进程产生，并在服务进程中处理。

前面已经论述，监控数据在服务进程中生成才具有可靠性，在应用进程中生成的监控数据有可能被应用恶意篡改和伪造，不具有可靠性。因此，主监控点必须加在服务进程中，然而某些场景下，不存在服务进程时，主监控点只能加在应用进程中。以Android平台为例，Runtime.exec()用来执行一个外部命令，如要监控这个API，那么主监控点需加在Runtime.exec()的实现中，虽然这部分代码是在Android框架层，但是在应用运行时，这部分代码是运行在应用的进程空间内，因此应用进程可以通过修改自己进程空间的代码和数据的方法，改变Runtime.exec()中监控点的监控逻辑。但Runtime.exec()是本地调用的API，并无IPC，所以也不存在服务进程。因此，这类主监控点只能加在应用进程中。

在本实施例中，主监控点生成的调用信息存在两类来源，一类是在应用进程中生成，另一类是在服务进程中生成。但后者占比越大，监控事件中MID的可信度也就越高，对于污染检测来说准确性也就越高。

需要说明的是，调用信息中，应用触发该主监控点的时间可以为获取到监控点标识MID的时间，因此即使应用是恶意的也无法篡改该时间值。

步骤S102，当某个API被第一应用调用而触发与该某个API对应的主监控点时，获取与该某个API对应的主监控点生成的调用信息；

第一应用调用到系统的某个API时，与该某个API对应的主监控点的代码被触发，此时获取该主监控点生成的调用信息。调用信息至少应包括：第一应用的UID，主监控点被触发的时间，以及该某个API所对应的主监控点的MID。

步骤S103，根据利用各个主监控点生成的调用信息按照UID确定出的第一应用触发各个主监控点的顺序和/或第一应用在一定时间内触发各个主监控点的次数，判断第一应用的监控数据是否存在数据污染。

某一应用在运行过程中，可能要完整一个操作，也可能要完成多个操作，这些一个/多个操作都对应地需要依次调用若干个API序列，应用在运行过程中对于这些API的正常调用顺序可以预先确定，例如通过先正常运行应用，然后从正常应用跑出来的监控数据中提取出相应的特征，转化为规则配置到监控系统中去。

由于一个应用在运行过程中，调用的每个API都被主监控点监控，每个API对应一个主监控点，每个主监控点都有唯一的MID标示，因此具有同一UID标识的应用在运行过程中会触发一系列主监控点，这样，一方面，可以根据各主监控点被触发的时间对应一个MID序列，来判断对应于同一UID标识的MID序列是否和预先确定的MID正常调用顺序一致，当不一致时，说明与该UID标识对应的应用存在监控数据污染。另一方面，可以判断具有同一UID标识的应用在一定时间内触发主监控点的次数是否满足阈值，当不满足时，说明与该UID标识对应的应用存在监控数据污染。

需要说明的是，对于监控点数量的统计，可以按监控事件的MID分类统计，也可以按监控事件总量进行统计。正常的应用在一定时间内，产生监控事件的数量不会超过预设阈值。预设阈值需要通过大量统计和实验，并根据实际的项目需求确定。并且预设阈值越小污染检测也越灵敏，同时误报率也会更高，反之越迟钝，误报率越低。

作为本实施例的一种优选实施方式，针对每个应用，对该应用的每个操作所对应的MID正常调用顺序与主监控点得到的MID序列进行匹配，确定该应用所有操作MID匹配不成功的次数。当匹配不成功的次数超过某一阈值后，则判定该应用在污染监控数据。

以Android平台的使用MediaRecorder录音/录像为例：录音/录像过程中存在关键API调用序列：MediaRecorder.prepare()，MediaRecorder.start()，MediaRecorder.stop()。这三个API如果被监控起来，每一个都会对应一个MID，假设这三个API对应的MID分别为3，7，9。如果一个应用的监控事件队列中出现了3，9，7或者9，3，7之类的序列，就可以认为这是违反常规的监控事件，因为正常的应用不会改变这几个关键API的调用序列，否则无法完成正常的录音或者录像功能。为减少误判，可为该应用设定给一个异常序列累计值，每发现一次异常的监控事件，则将该值加一。当该值超过预设的某一阈值时，可判定为该应用在污染监控数据。

在本实施例的一种实施方式中，步骤S103中，根据利用各个主监控点生成的调用信息确定出的第一应用触发各个主监控点的顺序，判断第一应用的监控数据是否存在数据污染，可以包括：

若第一应用触发各个主监控点的顺序不符合预设关联逻辑，则判断出第一应用的监控数据存在数据污染，其中该预设关联逻辑包括依赖逻辑、超时逻辑、缺失逻辑、顺序逻辑和循环逻辑中的至少一种。

其中，依赖逻辑是指某事件的产生，必先依赖于另一个事件的产生。如果另一事件还没产生，该事件就产生了，则大概率表明存在数据污染。并且这种依赖可以级联，即后发生的事件3可以依赖事件2，事件2又可以依赖先发生的事件1。例如：后产生的监控事件2，必须依赖先前产生的监控事件1。如果事件2单独存在或在事件2之前的一段时间内都未曾出现事件1，则表明该事件是伪造的，存在数据污染的可能性。以Android平台发短信为例，UiccSmsController.sendTextForSubscriber()(事件2)在被触发前，必先触发SmsManager.sendTextMessage()(事件1)。孤立的UiccSmsController.sendTextForSubscriber()事件(事件2)是不存在的。如果出现了孤立的UiccSmsController.sendTextForSubscriber()(事件2)，则可判定为该UiccSmsController.sendTextForSubscriber()事件(事件2)是伪造的。

其中，超时逻辑是指在某些操作中，需要在短时间内一系列API联合操作。这些API分别对应一系列监控事件。这些事件如果不是在短时间内触发完的。那么就存在数据污染的可能。例如：事件A、事件B、…、事件X之间通常是一气呵成的，正常的程序都需要在短时间内触发该序列，如果事件之间的时间超过特定的阈值，则认为该调用序列是伪造的，存在数据污染的可能性。同样以Android平台发短信为例，SmsManager.sendTextMessage()事件被触发后，会立即触发UiccSmsController.sendTextForSubscriber()事件。这两个事件的时间间隔应该不大于0.01秒。如果这两个事件的时间间隔超过了0.01秒，则可判定为存在数据污染的可能性。

其中，缺失逻辑是指在某些操作中，需要依次调用一组API。这些API分别对应一组监控事件。这些事件如果不是在短时间内触发完的，那么就存在数据污染的可能。例如：事件A、事件B、事件C，正常的应用会依次触发ABC，如果序列中依次出现了AC，而中间没有B，则很有可能该监控数据是伪造的。再以Android平台发短信为例，UiccSmsController.sendTextForSubscriber()(事件C)在被触发前，必先触发SmsManager.sendTextMessage()(事件B)。而在SmsManager.sendTextMessage()(事件B)被触发前，一般都会先触发Button.onClick()(事件A)。所以一个完整的发送短信会依次触发以下三个事件：Button.onClick()(事件A)、SmsManager.sendTextMessage()(事件B)、UiccSmsController.sendTextForSubscriber()(事件C)。如果中间缺失了SmsManager.sendTextMessage()(事件B)，则表明可能存在数据污染的行为。

其中，顺序逻辑是指在某些操作中，需要一次按照顺序调用一组API。这些API分别对应一组监控事件。如果顺序出现错误，则表明存在数据污染的可能性。例如：事件A、事件B、事件C，正常的应用会依次触发ABC，如果序列中依次出现了ACB、BAC等由A、B、C组成但非ABC序列的情况，则很有可能该监控数据是伪造的。以Android平台发短信为例，UiccSmsController.sendTextForSubscriber()(事件C)在被触发前，必先触发SmsManager.sendTextMessage()(事件B)。而在SmsManager.sendTextMessage()(事件B)被触发前，一般都会先触发Button.onClick()(事件A)。所以一个完整的发送短信会依次触发以下三个事件：Button.onClick()(事件A)、SmsManager.sendTextMessage()(事件B)、UiccSmsController.sendTextForSubscriber()(事件C)。如果出现了以下序列SmsManager.sendTextMessage((事件B))、Button.onClick()(事件A)、UiccSmsController.sendTextForSubscriber()(事件C)，则表明可能存在数据污染的行为。

其中，循环逻辑是指正常情况下，一个应用的执行序列存在一定的循环规律。若搜集到的监控事件中，毫无规律可循，则表明数据被造假的可能性很大。以Android平台为例，针对同一个Activity的生命周期中，会存在如下序列onCreate()->onStart()->onResume()->onPause()->onStop()->onStart()->onResume()->onPause()->onStop()->….如果事件序列中存在无序的onStop()->onPause()->onPause()->onStart()…则表明存在数据污染。因为一个应用在运行过程中经常执行类似的操作。比如每次打开微信、查看朋友圈、上下滚动刷新列表。下次打开微信还是做类似的操作，这样就形成了一个规律，如果突然某次查看朋友圈的时候，突然又录了一段语音，那么这个录语音就不是很合理，因为录音操作会出现在进入聊天界面操作后出现；如果是先上下滚动朋友圈列表，再打开微信，那么这个顺序上也是不符合逻辑的。

在本实施例的一种实施方式中，步骤S103中，根据利用各个主监控点生成的调用信息确定出的第一应用在一定时间内触发各个主监控点的次数，判断第一应用的监控数据是否存在数据污染，包括：

若各个主监控点在预设条件下被触发的总次数超过特定阈值，则判断出第一应用的监控数据存在数据污染，

在本实施例的一种实施方式中，各个主监控点在预设条件下被触发的总次数，包括：每隔第一预定时间段进行统计时，第一应用在最近的第一预定时间段内触发各个主监控点的总次数。若第一应用触发各个主监控点的总次数超过特定阈值，则判断第一应用的监控数据存在数据污染。

例如，设定一个定时器，每隔T时间，统计每个应用的最近T时间内的监控事件数量M。如果M大于N则表明存在数据污染行为，其中，N为特定阈值。

在本实施例的另一种实施方式中，各个主监控点在预设条件下被触发的总次数，包括：当某主监控点被第一应用触发时，第一应用在触发该某主监控点的时间之前的第二预设时间段内触发各个主监控点的总次数。若第一应用触发各个主监控点的总次数超过特定阈值，则判断所述第一应用的监控数据存在数据污染。

例如，每当一个新的监控事件到来时，检测该事件对应的应用在最近T时间内的监控事件数量M。如果M大于N则表明存在数据污染行为，N为特定阈值。

在本实施例的另一种实施方式中，各个主监控点在预设条件下被触发的总次数，包括：若某主监控点被第一应用触发，则当第一应用未进行过数据污染判断时，或，当第一应用触发该某主监控点的时间与上一次判断第一应用数据污染的时间的差值大于第三预设时间段时，第一应用在触发该某主监控点的时间之前的第三预设时间段内触发各个主监控点的总次数。若第一应用触发各个主监控点的总次数超过特定阈值，则判断第一应用的监控数据存在数据污染。

例如，为每一个应用设置一个检测时间戳，用于生成上一次检测的时间点，其初始值为0。当该应用的新的事件到来时，如果上次检测的时间戳为0或者当前时间减去上次检测的时间戳大于T，则触发一次检测。统计从当前时间开始往前推T时间的所有监控事件，若监控事件数量M超过特定阈值N，则表明存在数据污染行为。最后将当前时间更新到检测时间戳。当该应用的新的事件到来时，如果上次检测时间戳不为0且当前时间距离上次检测时间小于T，则什么都不做。

上述第一种实施方式在事件比较稀疏时，存在重复检测的现象，产生不必要的资源消耗，第二种实施方式在时间比较密集时会触发比较密集的统计，会带来较多的资源消耗，而第三种实施方式克服了第一种和第二种实施方式的缺点。

在本实施方式中，可以按照UID统计第一应用触发各个主监控点的总次数，例如可以统计某UID触发的监控事件总个数；可以统计某UID单位时间内的监控事件个数。

进一步地，本实施例还可以包括：

对至少一个预监控敏感行为发生时调用的各个API还对应设置冗余监控点，，以辅助对应的主监控点进行监控数据污染判断。

在同一调用序列中，在不同的位置，插入不过的主监控点，理论上只要一个主监控点即可标记该API调用，但适当加入一些冗余监控点可以相互印证，因为攻击者如果要攻击，需要把冗余监控点的数据一起污染，同时还需保证污染后的数据具有一致性，难度会增加。另外，在应用进程中插桩的主监控点在产生监控事件时，可以被应用进程伪造，所以需要冗余监控点来帮助辅助鉴别监控事件是否被伪造。

需要说明的是，本实施例的冗余监控点在服务进程或者应用进程都可以进行插桩。

可以理解地，通过冗余监控点辅助判断第一应用的监控数据是否存在数据污染，包括：

若冗余监控点和对应的主监控点产生的调用数据中，UID标识、PID标识和MID标识相同，则当具有该相同UID标识的应用触发主监控点的时间与触发冗余监控点的时间相近时，第一应用的监控数据不存在数据污染；

若事件A、事件B、事件C是一个调用序列中的依次存在的冗余监控点。因此事件A、事件B、事件C必然同时出现，并且是紧挨在一起的，若出现不完整的ABC时间序列，则表明数据是伪造的，第一应用的监控数据存在数据污染；

若在某个API的执行前、执行中、和执行后分别插入3个冗余监控点，显然这三个监控事件要么同时出现，要么同时不出现，如果只出现部分，则表明第一应用的监控数据存在数据污染。

需要说明的是，上述各种数据污染判断算法，每种算法均可以检测数据污染的可能性。为提升数据污染检测准确率和降低误报率，通常采用累加各种算法检测到的可疑污染数据行为的次数，当某应用的可疑数据污染次数超过阈值后，则最终判定该应用存在数据污染行为。

由上述技术方案可知，本实施例通过设置获取每个API调用情况的主监控点，当某应用在运行过程中触发主监控点时，根据获取的所有主监控点的调用信息，确定该应用触发所有主监控点的顺序和/或在一定时间内触发主监控点的次数，进而判断该应用的监控数据是否存在数据污染，克服了现有技术中当虚假构造监控数据时，直接利用监控数据判断应用是否恶意所存在的恶意行为无法识别和恶意行为判定不准确问题，本方法能准确判断主监控点的数据是否由恶意应用伪造而来，确保监控系统的监控质量，保证应用后续敏感行为判断的真实性，提前感知可能的异常和入侵。

【方法实施例2】

本实施例提供了一种对监控数据进行污染判断的方法，用于判断应用的某一进程的监控数据是否出现数据污染，参考图2，该方法包括：

步骤S201，对至少一个预监控敏感行为发生时调用的各个API对应设置主监控点，每个主监控点用于在对应的API被调用时生成调用信息，该调用信息包括对应的主监控点的标识MID、触发该对应的主监控点的应用的用户标识UID和进程标识PID、以及该应用触发与该对应的主监控点的时间；

步骤S202，当某个API被第一应用调用而触发与该某个API对应的主监控点时，获取与该某个API对应的主监控点生成的调用信息；

步骤S203，根据利用各个主监控点生成的调用信息按照PID确定出的第一应用触发各个特定主监控点的顺序和/或第一应用在一定时间内触发各个特定主监控点的次数，判断第一应用的特定进程的监控数据是否出现数据污染，

其中，特定主监控点为所有主监控点中，生成的调用信息所包含的第一应用的用户标识和进程标识均相同的监控点，另外特定进程为与特定主监控点对应的进程。

需要说明的是，本实施例中主监控点的设置、主监控点调用信息的获取的原理、特定主监控点触发顺序的确定以及一定时间内特定主监控点触发次数的确定的原理与上述方法实施例1中主监控点的设置、主监控点调用信息的获取、主监控点触发顺序的确定以及一定时间内主监控点触发次数的确定的原理分别相同，在此不再赘述，不同的是，每个主监控点生成的调用信息还包括触发该主监控点的应用的进程标识PID，该进程标识用于确定某被污染的应用中，具体是哪个进程出现异常。本实施例确定触发顺序以及确定一定时间内触发次数所针对的对象不同，实施例1是指与各个API对应的主监控点，而本实施例是指与各个API对应的主监控点中，生成的调用信息所包含的第一应用的用户标识和进程标识均相同的主监控点，为特定主监控点，它们是第一应用的同一进程。

本实施例通过判断各个主监控点生成的调用信息中，对应于同一UID标识、同一PID标识的MID顺序是否正确，以及对应于同一UID标识、同一PID标识的MID在一定时间内的总个数，来确定对应于同一UID标识、同一PID标识的第一应用的特定进程是否出现数据污染。

详细地，某应用通常完成某一操作，需要依次调用若干API序列，这些API的MID正常调用顺序可以预先确定。由于每个API又都被主监控点监控，每个API对应一个主监控点，每个监控点都有唯一的MID标示，因此具有同一UID标识和同一PID的应用进程在运行过程会触发一系列主监控点，根据各主监控点的触发时间对应一个MID序列，判断对应于同一UID标识和同一PID的MID序列是否和预先确定的MID正常调用顺序一致，当不一致时，说明与该PID和UID标识对应的应用进程存在监控数据污染；判断对应于同一UID标识和同一PID的MID序列在一定时间内触发的主监控点次数超过特定阈值，当超过时，说明与该PID和UID标识对应的应用进程存在监控数据污染。

作为示例：例如发送短信操作，需要很多步才能完成，抽取其中的三步：点击发送按钮、调用SmsManager发送短信、ISMS服务响应，这三步对应的API依次为Button.onCllick()、SmsManager.sendTextMessage()、UiccSmsController.sendTextForSubscriber()。假设这三个API的监控点MID的正常调用顺序分别为：3、7、9。而现在某PID队列中的MID序列为：1、2、10、3、5、7、9、11。则后者中含有子序列3、7、9，因此逻辑匹配通过。又例如，若某PID序列中的MID序列为：1、2、10、3、9、10、5、7、11。虽然该序列中含有3、7、9，但顺序不正确，因此匹配不成功。因为从理论上说，很短的时间内先触发UiccSmsController.sendTextForSubscriber()，再触发SmsManager.sendTextMessage()是不可能的。

在本实施例的一种实施方式中，步骤S203中，根据利用各个主监控点生成的调用信息确定出的第一应用触发各个特定主监控点的顺序，判断第一应用的特定进程的监控数据是否出现数据污染，包括：

若第一应用触发各个特定主监控点的顺序不符合预设关联逻辑，则判断第一应用的特定进程的监控数据存在数据污染，其中预设关联逻辑包括依赖逻辑、超时逻辑、缺失逻辑、顺序逻辑和循环逻辑中的至少一种。

其中，依赖逻辑是指某事件的产生，必先依赖于另一个事件的产生。如果另一事件还没产生，该事件就产生了，则大概率表明存在数据污染。并且这种依赖可以级联，即后发生的事件3可以依赖事件2，事件2又可以依赖先发生的事件1。例如：后产生的监控事件2，必须依赖先前产生的监控事件1。如果事件2单独存在或在事件2之前的一段时间内都未曾出现事件1，则表明该事件是伪造的，存在数据污染的可能性。以Android平台发短信为例，UiccSmsController.sendTextForSubscriber()(事件2)在被触发前，必先触发SmsManager.sendTextMessage()(事件1)。孤立的UiccSmsController.sendTextForSubscriber()事件(事件2)是不存在的。如果出现了孤立的UiccSmsController.sendTextForSubscriber()(事件2)，则可判定为该UiccSmsController.sendTextForSubscriber()事件(事件2)是伪造的。

其中，超时逻辑是指在某些操作中，需要在短时间内一系列API联合操作。这些API分别对应一系列监控事件。这些事件如果不是在短时间内触发完的。那么就存在数据污染的可能。例如：事件A，事件B…，事件X，之间通常是一气呵成的，正常的程序都需要在短时间内触发该序列，如果事件之间的时间超过特定的阈值，则认为该调用序列是伪造的，存在数据污染的可能性。同样以Android平台发短信为例，SmsManager.sendTextMessage()事件被触发后，会立即触发UiccSmsController.sendTextForSubscriber()事件。这两个事件的时间间隔应该不大于0.01秒。如果这两个事件的时间间隔超过了0.01秒，则可判定为存在数据污染的可能性。

其中，缺失逻辑是指在某些操作中，需要依次调用一组API。这些API分别对应一组监控事件。这些事件如果不是在短时间内触发完的，那么就存在数据污染的可能。例如：事件A，事件B，事件C，正常的应用会依次触发ABC，如果序列中依次出现了AC，而中间没有B，则很有可能该监控数据是伪造的。再以Android平台发短信为例，UiccSmsController.sendTextForSubscriber()(事件C)在被触发前，必先触发SmsManager.sendTextMessage()(事件B)。而在SmsManager.sendTextMessage()(事件B)被触发前，一般都会先触发Button.onClick()(事件A)。所以一个完整的发送短信会依次触发以下三个事件：Button.onClick()(事件A)、SmsManager.sendTextMessage()(事件B)、UiccSmsController.sendTextForSubscriber()(事件C)。如果中间缺失了SmsManager.sendTextMessage()(事件B)，则表明可能存在数据污染的行为。

其中，顺序逻辑是指在某些操作中，需要一次按照顺序调用一组API。这些API分别对应一组监控事件。如果顺序出现错误，则表明存在数据污染的可能性。例如：事件A，事件B，事件C，正常的应用会依次触发ABC，如果序列中依次出现了ACB、BAC等由A、B、C组成但非ABC序列的情况，则很有可能该监控数据是伪造的。以Android平台发短信为例，UiccSmsController.sendTextForSubscriber()(事件C)在被触发前，必先触发SmsManager.sendTextMessage()(事件B)。而在SmsManager.sendTextMessage()(事件B)被触发前，一般都会先触发Button.onClick()(事件A)。所以一个完整的发送短信会依次触发以下三个事件：Button.onClick()(事件A)、SmsManager.sendTextMessage()(事件B)、UiccSmsController.sendTextForSubscriber()(事件C)。如果出现了以下序列SmsManager.sendTextMessage((事件B))、Button.onClick()(事件A)、UiccSmsController.sendTextForSubscriber()(事件C)，则表明可能存在数据污染的行为。

其中，事件循环出现是指正常情况下，一个应用的执行序列存在一定的循环规律。若搜集到的监控事件中，毫无规律可循，则表明数据被造假的可能性很大。以Android平台为例，针对同一个Activity的生命周期中，会存在如下序列onCreate()->onStart()->onResume()->onPause()->onStop()->onStart()->onResume()->onPause()->onStop()->….如果事件序列中存在无序的onStop()->onPause()->onPause()->onStart()…则表明存在数据污染。因为一个应用在运行过程中经常执行类似的操作。比如每次打开微信、查看朋友圈、上下滚动刷新列表。下次打开微信还是做类似的操作，这样就形成了一个规律，如果突然某次查看朋友圈的时候，突然又录了一段语音，那么这个录语音就不是很合理；录音操作会出现在进入聊天界面操作后出现；如果是先上下滚动朋友圈列表，再打开微信，那么这个顺序上也是不符合逻辑的。

在本实施例的一种实施方式中，步骤S203中，根据利用各个主监控点生成的调用信息确定出的第一应用在一定时间内触发各个特定主监控点的次数，判断第一应用的特定进程的监控数据是否出现数据污染，包括：

若各个特定主监控点在预设条件下被触发的总次数超过特定阈值，则判断出第一应用的特定进程的监控数据存在数据污染，

较佳地，各个特定主监控点在预设条件下被触发的总次数，可以包括：每隔第一预定时间段进行统计时，第一应用在最近的第一预定时间段内触发各个特定主监控点的总次数。判断确定的总次数是否超过特定阈值，若超过，则判断出第一应用的特定进程的监控数据存在数据污染。

例如，设定一个定时器，每隔T时间，统计每个应用的最近T时间内的监控点数量M。如果M大于N则表明存在数据污染行为，N为阈值。

同样较佳地，各个特定主监控点在预设条件下被触发的总次数，还可以包括：当某特定主监控点被第一应用触发时，第一应用在触发特定主监控点的时间之前的第二预设时间段内触发各个特定主监控点的总次数。若第一应用触发各个特定主监控点的总次数超过特定阈值，则判断出第一应用的特定进程存在监控数据污染。

例如，每当一个新的监控事件到来时，检测该事件对应的应用在最近T时间内的监控事件数量M。如果M大于N则表明存在数据污染行为，N为阈值。

较佳地，各个特定主监控点在预设条件下被触发的总次数，还可以包括：若某监控点被第一应用触发，则当第一应用未进行过数据污染判断时，或，当第一应用触发特定主监控点的时间与上次判断第一应用数据污染的时间的差值大于第三预设时间段时，第一应用在触发特定主监控点的时间之前的第三预设时间段内触发各个特定主监控点的总次数。若第一应用触发各个特定主监控点的总次数超过监控点触发次数阈值，则判断出第一应用的特定进程存在监控数据污染。

例如，为每一个应用设置一个检测时间戳，用于生成上一次检测的时间点，其初始值为0。当该应用的新的事件到来时，如果上次检测的时间戳为0或者当前时间减去上次检测的时间戳大于T，则触发一次检测。统计从当前时间开始往前推T时间的所有监控事件，若监控事件数量M超过阈值N则表明存在数据污染行为。最后将当前时间更新到检测时间戳。当该应用的新的事件到来时，如果上次检测时间戳不为0且当前时间距离上次检测时间小于T，则什么都不做。

上述第一种方法在事件比较稀疏时，存在重复检测的现象，产生不必要的资源消耗，第二种方法在时间比较密集时会触发比较密集的统计，会带来较多的资源消耗，而第三种方法克服了第一种方法和第二种方法的缺点。

在本实施方式中，可以按照UID或PID统计第一应用触发各个监控点的总次数，例如可以统计某PID触发的监控事件总个数；可以统计某PID单位时间内监控事件个数；可以统计某UID或PID所触发的各MID的监控事件总个数；可以统计某UID或PID在单位时间内所触发的各MID的监控事件总个数。

在本实施例的一种实施方式中，该方法还包括：

对至少一个预监控敏感行为发生时调用的各个API还对应设置冗余监控点，以辅助对应的主监控点进行监控数据污染判断。

其中，通过冗余监控点辅助判断第一应用的特定进程是否存在监控数据污染，包括：

若冗余监控点和对应的特定主监控点产生的调用数据中，UID标识、PID标识和MID标识相同，而具有该相同UID标识的应用触发特定主监控点的时间与触发对应冗余监控点的时间相近，则第一应用的特定进程不存在监控数据污染；

若事件A、事件B、事件C是一个调用序列中的依次存在的冗余监控点。因此事件A、事件B、事件C必然同时出现，并且是紧挨在一起的，若出现不完整的ABC时间序列，则表明数据是伪造的，第一应用的特定进程存在监控数据污染；

若在某个API的执行前、执行中、和执行后分别插入3个冗余监控点，显然这三个监控事件要么同时出现，要么同时不出现，如果只出现部分，则第一应用的特定进程存在监控数据污染。

需要说明的是，上述各种数据污染判断算法，每种算法可以检测数据污染的可能性。为提升数据污染检测准确率和降低误报率，通常采用累加各种算法检测到的可疑污染数据行为的次数，当某第一应用中与特定主监控点对应的进程的可疑数据污染次数超过阈值后，则最终判定第一应用中与特定主监控点对应的进程存在数据污染行为。

可以理解地，可以将监控事件先按应用的UID进行分类，然后针对每个UID的监控事件，再进一步按照PID细分。每个PID分类，通过线性表按监控事件的时间顺序组织在一起。这也就需要给每个监控事件加上时间戳。时间戳为获取到主监控点的调用信息的时间。在每个以PID分类的线性表中，所有监控事件按照时间戳排序。每个监控事件队列设有最大值，当队列满时，最老的事件自动出队，最新的事件加入到队尾。队列可采用ring buffer实现。监控事件组织结构如图2A。

本实施例在根据监控点生成的调用数据判断应用是否为恶意应用之前，先判断该监控点生成的调用数据是否真实，是否由恶意应用伪造而来，以防止被污染的数据影响监控结果。如发现监控数据是正常的数据，则放行这些监控数据，让监控模块直接处理；如发现监控数据不真实，存在伪造的可能性，则可以采取相应的策略来应对：丢弃伪造的监控数据，并向监控模块报告其虚假行为；向处理模块报告该应用的伪造行为，让处理模块来对其进行处理，可能的处理手段有杀死其进程、禁用或卸载其应用。

【装置实施例1】

本实施例提供了一种对监控数据进行污染判断的装置，用于判断应用的监控数据是否出现数据污染，参考图3，该装置包括：

主监控点设置模块301，用于对至少一个预监控敏感行为发生时调用的各个API对应设置主监控点，每个主监控点用于在对应的API被调用时生成调用信息，调用信息包括对应的主监控点的标识、触发对应的主监控点的应用的用户标识，以及应用触发对应的主监控点的时间；

调用信息获取模块302，用于当某个API被第一应用调用而触发与某个API对应的主监控点时，获取与某个API对应的主监控点生成的调用信息；

第一污染判断模块303，用于根据利用各个主监控点生成的调用信息确定出的第一应用触发各个主监控点的顺序和/或第一应用在一定时间内触发各个主监控点的次数，判断第一应用的监控数据是否存在数据污染。

进一步地，该主监控点设置模块301设置主监控点的规则包括：

对于任一API的主监控点，当既能在对应的应用进程中插桩，又能在对应的服务进程中插桩时，或者仅能在对应的服务进程中插桩时，主监控点的插桩点位于对应的服务进程；当仅能在对应的应用进程中插桩时，主监控点的插桩点位于对应的应用进程。

进一步地，第一污染判断模块303具体包括：

触发顺序-污染判断单元，用于若第一应用触发各个主监控点的顺序不符合预设关联逻辑，则判断出第一应用的监控数据存在数据污染，

其中，预设关联逻辑包括依赖逻辑、超时逻辑、缺失逻辑、顺序逻辑和循环逻辑中的至少一种。

进一步地，第一污染判断模块303具体包括：

触发次数-污染判断单元，用于若各个主监控点在预设条件下被触发的总次数超过特定阈值，则判断出第一应用的监控数据存在数据污染，

其中，各个主监控点在预设条件下被触发的总次数，包括：

每隔第一预定时间段进行统计时，第一应用在最近的第一预定时间段内触发各个主监控点的总次数；和/或，

当某主监控点和/或某特定主监控点被第一应用触发时，第一应用在触发某主监控点的时间之前的第二预设时间段内触发各个主监控点的总次数；和/或，

若某主监控点被第一应用触发，则当第一应用的监控数据未进行过污染判断时，或，当第一应用触发某监控点的时间与上一次第一应用监控数据污染判断时间的差值大于第三预设时间段时，第一应用在触发某主监控点的时间之前的第三预设时间段内触发各个监控点的总次数。

需要说明的是，本装置可以位于监控点与原监控模块之间，或者集成在原监控模块上。本实施例通过主监控点设置模块301设置获取每个API调用情况的主监控点，当某应用在运行过程中触发主监控点时，第一污染判断模块303根据获取的所有主监控点的调用信息，确定该应用触发所有主监控点的顺序和/或在一定时间内触发主监控点的次数，进而判断该应用的监控数据是否存在数据污染，克服了现有技术中当虚假构造监控数据时，直接利用监控数据判断应用是否恶意所存在的恶意行为无法识别和恶意行为判定不准确问题，本方法能准确判断主监控点的数据是否由恶意应用伪造而来，确保监控系统的监控质量，保证应用后续敏感行为判断的真实性，提前感知可能的异常和入侵。

【装置实施例2】

本实施例提供了一种对监控数据进行污染判断的装置，用于判断应用的某一进程的监控数据是否出现数据污染，参考图4，该装置包括：

主监控点设置模块401，用于对至少一个预监控敏感行为发生时调用的各个API对应设置主监控点，每个主监控点用于在对应的API被调用时生成调用信息，所述调用信息包括对应的主监控点的标识、触发所述对应的主监控点的应用的用户标识和进程标识，以及所述应用触发所述对应的主监控点的时间；

调用信息获取模块402，用于当某个API被第一应用调用而触发与所述某个API对应的主监控点时，获取与所述某个API对应的主监控点生成的调用信息；

第一污染判断模块403，用于根据利用各个主监控点生成的调用信息通过UID确定出的所述第一应用触发各个主监控点的顺序和/或所述第一应用在一定时间内触发各个主监控点的次数，判断所述第一应用的监控数据是否存在数据污染；

第二污染判断模块404，用于根据利用各个主监控点生成的调用信息通过PID确定出的第一应用触发各个特定主监控点的顺序和/或第一应用在一定时间内触发各个特定主监控点的次数，判断第一应用的特定进程的监控数据是否存在数据污染，其中，特定主监控点为所有主监控点中，生成的调用信息所包含的第一应用的用户标识和进程标识均相同的监控点，该特定进程为与特定主监控点对应的进程。

进一步地，该主监控点设置模块401设置主监控点的规则包括：

对于任一API的主监控点，当既能在对应的应用进程中插桩，又能在对应的服务进程中插桩时，或者仅能在对应的服务进程中插桩时，所述主监控点的插桩点位于对应的服务进程；当仅能在对应的应用进程中插桩时，所述主监控点的插桩点位于对应的应用进程。

该第一污染判断模块403和/或第二污染判断模块404具体包括：

触发顺序-污染判断单元，用于若第一应用触发各个主监控点和/或特定主监控点的顺序不符合预设关联逻辑，则判断出第一应用的监控数据和/或第一应用的特定进程的监控数据存在数据污染，其中，预设关联逻辑包括依赖逻辑、超时逻辑、缺失逻辑、顺序逻辑和循环逻辑中的至少一种。

进一步地，第一污染判断模块403和/或第二污染判断模块404具体包括：

触发次数-污染判断单元，用于若各个主监控点和/或各个特定主监控点在预设条件下被触发的总次数超过特定阈值，则判断出第一应用的监控数据和/或第一应用的特定进程的监控数据存在数据污染，其中，各个主监控点和/或各个特定主监控点在预设条件下被触发的总次数，包括：

每隔第一预定时间段进行统计时，第一应用在最近的第一预定时间段内触发各个主监控点和/或各个特定主监控点的总次数；和/或，

当某主监控点和/或某特定主监控点被所述第一应用触发时，第一应用在触发某主监控点和/或某特定主监控点的时间之前的第二预设时间段内触发各个主监控点和/或各个特定主监控点的总次数；和/或，

若某主监控点和/或某特定主监控点被所述第一应用触发，则当第一应用的监控数据未进行过污染判断时，或，当第一应用触发某监控点和/或某特定主监控点的时间与上一次第一应用监控数据污染判断时间的差值大于第三预设时间段时，第一应用在触发某主监控点和/或某特定主监控点的时间之前的第三预设时间段内触发各个监控点和/或各个特定主监控点的总次数。

需要说明的是，本装置可以位于监控点与原监控模块之间，或者集成在原监控模块上。本实施例通过主监控点设置模块401设置获取每个API调用情况的主监控点，当某应用在运行过程中触发主监控点时，第二污染判断模块404根据获取的所有主监控点的调用信息，确定该应用触发所有特定主监控点的顺序和/或在一定时间内触发特定主监控点的次数，进而判断该应用的特定进程的监控数据是否存在数据污染，克服了现有技术中无法判断监控数据污染应用中具体哪个进程出现异常的问题，本方法能准确判断主监控点的对应进程的数据是否由恶意应用伪造而来，确保监控系统的监控质量，保证应用后续敏感行为判断的真实性，提前感知可能的异常和入侵。

本发明实施例又提供了一种计算机设备，包括处理器以及用于存放计算机程序的存储器，该处理器用于执行存储器上所存放的计算机程序，以实现前文提及的任一对监控数据进行污染判断的方法，或者，以实现前文提及的任一对监控数据进行污染判断的装置所执行的处理。

此外，本发明实施例再提供了一种计算机存储介质，该计算机存储介质内存储有计算机程序，其中计算机程序被处理器执行时实现前文提及的任一对监控数据进行污染判断的方法，或者，实现前文提及的任一对监控数据进行污染判断的装置所执行的处理。

上述存储介质和计算机设备，由于实现了上述对监控数据进行污染判断的方法，同理能准确判断主监控点所对应的应用及进程的监控数据是否由恶意应用伪造而来，确保监控系统的监控质量，保证应用后续敏感行为判断的真实性，提前感知可能的异常和入侵。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同及相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置设备实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。

本领域的技术人员可以清楚地了解到本发明可全部通过软件实现，也可借助软件结合硬件平台的方式来实现。基于这样的理解，本发明的技术方案对背景技术做出贡献的全部或者部分可以以软件产品的形式体现出来，所述计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、智能手机或者网络设备等)执行本发明各个实施例或实施例的某些部分所述的方法。

本文中所使用的“软件”等词均指一般意义上的任意类型的计算机编码或者计算机可执行指令集，可以运行所述编码或者指令集来使计算机或其他处理器程序化以执行如上所述的本发明的技术方案的各个方面。此外，需要说明的是，根据实施例的一个方面，在执行时实施本发明的技术方案的方法的一个或多个计算机程序不必须要在一台计算机或处理器上，而是可以分布于多个计算机或者处理器中的模块中，以执行本发明的技术方案的各个方面。

计算机可执行指令可以有许多形式，如程序模块，可以由一台或多台计算机或是其他设备执行。一般地，程序模块包括例程、程序、对象、组件以及数据结构等等，执行特定的任务或是实施特定的抽象数据类型。特别地，在各种实施例中，程序模块进行的操作可以根据各个不同实施例的需要进行结合或者拆分。

并且，本发明的技术方案可以体现为一种方法，并且已经提供了所述方法的至少一个示例。可以通过任何一种合适的顺序执行动作，所述动作表现为所述方法中的一部分。因此，实施例可以构造成可以按照与所示出的执行顺序不同的顺序执行动作，其中，可以包括同时地执行一些动作(尽管在示出的实施例中，这些动作是连续的)。

在本发明的各个具体实施例中，所描述的特征、架构或功能可在一个或一个以上实施例中以任何方式组合，其中众所周知的操作过程、程序模块、单元及其相互之间的连接、链接、通信或操作没有示出或未作详细说明。本领域技术人员应当理解，下述的各种实施例只用于举例说明，而非用于限制本发明的保护范围。本领域的技术人员还可以容易理解，本文所述和附图所示的各实施例中的程序模块、单元或步骤可以按多种不同配置进行组合和设计。

对于未在本说明书中进行具体说明的技术术语，除非另有特定说明，都应以本领域最为宽泛的意思进行解释。本文所给出的和使用的定义，应当对照字典、通过引用而并入的文档中的定义、和/或其通常意思进行理解。本文使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。

在权利要求书中以及上述的说明书中，所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项的任何或者所有可能组合。应当理解，尽管在本文可能采用术语第一、第二、第三等来描述各种信息和/或模块，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息和/或模块彼此区分开。例如，在不脱离本文范围的情况下，第一信息和/或模块也可以被称为第二信息和/或模块，类似地，第二信息和/或模块也可以被称为第一信息和/或模块。另外，在此所使用的词语“如果”，其意思取决于语境，可以被解释成为“在……时”或“当……时”或“响应于确定”。

在权利要求书中以及上述的说明书中，所有的过度短语，例如“包括”、“具有”、“包含”、“承载”、“具有”、“涉及”、“主要由…组成”以及其任何其它变体是应理解为是开放式的，即，包含但不限于，意在涵盖非排它性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其它要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句"包括一个……"限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本发明说明书中使用的术语和措辞仅仅为了举例说明，并不意味构成限定。本领域技术人员应当理解，在不脱离所公开的实施例的基本原理的前提下，对上述实施例中的各细节可进行各种变化。因此，本发明的范围只由权利要求确定，在权利要求中，除非另有说明，所有的术语应按最宽泛合理的意思进行理解。

Claims (13)

1.一种对监控数据进行污染判断的方法，包括：

对至少一个预监控敏感行为发生时调用的各个API对应设置主监控点，每个主监控点用于在对应的API被调用时生成调用信息，所述调用信息包括对应的主监控点的标识、触发所述对应的主监控点的应用的用户标识，以及所述应用触发所述对应的主监控点的时间；

当某个API被第一应用调用而触发与所述某个API对应的主监控点时，获取与所述某个API对应的主监控点生成的调用信息；

根据利用各个主监控点生成的调用信息确定出的所述第一应用触发各个主监控点的顺序和/或所述第一应用在一定时间内触发各个主监控点的次数，判断所述第一应用的监控数据是否存在数据污染。

2.如权利要求1所述的对监控数据进行污染判断的方法，其特征在于，所述主监控点的设置规则包括：

对于任一API的主监控点，当既能在对应的应用进程中插桩，又能在对应的服务进程中插桩时，或者仅能在对应的服务进程中插桩时，所述主监控点的插桩点位于对应的服务进程；当仅能在对应的应用进程中插桩时，所述主监控点的插桩点位于对应的应用进程。

3.如权利要求1或2所述的对监控数据进行污染判断的方法，其特征在于，所述调用信息还包括触发所述对应的主监控点的应用的进程标识，

所述方法还包括：

根据利用各个主监控点生成的调用信息确定出的所述第一应用触发各个特定主监控点的顺序和/或所述第一应用在一定时间内触发各个特定主监控点的次数，判断所述第一应用的特定进程的监控数据是否存在数据污染；

其中，所述特定主监控点为所有主监控点中，生成的调用信息所包含的第一应用的用户标识和进程标识均相同的监控点，所述特定进程为与所述特定主监控点对应的进程。

4.如权利要求3所述的对监控数据进行污染判断的方法，其特征在于，所述根据利用各个主监控点生成的调用信息确定出的所述第一应用触发各个主监控点和/或特定主监控点的顺序，判断所述第一应用的监控数据和/或所述第一应用的特定进程的监控数据是否存在数据污染，包括：

若所述第一应用触发各个主监控点和/或特定主监控点的顺序不符合预设关联逻辑，则判断出所述第一应用的监控数据和/或所述第一应用的特定进程的监控数据存在数据污染，

其中，所述预设关联逻辑包括依赖逻辑、超时逻辑、缺失逻辑、顺序逻辑和循环逻辑中的至少一种。

5.如权利要求3所述的对监控数据进行污染判断的方法，其特征在于，所述根据利用各个主监控点生成的调用信息确定出的所述第一应用在一定时间内触发各个主监控点和/或特定主监控点的次数，判断所述第一应用的监控数据和/或所述第一应用的特定进程的监控数据是否存在数据污染，包括：

若所述各个主监控点和/或各个特定主监控点在预设条件下被触发的总次数超过特定阈值，则判断出所述第一应用的监控数据和/或所述第一应用的特定进程的监控数据存在数据污染，

其中，所述各个主监控点和/或各个特定主监控点在预设条件下被触发的总次数，包括：

每隔第一预定时间段进行统计时，所述第一应用在最近的第一预定时间段内触发各个主监控点和/或各个特定主监控点的总次数；和/或，

当某主监控点和/或某特定主监控点被所述第一应用触发时，所述第一应用在触发所述某主监控点和/或所述某特定主监控点的时间之前的第二预设时间段内触发各个主监控点和/或各个特定主监控点的总次数；和/或，

若所述某主监控点和/或某特定主监控点被所述第一应用触发，则当所述第一应用的监控数据未进行过污染判断时，或，当所述第一应用触发所述某监控点和/或所述某特定主监控点的时间与上一次第一应用监控数据污染判断时间的差值大于第三预设时间段时，所述第一应用在触发所述某主监控点和/或所述某特定主监控点的时间之前的第三预设时间段内触发各个监控点和/或各个特定主监控点的总次数。

6.如权利要求3所述的对监控数据进行污染判断的方法，其特征在于，还包括：

对至少一个预监控敏感行为发生时调用的各个API还对应设置冗余监控点，以辅助对应的主监控点进行监控数据污染判断。

7.一种对监控数据进行污染判断的装置，包括：

主监控点设置模块，用于对至少一个预监控敏感行为发生时调用的各个API对应设置主监控点，每个主监控点用于在对应的API被调用时生成调用信息，所述调用信息包括对应的主监控点的标识、触发所述对应的主监控点的应用的用户标识，以及所述应用触发所述对应的主监控点的时间；

调用信息获取模块，用于当某个API被第一应用调用而触发与所述某个API对应的主监控点时，获取与所述某个API对应的主监控点生成的调用信息；

第一污染判断模块，用于根据利用各个主监控点生成的调用信息确定出的所述第一应用触发各个主监控点的顺序和/或所述第一应用在一定时间内触发各个主监控点的次数，判断所述第一应用的监控数据是否存在数据污染。

8.如权利要求7所述的对监控数据进行污染判断的装置，其特征在于，所述主监控点设置模块设置主监控点的规则包括：

对于任一API的主监控点，当既能在对应的应用进程中插桩，又能在对应的服务进程中插桩时，或者仅能在对应的服务进程中插桩时，所述主监控点的插桩点位于对应的服务进程；当仅能在对应的应用进程中插桩时，所述主监控点的插桩点位于对应的应用进程。

9.如权利要求6或7所述的对监控数据进行污染判断的装置，其特征在于，所述调用信息还包括触发所述对应的主监控点的应用的进程标识，

所述装置还包括：

第二污染判断模块，用于根据利用各个主监控点生成的调用信息确定出的所述第一应用触发各个特定主监控点的顺序和/或所述第一应用在一定时间内触发各个特定主监控点的次数，判断所述第一应用的特定进程的监控数据是否存在数据污染；

其中，所述特定主监控点为所有主监控点中，生成的调用信息所包含的第一应用的用户标识和进程标识均相同的监控点，所述特定进程为与所述特定主监控点对应的进程。

10.如权利要求9所述的对监控数据进行污染判断的装置，其特征在于，所述第一污染判断模块和/或所述第二污染判断模块具体包括：

触发顺序-污染判断单元，用于若所述第一应用触发各个主监控点和/或特定主监控点的顺序不符合预设关联逻辑，则判断出所述第一应用的监控数据和/或所述第一应用的特定进程的监控数据存在数据污染，

其中，所述预设关联逻辑包括依赖逻辑、超时逻辑、缺失逻辑、顺序逻辑和循环逻辑中的至少一种。

11.如权利要求9所述的对监控数据进行污染判断的装置，其特征在于，所述第一污染判断模块和/或所述第二污染判断模块具体包括：

触发次数-污染判断单元，用于若所述各个主监控点和/或各个特定主监控点在预设条件下被触发的总次数超过特定阈值，则判断出所述第一应用的监控数据和/或所述第一应用的特定进程的监控数据存在数据污染，

其中，所述各个主监控点和/或各个特定主监控点在预设条件下被触发的总次数，包括：

每隔第一预定时间段进行统计时，所述第一应用在最近的第一预定时间段内触发各个主监控点和/或各个特定主监控点的总次数；和/或，

当某主监控点和/或某特定主监控点被所述第一应用触发时，所述第一应用在触发所述某主监控点和/或所述某特定主监控点的时间之前的第二预设时间段内触发各个主监控点和/或各个特定主监控点的总次数；和/或，

若所述某主监控点和/或某特定主监控点被所述第一应用触发，则当所述第一应用的监控数据未进行过污染判断时，或，当所述第一应用触发所述某监控点和/或所述某特定主监控点的时间与上一次第一应用监控数据污染判断时间的差值大于第三预设时间段时，所述第一应用在触发所述某主监控点和/或所述某特定主监控点的时间之前的第三预设时间段内触发各个监控点和/或各个特定主监控点的总次数。

12.一种计算机设备，包括：

处理器；以及

用于存放计算机程序的存储器，

其特征在于，所述处理器用于执行所述存储器上所存放的计算机程序，以实现权利要求1至6中任一项权利要求所述的对监控数据进行污染判断的方法。

13.一种计算机存储介质，其特征在于，所述计算机存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现权利要求1至6中任一项权利要求所述的对监控数据进行污染判断的方法。