WO2016019790A1

WO2016019790A1 - Verification method, client, server and system for installation package

Info

Publication number: WO2016019790A1
Application number: PCT/CN2015/084272
Authority: WO
Inventors: 陈桌升; 杨允乐; 王传举
Original assignee: 优视科技有限公司
Priority date: 2014-08-04
Filing date: 2015-07-16
Publication date: 2016-02-11
Also published as: CN105320535B; CN105320535A

Abstract

A verification method, client, server and system for an installation package. The method comprises: acquiring a signature value of a first APK in a C language environment (S101); using the signature value of the first APK to perform first encryption processing on a request parameter for requesting a network data, to obtain an encrypted byte stream (S102); sending the encrypted byte stream to a server, for the server to decode the encrypted byte stream by means of a pre-configured signature value of a second APK (S103), wherein the second APK is an original APK; and receiving information returned when the server fails to decode the request parameter and used for identifying the first APK as a tampered APK (S104).By utilizing the method, a verification logic of the installation package can be prevented from being decompiled, and the reliability for verifying the installation package is improved.

Description

Method for verifying installation package, client, server and system

Technical field

The present invention relates to the field of data processing of mobile communications, and more particularly to a method, a client, a server and a system for verifying an installation package.

Background of the invention

With the popularity of the Android platform, many excellent Android installation packages have been tampered with by lawless elements: or implanted with malicious viruses; or add ads, and then re-enter the channel through secondary packaging.

For the anti-tampering of the installation package, the current market mainly uses the tamper-proof verification scheme, and the verification process is implemented in the Java language. The verification process is as follows: in the NDK (Native Development Kit) layer, the Java language is used to obtain the APK. Signature value, check whether the APK (Android Package, Android installation package) signature value matches the pre-configured APK signature value; if it matches, the APK is genuine and has not been tampered with; if it does not match, the APK has been tampered with.

However, since Java is an interpreted language, it runs in the virtual machine environment in the form of intermediate code during verification. This makes the check logic easy to be decompiled, and the check logic is restored or deleted in '*.smali'. This will not achieve the purpose of the installation package verification, reducing the reliability of the installation package inspection.

Summary of the invention

The object of the present invention is to provide a verification method, a client, a server and a system for an installation package, which can prevent the verification logic of the installation package from being decompiled and improve the reliability of the installation package inspection.

According to an aspect of the present invention, a verification method of an installation package is provided, comprising the steps of:

Obtaining a signature value of the first APK; and performing a first encryption process on the request parameter for requesting the network data by using the signature value of the first APK to obtain an encrypted byte stream; and sending the encrypted byte stream to the server, And the server decrypts the encrypted byte stream by using a signature value of the pre-configured second APK; wherein the second APK is an original APK; and receiving the identifier for returning when the server does not decrypt the request parameter The first APK is information about the tampering APK.

Preferably, the signature value of the first APK is obtained in a C language environment.

Preferably, the encrypted byte stream is in the form of a *.so file.

According to another aspect of the present invention, a verification method of an installation package is provided, comprising the steps of:

Receiving, by the client, an encrypted byte stream, where the encrypted byte stream is obtained by encrypting a request parameter for requesting network data by using a signature value of the first APK acquired by the client; a signature value of the second APK, decrypting the encrypted byte stream; wherein the second APK is an original APK; if the request parameter is not decrypted, returning to the client for identifying the first APK as being tampered with APK information.

Preferably, the client obtains the signature value of the first APK in the C language environment.

Preferably, the encrypted byte stream is in the form of a *.so file.

The client obtains the signature value of the first APK; the client performs a first encryption process on the request parameter for requesting the network data by using the signature value of the first APK to obtain an encrypted byte stream; the client encrypts the encrypted byte. Sending to the server; the server decrypting the encrypted byte stream by using a pre-configured second APK signature value; wherein the second APK is an original APK; if the request parameter is not decrypted, then the client The terminal returns information for identifying that the first APK is a tampered APK.

Preferably, the encrypted byte stream is in the form of a *.so file.

The client obtains the signature value of the first APK;

The client determines whether the signature value of the first APK is equal to the signature value of the pre-configured second APK; wherein the second APK is the original APK; if the determination result is no, the client returns to identify the first APK as being tampered with If the result of the determination is yes, the client uses the signature value of the first APK to perform a first encryption process on the request parameter for requesting the network data to obtain an encrypted byte stream;

The client sends the encrypted byte stream to the server, so that the server decrypts the encrypted byte stream by using the signature value of the pre-configured second APK;

The client receives information returned by the server for identifying the first APK as the original APK when the server decrypts the request parameter; and when the server does not decrypt the request parameter, the server returns the identifier for identifying the first APK to be tampered with APK information.

Preferably, the encrypted byte stream is in the form of a *.so file.

According to another aspect of the present invention, a client is provided, including:

a first acquiring unit, configured to acquire a signature value of the first APK;

An encryption unit, configured to perform, by using a signature value of the first APK, a first encryption process on a request parameter used to request network data, to obtain an encrypted byte stream;

a first sending unit, configured to send the encrypted byte stream to a server, where the server decrypts the encrypted byte stream by using a pre-configured second APK signature value; wherein the second APK is a raw APK ;

And a first receiving unit, configured to receive, when the server does not decrypt the request parameter, information used to identify the first APK as a tampered APK.

Preferably, the first obtaining unit acquires the signature value of the first APK in a C language environment.

Preferably, the encrypted byte stream is in the form of a *.so file.

According to another aspect of the present invention, a server is provided, comprising:

a second receiving unit, configured to receive an encrypted byte stream sent by the client, where the encrypted byte stream is obtained by encrypting a request parameter for requesting network data by using a signature value of the first APK acquired by the client of;

a decrypting unit, configured to decrypt the encrypted byte stream by using a signature value of a pre-configured second APK; wherein the second APK is an original APK;

The second sending unit is configured to return, to the client, information for identifying that the first APK is a tampered APK if the request parameter is not decrypted.

Preferably, the encrypted byte stream is in the form of a *.so file.

According to another aspect of the present invention, a verification system for an installation package is provided, comprising: the above client and the server.

With the solution of the present invention, the client preferably obtains the signature value of the APK in the C language environment and uses the signature value to encrypt the network data request of the APK and sends the encrypted byte stream to the server for verification, because the above process logic is in C After compiling in the language, the '*.so file' is generated. It is difficult to crack the logic in the '*.so file' by the decompilation tool. The solution to the technical difficulty is much more complicated than the one achieved by using the Java language. On the server side, Decrypting the encrypted byte stream by using the signature value of the pre-configured original APK. If the network data request is successfully decrypted, the original APK is installed on the client, and if the network data request cannot be decrypted, It means that the tamper-proof APK is installed on the above client, so that the related function of the client with the tamper-proof APK installed can be prohibited. Therefore, by the above processing, it is possible to prevent the check logic of the APK from being decompiled, and to improve the reliability of the installation package check.

In order to achieve the above objects, the one or more aspects of the present invention include the features which are described in detail below and particularly pointed out in the claims. The following description and the annexed drawings set forth in detail However, these aspects indicate that only the invention can be used. Some of the ways in which the principles are. Furthermore, the invention is intended to cover all such aspects and their equivalents.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and other objects, features and advantages of the present invention will become more apparent from the Detailed Description In the drawing:

1 is a flow chart showing a verification method of an installation package proposed by the present invention;

2 is another flow chart showing a verification method of an installation package proposed by the present invention;

3 is another flow chart showing a verification method of an installation package proposed by the present invention;

4 is another flow chart showing a verification method of an installation package proposed by the present invention;

FIG. 5 is a schematic structural diagram of a client according to the present invention; FIG.

FIG. 6 is a schematic diagram showing another structure of a client according to the present invention;

FIG. 7 is a schematic diagram showing another structure of a client proposed by the present invention;

FIG. 8 is a schematic structural diagram of a server according to the present invention;

FIG. 9 is a block diagram showing the structure of a calibration system for an installation package according to the present invention.

The same reference numerals are used throughout the drawings to refer to the

Mode for carrying out the invention

Various aspects of the disclosure are described below. It should be understood that the teachings herein may be embodied in a variety of forms and that any specific structure, function, or both disclosed herein are merely representative. Based on the teachings herein, one of ordinary skill in the art will appreciate that one aspect disclosed herein can be implemented independently of any other aspects, and two or more of these aspects can be combined in various ways. For example, an apparatus or a method of practice can be implemented using any number of the aspects set forth herein. In addition, such an apparatus may be implemented or practiced using other structures, functions, or structures and functions in addition to or in one or more aspects than those set forth herein. Furthermore, any aspect described herein can include at least one element of the claims.

Various embodiments of the present invention will be described below with reference to the drawings.

The present invention provides a verification method for an installation package, and the flow thereof can be referred to FIG. 1; specifically, the steps include:

Step S101: Acquire a signature value of the first APK;

The first APK refers to the APK that the user downloads to the client; specifically, when the signature value of the first APK is obtained, the getSign function may be called by the getPost function to obtain the signature value of the first APK;

The C language environment is a preferred solution, that is, the signature value of the first APK is preferably implemented in a C language environment.

Step S102: Perform a first encryption process on the request parameter for requesting network data by using a signature value of the first APK, to obtain an encrypted byte stream.

Specifically, the getPost function may be used to call the encodeData function to perform the first encryption process on the request parameter of the request network data by using the signature value of the first APK as the encryption key to obtain an encrypted byte stream. The encryption algorithm used in the first encryption process is a reversible symmetric algorithm, such as a DES algorithm, an RC5 algorithm, or an M9 encryption algorithm.

Preferably, the encrypted byte stream is in the form of a *.so file.

Then proceeding to step S103: sending the encrypted byte stream to the server, so that the server decrypts the encrypted byte stream by using the signature value of the pre-configured second APK;

The second APK is the original APK; in step S101 and step S102 in the C language environment, and the encrypted byte stream is sent to the server, since the above process logic is compiled in the C language to generate a '*.so file', It is very difficult to crack the logic in the '*.so file' by decompilation tools, which greatly increases the technical difficulty of cracking than the implementation using Java language.

Step S104: Receive information for identifying that the first APK is a tampered APK when the server does not decrypt the request parameter. The information returned when the server decrypts the request parameter is used to identify that the first APK is the original APK.

The above mentioned functions getPost, getSign, encodeData, the implementation process is located in the Android NDK layer, implemented in C language, belongs to the system native code, will generate ‘*.so after compilation File ', such files cannot be decompiled with decompilation tools.

With the present invention, the client obtains the signature value of the APK in the C language environment and encrypts the network data request of the APK by using the signature value, and sends the encrypted byte stream to the server for verification, because the above process logic is performed in the C language. After compiling, the '*.so file' is generated. It is very difficult to crack the logic in the '*.so file' by decompilation tool. The solution is much more difficult to solve in the technical difficulty than using the Java language. On the server side, the pre-configuration is utilized. The signature value of the original APK to decrypt the encrypted byte stream. If the above network data request can be successfully decrypted, the original APK installed on the client may not decrypt the above network data request, indicating the above client. The tamper-proof APK is installed on the side, so that the related functions of the client with the tamper-proof APK can be disabled; therefore, the check logic of the APK can be prevented from being decompiled, and the reliability of the package inspection is improved.

In order to further prevent the check logic of the APK from being decompiled and improve the reliability of the installation package detection, in the above embodiment, in step S102, the first encryption of the request parameter for requesting the network data is performed by using the signature value of the first APK. The processing may be performed as follows: 1) performing a second encryption process on the signature value of the first APK according to a predetermined algorithm to obtain a signature value of the encrypted first APK; specifically, when performing the second encryption process, The getKey function may be called by the getPost function to encrypt the signature value of the APK according to a predetermined algorithm; wherein the predetermined algorithm may be an md5 encryption algorithm or an algorithm capable of generating a fixed length string; 2) using the encrypted first The signature value of the APK performs a first encryption process on the request parameters used to request the network data.

Correspondingly, after the encrypted byte stream is sent to the server in step S103, the server decrypts the encrypted byte stream by using a pre-configured signature value of the second APK encrypted by the predetermined algorithm. That is to say, the way to encrypt the client and decrypt it in the server is pre-agreed. This method is only known by the client and the server, and since it is performed in the C language environment, this method will not be decompiled. Obtained to ensure full security.

In an aspect of the present invention, the initial detection of the APK may be performed on the client first, and only after the initial detection, the installation package detection after step S102 in the above embodiment is performed. An optional method for initial detection is to detect the APK signature value; specifically, the initial detection is performed after step S101, including the steps:

The client compares the signature value of the first APK with the signature value of the second APK pre-configured on the client. If they are equal, the client performs the detection process of step S102 and subsequent; if not, returns the identifier for The first APK is information of the tampering APK.

Another optional method for initial detection is to obtain the CRC (Cyclical Redundancy Check) value of the dex (type of executable file on the Android platform) file, and compare the obtained CRC value with the pre-configured CRC value. Specifically, the initial detection is performed after step S101, including the steps:

The client obtains the CRC value of the dex file of the first APK;

The client compares the CRC value of the dex file with a pre-configured CRC value, wherein the pre-configured CRC value is a CRC value of a dex file of the original APK;

When the CRC value of the dex file is equal to the pre-configured CRC value, the client performs the above-described step S102 and the subsequent detection process. If the CRC value of the dex file is not equal to the pre-configured CRC value, information indicating that the first APK is the tampered APK is returned.

Another alternative to the initial detection is to perform a first detection (or first comparison) of the APK signature value, and a second detection of the CRC value of the dex file when the detection result is yes (or The second comparison); specifically, the initial detection is performed after step S101, including the steps:

The client compares the signature value of the first APK with the signature value of the second APK pre-configured on the client. If they are equal, the client obtains the CRC value of the dex file and compares it with the pre-configured CRC value; if not, Returning information for identifying the first APK as a tampered APK;

When the CRC value of the dex file is equal to the pre-configured CRC value, the client performs the S102 step and the subsequent detection process; if not, returns information for identifying the first APK as the tampered APK.

As long as the APK is decompiled, the dex file will change and the CRC value will change. Cause According to the CRC value of the dex file, it can be initially determined whether the first APK has been tampered with.

A preferred embodiment flow is shown in Figure 2, which is based on the client side. Before proceeding with the specific process, you can first confuse the code: confuse the class name and package name of the first APK into the file names strictly forbidden by the two system naming systems of Window System and Linux system, such as com1, Com1, etc. Refers to the reorganization and processing of the class name and package name of the first APK, and obtains the file name strictly prohibited by the two system naming systems of the Window system and the Linux system; then the following processing flow is performed:

Step S201: The client acquires the signature value of the first APK.

Step S202: The client determines whether the signature value of the first APK is equal to the signature value of the pre-configured second APK; wherein the second APK is the original APK; if the determination result is no, proceed to step S203; if the determination result is yes , proceeding to step S204;

Step S203: The client returns information for identifying that the first APK is a tampered APK;

Step S204: The client acquires the CRC value of the dex file of the first APK;

Step S205: The client determines whether the CRC value of the dex file is equal to the pre-configured CRC value; wherein, the pre-configured CRC value is a CRC value for reference, that is, a CRC value of the original APK dex file; when determining the dex file When the CRC value is not equal to the pre-configured CRC value, proceed to step S203; when it is determined that the CRC value of the dex file is equal to the pre-configured CRC value, proceed to step S206;

Step S206: The client uses the signature value of the first APK to perform a first encryption process on the request parameter for requesting the network data, to obtain an encrypted byte stream. Specifically, the client may also first sign the first APK according to a predetermined algorithm. The value is subjected to encryption processing; and then the first encryption processing is performed by requesting the request parameter of the network data according to the encrypted signature value of the first APK.

Step S207: The client sends the encrypted byte stream to the server, so that the server decrypts the encrypted byte stream by using the signature value of the pre-configured second APK. Specifically, in step S206, according to the encrypted first APK. When the signature value is used to request the request parameter of the network data to perform the first encryption process, the server decrypts the encrypted byte stream by using the pre-configured signature value of the second APK encrypted by the predetermined algorithm.

Step S208: The client receives, when the server decrypts the request parameter, the information returned by the server for identifying the first APK as the original APK; and when the server does not decrypt the request parameter, the first APK returned by the server is used to identify the first APK. Information for the tampering APK.

The C language environment is a preferred solution, that is, the signature value of the first APK is preferably implemented in a C language environment. Preferably, the encrypted byte stream is in the form of a *.so file.

The present invention also proposes another verification method of the installation package, which is based on the server side, and the flow thereof can be referred to FIG. 3, including the steps:

Step S301: The server receives the encrypted byte stream sent by the client, where the encrypted byte stream is encrypted by using the signature value of the first APK acquired by the client in the C language environment for requesting the network data. owned;

Step S302: The server decrypts the encrypted byte stream by using the signature value of the pre-configured second APK; wherein the second APK is the original APK;

Step S303: If the server decrypts the request parameter, the server returns information for identifying the first APK as the original APK, and if the server does not decrypt the request parameter, returns to the client to identify that the first APK is tampered with. APK information.

Preferably, the encrypted byte stream is in the form of a *.so file.

The present invention also provides another verification method for the installation package. The process can be referred to FIG. 4, which is based on the interaction between the client and the server. The specific steps include:

Step S401: The client acquires the signature value of the first APK.

Step S402: The client performs a first encryption process on the request parameter for requesting network data by using the signature value of the first APK to obtain an encrypted byte stream.

Step S403: The client sends the encrypted byte stream to the server.

Step S404: The server decrypts the encrypted byte stream by using the signature value of the pre-configured second APK; wherein the second APK is the original APK; and then proceeds to step S405 or step S406 according to the decrypted result.

Step S405: If the server decrypts the request parameter, the server returns information for identifying the first APK as the original APK.

Step S406: If the server does not decrypt the request parameter, the server returns information for identifying the first APK as the tampered APK.

Preferably, the encrypted byte stream is in the form of a *.so file.

In another aspect of the present invention, a client 801 is also provided. The structure of the client 801 is as shown in FIG. 5. The client 801 includes:

The first obtaining unit 601 is configured to acquire a signature value of the first APK.

The encryption unit 602 is configured to perform, by using a signature value of the first APK, a first encryption process on a request parameter used to request network data, to obtain an encrypted byte stream.

Preferably, the encrypted byte stream is in the form of a *.so file.

The first sending unit 603 is configured to send the encrypted byte stream to the server, so that the server decrypts the encrypted byte stream by using a pre-configured second APK signature value; wherein the second APK is an original APK;

The first receiving unit 604 is configured to receive, when the server does not decrypt the request parameter, the information that is used to identify the first APK as a tampered APK. And receiving information returned by the server when the request parameter is decrypted to identify the first APK as the original APK.

On the other hand, on the other hand, the client can also perform initial detection on the APK according to the APK signature value. Specifically, refer to FIG. 6; the client further includes:

The first comparison unit 605 is configured to compare the signature value of the first APK with the signature value of the pre-configured second APK;

a first notification unit 606, configured to: when the comparison result of the first comparison unit is equal, Notifying the encryption unit to perform a first encryption process on the request parameter for requesting the network data; and when the comparison result of the first comparison unit is unequal, returning information for identifying the first APK as the tampered APK; The second APK is the original APK.

On the other hand, on the other hand, the client can also perform initial detection on the APK according to the CRC value. Specifically, referring to FIG. 7, the client further includes:

a second obtaining unit 607, configured to acquire a CRC value of a dex file of the first APK;

The second comparison unit 608 is configured to compare the CRC value of the dex file with the pre-configured CRC value;

The second notification unit 609 is configured to notify the encryption unit to perform a first encryption process on the request parameter for requesting network data when the comparison result of the second comparison unit is equal; and when the comparison result of the second comparison unit is unequal And returning information for identifying the first APK as the tampered APK; wherein the pre-configured CRC value is a CRC value of the dex file of the original APK.

On the other hand, on the other hand, the client can also perform initial detection on the APK according to the APK signature value and the CRC value. Specifically, the client also includes:

a third comparing unit, configured to compare a signature value of the first APK with a signature value of a pre-configured second APK;

a third acquiring unit, configured to acquire a CRC value of the dex file of the first APK when the comparison result of the third comparing unit is equal;

a fourth comparing unit, configured to compare a CRC value of the dex file acquired by the third acquiring unit with a pre-configured CRC value;

a third notification unit, configured to notify the encryption unit to perform a first encryption process on a request parameter for requesting network data when the comparison result of the fourth comparison unit is equal; when the third comparison unit or the fourth comparison When the comparison result of the units is unequal, the information for identifying the first APK as the falsified APK is returned; wherein the pre-configured CRC value is the CRC value of the dex file of the original APK.

In another aspect of the present invention, a server 802 is also proposed, the structure diagram of which can be referred to Referring to Figure 8, server 802 includes:

The second receiving unit 701 is configured to receive an encrypted byte stream sent by the client, where the encrypted byte stream is a request for requesting network data by using a signature value of the first APK acquired by the client in a C language environment. The parameters are obtained by encryption processing;

The decryption unit 702 is configured to decrypt the encrypted byte stream by using a signature value of the second APK configured in advance; wherein the second APK is an original APK;

The second sending unit 703 is configured to: if the request parameter is decrypted, return information for identifying the first APK as the original APK to the client; if the request parameter is not decrypted, return the identifier for the client The first APK is information of the tampering APK.

In another aspect of the present invention, a verification system for an installation package is also provided. Referring to FIG. 9 for a schematic structural diagram, the system includes: a client 801 shown in FIG. 5 and a server 802 shown in FIG. 8. It may also be the client of Figure 6 or Figure 7 and the server of Figure 8.

With the solution of the present invention, the client obtains the signature value of the APK in the C language environment and encrypts the network data request of the APK by using the signature value, and sends the encrypted byte stream to the server for verification, because the above process logic is in the C language. After compiling and generating *.so files, the packaging party will be difficult to crack the logic in *.so through the decompilation tool, which greatly increases the technical difficulty of the cracking than the implementation using the Java language; on the server side, the pre-configured The signature value of the original APK is used to decrypt the encrypted byte stream. If the network data request is successfully decrypted, the original APK installed on the client may not decrypt the network data request, indicating the client. The tamper-proof APK is installed on the website, so that the related functions of the client with the tamper-proof APK can be disabled; therefore, the check logic of the APK can be prevented from being decompiled, and the reliability of the package inspection is improved.

In addition, the mobile terminal of the present invention can be a variety of Bluetooth-enabled handheld terminal devices, such as a Bluetooth-enabled mobile phone, a personal digital assistant (PDA).

Furthermore, the method according to the invention can also be implemented as a computer program executed by a processor (such as a CPU) in a mobile terminal and stored in a memory of the mobile terminal. The above-described functions defined in the method of the present invention are performed when the computer program is executed by the processor.

Furthermore, the method according to the invention may also be embodied as a computer program product comprising a computer readable medium on which is stored a computer program for performing the functions described above in the method of the invention. .

Furthermore, the method steps and system units described above may also be implemented with a controller and a computer readable storage device for storing a computer program that causes the controller to implement the steps or unit functions described above.

The various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the disclosure herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described. Whether such functionality is implemented as software or as hardware depends on the particular application and design constraints imposed on the overall system. A person skilled in the art can implement the described functions in various ways for each specific application, but such implementation decisions should not be construed as causing a departure from the scope of the invention.

While the foregoing disclosure shows exemplary embodiments of the present invention, it should be understood that various changes and modifications may be made without departing from the scope of the invention. The functions, steps and/or actions of the method claims according to the embodiments of the invention described herein are not required to be performed in any particular order. In addition, although elements of the invention may be described or claimed in the form of an individual, many are contemplated, unless explicitly limited to the singular.

Although the description has been made in accordance with the various embodiments of the present invention as described above, those skilled in the art should understand that the various embodiments of the present invention described above may also be made without departing from the scope of the present invention. Improvements. Therefore, the scope of the invention should be determined by the content of the appended claims.

Claims

A method for verifying an installation package, comprising the steps of:

Obtaining a signature value of the first APK; and performing a first encryption process on the request parameter for requesting the network data by using the signature value of the first APK to obtain an encrypted byte stream;

Sending the encrypted byte stream to a server, for the server to decrypt the encrypted byte stream by using a signature value of a pre-configured second APK; wherein the second APK is an original APK;

Receiving information for identifying that the first APK is a tampered APK when the server does not decrypt the request parameter.
The method of verifying an installation package according to claim 1, wherein the step of performing a first encryption process on a request parameter for requesting network data by using a signature value of the first APK comprises:

Performing a second encryption process on the signature value of the first APK according to a predetermined algorithm to obtain a signature value of the encrypted first APK;

And performing a first encryption process on the request parameter for requesting network data by using the encrypted signature value of the first APK.
The method of verifying an installation package according to claim 2, wherein the predetermined algorithm is an algorithm that can generate a fixed-length character string; and the encryption algorithm used in the first encryption process is a reversible symmetric algorithm.
The method for verifying an installation package according to claim 1, wherein the step of acquiring the signature value of the first APK further comprises the steps of:

Comparing the signature value of the first APK with the signature value of the second APK configured in advance, and if the comparison result is equal, performing the step of performing the first encryption processing on the request parameter for requesting the network data; If the comparison result is unequal, the information for identifying the first APK as the falsified APK is returned; wherein the second APK is the original APK.
The method of verifying an installation package according to claim 1, wherein said obtaining the first After the step of signing the value of the APK, the steps are also included:

Obtaining the CRC value of the dex file of the first APK;

Comparing the obtained CRC value of the dex file with a pre-configured CRC value; when the CRC value of the dex file is equal to the pre-configured CRC value, performing the request parameter for requesting network data a step of encryption processing; and,

When the CRC value of the dex file is not equal to the pre-configured CRC value, returning information for identifying the first APK as the tampered APK; wherein the pre-configured CRC value is the dex file of the original APK CRC value.
The method of verifying an installation package according to claim 1, wherein the step of decrypting the encrypted byte stream by the server using a signature value of a pre-configured second APK comprises:

The server decrypts the encrypted byte stream by using a pre-configured signature value of the second APK encrypted by the predetermined algorithm.
The method for verifying an installation package according to claim 1, wherein the step of acquiring the signature value of the first APK further comprises the steps of:

Comparing the signature value of the first APK with the signature value of the pre-configured second APK:

If the comparison result is equal, obtaining a CRC value of the dex file of the first APK; comparing the obtained CRC value of the dex file with a pre-configured CRC value; when the CRC value of the dex file and the pre-configured CRC When the values are equal, performing the step of performing a first encryption process on the request parameter for requesting network data; when the CRC value of the dex file is not equal to the pre-configured CRC value, returning to identify the first An APK is the information of the tampered APK; wherein the pre-configured CRC value is the CRC value of the original APK dex file;

If the comparison result is not equal, returning information for identifying that the first APK is a tampered APK; wherein the second APK is the original APK.
The verification method of an installation package according to claim 1, wherein said encrypted byte stream is in the form of a *.so file.
The verification method of the installation package according to claim 1, wherein the signature value of the first APK is acquired in a C language environment.
A method for verifying an installation package, comprising the steps of:

Receiving, by the client, an encrypted byte stream, where the encrypted byte stream is obtained by encrypting a request parameter for requesting network data by using a signature value of the first APK acquired by the client;

Decrypting the encrypted byte stream with a signature value of a pre-configured second APK; wherein the second APK is an original APK;

If the request parameter is not decrypted, information indicating that the first APK is a tampered APK is returned to the client.
The verification method of an installation package according to claim 10, wherein said encrypted byte stream is in the form of a *.so file.
The verification method of the installation package according to claim 10, wherein the client obtains the signature value of the first APK in the C language environment.
A method for verifying an installation package, comprising the steps of:

The client obtains the signature value of the first APK;

The client performs a first encryption process on the request parameter for requesting network data by using the signature value of the first APK, to obtain an encrypted byte stream;

The client sends the encrypted byte stream to the server;

The server decrypts the received encrypted byte stream by using a pre-configured second APK signature value; wherein the second APK is an original APK;

If the server does not decrypt the request parameter, returning information to the client for identifying the first APK as a tampered APK.
The verification method of an installation package according to claim 13, wherein said encrypted byte stream is in the form of a *.so file.
The verification method of the installation package according to claim 13, wherein the client acquires the signature value of the first APK in a C language environment.
A method for verifying an installation package, comprising the steps of:

The client obtains the signature value of the first APK;

The client determines whether the signature value of the first APK is equal to the signature value of the pre-configured second APK; wherein the second APK is the original APK; if the determination result is no, the client returns to identify the first APK as being tampered with If the result of the determination is yes, the client uses the signature value of the first APK to perform a first encryption process on the request parameter for requesting the network data to obtain an encrypted byte stream;

The client sends the encrypted byte stream to the server, so that the server decrypts the encrypted byte stream by using the signature value of the pre-configured second APK;

The client receives information returned by the server for identifying the first APK as the original APK when the server decrypts the request parameter; and when the server does not decrypt the request parameter, the server returns the identifier for identifying the first APK to be tampered with APK information.
The verification method of an installation package according to claim 16, wherein said encrypted byte stream is in the form of a *.so file.
The verification method of the installation package according to claim 16, wherein the client acquires the signature value of the first APK in the C language environment.
The method for verifying an installation package according to claim 16, wherein the client obtains the CRC value of the dex file of the first APK when the client determines that the signature value of the first APK is equal to the signature value of the pre-configured second APK. The client determines whether the CRC value of the dex file is equal to the pre-configured CRC value; wherein, the pre-configured CRC value is the CRC value used for reference, that is, the CRC value of the original APK dex file; when determining the CRC value of the dex file If the CRC value is not equal to the pre-configured CRC, the client returns information for identifying the first APK as the falsified APK; when determining that the CRC value of the dex file is equal to the pre-configured CRC value, the client utilizes the first APK. The signature value performs a first encryption process on the request parameter used to request the network data to obtain an encrypted byte stream.
The method for verifying an installation package according to any one of claims 16 to 19, wherein the client uses the signature value of the first APK to perform the first addition of the request parameter for requesting the network data. In the case of the secret processing, the signature value of the first APK is first encrypted according to a predetermined algorithm; and then the first encryption processing is performed by requesting the request parameter of the network data according to the encrypted signature value of the first APK.
The verification method of the installation package according to claim 20, wherein, when the server decrypts the encrypted byte stream by using the signature value of the pre-configured second APK, the server uses the pre-configured second APK encrypted by the predetermined algorithm. The signature value decrypts the encrypted byte stream.
A client that includes:

a first acquiring unit, configured to acquire a signature value of the first APK;

An encryption unit, configured to perform, by using a signature value of the first APK, a first encryption process on a request parameter used to request network data, to obtain an encrypted byte stream;

a first sending unit, configured to send the encrypted byte stream to a server, where the server decrypts the encrypted byte stream by using a signature value of a pre-configured second APK; wherein the second APK is an original APK;

And a first receiving unit, configured to receive, when the server does not decrypt the request parameter, information used to identify the first APK as a tampered APK.
The client of claim 22 wherein said encrypted byte stream is in the form of a *.so file.
The client according to claim 22, wherein the first obtaining unit acquires the signature value of the first APK in a C language environment.
The client of claim 22, wherein the client further comprises:

a first comparing unit, configured to compare a signature value of the first APK with a signature value of a pre-configured second APK;

a first notification unit, configured to notify the encryption unit to perform a first encryption process on a request parameter for requesting network data when the comparison result of the first comparison unit is equal; when comparing the first comparison unit When the result is unequal, information indicating that the first APK is a tampered APK is returned; wherein the second APK is the original APK.
The client of claim 22, wherein the client further comprises:

a second acquiring unit, configured to acquire a CRC value of the dex file of the first APK;

a second comparing unit, configured to compare a CRC value of the dex file with a pre-configured CRC value;

a second notification unit, configured to: when the comparison result of the second comparison unit is equal, notify the encryption unit to perform a first encryption process on a request parameter for requesting network data; and when the comparison result of the second comparison unit is When not equal, information indicating that the first APK is a tampered APK is returned; wherein the pre-configured CRC value is a CRC value of a dex file of the original APK.
The client of claim 22, wherein the client further comprises:

a third comparing unit, configured to compare a signature value of the first APK with a signature value of a pre-configured second APK;

a third acquiring unit, configured to acquire a CRC value of the dex file of the first APK when the comparison result of the third comparing unit is equal;

a fourth comparing unit, configured to compare a CRC value of the dex file acquired by the third acquiring unit with a pre-configured CRC value;

a third notification unit, configured to notify the encryption unit to perform a first encryption process on a request parameter for requesting network data when the comparison result of the fourth comparison unit is equal; when the third comparison unit or the fourth comparison When the comparison result of the units is unequal, the information for identifying the first APK as the falsified APK is returned; wherein the pre-configured CRC value is the CRC value of the dex file of the original APK.
A server, including:

a second receiving unit, configured to receive an encrypted byte stream sent by the client, where the encrypted byte stream is obtained by encrypting a request parameter for requesting network data by using a signature value of the first APK acquired by the client of;

a decrypting unit, configured to decrypt the encrypted byte stream by using a signature value of a pre-configured second APK; wherein the second APK is an original APK;

a second sending unit, configured to: when the decryption unit does not decrypt the request parameter, Information for identifying the first APK as a tampered APK is returned to the client.
The server of claim 28, wherein the encrypted byte stream is in the form of a *.so file.
The server of claim 28, wherein the client obtains the signature value of the first APK in a C language environment.
A verification system for an installation package, comprising: the client of claim 22 and the server of claim 28.