本发明涉及计算机技术，尤其涉及一种软件升级的监管方法和装置。
背景技术：
随着互联网技术和智能终端技术的飞速发展，终端用户对终端上应用的功能需求日渐增多，若对应每一个新增功能需求都采用开发一款全新应用来实现，则会使终端的负担加大，降低终端内存使用效率，同时还会给用户的使用带来不便，并造成资源浪费。因此，终端应用服务提供商普遍采用在原有应用基础上，添加新的模块和功能，实现移动应用软件的升级，满足不同用户对于移动终端应用适应生活各方面的需求。
为了用户使用的方便，现有技术中往往对应用采取自动升级的手段实现功能的完善及版本的更新，而用户往往对这些更新不予关注，采取直接默认的更新。这样做虽然方便，却会使应用软件升级面临因升级包附带恶意插件导致升级时浪费流量、泄露数据等诸多问题。
因此，在应用自动升级时，如何避免因升级包附带恶意插件导致的浪费流量、泄露数据等恶意行为成为目前亟待解决的技术问题。
技术实现要素：
本发明提供一种软件升级的监管方法和装置，以解决现有技术中应用自动升级时因升级包附带恶意插件导致的浪费流量、泄露数据等恶意行为的问题。
本发明第一方面提供一种软件升级的监管方法，包括：
获取待监管软件的url特征向量；其中，上述url特征向量包括多个url地址；
从上述多个url地址中确定指向安装包的第一url地址，并通过访问上述第一url地址获取上述安装包；
判断上述安装包是否为上述待监管软件的升级包；
若是，则对上述安装包进行安全性检测，得到第一检测结果，并根据上述第一检测结果确定是否替换上述安装包。
进一步地，在本发明一种可能的实现方式中，上述判断上述安装包是否为上述待监管软件的升级包之前，还包括：
判断上述安装包是否完整，得到第二检测结果；
若上述第二检测结果为上述安装包完整，则判断上述安装包是否为上述待监管软件的升级包；
若上述第二检测结果为上述安装包不完整，则根据上述第二检测结果替换上述安装包。
进一步地，在本发明一种可能的实现方式中，上述判断上述安装包是否完整，具体包括：
判断访问上述第一url地址时得到的第一md5值与根据上述安装包计算出的第二md5值是否相同；
若是，则确定上述安装包完整；
若否，则确定上述安装包不完整。
进一步地，在本发明一种可能的实现方式中，上述对上述安装包进行安全性检测，得到第一检测结果，并根据上述第一检测结果确定是否替换上述安装包，具体包括：
检测上述安装包中是否存在恶意插件；
若是，则将上述第一检测结果推送给软件提供者，并根据上述软件提供者输入的替换指令替换上述安装包；
若否，则继续存储上述安装包。
进一步地，在本发明一种可能的实现方式中，上述获取待监管软件的url特征向量，具体包括：
对上述待监管软件进行反编译处理，得到反编译代码；
对上述反编译代码执行遍历操作，获取上述url特征向量。
本发明第二方面提供一种软件升级的监管装置，包括：获取模块、确定下载模块、判断模块、检测管理模块；其中；
上述获取模块，用于获取待监管软件的url特征向量；其中，上述url特征向量包括多个url地址；
上述确定下载模块，用于从上述多个url地址中确定指向安装包的第一url地址，并通过访问上述第一url地址获取上述安装包；
上述判断模块，用于判断上述安装包是否为上述待监管软件的升级包；
上述检测管理模块，用于当上述判断模块判断上述安装包为上述待监管软件的升级包时，对上述安装包进行安全性检测，得到第一检测结果，并根据上述第一检测结果确定是否替换上述安装包。
进一步地，在本发明一种可能的实现方式中，上述判断模块，还用于在判断上述安装包是否为上述待监管软件的升级包之前，判断上述安装包是否完整，得到第二检测结果；
上述检测管理模块，在上述判断模块判断上述第二检测结果为上述安装包完整时，指示上述判断模块判断上述安装包是否为上述待监管软件的升级包；以及，在上述判断模块判断上述第二检测结果为上述安装包不完整时，根据上述第二检测结果替换上述安装包。
进一步地，在本发明一种可能的实现方式中，上述判断模块，具体用于判断访问上述第一url地址时得到的第一md5值与根据上述安装包计算出的第二md5值是否相同；若是，则确定上述安装包完整；若否，则确定上述安装包不完整。
进一步地，在本发明一种可能的实现方式中，上述检测管理模块，具体用于检测上述安装包中是否存在恶意插件；若是，则将上述第一检测结果推送给软件提供者，并根据上述软件提供者输入的替换指令替换上述安装包；若否，则继续存储上述安装包。
进一步地，在本发明一种可能的实现方式中，上述获取模块，具体用于对待监管软件进行反编译处理，得到反编译代码，并对上述反编译代码执行遍历操作，获取url特征向量。
本发明提供的软件升级的监管方法和装置，首先通过获取待监管软件的url特征向量，并从多个url地址中确定指向安装包的第一url地址，然后通过访问第一url地址获取安装包，之后再通过判断安装包是否为待监管软件的升级包，当安装包为待监管软件的升级包时，对安装包进行安全性检测，得到第一检测结果，根据第一检测结果确定是否替换上述安装包，从而确保服务器中所存储的升级包均为安全的升级包，其不携带恶意插件，从而避免了软件升级时存在的浪费流量、泄露数据等恶意行为的问题，大大节省了用户的升级流量，提高了软件升级的安全性。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1为本发明软件升级的监管方法实施例一的流程图；
图2为本发明软件升级的监管方法实施例二的流程图；
图3为本发明软件升级的监管方法实施例三的流程图；
图4为本发明软件升级的监管装置实施例一的结构示意图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
随着移动互联网的高速发展，人们对移动终端应用的功能需求日渐增多，若对应每一个新增功能需求都采用开发一款全新应用来实现，则会使移动终端的负担加大，降低移动终端内存使用效率，同时还会给用户的使用带来不便，并造成资源浪费。因此，应用服务提供商普遍采用在原有应用基础上，添加新的模块和功能，实现应用软件的升级，满足不同用户对于应用适应生活各方面的需求。
为了用户使用的方便，现有技术中往往对移动应用采取自动升级的手段实现功能的完善及版本的更新。但是，在应用自动升级的过程中，由于未对应用的升级包进行安全性检测，因此，应用在自动升级的过程中面临因升级包附带恶意插件导致升级时存在浪费流量、泄露数据等恶意行为的问题。
本发明提供一种软件升级的监管方法，以解决现有技术中应用自动升级时因升级包附带恶意插件导致的浪费流量、泄露数据等恶意行为的问题。
本发明提供的软件升级的监管方法，首先通过获取待监管软件的url特征向量，并从多个url地址中确定指向安装包的第一url地址，然后通过访问第一url地址获取安装包；之后，再通过判断安装包是否为待监管软件的升级包，当安装包为待监管软件的升级包时，对安装包进行安全性检测，得到第一检测结果，根据第一检测结果确定是否替换上述安装包，从而确保服务器中所存储的升级包均为安全的升级包，其不携带恶意插件，从而避免了软件升级时存在的浪费流量、泄露数据等恶意行为的问题，大大节省了用户的升级流量，提高了软件升级的安全性。
图1为本发明软件升级的监管方法实施例一的流程图。本实施例涉及的是对升级包进行安全检测，从而确保服务器上的升级包的安全性的具体过程。本发明实施例的执行主体可以是软件升级的监管装置，还可以是集成了该软件升级的监管装置的服务器，本发明实施例以执行主体为服务器为例来进行说明。如图1所示，本实施例提供的软件升级的监管方法，可以包括：
s101、获取待监管软件的url特征向量；其中，上述url特征向量包括多个url地址。
需要说明的是，统一资源定位符url(uniformresourcelocator)地址对可以从互联网上得到的资源的位置及访问方法进行了限定。可以理解的是，互联网上的每个文件都有一个唯一的url地址，url地址包含的信息指出文件的位置。
具体地，在该步骤中，对于没有进行加壳处理的待监管软件，可以通过对待监管软件进行反编译处理，得到待监管软件的反编译代码，然后对上述反编译代码执行遍历操作，获取url特征向量；而对于进行了加壳处理的待监管软件，在该步骤中，则需要首先对该进行了加壳处理的待监管软件进行脱壳处理，然后再对经过脱壳处理后的待监管软件进行反编译处理，进而获取该待监管软件的url特征向量。
需要说明的是，url特征向量包括多个url地址，上述多个url地址可以包括多个静态url地址和/或多个动态url地址，并且上述多个url地址可以是指向网页的url地址，还可以是指向安装包的url地址。
s102、从上述多个url地址中确定指向安装包的第一url地址，并通过访问上述第一url地址获取上述安装包。
具体地，由于多个url地址包括多个静态url地址及多个动态url地址，而静态url地址可以直接访问，动态url地址因为其不完整所以不能够直接访问。因此，在该步骤中，需要首先对多个动态url地址进行拼接及正则表达处理，得到上述多个动态url地址对应的完整的url地址；然后逐个访问上述多个静态url地址和/或上述多个动态url地址对应的完整的url地址，根据访问结果，确定出指向安装包的第一url地址；在确定了指向安装包的第一url地址后，通过访问上述第一url地址，可以将第一url地址指向的安装包下载下来。
需要说明的是，在该步骤，当访问第一url地址时，服务器会返回安装包的信息摘要算法md5(messagedigestalgorithm5)值。而当通过访问第一url地址将该第一url地址指向的安装包下载下来时，可根据该安装包计算出另一个md5值。
s103、判断上述安装包是否为上述待监管软件的升级包。
具体地，在该步骤，首先应该判断上述所下载的安装包是否为上述待监管软件的安装包，当确定该安装包为上述待监管软件的安装包时，并进一步确定该安装包是否是待监管软件的升级包。
更具体地，在本实施例中，可以通过将安装包的包名与终端上待监管软件的当前版本的包名进行比较来判断上述安装包是否为待监管软件的安装包。例如，经过比较后，若两者的包名相同，则确定上述安装包为待监管软件的安装包。
进一步地，本实施例中，首先根据安装包的包名判断上述安装包是否为待监管软件的安装包；当安装包的包名与待监管软件的当前版本的安装包的包名相同时，确定上述安装包为待监管软件的安装包。此时，当确定了安装包是待监管软件的安装包后，由于该安装包可能是比待监管软件的当前版本的安装包版本更低的安装包，也可能是比待监管软件的当前版本的安装包版本更高或版本相同的安装包。因此，此时，还需要判断上述安装包是否为待监管软件的升级包。具体地，可以通过将该安装包的版本号与待监管软件的当前版本的版本号进行比较来判断上述安装包是否为待监管软件的安装包，例如，当该安装包的版本号比待监管软件的当前版本的版本号大时，判断该安装包为该待监管软件的升级包，进而使得服务器可以对该升级包进行安全性检测。
本实施例提供的软件升级的监管方法，通过判断安装包是否为待监管软件的安装包，当判断安装包为待监管软件的安装包时，进而判断安装包是否为待监管软件的升级包，这样，服务器仅对待监管软件的升级包进行安全性检测，避免了服务器对安装包进行盲目检测，提高了安全性检测的效率。
需要说明的是，在该步骤中，升级包的类型可以是整个待监管软件的安装包，也可以是增量包。
s104、若是，则对上述安装包进行安全性检测，得到第一检测结果，并根据上述第一检测结果确定是否替换上述安装包。
具体地，在该步骤中，若经过上一步骤判断出上述安装包为待监管软件的升级包，则在该步骤中，对上述安装包进行安全性检测，得到第一检测结果。需要说明的是，该步骤中，对安装包进行安全性检测，主要是检测上述安装包中是否存在恶意插件，即检测上述安装包对应的代码是否存在恶意属性。例如，可以是检测上述安装包是否会在用户不知情或未授权的情况，自动获取用户的短信内容、位置地址等；还可以是检测上述安装包是否会在用户不知情的情况下，自动订购移动增值业务等。
更具体地，本步骤中，通过对安装包进行安全性检测，可以得到第一检测结果，该第一检测结果表明上述安装包是否安全。当第一结果表明上述安装包是安全的时，此时，表明服务器中的安装包是安全的，确定不替换上述安装包，将上述安装包继续存储在服务器中；而当第一检测结果表明上述安装包是不安全的时，则表明服务器中的安装包是不安全的，此时，则采用一安全的安装包替换上述安装包。具体地，安全的安装包是指已经经过安全性检测，不存在恶意插件的安装包。需要说明的是，在该步骤中，可以是，服务器根据第一检测结果确定是否替换安装包；也可以是，服务器将第一检测结果推送给软件提供商，软件提供商根据第一检测结果向服务器输入控制指令，服务器根据软件提供商输入的控制指令确定是否替换安装包。在该种实现方式中，例如，当服务器确定升级包不安全时，此时，服务器将升级包不安全的检测信息推送给软件提供商，软件提供商根据上述升级包不安全的检测信息，向服务器输入替换命令，服务器则根据软件提供商输入的替换命令采用一安全的安装包替换上述安装包。
本实施例提供的软件升级的监管方法，首先通过获取待监管软件的url特征向量，并从多个url地址中确定指向安装包的第一url地址，然后通过访问第一url地址获取安装包，之后再通过判断安装包是否为待监管软件的升级包，当安装包为待监管软件的升级包时，对安装包进行安全性检测，得到第一检测结果，根据第一检测结果确定是否替换上述安装包，从而确保服务器中所存储的升级包均为安全的升级包，其不携带恶意插件，从而避免了软件升级时存在的浪费流量、泄露数据等恶意行为的问题，大大节省了用户的升级流量，提高了软件升级的安全性。
可选地，在本发明一种可能的实现方式中，步骤s101具体包括：
对上述待监管软件进行反编译处理，得到反编译代码；
对上述反编译代码执行遍历操作，获取上述url特征向量。
具体的，该步骤中，可以将待监管软件软件包中的二进制代码或字节码进行反编译处理，得到成类似于源码的反编译代码，该反编译代码中包含上述待监管软件的所有信息，可以从上述待监管代码中的所有信息中获取多个url地址，进而将多个url地址组成url特征向量。本实施例中，将待监管软件a的url特征向量表述为a＝〈a1,a2,...,an>，其中，a1～an相应的代表从该待监管软件的反编译代码中获取得到的多个url地址。
本实施例提供的软件升级的监管方法，通过对待监管软件进行反编译处理，可以得到多个url地址，而这多个url地址中包含指向安装包的第一url地址。这样，可以从该多个url地址中确定指向安装包的第一url地址，进而可通过该第一url地址，可获得待监管软件的安装包，进而使得服务器可以对该安装包进行安全性检测，提高了安装包的安全性；此外，本实施例提供的软件升级的监管方法，通过从多个url地址中确定指向安装包的第一url地址，进而可通过该第一url稳定可靠地获取到待监管软件的安装包。
图2为本发明软件升级的监管方法实施例二的流程图。本实施例涉及的是判断上述安装包是否完整的具体过程。在上述实施例的基础上，进一步地，在上述s103之前，该方法还可以包括如下步骤：
s201：判断上述安装包是否完整，得到第二检测结果；
s202：若上述第二检测结果为上述安装包完整，则判断上述安装包是否为上述待监管软件的升级包；
s203：若上述第二检测结果为上述安装包不完整，则根据上述第二检测结果替换上述安装包。
具体地，当根据第一url地址获取到安装包后，该安装包可能是已经经过篡改后的安装包，此时，需要对安装包的完整性进行检测。具体地，当访问指向安装包的第一url地址时，会得到该安装包的第一md5值，而当将安装包下载下来时，可根据该安装包计算出第二md5值，可以根据第一md5值及第二md5值对安装包的完整性进行判断。具体地，当第一md5值与第二md5值相同时，表明该安装包完整。当第一md5与第二md5值不相同时，表明该安装包不完整，这样通过判断安装包的完整性，得到第二检测结果。
该步骤中，当第二检测结果为安装包不完整时，表明下载下来的安装包不完整，而造成该安装包不完整的原因可能是服务器中的安装包本身就不完整，也可能是下载时网络方面的原因致使下载下来的安装包不完全。但是，由于无法确定是哪一方面的原因造成的下载下来的安装包不完整，因此，为了保证服务器中的安装包的完整性，此时，当第二检测结果为安装包不完整时，服务器根据上述第二检测结果采用一安全的安装包替换上述安装包。具体地，安全的安装包是指已经经过安全性检测，不存在恶意插件的安装包。
需要说明的是，在该步骤，若第二检测结果为安装包不完整时，此时，可以是，服务器可以根据第二检测结果自行替换上述安装包。也可以是，服务器将第二检测结果推送给软件提供商，软件提供商根据第二检测结果向服务器输入替换命令，服务器根据上述替换命令替换上述安装包。
本实施例提供的软件升级的监管方法，通过判断安装包是否完整，得到第二检测结果；若上述第二检测结果为上述安装包完整，则判断上述安装包是否为上述待监管软件的升级包；若上述第二检测结果为上述安装包不完整，则根据上述第二检测结果替换上述安装包，不仅能够保证服务器中的安装包的安全性，还能够保证服务器中的安装包的完整性，避免软件升级时因升级包不完整而给用户带来诸多不便。
图3为本发明软件升级的监管方法实施例三的流程图。本实施例涉及的是对上述安装包进行安全性检测的具体过程。在上述实施例的基础上，进一步地，上述s104具体可以包括如下步骤：
s301：检测上述安装包中是否存在恶意插件；
s302：若是，则将上述第一检测结果推送给软件提供者，并根据上述软件提供者输入的替换指令替换上述安装包；
s303：若否，则继续存储上述安装包。
本实施例提供的软件升级的监管方法，服务器根据软件提供者输入的替换指令替换不安全的安装包，可提高替换操作的准确性，避免当服务器自行根据第一检测结果替换安装包时存在的误操作问题。
图4为本发明软件升级的监管装置实施例一的结构示意图。如图4所示，本实施例提供的软件升级的监管装置，该装置可以通过软件、硬件或者软硬结合的方式实现。该装置可以包括：获取模块100、确定下载模块200、判断模块300、检测管理模块400；其中：
获取模块100，用于获取待监管软件的url特征向量；其中，上述url特征向量包括多个url地址；
确定下载模块200，用于从上述多个url地址中确定指向安装包的第一url地址，并通过访问上述第一url地址获取上述安装包；
判断模块300，用于判断上述安装包是否为上述待监管软件的升级包；
检测管理模块400，用于当判断模块300判断上述安装包为上述待监管软件的升级包时，对上述安装包进行安全性检测，得到第一检测结果，并根据上述第一检测结果确定是否替换上述安装包。
本实施例提供的软件升级的监管装置，可以执行图1所示方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。
进一步地，在本发明一种可能的实现方式中，判断模块300，还用于在判断所述安装包是否为所述待监管软件的升级包之前，判断上述安装包是否完整，得到第二检测结果；
检测管理模块400，还用于在判断模块300判断上述第二检测结果为上述安装包完整时，指示判断模块300判断上述安装包是否为上述待监管软件的升级包；以及，在判断模块300判断第二检测结果为上述安装包不完整时，根据上述第二检测结果替换上述安装包。
具体地，本实施例提供的软件升级的监管装置，可以用于执行图2所示方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。
进一步地，在本发明一种可能的实现方式中，判断模块300，具体用于，判断访问第一url地址时得到的第一md5值与根据上述安装包计算出的第二md5值是否相同；若是，则确定上述安装包完整；若否，则确定上述安装包不完整。
进一步地，在本发明一种可能的实现方式中，检测管理模块400，具体用于检测上述安装包中是否存在恶意插件；
若是，则将上述第一检测结果推送给软件提供者，并根据上述软件提供者输入的替换指令替换上述安装包；若否，则继续存储上述安装包。
具体地，本实施例提供的软件升级的监管装置，可以用于执行图3所示方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。
进一步地，在本发明一种可能的实现方式中，获取模块100，具体用于对待监管软件进行反编译处理，得到反编译代码；对上述反编译代码执行遍历操作，获取url特征向量。
本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：rom、ram、磁碟或者光盘等各种可以存储程序代码的介质。
最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。