A method and apparatus for hardening a hong meng application

Abstract

The present disclosure belongs to the technical field of information security, and particularly relates to a method and device for reinforcing a Hongmeng application. The method comprises the following steps: obtaining a Hongmeng application to be reinforced, wherein the Hongmeng application comprises at least one first bytecode file; decompiling the first bytecode file into an editable first file, modifying and reinforcing the first file to generate a second file; compiling the second file into a second bytecode file, and generating the reinforced Hongmeng application based on the second bytecode file. The present disclosure provides an application reinforcement scheme that is applicable to a Hongmeng system and has better performance.

Description

TECHNICAL FIELD

[0001] The present disclosure belongs to the technical field of information security, and particularly relates to a method and device for reinforcing a Harmony application. BACKGROUND

[0002] In a modern operating system, an application executes bytecode through a virtual machine (such as JVM of Java and Ark virtual machine of Harmony), and reverse engineering of the bytecode becomes a common means for an attacker to obtain the source code of the application.

[0003] Reinforcement of an application is usually achieved by modifying the source code or bytecode of the application to increase "anti-reversibility" and "anti-tamperability", so as to protect the intellectual property and security of the software.

[0004] The current Harmony development environment is not yet fully mature. Although the Harmony official provides a decompilation tool for bytecode files (referred to as ABC files by Harmony), Ark Bytecode, to allow developers to decompile and analyze the ABC files, there is a lack of back-translation tools, and therefore the ABC files cannot be modified to reinforce the Harmony application.

[0005] Therefore, the existing Harmony system can only reinforce the application by modifying the source code of the application. However, to modify the source code, the developer needs to perform additional processing and maintenance on the source code, which increases the workload and complexity; at the same time, the developer must have access to the source code, which may result in ineffective reinforcement in the case of using a third-party dynamic library (HSP) or framework; and after each update of the source code, the developer needs to perform reinforcement processing again. SUMMARY

[0006] Embodiments of the present disclosure provide a Harmony application reinforcement scheme based on ABC file decompilation technology, to solve the problem that the existing Harmony system does not have a performance good and easy-to-use application reinforcement scheme.

[0007] A first aspect of embodiments of the present disclosure provides a method for reinforcing a Harmony application, comprising:

[0008] obtaining a Harmony application to be reinforced, wherein the Harmony application comprises at least one first bytecode file;

[0009] decompiling the first bytecode file into an editable first file, modifying and reinforcing the first file, and generating a second file;

[0010] compiling the second file into a second bytecode file, and generating a reinforced Harmony application based on the second bytecode file.

[0011] In some embodiments of the present disclosure, the decompiling the first bytecode file into an editable first file comprises:

[0012] parsing the first bytecode file to extract compilation information, wherein the compilation information at least includes a literal table, a class information table, a method information table, and debugging information;

[0013] converting bytecode instruction streams in the first bytecode file into Ark Assembly Language instructions according to preset disassembly rules, wherein the compilation information in the disassembly rules is displayed in a preset format, and the preset format can ensure that the compilation information is restored when recompilation is performed;

[0014] outputting the Ark Assembly Language instructions in a text format to generate the first file, wherein the first file has a structure that meets preset standards.

[0015] In some embodiments of the present disclosure, the modifying and hardening of the first file includes:

[0016] obtaining a list of class names in the first file;

[0017] generating a unique random string for each class in the list of class names and replacing the class in the first file to generate the second file.

[0018] In some embodiments of the present disclosure, the modifying and hardening of the first file includes:

[0019] obtaining the name of each method in the first file;

[0020] generating a random string for each of the names and replacing the name in the first file to generate the second file.

[0021] In some embodiments of the present disclosure, the modifying and hardening of the first file includes:

[0022] obtaining the fields and their types in each class in the first file;

[0023] generating a random name for each of the fields and replacing the field in the first file to generate the second file.

[0024] In some embodiments of the present disclosure, the modifying and hardening of the first file includes:

[0025] obfuscating control flow in the first file, wherein the obfuscated control flow at least includes introducing invalid conditional statements and loop structures; and / or

[0026] renaming structures in the first file, wherein the renamed structures at least include renaming local variables, function calls, and temporary data structures; and / or

[0027] inserting invalid code blocks in the first file.

[0028] In some embodiments of the present disclosure, the modifying and hardening the first file comprises:

[0029] extracting constant strings in the first file;

[0030] encrypting the constant strings using encryption and decryption algorithms, wherein the encryption and decryption algorithms can restore the strings through dynamic decryption code.

[0031] In some embodiments of the present disclosure, the modifying and hardening the first file comprises:

[0032] inserting code in the first file, the code being used to check whether there is a debugger at runtime; and / or

[0033] inserting code in the first file, the code being used to check application signature or filehash at runtime to prevent repackaging and tampering; and / or

[0034] inserting code in the first file, the code being used to check device environment to prevent the application from being analyzed in a virtual environment, wherein the checking device environment at least includes detecting whether the application is running in an emulator, whether the system is rooted, and whether the application is hooked.

[0035] In some embodiments of the present disclosure, the compiling the second file into a second bytecode file comprises:

[0036] obtaining the second file and loading it in memory;

[0037] converting the Ark assembly language instructions in text format into operable structures in memory through lexical analysis and semantic analysis, parsing various entities and determining the offsets of the entities in the second bytecode file, wherein the entities include but are not limited to functions, classes, variables, and literals;

[0038] generating the final second bytecode file based on the entities and the offsets.

[0039] A second aspect of the embodiments of the present disclosure provides a hardening device of a Harmony application, comprising:

[0040] an obtaining module, configured to obtain a Harmony application to be hardened, the Harmony application containing at least one first bytecode file;

[0041] a hardening module, configured to decompile the first bytecode file into an editable first file, modify and harden the first file, and generate a second file;

[0042] A recompilation module is configured to compile the second file into a second bytecode file, and generate a hardened version of the HMS application based on the second bytecode file.

[0043] In summary, the embodiments of the present disclosure provide a HMS application hardening solution that is available for HMS system, easy to use, and has good performance, by hardening (e.g., obfuscation, encryption, and instrumentation) the intermediate code file in text format obtained by decompiling the ABC bytecode. The various problems encountered when modifying the source code to harden the HMS application are fundamentally avoided, because the HMS system lacks a retranslation tool, and thus cannot modify the ABC file to harden the HMS application. In particular, the technical solution provided by the present disclosure hardens the intermediate code generated by decompiling the ABC bytecode, and thus the hardening does not depend on the source code, greatly reducing the workload and cost of the developer, and increasing the flexibility and applicability of the hardening. By jointly using obfuscation, encryption, and instrumentation, the application is more resistant to attacks and cracking, and the security is enhanced. At the same time, because the hardening does not require the source code, the third-party dynamic library (HSP) file without the source code can also be effectively hardened, improving the applicability of the hardening solution. BRIEF DESCRIPTION OF DRAWINGS

[0044] The features and advantages of the present disclosure will be more clearly understood through reference to the following drawings, which are presented as illustrative and should not be construed as limiting the present disclosure, in which:

[0045] Figure 1 is a framework diagram of a HMS application hardening algorithm based on the ABC file decompilation technology shown in the present disclosure;

[0046] Figure 2 is a flowchart of a HMS application hardening method according to some embodiments of the present disclosure;

[0047] Figure 3 is a specific flow of a decompilation operation according to some embodiments of the present disclosure;

[0048] Figure 4 is a specific flow of a hardening operation according to some embodiments of the present disclosure;

[0049] Figure 5 is a specific flow of a recompilation operation according to some embodiments of the present disclosure;

[0050] Figure 6 is a schematic diagram of a HMS application hardening device according to some embodiments of the present disclosure. DETAILED DESCRIPTION

[0051] In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the disclosure. However, it will be apparent to one ordinarily skilled in the art that the disclosure can be practiced without these specific details. It should also be understood that the use of the terms "system," "apparatus," "unit," and / or "module" throughout this disclosure is used to represent different levels of abstraction in order to distinguish between different components, elements, parts, or assemblies in a sequential arrangement. However, these terms can be replaced by other expressions if other expressions can achieve the same purpose.

[0052] It should be understood that when an apparatus, unit, or module is referred to as being "on", "connected to", or "coupled to" another apparatus, unit, or module, it can be directly on, connected, or coupled to the other apparatus, unit, or module, or intervening apparatuses, units, or modules can be present, unless the context clearly dictates otherwise. For example, as used in the disclosure, the term "and / or" includes any and all combinations of one or more of the associated listed items.

[0053] The terminology used in the disclosure is only for the purpose of describing particular embodiments and is not intended to limit the scope of the disclosure. As used in the specification and claims of this disclosure, the words "a", "an", "one", and / or "the" are not intended to refer to only a singular entity, but rather can include one or more entities, unless the context clearly indicates otherwise. In general, the term "includes" and / or "including" means including, but not limited to.

[0054] These or other features and characteristics of the disclosure, the method of operation, the function and the combination of parts of the structure and the economy of manufacture can be better understood with reference to the specification and drawings, which form a part of this specification. However, it should be clearly understood that the drawings are only used for the purpose of illustration and description, and are not intended to limit the scope of protection of the disclosure. It can be understood that the drawings are not drawn to scale.

[0055] Various structural diagrams are used in the disclosure to illustrate various modifications according to embodiments of the disclosure. It should be understood that the foregoing or the following structures are not intended to limit the disclosure. The scope of protection of the disclosure is subject to the claims.

[0056] In modern operating systems, applications execute bytecodes through virtual machines (such as Java's JVM and the Ark virtual machine of Hongmeng), and the reverse engineering of bytecodes has become a common means for attackers to obtain application source code.

[0057] Application hardening is usually done by modifying the source code or bytecode of the application to increase "anti-reversing" and "anti-tampering" to protect the intellectual property and security of the software.

[0058] HarmonyOS is an operating system developed by Huawei, which uses a different application package (HAP, HarmonyOS Ability Package) and virtual machine execution mechanism from traditional operating systems.

[0059] HAP file (HarmonyOS Ability Package) is the basic unit of Harmony application, each HAP file is a compressed package containing code, resource files and configuration files, etc. The application code written by the developer will be compiled into ABC file (Ark Bytecode), which will run in the Ark virtual machine of Harmony.

[0060] ABC Ark Bytecode file is the bytecode format in Harmony system, similar to Java bytecode, it is generated by ArkTS / TS / JS compiler and provided to Ark runtime for interpretation and execution. The main content of bytecode is Ark bytecode instruction. The hardening technology for ABC file is particularly important.

[0061] APP file (Application Package) is a format used in Harmony operating system to package and release applications. It can contain one or more HAP (HarmonyOS Ability Package), allowing developers to package different functional modules together.

[0062] In the current Harmony development environment, there is a key technical bottleneck: although Harmony provides ABC decompilation tools that allow developers to decompile and analyze ABC files, this tool chain is not complete and lacks the ability to recompile the decompiled code back to executable ARK files. Therefore, the Harmony system cannot currently harden applications by modifying bytecode.

[0063] However, if you want to harden the application by modifying the source code, you need to operate on the basis of the application source code, which usually involves code obfuscation, encryption, and instrumentation techniques. There are the following problems:

[0064] High development cost: developers need to perform additional processing and maintenance on the source code, increasing workload and complexity.

[0065] Dependence on source code: must have access to the source code, which may result in ineffective hardening in the case of using third-party dynamic libraries (HSP) or frameworks.

[0066] Update difficulty: After each source code update, the developer needs to reprocess the hardening, which may affect the development progress and release cycle of the application.

[0067] To solve the above problems, the present disclosure introduces a Harmony application hardening scheme based on ABC file decompilation technology. By hardening the text format intermediate code file obtained by decompiling the ABC bytecode, such as obfuscation, encryption, and instrumentation, a Harmony system available application hardening scheme is provided. Figure 1 is the framework diagram of the Harmony application hardening algorithm based on the ABC file decompilation technology shown in the present disclosure. In some embodiments, the flowchart of the hardening method of the Harmony application is as shown in Figure 2 , specifically including the following steps:

[0068] S210, obtaining a Harmony application to be hardened, the Harmony application comprising at least one first bytecode file.

[0069] Specifically, the user uploads the HAP or APP file that needs to be hardened. The file contains one or more ABC bytecodes.

[0070] S220, decompiling the first bytecode file into an editable first file, modifying and hardening the first file to generate a second file.

[0071] In some embodiments of the present disclosure, the flow of the decompilation operation is as shown in Figure 3 , this step extracts the ABC bytecode file in the HAP file and converts it into an editable text format intermediate code.

[0072] In this step:

[0073] Input: HAP file

[0074] Output: Intermediate code file

[0075] Main operation: parse the ABC bytecode in the HAP file and convert it into a text format intermediate code.

[0076] Specifically includes:

[0077] 1. Parse the ABC file

[0078] Parse the file header:

[0079] Get the basic information of the file, such as the number of file versions, file identifiers, classes, and methods.

[0080] Parse the literal array table:

[0081] Extract literal values in the constant pool, such as strings, numerical values, etc.

[0082] Parse the record_table:

[0083] Extract metadata of classes, including class names, inheritance relationships, fields, etc.

[0084] Parse the function_table:

[0085] Extract metadata of each method, including method names, access modifiers, parameter types, return value types, etc.

[0086] Extract method bodies, instruction streams, and debugging information:

[0087] Get the instruction stream of each method, the logic of the method body, and metadata related to debugging (such as line number mapping, variable information, etc.).

[0088] 2. Convert to intermediate code in text format

[0089] Create syntax and disassembly logic:

[0090] Design the syntax and instruction set mapping rules of the Ark assembly language to ensure that the bytecode in the ABC file can be converted to a readable text format.

[0091] Disassemble the instruction stream:

[0092] According to the disassembly logic, convert the bytecode instruction stream in the ABC file to Ark assembly language instructions.

[0093] Process the literal table, class information table, and debugging information:

[0094] Display the literal, class information, and debugging information obtained by parsing in the assembly code in a specific format to ensure that these information can be restored during recompilation.

[0095] 3. Output intermediate code in text format

[0096] Output the disassembled results in text format to form editable intermediate code.

[0097] Ensure that the generated assembly code has a clear structure to facilitate user modification and optimization.

[0098] In some embodiments of the present disclosure, the flow of the hardening operation is as shown in Figure 4 This step involves developers making modifications and hardening in the intermediate code, including obfuscation, encryption, and instrumentation of the intermediate code to increase code security.

[0099] In this step:

[0100] Input: De-compiled intermediate code

[0101] Output: Hardened intermediate code

[0102] Main operations: Security enhancements on intermediate code, including code obfuscation, encryption, instrumentation, etc.

[0103] Specifically includes:

[0104] 1. Class name obfuscation

[0105] Objective: Replace class names with meaningless strings to increase analysis difficulty.

[0106] Implementation steps:

[0107] Get the list of class names in the decompiled intermediate code.

[0108] Generate a unique random string for each class and replace it.

[0109] Ensure that the relationship between classes is not destroyed, such as inheritance relationship, interface implementation.

[0110] 2. Method name obfuscation

[0111] Objective: Increase the complexity of reverse analysis through method name obfuscation.

[0112] Implementation steps:

[0113] Get the name, parameter type and return value type of each method.

[0114] Generate a random string for each method and replace it.

[0115] Ensure that the parameter type and return value type of method call remain consistent.

[0116] 3. Field name obfuscation

[0117] Objective: Increase the difficulty of data access through field name obfuscation.

[0118] Implementation steps:

[0119] Get the fields and their types in each class.

[0120] Generate a random name for each field and replace it.

[0121] Update access modifiers and related metadata of fields.

[0122] 4. Rename internal structure and control flow obfuscation

[0123] Objective: Change the internal structure and control flow of the program to increase the difficulty of analysis.

[0124] Implementation steps:

[0125] Control flow obfuscation: Introduce invalid conditional statements, loop structures, etc., to make the code look more complex.

[0126] Rename structure: Rename local variables, function calls, temporary data structures, etc.

[0127] Dead code insertion: Insert invalid code blocks to make it difficult for analysts to understand the actual program logic.

[0128] 5. String encryption

[0129] Objective: Encrypt sensitive strings in the program to prevent leakage.

[0130] Implementation steps:

[0131] Extract all constant strings.

[0132] Encrypt using encryption algorithm.

[0133] Restore the string by decrypting the code at runtime.

[0134] 6. Dynamic code instrumentation

[0135] Objective: Increase the dynamic instrumentation code to enhance protection, such as preventing debugging, analysis, and repackaging.

[0136] Implementation steps:

[0137] Anti-debugging: Insert code to check if there is a debugger.

[0138] Anti-repackaging: Insert code to check HAP signature or file hash at runtime to prevent repackaging and tampering.

[0139] Environment detection: Check device environment, such as whether running in an emulator, system rooted, application hooked, etc., to prevent analysis in a virtual environment.

[0140] S230, compiling the second file into a second bytecode file, generating a hardened HAP file based on the second bytecode file.

[0141] In some embodiments of the present disclosure, the recompilation operation flow is as shown in Figure 5 This step recompiles the hardened intermediate code into ABC bytecode through the recompilation operation and generates a new HAP file.

[0142] In this step:

[0143] Input: Hardened intermediate code

[0144] Output: Hardened ABC bytecode

[0145] Main operation: Recompilation of hardened intermediate code into ABC bytecode

[0146] Specifically includes:

[0147] 1. Load the decompiled ABC file

[0148] Objective: Read and parse the intermediate file in ABC text format to obtain the structured data contained therein.

[0149] Implementation steps:

[0150] Open the intermediate file in ABC text format.

[0151] Load the file content into memory, preparing for subsequent processing and parsing.

[0152] 2. File parsing

[0153] Objective: Convert the text format intermediate code into an operable structure in memory through lexical analysis and semantic analysis.

[0154] Implementation steps:

[0155] Parse the file header information: extract basic information such as version number, identifier and metadata.

[0156] Parse the literal table: identify and extract constants and literal values, including strings, numerical values, etc., and construct the corresponding data structure.

[0157] Parse the class information table: parse the relevant information of the class, including class name, field, method, etc.

[0158] Parse the method information table: extract method definitions and related information, including method name, parameter list, return type and method body.

[0159] Parse the instruction stream: extract and organize the instruction sequence of each method, ensuring that it is arranged in the correct order.

[0160] 3. Layout calculation

[0161] Objective: Determine the actual position (offset) of various entities (functions, classes, variables, literals, etc.) in the final generated ABC binary file.

[0162] Implementation steps:

[0163] Initialize offset: determine and set the precise position and alignment of each component in the binary file to ensure the correctness and access efficiency of the file structure.

[0164] Update order index: Reorder and update the order of each entity to ensure they are in the correct layout in the binary file.

[0165] Rebuild index section: Reconstruct the index section to ensure all class, literal, and other items are in the correct order.

[0166] Calculate line number and other debugging information: Ensure they are in the right place in the file.

[0167] Update the offset of all entities: Ensure they are in order and avoid conflicts.

[0168] 4. Binary file generation

[0169] Objective: Based on the parsed data and calculated layout, generate the final ABC binary file.

[0170] Implementation steps:

[0171] Write file header: First write the file header information and record the location of the checksum.

[0172] Write index information: Including class index and literal array index, ensure the position of each entity in its binary representation is accurately recorded.

[0173] Write index section: Write the built index section to the output stream to ensure the file structure is complete.

[0174] Write external items and regular items: Write all external items and regular items in order according to alignment requirements.

[0175] Write debugging information: Finally write the line number related index information to ensure accurate association with source code line numbers during debugging.

[0176] Checksum processing: Update and rewrite the checksum to ensure file integrity.

[0177] Complete all write operations: Generate the final ABC binary file.

[0178] 5. Generate hardened HAP file

[0179] The final HAP file contains hardened ABC bytecode and can be directly used for application deployment and execution.

[0180] Figure 6 is a schematic diagram of a hardened device of a Hongmeng application according to some embodiments of the present disclosure. As shown in Figure 6 the hardened device of the Hongmeng application 600 includes an acquisition module 610, a hardening module 620, and a recompilation module 630. Among them:

[0181] The acquisition module 610 is configured to acquire a to-be-reinforced Harmony application, wherein the Harmony application comprises at least one first bytecode file.

[0182] The reinforcement module 620 is configured to decompile the first bytecode file into an editable first file, modify and reinforce the first file, and generate a second file.

[0183] The recompilation module 630 is configured to compile the second file into a second bytecode file, and generate the reinforced Harmony application based on the second bytecode file.

[0184] To sum up, the method and device for reinforcing a Harmony application provided by the embodiments of the present disclosure can provide an application reinforcement scheme available for a Harmony system by reinforcing the intermediate code file in a text format obtained by decompiling the ABC bytecode (such as obfuscation, encryption, and instrumentation). The method and device fundamentally avoid various problems encountered when the source code is modified to reinforce the Harmony application because the Harmony system lacks a retranslation tool and thus cannot modify the ABC file to reinforce the Harmony application. In particular, the technical scheme provided by the present disclosure reinforces the intermediate code generated by decompiling the ABC bytecode, and thus the reinforcement is independent of the source code, which greatly reduces the workload and cost of the developer and increases the flexibility and applicability of the reinforcement. Furthermore, the reinforcement techniques such as obfuscation, encryption, and instrumentation are jointly used to make the application more resistant to attacks and cracking and enhance the security. Meanwhile, because the reinforcement does not require the source code, the third-party dynamic library (HSP) file without the source code can also be effectively reinforced, which improves the applicability of the reinforcement scheme.

[0185] Although the subject matter described herein is provided in the general context of computer-executable instructions of a program module being executed by a computer system on a computing device, those skilled in the art will recognize that other implementations can be performed in combination with other types of program modules. Generally, program modules include routines, programs, components, data structures, and other types of structures that perform particular tasks or implement particular abstract data types. Those skilled in the art will appreciate that the subject matter described herein can be practiced with other computer system configurations, including hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the like. The subject matter described herein can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules can be located in both local and remote memory storage devices.

[0186] Those skilled in the art can realize the units and method steps of the examples described in combination with the embodiments disclosed herein can be realized by electronic hardware, or a combination of computer software and electronic hardware. Whether the functions are executed in hardware or software depends on the specific application and design constraints. Professionals can use different methods to implement the described functions for each specific application, but it should not be considered that the implementation goes beyond the scope of the present disclosure.

[0187] It should be understood that the above specific embodiments of the present disclosure are merely used to illustrate or explain the principles of the present disclosure, and do not constitute a limitation on the present disclosure. Therefore, any modification, equivalent replacement, improvement, etc. made without departing from the spirit and scope of the present disclosure shall be included in the protection scope of the present disclosure. In addition, the claims of the present disclosure are intended to cover all variations and modifications falling within the scope and boundary of the appended claims, or the equivalent forms of such scope and boundary.

Claims

1. A method for hardening a HongMeng application, characterized in that, The method comprises: obtaining a to-be-strengthened Harmony application, the Harmony application comprising at least one first bytecode file; decompiling the first bytecode file into a first file in text format, modifying and strengthening the first file to generate a second file; compiling the second file into a second bytecode file, and generating the strengthened Harmony application based on the second bytecode file; wherein the decompiling the first bytecode file into a first file in text format comprises: parsing the first bytecode file to extract compilation information, wherein the compilation information at least comprises a literal table, class information table, method information table, and debugging information; converting bytecode instruction streams in the first bytecode file into Ark assembly language instructions according to preset disassembly rules, wherein the compilation information in the disassembly rules is displayed in a preset format, and the preset format can ensure that the compilation information is restored when recompiled; outputting the Ark assembly language instructions in text format to generate the first file, wherein the first file has a structure conforming to a preset standard; the modifying and strengthening the first file comprises: inserting code in the first file, the code being used to check whether there is a debugger at runtime; and / or inserting code in the first file, the code being used to check application signature or file hash at runtime to prevent repackaging and tampering; and / or inserting code in the first file, the code being used to check device environment to prevent the Harmony application from being analyzed in a virtual environment, wherein the checking device environment at least comprises detecting whether the application is running in an emulator, whether the system is rooted, and whether the application is Hooked; the compiling the second file into a second bytecode file comprises: obtaining the second file and loading it in memory; converting the Ark assembly language instructions in text format into an operable structure in memory through lexical analysis and semantic analysis, parsing various entities and determining offsets of the entities in the second bytecode file, wherein the entities comprise functions, classes, variables, and literals; generating the final second bytecode file based on the entities and the offsets.

2. The method of claim 1, wherein, the modifying and strengthening the first file comprises: obtaining a class name list in the first file; generating a unique random string for each class in the class name list and replacing it in the first file to generate the second file.

3. The method of claim 1, wherein, the modifying and strengthening the first file comprises: obtaining the name of each method in the first file; generating a random string for each name and replacing it in the first file to generate the second file.

4. The method of claim 1, wherein, the modifying and strengthening the first file comprises: obtaining fields and their types in each class in the first file; generating a random name for each field and replacing it in the first file to generate the second file.

5. The method of claim 1, wherein, the modifying and strengthening the first file comprises: obtaining fields and their types in each class in the first file; generating a random name for each field and replacing it in the first file to generate the second file. the modifying and strengthening the first file comprises: obtaining fields and their types in each class in the first file; generating a random name for each field and replacing it in the first file to generate the second file. renaming structures in the first file, the renaming structures including at least renaming local variables, function calls, temporary data structures; and / or inserting invalid code blocks in the first file.

6. The method of claim 1, wherein, The modifying and hardening the first file includes: extracting constant strings in the first file; encrypting the constant strings using encryption and decryption algorithms, wherein the encryption and decryption algorithms can restore the strings through dynamic decryption code.

7. A device for hardening a HongMeng application, characterized in that, includes: An acquisition module is configured to acquire a to-be-hardened Harmony application, the Harmony application including at least one first bytecode file; A hardening module is configured to decompile the first bytecode file into a first file in a text format, modify and harden the first file, and generate a second file; A recompilation module is configured to compile the second file into a second bytecode file and generate a hardened Harmony application based on the second bytecode file; The decompiling the first bytecode file into a first file in a text format includes: parsing the first bytecode file and extracting compilation information, wherein the compilation information includes at least a literal table, a class information table, a method information table, and debugging information; converting bytecode instruction streams in the first bytecode file into Ark assembly language instructions according to a preset disassembly rule, wherein the compilation information in the disassembly rule is displayed in a preset format, and the preset format can ensure that the compilation information is restored during recompilation; outputting the Ark assembly language instructions in a text format to generate the first file, wherein the first file has a structure that meets a preset standard; The modifying and hardening the first file includes: inserting code in the first file, the code being used to check whether a debugger exists at runtime; and / or inserting code in the first file, the code being used to check an application signature or a file hash at runtime to prevent repackaging and tampering; and / or inserting code in the first file, the code being used to check a device environment to prevent the Harmony application from being analyzed in a virtual environment, wherein the checking the device environment includes at least detecting whether the application is running in an emulator, whether a system is rooted, and whether the application is hooked. The compiling the second file into a second bytecode file includes: acquiring the second file and loading the second file in a memory; converting the Ark assembly language instructions in a text format into an operable structure in the memory through lexical analysis and semantic analysis, analyzing various entities, and determining offsets of the entities in the second bytecode file, wherein the entities include functions, classes, variables, and literals; generating a final second bytecode file based on the entities and the offsets.

Images