Android APP multi-tamper-proofing method, system, device and medium

Abstract

The invention is suitable for the technical field of information security, and provides an Android APP multi-tamper-proofing method, which comprises the following steps: acquiring a dex file of an APP, and encrypting the dex file by adopting a reinforcement algorithm to generate a dex reinforced file; a signature obfuscation algorithm is adopted, obfuscation code segments are embedded in the dex reinforcement file, and a signature verification module is generated; carrying out encryption processing on the resource file of the APP by adopting an encryption storage algorithm to generate a resource encryption file; when the APP is started, secondary integrity detection is carried out on the APP based on the signature verification module; if the integrity of the APP is not destroyed, loading the resource encryption file, and carrying out decryption operation on the resource encryption file; and after the decryption operation, the key business logic code segment is verified in the APP operation process through the operation verification method, the tampering and attack resisting capability of the APP is effectively improved, and therefore the safety and integrity of the APP are protected.

Description

Technical Field

[0001] This application belongs to the field of information security technology, and particularly relates to a method, system, device and medium for multi-anti-tampering of Android APPs. Background Art

[0002] With the rapid development of the Internet and the rapid popularization of intelligent terminals, the development speed of various mobile applications has accelerated. For example, APPs on the Android platform have been involved in various fields, including APPs with extremely high security requirements such as the financial field.

[0003] For the above Android APPs, when developers release the APP as a release version, they usually use code obfuscation technology to ensure the security of the APP. Specifically, by renaming class names, method names, variable names, etc. in the source code, the difficulty of reading the code is increased, thereby preventing reverse engineering analysis to a certain extent.

[0004] Although the above code obfuscation technology can increase the difficulty of directly compiling the code, professional reverse engineering tools may still successfully decompile the APK file, restore most of the logical structure of the APP, and then modify the original functions in the APP, such as changing the user interface, business logic, or even implanting advertisements, stealing sensitive user information, or inserting malicious code, etc., and then repackaging and signing the tampered content, thereby bypassing the security checks of most devices, posing a serious threat to the security of the APP. Summary of the Invention

[0005] The embodiments of this application provide a method, system, device and medium for multi-anti-tampering of Android APPs, which can improve the ability of the APP to resist tampering and attacks, and protect the security and integrity of the APP.

[0006] In the first aspect, the embodiments of this application provide a method for multi-anti-tampering of Android APPs, including:

[0007] Obtain the dex file of the APP, and encrypt the dex file using a reinforcement algorithm to generate a dex reinforcement file;

[0008] Use a signature obfuscation algorithm to embed an obfuscated code segment in the dex reinforcement file to generate a signature verification module;

[0009] Use an encrypted storage algorithm to encrypt the resource file of the APP to generate a resource encrypted file;

[0010] When starting the APP, based on the signature verification module, perform a secondary integrity check on the APP;

[0011] If the integrity of the APP is not damaged, load the resource encrypted file and perform a decryption operation on the resource encrypted file;

[0012] After the decryption operation, during the running of the APP, perform a verification on the critical business logic code segment by running a verification method.

[0013] Further, obtaining the dex file of the APP and encrypting the dex file using a reinforcement algorithm to generate a dex reinforcement file includes:

[0014] Unpack the APK file of the APP using a decompilation tool to obtain the dex file, and load the dex file into memory;

[0015] Adopt the AES encryption algorithm, and segmentally encrypt the dex data of the dex file according to the data characteristics of the dex file;

[0016] Package the encrypted dex data according to the initial mode to generate a dex reinforcement file, and the dex reinforcement file has the same file name and storage path information as the dex file;

[0017] Based on the dex reinforcement file, perform packaging and signing on the APP.

[0018] Further, the step of adopting the AES encryption algorithm to segmentally encrypt the dex data of the dex file according to the data characteristics of the dex file includes:

[0019] During the encryption process, traverse each module code segment in the dex file, adopt the AES encryption algorithm to encrypt the dex data of each module code segment respectively, and select an encryption mode for encryption processing according to the data characteristics of the dex data of each module code segment;

[0020] Before encryption, judge whether multiple dex files are included by parsing the dex file header of the dex file;

[0021] For multiple dex files, perform encryption processing on the multiple dex files in sequence, and after the encryption is completed, modify the magic field of the dex file to an encrypted field.

[0022] Further, the step of adopting a signature obfuscation algorithm to embed an obfuscated code segment in the dex reinforcement file to generate a signature verification module includes:

[0023] Analyze the signature verification logic of the dex reinforcement file to determine the critical code segment for signature verification;

[0024] Perform obfuscation processing on the key code segment based on a preset obfuscation rule to generate an obfuscated code segment;

[0025] Embed the obfuscated code segment into the dex reinforcement file to generate an obfuscation verification logic;

[0026] Based on a preset public key, perform asymmetric encryption on the obfuscation verification logic, and package and sign the encryption result of the asymmetric encryption with the dex reinforcement file to generate a signature verification module.

[0027] Further, when starting the APP, based on the signature verification module, perform a secondary integrity check on the APP, including:

[0028] Perform signature verification on the signature verification module based on a preset signature information to obtain the dex reinforcement file and the encryption result;

[0029] Based on a preset private key, decrypt the encryption result to obtain the obfuscation verification logic;

[0030] Load the dex reinforcement file, and based on the dex reinforcement file, dynamically call the obfuscation verification logic, and use a preset signature verification method to verify the file data of the APP.

[0031] Further, the performing signature verification on the signature verification module based on a preset signature information includes:

[0032] Obtain multiple digital fingerprints in the signature information, perform one-time encryption on each of the multiple digital fingerprints to obtain corresponding encrypted strings;

[0033] Concatenate the multiple encrypted strings to generate a concatenated string;

[0034] Perform secondary encryption on the concatenated string to generate a signature verification code;

[0035] Compare the signature verification code with a preset signature public key to determine the integrity of the signature verification module.

[0036] Further, the verifying the key business logic code segment during the running of the APP through the running verification method includes:

[0037] During the running of the APP, obtain the key business logic code segment, and assign a unique identifier to the key business logic code segment;

[0038] Based on the unique identifier, obtain the initial feature value of the key business logic code segment from a pre-established code segment feature library;

[0039] Calculate the current eigenvalue of the critical business logic code segment using the MD5 algorithm;

[0040] By comparing the initial eigenvalue and the current eigenvalue, determine whether the critical business logic code segment has been tampered with.

[0041] In a second aspect, an Android APP multiple anti-tampering system provided by an embodiment of the present application includes:

[0042] The first processing module: used to obtain the dex file of the APP, and encrypt the dex file using a reinforcement algorithm to generate a dex reinforcement file;

[0043] The second processing module: used to embed an obfuscation code segment in the dex reinforcement file using a signature obfuscation algorithm to generate a signature verification module;

[0044] The third processing module: used to encrypt the resource file of the APP using an encrypted storage algorithm to generate a resource encrypted file;

[0045] The fourth processing module: used to perform a secondary integrity check on the APP based on the signature verification module when the APP is started;

[0046] The fifth processing module: used to load the resource encrypted file and decrypt the resource encrypted file if the integrity of the APP is not damaged;

[0047] The sixth processing module: used to verify the critical business logic code segment during the operation of the APP by running a verification method after the decryption operation.

[0048] In a third aspect, an embodiment of the present application provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the above-mentioned Android APP multiple anti-tampering method is implemented.

[0049] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, including a computer program stored in the computer-readable storage medium. When the computer program is executed by a processor, the above-mentioned Android APP multiple anti-tampering method is implemented.

[0050] The beneficial effects of the embodiments of the present application compared with the prior art are:

[0051] The present invention discloses a method for multi - anti - tampering of Android APPs. By strengthening the dex files of the APP and embedding the obfuscated signature verification logic therein. At the same time, encrypt and store the resource files of the APP. When the APP is started, dynamically load the strengthened dex files and use the signature verification module to verify the integrity of the APP. If the verification passes, load and decrypt the resource files. In addition, introduce a running verification method to monitor the code segment during the running process of the APP to prevent tampering. By combining protection processes such as dex file strengthening, APP signature verification, resource encryption, and running - time verification, a complete multi - protection system is formed, effectively improving the ability of the APP to resist tampering and attacks, thereby protecting the security and integrity of the APP. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings required for use in the embodiments or the description of the prior art. Obviously, the following drawings are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0053] Figure 1 It is a schematic flowchart of a method for multi - anti - tampering of Android APPs provided by an embodiment of the present invention;

[0054] Figure 2 It is a schematic structural diagram of a multi - anti - tampering system for Android APPs provided by an embodiment of the present invention;

[0055] Figure 3 It is a schematic structural diagram of a computer device provided by an embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0056] In the following description, for the purpose of illustration rather than limitation, specific details such as specific system structures and technologies are put forward in order to thoroughly understand the embodiments of the present application. However, those skilled in the art should clearly understand that the present application can also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well - known systems, devices, circuits, and methods are omitted to avoid unnecessary details from interfering with the description of the present application.

[0057] It should be understood that when used in the specification of the present application and the appended claims, the term "comprising" indicates the presence of the described features, wholes, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components, and / or their combinations.

[0058] It should also be understood that the term "and / or" as used in the specification and appended claims of this application refers to any combination and all possible combinations of one or more of the associated listed items, and includes these combinations.

[0059] As used in the specification and appended claims of this application, the term "if" may be construed, depending on the context, as "when", "once", "in response to determining", or "in response to detecting". Similarly, the phrases "if determined" or "if [the described condition or event] is detected" may be construed, depending on the context, as meaning "once determined", "in response to determining", "once [the described condition or event] is detected", or "in response to detecting [the described condition or event]".

[0060] In addition, in the description of the specification and appended claims of this application, the terms "first", "second", "third", etc. are only used for distinguishing descriptions and should not be construed as indicating or implying relative importance.

[0061] Reference to "one embodiment" or "some embodiments" etc. described in the specification of this application means that a specific feature, structure, or characteristic described in connection with that embodiment is included in one or more embodiments of this application. Thus, statements such as "in one embodiment", "in some embodiments", "in other some embodiments", "in still other embodiments", etc. that appear in different places in this specification do not necessarily all refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized. The terms "comprising", "including", "having", and their variants all mean "including but not limited to", unless otherwise specifically emphasized.

[0062] Please refer to Figure 1 As shown, the present invention is an Android APP multiple anti-tampering method, including the following steps:

[0063] S100. Obtain the dex file of the APP, and encrypt the dex file using a reinforcement algorithm to generate a dex reinforcement file;

[0064] In some of these embodiments, the above step S100 includes:

[0065] Unpack the APK file of the APP through a decompilation tool to obtain the dex file;

[0066] Load the dex file into memory, and use the AES encryption algorithm to encrypt the dex data of the dex file, where the dex data includes data fields and method data;

[0067] Encapsulate the encrypted dex data according to the initial mode to generate a dex fortified file, where the dex fortified file has the same file name and storage path information as the dex file;

[0068] Based on the dex fortified file, package and sign the APP.

[0069] Specifically, the code of an Android APP is generally written in Java or Kotlin and finally compiled into a dex file, and the dex file will ultimately be packaged into an apk file. The apk file is the APP package finally installed on an Android phone and can be normally installed and run in the Android system.

[0070] In this embodiment, by strengthening the dex file in the APK file, it is prevented that the dex file is decompiled by tools such as apktool.jar to generate a new APP package, thereby tampering with the relevant content of the APP.

[0071] In this embodiment, when obtaining the dex file of the APP, the APK file is unpacked through a decompilation tool to obtain the relevant dex file. The dex file contains the code logic information of the APP. The obtained dex file is loaded into the memory through the DexClassLoader class, thereby avoiding directly modifying the file on the disk and improving security.

[0072] In this embodiment, according to the corresponding encryption requirements, based on the standard of the AES encryption algorithm, select the corresponding key length, and store the generated key in a secure storage area, such as an encrypted storage service, a hardware security module (HSM), or a secure key management service (KMS), to ensure that only authorized applications or services can access the key.

[0073] It can be understood that the initial mode is the original format of the dex file. For the encrypted dex data, it is encapsulated according to the original format of the dex file to generate a dex fortified file, thereby ensuring the consistency of the dex fortified file and the dex file in terms of data and structure and avoiding compatibility problems caused by file structure changes. Specifically, obtain the file name and storage path information of the dex file, create a dex fortified file with the same file name and storage path information as the dex file, and then encapsulate the encrypted dex data according to the initial mode and write it into the created dex fortified file.

[0074] In some embodiments, for the generated dex fortified file, by verifying the data format and file attributes of the dex fortified file, it is determined whether the dex fortified file is consistent with the dex file; if the dex fortified file is consistent with the format and attributes of the original dex file, the dex fortified file is stored in the specified path; if the dex fortified file is inconsistent with the format or attributes of the dex file, the encapsulation method of the encrypted data is adjusted to regenerate the dex fortified file until it is consistent with the original dex file. In addition, in order to further improve the security of the dex fortified file, in some other embodiments, the integrity of the encrypted dex fortified file is also verified to generate a digital signature or hash value to prevent the dex fortified file from being tampered with or replaced.

[0075] In this embodiment, the dex fortified file also includes a shell dex file for decrypting and loading the encrypted dex file. Specifically, the shell DEX file usually contains the decryption algorithm and loading logic of the dex file.

[0076] In this embodiment, the above dex fortified file is used as the base file for APP packaging and signing. For the above dex fortified file, an APP packaging operation is performed using a packaging tool to obtain an unsigned APP installation package file. Through a signing tool, the APP installation package file is digitally signed to obtain a signed APP installation package to ensure the integrity and security of the APP.

[0077] In some of these embodiments, the AES encryption algorithm is used to segmentally encrypt the dex data of the dex file according to the data characteristics of the dex file, including:

[0078] During the encryption process, each module code segment in the dex file is traversed, and the dex data of each module code segment is encrypted using the AES encryption algorithm, and an encryption mode is selected for the module code segment for encryption processing according to the data characteristics of the dex data of each module code segment;

[0079] Before encryption, by parsing the dex file header of the dex file, it is determined whether multiple dex files are included;

[0080] For multiple dex files, the multiple dex files are sequentially encrypted, and after the encryption is completed, the magic field of the dex file is modified to an encrypted field.

[0081] In this embodiment, the encryption process involves the data of each part of the dex file. Each part carries specific information and is a core component of the dex file, containing the logic and data structure of the application. Considering the data structure characteristics of the dex file, a segmented encryption strategy is adopted. The dex file is divided into multiple module code segments, and the dex data in each module code segment is separately encrypted using AES to improve the encryption efficiency and security. Specifically, a dex file can usually be divided into a dex file header, an index area, and a data area. Since the dex file header usually includes fields such as magic, checksum, signature, fileSize, and headerSize that are used to uniquely identify the dex file or represent the size of the dex file, during the reinforcement process of the dex file, relevant fields in the dex file header, such as checksum and signature, will be recalculated and reassigned according to the encryption of the dex data. Therefore, the dex file header is not encrypted. For the index area and the data area, each corresponds to a module code segment. At the same time, the dex data in each module code segment is traversed, and a suitable encryption mode is selected for encryption according to the data characteristics of the dex data.

[0082] It can be understood that in a module code segment, according to the data characteristics of the dex data, it usually includes data structure types and method types. For data structure types and method types, different encryption modes are respectively adopted according to the data length and data complexity, such as the ECB mode or the CBC mode. For data structure types with a small amount of data, the ECB mode can be selected for encryption. However, when encrypting the same data, the same ciphertext block is usually generated. Therefore, in some possible embodiments, the CBC mode is usually adopted for encryption to ensure the integrity and security of encryption. When performing AES encryption on the data of the method type in the dex file, since the data of the method type usually has a long length and contains a complex information structure, the CBC mode is usually adopted for encryption. In addition, when using the CBC mode for data encryption, a random initialization vector (IV) is generated for each data block and stored in plaintext together with the encrypted data, thereby enhancing the randomness and unpredictability of encryption and preventing dictionary attacks. It can be understood that the above data blocks are field data blocks of the data structure type or method data blocks of the method type, which is convenient for encrypting the dex data.

[0083] In an APP package, it is common to have multiple dex files packed. Therefore, in this embodiment, before encryption, it is necessary to determine whether the APP package contains multiple dex files. Specifically, since the dex file header is the starting point of the entire dex file and contains the basic attribute information of the dex file, by parsing the information content in the dex file header, it is further determined whether multiple dex files are included. For multiple dex files, the above encryption process is performed sequentially to ensure that all DEX files are encrypted and protected. In addition, after the encryption is completed, the magic field of the dex file needs to be modified to an encrypted field. It should be noted that the magic field is the identifier of the dex file. After the encryption is completed, it is replaced with the encrypted field to indicate that the dex file has been encrypted, preventing unauthorized decompilation and analysis. In one embodiment, the AES algorithm is used to encrypt the magic field to generate an encrypted byte sequence, that is, the encrypted field.

[0084] S200. Adopt a signature obfuscation algorithm to embed an obfuscated code segment in the dex fortified file to generate a signature verification module;

[0085] In this embodiment, the code segment related to the signature verification logic in the dex fortified file is further encrypted to generate an obfuscated code segment, thereby further improving the anti-tampering ability of the Android APP.

[0086] In some of these embodiments, the above step S200 includes:

[0087] Analyze the signature verification logic of the dex fortified file to determine the key code segment for signature verification;

[0088] Based on a preset obfuscation rule, perform obfuscation processing on the key code segment to generate an obfuscated code segment;

[0089] Embed the obfuscated code segment into the dex fortified file to generate an obfuscated verification logic;

[0090] Based on a preset public key, perform asymmetric encryption on the obfuscated verification logic to generate an encryption result;

[0091] Based on the encryption result and the dex fortified file, generate a signature verification module and perform packaging and signing on the APP.

[0092] In this embodiment, the key code segments that need to be obfuscated are obtained. Specifically, in the dex reinforcement file, the location where the signature verification logic is located is located, and then the key code segments used to verify whether the dex reinforcement file has been tampered with are extracted from the signature verification logic. The above key code segments usually involve reading the signature file, using the public key for signature verification, etc. For the key code segments, preset obfuscation rules are determined. The obfuscation rules can include the replacement of variable names, method names, class names, and the adjustment of code structures, etc.; according to the obfuscation rules, the control flow, data flow, etc. in the key code segments are obfuscated. Specifically, it can include inserting useless code, obfuscating variable names, splitting functions, etc.; through the semantic equivalence conversion algorithm, the code structure is changed on the premise of keeping the code semantics unchanged, increasing the code complexity; according to the obfuscated code structure, an obfuscated code segment is generated; in actual applications, the obfuscated code segment is tested to ensure that its function is the same as that of the original code segment, and the obfuscated code segment replaces the original key code segment, thereby realizing the security protection of the code.

[0093] In this embodiment, a dex editing tool, such as dexlib2, baksmali / smali, etc., is used to embed the obfuscated code segment back into the dex reinforcement file to replace the original signature verification logic. In some embodiments, a verification logic is added to the dex reinforcement file to verify the integrity of the obfuscated code segment.

[0094] In this embodiment, a public key for encrypting the obfuscation verification logic is selected from the preset public keys, and the obfuscation verification logic is asymmetrically encrypted using the public key to generate an encryption result. Based on the encryption result and the dex reinforcement file, a signature verification module is generated, and the APP is packaged and signed. Specifically, the encryption result and the dex reinforcement file are encapsulated into a signature verification module, and during the APP packaging process, the encryption result is embedded in a specific location of the APK file or stored as an external resource of the APK file. In addition, the APK file needs to be signed, thereby increasing the difficulty of tampering with the finally generated APP package.

[0095] When running the APP, it is necessary to decrypt the obfuscation verification logic with the private key first before performing the verification based on the obfuscation verification logic.

[0096] S300. An encryption storage algorithm is adopted to encrypt the resource files of the APP to generate resource encrypted files;

[0097] In some of these embodiments, the above step S300 includes:

[0098] For the resource types of different resource files, different encryption algorithms are adopted to encrypt the resource files. The resource files include text files, picture files, and audio-video files.

[0099] In this embodiment, a resource file to be encrypted is obtained, and the type of the resource file is determined. If the resource file is a text file, a symmetric encryption algorithm is used to encrypt the text file to obtain an encrypted text file; if the resource file is a picture file, according to the characteristics of the picture file, an image encryption algorithm based on the chaos theory is used to encrypt the picture file. By scrambling and diffusing the image pixel positions and pixel values, an encrypted picture file is obtained; if the resource file is an audio-video file, according to the characteristics of the audio-video data, an encryption algorithm combining intra-frame prediction and inter-frame prediction is used to perform segmented encryption on the audio-video file. According to the different characteristics of intra-frame prediction and inter-frame prediction, the key frames and non-key frames are encrypted respectively to obtain an encrypted audio-video file.

[0100] In this embodiment, according to the confidentiality level of the resource file, the key length and the number of encryption rounds of the encryption algorithm are determined. The longer the key length and the more the number of encryption rounds, the higher the encryption strength and the better the security of the resource file; the integrity of the encrypted resource file is verified. By calculating the hash value of the resource file, it is judged whether the resource file has been tampered with to ensure the integrity of the resource file; the encrypted resource file and the corresponding encryption parameters are stored securely, and a secure and reliable key management mechanism is used to protect the encryption key to prevent key leakage; an access control mechanism for the resource file is established. According to the identity and permissions of the user, the user's access to the encrypted resource file is controlled, and only authorized users are allowed to access the corresponding resource file to ensure the confidentiality of the resource file.

[0101] S400. When starting the APP, based on the signature verification module, perform a secondary integrity detection on the APP;

[0102] In this embodiment, during the process of starting the APP, performing a secondary integrity detection on the APP can timely detect whether the APP has been maliciously tampered with. The first integrity detection is the first layer of anti-tampering, which combines the reinforcement of the dex file and the packaging signature of the APP to increase the difficulty of decompiling and tampering with the APP. The second integrity detection is the second layer of anti-tampering. The file data in the APP is verified to check whether the file data has been modified or replaced without authorization, preventing the file data from being maliciously tampered with and further reducing the possibility of the APP being tampered with.

[0103] In some of the embodiments, the above step S400 includes:

[0104] Based on the preset signature information, perform a signature verification on the APP to obtain the dex reinforcement file and the encryption result;

[0105] Based on the preset private key, decrypt the encryption result to obtain the obfuscated verification logic;

[0106] Load the dex reinforcement file, and based on the dex reinforcement file, dynamically call the obfuscation verification logic, and use a preset signature verification method to verify the file data of the APP.

[0107] In this embodiment, when the APP is started, the APP is signature-verified based on preset signature information. If the signature verification fails, the execution of the application is terminated by throwing an exception; if the signature verification passes, the corresponding encryption result and dex reinforcement file are obtained from the signature verification module. It can be understood that the signature information is generated when the APP is packaged and signed in step S200 and is used to verify the APP.

[0108] In this embodiment, the encryption result is decrypted based on a preset private key to obtain the corresponding obfuscation verification logic. The dex reinforcement file is dynamically loaded into the memory through DexClassLoader. From the loaded dex reinforcement file, the obfuscation verification logic is dynamically called to obtain the class names and method names in the obfuscated code segment. The above class names are instantiated using the reflection mechanism to obtain a signature verification object. A preset signature verification method is used to perform signature verification on the file data of the APP to determine whether the file data in the APP has been tampered with. Specifically, the file data includes resource files and key files such as AndroidManifest.xml.

[0109] Specifically, the above dex file reinforcement process only protects the relevant code from being tampered with, and there is still a risk that the file data in the APP, etc., may be tampered with. When the above file data is tampered with and repackaged and signed, the new APP package can still be installed and run normally. Therefore, in this embodiment, signature verification of the file data in the APP is also included to prevent the file data from being maliciously tampered with.

[0110] In one embodiment, a preset signature verification method is used to perform signature verification on the file data of the APP to determine whether the file data in the APP has been tampered with. Specifically, it includes: using the MD5 algorithm to calculate the hash of the key files (such as AndroidManifest.xml) and resource files of the APP to obtain an integrity verification code; passing the integrity verification code to the signature verification object, and then calling the signature verification method therein; in the signature verification method, the integrity verification code is verified through a preset verification code to determine whether the file data in the APP has been tampered with.

[0111] In this embodiment, when calling the obfuscation verification logic, the reflection technology is used to avoid directly exposing the real method names and class names of the signature verification logic in the code, increasing its concealment.

[0112] In this embodiment, during the signature verification process, a random number generator is introduced to dynamically generate parameters such as the salt value used during verification, improving the unpredictability of the signature verification logic and increasing the difficulty for attackers to crack it.

[0113] In some of these embodiments, performing signature verification on the APP based on the preset signature information includes:

[0114] Obtaining multiple Fingerprint values in the signature information, encrypting each of the multiple Fingerprint values once to obtain corresponding encrypted strings;

[0115] Concatenating the multiple encrypted strings to generate a concatenated string;

[0116] Performing secondary encryption on the concatenated string to generate a signature verification code;

[0117] Comparing the signature verification code with the preset signature public key to determine the integrity of the APP.

[0118] Specifically, when an Android APP is packaged into an APK file, it is signed and corresponding signature information is generated for verifying the integrity of the APP. The signature information includes Fingerprint values generated by various hash algorithms. The above Fingerprint values are used to uniquely identify the signature. Among them, the hash algorithms include but are not limited to MD5, SHA-1, and SHA-256.

[0119] In this embodiment, when the APP is started, the Fingerprint values in the current APP signature information are obtained, specifically the Fingerprint values of MD5, SHA-1, and SHA-256. The Fingerprint values of MD5, SHA-1, and SHA-256 are encrypted once respectively to generate encrypted strings of the Fingerprints of MD5, SHA-1, and SHA-256. Then, the above encrypted strings are concatenated to generate a concatenated string, and the concatenated string is encrypted twice to obtain the final signature verification code. Specifically, both the first encryption and the second encryption can be MD5 encryption.

[0120] In this embodiment, the correct signature public key is preset in the APP code. By comparing whether the signature verification code is equal to the signature public key, the integrity of the APP is determined. Specifically, if they are equal, it indicates that the current APP has not been tampered with and the APP can be run normally; if they are not equal, it indicates that the current APP has been tampered with, an abnormal log is recorded, and a warning prompt box is popped up, prompting the user that "the APP has been tampered with. For security reasons, do not continue to use it", and the APP is exited.

[0121] S500. If the integrity of the APP is not compromised, load the resource encrypted file and perform a decryption operation on the resource encrypted file.

[0122] In this embodiment, through the verification in step S400 above, the integrity of the APP package and the file data of the APP is not compromised. Then start the APP, load the corresponding resource encrypted file, and perform a decryption operation on it. If the integrity verification of either the APP package or the file data fails, terminate the operation of the APP and give a security warning. By performing two verifications on the APP package and the file data, the possibility of the APP being tampered with is reduced.

[0123] S600. After the decryption operation, during the operation of the APP, verify the critical business logic code segment by running a verification method.

[0124] In this application, during the operation of the APP, a third anti-tampering operation for the APP is performed. By monitoring the critical business logic code segment during the operation of the APP, the possibility of the relevant code being tampered with during the operation is reduced.

[0125] In some of the embodiments, the verification of the critical business logic code segment during the operation of the APP by running a verification method includes:

[0126] During the operation of the APP, obtain the critical business logic code segment and assign a unique identifier to the critical business logic code segment;

[0127] Based on the unique identifier, obtain the initial feature value of the critical business logic code segment from a pre-established code segment feature library;

[0128] [[ID=]]Using the MD5 algorithm, calculate the critical business logic code segment to obtain the current feature value of the critical business logic code segment;

[0129] By comparing the initial feature value and the current feature value, determine whether the critical business logic code segment has been tampered with.

[0130] In this embodiment, during the operation of the APP, the critical business logic code segment is monitored in real time, thereby reducing the possibility of the relevant code being tampered with during the operation of the APP.

[0131] Specifically, obtain the critical business logic code segment to be executed. By scanning the code repository or the path of the critical business logic code segment pre-configured in the configuration file, read the corresponding code file to obtain the critical business logic code segment, and set a unique identifier for the critical business logic code segment. In one embodiment, information such as the file path and method signature of the critical business logic code segment is used to generate a SHA256 digest, and the above SHA256 digest is used as the unique identifier of the code segment.

[0132] In this embodiment, according to the unique identifier of the critical business logic code segment, obtain the initial feature value corresponding to the critical business logic code segment from the pre-established code segment feature library. Specifically, the code segment feature library is stored in the form of key-value pairs, with the unique identifier of the code segment as the key and the SHA256 digest of the code segment as the value. When initializing the code segment feature library, it is necessary to traverse all critical business logic code segments, calculate their SHA256 digests and store them.

[0133] In this embodiment, use the MD5 algorithm to calculate the currently executing critical business logic code segment to obtain its current MD5 digest as the current feature value. Compare the current feature value with the initial feature value obtained from the code segment feature library to determine whether the two feature values are the same. If the two feature values are the same, it is determined that the critical business logic code segment has not been tampered with, and the critical business logic code segment is executed. If the two feature values are different, it is determined that the critical business logic code segment has been tampered with, reject the execution of the business logic, record the tampering event log, send an alarm notification, and interrupt the current business process;

[0134] In this embodiment, after the critical business logic is executed, recalculate the SHA256 digest of the code segment according to the unique identifier of the code segment, and update the initial feature value in the code segment feature library to ensure the real-time validity of the initial feature value of the code segment feature library.

[0135] In this application, through a multi-layer protection mechanism, combining protection processes such as dex file reinforcement, APP signature verification, resource encryption, and runtime verification, a complete protection system is formed to increase the difficulty of APP tampering. Specifically, through the secondary integrity verification before APP startup and the integrity verification during APP operation, multiple anti-tampering of the APP is realized. In the first anti-tampering, the reinforcement of the dex file is combined with the packaging signature of the APP to increase the difficulty of APP decompilation and tampering; in the second anti-tampering, the file data in the APP is verified to prevent malicious tampering of the file data, and at the same time, the resource files are encrypted to further improve the security of the APP file data; in the third anti-tampering, the code segments during APP operation are monitored to reduce the possibility of related code being tampered with during operation.

[0136] Please refer to Figure 2 As shown, the present invention also provides an Android APP multiple anti-tampering system, and the system includes:

[0137] The first processing module 201: is used to obtain the dex file of the APP, encrypt the dex file by using a reinforcement algorithm, and generate a dex reinforced file;

[0138] The second processing module 202: is used to embed a confusion code segment into the dex reinforced file by using a signature confusion algorithm to generate a signature verification module;

[0139] The third processing module 203: is used to encrypt the resource file of the APP by using an encrypted storage algorithm to generate a resource encrypted file;

[0140] The fourth processing module 204: is used to perform a secondary integrity detection on the APP based on the signature verification module when the APP is started;

[0141] The fifth processing module 205: is used to load the resource encrypted file and perform a decryption operation on the resource encrypted file if the integrity of the APP is not damaged;

[0142] The sixth processing module 206: is used to verify the critical business logic code segment during the running of the APP by running a verification method after the decryption operation.

[0143] It can be understood that the content in the embodiments of the Android APP multiple anti-tampering method as Figure 1 shown is applicable to the embodiments of this Android APP multiple anti-tampering system. The functions specifically implemented by the embodiments of this Android APP multiple anti-tampering system are the same as those in the embodiments of the Android APP multiple anti-tampering method as Figure 1 shown, and the beneficial effects achieved are also the same as those in the embodiments of the Android APP multiple anti-tampering method as Figure 1 shown.

[0144] It should be noted that for the information interaction, execution process, etc. between the above systems, since they are based on the same concept as the method embodiments of the present invention, the specific functions and the technical effects brought by them can be specifically referred to in the method embodiment part, and will not be elaborated here.

[0145] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the above-mentioned division of each functional unit and module is used as an example. In actual applications, the above functions can be allocated to different functional units and modules according to needs, that is, the internal structure of the system is divided into different functional units or modules to complete all or part of the functions described above. Each functional unit and module in the embodiment can be integrated in a processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of a software functional unit. In addition, the specific names of each functional unit and module are only for the convenience of mutual distinction and do not limit the protection scope of this application. The specific working processes of the units and modules in the above system can refer to the corresponding processes in the foregoing method embodiments and will not be elaborated herein.

[0146] Please refer to Figure 3 As shown, an embodiment of the present invention further provides a computer device 3, including: a memory 302, a processor 301, and a computer program 303 stored on the memory 302. When the computer program 303 is executed on the processor 301, the Android APP multiple anti-tampering method described in any one of the above methods is implemented.

[0147] The computer device 3 may be a computing device such as a desktop computer, a notebook, a palm computer, and a cloud server. The computer device 3 may include, but is not limited to, a processor 301 and a memory 302. Those skilled in the art can understand that Figure 3 This is only an example of the computer device 3 and does not constitute a limitation on the computer device 3. It may include more or fewer components than shown in the figure, or combine some components, or different components. For example, it may also include input / output devices, network access devices, etc.

[0148] The so-called processor 301 may be a central processing unit (CPU), and the processor 301 may also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc.

[0149] In some embodiments, the memory 302 may be an internal storage unit of the computer device 3, such as the hard disk or memory of the computer device 3. In other embodiments, the memory 302 may also be an external storage device of the computer device 3, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) card, a Flash Card, etc. equipped on the computer device 3. Further, the memory 302 may also include both the internal storage unit and the external storage device of the computer device 3. The memory 302 is used to store an operating system, application programs, a BootLoader, data, and other programs, such as the program code of the computer program. The memory 302 may also be used to temporarily store data that has been output or will be output.

[0150] An embodiment of the present invention also provides a computer-readable storage medium, on which a computer program is stored. When the computer program is run by a processor, it implements the Android APP multi-anti-tampering method as described in any one of the above methods.

[0151] In this embodiment, if the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on such an understanding, to implement all or part of the processes in the above embodiment methods of the present application, a computer program can be used to instruct relevant hardware to complete. The computer program can be stored in a computer-readable storage medium. When the computer program is executed by a processor, it can implement the steps of the above various method embodiments. Among them, the computer program includes computer program code, and the computer program code can be in the form of source code, object code, an executable file, or some intermediate form, etc. The computer-readable medium may at least include: any entity or device that can carry the computer program code to the photographing device / computer device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. For example, a USB flash drive, a mobile hard disk, a magnetic disk, or an optical disc, etc. In some jurisdictions, according to legislation and patent practice, the computer-readable medium may not be an electrical carrier signal and a telecommunication signal.

[0152] The above-described embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that: they can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements on some of the technical features; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should all be included within the protection scope of the present application.

Claims

1. An Android APP multiple anti-tampering method, characterized in that, Including: Obtain the dex file of the APP, encrypt the dex file using a reinforcement algorithm to generate a dex reinforced file; Use a signature obfuscation algorithm to embed an obfuscated code segment in the dex reinforced file to generate a signature verification module; Use an encrypted storage algorithm to encrypt the resource file of the APP to generate a resource encrypted file; When starting the APP, based on the signature verification module, perform a secondary integrity check on the APP; If the integrity of the APP is not damaged, load the resource encrypted file and perform a decryption operation on the resource encrypted file; After the decryption operation, by running a verification method, during the operation of the APP, verify the critical business logic code segment.

2. The method according to claim 1, characterized in that The obtaining the dex file of the APP, encrypting the dex file using a reinforcement algorithm to generate a dex reinforced file includes: Use a decompilation tool to unpack the APK file of the APP to obtain the dex file, and load the dex file into memory; Use the AES encryption algorithm to segmentally encrypt the dex data of the dex file according to the data characteristics of the dex file; Encapsulate the encrypted dex data according to the initial mode to generate a dex reinforced file, and the dex reinforced file has the same file name and storage path information as the dex file; Based on the dex reinforced file, perform packaging and signing on the APP.

3. The method according to claim 2, wherein The using the AES encryption algorithm to segmentally encrypt the dex data of the dex file according to the data characteristics of the dex file includes: During the encryption process, traverse each module code segment in the dex file, use the AES encryption algorithm to encrypt the dex data of each module code segment respectively, and according to the data characteristics of the dex data of each module code segment, select an encryption mode for the module code segment for encryption processing; Before encryption, by parsing the dex file header of the dex file, determine whether multiple dex files are included; For multiple dex files, encrypt the multiple dex files in sequence, and after encryption, modify the magic field of the dex file to an encrypted field.

4. The method according to claim 1, wherein The using a signature obfuscation algorithm to embed an obfuscated code segment in the dex reinforced file to generate a signature verification module includes: Analyze the signature verification logic of the dex reinforced file to determine the critical code segment for signature verification; Based on a preset obfuscation rule, perform obfuscation processing on the critical code segment to generate an obfuscated code segment; Embed the obfuscated code segment into the dex reinforced file to generate an obfuscated verification logic; Based on a preset public key, perform asymmetric encryption on the obfuscated verification logic, and package and sign the asymmetric encryption result with the dex reinforced file to generate a signature verification module.

5. The method according to claim 4, wherein When starting the APP, based on the signature verification module, perform a secondary integrity check on the APP, including: Based on a preset signature information, perform signature verification on the signature verification module to obtain the dex reinforced file and the encryption result; Decrypt the encrypted result based on a preset private key to obtain the obfuscated verification logic; Load the dex reinforcement file, and based on the dex reinforcement file, dynamically call the obfuscated verification logic, and use a preset signature verification method to verify the file data of the APP.

6. The method according to claim 5, characterized in that, The signature verification of the signature verification module based on the preset signature information includes: Obtain multiple digital fingerprints in the signature information, encrypt each of the multiple digital fingerprints once to obtain corresponding encrypted strings; Concatenate the multiple encrypted strings to generate a concatenated string; Perform secondary encryption on the concatenated string to generate a signature verification code; Compare the signature verification code with a preset signature public key to determine the integrity of the signature verification module.

7. The method according to claim 1, wherein The verification by running the verification method to verify the critical business logic code segment during the running of the APP includes: During the running of the APP, obtain the critical business logic code segment and assign a unique identifier to the critical business logic code segment; Based on the unique identifier, obtain the initial feature value of the critical business logic code segment from a pre-established code segment feature library; Use the MD5 algorithm to calculate the critical business logic code segment to obtain the current feature value of the critical business logic code segment; Judge whether the critical business logic code segment has been tampered with by comparing the initial feature value and the current feature value.

8. An Android APP multiple anti-tampering system, characterized in that, Includes: The first processing module: used to obtain the dex file of the APP, and encrypt the dex file using a reinforcement algorithm to generate a dex reinforcement file; The second processing module: used to embed an obfuscated code segment in the dex reinforcement file using a signature obfuscation algorithm to generate a signature verification module; The third processing module: used to encrypt the resource file of the APP using an encrypted storage algorithm to generate a resource encrypted file; The fourth processing module: used to perform secondary integrity detection on the APP based on the signature verification module when the APP is started; The fifth processing module: used to load the resource encrypted file and perform a decryption operation on the resource encrypted file if the integrity of the APP is not damaged; The sixth processing module: used to verify the critical business logic code segment during the running of the APP by running the verification method after the decryption operation.

9. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method according to any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the method according to any one of claims 1 to 7.

Images