Strengthening method and device for gap application

Abstract

The invention belongs to the technical field of information security, and particularly relates to a reinforcing method and device for a swan application. The method comprises the steps of obtaining a to-be-reinforced swan gap application, wherein the swan gap application comprises at least one first byte code file; decompiling the first byte code file into an editable first file, and modifying and reinforcing the first file to generate a second file; and compiling the second file into a second byte code file, and generating the reinforced swan application based on the second byte code file. The invention provides an application reinforcement scheme which is available for a swan-gap system and has better performance.

Description

Technical Field

[0001] The present disclosure belongs to the field of information security technology, and particularly relates to a method and device for strengthening HarmonyOS applications. Background Art

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

[0003] The strengthening of applications usually involves modifying the source code or bytecode of the application to increase "anti-reverse engineering" and "anti-tampering" capabilities, protecting the intellectual property rights and security of the software.

[0004] The current HarmonyOS development environment is not yet fully mature. Although the HarmonyOS official provides a decompilation tool for bytecode files (HarmonyOS calls them ABC files, ArkBytecode), allowing developers to decompile and analyze ABC files. However, there is a lack of a backtranslation tool, so it is impossible to modify ABC files to strengthen HarmonyOS applications.

[0005] Therefore, the existing HarmonyOS system can only strengthen applications by modifying the source code of the applications. However, to modify the source code, developers need to perform additional processing and maintenance on the source code, increasing the workload and complexity; at the same time, developers must have access to the source code, which may lead to ineffective strengthening in the case of using third-party dynamic libraries (HSP) or frameworks; after each update of the source code, developers need to perform the strengthening process again. Summary of the Invention

[0006] An embodiment of the present disclosure proposes a HarmonyOS application strengthening solution based on ABC file decompilation technology to solve the problem that there is no application strengthening solution with good performance and convenient use in the current HarmonyOS system.

[0007] The first aspect of the embodiment of the present disclosure provides a method for strengthening a HarmonyOS application, including:

[0008] Obtain a HarmonyOS application to be strengthened, where the HarmonyOS application includes at least one first bytecode file;

[0009] Decompile the first bytecode file into an editable first file, modify and strengthen the first file to generate a second file;

[0010] Compile the second file into a second bytecode file, and generate the strengthened HarmonyOS 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 includes:

[0012] Parse the first bytecode file to extract compilation information, where the compilation information at least includes a literal table, a class information table, a method information table, and debug information;

[0013] According to a preset disassembly rule, convert the bytecode instruction stream in the first bytecode file into Ark assembly language instructions, where 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;

[0014] Output the Ark assembly language instructions in text format to generate the first file, where the first file has a structure that conforms to a preset standard.

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

[0016] Obtain the class name list in the first file;

[0017] Generate a unique random string for each class in the class name list and replace it in the first file to generate the second file.

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

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

[0020] Generate a random string for each name and replace it in the first file to generate the second file.

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

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

[0023] Generate a random name for each field and replace it in the first file to generate the second file.

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

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

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

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

[0028] In some embodiments of the present disclosure, the modification and strengthening of the first file include:

[0029] Extract constant strings from the first file;

[0030] Encrypt the constant strings using an encryption and decryption algorithm, where the encryption and decryption algorithm can restore the strings through dynamic decryption code.

[0031] In some embodiments of the present disclosure, the modification and strengthening of the first file include:

[0032] Insert code into the first file, where the code is used to check whether there is a debugger during runtime; and / or

[0033] Insert code into the first file, where the code is used to check the application signature or file hash during runtime to prevent repackaging and tampering; and / or

[0034] Insert code into the first file, where the code is used to check the device environment to prevent the HarmonyOS application from being analyzed in a virtual environment, where the check of the 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 compilation of the second file into a second bytecode file includes:

[0036] Obtain the second file and load it into memory;

[0037] Through lexical analysis and semantic analysis, convert the Ark assembly language instructions in text format into an operable structure in memory, parse various entities, and determine the offsets of the entities in the second bytecode file, where the entities include but are not limited to functions, classes, variables, and literals;

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

[0039] The second aspect of the embodiments of the present disclosure provides a strengthening device for a HarmonyOS application, including:

[0040] An acquisition module, configured to acquire a HarmonyOS application to be strengthened, where the HarmonyOS application includes at least one first bytecode file;

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

[0042] A recompilation module, configured to compile the second file into a second bytecode file, and generate the fortified HarmonyOS application based on the second bytecode file.

[0043] In summary, each embodiment of the present disclosure provides an application fortification solution for HarmonyOS that is available, easy to use, and has good performance by fortifying the intermediate code file in text format obtained by decompiling the ABC bytecode (such as obfuscation, encryption, instrumentation, etc.). Fundamentally, it avoids various problems encountered when modifying the ABC file to fortify the HarmonyOS application due to the lack of a backtranslation tool in the HarmonyOS system, and when fortifying by modifying the source code. In particular, the technical solution provided by the present disclosure fortifies the intermediate code generated by decompiling the ABC bytecode, so the fortification does not depend on the source code, greatly reducing the workload and cost of developers, increasing the flexibility and scope of application of the fortification; and by jointly applying fortification technologies such as obfuscation, encryption, and instrumentation, the application becomes more resistant to attacks and anti-cracking, enhancing security; at the same time, since the fortification does not require the source code, third-party dynamic library (HSP) files without the source code can also be effectively fortified, improving the applicability of the fortification solution. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] The features and advantages of the present disclosure will be more clearly understood by referring to the accompanying drawings. The drawings are schematic and should not be construed as imposing any limitation on the present disclosure. In the drawings:

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

[0046] Figure 2 is a flowchart of a method for fortifying a HarmonyOS application according to some embodiments of the present disclosure;

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

[0048] Figure 4 is the specific process of the fortification operation according to some embodiments of the present disclosure;

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

[0050] Figure 6 is a schematic diagram of a HarmonyOS application fortification device according to some embodiments of the present disclosure. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0051] In the following detailed description, numerous specific details of the present disclosure are set forth by way of example in order to provide a thorough understanding of the relevant disclosure. However, it will be apparent to those of ordinary skill in the art that the present disclosure may be practiced without these details. It should be understood that the terms "system", "device", "unit", and / or "module" used in the present disclosure are a means of distinguishing different components, elements, parts, or assemblies at different levels in a sequential arrangement. However, these terms may be replaced by other expressions if other expressions can achieve the same purpose.

[0052] It should be understood that when a device, unit, or module is referred to as being "on", "connected to", or "coupled to" another device, unit, or module, it may be directly on, connected to, or coupled to or communicate with the other device, unit, or module, or there may be intermediate devices, units, or modules, unless the context clearly indicates an exception. For example, the term "and / or" used in the present disclosure includes any and all combinations of one or more of the related listed items.

[0053] The terms used in the present disclosure are only for describing specific embodiments and do not limit the scope of the present disclosure. As shown in the specification and claims of the present disclosure, unless the context clearly indicates an exception, words such as "a", "an", "one", and / or "the" are not specifically singular and may also include the plural. Generally speaking, the terms "comprising" and "including" only indicate the inclusion of the clearly identified features, wholes, steps, operations, elements, and / or components, and such expressions do not constitute an exclusive list, and other features, wholes, steps, operations, elements, and / or components may also be included.

[0054] Referring to the following description and the accompanying drawings, these or other features and characteristics of the present disclosure, the operating methods, the functions of the related elements of the structure, the combination of parts, and the economy of manufacture can be better understood, where the description and the drawings form a part of the specification. However, it is clearly understood that the drawings are only for the purpose of illustration and description and are not intended to limit the scope of protection of the present disclosure. It can be understood that the drawings are not drawn to scale.

[0055] In the present disclosure, a variety of structure diagrams are used to illustrate various deformations according to the embodiments of the present disclosure. It should be understood that the foregoing or following structures are not used to limit the present disclosure. The scope of protection of the present disclosure is subject to the claims.

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

[0057] The hardening of applications usually involves modifying the source code or bytecode of the application to increase "anti-disassembly" and "anti-tampering" capabilities, protecting the intellectual property rights and security of the software.

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

[0059] The HAP file (HarmonyOS Ability Package) is the basic component unit of HarmonyOS applications. Each HAP file is a compressed package that contains code, resource files, configuration files, etc. The application code written by developers will be compiled into ABC files (Ark Bytecode), and this bytecode will run in the Ark virtual machine of HarmonyOS.

[0060] The ABC Ark bytecode file (Ark Bytecode) is the bytecode format in the HarmonyOS system, similar to Java bytecode. It is generated by the Ark compiler compiling ArkTS / TS / JS and is a binary file provided for the Ark runtime to interpret and execute. The main content in the bytecode is Ark bytecode instructions. The hardening technology for ABC files is particularly important.

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

[0062] In the current HarmonyOS development environment, there is a key technical bottleneck: Although Huawei provides an ABC decompilation tool that allows developers to decompile and analyze ABC files, this toolchain is incomplete and lacks the ability to recompile the decompiled code back into an executable ARK file. Therefore, the HarmonyOS system cannot harden applications by modifying the bytecode at this stage.

[0063] However, if we harden applications by modifying the source code, developers need to operate on the basis of the application source code, which usually involves techniques such as code obfuscation, encryption, and instrumentation. The following problems exist:

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

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

[0066] Difficult to update: After each update of the source code, developers need to re - perform the reinforcement process, which may affect the development progress and release cycle of the application.

[0067] To solve the above problems, the present disclosure introduces a HarmonyOS application reinforcement solution based on ABC file decompilation technology. By performing reinforcement processing (such as obfuscation, encryption, instrumentation, etc.) on the intermediate code file in text format obtained by decompiling the ABC bytecode, a HarmonyOS - available application reinforcement solution is provided. Figure 1 It is a framework diagram of the HarmonyOS application reinforcement algorithm based on ABC file decompilation technology shown in the present disclosure. In some embodiments, the flowchart of the reinforcement method for the HarmonyOS application is as Figure 2 shown, and specifically includes the following steps:

[0068] S210, Obtain the HarmonyOS application to be reinforced, where the HarmonyOS application includes at least one first bytecode file.

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

[0070] S220, Decompile the first bytecode file into an editable first file, modify and reinforce the first file, and generate a second file.

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

[0072] In this step:

[0073] Input: HAP file

[0074] Output: Intermediate code file

[0075] Main operations: Parse the ABC bytecode in the HAP file and convert it into an intermediate code in text format.

[0076] Specifically include:

[0077] 1. Parse the ABC file

[0078] Parse the file header:

[0079] Obtain the basic information of the file, such as the file version, file identifier, number of classes, methods, etc.

[0080] Parse the literal array table (literalarray_table):

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

[0082] Parse the class information table (record_table):

[0083] Extract the metadata of the class, including the class name, inheritance relationship, fields, and other information.

[0084] Parse the method information table (function_table):

[0085] Extract the metadata of each method, including the method name, access modifier, parameter types, return value type, etc.

[0086] Extract the method body, instruction stream, and debugging information:

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

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

[0089] Create the syntax and disassembly logic:

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

[0091] Decompile the instruction stream:

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

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

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

[0095] 3. Output the intermediate code in text format

[0096] Output the decompilation result in text form to form editable intermediate code.

[0097] Ensure that the generated assembly code has a clear structure, facilitating users to modify and optimize.

[0098] In some embodiments of the present disclosure, the process of the strengthening operation is as Figure 4 shown. In this step, the developer modifies and strengthens the intermediate code, including processes such as obfuscating, encrypting, and instrumenting the intermediate code to increase the security of the code.

[0099] In this step:

[0100] Input: Intermediate code after decompilation

[0101] Output: Strengthened intermediate code

[0102] Main operations: Perform security enhancement processing on the intermediate code, including code obfuscation, encryption, instrumentation, etc.

[0103] Specifically include:

[0104] 1. Class name obfuscation

[0105] Goal: Replace the class name with a meaningless string to increase the analysis difficulty.

[0106] Implementation steps:

[0107] Obtain the list of class names in the intermediate code after decompilation.

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

[0109] Ensure that the relationships between classes are not damaged, such as inheritance relationships and interface implementations.

[0110] 2. Method name obfuscation

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

[0112] Implementation steps:

[0113] Obtain the name, parameter types, and return value types of each method.

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

[0115] Ensure that the parameter types and return value types of method calls remain consistent.

[0116] 3. Field name obfuscation

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

[0118] Implementation steps:

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

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

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

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

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

[0124] Implementation steps:

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

[0126] Rename structures: 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] Use an encryption algorithm for encryption.

[0133] Restore the string through dynamic decryption code at runtime.

[0134] 6. Dynamic code instrumentation

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

[0136] Implementation steps:

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

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

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

[0140] S230, compile the second file into a second bytecode file, and generate the fortified HarmonyOS application based on the second bytecode file.

[0141] In some embodiments of the present disclosure, the process of back-compilation operation is as Figure 5 shown. In this step, the fortified intermediate code is recompiled into ABC bytecode through back-compilation operation, and a new HAP file is generated.

[0142] In this step:

[0143] Input: Fortified intermediate code

[0144] Output: Reinforced ABC bytecode

[0145] Main operation: Recompile the reinforced intermediate code into ABC bytecode

[0146] Specifically including:

[0147] 1. Load the decompiled ABC file

[0148] Goal: Read and parse the intermediate file in ABC text format to obtain the structured data it contains.

[0149] Implementation steps:

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

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

[0152] 2. File parsing

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

[0154] Implementation steps:

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

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

[0157] Parse the class information table: Parse the relevant information of the class, covering class name, fields, methods, etc.

[0158] Parse the method information table: Extract the method definition and its relevant information, including method name, parameter list, return type, and method body, etc.

[0159] Parse the instruction stream: Extract and organize the instruction sequences of each method to ensure they are arranged in the correct order.

[0160] 3. Layout calculation

[0161] Goal: Determine the actual positions (offsets) of various entities (functions, classes, variables, literals, etc.) in the finally generated ABC binary file.

[0162] Implementation steps:

[0163] Initialize the offset: Determine and set the exact positions and alignment methods of each component in the binary file to ensure the correctness and access efficiency of the file structure.

[0164] Update Sequence Index: Reorder and update the sequence of each entity to ensure their correct layout in the binary file.

[0165] Rebuild Index Section: Rebuild the index section to ensure that the positions of all items such as classes and literals are arranged in the correct order.

[0166] Calculate Debug Information such as Line Numbers: Ensure that it occupies an appropriate position in the file.

[0167] Update the Offsets of All Entities: Ensure that they are arranged in order and avoid conflicts.

[0168] 4. Binary File Generation

[0169] Objective: Generate the final ABC binary file based on the parsed data and the calculated layout.

[0170] Implementation Steps:

[0171] Write File Header: First, write the file header information and record the position of the checksum.

[0172] Write Index Information: Include class index and literal array index to ensure that 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 integrity of the file structure.

[0174] Write External Items and Regular Items: Write all external items and regular items in sequence according to the alignment requirements.

[0175] Write Debug Information: Finally, write the index information related to line numbers to ensure that the source code line numbers can be accurately associated during debugging.

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

[0177] Complete All Writing Operations: Generate the final ABC binary file.

[0178] 5. Generate the Fortified HAP File

[0179] The finally generated HAP file contains the fortified ABC bytecode and can be directly used for the deployment and execution of the application.

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

[0181] An acquisition module 610, configured to acquire a HarmonyOS application to be fortified, where the HarmonyOS application includes at least one first bytecode file;

[0182] A fortification module 620, configured to decompile the first bytecode file into an editable first file, modify and fortify the first file, and generate a second file;

[0183] A recompilation module 630, configured to compile the second file into a second bytecode file, and generate the fortified HarmonyOS application based on the second bytecode file

[0184] In summary, the fortification method and device for HarmonyOS applications provided in the embodiments of the present disclosure provide a fortification solution applicable to the HarmonyOS system by fortifying the intermediate code file in text format obtained by decompiling the ABC bytecode (such as obfuscation, encryption, instrumentation, etc.). Fundamentally, it avoids various problems encountered when modifying the source code to fortify the HarmonyOS application due to the lack of a backtranslation tool in the HarmonyOS system, making it impossible to modify the ABC file to fortify the HarmonyOS application. In particular, the technical solution provided in the present disclosure fortifies the intermediate code generated by decompiling the ABC bytecode. Therefore, the fortification does not depend on the source code, greatly reducing the workload and cost of developers, increasing the flexibility and scope of application of the fortification; and by jointly applying fortification technologies such as obfuscation, encryption, and instrumentation, the application becomes more resistant to attacks and anti-cracking, enhancing security; at the same time, since the fortification does not require the source code, third-party dynamic library (HSP) files without the source code can also be effectively fortified, improving the applicability of the fortification solution.

[0185] Although the subject matter described herein is provided in the general context of the execution of an operating system and application programs on a computer system, those skilled in the art will recognize that other implementations may also 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 specific tasks or implement specific abstract data types. Those skilled in the art can understand that the subject matter described herein can be practiced using other computer system configurations, including handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, etc., and can also be used in a distributed computing environment where tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules can be located in both local and remote memory storage devices.

[0186] Those of ordinary skill in the art can realize that the units and method steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware or a combination of computer software and electronic hardware. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. A professional technician can use different methods for each specific application to implement the described functions, but such implementation should not be considered to exceed the scope of the present disclosure.

[0187] It should be understood that the above specific embodiments of the present disclosure are only used for exemplary illustration or explanation of the principles of the present disclosure, and do not constitute a limitation on the present disclosure. Therefore, any modifications, equivalent replacements, improvements, etc. made without departing from the spirit and scope of the present disclosure should be included within the protection scope of the present disclosure. In addition, the appended claims of the present disclosure are intended to cover all changes and modifications that fall within the scope and boundaries of the appended claims or equivalent forms of such scope and boundaries.

Claims

1. A reinforcement method for HarmonyOS applications, characterized in that, Including: Obtain a HarmonyOS application to be fortified, where the HarmonyOS application includes at least one first bytecode file; Decompile the first bytecode file into an editable first file, modify and fortify the first file to generate a second file; Compile the second file into a second bytecode file, and generate the fortified HarmonyOS application based on the second bytecode file.

2. The method according to claim 1, wherein The step of decompiling the first bytecode file into an editable first file includes: Analyze the first bytecode file and extract compilation information, where the compilation information at least includes a literal table, a class information table, a method information table, and debug information; According to a preset disassembly rule, convert the bytecode instruction stream in the first bytecode file into Ark assembly language instructions, where 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; Output the Ark assembly language instructions in text format to generate the first file, where the first file has a structure that conforms to a preset standard.

3. The method according to claim 2, wherein The step of modifying and fortifying the first file includes: Obtain the class name list in the first file; Generate a unique random string for each class in the class name list and replace it in the first file to generate the second file.

4. The method according to claim 2, characterized in that The step of modifying and fortifying the first file includes: Obtain the name of each method in the first file; Generate a random string for each name and replace it in the first file to generate the second file.

5. The method according to claim 2, wherein The step of modifying and fortifying the first file includes: Obtain the fields and their types in each class in the first file; Generate a random name for each field and replace it in the first file to generate the second file.

6. The method according to claim 2, wherein The step of modifying and fortifying the first file includes: Obfuscate the control flow in the first file, where the obfuscated control flow at least includes introducing invalid conditional statements and loop structures; and / or Rename structures in the first file, where the renamed structures at least include renaming local variables, function calls, and temporary data structures; and / or Insert invalid code blocks in the first file.

7. The method according to claim 2, wherein The step of modifying and fortifying the first file includes: Extract constant strings in the first file; Encrypt the constant strings using an encryption and decryption algorithm, where the encryption and decryption algorithm can restore the strings through dynamic decryption code.

8. The method according to claim 2, wherein The step of modifying and fortifying the first file includes: Insert code in the first file for checking whether there is a debugger at runtime; and / or Insert code in the first file for checking the application signature or file hash at runtime to prevent repackaging and tampering; and / or Insert code in the first file for checking the device environment to prevent the HarmonyOS application from being analyzed in a virtual environment, where the checking of the 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.

9. The method according to claim 2, characterized in that The step of compiling the second file into a second bytecode file includes: Obtain the second file and load it into memory; Through lexical analysis and semantic analysis, convert the Ark assembly language instructions in text format into an operable structure in memory, parse various entities, and determine the offsets of the entities in the second bytecode file, where the entities include but are not limited to functions, classes, variables, and literals; Based on the entities and the offsets, generate the final second bytecode file.

10. A reinforcement device for HarmonyOS applications, characterized in that It includes: An acquisition module for acquiring a Hongmeng application to be fortified, where the Hongmeng application includes at least one first bytecode file; A fortification module for decompiling the first bytecode file into an editable first file, modifying and fortifying the first file, and generating a second file; A recompilation module for compiling the second file into a second bytecode file and generating the fortified Hongmeng application based on the second bytecode file.

Images