一种检测APP更新过程中安全性的方法以及检测装置与流程

本发明属于app更新领域，更具体地，涉及一种检测app更新过程中安全性的方法以及检测装置。

背景技术：

随着移动互联网的飞速发展，人们越来越喜欢在手机上安装各类应用程序(application，简写为app)，当一个app发布之后，突然发现了一个严重bug需要进行紧急修复，如果重新发布新版本的app，肯定要付出巨大的成本，也会影响用户体验，为了避免前述问题，热补丁动态修复技术应运而生。热补丁动态修复技术，通过向用户下发补丁包，在用户无感知的情况下修复app中的问题。

不过，热更新技术虽然带来了便利，但也存在安全隐患，app的补丁包是存在于网络流量中的，如果传输app补丁包的流量不加密，并且app不对补丁包做校验，那么如果有人从中间篡改补丁包中的代码，app安装补丁包之后就会执行这些被修改的代码，后果不堪设想。

鉴于此，克服该现有技术所存在的缺陷是本技术领域亟待解决的问题。

技术实现要素：

针对现有技术的以上缺陷或改进需求，本发明提供了一种检测app更新过程中安全性的方法以及检测装置，其目的在于采用本发明的方法可以确定不安全的补丁包，一方面便于提醒用户某些补丁包可能存在安全隐患；另一方面，可以将存在安全隐患的补丁包上报给开发者或者厂商，以督促进行改善。

为实现上述目的，按照本发明的一个方面，提供了一种检测app更新过程中安全性的方法，所述检测app更新过程中安全性的方法包括：

获取用于更新的补丁包；

在所述补丁包中插入测试代码；

采用修改过的补丁包更新对应的app，运行更新后的app以进行测试；

获取测试结果，当所述测试结果中存在与所述测试代码相匹配的标识时，标记所述app在更新过程中存在安全隐患。

优选地，所述获取用于更新的补丁包之后，在所述补丁包中插入测试代码之前包括：

识别所述补丁包的更新框架，根据所述补丁包的更新框架，初步判断所述补丁包是否存在潜在安全隐患；

若所述补丁包存在潜在安全隐患，则执行在所述补丁包中插入测试代码。

优选地，识别所述补丁包的更新框架，根据所述补丁包的更新框架，初步判断所述补丁包是否存在潜在安全隐患包括：

分析携带所述补丁包的流量中是否存在安全校验；

若流量中不存在安全校验，则所述补丁包存在潜在安全隐患；

若流量中存在安全校验，则进一步分析所述安全校验存在的方式；

若所述安全校验是明文，则所述补丁包存在潜在安全隐患。

优选地，所述检测app更新过程中安全性的方法还包括：

将在更新过程中存在安全隐患的app上报给用户或厂商，以便督导厂商对存在安全隐患的app进行整改。

优选地，所述检测app更新过程中安全性的方法还包括：

获取测试结果，当所述测试结果中不存在与所述测试代码相匹配的标识时，标记所述app在更新过程中不存在安全隐患；

识别不存在安全隐患的app的开发商，将不存在安全隐患的app与其相对应的开发商建立映射关系，并存储至预设的检查表中，以便通过所述检查表确定app在更新过程中是否具有安全隐患。

优选地，所述获取用于更新的补丁包之后，在所述补丁包中插入测试代码之前包括：

识别所述补丁包对应的app的开发商；

遍历所述检查表，判断所述补丁包对应的app的开发商是否存在于所述检查表中；

若存在，则标记所述补丁包不具有安全隐患；

若不存在，则执行在所述补丁包中插入测试代码的步骤。

优选地，在所述补丁包中插入测试代码包括：

对所述补丁包进行解压，得到dex格式的补丁包；

采用baksmali.jar工具对所述dex格式的补丁包进行反编译，得到smali格式的代码文件；

在所述smali格式的代码文件中寻找插入点，将所述测试代码插入到所述插入点中；

采用smali.jar工具将修改后的smali格式的代码文件重新打包为dex格式的补丁包；

将新的dex格式的补丁包与原始文件重新打包，生成修改后的补丁包。

优选地，在所述smali格式的代码文件中寻找插入点，将所述测试代码插入到所述插入点中包括：

在所述smali格式的代码文件中寻找类的初始化函数，将所述类的初始化函数作为插入点；

在所述类的初始化函数中插入所述测试代码；或

在所述smali格式的代码文件中，获取全部以.method开头的函数，将所述以.method开头的函数作为插入点；

在全部以.method开头的函数的头部中插入所述测试代码。

优选地，所述测试代码在运行后，会生成预设的字符串；

所述获取测试结果，当所述测试结果中存在与所述测试代码相匹配的标识时，标记所述app在更新过程中存在安全隐患包括：

获取更新后的app在运行过程中产生的日志；

当所述日志中存在所述预设的字符串时，表明所述app在更新过程中未进行校验，标记所述app在更新过程中存在安全隐患。

按照本发明的另一方面，提供了一种检测装置，用于检测app更新过程中的安全性，包括至少一个处理器；以及，与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被程序设置为执行本发明所述的检测app更新过程中安全性的方法。

总体而言，通过本发明所构思的以上技术方案与现有技术相比，具有如下有益效果：本发明提供一种检测app更新过程中安全性的方法以及检测装置，该检测app更新过程中安全性的方法包括：获取用于更新的补丁包；在补丁包中插入测试代码；采用修改过的补丁包更新对应的app，运行更新后的app以进行测试；获取测试结果，当测试结果中存在与测试代码相匹配的标识时，标记app在更新过程中存在安全隐患。采用本发明的方法可以确定不安全的补丁包，一方面便于提醒用户某些补丁包可能存在安全隐患；另一方面，可以将存在安全隐患的补丁包上报给开发者或者厂商，以督促进行改善。

附图说明

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

图1是本发明实施例提供的一种测试环境的结构示意图；

图2是本发明实施例提供的一种检测app更新过程中安全性的方法的流程示意图；

图3是本发明实施例提供的一种测试代码以及测试代码运行成功后的测试结果的示意图；

图4是本发明实施例提供的另一种检测app更新过程中安全性的方法的流程示意图；

图5是本发明实施例提供的又一种检测app更新过程中安全性的方法的流程示意图；

图6是本发明实施例提供的第一种开发商的补丁包框架；

图7是本发明实施例提供的第二种开发商的补丁包框架；

图8是本发明实施例提供的第三种开发商的补丁包框架；

图9是本发明实施例的检测装置的结构示意图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

此外，下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。

实施例1：

本发明实施例提供一种检测app更新过程中安全性的方法，该方法适用于热更新，也适用于冷更新，通过该方法对各类app的补丁包进行检测，识别并确定各类app的补丁包是否存在隐患，一方面便于提醒用户某些补丁包可能存在安全隐患；另一方面，可以将存在安全隐患的补丁包上报给开发者或者厂商，以督促进行改善。

为了保证本实施例的方法能够有效执行，对各类app的补丁包进行检测，本实施例的方法需在特定的测试环境运行。下面结合图1，具体说明适用于本实施例的测试环境的实现方式之一。

测试环境中包括终端和服务器，其中，终端上安装有虚拟机、流量转发模块和流量处理模块，虚拟机用于产生请求；服务器用于根据虚拟机的请求，反馈与之匹配的结果；流量转发模块用于将来自于虚拟机的流量转发至流量处理模块，还用于将来自于流量处理模块的流量转发至虚拟机；流量处理模块用于向服务器发送虚拟机的请求，还用于将来自于服务器的反馈结果发送至虚拟机。

其中，终端可以为电脑，终端对应的操作系统为windows或其他系统，终端的配置以及环境需保证能够安装虚拟机、流量转发模块和流量处理模块。

其中，流量转发模块为基于proxifier的模块，流量处理模块为基于mitmproxy的模块。

在实际搭建测试环境时，安装mitmproxy软件，建立流量处理模块，编写mitmproxy脚本并启动mitmdump加载，其中，mitmdump为命令行接口，可以对接python脚本，通过脚本实现监听后的处理，用于修改网络流量。在实际应用场景下，可以设置默认代理端口为8080。安装proxifier软件，建立流量转发模块，并设置代理ip地址和代理端口，其中，代理ip地址和代理端口指向流量处理模块，设置之后虚拟机产生的流量都会经过mitmproxy代理(流量处理模块)。

为了更清楚地了解流量转发模块和流量处理模块的作用以及搭建测试环境的必要性，首先简要介绍一下正常情况下，ssl(securesocketslayer，简写为ssl)的通信过程：

(1)客户端向服务器请求连接；

(2)服务器回复客户端ssl组件的版本以及证书(证书中含有公钥)；

(3)客户端随机出一串数字，使用证书中的公钥加密后发送给服务器；

(4)服务器使用私钥解密出客户端发送的数字串；

(5)客户端与服务器都有了这串数字之后，开始通信；

(6)把这串数字作为秘钥，之后所有的通信内容都会用这串数字进行加密。

从前述ssl的通信过程中，可以看出想要解密流量必须获取到加密通信内容的秘钥，但是这个秘钥是客户端产生的随机数字串，又通过非对称加密发送给服务器，只有服务器用私钥解密才能得到这个数字串。本实施例的方法需要获取流量中的补丁包，以确定补丁包是否存在安全隐患，为了获取补丁包，需要架设中间代理人(mitmproxy)，通过中间代理人获取流量中的补丁包。

其中，mitmproxy通过中间人的方法，在客户端请求服务器时，将设定的证书发送给客户端，如果客户端对证书没有校验的情况下，使用证书中的公钥加密随机的通信秘钥，然后发送给mitmproxy，mitmproxy通过私钥便能解密出通信秘钥，之后客户端与服务器的通信内容便可以通过通信秘钥来解密。

在架设mitmproxy(简称mp)代理之后的ssl通信过程：

(1)客户端向服务端请求连接，请求流量通过mp；

(2)mp将预设的证书发送给客户端，再将请求发送给服务器，服务器回复证书给mp

(3)客户端随机出一串数字，用mp反馈的预设的证书中的公钥加密后发送给mp；

(4)mp通过私钥解密出客户端的数字串；

(5)mp再通过服务器证书中的公钥加密数字串之后发送给服务器，开始通信，通信内容使用数字串加密；

(6)mp已经得到用于加密的数字串，便可解密通信内容。

其中，mitmproxy是架设代理的软件，可架设http、https、socks代理，有windows版本与linux版本，可以编写脚本处理通过代理的流量。

其中，proxifier是一款功能非常强大的socks5客户端，可以让不支持通过代理服务器工作的网络程序能通过http、https或socks代理，由于很多手机应用的代码中创建网络链接时指定不走代理，所以即使虚拟机中设置了指向代理服务器(mitmproxy)，但是虚拟机的app流量也不会经过代理服务器(mitmproxy)，所以proxifier的作用就是在虚拟机之外，将虚拟机产生的所有流量都转发到代理服务器(mitmproxy)中处理，从而能够获取补丁包流量，并对补丁包流量进行修改。

在实际应用场景下，终端上也可以不安装流量转发模块，在此情况下，只能获取创建网络链接时可以走代理的app的补丁包，虽然检测的补丁包的类型有限，但是不影响本实施例的方法的执行。在优选的实施例中，如图1所示，终端上安装有流量转发模块，可以获取全部类型的app的补丁包，可以极大的拓宽检测的场景，使得检测结果更全面。

下面参阅图1，具体说明本实施例的检测app更新过程中安全性的方法包括如下步骤：

在步骤101中，获取用于更新的补丁包。

其中，用于更新的补丁包的种类很多，可以覆盖各类app。

在实际应用场景下，虚拟机获取apk包，具体可以采用爬虫技术从应用市场上获取各类app应用的apk包，然后反编译每一apk包，读取androidmanifest.xml文件中的所有功能操作，通过apk包在虚拟机上安装对应的app应用。针对每一个app逐一启动所有的功能操作，触发补丁包流量。当针对某一功能操作存在补丁包时，虚拟机触发获取补丁包的流量请求，流量转发模块接收流量请求，将流量请求转发至流量处理模块，流量处理模块再将流量请求发送至服务器，服务器解析流量请求并将与流量请求相匹配的补丁包发送至流量处理模块，按照此方式获取到用于更新的补丁包。

在步骤102中，在所述补丁包中插入测试代码。

在本实施例中，在获取到补丁包后，先在补丁包中插入测试代码，然后，再将插入测试代码之后的补丁包发送至虚拟机，以便于更新安装。

其中，测试代码是预先进行编译的函数，当测试代码运行成功后，会在对应的日志中生成与测试代码相匹配的标识，以便于确定修改后的补丁包是否运行成功。

在具体应用场景下，插入测试代码的过程可以在流量处理模块中执行。

在步骤103中，采用修改过的补丁包更新对应的app，运行更新后的app以进行测试。

将修改过的补丁包发送至虚拟机，以使虚拟机根据修改过的补丁包进行更新。

在步骤104中，获取测试结果，当所述测试结果中存在与所述测试代码相匹配的标识时，标记所述app在更新过程中存在安全隐患。

在本实施例中，采用修改过的补丁包更新对应的app，运行更新后的app，app在运行过程中会产生日志，可以将app的运行日志作为测试结果，当测试结果中存在与所述测试代码相匹配的标识时，说明app通过修改过的补丁包进行了更新，标记所述app在更新过程中存在安全隐患。

其中，前述的标识可以是预设的字符串，当测试结果中存在预设的字符串时，说明app通过修改过的补丁包进行了更新，标记所述app在更新过程中存在安全隐患。

采用本实施例的方法可以确定不安全的补丁包，一方面便于提醒用户某些补丁包可能存在安全隐患；另一方面，可以将存在安全隐患的补丁包上报给开发者或者厂商，以督促进行改善。

在实际应用场景下，在步骤104之后还包括：将在更新过程中存在安全隐患的app上报给用户或厂商，以便督导厂商对存在安全隐患的app进行整改或提醒用户app存在安全隐患。

在实际应用场景下，从流量中获取到的补丁包不能直接被修改，需要对补丁包进行处理，得到可编译的补丁包，以在补丁包中插入测试代码。在可选的方案中，在步骤102中具体包括如下步骤：对所述补丁包进行解压，得到dex格式的补丁包；采用baksmali.jar工具对所述dex格式的补丁包进行反编译，得到smali格式的代码文件；在所述smali格式的代码文件中寻找插入点，将所述测试代码插入到所述插入点中；采用smali.jar工具将修改后的smali格式的代码文件重新打包为dex格式的补丁包；将新的dex格式的补丁包与原始文件重新打包，生成修改后的补丁包，其中，原始文件包括manifest.mf文件。

在实际应用场景下，前述的实现过程可以编写为对应的程序，并将该程序设置在mitmproxy中，用于修改原始的补丁包。

其中，baksmali.jar工具可以反编译补丁包中dex文件，smali.jar工具可以编译dex文件，dex文件相当于安卓的可执行文件，反编译出来的smali文件可以理解为源码文件，测试代码插入到smali文件后，重新编译，然后让app加载执行。

为了保证测试代码能够被运行，需要将测试代码插入至合适的位置。在优选的实施例中，所述插入点可以为类的初始化函数。在实际应用场景下，在引用一个类的时候，类的构造函数肯定是先被调用的，类中的方法确不一定被调用，因此，测试代码需要插入到每个类的构造函数(初始化函数)中，这样才最有可能被调用运行。在可选的方案中，在所述smali格式的代码文件中寻找类的初始化函数，将所述类的初始化函数作为插入点；在所述类的初始化函数中插入所述测试代码。

在优选的实施例中，在所述smali格式的代码文件中，获取全部以.method开头的函数，将所述以.method开头的函数作为插入点；在全部以.method开头的函数的头部中插入所述测试代码。在实际应用场景下，每个函数都会以.method开头，可以在每个函数的头部都插入测试代码，将测试代码插入到靠前的位置，由于每个函数中均被插入测试代码，虽然会造成代码冗余，但是可以增加运行几率，即使部分函数不被调用，对于测试代码的运行的影响也是很小的，从而保证测试代码能够被运行。

在实际应用场景下，所述测试代码具有打印功能，相当c语言中的printf功能，在所述测试代码在运行后，会生成预设的字符串，其中，预设的字符串可以根据实际情况设置，在此，不做具体限定。在可选的方案中，在步骤104中，具体包括获取更新后的app在运行过程中产生的日志；当所述日志中存在所述预设的字符串时，表明所述app在更新过程中未进行校验，标记所述app在更新过程中存在安全隐患。

如图3所示，在补丁包对应的smali格式的代码文件中，插入测试代码，测试代码执行成功后，会打印字符串zhchello。

区别于现有技术，采用本实施例的方法可以确定不安全的补丁包，一方面便于提醒用户某些补丁包可能存在安全隐患；另一方面，可以将存在安全隐患的补丁包上报给开发者或者厂商，以督促进行改善。

实施例2：

在实施例1中，针对任意补丁包均执行插入测试代码的操作，但是，在实际应用场景下，大多数补丁包存在校验，安全性较高，假设按照实施例1的方法进行检测时，只能根据测试结果确定补丁包是否存在安全隐患，检测效率极低。为了提高检测效率，对实施例1进行改进，本实施例提供另一种方法，可以对补丁包进行初步判断，筛选出具有潜在安全隐患的补丁包，针对潜在安全隐患的补丁包进行进一步地判断，以最终确定补丁包是否具有安全隐患；在进行初步判断后，针对不存在安全隐患的补丁包，无需进行进一步判断，极大减小了测试的数据源，提高了检测的效率。

下面参阅图4，具体说明本实施例的检测app更新过程中安全性的方法所包括的步骤：

在步骤201中，获取用于更新的补丁包。

其中，步骤201与实施例1的步骤101的实现方式相同，在此，不再赘述。

在步骤202中，分析携带所述补丁包的流量中是否存在安全校验。在实际应用场景下，不同的开发商对应的补丁包的更新框架存在差异，部分开发商的补丁包更新框架中存在至少一种校验，保证补丁包被修改后能够被识别出来；部分开发商的补丁包更新框架中，不存在校验，即使补丁包被修改，也无法识别出来，这类补丁包具有极大的安全隐患。

其中，补丁包中可能存在md5校验、文件签名和文件签名校验，当补丁包中存在前述校验的话，可以降低补丁包的安全隐患。

在优选的实施例中，识别所述补丁包的更新框架，根据所述补丁包的更新框架，初步判断所述补丁包是否存在潜在安全隐患；若所述补丁包存在潜在安全隐患，则执行在所述补丁包中插入测试代码。

在此，以安全校验为md5校验为例解释说明。

在本实施例中，首先确定补丁包是否存在md5校验，其中，md5为message-digestalgorithm5(信息-摘要算法5)。具体地，分析携带所述补丁包的流量中是否存在md5校验。

在实际应用场景下，在传输补丁包的前后流量中，流量中一般会包含传输补丁包的md5值(可以理解为校验码)，当补丁包被修改时，md5值可能会被改变，app在通过补丁包进行更新时，会对补丁包进行md5运算得到md5值，当解析出来的md5值与流量中的md5值相同时，补丁包未被修改，说明补丁包不具有安全隐患；当解析出来的md5值与流量中的md5值不相同时，补丁包可能被修改过，说明补丁包具有潜在安全隐患。

进一步地，流量中包含的传输补丁包的md5值，可能存在于明文中或被加密，如果存在明文(未被加密)中的话，则可以对补丁包进行修改，当保证修改后的补丁包对应的md5值与流量中携带的md5值相同时，即使app在更新过程中，进行md5校验，也无法识别出补丁包被修改过，则此类补丁包具有潜在安全隐患。

此外，在传输补丁包的前后流量中，可能不会包含传输补丁包的md5值，app在更新过程中，可能不对补丁包进行校验，则初步说明补丁包具有潜在安全隐患。

鉴于前述的分析，在本实施例中，首先，分析携带所述补丁包的流量中是否存在md5校验。

当流量中存在md5校验时，说明流量中存在安全校验，则执行步骤203；当流量中不存在md5校验时，说明流量中不存在安全校验，则执行步骤205。

在步骤203中，若流量中存在安全校验，则进一步分析所述安全校验存在的方式。

在此以安全校验为md5校验为例解释说明。

其中，md5校验存在的位置包括：存在于http流量、https流量或者其他加密流量中，md5校验存在的方式包括：存在于明文中或者被加密。其中，当md5校验存在于http流量或https流量中时，或者，当md5校验存在于明文中时，补丁包可能存在潜在安全隐患。

当md5校验被加密或者md5校验存在于加密流量中时，补丁包具有较高的安全级别。

在步骤204中，若所述安全校验是明文，则所述补丁包存在潜在安全隐患。

在步骤205中，若流量中不存在安全校验，则所述补丁包存在潜在安全隐患。

在步骤206中，在存在潜在安全隐患的补丁包中插入测试代码。

在步骤207中，采用修改过的补丁包更新对应的app，运行更新后的app以进行测试。

在步骤208中，获取测试结果，当所述测试结果中存在与所述测试代码相匹配的标识时，标记所述app在更新过程中存在安全隐患。

其中，步骤206与实施例1的步骤102相同，步骤207与实施例1的步骤103相同，步骤208与实施例1的步骤104相同，具体请参照实施例1，在此，不再赘述。

在其他实施例中，识别所述补丁包的更新框架，根据所述补丁包的更新框架，初步判断所述补丁包是否存在潜在安全隐患；若所述补丁包存在潜在安全隐患，则执行在所述补丁包中插入测试代码，还可以按照如下方式进行检验：

在此，以安全校验为文件签名为例解释说明。

在获取到用于更新的补丁包之后，解压补丁包，确定补丁包中是否具有文件签名，当补丁包中具有文件签名时，补丁包具有较高的安全级别；当补丁包中不具有文件签名时，补丁包存在潜在安全隐患。

具体地，解压补丁包，得到meta-inf文件，其中，meta-inf文件包括manifest.mf文件、cert.sf文件和cert.rsa文件。其中，manifest.mf文件是摘要文件，manifest.mf文件中包含摘要信息，针对补丁包中的所有文件，生成摘要细信息，并进行编码后，存储在manifest.mf文件中。具体地，对非文件夹非签名文件的文件，逐个用sha1生成摘要信息，再用base64进行编码，最后存储在manifest.mf文件中。

其中，cert.sf文件是对摘要信息(即，manifest.mf文件)的签名文件。对前一步生成的manifest.mf文件，使用预设的算法，例如，可以为sha1-rsa算法，用开发者的私钥进行签名。在安装时只能使用公钥才能解密该cert.sf文件。解密之后，将cert.sf文件与未加密的摘要信息(即，manifest.mf文件)进行对比，如果二者内容相符，则表明补丁包没有被异常修改；如果二者内容不相符，则表明补丁包被修改过。

其中，cert.rsa文件中保存了公钥、所采用的加密算法等信息，相当于是一个证书，app对cert.sf文件进行解密，所需要的公钥就是从cert.rsa文件。

在实际应用场景下，可以解析所述补丁包，判断确定所述补丁包中是否存在manifest.mf文件、cert.sf文件和cert.rsa文件，若存在，则说明所述补丁包具有较高的安全级别；若不存在，则说明补丁包存在潜在安全隐患。

区别于现有技术，本实施例的方法通过补丁包的更新框架进行初步判断，筛选出具有潜在安全隐患的补丁包，针对潜在安全隐患的补丁包进行进一步地判断，以最终确定补丁包是否具有安全隐患；在进行初步判断后，针对不存在安全隐患的补丁包，无需进行进一步判断，提高了检测的效率。

实施例3：

在实际应用场景下，不同的开发商对app的补丁包的更新框架存在差异，经过多次检测与验证之后，可以根据开发商确定不同系列的补丁包的安全性，例如，阿里系列的补丁包中含有文件签名，并且补丁包的md5是通过https传输，阿里系列的补丁包不能修改，具有较高的安全性；腾讯系列的补丁包含有文件签名，并且补丁包的md5是通过腾讯安全服务器传输，流量是加密的，加密算法是腾讯内部算法，无法解密，腾讯系列的补丁包不能修改，具有较高的安全性；美团系列补丁包中没有文件签名，只有补丁包md5校验，如果md5使用明文传输，则补丁包可以修改，美团系列的补丁包存在潜在安全隐患。关于其他系列的补丁包，在此不再一一列举。

在实际应用场景下，可以基于已经完成的检测结果，生成检查表，根据检查表初步判断补丁包是否具有安全隐患，当补丁包具有安全隐患时，再执行插入测试代码检测的过程。

针对实施例1，提出一种改进的方案，在步骤104之后，还包括，获取测试结果，当所述测试结果中不存在与所述测试代码相匹配的标识时，标记所述app在更新过程中不存在安全隐患；识别不存在安全隐患的app的开发商，将不存在安全隐患的app与其相对应的开发商建立映射关系，并存储至预设的检查表中，以便通过所述检查表确定app在更新过程中是否具有安全隐患。

进一步地，为了提高检查表的准确性，可以依据实际情况实时更新检查表。

具体地，按照预设的时间周期，搜集用户对于补丁包安全性的反馈，当存在某一个开发商的补丁包存在安全隐患时，将该开发商从所述检查表中剔除，生成更新后的检查表。其中，预设的时间周期可以为7天或一个月，具体依据实际情况而定，在此，不做具体限定。

前述主要描述了检查表的生成过程，下面参阅图5，具体说明本实施例的检测app更新过程中安全性的方法，该方法基于前述的检查表进行初步判断，筛选出具有安全隐患的补丁包，再对具有安全隐患的补丁包进行检测，可以减小检测数数据源，提高检测的效率。

在步骤301中，获取用于更新的补丁包。

其中，步骤301与实施例1的步骤101的实现方式相同，在此，不再赘述。

在步骤302中，识别所述补丁包对应的app的开发商。

在本实施例中，对补丁包进行解析，得到补丁包对应的app的开发商。具体地，对补丁包进行解压，得到包含开发商信息的文件，通过包含开发商信息的文件中的字符串或标识，确定所述补丁包对应的开发商。

下面结合图6～图8，举例说明识别所述补丁包对应的app的开发商的具体过程。

如图6所示，解压补丁包，得到meta-inf文件，读取meta-inf文件下的patch.mf文件，如果patch.mf文件中含有com_taobao_maindex字符串，说明该补丁包为阿里系补丁包，该补丁包对应的开发商为阿里。

如图7所示，解压补丁包，得到assets文件，读取assets文件夹下的package_meta.txt文件，如果package_meta.txt文件中含有tinker_id字符串，说明该补丁包为腾讯系补丁包，该补丁包对应的开发商为腾讯。

如图8所示，解压补丁包，得到classes.dex文件，读取classes.dex文件中的所有字符串，如果classes.dex文件中含有字符串com/meituan/robust，说明该补丁包为美团系列补丁包，该补丁包对应的开发商为美团。

由上分析可知，阿里系列的补丁包和腾讯系列的补丁包具有安全性，则将com_taobao_maindex和tinker_id添加至检查表中，其中com_taobao_maindex和tinker_id分别代表开发商。

其他类型的补丁包获取对应开发商的方式，同样可以通过解释补丁包内所包含的文件而获得，在此不再一一列举

在步骤303中，遍历所述检查表，判断所述补丁包对应的app的开发商是否存在于所述检查表中。

在获取到补丁包对应的开发商后，遍历所述检查表，判断所述补丁包对应的app的开发商是否存在于所述检查表中。其中，可以采用字符串相似性方法遍历所述检查表，判断所述补丁包对应的app的开发商是否存在于所述检查表中。若存在，则执行步骤304；若不存在，执行步骤305。

在步骤304中，若存在，则标记所述补丁包不具有安全隐患。

在步骤305中，若不存在，在所述补丁包中插入测试代码。

在步骤306中，采用修改过的补丁包更新对应的app，运行更新后的app以进行测试。

在步骤307中，获取测试结果，当所述测试结果中存在与所述测试代码相匹配的标识时，标记所述app在更新过程中存在安全隐患。

其中，步骤305与实施例1的步骤102相同，步骤306与实施例1的步骤103相同，步骤307与实施例1的步骤104相同，具体请参照实施例1，在此，不再赘述。

在步骤308中，获取测试结果，当所述测试结果中不存在与所述测试代码相匹配的标识时，标记所述app在更新过程中不存在安全隐患。

在步骤309中，识别不存在安全隐患的app的开发商，将不存在安全隐患的app与其相对应的开发商建立映射关系，并存储至预设的检查表中，以便通过所述检查表确定app在更新过程中是否具有安全隐患。

区别于现有技术，在本实施例中，可以基于已经完成的检测结果，生成检查表，根据检查表初步判断补丁包是否具有安全隐患，当补丁包具有安全隐患时，再执行插入测试代码检测的过程，可以提高检测效率。

进一步地，为了提高检查表的准确性，可以依据实际情况实时更新检查表。

实施例4：

请参阅图9，图9是本发明实施例提供的一种检测装置的结构示意图。本实施例的检测装置包括一个或多个处理器41以及存储器42。其中，图9中以一个处理器41为例。

处理器41和存储器42可以通过总线或者其他方式连接，图9中以通过总线连接为例。

存储器42作为一种基于检测app更新过程中安全性的方法的非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块，如实施例1、实施例2和/或实施例3中的检测app更新过程中安全性的方法以及对应的程序指令。处理器41通过运行存储在存储器42中的非易失性软件程序、指令以及模块，从而执行检测app更新过程中安全性的方法的各种功能应用以及数据处理，实现实施例1、实施例2和/或实施例3的检测app更新过程中安全性的方法的功能。

其中，存储器42可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实施例中，存储器42可选包括相对于处理器41远程设置的存储器，这些远程存储器可以通过网络连接至处理器41。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

关于检测app更新过程中安全性的方法请参照图1～图8及相关的文字描述在此，不再赘述。

值得说明的是，上述装置和系统内的模块、单元之间的信息交互、执行过程等内容，由于与本发明的处理方法实施例基于同一构思，具体内容可参见本发明方法实施例中的叙述，此处不再赘述。

本领域普通技术人员可以理解实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：只读存储器(readonlymemory，简写为rom)、随机存取存储器(randomaccessmemory，简写为ram)、磁盘或光盘等。

本领域的技术人员容易理解，以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。