CN110162964A - 一种文件篡改的检查方法、装置及系统 - Google Patents

Abstract

本发明提供一种文件篡改的检查方法、装置及系统，该检查方法中在安装应用程序后，获取安装应用程序的待检查文件的哈希值，以及从与该应用程序对应的全量包中获取索引文件，从所述索引文件中获取与待检查文件对应的哈希值，然后判断获取到的待检查文件的哈希值以及索引文件中与待检查文件对应的哈希值是否相同。若待检查文件的哈希值与索引文件中待检查文件的哈希值不同，则确定待检查文件发生了篡改，否则，确定待检查文件没有被篡改。实现了对客户端中存储的该应用程序的文件是否发生了篡改的检查，避免了在发生篡改的情况下启动并运行应用程序导致发生安全隐患问题的产生。

Description

一种文件篡改的检查方法、装置及系统

技术领域

本发明属于计算机安全技术领域，尤其涉及一种文件篡改的检查方法、装置及系统。

背景技术

现有技术中，客户端根据从服务器获取到的全量包安装某个应用程序后，在启动运行该应用程序时，若检测到该应用程序存在更新版本时，从服务器获取该应用程序的增量包以更新该应用程序，并运行该更新后的应用程序。若检测到该应用程序不存在更新版本时，直接运行该应用程序。

客户端根据从服务器获取到的全量包安装应用程序后，会在客户端本地生成关于应用程序的文件，若客户端生成的关于应用程序的文件被篡改后，在根据篡改后的文件启动运行该应用程序时会存在安全问题。

由于现有技术中并没有关注到对客户端生成的关于应用程序的文件进行检查以确定文件是否被篡改的问题，因此在运行应用程序时存在安全问题。

发明内容

有鉴于此，本发明的目的在于提供一种文件篡改的检查方法、装置及系统，以解决现有技术中没有对客户端生成的关于应用程序的文件是否被篡改的检查进而存在安全隐患的问题。

技术方案如下：

本发明提供一种文件篡改的检查方法，包括：

获取待检查文件的哈希值；其中，所述待检查文件为根据从服务器获取到的数据包安装应用程序后生成的文件；其中，所述数据包为全量包或增量包；

从全量包中获取索引文件，所述索引文件中存储有与全量包中各个文件分别对应的哈希值；

从所述索引文件中获取与所述待检查文件对应的哈希值；

判断待检查文件的哈希值与所述索引文件中与该待检查文件对应的哈希值是否相同；

若判断待检查文件的哈希值与所述索引文件中与该待检查文件对应的哈希值不同，则确定所述待检查文件被篡改。

优选地，若待检查文件为多个，则判断待检查文件的哈希值与所述索引文件中与该待检查文件对应的哈希值是否相同包括：

将获取到的每个待检查文件的哈希值组合成第一字符串；

获取所述第一字符串的哈希值，得到第一汇总哈希值；

将分别从所述索引文件中获取到的与每个待检查文件对应的哈希值组合成第二字符串；

获取所述第二字符串的哈希值，得到第二汇总哈希值；

判断所述第一汇总哈希值与所述第二汇总哈希值是否相同。

优选地，所述确定所述待检查文件被篡改之后，还包括：

删除存储的已经安装的应用程序的版本信息；

在启动运行该应用程序时，将存储的该应用程序的版本信息以及与该版本信息对应的增量包的哈希值发送至服务器，使得服务器接收到版本信息为空后重新下发与该应用程序对应的全量包；其中，若所述待检查文件未被篡改，则服务器接收到版本信息后判断接收到的版本信息与服务器存储的版本信息相同且接收到的与版本信息对应的增量包的哈希值与服务器存储的上一个版本信息对应的增量包的哈希值相同后下发与新生成的该应用程序的版本信息对应的增量包。

优选地，接收到增量包后，还包括：

将所述增量包中包括的各个文件合并到本地的全量包中，更新所述本地的全量包的文件；

将所述增量包的索引文件合并到所述本地的全量包的索引文件中，更新所述本地的全量包的索引文件。

本发明还提供了一种文件篡改的检查方法，包括：

根据待打包资源文件信息，生成索引文件；

压缩索引文件以及与待打包资源文件信息对应的资源文件，生成数据包；

将所述数据包发送至客户端，使得客户端获取到所述数据包后安装应用程序。

优选地，所述压缩索引文件以及与待打包资源文件信息对应的资源文件，生成数据包包括：

由索引长度、索引文件数据、待打包资源文件信息对应的资源文件的索引数据以及待打包资源文件信息对应的资源文件组成压缩包文件流；

对压缩包文件流进行压缩，生成全量包。

优选地，还包括：

接收客户端发送的版本信息以及与所述版本信息对应的增量包的哈希值；

判断客户端的版本信息与服务器存储的该应用程序的版本信息是否相同，客户端的增量包的哈希值与服务器存储的上一个版本信息对应的增量包的哈希值是否相同；

若判断客户端的版本信息与服务器存储的该应用程序的版本信息不同，且客户端的增量包的哈希值与服务器存储的上一个版本信息对应的增量包的哈希值相同，将服务器新生成的增量包发送至客户端；

若判断客户端的版本信息与服务器存储的该应用程序的版本信息不同，且客户端的增量包的哈希值与服务器存储的上一个版本信息对应的增量包的哈希值不同，则将服务器新生成的全量包发送至客户端。

本发明还提供了一种文件篡改的检查装置，应用于客户端，包括：

第一获取单元，用于获取待检查文件的哈希值；其中，所述待检查文件为根据从服务器获取到的数据包安装应用程序后生成的文件；其中，所述数据包为全量包或增量包；

第二获取单元，用于从全量包中获取索引文件，所述索引文件中存储有与全量包中各个文件分别对应的哈希值；

第三获取单元，用于从所述索引文件中获取与所述待检查文件对应的哈希值；

判断单元，用于判断待检查文件的哈希值与所述索引文件中与该待检查文件对应的哈希值是否相同；

确定单元，用于若判断待检查文件的哈希值与所述索引文件中与该待检查文件对应的哈希值不同，则确定所述待检查文件被篡改。

本发明还提供了一种文件篡改的检查装置，应用于服务器，包括：

生成单元，用于根据待打包资源文件信息，生成索引文件；

压缩单元，用于压缩索引文件以及与待打包资源文件信息对应的资源文件，生成数据包；

发送单元，用于将所述数据包发送至客户端，使得客户端获取到所述数据包后安装应用程序。

本发明还提供了一种文件篡改的检查系统，其特征在于，包括客户端以及与客户端连接的服务器；

所述客户端应用如上所述的文件篡改的检查方法；

所述服务器应用如上所述的文件篡改的检查方法。

与现有技术相比，本发明提供的上述技术方案具有如下优点：

从上述技术方案可知，本申请中安装应用程序后，获取安装应用程序的待检查文件的哈希值，以及从与该应用程序对应的全量包中获取索引文件，从所述索引文件中获取与待检查文件对应的哈希值，然后判断获取到的待检查文件的哈希值以及索引文件中与待检查文件对应的哈希值是否相同。若待检查文件的哈希值与索引文件中待检查文件的哈希值不同，则确定待检查文件发生了篡改，否则，确定待检查文件没有被篡改。实现了对客户端中存储的该应用程序的文件是否发生了篡改的检查，避免了在发生篡改的情况下启动并运行应用程序导致发生安全隐患问题的产生。

附图说明

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

图1是本发明实施例提供的一种文件篡改的检查方法的流程图；

图2是本发明实施例提供的另一种文件篡改的检查方法的流程图；

图3是本发明实施例提供的另一种文件篡改的检查方法的流程图；

图4是本发明实施例提供的索引文件存储内容的示意图；

图5是本发明实施例提供的另一种文件篡改的检查方法的流程图；

图6是本发明实施例提供的一种文件篡改的检查装置的结构示意图；

图7是本发明实施例提供的另一种文件篡改的检查装置的结构示意图。

具体实施方式

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

客户端已经安装的应用程序，当存在该应用程序的新版本时，需要对该应用程序进行更新，以升级该应用程序的版本。现有技术中对应用程序更新的过程为：服务器打包增量包，接收到客户端发送的已经安装的应用程序的版本信息后，判断客户端已经安装的应用程序的版本信息与当前最新版本信息是否相同，若不同，则根据最新版本信息与客户端已经安装的应用程序的版本信息的差距，响应客户端的下载请求，将与差距对应的增量包下发至客户端；客户端下载得到增量包后解压安装增量包，实现对应用程序的更新。当然，在实际应用中，服务器打包增量包的同时还可以生成最新版本的全量包，客户端不仅可以从服务器下载得到与应用程序对应的增量包，还可以下载得到该应用程序的最新版本的全量包。

但是，无论是直接下载增量包还是下载全量包，客户端下载并安装更新后的应用程序后，接收到用户对应用程序的启动命令后，直接启动并运行该应用程序，而并不检查客户端中解压该应用程序的增量包或全量包后存储的该应用程序的文件是否被篡改，导致在发生篡改的情况下启动并运行应用程序存在安全隐患问题。

针对此，本实施例提供了一种文件篡改的检查方法，应用于客户端，如移动终端、电脑等电子设备上，所述客户端安装有至少一个应用程序。

参见图1，该实施例包括以下步骤：

S101、获取待检查文件的哈希值；其中，所述待检查文件为根据从服务器获取到的数据包安装应用程序后生成的文件；

客户端开机启动时，针对客户端上安装的每个应用程序，分别获取与该应用程序对应的待检查文件的哈希值。

其中，待检查文件为根据从服务器获取到的数据包安装应用程序后生成的文件。所述数据包为全量包或增量包。

客户端在第一次下载并安装应用程序时从服务器下载全量包，并根据全量包解压后生成关于该应用程序的文件，以根据生成的文件启动并运行该应用程序。而后续在启动并运行该应用程序时，确定需要对该应用程序进行更新时，从服务器获取该应用程序的增量包，以根据获取到的增量包对安装的应用程序进行功能更新或修复。

本实施例中，根据从服务器获取到全量包或增量包安装应用程序后，在客户端生成的文件包括应用静态文件、动态链接库/可执行文件、配置文件。其中，配置文件允许客户端的用户根据实际需求进行个性化配置。本实施例中待检查文件包括应用静态文件、动态链接库/可执行文件，而不包括配置文件。

S102、从全量包中获取索引文件，所述索引文件中存储有与全量包中各个文件分别对应的哈希值；

本实施例中，在对已经安装的应用程序没有更新前，该应用程序对应的全量包是从服务器下载得到的初始安装该应用程序时的全量包；在对已经安装的应用程序利用增量包进行更新后，该应用程序对应的全量包是将从服务器下载得到的增量包合并到初始安装该应用程序时的全量包后得到的新的全量包。

从服务器下载得到的全量包中包括全量包的索引文件，全量包的索引文件中存储有与该全量包中各个文件分别对应的哈希值；从服务器下载得到的增量包中包括增量包的索引文件，增量包的索引文件中存储有与该增量包中各个文件分别对应的哈希值。

利用从服务器下载得到的增量包对该应用程序进行更新时，将增量包合并到从服务器下载得到的本地全量包后，将增量包的索引文件也合并到从服务器下载得到的本地全量包的索引文件中，使得新的全量包中包括的索引文件也得到更新。

一种实现方式为：将所述增量包中包括的各个文件合并到本地的全量包中；从所述增量包中获取该增量包的索引文件；确定索引文件包括的资源文件中是否存在与本地的全量包包括的资源文件相同的资源文件；若确定索引文件包括的资源文件中存在与本地的全量包包括的资源文件相同的资源文件，则获取所述索引文件包括的资源文件与本地的全量包包括的资源文件相同的资源文件对应的哈希值；利用所述索引文件中与所述本地的全量包中相同的资源文件对应的哈希值，更新所述本地的全量包中对应的资源文件的哈希值；而对于增量包中包括但是本地全量包中不包括的资源文件，直接进行合并即可。

S103、从所述索引文件中获取与所述待检查文件对应的哈希值；

从与该应用程序对应的全量包的索引文件中获取与该应用程序的待检查文件对应的哈希值。索引文件中与待检查文件对应的哈希值是待检查文件的初始哈希值。

若客户端上该应用程序的待检查文件被篡改后，获取到的待检查文件的哈希值相较于待检查文件的初始哈希值就会发生变化；若客户端上该应用程序的待检查文件没有被篡改，获取到的待检查文件的哈希值相较于待检查文件的初始哈希值是相同的。

S104、判断待检查文件的哈希值与所述索引文件中与该待检查文件对应的哈希值是否相同；

若判断待检查文件的哈希值与所述索引文件中与该待检查文件对应的哈希值不同，则执行步骤S105；

若判断待检查文件的哈希值与所述索引文件中与该待检查文件对应的哈希值相同，则确定待检查文件没有被篡改，可以直接启动运行该应用程序。

S105、确定所述待检查文件被篡改。

从上述技术方案可知，本实施例中安装应用程序后，获取安装应用程序的待检查文件的哈希值，以及从与该应用程序对应的全量包中获取索引文件，从所述索引文件中获取与待检查文件对应的哈希值，然后判断获取到的待检查文件的哈希值以及索引文件中与待检查文件对应的哈希值是否相同。若待检查文件的哈希值与索引文件中待检查文件的哈希值不同，则确定待检查文件发生了篡改，否则，确定待检查文件没有被篡改。实现了对客户端中存储的该应用程序的文件是否发生了篡改的检查，避免了在发生篡改的情况下启动并运行应用程序导致发生安全隐患问题的产生。

本实施例还公开了另一种检查文件篡改的方法，应用于客户端，所述客户端安装有至少一个应用程序。

参见图2，该实施例包括以下步骤：

S201、获取待检查文件的哈希值；其中，所述待检查文件为根据从服务器下载得到的全量包安装应用程序后生成的文件；

S202、从所述全量包中获取索引文件，所述索引文件中存储有与全量包中各个文件分别对应的哈希值；

S203、从所述索引文件中获取与所述待检查文件对应的哈希值；

本实施例中步骤S201-S203的实现方式与上一实施例中步骤S101-S103的实现方式类似，此处不再赘述。

在本实施例中，考虑到针对每个应用程序，待检查文件包括应用静态文件、动态链接库/可执行文件这多个文件，下面详细介绍本实施例中采用哈希值比对的方式检查多个待检查文件是否发生篡改的方法。

S204、将获取到的每个待检查文件的哈希值组合成第一字符串；

分别获取到该应用程序的每个待检查文件的哈希值后，将获取到的每个待检查文件的哈希值拼接组合成一个字符串。

S205、获取所述第一字符串的哈希值，得到第一汇总哈希值；

获取该应用程序的全部待检查文件的哈希值拼接组合成的字符串的哈希值。

S206、将分别从所述索引文件中获取到的与每个待检查文件对应的哈希值组合成第二字符串；

从该应用程序对应的全量包的索引文件中，分别获取该应用程序的每个待检查文件的哈希值，将获取到的每个待检查文件的哈希值拼接组合成一个字符串。

在拼接组合每个待检查文件的哈希值时，对从索引文件中获取到的待检查文件的哈希值的拼接顺序与步骤S204中获取到的待检查文件的哈希值的拼接顺序相同。如，拼接顺序是应用静态文件的哈希值、动态链接库/可执行文件的哈希值。

在其他实施例中，在获取到待检查文件的哈希值后，还可以采用其他拼接组合的方式将该应用程序的所有待检查文件的哈希值拼接组合成字符串。

S207、获取所述第二字符串的哈希值，得到第二汇总哈希值；

S208、判断所述第一汇总哈希值与所述第二汇总哈希值是否相同；

若判断待检查文件的哈希值与所述索引文件中与该待检查文件对应的哈希值不同，则执行步骤S209；

若判断待检查文件的哈希值与所述索引文件中与该待检查文件对应的哈希值相同，则确定待检查文件没有被篡改，可以启动并运行该应用程序，执行步骤S211。

索引文件中与待检查文件对应的哈希值是待检查文件的初始哈希值。将索引文件中待检查文件的哈希值汇总后得到的汇总哈希值与客户端对全量包或增量包解压后生成的待检查文件的哈希值汇总后得到的汇总哈希值进行比较。

若客户端上该应用程序的待检查文件被篡改后，获取到的待检查文件的哈希值相较于待检查文件的初始哈希值就会发生变化，进而两个汇总哈希值是不同的；若客户端上该应用程序的待检查文件没有被篡改，获取到的待检查文件的哈希值相较于待检查文件的初始哈希值是相同的，进而两个汇总哈希值也相同。

在本实施例中通过将多个待检查文件的哈希值拼接组合成字符串，并获取字符串的哈希值，得到第一汇总哈希值，同理对从索引文件中获取到的待检查文件的哈希值进行拼接组合操作，得到第二汇总哈希值，通过比较第一汇总哈希值与第二汇总哈希值，即可确定待检查文件是否发生篡改。即通过一次比较操作，实现了快速地确定待检查文件是否发生篡改的目的。

在其他实施例中，在待检查文件的个数较少的情况下，还可以采用依次比较每个待检查文件的哈希值的方式确定待检查文件是否发生篡改。

S209、确定所述待检查文件被篡改；

在确定待检查文件已经被篡改了，为了避免启动运行该应用程序导致存在安全隐患的问题，本实施例中在确定待检查文件被篡改后，执行步骤S210-S211的操作。

S210、删除存储的已经安装的应用程序的版本信息；

本实施例中，客户端预先设置存储文件，存储文件用于存储客户端安装的应用程序的版本信息、版本更新时间和增量包的哈希值，其中，增量包的哈希值指的是增量包这一整体压缩包的哈希值。本实施例中，存储文件以xml格式维护。

删除存储文件中存储的客户端安装的应用程序的版本号，当然也可以同时删除存储文件中存储的版本更新时间和增量压缩包的哈希值。

S211、在启动运行该应用程序时，将存储的该应用程序的版本信息以及与该版本信息对应的增量包的哈希值发送至服务器，使得服务器接收到版本信息为空后重新下发与该应用程序对应的全量包；其中，若所述待检查文件未被篡改，则服务器接收到版本信息后判断接收到的版本信息与服务器存储的版本信息不同且接收到的与版本信息对应的增量包的哈希值与服务器存储的上一个版本信息对应的增量包的哈希值相同后下发与新生成的该应用程序的版本信息对应的增量包。

步骤S201-S210是在客户端的电子设备开机启动时执行，步骤S211为在接收到客户端的用户对已经安装的应用程序的启动运行命令后执行。

以客户端为移动终端为例，如手机，手机的显示界面上显示有安装的各个应用程序的应用图标，用户通过点击应用图标即可触发该应用程序的启动运行操作。

在启动运行该应用程序时，将存储文件中存储的该应用程序的版本信息以及与该版本信息对应的增量包的哈希值发送至服务器。

若该应用程序的待检查文件已经被篡改，那么，已经将存储文件中存储的该应用程序的版本信息删除，因此，服务器接收到的版本信息为空，或者为没有接收到客户端发送的版本信息，则服务器重新下发与该应用程序对应的全量包，全量包为服务器当前存储的该应用程序的最新版本的全量包。

若所述待检查文件未被篡改，则服务器接收到版本信息后判断接收到的版本信息与服务器存储的版本信息不同，且接收到的与版本信息对应的增量包的哈希值与服务器存储的上一个版本信息对应的增量包的哈希值相同后下发与新生成的该应用程序的版本信息对应的增量包。

其中，服务器接收到的版本信息与服务器存储的版本信息不同，但接收到增量包的哈希值与服务器存储的上一个版本信息对应的增量包的哈希值相同，说明客户端安装的应用程序的版本与服务器当前存储的该应用程序的最新版本之间相差不大，可以直接从服务器下载该应用程序的增量包以完成对客户端安装的应用程序的版本升级。

还有一种可能为服务器接收到的版本信息与服务器存储的版本信息不同，且接收到的增量包的哈希值与服务器存储的上一个版本信息对应的增量包的哈希值不同，说明客户端安装的应用程序的版本与服务器当前存储的该应用程序的最新版本之间相差较大，需要从服务器下载该应用程序的全量包以完成对客户端安装的应用程序的版本升级。

在实际应用中，由于存在用户在一定时间内都没有使用某个应用程序的情况，进而在用户不使用该应用程序的时间段内，客户端并未启动运行该应用程序，因此不会将该应用程序的版本信息以及与该版本信息对应的增量包的哈希值发送至服务器。

但是，在用户不使用该应用程序的时间段内，服务器端可能已经存储有该应用程序的多个增量包，在这种情况下，在用户启动运行该应用程序时，将该应用程序的版本信息以及与该版本信息对应的增量包的哈希值发送至服务器，服务器查找与该应用程序的版本信息相同的版本信息对应的增量包的哈希值，若相同，则将服务器存储的版本信息高于客户端的该应用程序的版本信息对应的增量包全部下发至客户端；若不同，则将服务器存储的该应用程序的最新版本的全量包下发至客户端。

一种实现方式为，服务器可以查找10个版本信息范围内版本信息对应的增量包的哈希值。

从上述技术方案可知，本实施例中安装应用程序后，获取安装应用程序的待检查文件的哈希值，以及从与该应用程序对应的全量包中获取索引文件，从所述索引文件中获取与待检查文件对应的哈希值，然后判断获取到的待检查文件的哈希值以及索引文件中与待检查文件对应的哈希值是否相同。若待检查文件的哈希值与索引文件中待检查文件的哈希值不同，则确定待检查文件发生了篡改，否则，确定待检查文件没有被篡改。实现了对客户端中存储的该应用程序的文件是否发生了篡改的检查，避免了在发生篡改的情况下启动并运行应用程序导致发生安全隐患问题的产生。

本实施例还提供了一种检查文件篡改的方法，应用于服务器端，参见图3，该实施例包括以下步骤：

S301、根据待打包资源文件信息，生成索引文件；

生成应用程序的全量包或增量包的方式都是获取资源文件，并将资源文件打包生成全量包或增量包。全量包与增量包的区别仅在于包括的资源文件是不同的。

在本实施例中，服务器生成增量包的同时生成新的全量包，其中，新的全量包中也包括增量包中的资源文件。同时，在生成增量包时生成增量包的索引文件，生成全量包时生成全量包的索引文件。

索引文件包括资源文件名称、相对路径、哈希值、文件大小等内容。其中，资源文件名称、相对路径、哈希值、资源文件大小之间是一一对应的，即索引文件中存储有打包的各个资源文件的文件名称、相对路径、哈希值、文件大小等内容。本实施例中，采用xml格式维护索引文件。如图4所示，为本实施例中提供的索引文件存储内容的示意图。

S302、压缩索引文件以及与待打包资源文件信息对应的资源文件，生成数据包；其中，数据包为全量包或增量包；

以全量包为例，将全量包中包括的资源文件以及索引文件打包生成一个全量包。

一种实现方式为通过增加压缩文件索引的方式创建压缩方法，具体为调用GZipStream组件提供的压缩方法，将生成的索引文件和所有资源文件依次写进压缩文件流中。压缩文件流的结构如下表1所示。

表1

压缩文件流的结构由索引长度+索引文件数据+资源文件索引+资源文件的压缩数据四部分组成。

其中，表1中索引长度用于标识索引文件在压缩文件流中的位置；索引文件数据用于存储索引文件的内容；资源文件索引用于标识资源文件在压缩文件流中的位置；资源文件的压缩数据用于存储各个资源文件的内容。

S303、将所述数据包发送至客户端，使得客户端获取到所述数据包后安装应用程序。

从上述技术方案可知，本实施例中服务器在打包生成数据包时，除了将资源文件添加进数据包，同时，还将索引文件添加进数据包，使得客户端获取到数据包后，可以获取数据包中的索引文件，并根据索引文件中包括的资源文件的哈希值与客户端本地存储的资源文件的哈希值比对，进而确定客户端存储的资源文件是否被篡改。同时，本实施例中在打包生成数据包时，对每个待打包的资源文件进行处理后顺序加入压缩文件流中，相较于现有技术中对全部资源文件整体进行处理后打包的方式，本实施例中在需要获取压缩文件流中的某个资源文件时可以根据索引文件直接从压缩文件流中获取到该资源文件，而不用对整个压缩文件流先全部解压后，从解压后的文件中获取某个资源文件。由于不涉及对数据巨大的压缩数据流的解压操作，因此避免了解压操作耗费时间长的问题产生。

本实施例还提供了另一种检查文件篡改的方法，参见图5所示，该实施例包括以下步骤：

S401、根据待打包资源文件信息，生成索引文件；

S402、压缩索引文件以及与待打包资源文件信息对应的资源文件，生成数据包；

S403、将所述数据包发送至客户端，使得客户端获取到所述数据包后安装应用程序；

本实施例中步骤S401-步骤S403的实现方式与上一实施例中步骤S301-S303的实现方式类似，此处不再赘述。

下面详细介绍服务器接收到客户端发送的信息后，检测到应用程序需要更新并且实现更新的方法。

S404、接收客户端发送的版本信息以及与所述版本信息对应的增量包的哈希值；

客户端发送的版本信息为客户端当前安装的应用程序的版本号；增量包的哈希值为增量包这一整体数据包的哈希值，可以理解为是增量包中各个资源文件汇总后的哈希值。

S405、判断客户端的版本信息与服务器存储的该应用程序的版本信息是否相同，客户端的增量包的哈希值与服务器存储的上一个版本信息对应的增量包的哈希值是否相同；

若判断客户端的版本信息与服务器存储的该应用程序的版本信息不同，且客户端的增量包的哈希值与服务器存储的上一个版本信息对应的增量包的哈希值相同，则执行步骤S406；

若判断客户端的版本信息与服务器存储的该应用程序的版本信息不同，且客户端的增量包的哈希值与服务器存储的上一个版本信息对应的增量包的哈希值不同，则执行步骤S407；

若服务器接收到的版本信息与服务器存储的版本信息不同，但接收到增量包的哈希值与服务器存储的上一个版本信息对应的增量包的哈希值相同，说明客户端安装的应用程序的版本与服务器当前存储的该应用程序的最新版本之间相差不大，可以直接从服务器下载该应用程序的增量包以完成对客户端安装的应用程序的版本升级。

若服务器接收到的版本信息与服务器存储的版本信息不同，且接收到的增量包的哈希值与服务器存储的上一个版本信息对应的增量包的哈希值不同，说明客户端安装的应用程序的版本与服务器当前存储的该应用程序的最新版本之间相差较大，需要从服务器下载该应用程序的全量包以完成对客户端安装的应用程序的版本升级。

S406、将服务器新生成的增量包发送至客户端；

S407、将服务器新生成的全量包发送至客户端。

从上述技术方案可知，本实施例中服务器在打包生成数据包时，除了将资源文件添加进数据包，同时，还将索引文件添加进数据包，使得客户端获取到数据包后，可以获取数据包中的索引文件，并根据索引文件中包括的资源文件的哈希值与客户端本地存储的资源文件的哈希值比对，进而确定客户端存储的资源文件是否被篡改。同时，本实施例中在打包生成数据包时，对每个待打包的资源文件进行处理后顺序加入压缩文件流中，相较于现有技术中对全部资源文件整体进行处理后打包的方式，本实施例中在需要获取压缩文件流中的某个资源文件时可以根据索引文件直接从压缩文件流中获取到该资源文件，而不用对整个压缩文件流先全部解压后，从解压后的文件中获取某个资源文件。由于不涉及对数据巨大的压缩数据流的解压操作，因此避免了解压操作耗费时间长的问题产生。

对应上述文件篡改的检查方法，本发明还提供了一种文件篡改的检查装置，所述检查装置集成到客户端，如移动设备、笔记本电脑、台式电脑等电子设备。

所述检查装置的结构示意图请参阅图6所示，本实施例中检查装置包括：

第一获取单元501、第二获取单元502、第三获取单元503、判断单元504和确定单元505；

第一获取单元501，用于获取待检查文件的哈希值；其中，所述待检查文件为根据从服务器获取到的数据包安装应用程序后生成的文件；其中，所述数据包为全量包或增量包；

第二获取单元502，用于从全量包中获取索引文件，所述索引文件中存储有与全量包中各个文件分别对应的哈希值；

第三获取单元503，用于从所述索引文件中获取与所述待检查文件对应的哈希值；

判断单元504，用于判断待检查文件的哈希值与所述索引文件中与该待检查文件对应的哈希值是否相同；

确定单元505，用于若判断待检查文件的哈希值与所述索引文件中与该待检查文件对应的哈希值不同，则确定所述待检查文件被篡改。

从上述技术方案可知，本实施例中安装应用程序后，获取安装应用程序的待检查文件的哈希值，以及从与该应用程序对应的全量包中获取索引文件，从所述索引文件中获取与待检查文件对应的哈希值，然后判断获取到的待检查文件的哈希值以及索引文件中与待检查文件对应的哈希值是否相同。若待检查文件的哈希值与索引文件中待检查文件的哈希值不同，则确定待检查文件发生了篡改，否则，确定待检查文件没有被篡改。实现了对客户端中存储的该应用程序的文件是否发生了篡改的检查，避免了在发生篡改的情况下启动并运行应用程序导致发生安全隐患问题的产生。

对应上述文件篡改的检查方法，本发明还提供了另一种文件篡改的检查装置，所述检查装置集成到服务器。

所述检查装置的结构示意图请参阅图7所示，本实施例中检查装置包括：

生成单元601、压缩单元602和发送单元603；

生成单元601，用于根据待打包资源文件信息，生成索引文件；

压缩单元602，用于压缩索引文件以及与待打包资源文件信息对应的资源文件，生成数据包；

发送单元603，用于将所述数据包发送至客户端，使得客户端获取到所述数据包后安装应用程序。

从上述技术方案可知，本实施例中服务器在打包生成数据包时，除了将资源文件添加进数据包，同时，还将索引文件添加进数据包，使得客户端获取到数据包后，可以获取数据包中的索引文件，并根据索引文件中包括的资源文件的哈希值与客户端本地存储的资源文件的哈希值比对，进而确定客户端存储的资源文件是否被篡改。同时，本实施例中在打包生成数据包时，对每个待打包的资源文件进行处理后顺序加入压缩文件流中，相较于现有技术中对全部资源文件整体进行处理后打包的方式，本实施例中在需要获取压缩文件流中的某个资源文件时可以根据索引文件直接从压缩文件流中获取到该资源文件，而不用对整个压缩文件流先全部解压后，从解压后的文件中获取某个资源文件。由于不涉及对数据巨大的压缩数据流的解压操作，因此避免了解压操作耗费时间长的问题产生。

对应上述文件篡改的检查方法，本发明还提供了一种文件篡改的检查系统，包括客户端和服务器端，客户端采用图1或图2所示的文件篡改的检查方法，服务器应用如图3或图5所示的文件篡改的检查方法。

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

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

对所公开的实施例的上述说明，使本领域技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (10)

1.一种文件篡改的检查方法，其特征在于，包括：

获取待检查文件的哈希值；其中，所述待检查文件为根据从服务器获取到的数据包安装应用程序后生成的文件；其中，所述数据包为全量包或增量包；

从全量包中获取索引文件，所述索引文件中存储有与全量包中各个文件分别对应的哈希值；

从所述索引文件中获取与所述待检查文件对应的哈希值；

判断待检查文件的哈希值与所述索引文件中与该待检查文件对应的哈希值是否相同；

若判断待检查文件的哈希值与所述索引文件中与该待检查文件对应的哈希值不同，则确定所述待检查文件被篡改。

2.根据权利要求1所述的方法，其特征在于，若待检查文件为多个，则判断待检查文件的哈希值与所述索引文件中与该待检查文件对应的哈希值是否相同包括：

将获取到的每个待检查文件的哈希值组合成第一字符串；

获取所述第一字符串的哈希值，得到第一汇总哈希值；

将分别从所述索引文件中获取到的与每个待检查文件对应的哈希值组合成第二字符串；

获取所述第二字符串的哈希值，得到第二汇总哈希值；

判断所述第一汇总哈希值与所述第二汇总哈希值是否相同。

3.根据权利要求1所述的方法，其特征在于，所述确定所述待检查文件被篡改之后，还包括：

删除存储的已经安装的应用程序的版本信息；

在启动运行该应用程序时，将存储的该应用程序的版本信息以及与该版本信息对应的增量包的哈希值发送至服务器，使得服务器接收到版本信息为空后重新下发与该应用程序对应的全量包；其中，若所述待检查文件未被篡改，则服务器接收到版本信息后判断接收到的版本信息与服务器存储的版本信息相同且接收到的与版本信息对应的增量包的哈希值与服务器存储的上一个版本信息对应的增量包的哈希值相同后下发与新生成的该应用程序的版本信息对应的增量包。

4.根据权利要求3所述的方法，其特征在于，接收到增量包后，还包括：

将所述增量包中包括的各个文件合并到本地的全量包中，更新所述本地的全量包的文件；

将所述增量包的索引文件合并到所述本地的全量包的索引文件中，更新所述本地的全量包的索引文件。

5.一种文件篡改的检查方法，其特征在于，包括：

根据待打包资源文件信息，生成索引文件；

压缩索引文件以及与待打包资源文件信息对应的资源文件，生成数据包；

将所述数据包发送至客户端，使得客户端获取到所述数据包后安装应用程序。

6.根据权利要求5所述的方法，其特征在于，所述压缩索引文件以及与待打包资源文件信息对应的资源文件，生成数据包包括：

由索引长度、索引文件数据、待打包资源文件信息对应的资源文件的索引数据以及待打包资源文件信息对应的资源文件组成压缩包文件流；

对压缩包文件流进行压缩，生成全量包。

7.根据权利要求5所述的方法，其特征在于，还包括：

接收客户端发送的版本信息以及与所述版本信息对应的增量包的哈希值；

判断客户端的版本信息与服务器存储的该应用程序的版本信息是否相同，客户端的增量包的哈希值与服务器存储的上一个版本信息对应的增量包的哈希值是否相同；

若判断客户端的版本信息与服务器存储的该应用程序的版本信息不同，且客户端的增量包的哈希值与服务器存储的上一个版本信息对应的增量包的哈希值相同，将服务器新生成的增量包发送至客户端；

若判断客户端的版本信息与服务器存储的该应用程序的版本信息不同，且客户端的增量包的哈希值与服务器存储的上一个版本信息对应的增量包的哈希值不同，则将服务器新生成的全量包发送至客户端。

8.一种文件篡改的检查装置，其特征在于，应用于客户端，包括：

第一获取单元，用于获取待检查文件的哈希值；其中，所述待检查文件为根据从服务器获取到的数据包安装应用程序后生成的文件；其中，所述数据包为全量包或增量包；

第二获取单元，用于从全量包中获取索引文件，所述索引文件中存储有与全量包中各个文件分别对应的哈希值；

第三获取单元，用于从所述索引文件中获取与所述待检查文件对应的哈希值；

判断单元，用于判断待检查文件的哈希值与所述索引文件中与该待检查文件对应的哈希值是否相同；

确定单元，用于若判断待检查文件的哈希值与所述索引文件中与该待检查文件对应的哈希值不同，则确定所述待检查文件被篡改。

9.一种文件篡改的检查装置，其特征在于，应用于服务器，包括：

生成单元，用于根据待打包资源文件信息，生成索引文件；

压缩单元，用于压缩索引文件以及与待打包资源文件信息对应的资源文件，生成数据包；

发送单元，用于将所述数据包发送至客户端，使得客户端获取到所述数据包后安装应用程序。

10.一种文件篡改的检查系统，其特征在于，包括客户端以及与客户端连接的服务器；

所述客户端应用如权利要求1-4任意一项所述的文件篡改的检查方法；

所述服务器应用如权利要求5-7任意一项所述的文件篡改的检查方法。