Application reinforcement method and device, storage medium and electronic equipment

Abstract

The application discloses a kind of application reinforcement method and device, storage medium and electronic equipment. Among them, the method comprises: obtaining the code relationship diagram of target application program, wherein the code relationship diagram includes the reference relationship between each class in the bytecode assembly file corresponding to target application program;Based on the class code of each class, generate code retrieval strategy, wherein the code retrieval strategy includes a set of retrieval rules generated using the reference relationship between each class;Based on a set of retrieval rules, determine the code set to be processed from bytecode assembly file;The code in the code set to be processed is reinforced, and the reinforced target application program is obtained. The present application solves the technical problem of low efficiency in the application program reinforcement process in the related art.

Description

Technical Field

[0001] This application relates to the field of computers, and more specifically, to a method and apparatus for hardening applications, a storage medium, and an electronic device. Background Technology

[0002] With the rapid development of the Android platform, it has become the mainstream market for mobile smart terminals. Due to the open-source nature of the Android system and the fact that Android applications are primarily developed using Java, which generates .dex files after compilation, these files can be easily decompiled to visually display the program's code to the user. With slight modifications, new mobile applications can be generated. Therefore, application hardening is particularly important to prevent malicious attacks.

[0003] In related technologies, application hardening methods mainly include two types: one is to encrypt the entire code, and the other is to extract the instructions of the target function from the dex file, encrypt them, and then decrypt and fill them in as needed at runtime. However, the method of encrypting the entire code incurs significant runtime overhead, while the latter hardening method cannot accurately locate the code that needs hardening, and the decryption process during runtime cannot guarantee the stability of the application. In other words, related technologies suffer from low efficiency in the application hardening process.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This application provides a method and apparatus for hardening applications, a storage medium, and an electronic device to at least solve the technical problem of low efficiency in the application hardening process.

[0006] According to one aspect of the embodiments of this application, an application hardening method is provided, comprising: obtaining a code relationship graph of a target application, wherein the code relationship graph includes reference relationships between classes in a bytecode assembly file corresponding to the target application; generating a code retrieval strategy based on the class code of each class, wherein the code retrieval strategy includes a set of retrieval rules generated using the reference relationships between classes; determining a code set to be processed from the bytecode assembly file based on the set of retrieval rules; and hardening the code in the code set to be processed to obtain a hardened target application.

[0007] Optionally, the above set of retrieval rules includes at least one of the following: identifying at least a portion of the SDK packages from a set of SDK packages of the target application, and identifying the code in the at least a portion of the SDK packages as a first subset of code to be hardened; identifying class code with inheritance relationships as a second subset of code to be hardened, wherein the relationship between parent and child classes with the same attributes and methods is identified as an inheritance relationship; identifying method code in class code with calling relationships as a third subset of code to be hardened, wherein the first and second types of code have a calling relationship when a method is called from the first type of code to the second type of code using a method signature; and identifying method code in class code with overloading relationships as a fourth subset of code to be hardened, wherein the third type of code and the fourth type of code have an overloading relationship when the third type of code inherits from the fourth type of code and modifies a specified method in the fourth type of code.

[0008] Optionally, the above method further includes merging the first subset of code to be processed, the second subset of code to be processed, the third subset of code to be processed, and the fourth subset of code to be processed to obtain a set of code to be processed.

[0009] Optionally, the above-mentioned hardening process for the code in the code set to be processed to obtain the hardened target application includes: compiling a set of bytecode assembly files corresponding to the code set to be processed into M bytecode files, where M is a positive integer greater than or equal to 1, and the bytecode assembly files corresponding to the target application include a set of bytecode assembly files; hardening the M bytecode files to obtain the hardened M bytecode files; and obtaining the hardened target application based on the hardened M bytecode files.

[0010] Optionally, the above-mentioned method of obtaining the hardened target application based on the hardened M bytecode files includes: removing class code with the same attributes as those in the M bytecode files from the N bytecode files to obtain the processed N bytecode files, wherein the N bytecode files are obtained by compiling the bytecode assembly file corresponding to the target application, and N is a positive integer greater than or equal to M; and obtaining the hardened target application based on the processed N bytecode files and the hardened M bytecode files.

[0011] Optionally, before obtaining the code relationship diagram of the target application, the above method further includes: obtaining the APK application package of the target application, wherein the APK application package includes a set of bytecode files; and decompiling the set of bytecode files to obtain the bytecode assembly file corresponding to the target application.

[0012] Optionally, after decompiling a set of bytecode files to obtain the bytecode assembly file corresponding to the target application, the above method further includes: parsing the data structure of each class in the bytecode assembly file corresponding to the target application to obtain the index relationship between each class; and generating a code relationship diagram based on the index relationship between each class.

[0013] According to another aspect of the embodiments of this application, an application hardening apparatus is also provided, comprising: a first acquisition unit, configured to acquire a code relationship diagram of a target application, wherein the code relationship diagram includes reference relationships between classes in a bytecode assembly file corresponding to the target application; a first processing unit, configured to generate a code retrieval strategy based on the class code of each class, wherein the code retrieval strategy includes a set of retrieval rules generated using the reference relationships between classes; a second processing unit, configured to determine a code set to be processed from the bytecode assembly file based on the set of retrieval rules; and a hardening unit, configured to harden the code in the code set to be processed to obtain a hardened target application.

[0014] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein a computer program is stored in the computer program for executing the above-described application hardening method when the electronic device is run.

[0015] According to another aspect of the embodiments of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the hardening method of the application program through the computer program.

[0016] The embodiments provided in this application generate a set of retrieval rules based on the index relationship between classes in the bytecode assembly file corresponding to the application and in combination with the hardening requirements. A small amount of code that needs to be hardened is determined from the bytecode assembly file according to the retrieval rules, thereby hardening the critical code of the application. This solves the problem of low hardening efficiency of program code in related technologies, achieves the technical effect of improving the hardening efficiency of the application, and enhances the security of the program code. Attached Figure Description

[0017] The accompanying drawings, which are provided to further illustrate this application and form part of this application, illustrate exemplary embodiments of this application and are used to explain this application, but do not constitute an undue limitation of this application.

[0018] Figure 1 This is a schematic diagram illustrating an application scenario of an optional application hardening method according to an embodiment of this application;

[0019] Figure 2This is a flowchart of an optional application hardening method according to an embodiment of this application;

[0020] Figure 3 This is a schematic diagram of an optional code relationship diagram according to an embodiment of this application;

[0021] Figure 4 This is a specific example of an optional method for determining the code to be hardened according to retrieval rules, based on an embodiment of this application.

[0022] Figure 5 This is an overall flowchart of an optional application hardening method according to an embodiment of this application;

[0023] Figure 6 This is a schematic diagram of the structure of an optional application reinforcement device according to an embodiment of this application;

[0024] Figure 7 This is a schematic diagram of the structure of an optional electronic device according to an embodiment of this application. Detailed Implementation

[0025] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0026] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0027] The technical solutions in this application will comply with legal regulations during implementation. When performing operations according to the technical solutions in the embodiments, the data used will not involve user privacy, ensuring that the operation process is compliant and legal while guaranteeing data security.

[0028] In addition, when the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data must comply with the relevant regulations and standards of the relevant countries or regions.

[0029] According to one aspect of the embodiments of this application, an application hardening method is provided. As an optional implementation, the above-described application hardening method can be applied to, but is not limited to, applications such as... Figure 1 The application scenarios shown are as follows. In, for example... Figure 1 In the application scenario shown, the target terminal 102 can communicate with the server 106 via network 104, but is not limited to this. The server 106 can perform operations on the database 108, such as write or read data operations. The target terminal 102 may include, but is not limited to, a human-computer interaction screen, a processor, and a memory. The human-computer interaction screen may be used to display the startup screen and process screen of the target application on the target terminal 102. The processor may be used to respond to the human-computer interaction operations, execute corresponding operations, or generate corresponding instructions and send the generated instructions to the server 106. The memory is used to store relevant processing data, such as code relationship diagrams, code retrieval strategies, and the hardened target application.

[0030] Optionally, in this embodiment, the target terminal can be a terminal configured with a target client, which may include, but is not limited to, at least one of the following: mobile phone (such as Android phone, iOS phone, etc.), laptop computer, tablet computer, PDA, MID (Mobile Internet Devices), PAD, desktop computer, smart TV, etc. The target client may be a video client, instant messaging client, browser client, educational client, etc. The network may include, but is not limited to, wired network and wireless network, wherein the wired network includes: local area network, metropolitan area network and wide area network, and the wireless network includes: Bluetooth, WIFI and other networks that enable wireless communication. The server may be a single server, a server cluster composed of multiple servers, or a cloud server.

[0031] To address the issue of low application hardening efficiency mentioned above, this application proposes an application hardening method. Figure 2 This is a flowchart of an application hardening method according to an embodiment of this application, which includes the following steps S202 to S208.

[0032] It should be noted that the application hardening methods shown in steps S202 to S208 can be, but are not limited to, performed by an electronic device, wherein the electronic device can be, but is not limited to, as shown in steps S202 to S208. Figure 1The target terminal or server shown.

[0033] Step S202: Obtain the code relationship diagram of the target application, wherein the code relationship diagram includes the reference relationships between various classes in the bytecode assembly file corresponding to the target application;

[0034] Step S204: Generate a code retrieval strategy based on the class code of each class, wherein the code retrieval strategy includes a set of retrieval rules generated using the reference relationships between each class;

[0035] Step S206: Based on a set of retrieval rules, determine the code set to be processed from the bytecode assembly file;

[0036] Step S208: Harden the code in the code set to be processed to obtain the hardened target application.

[0037] The technical solutions in this application embodiment can be applied, but are not limited to, code hardening of applications developed using the Android system. Developers use the Java language to develop different applications (referred to as APP), and the compilation tool compiles the Java source files into Dalvik executable files (.dex).

[0038] Code hardening refers to encrypting, obfuscating, and modifying critical parts of source code through a series of technical means and methods to enhance its ability to resist reverse engineering and malicious exploitation, thereby protecting core business logic, improving code security, and meeting compliance requirements.

[0039] By decompiling the executable file (.dex) mentioned above, the bytecode assembly file (.smali file) corresponding to the target application is obtained. The smali file is composed of multiple different classes, each with its own class code.

[0040] Each class includes different attributes, methods, and reference relationships between the class and other classes. In this embodiment, the reference relationships include, but are not limited to, calling, inheritance, and overloading. A method is the smallest execution unit in a Java program, and the purpose of a method is to improve code reusability and maintainability.

[0041] In practical applications, if a specific class belongs to another larger class, then when creating this specific class, it can inherit from the larger class. In inheritance, the inherited class is called the parent class, and the inheritor is called the child class. After the child class inherits from the parent class, it contains all the attributes and methods of the parent class. This kind of reference relationship is called inheritance.

[0042] If a concrete class belongs to another larger class, then when creating this concrete class, it can inherit from the larger class. In inheritance, the class being inherited from is called the parent class, and the class inheriting from it is called the child class. After inheriting from the parent class, the child class includes all the attributes and methods of the parent class. This kind of reference relationship is called inheritance. Other reference relationships between classes will be described below with specific examples.

[0043] Based on the class code of each of the above classes and in combination with the reinforcement requirements, a set of retrieval rules are generated. The retrieval rules are used to identify a small amount of code that needs to be reinforced from the class code of each class according to specified requirements.

[0044] The relationships between classes can be, but are not limited to, directly obtained from the code relationship diagram. The code relationship diagram can, but is not limited to, [examples of such relationships]. Figure 3 As shown below, the specific process of generating the code relationship diagram is described in conjunction with a specific embodiment.

[0045] Before generating the code relationship diagram, the following process may be performed, but is not limited to:

[0046] Obtain the APK application package of the target application, wherein the APK application package includes a set of bytecode files;

[0047] A set of bytecode files is decompiled to obtain the bytecode assembly file corresponding to the target application.

[0048] The APK application package contains a compressed package of multiple .dex files (which can also be understood as bytecode files). The above multiple .dex files are decompiled using tools to obtain the bytecode assembly file (.smali file) corresponding to the target application. Then, based on the bytecode assembly file corresponding to the target application, the above code relationship diagram is generated.

[0049] As an optional implementation, the specific process of generating the above code relationship diagram is as follows:

[0050] Analyze the data structures of each class in the bytecode assembly file corresponding to the target application to obtain the index relationships between the classes;

[0051] A code relationship diagram is generated based on the index relationships between various classes.

[0052] By parsing the class structures and instructions such as constants and method calls in the bytecode assembly file corresponding to the target application, class indexes and dependencies are established and mapped as follows: Figure 3 The code relationship diagram shown.

[0053] It should be noted that the code relationship diagram includes, but is not limited to, the following information:

[0054] (1) A dictionary table of signature characters to class, field, and method structures;

[0055] (2) The Class structure contains a list of declared member structures, where the members are Field and method;

[0056] (3) The Class structure contains a list of all inherited and implemented negative Class structures;

[0057] (4) The Class structure contains a list of all references to the Type structure, where Type is both PrimitiveType and Class;

[0058] (5) The Class structure contains a list of all referenced String constants;

[0059] (6) The Class structure contains a list of all referenced methods;

[0060] (7) The Method structure contains a list of all other methods that are called;

[0061] (8) The Method structure contains a list of all Methods that are called by other Methods.

[0062] By using the open-source tool apktool for decompilation and parsing the decompiled smali file according to the Dalvik bytecode protocol, the reference relationships between various class structures are obtained, and indexes and dependencies are established, ultimately mapping them into a code relationship graph.

[0063] The code relationship diagram described above is the basis for implementing the technical solution of this application. The relationship between the classes can be directly determined from the code relationship diagram. For example, a subclass inherits from a parent class, and method 1 (method1) in one class calls method 2 (method2) in the method list of another class, etc.

[0064] Combining the code relationship diagram above and a pre-defined set of retrieval rules, the code set to be processed is determined from the bytecode assembly file. The set of retrieval rules may, but is not limited to, extracting a small amount of key code from the target application's bytecode assembly file for hardening based on the hardening requirements, thereby protecting the key code and avoiding the inefficiency caused by indiscriminate hardening of all code.

[0065] As an optional implementation, the above set of retrieval rules includes at least one of the following:

[0066] Identify at least some SDK packages from a set of SDK packages of the target application, and determine the code in at least some SDK packages as the first subset of code to be hardened;

[0067] Class code with inheritance relationships is identified as the second subset of code to be hardened, where the relationship between parent and child classes with the same attributes and methods is identified as an inheritance relationship.

[0068] Method code in class code with calling relationships is identified as the third subset of code to be hardened, wherein the first and second types of code have a calling relationship when a method is called from the first type of code to the second type of code through a method signature.

[0069] Method code in classes with overloading relationships is identified as the fourth subset of code to be hardened. Among them, the third type of code inherits from the fourth type of code and modifies a specified method in the fourth type of code, thus the third type of code and the fourth type of code have an overloading relationship.

[0070] Among them, the ways to modify the specified method in the fourth type of code include, but are not limited to, modifying the number, order and type of parameters contained in the specified method.

[0071] In related technologies, the simplest and most accurate way to describe hardening requirements is to enumerate the signatures of the basic elements (Class, Field, and Method) to be hardened one by one. Therefore, in this embodiment, the retrieval rules for enumerating signatures are still used, and regular expression expansions are added to the signature characters. This rule can be referred to as R1. Example: "R1":["Lcom / demo1 / ClassA;.*","Lcom / demo2 / ClassB;.*"], indicating that the code in ClassA and ClassB will be hardened.

[0072] However, when the application's codebase grows to a certain size, the above enumeration method becomes difficult to implement and maintain. Therefore, in this embodiment, the reinforcement requirements are further categorized, and the reinforcement scope is determined based on the categorization results.

[0073] Determining the scope of hardening primarily relies on selecting a small subset of code from the target application's code files according to specific retrieval rules. These retrieval rules include, but are not limited to, the following:

[0074] (1) All code in the specified SDK package or Class needs to be hardened;

[0075] It should be noted that an application's corresponding APK compressed package includes multiple SDK packages (Software Development Kits). An SDK package is a collection of development tools used by software engineers to create application software for specific software packages, software frameworks, hardware platforms, operating systems, etc.

[0076] Since the class signature must be prefixed with the package name of the SDK package, R1 based on the signature character regular expression can actually be applied here.

[0077] For example, “R1”:[“Lcom / demo1 / .*”,“Lcom / demo2 / .*”] means that the code in both the demo1 and demo2 packages will be hardened.

[0078] (2) All Class code that inherits from or implements the specified Class needs to be hardened;

[0079] Combination Figure 3 The code relationship diagram shown allows for reverse indexing of the parent Class list corresponding to the Class structure, thus easily enabling retrieval. Therefore, the Class signature list can be directly listed in the retrieval rule, which is denoted as R2.

[0080] like Figure 3 As shown, ClassB is a subclass of ClassA. ClassB inherits from its parent class ClassA and includes all the attributes and methods of ClassA. There is an inheritance relationship between ClassA and ClassB.

[0081] For example, "R2":["Landroid / app / Activity;","Landroid / app / Service;"] means that all code that inherits from the Activity class and all code that inherits from the Service class will be hardened.

[0082] (3) All Method code that overloads the specified Method needs to be hardened;

[0083] Similar to the retrieval rule R2 for class code with inheritance relationship mentioned above, simply replace the class signature with the method signature. This retrieval rule is denoted as R3.

[0084] For example, the search rule "R3":["Landroid / app / Activity;->onResume()V","Landroid / app / Service;->onDestroy()V"] means that all overridden methods of Activity onResume and all overridden methods of Service onDestroy will be hardened.

[0085] It should be noted that method overloading refers to calling different methods with the same method name based on different parameters provided. The number, order, and type of parameters can all constitute overloading.

[0086] For example, such as Figure 4 As shown, suppose an application's program code includes class code corresponding to three classes: ClassA, ClassB, and ClassC. If method2 in ClassA is based on method1 in ClassB and modifies method1 to obtain the modified method1, then if ClassA contains the method code corresponding to the modified method1, then it can be said that method2 in ClassA overloads method1 in ClassB.

[0087] At this point, in addition to identifying the code in the modified method1 contained in ClassA that has overloaded method1 as the code to be hardened, it is also necessary to identify the code in the modified method1 contained in ClassC that also has overloaded method1, as well as the code in method1 in ClassB as the code to be hardened.

[0088] In other words, according to the above retrieval rule 3, all method code that overrides method1 in all classes is method code that needs to be hardened.

[0089] (4) All Method code that calls the specified Method needs to be hardened.

[0090] Combination Figure 3 The list of Methods that call themselves corresponding to the Method structure in the code relationship diagram shown can be easily retrieved. The list of Method signatures can be listed in the rule, and the regular expression of the signature can be added to further adapt to the polymorphism of the Method. This retrieval rule is denoted as R4.

[0091] For example, "R4":["L.*;->encrypt1\(Ljava / lang / String;\)V","L.*;->encrypt2\(Ljava / lang / String;\)V"] means that all code that calls the method encrypt1 and all code that calls the method encrypt2 will be hardened.

[0092] For example, such as Figure 4 As shown, assuming an application's program code includes class code corresponding to three classes: ClassA, ClassB, and ClassC, and method2 in ClassA calls method1 in ClassB, then the code in method1 in ClassA, the code in method2 in ClassA, and the code in method1 in ClassB are the retrieved code that needs to be hardened.

[0093] In addition, if method3 in ClassC also calls method1 in ClassB, then the code in method1 in ClassC, the code in method3 in ClassC, and the code in method1 in ClassB are also the retrieved code that needs to be hardened.

[0094] Based on the four retrieval rules above, matching code for hardening can almost meet all scope-based or special-case hardening needs. Adding corresponding blacklist rules with similar definitions (referred to as B1, B2, B3, and B4) can further filter out code that doesn't need hardening, thus achieving the goal of "determining the minimum set of code that needs hardening."

[0095] The above methods can accurately locate the code that needs to be hardened, improving the accuracy of the critical code to be hardened and increasing the efficiency of program code hardening.

[0096] As an optional implementation, after retrieving some of the code to be hardened according to the above set of retrieval rules, the method also includes:

[0097] The first, second, third, and fourth subsets of code to be processed are merged to obtain the set of code to be processed.

[0098] After determining each subset of code to be processed according to the above set of retrieval rules, the subsets of code to be processed are merged, and the merged code set is determined as the code set to be processed.

[0099] Obviously, in this embodiment of the application, the above set of retrieval rules is only an example and is not intended to limit the scope of the application.

[0100] For example, some of the rules in R1 to R4 above can be combined into another set of retrieval rules. The code to be reinforced can be determined using the other set of retrieval rules, and the retrieved code can be merged to obtain the final set of code to be reinforced.

[0101] As an optional example, the code in the above-mentioned code set to be processed is hardened to obtain the hardened target application, including:

[0102] Compile a set of bytecode assembly files corresponding to the code set to be processed into M bytecode files, where M is a positive integer greater than or equal to 1, and the bytecode assembly files corresponding to the target application include a set of bytecode assembly files;

[0103] Harden M bytecode files to obtain hardened M bytecode files;

[0104] Based on the hardened M bytecode files, the hardened target application is obtained.

[0105] The code set to be processed identified using a set of search rules corresponds to a set of bytecode assembly files (.smali files). The apktool tool described in the above embodiment can also recompile the list of smali files into .dex files. Therefore, it is only necessary to map the merged code set to be processed into a list of smali files, move these files to a centralized directory, and then use apktool to perform compilation to generate a new dex file.

[0106] The code set consists of Class, Field, and Method. The Field and Method are replaced with the Class in which they are declared. Then, they are merged with the existing Classes in the code set and deduplicated. Finally, the package name paths of the Classes are converted into smali file paths, which can be mapped into a list of smali files.

[0107] Move these smali files to a new consolidated directory so that the code is removed from the original dex file and a new .dex file (bytecode file) is generated.

[0108] Because dex has a maximum limit of 64K constant symbol references, it is necessary to calculate the total number of duplicate references to all classes (including String, Type, and Method) in the new directory. Once it exceeds 64K, a new directory needs to be created to store the smali files of the classes. Each directory will compile a new dex.

[0109] It should be noted that in this embodiment of the application, the object of hardening is the newly compiled .dex file (bytecode file) mentioned above, while the original dex file does not need to be unpacked and decrypted when running the application, which reduces the operation process and improves the running efficiency of the hardened target application.

[0110] Based on the above-mentioned M hardened bytecode files, the hardened target application is obtained, including:

[0111] Remove class code with the same attributes from N bytecode files and M bytecode files to obtain N processed bytecode files. The N bytecode files are obtained by compiling the bytecode assembly file corresponding to the target application, and N is a positive integer greater than or equal to M.

[0112] Based on the processed N bytecode files and the hardened M bytecode files, the hardened target application is obtained.

[0113] The N bytecode files obtained after compiling the bytecode assembly file corresponding to the target application contain complete program code. However, since a small amount of critical code has been removed through the above set of search rules and this critical code has been hardened, when using the hardened M bytecode files and N bytecode files to obtain the hardened application, it is necessary to remove the code that participated in the hardening process from the original N bytecode files.

[0114] Specifically, the class code with the same attributes as the M bytecode files to be hardened is found from the N bytecode files, and the found class code is removed from the N bytecode files. Then, based on the processed N bytecode files and the hardened M bytecode files, the hardened target application is obtained.

[0115] By using the above method, we can effectively prevent class code from appearing repeatedly in N bytecode files in the M bytecode files that are involved in the hardening process.

[0116] As an optional implementation, the above method, based on the processed N bytecode files and the hardened M bytecode files, yields the hardened target application, including:

[0117] After encrypting M bytecode files, they are dumped to the data area. The M hardened bytecode files and the N processed bytecode files are then merged. The code in the merged bytecode file is identified as the code of the hardened target application.

[0118] Practical results show that when an APK of 100M+ size is hardened using the technical solution of this application, while meeting all core code protection and security compliance requirements, only a dex file of less than 8M size needs to be hardened, and the average increase in running time is less than 150 milliseconds.

[0119] To more clearly understand the application hardening methods described above, the following will combine... Figure 5 The overall flowchart shown further describes it.

[0120] S502 decompiles the bytecode files in the APK package to obtain the bytecode assembly file corresponding to the target application;

[0121] Among them, bytecode files can be, but are not limited to, .dex files, and bytecode assembly files can be, but are not limited to, .smai files.

[0122] S504, use the compilation tool to compile the above bytecode assembly file into the corresponding bytecode file;

[0123] S506, by parsing the class structure in the decompiled bytecode assembly file in step S502, a code relationship diagram is generated;

[0124] This involves parsing the class structure and bytecode to extract constants and method calls from the file, establishing indexes and dependencies between classes, and mapping them as follows: Figure 3 The code relationship diagram shown.

[0125] S508, based on reinforcement requirements, establishes a set of retrieval rules;

[0126] One set of retrieval rules can, but is not limited to, determining the coverage of the code to be reinforced based on the reinforcement requirements. For example, all code in a specified SDK package or Class needs to be reinforced, or all class code that inherits from or implements a specified class needs to be reinforced. For details, please refer to the description in the above embodiments, which will not be repeated here.

[0127] It should be noted that, in addition to the search rules mentioned above, this application also proposes a set of blacklist rules B1, B2, B3, and B4 corresponding to the above set of rules. These blacklist rules are used to define code that does not need to be hardened.

[0128] After using the above set of retrieval rules to filter out the code that needs to be reinforced, a set of blacklist rules is then used to remove the code that does not need to be reinforced from the initially filtered code, thus obtaining the "minimum" number of codes to be reinforced. This improves the accuracy of locating the code that needs to be reinforced and increases the reinforcement efficiency.

[0129] S510, using the above retrieval rules, obtain the code set that needs to be reinforced;

[0130] The code set that needs to be hardened corresponds to the .smai file, where, Figure 5 The code shown in smai_classes 1 to smai_classes 3 includes the code in smai_classes 4 and smai_classes 5.

[0131] S512 compiles the code set to be hardened, resulting in new bytecode files .dex4 and .dex5.

[0132] The code in the aforementioned bytecode files .dex1 to .dex3 includes all the code in the new bytecode files .dex4 and .dex5.

[0133] S514 encrypts the new bytecode files .dex4 and .dex5 to obtain encrypted data;

[0134] S516, obtain the encrypted bytecode file;

[0135] S518, based on the encrypted bytecode file and the original bytecode file, obtains the encrypted application.

[0136] As can be seen from the description in the above embodiments, since the code to be hardened determined according to the above retrieval rules is a part of the code in the original bytecode file, after hardening the extracted part of the code, it is necessary to first remove the code in the original bytecode file that is duplicated with the part of the code participating in the hardening process, so as to obtain the processed bytecode file.

[0137] The processed bytecode file and the encrypted bytecode file are then merged to obtain the code set in the hardened application.

[0138] The embodiments provided in this application can achieve the effect of encrypting the critical code of the application, avoiding the shortcomings of low hardening efficiency caused by indiscriminate hardening of all code in related technologies; at the same time, it does not require overall shutdown of virtual machine optimization or inefficient instruction translation.

[0139] In terms of product experience, it can enhance application security while maximizing application performance and stability.

[0140] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0141] According to another aspect of the embodiments of this application, as follows is also provided Figure 6 An application hardening device is shown, the device comprising:

[0142] The first acquisition unit 602 is used to acquire the code relationship diagram of the target application, wherein the code relationship diagram includes the reference relationship between various classes in the bytecode assembly file corresponding to the target application;

[0143] The first processing unit 604 is used to generate a code retrieval strategy based on the class code of each class, wherein the code retrieval strategy includes a set of retrieval rules generated using the reference relationships between each class;

[0144] The second processing unit 606 is used to determine the code set to be processed from the bytecode assembly file based on a set of search rules;

[0145] The hardening unit 608 is used to harden the code in the code set to be processed, so as to obtain the hardened target application.

[0146] Optionally, the first processing unit 604 includes:

[0147] The first processing module is used to identify at least a portion of the SDK packages from a set of SDK packages of the target application, and to identify the code in the at least a portion of the SDK packages as the first subset of code to be hardened.

[0148] The second processing module is used to identify class code with inheritance relationships as the second subset of code to be hardened, wherein the relationship between parent and child classes with the same attributes and methods is identified as an inheritance relationship;

[0149] The third processing module is used to identify the method code in the class code with a calling relationship as the third subset of code to be hardened, wherein the first type of code and the second type of code have a calling relationship when a method code is called from the first type of code to the second type of code through a method signature;

[0150] The fourth processing module is used to identify the method code in class code with overloading relationship as the fourth subset of code to be hardened. In the case where the third type of code inherits from the fourth type of code and modifies the specified method in the fourth type of code, the third type of code and the fourth type of code have an overloading relationship.

[0151] Optionally, the above-mentioned device further includes:

[0152] The merging unit is used to merge the first, second, third, and fourth subsets of code to be processed to obtain the set of code to be processed.

[0153] Optionally, the aforementioned reinforcement unit 608 includes:

[0154] The compilation module is used to compile a set of bytecode assembly files corresponding to the code set to be processed into M bytecode files, where M is a positive integer greater than or equal to 1, and the bytecode assembly files corresponding to the target application include a set of bytecode assembly files;

[0155] The hardening module is used to harden M bytecode files to obtain hardened M bytecode files;

[0156] The fifth processing module is used to obtain the hardened target application based on the hardened M bytecode files.

[0157] Optionally, the fifth processing module mentioned above includes:

[0158] The first processing submodule is used to remove class code with the same attributes from N bytecode files and M bytecode files, and obtain N processed bytecode files. The N bytecode files are obtained by compiling the bytecode assembly file corresponding to the target application, and N is a positive integer greater than or equal to M.

[0159] The second processing submodule is used to obtain the hardened target application based on the processed N bytecode files and the hardened M bytecode files.

[0160] Optionally, the above method further includes:

[0161] The second acquisition unit is used to acquire the APK application package of the target application, wherein the APK application package includes a set of bytecode files;

[0162] The third processing unit is used to decompile a set of bytecode files to obtain the bytecode assembly file corresponding to the target application.

[0163] Optionally, the third processing unit mentioned above includes:

[0164] The parsing module is used to parse the data structures of each class in the bytecode assembly file corresponding to the target application and obtain the index relationship between each class.

[0165] The sixth processing module is used to generate a code relationship diagram based on the index relationships between various classes.

[0166] By applying the aforementioned device to generate a set of retrieval rules based on the index relationships between classes in the bytecode assembly file corresponding to the application and in conjunction with the hardening requirements, a small amount of code that needs to be hardened is determined from the bytecode assembly file according to the retrieval rules, thereby hardening the critical code of the application. This solves the problem of low program code hardening efficiency in related technologies, achieves the technical effect of improving the hardening efficiency of applications, and enhances the security of program code.

[0167] It should be noted that the embodiments of the application hardening device described here can refer to the embodiments of the application hardening method described above, and will not be repeated here.

[0168] According to another aspect of the embodiments of this application, an electronic device for implementing the above-described application hardening method is also provided, the electronic device being... Figure 1 The target terminal or server is shown. This embodiment uses the electronic device as an example to illustrate the concept. Figure 7 As shown, the electronic device includes a memory 702 and a processor 704. The memory 702 stores a computer program, and the processor 704 is configured to execute the steps in any of the above method embodiments via the computer program.

[0169] Optionally, in this embodiment, the aforementioned electronic device may be located in at least one of a plurality of network devices in a computer network.

[0170] Optionally, in this embodiment, the processor can be configured to perform the following steps via a computer program:

[0171] S1, Obtain the code relationship diagram of the target application, wherein the code relationship diagram includes the reference relationships between various classes in the bytecode assembly file corresponding to the target application;

[0172] S2, Based on the class code of each class, generate a code retrieval strategy, wherein the code retrieval strategy includes a set of retrieval rules generated using the reference relationships between each class;

[0173] S3, based on a set of search rules, determines the code set to be processed from the bytecode assembly file;

[0174] S4, strengthens the code in the code set to be processed, and obtains the strengthened target application.

[0175] Alternatively, as those skilled in the art will understand, Figure 7 The structure shown is for illustrative purposes only. Figure 7 This does not limit the structure of the aforementioned electronic devices or electronic equipment. For example, electronic devices or electronic equipment may also include components that are more... Figure 7 The more or fewer components shown (such as network interfaces, etc.), or having the same Figure 7 The different configurations shown.

[0176] The memory 702 can be used to store software programs and modules, such as the program instructions / modules corresponding to the application hardening method and apparatus in this embodiment. The processor 704 executes various functional applications and data processing by running the software programs and modules stored in the memory 702, thereby implementing the aforementioned application hardening method. The memory 702 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 702 may further include memory remotely located relative to the processor 704, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. Specifically, the memory 702 may be used, but is not limited to, storing code relationship diagrams, a set of retrieval rules, and bytecode assembly files, etc. As an example, such as... Figure 7 As shown, the memory 702 may include, but is not limited to, the first acquisition unit 602, the first processing unit 604, the second processing unit 606, and the hardening unit 608 in the application hardening device. Furthermore, it may include, but is not limited to, other module units in the application hardening device, which will not be elaborated upon in this example.

[0177] Optionally, the transmission device 706 described above is used to receive or send data via a network. Specific examples of the network described above may include wired networks and wireless networks. In one example, the transmission device 706 includes a Network Interface Controller (NIC), which can be connected to other network devices and a router via a network cable to communicate with the Internet or a local area network. In another example, the transmission device 706 is a radio frequency (RF) module, used for wireless communication with the Internet.

[0178] In addition, the aforementioned electronic device also includes: a display 708 for displaying the screen of the hardened target application after it has been run; and a connection bus 710 for connecting the various module components in the aforementioned electronic device.

[0179] In other embodiments, the target terminal or server can be a node in a distributed system, which can be a blockchain system. This blockchain system is formed by connecting multiple nodes through network communication. The nodes can form a point-to-point network, and any type of computing device, such as a server or target terminal, can become a node in the blockchain system by joining this point-to-point network.

[0180] According to another aspect of this application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the application hardening method provided in various optional implementations of the above-described server verification processing, wherein the computer program is configured to execute the steps in any of the above-described method embodiments at runtime.

[0181] Optionally, in this embodiment, the computer-readable storage medium described above may be configured to store a computer program for performing the following steps:

[0182] S1, Obtain the code relationship diagram of the target application, wherein the code relationship diagram includes the reference relationships between various classes in the bytecode assembly file corresponding to the target application;

[0183] S2, Based on the class code of each class, generate a code retrieval strategy, wherein the code retrieval strategy includes a set of retrieval rules generated using the reference relationships between each class;

[0184] S3, based on a set of search rules, determines the code set to be processed from the bytecode assembly file;

[0185] S4, strengthens the code in the code set to be processed, and obtains the strengthened target application.

[0186] Optionally, in embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0187] Optionally, in this embodiment, those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the target terminal. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0188] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0189] If the integrated units in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in the aforementioned computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause one or more computer devices (which may be personal computers, servers, or network devices, etc.) to execute all or part of the steps of the methods of the various embodiments of this application.

[0190] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0191] In the several embodiments provided in this application, it should be understood that the disclosed client can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or the indirect coupling or communication connection of units or modules may be electrical or other forms.

[0192] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0193] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0194] The above are merely preferred embodiments of this application. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for hardening an application, characterized in that, include: Obtain the code relationship diagram of the target application, wherein the code relationship diagram includes the reference relationships between various classes in the bytecode assembly file corresponding to the target application; Based on the class code of each class, a code retrieval strategy is generated, wherein the code retrieval strategy includes a set of retrieval rules generated using the reference relationships between the classes; Based on the set of retrieval rules, the code set to be processed is determined from the bytecode assembly file; The code in the code set to be processed is hardened to obtain a hardened target application. Specifically, a set of bytecode assembly files corresponding to the code set to be processed is compiled into M bytecode files, where M is a positive integer greater than or equal to 1. The bytecode assembly files corresponding to the target application include the set of bytecode assembly files. The M bytecode files are then hardened to obtain M hardened bytecode files. Based on the M hardened bytecode files, the hardened target application is obtained.

2. The method according to claim 1, characterized in that, The set of retrieval rules includes at least one of the following: At least a subset of SDK packages are identified from a set of SDK packages of the target application, and the code in the at least a subset of SDK packages is identified as the first subset of code to be hardened. Class code with inheritance relationship is identified as the second subset of code to be hardened, wherein the relationship between parent and child classes with the same attributes and methods is identified as the inheritance relationship; Method code in class code with a calling relationship is identified as the third subset of code to be hardened, wherein the first class code and the second class code have the calling relationship when a method code is called from the first class code to the second class code through a method signature; The method code in the class code with overloading relationship is identified as the fourth subset of code to be processed and hardened. In the case where the third type of code inherits from the fourth type of code and modifies the specified method in the fourth type of code, the third type of code and the fourth type of code have the overloading relationship.

3. The method according to claim 2, characterized in that, The method further includes: The first subset of code to be processed, the second subset of code to be processed, the third subset of code to be processed, and the fourth subset of code to be processed are merged to obtain the set of code to be processed.

4. The method according to claim 1, characterized in that, The process of obtaining the hardened target application based on the hardened M bytecode files includes: Remove class code with the same attributes as the M bytecode files from the N bytecode files to obtain the N processed bytecode files, wherein the N bytecode files are obtained by compiling the bytecode assembly file corresponding to the target application, and N is a positive integer greater than or equal to M; Based on the processed N bytecode files and the hardened M bytecode files, the hardened target application is obtained.

5. The method according to any one of claims 1 to 4, characterized in that, Before obtaining the code relationship graph of the target application, the method further includes: Obtain the APK application package of the target application, wherein the APK application package includes a set of bytecode files; The set of bytecode files is decompiled to obtain the bytecode assembly file corresponding to the target application.

6. The method according to claim 5, characterized in that, After decompiling the set of bytecode files to obtain the bytecode assembly file corresponding to the target application, the method further includes: The data structures of each class in the bytecode assembly file corresponding to the target application are analyzed to obtain the index relationship between the classes. The code relationship diagram is generated based on the index relationships between the various classes.

7. A device for hardening an application, characterized in that, include: The first acquisition unit is used to acquire the code relationship diagram of the target application, wherein the code relationship diagram includes the reference relationship between various classes in the bytecode assembly file corresponding to the target application; The first processing unit is configured to generate a code retrieval strategy based on the class code of each class, wherein the code retrieval strategy includes a set of retrieval rules generated using the reference relationships between the classes; The second processing unit is used to determine the code set to be processed from the bytecode assembly file based on the set of retrieval rules. The hardening unit is used to harden the code in the code set to be processed to obtain a hardened target application. Specifically, it compiles a set of bytecode assembly files corresponding to the code set to be processed into M bytecode files, where M is a positive integer greater than or equal to 1. The bytecode assembly files corresponding to the target application include the set of bytecode assembly files. It then hardens the M bytecode files to obtain M hardened bytecode files. Based on the M hardened bytecode files, it obtains the hardened target application.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein the program can be executed by a terminal device or a computer at runtime as described in any one of claims 1 to 6.

9. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to execute the method as described in any one of claims 1 to 6 through the computer program.

Images