描述本发明的各个实施例。
[0037]本发明提出一种安装包的校验方法，其流程可参考图1 ;具体的，包括步骤:
[0038]步骤S101:在C语言环境下获取第一 APK的签名值；
[0039]其中，第一 APK指的是用户下载到客户端的APK ;具体的，获取第一 APK的签名值时，可以通过getPost函数调用getSign函数获得第一 APK的签名值sign ；
[0040]步骤S102:利用第一 APK的签名值对用来请求网络数据的请求参数进行第一加密处理，得到加密字节流；
[0041]具体的，可以通过getPost函数调用encodeData函数利用第一 APK的签名值作为加密密钥对网络请求参数进行第一加密处理，得到加密字节流。其中，第一加密处理采用的加密算法为可逆对称算法，如:DES算法、RC5算法，也可以米用M9加密算法。
[0042]然后进行步骤S103:将加密字节流发送至服务器，以供服务器利用预先配置的第二 APK的签名值解密该加密字节流；
[0043]其中，第二 APK是原始APK ;在C语言环境下进行步骤S101及步骤S102，及将加密字节流发送给服务器，由于上述过程逻辑在C语言中进行编译后产生so文件’，通过反编译工具将很难破解so文件’里的逻辑，在破解技术难度上比使用Java语言实现的方案大大增加；
[0044]步骤S104:接收当服务器未解密出请求参数时返回的用于标识第一 APK为被篡改的APK的信息。其中，当服务器解密出请求参数时返回的用于标识第一 APK为原始APK的信息。
[0045]以上提到的函数getPost、getSign、encodeData,实现过程都位于 Android NDK层，用C语言实现，属于系统原生代码，编译后会产生so文件’，用反编译工具无法反编译出此类文件。
[0046]利用本发明，客户端在C语言环境中获取APK的签名值以及利用该签名值加密APK的网络数据请求并将加密后的字节流发送至服务器校验，由于上述过程逻辑在C语言中进行编译后产生‘*.so文件’，通过反编译工具将很难破解‘*.so文件’里的逻辑，在破解技术难度上比使用Java语言实现的方案大大增加；在服务器侧，利用预先配置的原始APK的签名值去解密上述加密的字节流，若能成功解密出上述网络数据请求，则说明上述客户端上安装的原始的APK，若不能解密出上述网络数据请求，则说明上述客户端上安装的是被篡改的APK，从而可以禁止安装有被篡改的APK的客户端的相关功能；因此可以防止APK的校验逻辑被反编译，提高安装包检验的可靠性。
[0047]为了进一步防止APK的校验逻辑被反编译，提高安装包检测的可靠性，针对上述实施例，在步骤S102中，利用第一 APK的签名值对用来请求网络数据的请求参数进行第一加密处理时，具体可以按以下步骤进行:1)按预定算法对该第一 APK的签名值进行第二加密处理,得到加密后的第一 APK的签名值；具体的，进行第二加密处理时，可通过getPost函数调用getKey函数根据预定算法来对APK的签名值进行加密处理；其中，预定算法可以是md5加密算法也可以是可产生固定长度字符串的算法；2)利用该加密后的第一 APK的签名值对用来请求网络数据的请求参数进行第一加密处理。
[0048]对应的，经步骤S103将加密字节流发送给服务器后，服务器利用预先配置的按该预定算法加密后的第二 APK的签名值解密该加密字节流。即是说，预先约定好在客户端加密和在服务器中解密的方式，这种方式只有客户端和服务器知道，同时由于是在C语言的环境下进行，因此这种方式不会被反编译而被获取，可以充分保证安全性。
[0049]在本发明的一个方面，可以先在客户端进行APK的初始检测，只有通过初始检测的，才进行上述实施例中步骤S102之后的安装包检测流程；初始检测的其中一个可选方法是检测APK签名值；具体的，初始检测在步骤S101之后进行，包括步骤:
[0050]客户端将第一 APK的签名值与在客户端预先配置的第二 APK的签名值进行比较，若相等，则客户端进行该S102步骤及之后的检测流程；若不相等，则返回用于标识该第一APK为被篡改的APK的信息。
[0051]初始检测的另一个可选方法是获取dex(Android平台上可执行文件的类型)文件的CRC(Cyclical Redundancy Check，循环冗余码校验)值，将获取的CRC值与预配置的CRC值比较；具体的，初始检测在步骤S101之后进行，包括步骤:
[0052]客户端获取第一 APK的dex文件的CRC值；
[0053]客户端将该dex文件的CRC值与预配置的CRC值比较，其中，预配置的CRC值为原始APK的dex文件的CRC值；
[0054]当dex文件的CRC值与预配置的CRC值相等时，客户端进行上述S102步骤及之后的检测流程。若dex文件的CRC值与预配置的CRC值不相等，则返回用于标识该第一 APK为被篡改的APK的信息。
[0055]初始检测的另一个可选方法是在检测APK签名值之后再检测dex文件的CRC值；具体的，初始检测在步骤S101之后进行，包括步骤:
[0056]客户端将第一 APK的签名值与在客户端预先配置的第二 APK的签名值进行比较，若相等，则客户端获取dex文件的CRC值；若不相等，则返回用于标识该第一 APK为被篡改的APK的信息；
[0057]当该dex文件的CRC值与预配置的CRC值相等时，客户端进行该S102步骤及之后的检测流程；若不相等，则返回用于标识第一 APK为被篡改的APK的信息。
[0058]只要APK被反编译，dex文件就会产生变化，CRC值也会改变。因此根据dex文件的CRC值，可以初步判断第一 APK是否被篡改。
[0059]一个优选的实施例流程如图2所示，该方法基于客户端侧。在进行具体流程前，可先进行代码混淆:将第一 APK的类名、包名混淆为Window系统和Linux系统两个系统命名系统严令禁止使用的文件名，如coml、Coml等，其中，混淆指的是对第一 APK的类名、包名进行重新组织和处理，得到Window系统和Linux系统两个系统命名系统严令禁止使用的文件名；然后进行以下处理流程:
[0060]步骤S201:客户端在C语言环境下获取第一 APK的签名值；
[0061]步骤S202:客户端判断第一 APK的签名值与预先配置的第二 APK的签名值是否相等；其中，第二 APK为原始APK ;若判断结果为否，则进行步骤S203 ;若判断结果为是，则进行步骤S204 ；
[0062]步骤S203:客户端返回用于标识第一 APK为被篡改的APK的信息；
[0063]步骤S204:客户端获取第一 APK的dex文件的CRC值；
[0064]步骤S205:客户端判断dex文件的CRC值与预配置的CRC值是否相等；其中，预配置的CRC值是用于参考的CRC值，即原始APK的dex文件的CRC值；当判断dex文件的CRC值与预配置的CRC值不相等时，进行步骤S203 ；当判断dex文件的CRC值与预配置的CRC值相等时，进行步骤S206 ；
[0065]步骤S206:客户端利用第一 APK的签名值