Reverse analysis method and device

Abstract

The invention discloses a reverse analysis method and device, relates to the technical field of reverse analysis, and mainly aims at providing a reverse analysis technology adaptive to a swan gap application package. The main technical scheme comprises the steps that the swan gap application package to be subjected to reverse analysis is analyzed, and byte code files in the swan gap application package are obtained; performing static grammar analysis on the byte code file, and identifying a suspicious method in an application layer; if the suspicious method is identified, performing dynamic runtime analysis on the byte code file, and tracking a calling logic link related to the suspicious method in an application layer; if it is determined that the calling logic link indicates a target method having a cross-layer calling relationship with the primary layer, determining a cross-layer interaction link between the application layer and the primary layer based on the cross-layer calling relationship between the target method and the primary layer; and based on a suspicious method, calling a logic link and a cross-layer interaction link, and generating a reverse analysis result of the swan application package.

Description

Technical Field

[0001] This application relates to the field of reverse engineering technology, and in particular to a reverse engineering method and apparatus. Background Technology

[0002] With the widespread application of HarmonyOS in consumer electronics, the Internet of Things, and other fields, the security of its Harmony Ability Package (HAP) is directly related to system stability and user rights. Reverse engineering, as a supporting technology for identifying potential malicious behavior and security vulnerabilities, plays an irreplaceable role in application package security assessment. However, the underlying architecture, file format, and operating mechanism of HarmonyOS application packages differ fundamentally from Android application packages, making it difficult to directly adapt existing mature Android reverse engineering techniques to the reverse analysis of HarmonyOS application packages. Currently, the lack of applicable reverse engineering techniques for HarmonyOS application packages has become a major bottleneck restricting its security assessment. Therefore, there is an urgent need for a reverse engineering technique that can accurately parse HarmonyOS application packages to provide reliable technical support for their security assessment. Summary of the Invention

[0003] This application proposes a reverse analysis method and apparatus, the main purpose of which is to provide reverse analysis technology adapted to HarmonyOS application packages, so as to provide reliable technical support for the security assessment of HarmonyOS application packages.

[0004] To achieve the above objectives, this application mainly provides the following technical solutions: Firstly, this application provides a reverse analysis method. The reverse analysis method provided in this embodiment may include at least: parsing the HarmonyOS application package to be reverse analyzed to obtain bytecode files within the HarmonyOS application package; performing static syntax analysis on the bytecode files to identify suspicious methods in the application layer; if a suspicious method is identified, performing dynamic runtime analysis on the bytecode files to trace the call logic chain related to the suspicious method in the application layer; if it is determined that the call logic chain indicates a target method with a cross-layer call relationship with the native layer, determining the cross-layer interaction chain between the application layer and the native layer based on the cross-layer call relationship between the target method and the native layer; and generating the reverse analysis result of the HarmonyOS application package based on the suspicious method, the call logic chain, and the cross-layer interaction chain.

[0005] Secondly, this application provides a reverse analysis apparatus, which in this embodiment may include at least: The parsing module is used to parse the HarmonyOS application package to be reverse-engineered and obtain the bytecode file within the HarmonyOS application package. The identification module is used to perform static syntax analysis on the bytecode file and identify suspicious methods in the application layer; The tracing module is used to perform dynamic runtime analysis on the bytecode file if a suspicious method is identified, and to trace the call logic chain related to the suspicious method in the application layer. The determination module is used to determine the cross-layer interaction link between the application layer and the native layer based on the cross-layer call relationship between the target method and the native layer if the determined call logic link indicates that the target method has a cross-layer call relationship with the native layer. The generation module is used to generate reverse analysis results of the HarmonyOS application package based on the suspicious method, the call logic chain, and the cross-layer interaction chain.

[0006] Thirdly, this application provides a computer-readable storage medium including a stored program, wherein the program, when running, controls the device where the storage medium is located to execute the reverse analysis method of the first aspect.

[0007] Fourthly, this application provides an electronic device comprising: a memory for storing a program; and a processor coupled to the memory for running the program to perform the reverse analysis method of the first aspect.

[0008] Fifthly, this application provides a computer program product comprising: a computer program / computer executable instructions, wherein the computer program / computer executable instructions are a reverse analysis method of the first aspect.

[0009] The reverse engineering method and apparatus provided in this application, upon determining the HarmonyOS application package to be reverse engineered, parses the HarmonyOS application package to obtain bytecode files within it. Then, static syntax analysis is performed on the bytecode files to identify suspicious methods in the application layer. If suspicious methods are identified, dynamic runtime analysis is performed on the bytecode files to trace the call logic chain related to the suspicious methods in the application layer. If the call logic chain indicates a target method with a cross-layer call relationship to the native layer, the cross-layer interaction chain between the application layer and the native layer is determined based on this cross-layer call relationship. Finally, based on the suspicious methods, call logic chains, and cross-layer interaction chains, the reverse engineering results of the HarmonyOS application package are generated. It can be seen that the solution provided in this embodiment uses bytecode files as the entry point for reverse engineering. By parsing the bytecode files, suspicious methods are identified, the call logic chains related to the suspicious methods and the cross-layer interaction chains between the application layer and the native layer are traced and reconstructed, and then the reverse engineering results are generated based on the suspicious methods, call logic chains, and cross-layer interaction chains. This approach clarifies the execution path, triggering conditions, and cross-layer call dependencies of suspicious methods, thereby overcoming the problems of strong concealment of malicious methods and difficulty in reconstructing cross-layer interaction logic in the HarmonyOS ecosystem. It can provide effective support for the security assessment of subsequent HarmonyOS application packages.

[0010] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 A flowchart of a reverse analysis method provided in one embodiment of this application is shown; Figure 2 A flowchart of a reverse analysis method provided in another embodiment of this application is shown; Figure 3 This illustration shows a schematic diagram of a reverse analysis apparatus according to an embodiment of this application; Figure 4 A schematic diagram of a reverse analysis apparatus provided in another embodiment of this application is shown. Detailed Implementation

[0013] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0014] Currently, HarmonyOS application packages differ fundamentally from traditional Android application packages, making it difficult to directly adapt existing, mature Android reverse engineering techniques to HarmonyOS application packages. The lack of dedicated reverse engineering techniques for HarmonyOS application packages hinders effective security assessments such as security testing, vulnerability discovery, and malware identification. This not only restricts the construction of a security defense for the HarmonyOS application ecosystem but also poses a potential threat to the stable operation of the system and the legitimate rights and interests of users, creating hidden security risks.

[0015] Research has revealed that the HarmonyOS application package contains critical bytecode files. These bytecode files carry the application's execution logic and functional implementation, serving as a starting point for reverse engineering. Based on this, by parsing the bytecode files in the HarmonyOS application package, hidden suspicious methods can be identified, the call logic chains related to these methods can be traced and reconstructed, and the cross-layer interaction chains between the application layer and the native layer can be traced. Then, based on the suspicious methods, call logic chains, and cross-layer interaction chains, reverse engineering results can be generated, thus forming a reverse engineering technique for parsing the HarmonyOS application package, providing reliable technical support for the security assessment of the HarmonyOS application package.

[0016] Based on the above findings, this embodiment provides a specific reverse analysis scheme, which includes: parsing the HarmonyOS application package to be reverse analyzed to obtain the bytecode file within the HarmonyOS application package; performing static syntax analysis on the bytecode file to identify suspicious methods in the application layer; if a suspicious method is identified, performing dynamic runtime analysis on the bytecode file to trace the call logic chain related to the suspicious method in the application layer; if the call logic chain indicates a target method with a cross-layer call relationship with the native layer, determining the cross-layer interaction chain between the application layer and the native layer based on the cross-layer call relationship between the target method and the native layer; and generating the reverse analysis result of the HarmonyOS application package based on the suspicious method, the call logic chain, and the cross-layer interaction chain.

[0017] The reverse engineering scheme provided in this embodiment can perform reverse engineering analysis on any HarmonyOS application package. The HarmonyOS application package can be flexibly selected based on business needs, and this embodiment does not limit it. Based on the above reverse engineering scheme, this embodiment specifically provides a reverse engineering method and apparatus, which will be described in detail below.

[0018] This application provides a reverse analysis method, such as... Figure 1 As shown, the reverse analysis method provided in this embodiment may include at least the following steps 101 to 105.

[0019] 101. Parse the HarmonyOS application package to be reverse-engineered to obtain the bytecode files within the HarmonyOS application package.

[0020] The HarmonyOS Application Package (HAP) is a standardized application distribution and runtime platform built on the HarmonyOS operating system. It includes code, resources, and configurations, and is compatible with various terminal devices such as mobile phones, tablets, smart wearables, and in-vehicle systems. It is the core unit for application distribution, installation, and operation within the HarmonyOS ecosystem. In some embodiments, when a security assessment of any HarmonyOS Application Package is required, that application package can be identified as the HarmonyOS Application Package to be reverse engineered, so that the security assessment of the application package can be supported by the reverse engineering results.

[0021] After identifying the HarmonyOS application package to be reverse-engineered, it is necessary to parse the HarmonyOS application package to obtain the bytecode files that carry the application's execution logic and functional implementation, so as to use the bytecode files as the entry point for reverse-engineering.

[0022] In some embodiments, the specific implementation process of parsing the HarmonyOS application package to be reverse-engineered and obtaining the bytecode files within the HarmonyOS application package may include: determining the compression format of the HarmonyOS application package, decompressing the HarmonyOS application package to a specified directory using a decompression algorithm or decompression tool adapted to the compression format, and extracting the .abc format bytecode files (i.e., Ark bytecode files) from the specified directory. For example, the HarmonyOS application package is a ZIP compressed package. The HarmonyOS compressed package is decompressed to a specified directory using the unzip command or any decompression tool. The ets / directory is located within the specified directory. This ets / directory (e.g., ets / modules.abc) contains the .abc format Ark bytecode files generated by the Ark compiler. Therefore, the .abc format Ark bytecode files are extracted as bytecode files within the HarmonyOS application package.

[0023] 102. Perform static syntax analysis on bytecode files to identify suspicious methods in the application layer.

[0024] Some malicious methods in the application layer (such as unauthorized data theft, remote code injection, malicious instruction execution, and illegal uploading of private information) may evade dynamic detection by means of syntax obfuscation, hiding call chains, and disguising legitimate functions. However, bytecode directly maps the execution logic and behavioral characteristics of HarmonyOS applications. Static syntax analysis can identify methods in the application layer that may pose security risks without running the HarmonyOS application. Therefore, suspicious methods in the application layer can be identified by performing static syntax analysis on bytecode files.

[0025] In some embodiments, the process of performing static syntax analysis on bytecode files to identify the implementation of suspicious methods in the application layer may include at least the following steps 102A to 102C.

[0026] 102A. Perform static syntax analysis on the bytecode file to extract code element information from the application layer.

[0027] The code element information in the application layer can include at least one of the following: class information, method information, variable information, and literal array information. In some embodiments, the implementation process of step 102A may include at least the following steps: Parsing the bytecode file into a structured abstract syntax tree using a syntax tree (AST) construction tool, and expanding the hierarchical extraction steps with class definitions as the top-level node: traversing from the top-level node to obtain the class name, access modifier, inheritance relationship, and implemented interfaces, and parsing the class-level field definitions (including name, type, and modifiers) to obtain class information; for the method sub-nodes under the class node, extracting the method name, parameter list, return type, modifier, and exception declaration information to obtain method information; identifying local variable definitions from the method body syntax subtree, recording their name, type, scope, and position in the syntax tree to obtain variable information; when parsing variable initialization or assignment nodes, if a literal array is encountered (such as {1, 2, 3} in int[]nums = {1, 2, 3}), relevant information is extracted to obtain literal array information, at least including the array element type, element value (such as 1, 2, 3), array length, and association with the variable to which it belongs (i.e., which variable the literal array is the initial value of).

[0028] 102B. Match the extracted code element information with the first information database.

[0029] The first information database includes sample code elements known to trigger sensitive behaviors in HarmonyOS applications. Sensitive behaviors are those that could lead to security risks and losses, such as unauthorized access to system privileges, data leakage, data tampering, data loss, abuse of software and hardware resources, business process interruption, or system malfunction. Therefore, to quickly identify suspicious methods in the HarmonyOS application package that may pose security risks and losses, the extracted code element information needs to be matched against the predefined first information database. Specifically, this matching process may include performing the following steps for each extracted code element: determining whether the current code element exists as a sample code element in the first information database; if so, identifying the current code element as a successfully matched first code element; otherwise, determining the similarity between the current code element and the sample code element in the first information database; if a sample code element exists and its similarity to the current code element is not less than a similarity threshold, then identifying the current code element as a successfully matched first code element. It should be noted that the First Information Database continuously updates the sample code element information based on the latest discoveries of code element information that triggers sensitive behaviors in HarmonyOS applications.

[0030] 102C. If there is a first code element information that successfully matches the first information database, then the method associated with the first code element information in the application layer is identified as a suspicious method.

[0031] The first code element information that successfully matches the first information database is highly likely to trigger sensitive behaviors in HarmonyOS applications. Therefore, the method associated with the first code element information in the application layer is identified as a suspicious method, so that it can be reverse-engineered in a targeted manner for subsequent security assessment.

[0032] In some embodiments, after step 102B, there may be a situation where there is no first code element information that successfully matches the first information database. Based on this, the reverse analysis method provided in this embodiment may further include the following steps: if there is second code element information that does not successfully match the first information database and does not successfully match the second information database, then the method associated with the second code element information in the application layer is determined as a suspicious method.

[0033] The second information base includes sample code element information that is known not to trigger sensitive behaviors in HarmonyOS applications. If second code element information exists, it indicates that it may or may not trigger sensitive behaviors in HarmonyOS applications. Therefore, the method of associating second code element information in the application layer is also identified as a suspicious method.

[0034] In some embodiments, the behavior of the method is correlated. Therefore, after a suspicious method is identified, the reverse analysis method provided in this embodiment may further include the following operations A and B.

[0035] Operation A: If a suspected method that has been identified has a related method in the bytecode file, then add the related method as an incremental addition to the identified suspected methods.

[0036] Methods associated with a suspicious method in the bytecode file may also pose risks due to risk propagation and implicit dependencies between them. Therefore, associated methods should also be added as incremental suspicious methods to the list of identified suspicious methods for comprehensive investigation. The specific implementation process for detecting whether an identified suspicious method has associated methods in the bytecode file can include performing the following steps for each identified suspicious method: Locate the identified suspicious method in the bytecode file; analyze the call relationships of the suspicious method to determine the methods called by the suspicious method and the methods that call the suspicious method; examine the target fields (such as static variables and instance variables) accessed by the suspicious method, tracing the read and write operations of these target fields by other methods to identify other methods operating on the target fields; and determine the methods called by the suspicious method, the methods that call the suspicious method, and the other methods operating on the target fields as associated methods in the bytecode file. Furthermore, after identifying associated methods in the bytecode file, the actual interaction between the associated methods and the suspicious method can be verified using debugging tools (such as the IDEA debugger). Based on the verified actual interaction relationships, the methods among these associated methods that actually have a relationship with the suspicious method can be identified.

[0037] Step B: Identify all methods in the bytecode file as suspicious methods. The complexity and concealment of suspicious methods in the bytecode file may prevent some risks from being discovered. Therefore, it is necessary to identify all methods in the bytecode file as suspicious methods to avoid missed detections.

[0038] The above operations A and B can be flexibly selected based on business needs, and this embodiment does not limit either one.

[0039] 103. If a suspicious method is identified, perform dynamic runtime analysis on the bytecode file to trace the call logic chain related to the suspicious method in the application layer.

[0040] Static syntax analysis can identify suspicious methods, but it cannot capture the calling logic of these methods. Therefore, when suspicious methods are identified through static syntax analysis, dynamic runtime analysis of the bytecode file is needed to trace the call logic chain related to the suspicious methods in the application layer. This overcomes the limitations of static syntax analysis and provides a more accurate basis for attack tracing and defense for security assessment. The call logic chain reflects the sequence and relationship of method calls in the HarmonyOS application. By reverse-analyzing its bytecode to extract this chain, the application's functional implementation logic (such as sensitive data acquisition and transmission paths, key business processes, etc.) can be reconstructed, thereby revealing the internal operating mechanism and potential behavior of the HarmonyOS application and providing core clues for reverse analysis of the HarmonyOS application package.

[0041] In some embodiments, performing dynamic runtime analysis on bytecode files to trace the specific implementation process of the call logic chain related to the suspicious method in the application layer may include at least the following steps 103A to 103C.

[0042] 103A. Run the bytecode file in the first sandbox isolation environment and synchronously collect register status data. The register status data is used to indicate the context information of method calls in the bytecode and the jump behavior characteristics between bytecode instructions.

[0043] The first sandbox isolation environment is the HarmonyOS emulator environment. This environment ensures that bytecode file execution does not affect or is unaffected by external systems, and that register status data is collected without omission or delay. Furthermore, the first sandbox isolation environment is set to the phone's screen resolution to eliminate environmental interference and reproduce the actual display scenario on the phone.

[0044] The specific implementation process of step 103A may include the following steps: loading the bytecode file in the first sandbox isolation environment, converting the bytecode file into executable instructions through a parser adapted to the corresponding instruction set architecture; calling the instruction execution engine to execute the instructions one by one in sequence, while simultaneously collecting the changes in register values ​​and status indicators before and after the execution of each instruction in real time, and synchronously storing the collected data to the target storage location according to the execution sequence.

[0045] Register state data is used to indicate the context information of method calls in bytecode and the characteristics of jump behavior between bytecode instructions. For example, during bytecode file execution, when a method is called, the program counter in the register records the address of the current calling instruction, the stack pointer register is updated as the method stack frame is pushed onto the stack to point to the top of the new stack frame, and the registers related to the local variable table store the parameter values ​​passed by the caller. The recorded register state data together constitute the context information during a method call. For example, when a conditional jump instruction (such as `ifeq`) is encountered, the status register in the register sets a zero flag based on the calculation result, and the program counter jumps to the corresponding instruction address based on the flag status. The change in register state directly reflects the jump logic between instructions. For instance, if the zero flag is 1, the program counter is updated to the jump target address; otherwise, it continues to increment sequentially. Through these real-time changes in register state data, the triggering conditions and execution path of jump behavior can be tracked.

[0046] 103B. Based on the jump behavior characteristics indicated by register status data, the branch logic at the bytecode level is reconstructed.

[0047] The specific implementation process of step 103B may include the following steps: Extracting key features of jump instructions (such as conditional jumps and unconditional jumps) from register status data. Key features may include, but are not limited to, at least one of the following: the current instruction address pointed to before the jump, the specific value of the flag bits in the status register reflecting the jump trigger condition, the target instruction address updated after the jump, and the operand values ​​in the general-purpose registers before and after the jump (to assist in verifying the condition logic), etc.; performing correlation analysis between the key features and the bytecode instruction sequence of the bytecode file, by matching the jump instruction type (such as ifeq, iflt, etc.), comparing the correspondence between the flag bit status and the jump direction (such as jumping to branch A when the zero flag is 1, and jumping to branch B when it is 0), and combining the position of the instruction address in the bytecode to determine the branch entry point, sorting out the trigger condition of the branch logic, the instruction range of the branch path, and the flow relationship between each branch, and restoring the branch logic at the bytecode level.

[0048] For example, the restored branch logic includes: if the value of register v0 is greater than the value of register v1, then execute the instruction corresponding to label L1; otherwise, execute the instruction corresponding to label L2.

[0049] 103C. Associate the branch logic with the context information of the suspicious method call indicated by the register status data to obtain the call logic chain related to the suspicious method in the application layer.

[0050] The specific implementation process of step 103C may include at least the following steps: extracting the method call context information recorded in the register state data (the context information may include, but is not limited to, at least one of the following key data such as caller identifier, parameter passing value, and return address); establishing a mapping relationship between branch jumps in the branch logic and the context information; using register state changes as timing anchors; tracing the method call triggering conditions corresponding to each branch jump; and connecting the initiation, execution, branch switching, and return of the method call through the call chain identifier in the context data to restore the call logic chain related to the suspicious method in the application layer, so as to clarify the dependency relationship and execution sequence of the method call in the branch flow through the call logic chain.

[0051] For example, the call logic chain includes: when the application detects that the user's authorization status is authorized, it calls the method to obtain the user's location information (which is a suspicious method), and after obtaining it, it continues to call the method to upload location data (which is a suspicious method); if the authorization status is unauthorized, it calls the method to prompt for permission to be granted.

[0052] 104. If the call logic chain indicates that there is a cross-layer call relationship between the target method and the native layer, then the cross-layer interaction chain between the application layer and the native layer is determined based on the cross-layer call relationship between the target method and the native layer.

[0053] The HarmonyOS application package's functionality is implemented with the application layer at its core, and can be combined with the native layer as needed. The native layer carries critical functions such as performance computing, low-level hardware interaction, and encryption algorithms. Furthermore, the native layer code (implemented in C / C++) is difficult to directly decompile, and its call relationships with the application layer (implemented in ArkTS / JS) (such as function calls, data transfer, and permission requests) often conceal the application's core business processes, security mechanisms, and potential risks. Therefore, it is necessary to identify the target methods with cross-layer call relationships with the native layer by determining the call logic chain. This allows for the identification of cross-layer interaction links between the application layer and the native layer, providing comprehensive technical logic support for subsequent security assessments such as vulnerability discovery, malicious behavior analysis, feature replication, and compatibility adaptation. This avoids overlooking details due to analyzing only a single layer.

[0054] In some embodiments, the method for determining the implementation of the target method that indicates a cross-layer call relationship with the native layer by the call logic chain may include at least the following method A1 and method A2.

[0055] Method A1, the process of determining the implementation of the target method that has a cross-layer call relationship with the native layer as indicated by the call logic chain, may include the following steps: obtaining the declaration information of the method in the application layer in the call logic chain; if there is a method marked by the native layer keyword in the declaration information, then the corresponding method is determined as the target method that has a cross-layer call relationship with the native layer as indicated by the call logic chain.

[0056] The call logic chain includes suspicious methods and methods that have direct or indirect call logic relationships with the suspicious methods. For each of these methods, the following steps are performed: Determine the declaration information of the current method in the application layer in the bytecode file; Perform keyword matching verification on the declaration information. If the declaration information contains keywords corresponding to the HarmonyOS native layer (such as native annotations, native interface binding identifiers, etc.), it is determined that the current method is marked by native layer keywords, and the current method is identified as the target method indicated by the call logic chain that has a cross-layer call relationship with the native layer.

[0057] Method A2, the process of determining the implementation of the target method that has a cross-layer call relationship with the native layer as indicated by the call logic chain, may include the following steps: determining the call stack corresponding to the call logic chain; if there is a cross-layer call jump node in the call stack, and the cross-layer call jump node is associated with a method in the call logic chain, then the corresponding method is determined as the target method that has a cross-layer call relationship with the native layer as indicated by the call logic chain.

[0058] The process involves analyzing the call stack's hierarchical structure, node relationships, and call sequence to clarify the one-to-one correspondence between each node in the stack and the specific methods in the call logic chain (nodes serve as structured carriers of method call information, encapsulating core attributes such as method identifiers, hierarchical affiliation, and parent / child call relationships). Then, all nodes in the call stack are traversed, and potential cross-level call jump nodes are selected based on cross-level call determination rules (such as discontinuous method levels between a node and its parent node, or hierarchical jumps with non-direct parent-child relationships). Finally, it verifies whether the methods carried by the selected potential nodes belong to the call logic chain and whether the node serves as the initiator, receiver, or intermediate jump medium for cross-level method calls within the chain. If so, the method corresponding to that node is identified as the target method indicated by the call logic chain that has a cross-level call relationship with the native layer.

[0059] The above methods A1 and A2 can be flexibly selected based on business needs, and this embodiment does not limit this.

[0060] In some embodiments, when the call logic chain indicates that the target method has a cross-layer call relationship with the native layer, it is necessary to clarify its cross-layer interaction chain. Therefore, the step of determining the cross-layer interaction chain between the application layer and the native layer based on the cross-layer call relationship between the target method and the native layer is performed. The implementation process of this step may include at least performing the following steps 104A1 to 104A3 for each target method.

[0061] 104A1. Parse the dynamic link library file to determine the registered entry module symbol associated with the target method call, and based on the symbol, parse out the registered application module, and determine the initialization function bound to the target method in the application module.

[0062] By parsing the HarmonyOS application package, we can also obtain the dynamic link library files (usually .so files) within the HarmonyOS application package. Dynamic link library files are binary code libraries containing multiple functions that can be dynamically called by applications. Functions are the core components, and cross-layer sharing and flexible calling are achieved through the dynamic linking mechanism.

[0063] The specific implementation process of step 104A1 may include: parsing the symbol table of the dynamic link library file using tools (such as HDC, readelf, or objdump); filtering out the entry symbols related to module registration, i.e., the registration entry module symbols (usually containing module identification information), from the symbol table according to the HarmonyOS application module registration mechanism (such as through OHOS_MODULE_INFO or related registration macros), and determining the application module to which the symbol belongs; and searching for initialization functions that have a binding relationship with the target method in the source code or compilation artifacts of the application module, according to the HarmonyOS method binding rules (such as associating methods with initialization functions through macro definitions, annotations, or registration functions).

[0064] 104A2. In the second sandbox isolation environment, trace the address jumps during the execution of the initialization function, restore the other functions called by the initialization function in the native layer, and form a function call chain.

[0065] The second sandbox isolation environment is a customized HarmonyOS sandbox environment, which can reuse the first sandbox isolation environment or be rebuilt. This embodiment does not limit this. The specific implementation process of step 104A2 includes: loading and running the HarmonyOS application package in the second sandbox isolation environment, enabling dynamic instrumentation tools (such as Frida, Xposed) or system-level debugging components (such as the hdc debugger), and performing breakpoint interception and execution tracing on the initialization functions triggered by the application layer (such as Ability lifecycle initialization, Native module loading functions); monitoring register value changes, memory address jumps and system call triggering events during the execution of the initialization functions in the second sandbox isolation environment, capturing the function call instructions initiated to the native layer through the JNI / NDK interface (such as dlsym dynamic linking calls, static binding function calls), parsing the ELF file symbol table, function signature and parameter passing rules corresponding to the jump address; and combining disassemblers (such as IDA) to perform the following steps. Pro and Ghidra perform static analysis on the dynamic link library files in the native layer, cross-validate the address jumps and function call correlations captured in the sandbox, and gradually reconstruct the dependent functions (such as initialization configuration parsing, hardware resource adaptation, cross-process communication proxy, etc.) called by the initialization function in the native layer. Finally, according to the call sequence, parameter passing path and return value correlation, construct the function call chain from the application layer initialization function to the multi-level dependent functions in the native layer, so as to clarify the functional positioning and interaction logic of the function through the function call chain.

[0066] 104A3. Based on the binding relationship between the target method and the initialization function, as well as the function call chain, the cross-layer interaction link between the application layer and the native layer corresponding to the target method is determined.

[0067] The cross-layer interaction link between the application layer and the native layer is a bidirectional call and data interaction path formed by the application layer code in the HarmonyOS application through mechanisms such as JNI / NDK interfaces and system framework APIs, and the native layer SO library functions and kernel module interfaces. It is the core bridge connecting the application layer business logic and the underlying capabilities of the native layer. In the reverse analysis of the HarmonyOS application package, the analysis of this link can clarify the cross-layer function implementation dependencies and data flow logic, locate the cross-layer vulnerability trigger path, and expose the underlying mechanisms by which malicious applications evade detection and steal sensitive information. At the same time, it provides key support for application function restoration, protocol parsing, and security hardening verification.

[0068] The specific implementation process of step 104A3 may include the following steps: Based on the binding relationship between the target method and the initialization function, starting from the entry point of the target method in the application layer, use dynamic debugging tools (such as Frida script hooks) in the second sandbox isolation environment to trace its execution flow and record the trigger points of the initialization functions involved in the call stack; then, combined with the restored function call chain, locate the key nodes that initiate calls from the initialization function to the native layer (such as JNI function table indexes, NativeMethod structure mappings, or symbol addresses of dynamic links), and determine the functions called in the native layer by parsing the symbol table and disassembled code of the dynamic link library file corresponding to the key node; subsequently, perform single-step debugging of the native layer functions in the second sandbox isolation environment, and monitor their interaction with the application layer callbacks (such as JNI) through system APIs (such as HarmonyOS's IPC communication interface and Ability framework interaction functions). The process involves calling back application layer methods and event bus notifications, while also tracing parameter passing paths using cross-layer data structures (such as Parcel serialized objects and Binder proxies) from static analysis. Finally, following the bidirectional interaction logic of "application layer target method → ​​initialization function → native layer call function → native layer callback / system interaction → application layer response", the cross-layer interaction chain, including call sequence, data flow, and interface mapping relationships, is identified.

[0069] In some embodiments, the second sandbox isolation environment further deploys sensitive data. Based on this, the reverse analysis method provided in this embodiment may further include the following steps: if a target function is detected in the function call chain, and the parameters of the target function include at least some sensitive data in the second sandbox isolation environment, the conclusion that the target method will cause sensitive data leakage is added to the reverse analysis result so that when a security assessment is subsequently performed based on the reverse analysis result, the target method needs to be given priority for evaluation.

[0070] In some embodiments, the reverse analysis method provided in this embodiment may further include the following steps: if it is determined that the call logic link does not indicate a target method that has a cross-layer call relationship with the native layer, it indicates that the suspicious method does not involve cross-layer calls. Therefore, based on the suspicious method, the call logic link and the cross-layer interaction link, the reverse analysis result of the HarmonyOS application package is generated.

[0071] 105. Based on suspicious methods, call logic links, and cross-layer interaction links, generate reverse analysis results of the HarmonyOS application package.

[0072] Suspicious methods are those that could trigger sensitive actions that could harm the HarmonyOS ecosystem and user information. The call logic chain clearly identifies the call order, dependencies, and trigger paths of these suspicious methods. The cross-layer interaction chain clarifies data transmission, permission requests, resource access, and other interactive behaviors between different layers. Considering that malicious actions in HarmonyOS applications typically do not occur independently of a single method, but rather through the orderly invocation of multiple methods and cross-layer interaction to construct an attack chain, analyzing a single method in isolation cannot reconstruct its triggering conditions, execution flow, attack targets, and scope of harm. Therefore, based on suspicious methods, call logic chains, and cross-layer interaction chains, reverse engineering results of the HarmonyOS application package are generated to provide complete and verifiable technical evidence for security assessments.

[0073] The specific implementation process of step 105 may include at least the following steps: classifying and labeling suspicious methods, clarifying the function (such as data theft, permission overreach, remote control, etc.), triggering conditions, and key parameters of each suspicious method; sorting out the calling order, parameter passing relationship, and conditional branches between methods through the call logic chain, and drawing the call flowchart; clarifying the cross-layer behavior of the corresponding methods through the cross-layer interaction chain; summarizing the suspicious methods, call logic chain, cross-layer interaction chain, method characteristics corresponding to each suspicious method, call flowchart, and cross-layer behavior to generate the reverse analysis results of the HarmonyOS application package.

[0074] The reverse engineering method provided in this application, upon identifying the HarmonyOS application package to be reverse engineered, parses the HarmonyOS application package to obtain bytecode files within it. Static syntax analysis is then performed on the bytecode files to identify suspicious methods in the application layer. If suspicious methods are identified, dynamic runtime analysis is performed on the bytecode files to trace the call logic chain related to these suspicious methods in the application layer. If the call logic chain indicates a target method with a cross-layer call relationship to the native layer, the cross-layer interaction chain between the application layer and the native layer is determined based on this cross-layer call relationship. Finally, based on the suspicious methods, call logic chains, and cross-layer interaction chains, the reverse engineering result of the HarmonyOS application package is generated. As can be seen, the solution provided in this embodiment uses bytecode files as the entry point for reverse engineering. By parsing the bytecode files, it identifies suspicious methods within them, traces and reconstructs the call logic chains related to these suspicious methods, and establishes cross-layer interaction chains between the application layer and the native layer. Then, it generates reverse engineering results based on these suspicious methods, call logic chains, and cross-layer interaction chains. This approach clarifies the execution path, triggering conditions, and cross-layer call dependencies of suspicious methods, thereby overcoming the problems of strong concealment of malicious methods and difficulty in reconstructing cross-layer interaction logic in the HarmonyOS ecosystem. It can provide effective support for the security assessment of subsequent HarmonyOS application packages.

[0075] In some embodiments of this application, one embodiment also provides a reverse analysis method, such as... Figure 2 As shown, the reverse analysis method provided in this embodiment may include at least the following steps 201 to 207.

[0076] 201. Parse the HarmonyOS application package to be reverse-engineered to obtain the bytecode files within the HarmonyOS application package.

[0077] 202. Perform static syntax analysis on the bytecode file to identify suspicious methods in the application layer; if a suspicious method is identified, proceed to step 203; if no suspicious method is identified, issue a message indicating that no suspicious method is found and end the current process.

[0078] Furthermore, in order to more comprehensively identify suspicious methods in the application layer, before step 203, the reverse analysis method provided in this embodiment may also include the following steps: running the HarmonyOS application package in a third sandbox isolation environment where sensitive data is deployed; if it is monitored that the HarmonyOS application package calls a method for obtaining sensitive data during operation, and / or, it is monitored that the network data generated by the HarmonyOS application package during operation includes at least some sensitive data, then the method for obtaining sensitive data in the bytecode file is added as a suspicious method increment to the identified suspicious methods.

[0079] The fact that methods for obtaining sensitive data are called during runtime indicates that these methods could lead to sensitive data leakage. Furthermore, the fact that network data includes at least some sensitive data indicates that methods within the HarmonyOS application package that perform sensitive data acquisition functions could lead to sensitive data leakage. Based on this, methods in the bytecode files used to obtain sensitive data (e.g., methods for obtaining contacts, SMS messages, etc.) are identified, and these methods are then added incrementally as suspicious methods to the list of identified suspicious methods.

[0080] 203. Perform dynamic runtime analysis on the bytecode file and trace the call logic chain related to the suspicious method in the application layer. If it is determined that the call logic chain indicates a target method with a cross-layer call relationship with the native layer, then execute step 204. Or if it is determined that the call logic chain does not indicate a target method with a cross-layer call relationship with the native layer, then execute step 205.

[0081] 204. Based on the cross-layer call relationship between the target method and the native layer, determine the cross-layer interaction link between the application layer and the native layer, and execute step 206.

[0082] 205. Based on the suspicious methods and call logic chain, generate the reverse analysis results of the HarmonyOS application package and execute 207.

[0083] 206. Based on suspicious methods, call logic links, and cross-layer interaction links, generate reverse analysis results of the HarmonyOS application package.

[0084] 207. Obtain resource identifiers from the constant pool of the bytecode file; determine the target bytecode instructions that reference the resource identifiers in the bytecode; if there is a target suspicious method associated with the target bytecode instruction, obtain the resource corresponding to the resource identifier through the resource file, and associate the resource with the target suspicious method in the reverse analysis results.

[0085] Parsing the HarmonyOS application package also yields resource files within it. These resource files store resource entities such as layouts, strings, and images, and are mapped to method calls through resource identifiers in the bytecode constant pool, providing necessary resource support for method execution. Therefore, step 207 needs to be executed to support the restoration of application runtime logic, verification of resource legitimacy, or identification of malicious resource dependencies.

[0086] If a suspicious method associated with the target bytecode instruction exists, the resource corresponding to the resource identifier is obtained through the resource file, and the resource is associated with the suspicious method in the reverse analysis results. This allows for the accurate extraction of resource data that the method depends on during execution, providing a foundation for subsequent analysis of application function implementation mechanisms, verification of resource call legitimacy, and locating resource dependencies hidden by malicious code (such as malicious configurations, illegal interface addresses, etc.).

[0087] Furthermore, one embodiment of this application also provides a reverse analysis apparatus, such as... Figure 3 As shown, the reverse analysis apparatus provided in this embodiment may include at least: Parsing module 31 is used to parse the HarmonyOS application package to be reverse analyzed and obtain the bytecode file within the HarmonyOS application package; The identification module 32 is used to perform static syntax analysis on the bytecode file and identify suspicious methods in the application layer; The tracing module 33 is used to perform dynamic runtime analysis on the bytecode file if a suspicious method is identified, and to trace the call logic chain related to the suspicious method in the application layer. The determination module 34 is used to determine the cross-layer interaction link between the application layer and the native layer based on the cross-layer call relationship between the target method and the native layer if the determined call logic link indicates that the target method has a cross-layer call relationship with the native layer. The generation module 35 is used to generate the reverse analysis results of the HarmonyOS application package based on the suspicious method, the call logic chain, and the cross-layer interaction chain.

[0088] The reverse engineering apparatus provided in this embodiment, upon determining the HarmonyOS application package to be reverse-engineered, parses the HarmonyOS application package to obtain bytecode files within it. Then, static syntax analysis is performed on the bytecode files to identify suspicious methods in the application layer. If suspicious methods are identified, dynamic runtime analysis is performed on the bytecode files to trace the call logic chain related to the suspicious methods in the application layer. If the call logic chain indicates a target method with a cross-layer call relationship to the native layer, the cross-layer interaction chain between the application layer and the native layer is determined based on this cross-layer call relationship. Finally, based on the suspicious methods, call logic chains, and cross-layer interaction chains, the reverse engineering result of the HarmonyOS application package is generated. It can be seen that the solution provided in this embodiment uses bytecode files as the entry point for reverse engineering. By parsing the bytecode files, suspicious methods are identified, the call logic chains related to the suspicious methods and the cross-layer interaction chains between the application layer and the native layer are traced and reconstructed, and then the reverse engineering result is generated based on the suspicious methods, call logic chains, and cross-layer interaction chains. This approach clarifies the execution path, triggering conditions, and cross-layer call dependencies of suspicious methods, thereby overcoming the problems of strong concealment of malicious methods and difficulty in reconstructing cross-layer interaction logic in the HarmonyOS ecosystem. It can provide effective support for the security assessment of subsequent HarmonyOS application packages.

[0089] In some embodiments of this application, such as Figure 4 As shown, the tracking module 33 may include at least: The acquisition unit 331 is used to run the bytecode file in the first sandbox isolation environment and synchronously acquire register status data. The register status data is used to indicate the context information of method calls in the bytecode and the jump behavior characteristics between bytecode instructions. The restoration unit 332 is used to restore the branch logic at the bytecode level based on the jump behavior characteristics indicated by the register status data. The association unit 333 is used to associate the branch logic with the context information of the suspicious method call indicated by the register status data to obtain the call logic chain related to the suspicious method in the application layer.

[0090] In some embodiments of this application, such as Figure 4 As shown, the determining module 34 may include at least: The first determining unit 341 is used to obtain the declaration information of the method in the call logic chain in the application layer; if there is a method marked by the native layer keyword in the declaration information, the corresponding method is determined as the target method indicated by the call logic chain that has a cross-layer call relationship with the native layer.

[0091] And / or, The second determining unit 342 is used to determine the call stack corresponding to the call logic link; if there is a cross-layer call jump node in the call stack, and the cross-layer call jump node is associated with a method in the call logic link, then the corresponding method is determined as the target method indicated by the call logic link that has a cross-layer call relationship with the native layer.

[0092] In some embodiments of this application, such as Figure 4 As shown, by parsing the HarmonyOS application package, dynamic link library files within the HarmonyOS application package are also obtained. Therefore, the determining module 34 may include at least: a third determining unit 343, used to perform the following for each target method: parsing the dynamic link library file to determine the registered entry module symbol associated with the target method call; parsing the registered application module based on the symbol, and determining the initialization function bound to the target method in the application module; tracing the address jumps during the execution of the initialization function in the second sandbox isolation environment, restoring other functions called by the initialization function in the native layer, and forming a function call chain; and determining the cross-layer interaction link between the application layer and the native layer corresponding to the target method based on the binding relationship between the target method and the initialization function and the function call chain.

[0093] In some embodiments of this application, such as Figure 4As shown, the determining module 34 may further include: a first detection unit 344, which is used to add the conclusion that the target method will cause sensitive data leakage to the reverse analysis result if a target function is detected in the function call chain, wherein the parameters of the target function include at least some sensitive data in the second sandbox isolation environment.

[0094] In some embodiments of this application, such as Figure 4 As shown, the identification module 32 may include at least: Extraction unit 321 is used to perform static syntax analysis on the bytecode file and extract code element information in the application layer; The matching unit 322 is used to match the extracted code element information with the first information database, which includes sample code element information known to cause sensitive behaviors in HarmonyOS applications. The fourth determining unit 323 is used to determine the method associated with the first code element information in the application layer as a suspicious method if there is first code element information that successfully matches the first information database.

[0095] In some embodiments of this application, such as Figure 4 As shown, the identification module 32 may further include: a fifth determining unit 324, which is used to determine the method associated with the second code element information in the application layer as a suspicious method if there is second code element information that is not successfully matched with the first information database and is not successfully matched with the second information database. The second information database includes sample code element information that is known not to cause HarmonyOS applications to generate sensitive behaviors.

[0096] In some embodiments of this application, such as Figure 4 As shown, the identification module 32 may further include: a second detection unit 325, used to add the associated method as an incremental suspicious method to the identified suspicious methods if the identified suspicious method has an associated method in the bytecode file.

[0097] In some embodiments of this application, such as Figure 4 As shown, the reverse analysis device provided in this embodiment may further include: a first detection module 36, used to run the HarmonyOS application package in a third sandbox isolation environment where sensitive data is deployed; if it is detected that the HarmonyOS application package calls a method for obtaining the sensitive data during operation, and / or, it is detected that the network data generated by the HarmonyOS application package during operation includes at least some sensitive data, then the method for obtaining the sensitive data in the bytecode file is added as a suspicious method increment to the suspicious methods identified by the identification module 32.

[0098] In some embodiments of this application, such as Figure 4As shown, by parsing the HarmonyOS application package, resource files within the HarmonyOS application package are also obtained. Therefore, the reverse analysis device provided in this embodiment may further include: a second detection module 37, used to obtain resource identifiers in the constant pool of the bytecode file; determine the target bytecode instruction in the bytecode that references the resource identifier; if there is a target suspicious method associated with the target bytecode instruction, then obtain the resource corresponding to the resource identifier through the resource file, and associate the resource with the target suspicious method in the reverse analysis result generated by the generation module 35.

[0099] For a detailed explanation of the reverse analysis apparatus provided in this application, the operation of each functional module can be found in the corresponding detailed explanation of the above-described reverse analysis method embodiment, and will not be repeated here.

[0100] Furthermore, one embodiment of this application also provides a computer-readable storage medium, the storage medium including a stored program, wherein, when the program is executed, it controls the device where the storage medium is located to perform the above-described reverse analysis method.

[0101] Furthermore, one embodiment of this application also provides an electronic device, the electronic device comprising: a memory for storing a program; and a processor coupled to the memory for running the program to perform the above-described reverse analysis method.

[0102] Furthermore, one embodiment of this application also provides a computer program product, the computer program product comprising: a computer program / computer executable instructions, the computer program / computer executable by the above-described reverse analysis method.

[0103] In the above embodiments, the data involved in each embodiment are all authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data comply with the relevant laws, regulations and standards of the relevant countries and regions.

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

[0105] It is understood that the relevant features in the above methods and apparatus can be referenced interchangeably. Furthermore, the terms "first," "second," etc., in the above embodiments are used to distinguish between embodiments and do not represent the superiority or inferiority of any particular embodiment.

[0106] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0107] The algorithms and displays provided herein are not inherently related to any particular computer, virtual system, or other device. Various general-purpose systems can also be used in conjunction with the teachings herein. The required structure for constructing such systems is apparent from the above description. Furthermore, this application is not directed to any particular programming language. It should be understood that the content of this application described herein can be implemented using various programming languages, and the above description of specific languages ​​is for the purpose of disclosing preferred embodiments of this application.

[0108] In addition, the memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0109] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0110] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data cutover device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data cutover device, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0111] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data cutover device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0112] These computer program instructions can also be loaded onto a computer or other programmable data cutover device to cause a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable device for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0113] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0114] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0115] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0116] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0117] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0118] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A reverse analysis method, characterized in that, The method includes: Parse the HarmonyOS application package to be reverse-engineered to obtain the bytecode file within the HarmonyOS application package; Static syntax analysis is performed on the bytecode file to identify suspicious methods in the application layer; If a suspicious method is identified, dynamic runtime analysis is performed on the bytecode file to trace the call logic chain related to the suspicious method in the application layer; If the call logic chain indicates a target method that has a cross-layer call relationship with the native layer, then based on the cross-layer call relationship between the target method and the native layer, the cross-layer interaction chain between the application layer and the native layer is determined. Based on the suspected method, the call logic chain, and the cross-layer interaction chain, the reverse analysis results of the HarmonyOS application package are generated.

2. The method according to claim 1, characterized in that, Dynamic runtime analysis is performed on the bytecode file to trace the call logic chain related to the suspicious method in the application layer, including: The bytecode file is run in the first sandbox isolation environment, and register status data is collected synchronously. The register status data is used to indicate the context information of method calls in the bytecode and the jump behavior characteristics between bytecode instructions. Based on the jump behavior characteristics indicated by the register status data, the branch logic at the bytecode level is reconstructed. By associating the branch logic with the context information of the suspicious method call indicated by the register status data, the call logic chain related to the suspicious method in the application layer is obtained.

3. The method according to claim 1, characterized in that, Determining the target method indicated by the call logic chain that has a cross-layer call relationship with the native layer includes: Obtain the declaration information of the methods in the call logic chain in the application layer; if there is a method marked by a native layer keyword in the declaration information, then determine the corresponding method as the target method indicated by the call logic chain that has a cross-layer call relationship with the native layer; And / or, determine the call stack corresponding to the call logic chain; if there is a cross-layer call jump node in the call stack, and the cross-layer call jump node is associated with a method in the call logic chain, then the corresponding method is determined as the target method indicated by the call logic chain that has a cross-layer call relationship with the native layer.

4. The method according to claim 1, characterized in that, By parsing the HarmonyOS application package, dynamic link library files within the application package are also obtained. Based on the cross-layer call relationship between the target method and the native layer, the cross-layer interaction link between the application layer and the native layer is determined, including: For each target method, the following steps are performed: Parse the dynamic link library file to determine the registered entry module symbol associated with the target method call; based on the symbol, parse the registered application module, and determine the initialization function bound to the target method within the application module; trace the address jumps during the execution of the initialization function in the second sandbox isolation environment, reconstruct other functions called by the initialization function in the native layer, and form a function call chain; based on the binding relationship between the target method and the initialization function and the function call chain, determine the cross-layer interaction link between the application layer and the native layer corresponding to the target method.

5. The method according to claim 4, characterized in that, The method further includes: If a target function is detected in the function call chain, the conclusion that the target method will cause sensitive data leakage is added to the reverse analysis result. The parameters of the target function include at least some sensitive data in the second sandbox isolation environment.

6. The method according to claim 1, characterized in that, Static syntax analysis is performed on the bytecode file to identify suspicious methods in the application layer, including: Static syntax analysis is performed on the bytecode file to extract code element information from the application layer; The extracted code element information is matched with the first information database, which includes sample code element information known to trigger sensitive behaviors in HarmonyOS applications. If a first code element information that successfully matches the first information database exists, then the method associated with the first code element information in the application layer is identified as a suspicious method.

7. The method according to claim 6, characterized in that, The method further includes: if there is second code element information that does not match the first information database and does not match the second information database, then the method associated with the second code element information in the application layer is determined as a suspicious method, and the second information database includes sample code element information that is known not to cause HarmonyOS applications to generate sensitive behaviors; And / or, The method further includes: if an identified suspicious method has an associated method in the bytecode file, then the associated method is added as an increment to the identified suspicious methods.

8. The method according to any one of claims 1-7, characterized in that, The method further includes: running the HarmonyOS application package in a third sandbox isolation environment where sensitive data is deployed; if it is detected that the HarmonyOS application package calls a method for obtaining the sensitive data during operation, and / or, it is detected that the network data generated by the HarmonyOS application package during operation includes at least some sensitive data, then the method for obtaining the sensitive data in the bytecode file is added as a suspicious method increment to the identified suspicious methods; And / or, If the HarmonyOS application package is parsed and resource files within the HarmonyOS application package are also obtained, then the method further includes: obtaining resource identifiers in the constant pool of the bytecode file; determining the target bytecode instruction in the bytecode that references the resource identifier; if there is a target suspicious method associated with the target bytecode instruction, then obtaining the resource corresponding to the resource identifier through the resource file, and associating the resource with the target suspicious method in the reverse analysis result.

9. A reverse analysis device, characterized in that, The device includes: The parsing module is used to parse the HarmonyOS application package to be reverse-engineered and obtain the bytecode file within the HarmonyOS application package. The identification module is used to perform static syntax analysis on the bytecode file and identify suspicious methods in the application layer; The tracing module is used to perform dynamic runtime analysis on the bytecode file if a suspicious method is identified, and to trace the call logic chain related to the suspicious method in the application layer. The determination module is used to determine the cross-layer interaction link between the application layer and the native layer based on the cross-layer call relationship between the target method and the native layer if the determined call logic link indicates that the target method has a cross-layer call relationship with the native layer. The generation module is used to generate reverse analysis results of the HarmonyOS application package based on the suspicious method, the call logic chain, and the cross-layer interaction chain.

10. A computer-readable storage medium, characterized in that, The storage medium includes a stored program, wherein, when the program is executed, it controls the device containing the storage medium to perform the reverse analysis method according to any one of claims 1 to 8.

11. An electronic device, characterized in that, The electronic device includes: a memory for storing a program; and a processor coupled to the memory for running the program to perform the reverse analysis method according to any one of claims 1 to 8.

12. A computer program product, characterized in that, The computer program product includes: a computer program / computer executable instructions, wherein the computer program / computer executable is the reverse analysis method according to any one of claims 1 to 8.

Images