Application verification method and device, equipment and storage medium

Abstract

The invention provides an application program verification method and device, equipment and a storage medium, relates to the technical field of software engineering, and is used for avoiding damage to rights and interests of a user due to the fact that an APP is secondarily packaged. The method is applied to the mobile terminal and comprises the steps that the mobile terminal determines an MD5 value of a local file of a to-be-verified application program; and encrypting the MD5 value of the local file to obtain a to-be-verified field. Further, the mobile terminal sends the version number of the to-be-verified application program and the to-be-verified field to a server corresponding to the to-be-verified application program, so that the server performs comparison verification on the to-be-verified field according to a standard field corresponding to the version number; and obtaining a verification result sent by the server, and terminating the operation of the to-be-verified application program under the condition that the verification result is verification failure.

Description

Technical Field

[0001] The present application relates to the field of software engineering technology, and in particular to an application verification method, device, equipment and storage medium. Background Art

[0002] In recent years, the mobile Internet has developed rapidly, and smart mobile devices have become popular rapidly. However, the mobile security issues caused by this have also become increasingly prominent, especially in the open Android ecosystem, where secondary packaged "pirated applications (APP)" have become the gateway for mobile phone Trojans, mobile phone viruses, privacy theft and other "chronic diseases" to run rampant.

[0003] Secondary packaging refers to the process of cracking (decompiling) an application, then tampering with or inserting malicious code, and finally generating a new application. Usually, criminals prefer to secondary package apps with high download volume on the market. These apps have a large number of user clusters and gain profits by inserting advertisements, Trojans, and viruses to steal user privacy and absorb funds. From the appearance, the pirated apps after secondary packaging are exactly the same as the genuine apps, and users cannot distinguish them with the naked eye. Therefore, once any irreparable losses occur, users will blame the APP and the developer, which seriously infringes on the interests of the developers.

[0004] In order to prevent the APP from being repackaged, some developers will obfuscate the APP code, but code obfuscation only increases the difficulty of reading the APP code and cannot really prevent the reverse cracking process of crackers. Summary of the invention

[0005] The present application proposes an application verification method, device, equipment and storage medium, which are used to avoid infringement of user rights and interests caused by secondary packaging of APP.

[0006] In order to achieve the above objectives, this application adopts the following technical solutions:

[0007] In a first aspect, an application verification method is provided, which is applied to a mobile terminal, and the method includes: the mobile terminal determines the MD5 value of a local file of the application to be verified; and encrypts the MD5 value of the local file to obtain a field to be verified. Further, the mobile terminal sends the version number of the application to be verified and the field to be verified to a server corresponding to the application to be verified, so that the server compares and verifies the field to be verified according to the standard field corresponding to the version number; and obtains the verification result sent by the server, and when the verification result is a verification failure, terminates the operation of the application to be verified.

[0008] In the application verification method provided in the present application, the fields to be verified are obtained by processing local files, and the server compares and verifies the fields to be verified according to the standard fields when the APP is released to determine whether the APP installed on the mobile terminal has been tampered with. If the verification fails, it means that the APP has been tampered with, and the mobile terminal terminates the operation of the application to be verified to avoid infringement of the user's rights and interests.

[0009] In one possible design, the application verification method is stored in the SO library in the form of a binary file; the SO library is initialized in response to a network request initiated by the application to be verified. In this design, by storing the application verification method in the SO library of the APP, when the APP issues a network request, the SO library is initialized and the application verification method is called. Since the SO library is a binary file, even if it is cracked by a hacker, the business logic and the verification method cannot be sorted out, which can prevent the verification method from being modified by the hacker.

[0010] In one possible design, local files include a signature file, a DEX file set, and an application installation package. The mobile terminal determines the MD5 value of the local file of the application to be verified, including: calculating the signature file MD5 value, the DEX file set MD5 value, and the application installation package MD5 value based on the signature file, the DEX file set, and the application installation package, respectively; determining the MD5 value of the local file of the application to be verified based on the signature file MD5 value, the DEX file set MD5 value, the application installation package MD5 value, and a preset combination rule.

[0011] In a possible design, the SO library includes a verification SO library. In response to the initialization of the SO library, the verification SO library sends the data to be verified to the server and obtains the verification status returned by the server. The verification status includes verification failure and verification success. When the verification status is verification failure, the operation of the application to be verified is terminated. This design provides a redundant verification method, which verifies the data to be verified in the verification SO library to determine whether the SO library has been attacked and cracked, thereby ensuring the normal operation of the APP.

[0012] In a second aspect, an application verification method is provided, which is applied to a server, and the method includes: the server receives the version number of the application to be verified and the field to be verified sent by the mobile terminal, and the field to be verified is obtained by encrypting the MD5 value of the local file of the application to be verified. Further, the server compares and verifies the field to be verified according to the standard field corresponding to the version number; and sends the verification result to the mobile terminal. If the field to be verified is different from the standard field, the verification result is verification failure.

[0013] In one possible design, when the verification result is a verification failure, an exception report is generated, which includes the installation package information of the application to be verified, user information, and device information of the mobile terminal. In this design, when the APP verification fails, the server will generate an exception report to enable the operation and maintenance personnel to quickly locate the problematic APP and remind the user to avoid infringement of user rights.

[0014] In one possible design, the server determines the version number corresponding to the standard field, including: obtaining the MD5 value of the application installation package, the MD5 value of the signature file, and the MD5 value of the DEX file of the application to be verified stored locally according to the version number; and encrypting the MD5 value of the application installation package, the MD5 value of the signature file, and the MD5 value of the DEX file to obtain the standard field.

[0015] In one possible design, the server determines the version number of the target application, the MD5 value of the application installation package, the MD5 value of the signature file, and the MD5 value of the DEX file set based on the application installation package and signature file of the target application; and in response to the release of the target application, establishes a mapping relationship between the version number of the target application and the MD5 value of the application installation package, the MD5 value of the signature file, and the MD5 value of the DEX file set of the target application.

[0016] In a third aspect, an application verification device is provided, which is deployed in a mobile terminal and includes a determination unit, a processing unit, a sending unit, and a receiving unit. The determination unit is used to determine the MD5 value of the local file of the application to be verified. The processing unit is used to encrypt the MD5 value of the local file to obtain the field to be verified. The sending unit is used to send the version number of the application to be verified and the field to be verified to the server corresponding to the application to be verified, so that the server compares and verifies the field to be verified according to the standard field corresponding to the version number. The receiving unit is used to receive the verification result sent by the server, and when the verification result is a verification failure, terminate the operation of the application to be verified.

[0017] In a possible design, the application verification method is stored in a dynamically linked SO library in the form of a binary file. The processing unit is also used to initialize the SO library in response to a network request initiated by the application to be verified.

[0018] In a possible design, the local file includes a signature file, a DEX file set, and an application installation package. The determination unit is specifically used to calculate the signature file MD5 value, the DEX file set MD5 value, and the application installation package MD5 value based on the signature file, the DEX file set, and the application installation package, respectively; and determine the MD5 value of the local file of the application to be verified based on the signature file MD5 value, the DEX file set MD5 value, the application installation package MD5 value, and the preset combination rule.

[0019] In a possible design, the SO library includes a verification SO library. In response to the initialization of the SO library, the verification SO library sends the data to be verified to the server through the sending unit, and obtains the verification status returned by the server through the receiving unit, and the verification status includes verification failure and verification success. The processing unit is also used to terminate the operation of the application to be verified when the verification status is verification failure.

[0020] In a fourth aspect, a mobile terminal is provided, which includes a memory and a processor; the memory and the processor are coupled, the memory is used to store computer program code, the computer program code includes computer instructions, and when the processor executes the computer instructions, the mobile terminal executes the application verification method provided by the first aspect or any possible design thereof.

[0021] In a fifth aspect, a server is provided, comprising a memory and a processor; the memory and the processor are coupled, the memory is used to store computer program code, the computer program code comprises computer instructions, and when the processor executes the computer instructions, the server executes the application verification method provided in the second aspect or any possible design thereof.

[0022] In a sixth aspect, a computer-readable storage medium is provided, in which instructions are stored. When the instructions are executed on a mobile terminal, the mobile terminal executes the application verification method provided in the first aspect or any possible implementation thereof.

[0023] In a seventh aspect, a computer program product is provided, the computer program product comprising computer instructions, which, when executed on a mobile terminal, causes the mobile terminal to execute an application verification method as provided in the first aspect or any possible implementation thereof. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 A schematic diagram of the structure of an application verification system provided in an embodiment of the present application;

[0025] Figure 2 A schematic diagram of an application verification method provided in an embodiment of the present application Figure 1 ;

[0026] Figure 3 A schematic diagram of an application verification method provided in an embodiment of the present application Figure 2 ;

[0027] Figure 4 A schematic diagram of an application verification method provided in an embodiment of the present application Figure 3 ;

[0028] Figure 5 A schematic diagram of an application verification method provided in an embodiment of the present application Figure 4 ;

[0029] Figure 6 A schematic diagram of a process of a server publishing an APP provided in an embodiment of the present application;

[0030] Figure 7 A schematic diagram of the structure of an application verification device provided in an embodiment of the present application;

[0031] Figure 8 A schematic diagram of the structure of a mobile terminal provided for an embodiment of the present application. DETAILED DESCRIPTION

[0032] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application.

[0033] In the embodiments of the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a specific way.

[0034] In the description of this application, unless otherwise specified, " / " means "or", for example, A / B can mean A or B. "And / or" in this article is merely a description of the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, "at least one" and "plurality" refer to two or more. The words "first", "second", etc. do not limit the quantity and execution order, and the words "first", "second", etc. do not limit them to be different.

[0035] In order to facilitate the understanding of the embodiments of the present application, the concepts of the terms involved are first introduced below.

[0036] Secondary packaging refers to repackaging an already developed APP, usually to insert malicious code or advertisements to gain profits. The impact of secondary packaging is mainly reflected in advertising harassment, traffic loss, and privacy leakage, which harms users of the APP and affects the interests of the APP and APP developers. The steps of secondary packaging include unpacking (decompiling), inserting / tampering with code, generating a new package, re-signing, and running.

[0037] Decompilation refers to the use of reverse engineering technology by crackers to analyze and restore the source code of the APP. Crackers can obtain the internal implementation details, algorithms, business logic and sensitive information of the APP through decompilation tools, debuggers or other technical means.

[0038] APK file is a file used by the Android operating system. The file format of APK file is an application package file format.

[0039] The DEX file is a file with the suffix .dex that is extracted from the APK file.

[0040] DEX files contain executable files of the Android operating system, including all operations of the APP and runtime data, which are processed and executed by the Dalvik Virtual Machine (DVM) or Android Runtime (ART). After the APP's Java source code is compiled into a class file (a class file is a binary file compiled from the java source code), the dx tool is used to integrate the class files into a dex file. This allows data to be shared, reduces redundancy to a certain extent, and also makes the file structure more compact.

[0041] Among them, the dex file includes a file header (header), a data index area (format is xxx_ids), a class definition area (class_def), a data area (data) and a link data area (link_data).

[0042] The file header is used to record the relevant properties of the entire dex file;

[0043] The data index area stores the index of resource data such as strings, type data, method information, and field information. The actual data in the data area can be found through the index of resource data.

[0044] The class definition area (class_def) records the class information, including but not limited to the interface, superclass, class data offset, etc.

[0045] Data area, storing real data of each class;

[0046] Link data area, which stores data used in static link files.

[0047] MD5 is a message digest algorithm (Message Digest Algorithm MD5), which is used to ensure the integrity and consistency of information transmission. Among them, the MD5 algorithm can calculate an input string of any length to obtain an output of a fixed length, and only when the plaintext is the same can the same ciphertext be obtained. In addition, this algorithm is irreversible. Even if the encrypted ciphertext is obtained, it is impossible to reverse the plaintext through the decryption algorithm.

[0048] A dynamic link library is a file used to store reusable code and data in an executable program. It is loaded into memory when the APP is running to improve code reusability and reduce program size. In the Android operating system, it usually exists in the form of a .so (SharedObject) file, which is a binary file.

[0049] At present, in order to prevent the APP from being repackaged, some developers will obfuscate the APP code, but code obfuscation only increases the difficulty of reading the APP code and cannot really prevent the reverse cracking process of crackers.

[0050] In order to solve the above problems, the present application proposes an application verification method, device, equipment and storage medium. The application verification method is applied to a mobile terminal, and the mobile terminal determines the MD5 value of the local file of the application to be verified; and encrypts the MD5 value of the local file to obtain the field to be verified. Furthermore, the mobile terminal sends the version number of the application to be verified and the field to be verified to the server corresponding to the application to be verified, so that the server compares and verifies the field to be verified according to the standard field corresponding to the version number; and obtains the verification result sent by the server. If the verification result is a verification failure, the operation of the application to be verified is terminated.

[0051] In this way, in the application verification method provided by the present application, the fields to be verified are obtained by processing the local files, and the server compares and verifies the fields to be verified according to the standard fields when the APP is released to determine whether the APP installed on the mobile terminal has been tampered with. If the verification fails, it means that the APP has been tampered with, and the mobile terminal terminates the operation of the application to be verified to avoid infringement of the user's rights and interests.

[0052] Figure 1 An application verification system is shown. The application verification method provided in the embodiment of the present application can be applied to Figure 1 The application verification system shown is used to prevent the infringement of user rights due to secondary packaging of APP. Figure 1 As shown, the application verification system 10 includes a mobile terminal 11 and a server 12 .

[0053] The mobile terminal 11 has an APP installed in it, and the server 12 is a server corresponding to the APP.

[0054] The mobile terminal 11 in the present application can be a mobile phone, a tablet computer, a personal computer (PC), a personal digital assistant (PDA), a smart watch, a netbook, a wearable electronic device, an augmented reality (AR) device, a virtual reality (VR) device, a vehicle-mounted device, a smart car, a smart speaker, a robot, etc. The present application does not impose any special restrictions on the specific form of the mobile terminal.

[0055] The mobile terminal 11 may be used to obtain a local file of the APP to be verified based on the APP to be verified among the installed APPs, and determine an MD5 value of the local file.

[0056] The mobile terminal 11 may also be used to encrypt the MD5 value of the local file to obtain the field to be checked.

[0057] The mobile terminal 11 may also be used to send the version number of the APP to be verified and the field to be verified to the server 12 corresponding to the APP to be verified.

[0058] Correspondingly, the server 12 receives the version number of the APP to be verified and the field to be verified sent by the mobile terminal.

[0059] The server 12 can be used to compare and verify the fields to be verified according to the standard fields corresponding to the version number of the APP to be verified, and generate and send the verification result to the mobile terminal 11.

[0060] If the field to be checked is different from the standard field, the check result is check failure.

[0061] After receiving the verification result, if the mobile terminal 11 determines that the verification result is a verification failure, the operation of the APP to be verified is terminated to ensure that the user's rights and interests are not infringed.

[0062] Figure 2 FIG. 1 is a flow chart of an application verification method according to some exemplary embodiments. In some embodiments, the above application verification method can be applied to Figure 1 The application verification system 10 shown includes a mobile terminal 11 and a server 12. The application verification method described above is described below.

[0063] like Figure 2 As shown, the application verification method provided in the embodiment of the present application includes the following S201-S206.

[0064] S201. The mobile terminal determines the MD5 value of the local file of the application to be verified.

[0065] Among them, local files exemplarily include signature files, DEX file sets and application installation packages, and the DEX file set includes all DEX files in the application installation package.

[0066] As a possible implementation method, the mobile terminal obtains the local file of the APP to be verified, and performs calculation based on the MD5 algorithm to determine the MD5 value of the local file.

[0067] In some embodiments, the application verification method proposed in the present application is stored in the SO library in the form of a binary file; in response to a network request initiated by the application to be verified, the SO library is initialized.

[0068] It should be noted that the network requests initiated by the application to be verified include login operations, operations to obtain new Keys, or other operations to transmit data between the server, etc. The Key is a credential used to verify the legitimacy of API access. The validity period can be set to 2 hours. During the validity period of the Key, specific services or data can be accessed. After the validity period expires, it is necessary to request a new Key from the server again.

[0069] It can be understood that by storing the application verification method in the SO library and initializing it when the APP initiates a network request, the APP can be verified every time it accesses or obtains data, thereby preventing the user's rights from being infringed.

[0070] Among them, the SO library reads the signature file, DEX file set and application installation package of the APP to be verified at the bottom layer through the Native Development Kit (NDK), and further calculates the MD5 value of each file based on the MD5 algorithm to obtain the MD5 value of the local file including the MD5 value of the signature file, the MD5 value of the DEX file set and the MD5 value of the application installation package.

[0071] In some embodiments, the mobile terminal further combines the signature file MD5 value, the DEX file set MD5 value, and the application installation package MD5 value into the MD5 value of the local file based on the calculated signature file MD5 value, the DEX file set MD5 value, the application installation package MD5 value, and the preset combination rules.

[0072] It should be noted that the preset combination rule can be set in advance in the mobile terminal by the operation and maintenance personnel of the application verification system. For example, the preset combination rule is to concatenate the three MD5 values ​​in the order of signature file MD5 value, DEX file set MD5 value, and application installation package MD5 value, or to concatenate the first N bits of the three MD5 values ​​in the order of signature file MD5 value, DEX file set MD5 value, and application installation package MD5 value. The embodiments of the present application do not specifically limit this.

[0073] Exemplarily, if the preset combination rule is to concatenate the three MD5 values ​​in the order of signature file MD5 value, DEX file set MD5 value, and application installation package MD5 value, and the three MD5 values ​​are MD5A, MD5B, and MD5C respectively, then the obtained MD5 value of the local file is MD5A_MD5B_MD5C.

[0074] S202: The mobile terminal encrypts the MD5 value of the local file to obtain a field to be verified.

[0075] As a possible implementation manner, the mobile terminal encrypts the MD5 value of the local file calculated in the above step S201 based on a preset key, and the encrypted MD5 value is the field to be verified.

[0076] It should be noted that the preset key can be set in advance in the mobile terminal and the server by the operation and maintenance personnel of the application verification system; the mapping relationship between the version number of the APP and the key can also be set in the mobile terminal and the server, so that the mobile terminal can obtain the corresponding key through the version number of the APP to be verified to encrypt the MD5 value of the local file. The embodiment of the present application does not make specific limitations on this.

[0077] Exemplarily, taking the mapping relationship between the version number of the APP and the key set in the mobile terminal and the server as an example, the mapping relationship is shown in Table 1 below.

[0078] Table 1: Mapping relationship between APP version number and key

[0079] APP version number Key 2.0.1 Key A 2.0.6 Key B 2.1.0 Key C 2.1.5 Key D

[0080] Based on the mapping relationship table shown in Table 1 above, if the mobile terminal determines that the version number of the APP to be verified is 2.1.5, the key D is obtained from the mapping relationship table as the preset key, and the MD5 value of the local file is encrypted based on the key D to obtain the field to be verified.

[0081] In some embodiments, if the MD5 value of the local file is a combination of the signature file MD5 value, the DEX file set MD5 value, and the application installation package MD5 value, the mobile terminal encrypts the combined MD5 value based on a preset key to obtain the field to be checked.

[0082] If the MD5 value of the local file includes the MD5 value of the signature file, the MD5 value of the DEX file set, and the MD5 value of the application installation package, the mobile terminal encrypts the three MD5 values ​​respectively based on the preset key. After obtaining the three encrypted MD5 values, the mobile terminal can determine the three encrypted MD5 values ​​as the fields to be verified, and verify them separately in the subsequent verification process; it can also combine the three encrypted MD5 values, determine the combined field as the field to be verified, and verify it in the subsequent process.

[0083] S203: The mobile terminal sends the version number of the application to be verified and the field to be verified to the server corresponding to the application to be verified.

[0084] As a possible implementation manner, the mobile terminal sends the version number of the APP to be verified and the field to be verified to the server based on the communication connection between the server and the APP to be verified.

[0085] Correspondingly, the server receives the version number of the APP to be verified and the field to be verified sent by the mobile terminal.

[0086] S204: The server compares and verifies the field to be verified according to the standard field corresponding to the version number.

[0087] As a possible implementation method, the server obtains the standard field corresponding to the version number of the APP to be verified from the mapping relationship table between the version number and the standard field based on the version number of the APP to be verified received in the above step S203, and compares and verifies the field to be verified based on the standard field to generate a verification result, wherein, when the field to be verified is completely consistent with the standard field, the verification result is a successful verification; when the field to be verified is different from the standard field, the verification result is a failed verification.

[0088] It should be noted that the standard field is encrypted after the current version of the APP is released, based on the file of the current version of the APP, by calculating the MD5 value, which is consistent with the way to generate the field to be verified in the mobile terminal. Furthermore, a mapping relationship is established based on the version number of the APP and the calculated standard field, and stored in the server.

[0089] Exemplarily, the mapping relationship between the APP version number and the standard field can be shown in Table 2 below.

[0090] Table 2: Mapping relationship between APP version number and standard fields

[0091]

[0092]

[0093] Based on the mapping relationship table shown in Table 2, when the APP version number is 2.1.5, the standard field obtained by the server is the standard field D, and the field to be checked is compared and checked based on the standard field to generate a verification result.

[0094] In some embodiments, when the server releases the APP, it establishes a mapping relationship between the APP's signature file MD5 value, the DEX file set MD5 value, and the application installation package MD5 value and the APP's version number, and stores them.

[0095] Exemplarily, the mapping relationship between the APP version number and the file MD5 value is shown in Table 3 below.

[0096] Table 3: Mapping relationship between APP version number and file MD5 value

[0097]

[0098] In this case, the server determines the standard field corresponding to the version number of the APP to be detected, including the following steps S2041-S2042.

[0099] S2041. The server obtains the MD5 value of the application installation package, the signature file MD5 value, and the DEX file MD5 value of the application to be verified stored locally according to the version number.

[0100] As a possible implementation method, the server obtains the corresponding application installation package MD5 value, signature file MD5 value and DEX file MD5 value from the mapping relationship table between APP version number and file MD5 value based on the version number received in the above step S203.

[0101] S2042. The server encrypts the MD5 value of the application installation package, the MD5 value of the signature file, and the MD5 value of the DEX file to obtain a standard field.

[0102] As a possible implementation method, the server obtains the key corresponding to the APP version number from the mapping relationship table between the APP version number and the key, encrypts the MD5 value of the application installation package, the MD5 value of the signature file, and the MD5 value of the DEX file to obtain the standard field.

[0103] It should be noted that the way the server encrypts the MD5 value of the application installation package, the MD5 value of the signature file, and the MD5 value of the DEX file based on the key corresponding to the APP version number is consistent with the encryption method of the mobile terminal in the above steps.

[0104] S205. The server sends the verification result to the mobile terminal.

[0105] If the field to be checked is different from the standard field, the check result is check failure.

[0106] Correspondingly, the mobile terminal receives the verification result sent by the server.

[0107] In some embodiments, if the verification result is a verification failure, the server generates an exception report, wherein the exception report includes the installation package information of the APP to be verified, user information, and device information of the mobile terminal.

[0108] Exemplarily, the installation package information includes the version number of the installation package and the data of the installation package, the user information includes the user ID and IP address, etc., and the device information of the mobile terminal includes the model of the device, etc.

[0109] It is understandable that when the server determines that the mobile terminal verification has failed, it generates an exception report, which enables the operation and maintenance personnel to be informed of the abnormal use of the APP and to provide timely feedback to the corresponding users to avoid infringement of the user's rights and interests.

[0110] S206: When the verification result is a verification failure, the mobile terminal terminates the running of the application to be verified.

[0111] As a possible implementation, when the received verification result is a verification failure, the mobile terminal terminates the running of the application to be verified, cancels the generated data, and returns to the APP login page.

[0112] In some embodiments, when the verification result is a verification failure, the mobile terminal generates an APP abnormality reminder to instruct the user to pay attention to whether the current APP has risks to avoid infringement of the user's rights and interests.

[0113] It can be understood that the application verification method proposed in this application is set in the SO library of the APP. When the APP sends a network request, the SO library is initialized and the application verification method is called. Since the SO library is a binary file, even if it is cracked by a cracker, the business logic and the verification method cannot be sorted out, so as to avoid the verification method being modified by the cracker. In addition, when executing the application verification method, the field to be verified is obtained by processing the local file, and the server compares and verifies the field to be verified according to the standard field when the APP is released to determine whether the APP installed on the mobile terminal has been tampered with. If the verification fails, it means that the APP has been tampered with, and the mobile terminal terminates the operation of the application to be verified to avoid infringement of the rights and interests of users.

[0114] In some embodiments, in order to determine whether the SO library has been cracked by the cracker, a verification SO library is included in the multiple sub-libraries included in the SO library, in which the data to be verified is stored. In response to the initialization of the SO library, the data to be verified is sent to the server, and the verification status returned by the server is obtained. The verification status includes verification failure and verification success. When the verification status is verification failure, the operation of the APP to be verified is terminated.

[0115] Correspondingly, the server also stores corresponding data for comparison and verification of the verification data. In the case of consistency, a verification status of successful verification is returned; in the case of difference, a verification status of failed verification is returned.

[0116] In some embodiments, the server includes an APP publishing platform for implementing the publishing of different versions of the APP, including the following steps.

[0117] The server determines the version number of the target application, the MD5 value of the application installation package, the MD5 value of the signature file, and the MD5 value of the DEX file set according to the application installation package and the signature file of the target application.

[0118] Among them, the version number and DEX file set can be parsed from the application installation package.

[0119] Furthermore, the server publishes the target application in response to the user's publishing operation, and establishes a mapping relationship between the version number of the target application and the MD5 value of the application installation package of the target application, the MD5 value of the signature file, and the MD5 value of the DEX file set.

[0120] In this way, when the server receives the verification of the target application, it can obtain the application installation package MD5 value, signature file MD5 value and DEX file set MD5 value corresponding to the version number of the target application from the internal storage to verify the target application.

[0121] In one design, Figure 3 A flow chart of an application verification method is shown. In which, on the mobile terminal side, the APP initializes the SO library; the SO library executes the application verification method, including reading the signature file MD5 value, reading the DEX file set MD5 value, and reading the application installation package MD5 value; further, based on the signature file MD5 value, the DEX file set MD5 value, and the application installation package MD5 value, the to-be-verified field is encrypted and generated, and the to-be-verified field and version number are uploaded to the server.

[0122] On the server side, the MD5 value of the file corresponding to the version number stored when the APP was released is obtained according to the version number, including the MD5 value of the signature file, the MD5 value of the DEX file set, and the MD5 value of the application installation package; further, the server encrypts the file MD5 value based on symmetric encryption to obtain the standard field; based on the one-to-one comparison of the standard field with the field to be verified, a verification result is generated, and the verification result is returned to the mobile terminal. If the verification result is a verification failure, the server generates an exception report.

[0123] Correspondingly, after receiving the verification result on the mobile terminal side, if the verification result is successful, the APP runs normally, and if the verification result is failed, the running of the APP is terminated.

[0124] In addition, the server side also includes an APP publishing platform, which is used to enter the APP release information when the APP is released. The APP release information includes the signature file MD5 value, the DEX file set MD5 value, the application installation package MD5 value and the APP release version number.

[0125] In one design, Figure 4 A flow chart of another application verification method is shown. In which, on the mobile terminal side, in response to the APP login operation or obtaining a new Key, a network request in the business logic SO library is called to perform a login operation or obtain a new Key, and the verification SO library is called to obtain the field to be verified. When executing the network request, the field to be verified, the APP version number and the verification identifier are reported to the server.

[0126] When the verification flag is true, it is used to instruct the server to verify the field to be verified. When the verification flag is false, it is used to instruct the server not to verify.

[0127] On the server side, first determine whether the check field is true. If the check field is true, check the field to be checked, generate the check result, and execute the business logic corresponding to the network request if the check is successful, otherwise return the check failure result to the mobile terminal side. If the check field is false, directly execute the business logic corresponding to the network request, and return the result after execution to the mobile terminal side.

[0128] Correspondingly, the mobile terminal receives the result returned by the server and performs different operations according to the returned result, wherein the received result includes a verification failure result or an execution result. After receiving the verification failure result, the operation of the APP is terminated, and after receiving the execution result, the calling logic proceeds normally.

[0129] In one design, Figure 5A flowchart of another application verification method is shown. In the APP design on the mobile terminal side, it mainly includes three parts: business logic SO library, verification SO library and application termination receiver.

[0130] The business logic SO library mainly includes network requests and database addition, deletion, modification and query operations. The two parts are designed with a unified calling entry, and judge whether the APP verification is successful at the calling entry. If the verification is successful, the calling logic proceeds normally. If the verification fails, the APP call is terminated, and the generated data is cancelled, instructing the application to terminate the receiver, terminate the operation of the application, and return to the login interface.

[0131] The verification SO library is a sub-library of the APPSO library. When the APP is initialized, the verification status is initialized and the data to be verified is submitted to the server. The verification status in the verification SO library is updated according to the verification status returned by the server.

[0132] In one design, Figure 6 A schematic diagram showing a process of a server publishing an APP.

[0133] Get the uploaded application installation package and signature file, use ApkFile SDK to automatically read the application installation package to obtain the APP version number, parse the application installation package, traverse all DEX files, and generate the DEX file set MD5 value based on all DEX files.

[0134] In the process of parsing the application installation package, the suffix of the application installation package is first changed to .zip, and then the application installation package is decompressed and all DEX files are traversed to obtain.

[0135] The MD5 value of the application installation package is calculated for the application installation package, and the MD5 value of the signature file is calculated for the signature file.

[0136] Based on the APP version number, signature file MD5 value, DEX file set MD5 value and application installation package MD5 value, a data table entry is generated. In response to the administrator's publishing operation, the data is stored in the verification database for calling and obtaining standard fields during the verification of the APP.

[0137] The above mainly introduces the solution provided by the embodiment of the present application from the perspective of the method. In order to realize the above functions, it includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should easily realize that, in combination with the units and algorithm steps of each example described in the embodiment disclosed herein, the embodiment of the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present application.

[0138] The embodiment of the present application can divide the functional modules of the user equipment according to the above method example. For example, each functional module can be divided according to each function, or two or more functions can be integrated into one processing module. The above integrated module can be implemented in the form of hardware or in the form of software functional modules. Optionally, the division of modules in the embodiment of the present application is schematic and is only a logical function division. There may be other division methods in actual implementation.

[0139] Figure 7 Schematic diagram of the structure of an application verification device provided in an embodiment of the present application. The application verification device is used to execute the above-mentioned application verification method. Figure 7 As shown, the application verification device 70 includes a determination unit 701 , a processing unit 702 , a sending unit 703 and a receiving unit 704 .

[0140] The determination unit 701 is used to determine the MD5 value of the local file of the application to be verified.

[0141] The processing unit 702 is used to encrypt the MD5 value of the local file to obtain the field to be checked.

[0142] The sending unit 703 is used to send the version number of the application to be checked and the field to be checked to the server corresponding to the application to be checked, so that the server compares and checks the field to be checked according to the standard field corresponding to the version number.

[0143] The receiving unit 704 is used to receive the verification result sent by the server, and when the verification result is a verification failure, terminate the running of the application to be verified.

[0144] Optional, such as Figure 7 As shown, in the application verification device 70 provided in the embodiment of the present application, the application verification method is stored in the dynamic link SO library in the form of a binary file.

[0145] The processing unit 702 is further configured to initialize the SO library in response to a network request initiated by the application to be verified.

[0146] Optional, such as Figure 7 As shown, in the application verification device 70 provided in the embodiment of the present application, the local files include signature files, DEX file sets and application installation packages.

[0147] The determination unit 701 is specifically used to calculate the signature file MD5 value, the DEX file set MD5 value and the application installation package MD5 value based on the signature file, the DEX file set and the application installation package respectively; and determine the MD5 value of the local file of the application to be verified based on the signature file MD5 value, the DEX file set MD5 value, the application installation package MD5 value, and the preset combination rule.

[0148] Optional, such as Figure 7 As shown, in the application verification device 70 provided in the embodiment of the present application, the SO library includes a verification SO library.

[0149] The verification SO library responds to the initialization of the SO library by sending the data to be verified to the server through the sending unit 703, and obtains the verification status returned by the server through the receiving unit 704. The verification status includes verification failure and verification success.

[0150] The processing unit 702 is further configured to terminate the running of the application to be verified when the verification status is verification failure.

[0151] In the case of implementing the functions of the above-mentioned integrated modules in the form of hardware, the embodiment of the present application provides a possible structural diagram of a mobile terminal. The mobile terminal is used to execute the method executed by the mobile terminal in the above-mentioned embodiment. Figure 8 As shown, the mobile terminal 80 includes a processor 801, a memory 802 and a bus 803. The processor 801 and the memory 802 may be connected via the bus 803.

[0152] The processor 801 is the control center of the mobile terminal, which can be a processor or a general term for multiple processing elements. For example, the processor 801 can be a general-purpose central processing unit (CPU) or other general-purpose processors. Among them, the general-purpose processor can be a microprocessor or any conventional processor.

[0153] As an embodiment, the processor 801 may include one or more CPUs, such as Figure 8 CPU 0 and CPU 1 are shown in .

[0154] The memory 802 may be a read-only memory (ROM) or other type of static storage device that can store static information and instructions, a random access memory (RAM) or other type of dynamic storage device that can store information and instructions, an electrically erasable programmable read-only memory (EEPROM), a disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited to these.

[0155] As a possible implementation, the memory 802 can exist independently of the processor 801, and the memory 802 can be connected to the processor 801 via a bus 803 to store instructions or program codes. When the processor 801 calls and executes the instructions or program codes stored in the memory 802, the method provided in the embodiment of the present application can be implemented.

[0156] In another possible implementation, the memory 802 may also be integrated with the processor 801 .

[0157] The bus 803 may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 8 Only one thick line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0158] It should be pointed out that Figure 8 The structure shown does not constitute a limitation on the mobile terminal 80. Figure 8 In addition to the components shown, the mobile terminal 80 may include Figure 8 More or fewer components, or combinations of certain components, or different arrangements of components may be shown.

[0159] As an example, combining Figure 7 The functions implemented by the determination unit 701, the processing unit 702, the sending unit 703 and the receiving unit 704 in the application verification device 70 are similar to those Figure 8 The function of processor 801 in is the same.

[0160] Optional, such as Figure 8 As shown, the mobile terminal provided in the embodiment of the present application may further include a communication interface 804.

[0161] The communication interface 804 is used to connect with other devices through a communication network. The communication network may be Ethernet, wireless access network, wireless local area network (WLAN), etc. The communication interface 804 may include an acquisition unit for receiving data and a sending unit for sending data.

[0162] In one design, in the mobile terminal provided in an embodiment of the present application, the communication interface may also be integrated into the processor.

[0163] Through the description of the above implementation methods, those skilled in the art can clearly understand that for the convenience and simplicity of description, only the division of the above functional units is used as an example. In practical applications, the above functions can be assigned to different functional units as needed, that is, the internal structure of the device can be divided into different functional units to complete all or part of the functions described above. The specific working process of the system, device and unit described above can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0164] An embodiment of the present application also provides a computer-readable storage medium, in which instructions are stored. When a computer executes the instructions, the computer executes each step in the method flow shown in the above method embodiment.

[0165] An embodiment of the present application provides a computer program product including instructions. When the instructions are executed on a computer, the computer executes the method in the above method embodiment.

[0166] Among them, the computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection with one or more wires, a portable computer disk, and a hard disk. Random Access Memory (RAM), Read-Only Memory (ROM), Erasable Programmable Read Only Memory (EPROM), registers, hard disks, optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any other form of computer-readable storage medium in a suitable combination of the above, or numerical values ​​in the art. An exemplary storage medium is coupled to a processor so that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can be located in an Application Specific Integrated Circuit (ASIC). In the embodiments of the present application, a computer-readable storage medium may be any tangible medium that contains or stores a program, which may be used by or in conjunction with an instruction execution system, apparatus, or device.

[0167] Since the apparatus, device computer-readable storage medium, and computer program product in the embodiments of the present application can be applied to the above-mentioned method, the technical effects that can be obtained can also refer to the above-mentioned method embodiments, and the embodiments of the present application will not be described in detail here.

[0168] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions within the technical scope disclosed in the present application should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. An application verification method, characterized in that: Applied to a mobile terminal, the method comprises: Determine the MD5 value of the local file of the application to be verified; Encrypt the MD5 value of the local file to obtain the field to be verified; Sending the version number of the application to be verified and the field to be verified to a server corresponding to the application to be verified, so that the server compares and verifies the field to be verified according to the standard field corresponding to the version number; The verification result sent by the server is received, and when the verification result is a verification failure, the operation of the application to be verified is terminated.

2. The application verification method according to claim 1, characterized in that: The application verification method is stored in a dynamically linked SO library in the form of a binary file; the SO library is initialized in response to a network request initiated by the application to be verified.

3. The application verification method according to claim 1 or 2, characterized in that: The local file includes a signature file, a DEX file set, and an application installation package, and the MD5 value of the local file of the application to be verified is determined, including: Based on the signature file, the DEX file set and the application installation package, respectively, the signature file MD5 value, the DEX file set MD5 value and the application installation package MD5 value are calculated; Based on the signature file MD5 value, the DEX file set MD5 value, the application installation package MD5 value, and a preset combination rule, the MD5 value of the local file of the application to be verified is determined.

4. The application verification method according to claim 2, characterized in that: The SO library includes a verification SO library, and the verification SO library sends the data to be verified to the server in response to the initialization of the SO library, and obtains the verification status returned by the server, and the verification status includes verification failure and verification success; When the verification status is verification failure, the running of the application to be verified is terminated.

5. An application verification method, characterized in that: Applied to a server, the method comprises: Receive the version number of the application to be verified and the field to be verified sent by the mobile terminal, where the field to be verified is obtained by encrypting the MD5 value of the local file of the application to be verified; Compare and verify the field to be verified according to the standard field corresponding to the version number; A verification result is sent to the mobile terminal, and when the field to be verified is different from the standard field, the verification result is verification failure.

6. The application verification method according to claim 5, characterized in that: When the verification result is a verification failure, an exception report is generated, and the exception report includes installation package information of the application to be verified, user information, and device information of the mobile terminal.

7. The application verification method according to claim 5 or 6, characterized in that: Determine that the version number corresponds to a standard field, including: According to the version number, obtain the MD5 value of the application installation package, the MD5 value of the signature file, and the MD5 value of the DEX file of the application to be verified stored locally; The MD5 value of the application installation package, the MD5 value of the signature file, and the MD5 value of the DEX file are encrypted to obtain the standard field.

8. The application verification method according to claim 5 or 6, characterized in that: The method further comprises: Determine the version number of the target application, the MD5 value of the application installation package, the MD5 value of the signature file, and the MD5 value of the DEX file set according to the application installation package and the signature file of the target application; In response to the release of the target application, a mapping relationship is established between the version number of the target application and the MD5 value of the application installation package, the signature file MD5 value, and the DEX file set MD5 value of the target application.

9. A mobile terminal, characterized in that: including memory and processor; The memory is coupled to the processor; The memory is used to store computer program code, wherein the computer program code includes computer instructions; When the processor executes the computer instructions, the mobile terminal executes the application verification method as described in any one of claims 1-4.

10. A computer-readable storage medium, wherein instructions are stored in the computer-readable storage medium, characterized in that: When the instruction is executed on the mobile terminal, the mobile terminal executes the application verification method as described in any one of claims 1 to 4.

Images