A method and system for dynamically instrumenting HarmonyOS NEXT Native layer functions

Abstract

The present application relates to the technical field of dynamic plug-in, and particularly relates to a method and system for dynamically plugging in a function of a NEXT Native layer of a Hongmeng system.The method comprises the following steps: obtaining a process identifier of a target application process, so as to read a corresponding memory mapping file to obtain a loading base address and a file path of a Native layer ELF shared object; reading an ELF file corresponding to the file path, and establishing an index relationship table of a target function symbol name, a PLT entry and a PLT section file offset of each entry in a PLT section; adding the loading base address and the PLT section file offset to calculate a PLT section memory starting address; and calculating a memory absolute address of a target function PLT entry according to a PLT entry of a to-be-intercepted function in the index relationship table.The present application establishes an index relationship of a symbol and an address by analyzing a memory mapping file and an ELF shared object file of a target process, and realizes accurate function interception at a PLT entry level.

Description

Technical Field

[0001] This invention relates to the field of dynamic instrumentation technology, and in particular to a method and system for dynamically instrumenting HarmonyOS NEXT Native layer functions. Background Technology

[0002] The HarmonyOS NEXT operating system, now officially independent, has transitioned its underlying architecture from a traditional Linux kernel-compatible layer to a self-developed OpenHarmony kernel system. Its application runtime framework has also shifted from multi-language mixed execution to a unified compilation and execution mode centered around ArkTS. During this process, HarmonyOS NEXT introduced a new Native layer runtime environment. This environment supports inter-module communication between C / C++ and the ArkTS layer through the ELF shared object mechanism, providing efficient execution capabilities for underlying performance components and system services. However, with the upgrade of the system security model and the deepening of the distributed architecture, developers find it difficult to directly access the runtime behavior of the Native layer, making traditional hooking or debugging methods inapplicable in HarmonyOS NEXT.

[0003] Existing dynamic instrumentation techniques are primarily designed for Android or Linux environments, relying on the standard / proc process information interface and writable memory space to intercept functions. However, in HarmonyOS NEXT, the system's security sandbox mechanism, distributed memory layout, and ArkTS runtime bridging mechanism make conventional instrumentation methods ineffective in identifying cross-language call relationships and unable to trace native layer functions without compromising system security. In particular, HarmonyOS NEXT's process mapping table adopts a new address randomization strategy, making the loading base addresses of different dynamic libraries no longer fixed, causing static offset positioning to fail; simultaneously, the metadata structure injected by the ArkTS runtime at the native call bridge also changes the traditional call stack layout, making existing tools unable to correctly recover cross-layer function call chains. Summary of the Invention

[0004] Based on this, it is necessary for the present invention to provide a method and system for dynamically instrumenting HarmonyOS NEXT Native layer functions to solve at least one of the above-mentioned technical problems.

[0005] To achieve the above objectives, a method for dynamically instrumenting HarmonyOS NEXT Native layer functions includes the following steps:

[0006] Step S1: Obtain the process identifier of the target application process, and then read the corresponding memory-mapped file to obtain the loading base address and file path of the Native layer ELF shared object;

[0007] Step S2: Read the ELF file corresponding to the file path and create an index table of the objective function symbol name, PLT entry, and PLT section file offset for each entry in the PLT section;

[0008] Step S3: Add the load base address to the PLT section file offset to calculate the starting address of the PLT section memory; calculate the absolute memory address of the target function's PLT entry based on the PLT entry of the function to be intercepted in the index table;

[0009] Step S4: Deploy interception code at the absolute memory address. When the function is called, save the register state and analyze the call stack return address. When the return address is located in a dynamic library containing the ArkTS runtime identifier, it is identified as a bridged call and the ArkTS layer function information is extracted.

[0010] Step S5: Obtain the distributed and hardware context summary of the function to be intercepted based on the runtime environment, and combine the register state, ArkTS layer function information and context summary to construct a four-layer call context.

[0011] This invention also provides a system for dynamically instrumenting HarmonyOS NEXT Native layer functions, and a method for executing the aforementioned dynamically instrumented HarmonyOS NEXT Native layer functions. The system for dynamically instrumenting HarmonyOS NEXT Native layer functions includes:

[0012] The process mapping resolution module is used to obtain the process identifier of the target application process and read the memory mapping file of the process to obtain the loading base address and file path of the Native layer ELF shared object;

[0013] The ELF structure index building module is used to read the ELF file corresponding to the file path and build an index relationship table of the objective function symbol name, PLT entry, and PLT section file offset for each entry in the PLT section;

[0014] The function address calculation module is used to calculate the starting address of the PLT section memory by adding the load base address to the PLT section file offset; and to calculate the absolute memory address of the PLT entry of the function to be intercepted based on the PLT entry of the function in the index table.

[0015] The dynamic interception execution module is used to deploy interception code at the absolute memory address. When a function is called, it saves the register state and analyzes the call stack return address. When the return address is located in a dynamic library containing the ArkTS runtime identifier, it is identified as a bridged call and the ArkTS layer function information is extracted.

[0016] The multi-layer context building module is used to obtain the distributed and hardware context summary of the function to be intercepted based on the runtime environment, and combine the register state, ArkTS layer function information and context summary to build a four-layer call context.

[0017] This invention, through dynamic instrumentation and multi-layer context construction of Native layer functions during HarmonyOS NEXT runtime, enables precise capture and cross-layer tracing of function execution paths without modifying application source code, thereby significantly improving the efficiency of fault location and performance analysis. Based on process management interfaces and memory mapping information, the method automatically identifies and locates the load base address and PLT entry of the target ELF shared object, and resolves function symbols using dynamic symbol tables and string tables to reliably locate function entry points. At interception points, controlled jump replacement is used to achieve real-time acquisition of register snapshots and call stacks, accurately reconstructing the Native layer call context. Furthermore, stack backtracking identifies bridging calls in the ArkTS layer, thereby extracting upper-layer function metadata and completing semantic mapping between language layers.

[0018] This solution further integrates distributed service status and remote tracing capabilities into a unified call description. Upon detecting a distributed proxy call, it proactively exchanges execution information with remote devices, achieving time alignment and completion of cross-device call chains. Simultaneously, it monitors underlying hardware events and establishes causal relationships using timestamp thresholds, presenting application logic, runtime bridging, distributed interaction, and hardware response information in a single view. The overall implementation balances system security and stability, reducing intrusion into target processes through access control and page protection, and considering compatibility with ASLR, compressed libraries (.z.so), and multi-process scenarios, facilitating deployment in real-world projects. Ultimately, this method provides developers and operations personnel with high-precision, low-intrusion, cross-device, and cross-language debugging and analysis capabilities, significantly reducing problem localization time and improving system reliability and observability. Attached Figure Description

[0019] Other features, objects, and advantages of the invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0020] Figure 1 This is a flowchart illustrating the steps of a method for dynamically instrumenting HarmonyOS NEXT Native layer functions according to the present invention.

[0021] Figure 2 This is a schematic diagram of the call stack structure and memory mapping relationship according to an embodiment of the present invention;

[0022] Figure 3 This is a flowchart illustrating the ArkTS and Native layer bridging call identification process according to one embodiment of the present invention.

[0023] Figure 4 This is a schematic diagram of a system for dynamically instrumenting HarmonyOS NEXT Native layer functions according to the present invention. Detailed Implementation

[0024] The technical method of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0025] Furthermore, the accompanying drawings are merely illustrative of the invention and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor methods and / or microcontroller methods.

[0026] It should be understood that although the terms "first," "second," etc., may be used herein to describe various units, these units should not be limited by these terms. These terms are used merely to distinguish one unit from another. For example, without departing from the scope of the exemplary embodiments, a first unit may be referred to as a second unit, and similarly, a second unit may be referred to as a first unit. The term "and / or" as used herein includes any and all combinations of one or more of the associated listed items.

[0027] To achieve the above objectives, please refer to Figures 1 to 4 This invention provides a method for dynamically instrumenting HarmonyOS NEXT Native layer functions, the method comprising the following steps:

[0028] Step S1: Obtain the process identifier of the target application process, and then read the corresponding memory-mapped file to obtain the loading base address and file path of the Native layer ELF shared object;

[0029] Step S2: Read the ELF file corresponding to the file path and create an index table of the objective function symbol name, PLT entry, and PLT section file offset for each entry in the PLT section;

[0030] Step S3: Add the load base address to the PLT section file offset to calculate the starting address of the PLT section memory; calculate the absolute memory address of the target function's PLT entry based on the PLT entry of the function to be intercepted in the index table;

[0031] Step S4: Deploy interception code at the absolute memory address. When the function is called, save the register state and analyze the call stack return address. When the return address is located in a dynamic library containing the ArkTS runtime identifier, it is identified as a bridged call and the ArkTS layer function information is extracted.

[0032] Step S5: Obtain the distributed and hardware context summary of the function to be intercepted based on the runtime environment, and combine the register state, ArkTS layer function information and context summary to construct a four-layer call context.

[0033] Furthermore, step S1 includes the following steps:

[0034] Step S11: Query the list of currently running processes through the process management interface of the HarmonyOS NEXT system;

[0035] For example, the system service interface of HarmonyOS NEXT can be called to obtain a set of information about active processes in the system. The process information returned by this interface includes the package name, application name, process identifier, device identifier, and process type fields. When this query operation is executed, the system reads the current device's process snapshot information from the distributed task scheduling framework, obtaining a list containing application processes and system service processes. Developers can specify a query mode to obtain only processes related to user applications, thereby avoiding interference from system-level processes.

[0036] It should be noted that in multi-device collaboration scenarios, the same application may be launched on multiple devices. Therefore, the query results should be filtered in conjunction with the device identifier field to ensure that the process list only includes the target application process on the local device.

[0037] Step S12: Match the process list according to the package name or application name of the target application to obtain the corresponding process entry and extract the process identifier;

[0038] For example, if the target application's package name is com.example.cameraapp, the package name field is compared item by item in the process list. When a package name that matches the target is detected, the process entry is identified as the target process. Then, the process identifier field value is read from this entry and saved as the PID. This PID is used for subsequent access operations to memory-mapped files.

[0039] It should be noted that in the HarmonyOS NEXT system, an application may contain multiple instances such as the main process and service extension processes. Therefore, when multiple processes with the same package name are matched, the main process or a specific extension process can be filtered out as the target based on the process type field.

[0040] Step S13: Construct the path of the memory-mapped file based on the process identifier, open the memory-mapped file, and parse the contents of the memory-mapped file. Each line of content contains the memory address range, permission identifier, file offset, device number, inode number, and path field.

[0041] For example, when the target process identifier is 23104, the path " / proc / 23104 / maps" can be constructed to read the process's memory mapping information. The text content returned by the system contains multiple lines of records, each corresponding to a mapped memory region. Each region describes the start and end addresses of the memory segment, access permissions, file offset values, and the path of the mapped file. When parsing this content, each line can be separated by spaces to extract fields and obtain the required memory address and path information.

[0042] It should be noted that the process isolation mechanism of the HarmonyOS NEXT system requires that only processes with system-level debugging privileges can access the mapping information of other applications. Therefore, this step is usually performed by the analysis service or instrumentation management process with system privileges.

[0043] Step S14: Filter the rows in the memory-mapped files whose path fields end with the shared object file extension and contain native layer dynamic library characteristics, and use them as dynamic library memory-mapped entries.

[0044] In one embodiment, in the parsed path field, any record ending with ".so" or ".z.so" and containing a directory path such as " / lib / " or " / system / lib / module / " can be identified as a Native layer dynamic library mapping. Typical record paths include " / system / lib / module / libnative_engine.z.so" or " / data / storage / el2 / base / lib / libexample.so". By performing suffix judgment and directory matching on the path string, shared object files associated with Native layer code can be effectively filtered out.

[0045] It should be noted that some shared object files in the HarmonyOS NEXT system are loaded in a compressed format. Although their file extension is ".z.so", they still conform to the ELF file structure. Therefore, they should be regarded as valid Native layer dynamic libraries in the filtering logic.

[0046] Step S15: Extract the starting address of the memory address range from the dynamic library memory mapping entry as the load base address of the current ELF shared object, and use the path field in the same line as the file path of the current ELF shared object.

[0047] For example, when the memory range field of a certain mapping record is "0x74a0f000-0x74c1a000", the permission identifier is "r-xp", and the path field is " / system / lib / module / libnative_engine.z.so", the starting address 0x74a0f000 can be resolved to the load base address of the shared object in the memory space, and its path information can be recorded for subsequent ELF file structure analysis.

[0048] It should be noted that the HarmonyOS NEXT system enables a randomized address loading mechanism for shared object files during process startup. Therefore, the base address of the same dynamic library will be different each time it runs. To ensure the accuracy of instrumentation operations, this load base address must be extracted from the memory mapping information of the current process in real time, and cannot rely on static offsets or preset addresses.

[0049] Furthermore, step S2 includes the following steps:

[0050] Step S21: Read the ELF file corresponding to the file path and read the file header data. Extract the starting position value of the section header table from the file header data, locate and read the section header table data according to the starting position value of the section header table;

[0051] In one embodiment, the file content pointed to by the ELF shared object file path obtained in step S15 is read through the file input interface. First, the file header of the ELF file is read. The file header, typically located at the beginning of the file, contains key information about the file's structure and layout. By parsing the "section header table offset" field value in the file header, the starting position of the section header table in the file can be determined. The program then jumps to the section header table location based on this offset and reads the complete section header table data, laying the foundation for subsequent searches of specific section information.

[0052] For example, when the file header indicates a section header table offset of 0x200, the system will sequentially read the section header table data starting from position 0x200 of the file for subsequent section location.

[0053] Step S22: Traverse the section header table data to find the section description information whose section name field value is the PLT section identifier, extract the file offset field value from the section description information, and record it as the PLT section file offset value;

[0054] In one embodiment, the read section header table data is traversed. Each section header table entry describes the basic attributes of a section, including section name, type, file offset, section size, etc. During the traversal, the program determines the section type based on the section name field. When the section name field value is "PLT" or ".plt", the section is confirmed to be a Procedure Link Table (PLT) section. The program then extracts the file offset field value of the section and records it as the PLT section file offset value.

[0055] For example, if a section with the name field ".plt" is found in the section header table and its file offset field value is 0x4000, then the file offset value of the PLT section is 0x4000.

[0056] Step S23: Traverse the section header table data and find the section description information where the section name field value is the dynamic symbol table identifier and the string table identifier respectively. Extract the file offset field value from these two section description information and record them as the dynamic symbol table file offset value and the string table file offset value respectively.

[0057] In one embodiment, the program continues to traverse the section header table data, searching for sections with section name fields of ".dynsym" and ".strtab". The ".dynsym" section represents the dynamic symbol table, used to store metadata information for symbol entries, while the ".strtab" section represents the string table, used to store string data for symbol names. After identifying the corresponding sections, the program extracts the file offset field values ​​of both sections and records them as the dynamic symbol table file offset value and the string table file offset value, respectively.

[0058] For example, if the dynamic symbol table offset is 0x6000 and the string table offset is 0x8000, these two offsets will be used for subsequent symbol-to-name mapping.

[0059] Furthermore, step S2 also includes the following steps:

[0060] Step S24: Locate the starting position of the PLT section in the file according to the PLT section file offset value and read the PLT data. Parse and identify the boundary position of each entry according to the fixed byte length of the PLT section entry and assign a sequence number value to each entry to obtain an entry list containing entry data and entry number values.

[0061] In one embodiment, the starting position of the PLT section is located in the ELF file based on the PLT section file offset value, and the PLT section data is read sequentially. The PLT section consists of multiple fixed-length entries, each corresponding to a jump entry for a dynamic function call. The system parses the read data in segments according to a preset entry length (e.g., 16 bytes or 32 bytes), identifies entry boundaries one by one, and assigns a consecutive number value to each entry, thereby forming an entry list containing entry numbers and entry data.

[0062] For example, if the PLT section is 512 bytes long and each entry is 16 bytes, then a total of 32 entries numbered from 0 to 31 can be generated.

[0063] Step S25: Parse the symbol table index value of the jump instruction byte sequence in the entry list;

[0064] In one embodiment, each entry in the entry list is disassembled or its instruction sequence analyzed to identify the jump instruction byte sequence. Jump instructions typically contain an immediate value parameter or register offset pointing to a symbol table index. The program extracts the symbol table index value corresponding to each entry by performing pattern matching and numerical decoding on these byte sequences.

[0065] For example, under the aarch64 architecture of the HarmonyOS NEXT system, a typical PLT jump instruction sequence might be "ADR X16,#offset;BR X17", and the system can parse its symbol table index value as 0x12 based on the offset parameter.

[0066] Step S26: Locate the dynamic symbol table based on the offset value of the dynamic symbol table file and use the symbol table index value to find the corresponding symbol entry data.

[0067] In one embodiment, using the symbol table index value obtained in the previous step, and based on the dynamic symbol table file offset value obtained in step S23, the dynamic symbol table region is located in the ELF file. Then, the corresponding symbol entry data is read according to the fixed structure of the symbol table entries. Each symbol entry data includes fields such as symbol name offset, symbol value, symbol size, and binding type. The program extracts and caches this data for subsequent name resolution.

[0068] Furthermore, step S2 also includes the following steps:

[0069] Step S27: Extract the name offset field value from the symbol entry data to obtain a list of name offset values ​​for each entry;

[0070] In one embodiment, the name offset field value of each entry is obtained from the extracted symbol entry data, and recorded sequentially to form a list of name offset values. Each value in this list represents the starting position of the corresponding symbol name in the string table.

[0071] For example, if the name offsets of the three symbol entries are 0x10, 0x50, and 0x90 respectively, the system will record them as [0x10, 0x50, 0x90] for subsequent string positioning.

[0072] Step S28: Locate the string table based on the file offset value and name offset value list, locate each name offset value in the string table and read the string data ending with a null character to obtain the function symbol name string list corresponding to each entry;

[0073] In one embodiment, based on the string table file offset value obtained in step S23, the system locates the string table position in the ELF file and, combined with the name offset value list in step S27, calculates the absolute position of each symbol name in the file one by one. The program then reads character data from each position until it encounters a null character (\0), forming a complete function symbol name string.

[0074] For example, if the string corresponding to offset 0x50 is "_Z10initModulev", the system will resolve the name to the function name corresponding to the symbol index.

[0075] Step S29: Combine the list of function symbol name strings, the corresponding list of entries, and the PLT section file offset values ​​into an index record containing a symbol name field, an entry number field, and a file offset field, and summarize them to form an index relationship table.

[0076] In one embodiment, the function symbol name string obtained in step S28 is associated with the entry list generated in step S24 and the PLT section file offset value determined in step S22. The system generates an index record for each function name, which includes a symbol name field, a corresponding PLT entry number field, and a file offset field. All index records are summarized to form an index relationship table, which is used to realize the correspondence between dynamic function symbols in the ELF file and memory jump table entries.

[0077] For example, the indexed relation table may contain records similar to {function name: "printf", entry number: 2, file offset: 0x4020}.

[0078] Furthermore, step S3 includes the following steps:

[0079] Step S31: Add the load base address to the PLT section file offset to calculate the starting address of the PLT section in the target process's memory space;

[0080] In one embodiment, after obtaining the ELF shared object load base address determined in step S15 and the PLT section file offset extracted in step S22, the system calculates the starting address of the PLT section in the target process's virtual memory space by adding the two values. This starting address is used to locate the process link table region within the process and is the basis for subsequent function interception operations.

[0081] For example, if the shared object load base address is 0x7F000000 and the PLT section file offset is 0x4000, then the calculated starting address of the PLT section in the process memory is 0x7F004000.

[0082] Step S32: Search for the index record in all index records of the index relationship table whose symbol name field value matches the string of the symbol name of the function to be intercepted, and obtain the index record data;

[0083] In one embodiment, the symbol name field of all index records in the index relationship table is matched. Specifically, the program uses the symbol name string of the target interception function (e.g., "connect" or "sendto") as a key to compare the symbol name field stored in the index table. When an index record is found whose symbol name field value is exactly the same as the target string, it is determined that the record is the index record data corresponding to the function to be intercepted.

[0084] For example, if the objective function is "sendto", the system finds the record {symbol name: "sendto", entry number: 5, file offset: 0x4080} in the index table, and then extracts the data from this record as input for subsequent operations.

[0085] Step S33: Extract the entry number field value from the index record data, and multiply the entry number field value with the fixed byte length value of a single PLT entry to output the offset value of the PLT entry of the function to be intercepted relative to the start position of the PLT section;

[0086] In one embodiment, the system extracts the entry number field value from the index record data obtained in step S32. This entry number value represents the sequence position of the target function in the PLT section. Subsequently, the system performs a multiplication operation between the entry number value and the byte length according to the fixed byte length parameter (e.g., 16 bytes or 32 bytes) of a single entry in the PLT section to calculate the offset value of the target function PLT entry relative to the starting address of the PLT section.

[0087] For example, if the entry number is 5 and the length of a single PLT entry is 16 bytes, the calculation result is 5 × 16 = 80 (decimal), which is the offset value of 0x50.

[0088] Step S34: Add the starting address value and the offset value to obtain the absolute memory address value of the PLT entry of the function to be intercepted.

[0089] In one embodiment, the starting address of the PLT section in the process memory space calculated in step S31 is added to the target entry offset obtained in step S33 to obtain the absolute memory address of the function's PLT entry. This address is the jump entry point of the target function in the current process and can be used as the target of interception or redirection operations.

[0090] For example, if the starting address of the PLT section is 0x7F004000 and the offset value is 0x50, then the absolute memory address of the PLT entry of the function to be intercepted is 0x7F004050.

[0091] Of particular importance, step S34 is followed by:

[0092] Read several consecutive bytes of machine code data from the memory location pointed to by the absolute memory address value, verify whether the machine code data conforms to the standard jump instruction format of the PLT entry, mark the absolute memory address value as a valid interception point and output it for subsequent interception code deployment, and record the error information and terminate the instrumentation operation of the function when the verification fails.

[0093] Furthermore, step S4 includes the following steps:

[0094] Step S41: Write a jump instruction to the memory location pointed to by the absolute memory address value to complete the deployment of the interception code, wherein the jump instruction points to the entry address of the pre-prepared interception processing function;

[0095] In one embodiment, the absolute memory address of the PLT entry of the function to be intercepted, calculated in step S34, is used as the writing target location through the process memory access interface provided by HarmonyOS NEXT. The program overwrites this address with a jump instruction to redirect the call flow, which originally pointed to the function implementation body, to the entry address of a custom interception processing function. The written jump instruction can adopt a corresponding format according to the system architecture (such as aarch64), for example, a direct jump operation in the form of "B" or "BL".

[0096] For example, when the entry address of the interception handling function is 0x7F050000, the system writes the instruction "B0x7F050000" at the PLT entry, thereby causing the target function call to be redirected to execute the interception logic.

[0097] It should be noted that, to ensure system stability, the target memory page should be modified to a writable state through page protection control before writing, and then restored to read-only attribute after the operation is completed.

[0098] Step S42: When the function to be intercepted is called, the execution flow jumps to the interception handling function. At the entry point of the interception handling function, the values ​​of all registers used by the current thread are read to obtain the register status data.

[0099] In one embodiment, when the application calls the redirected target function during runtime, the program flow automatically jumps to the interception handling function deployed in step S41. At its entry point, the interception handling function first reads the register contents of the current thread context through the system call interface or inline assembly instructions, including general-purpose registers, stack pointer register (SP), frame pointer register (FP), etc., and temporarily stores these values ​​as register state data for subsequent call stack analysis.

[0100] For example, if a thread is currently in the process of function A calling function B, then the values ​​of SP and FP will correspond to the stack start position of the function B call frame and the link position of the upper-level call frame, respectively.

[0101] Step S43: Extract the values ​​of the stack pointer register and the frame pointer register from the register status data to locate the top position of the current call stack;

[0102] In one embodiment, the system locates the register values ​​of SP (Stack Pointer) and FP (Frame Pointer) in the register status data. The SP register points to the top of the current call stack, while the FP register points to the reference position of the current stack frame. By extracting the values ​​of these two registers, the system can accurately determine the structural range of the current call frame in memory, providing a starting reference for subsequent backtracking of the upper-level call stack.

[0103] For example, if the SP register value is 0x7FFD1000 and the FP register value is 0x7FFD1080, the system determines that the memory range occupied by the current call frame is from 0x7FFD1000 to 0x7FFD1080.

[0104] Step S44: Starting from the memory location pointed to by the top of the stack, traverse upwards according to the standard structure of the call frame, and read the return address value stored in each call frame in turn to obtain the return address list;

[0105] In one embodiment, based on the current frame pointer position determined in step S43, the program traverses the previous call frames sequentially upwards according to the standard layout rules of function call frames in the system stack. Each call frame typically stores the FP value of the previous frame and the return address of the called function. The program reads these return address fields layer by layer and summarizes the results to form a return address list. This list reflects the complete call path from the current function to the parent function.

[0106] For example, if the traversal results in the return addresses [0x4008A0, 0x401230, 0x402150], it means that the current function was indirectly triggered by the caller at address 0x4008A0.

[0107] It should be noted that, in order to prevent misreading or out-of-bounds access, the system should determine the termination condition of the stack frame linked list during traversal, and stop immediately if the FP value is abnormal or exceeds the stack boundary.

[0108] Step S45: When the return address in the return address list is located in a dynamic library containing the ArkTS runtime identifier, it is identified as a bridged call and the ArkTS layer function information is extracted.

[0109] In one embodiment, the list of return addresses obtained in step S44 is analyzed one by one, and each return address is mapped to a memory-mapped file path to determine the module origin of the address. When a return address is detected to fall within the path field containing "libark_jsruntime.so" or other dynamic library address ranges identified by the ArkTS runtime, it can be determined that the current call belongs to a bridged call triggered by the ArkTS layer. At this time, the system further parses the symbol information of the call frame in the runtime stack and extracts the corresponding ArkTS layer function name and call context data.

[0110] For example, when the return address 0x401230 is located in the range " / system / lib64 / libark_jsruntime.so", the system can find out from the symbol table that the call originated from the ArkTS function "handleNetworkRequest()", thereby achieving an accurate mapping of the upper-level logical call chain.

[0111] See Figure 2This diagram illustrates the structure of the runtime call stack and its correspondence with memory-mapped regions. In the specific implementation, a thread sequentially forms multiple call frames during execution. Each call frame stores information such as the frame pointer (FP) of the current function, its return address, and local variables. For example, the FP of the current frame is 0x7FFD1000, and the corresponding return address is 0x4008A0; its upper-level frame is a native layer function, with an FP of 0x7FFD1080 and a return address of 0x401230; the frame above that is the ArkTS runtime frame, with an FP of 0x7FFD1100 and a return address of 0x402150.

[0112] Each call frame is cascaded through a call chain to form a complete stack call chain structure. When the system performs a return operation, the program will backtrack sequentially according to the return address recorded in each frame.

[0113] like Figure 2 As shown, there is a one-to-one correspondence between the call stack region and the memory-mapped region. The memory-mapped region includes two types of dynamic link library files: libark_jsruntime.so and libnative.so. The former corresponds to the ArkTS runtime module, and the latter corresponds to the native layer module. By mapping the return address to the memory-mapped path, the module to which the call frame belongs can be accurately located, providing basic data for subsequent bridging function identification.

[0114] Furthermore, step S45 includes the following steps:

[0115] Step S451: Based on the list of return addresses, find the memory region to which the return address value belongs in the memory-mapped file, and extract the path field value from the description information of the memory region to generate a dynamic library path list;

[0116] In one embodiment, the program queries the target process's memory-mapped file (such as / proc / ). <pid>The system retrieves the start and end address ranges of all current memory segments and their corresponding path field descriptions using the ` / maps` function. Then, it iterates through these memory segment ranges, comparing each return address with the specified range. If a return address falls within the address range of a memory segment, it indicates that the code segment to which that return address belongs is located within that memory-mapped region. Subsequently, the program extracts the path field values, such as dynamic library file paths, from the description information corresponding to that memory region and records the results in the dynamic library path list.

[0117] For example, if the return address 0x7F4123A0 is located in the memory segment [0x7F410000, 0x7F420000], and the corresponding path of the memory segment is " / system / lib64 / libark_jsruntime.so", then the system adds the path to the dynamic library path list.

[0118] Step S452: Traverse each path character in the dynamic library path list, check whether the path string contains the characteristic keywords of ArkTS runtime, and when a path string containing the characteristic keywords is found, mark the return address corresponding to the path as the bridge call return address, and obtain the bridge call identifier and the bridge call return address value.

[0119] In one embodiment, the system traverses the list of dynamic library paths and performs content matching analysis on each path string. The program predefines a set of characteristic keywords for ArkTS runtime modules, such as "ark_jsruntime", "arkcompiler", "libark_ts", and "libark_runtime". During the traversal, the system sequentially checks whether each path string contains these keywords. When any one of these characteristic keywords is detected in a path string, the system determines that the return address corresponding to that path belongs to an ArkTS runtime module. At this point, the system generates a bridging call identifier for that return address and marks it as a bridging call return address.

[0120] For example, when the dynamic library path " / system / lib64 / libark_jsruntime.so" contains the keyword "ark_jsruntime", the system marks the corresponding return address 0x7F4123A0 as the bridged call return address.

[0121] Step S453: When a bridge call identifier exists, locate the ArkTS layer call frame in the call stack according to the bridge call return address value, read the metadata information of the ArkTS function from the memory area of ​​the call frame, and obtain the ArkTS layer function information containing the ArkTS function name string and parameter type descriptor.

[0122] In one embodiment, when a bridge call identifier is detected, the system uses the marked bridge call return address value to reverse-locate the memory region of the call frame containing it within the call stack structure. Subsequently, the program reads the metadata information of the ArkTS layer function within the memory space of that frame. This information is typically stored in a runtime-maintained function context structure and includes data such as a pointer to the function name string, parameter type descriptors, and return value type identifiers. After parsing these fields, the program can reconstruct the function information of the ArkTS layer.

[0123] For example, when the function name pointer stored in the memory area of ​​the call frame corresponding to the bridge call return address 0x7F4123A0 points to the string "onConnect" and the parameter type descriptor is "(String, Number)", the system can generate an ArkTS function information record containing the function name "onConnect" and parameter type description information.

[0124] See Figure 3 This embodiment demonstrates a process for identifying bridged calls between ArkTS and the Native layer based on return addresses. After the process begins, the system first obtains a list of return addresses in the current call stack; then, it queries the memory mapping path based on the return address. When the mapping path contains an ArkTS runtime identifier (e.g., the path contains features such as "libark_jsruntime.so"), the call is determined to be a bridged call; if the path does not contain this identifier, it is determined to be a non-bridged call.

[0125] For cases identified as bridged calls, the system further extracts the symbol information and associated call parameters of the ArkTS layer functions to establish a cross-language function call relationship mapping table, enabling dynamic analysis and tracing of the interaction between the ArkTS and Native layers. This process can automatically identify cross-layer call relationships without modifying the target process, through stack backtracking and memory mapping matching techniques, improving the accuracy and automation of dynamic instrumentation and function tracing.

[0126] Furthermore, step S5 includes the following steps:

[0127] Step S51: Determine the call type of the function to be intercepted based on the current distributed service status of the process;

[0128] In one embodiment, the distributed service framework interface provided by the HarmonyOS NEXT operating system is first used to query the distributed running status of the current process to determine whether the current function call involves cross-device or remote proxy. Specifically, the program reads the distributed task identifier (such as the session ID or distributed task flag of DSoftBus) from the process context and combines it with the context information of the function execution thread to determine whether the call belongs to a distributed remote call, a cross-process call, or a purely local call.

[0129] For example, when the execution thread of a function is bound to the distributed identifier "Session_ark_1234", the system recognizes that the function call originates from the remote proxy mechanism of the ArkTS runtime, and thus marks the call type as "distributed proxy call"; while when the thread context does not contain any distributed flags, the call type is determined to be "local call".

[0130] Step S52: Combine the register state and ArkTS layer function information with the call type to construct a unified call description;

[0131] In one embodiment, after identifying the call type, the register status data, ArkTS layer function information, and call type are combined to form a unified call description structure. This structure is used to transmit call information in different call relationships, including fields such as function name, call entry time, register snapshot, call stack depth, ArkTS function name and parameter description, and distributed identifier.

[0132] For example, if the register status records the values ​​of the current CPU general-purpose registers R0-R15, the ArkTS function information records the function name "onMessageReceived" and the parameter type descriptor "(String)", and the call type is a distributed proxy call, then the system will assemble these fields into a unified call description record for subsequent tracking and matching operations.

[0133] Step S53: When the call type is a distributed proxy call, send a tracing request containing the current function name and call timestamp to the remote device, receive the remote function execution status and parameter values ​​returned by the remote device, and complete the unified call description by aligning the local call information with the remote call information according to the timestamp.

[0134] In one embodiment, when the call type is identified as a distributed proxy call, the system sends a tracing request to the remote device through a distributed communication interface. This request data packet includes the name of the current function, the call timestamp, the calling thread identifier, and a unique device identifier. Upon receiving the tracing request, the remote device extracts the execution status, parameter values, and return timestamp of the corresponding function from its own distributed service runtime environment and sends this information back to the initiating end. Upon receiving the returned data, the initiating end compares and aligns the remote execution record with the local call description by timestamp field, thereby generating complete call chain information across devices.

[0135] For example, when the local function "sendToRemoteDevice()" is called at timestamp 16235000, and the remote device records the execution status of the function "onRemoteMessage()" at timestamp 16235005, the system automatically matches the two based on the timestamp difference to form a complete distributed call record.

[0136] Step S54: Listen to underlying hardware events and compare the timestamps of the unified call description. When the time difference is less than a preset threshold, establish a causal relationship between the function call and the hardware event, and output a four-layer call context including the Native layer, ArkTS layer, distributed layer and hardware layer.

[0137] In one embodiment, after establishing a unified call description, the system further monitors hardware events related to function execution, such as sensor triggers, interrupt responses, GPU rendering startup, and network transmission / reception events, through the HarmonyOS NEXT underlying hardware event subscription interface. When the system detects a hardware event, it records the event's trigger timestamp and compares it with the call timestamp in the unified call description. When the time difference is less than a preset threshold (e.g., 5 milliseconds), it is determined that the function call and the corresponding hardware event are causally related. Based on this, the system combines the Native layer function call, the ArkTS layer bridge call, the distributed proxy execution, and the hardware event to output a complete four-layer call context.

[0138] For example, when a Native layer function "StartCameraStream()" is called, and a startup interruption event of the camera hardware is detected within 3 milliseconds, the system establishes a correspondence of "function call - distributed task - ArkTS logic - hardware response" in the four-layer context.

[0139] See Figure 4 The present invention also provides a system 100 for dynamically instrumenting HarmonyOS NEXT Native layer functions, and a method for executing the aforementioned method for dynamically instrumenting HarmonyOS NEXT Native layer functions. The system 100 for dynamically instrumenting HarmonyOS NEXT Native layer functions includes:

[0140] The process mapping resolution modulo 101 is used to obtain the process identifier of the target application process, thereby reading the corresponding memory-mapped file to obtain the loading base address and file path of the Native layer ELF shared object;

[0141] ELF structure index building module 102 is used to read the ELF file corresponding to the file path and build an index relationship table of the objective function symbol name, PLT entry, and PLT section file offset for each entry in the PLT section;

[0142] The function address calculation module 103 is used to calculate the starting address of the PLT section memory by adding the load base address to the PLT section file offset; and to calculate the absolute memory address of the target function's PLT entry based on the PLT entry of the function to be intercepted in the index table.

[0143] The dynamic interception execution module 104 is used to deploy interception code at the absolute memory address. When a function is called, it saves the register state and analyzes the call stack return address. When the return address is located in a dynamic library containing the ArkTS runtime identifier, it is identified as a bridged call and the ArkTS layer function information is extracted.

[0144] The multi-layer context building module 105 is used to obtain the distributed and hardware context summary of the function to be intercepted based on the runtime environment, and combine the register state, ArkTS layer function information and context summary to build a four-layer call context.

[0145] Therefore, the embodiments should be considered as exemplary and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of the equivalents of the application are intended to be included within the invention.

[0146] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features of the invention herein.< / pid>

Claims

1. A method for dynamically instrumenting HarmonyOS NEXT Native layer functions, characterized in that, Includes the following steps: Step S1: Obtain the process identifier of the target application process, and then read the corresponding memory-mapped file to obtain the loading base address and file path of the Native layer ELF shared object; Step S2: Read the ELF file corresponding to the file path and create an index table of the objective function symbol name, PLT entry, and PLT section file offset for each entry in the PLT section; Step S3: Add the load base address to the PLT section file offset to calculate the starting address of the PLT section memory; calculate the absolute memory address of the target function's PLT entry based on the PLT entry of the function to be intercepted in the index table; Step S4: Deploy interception code at the absolute memory address. When the function is called, save the register state and analyze the call stack return address. When the return address is located in a dynamic library containing the ArkTS runtime identifier, it is identified as a bridged call and the ArkTS layer function information is extracted. Step S5: Obtain the distributed and hardware context summary of the function to be intercepted based on the runtime environment, and combine the register state, ArkTS layer function information and context summary to construct a four-layer call context.

2. The method for dynamically instrumenting HarmonyOS NEXT Native layer functions according to claim 1, characterized in that, Step S1 includes the following steps: Step S11: Query the list of currently running processes through the process management interface of the HarmonyOS NEXT system; Step S12: Match the process list according to the package name or application name of the target application to obtain the corresponding process entry and extract the process identifier; Step S13: Construct the path of the memory-mapped file based on the process identifier, open the memory-mapped file, and parse the contents of the memory-mapped file. Each line of content contains the memory address range, permission identifier, file offset, device number, inode number, and path field. Step S14: Filter the rows in the memory-mapped files whose path fields end with the shared object file extension and contain native layer dynamic library characteristics, and use them as dynamic library memory-mapped entries. Step S15: Extract the starting address of the memory address range from the dynamic library memory mapping entry as the load base address of the current ELF shared object, and use the path field in the same line as the file path of the current ELF shared object.

3. The method for dynamically instrumenting HarmonyOS NEXT Native layer functions according to claim 2, characterized in that, Step S2 includes the following steps: Step S21: Read the ELF file corresponding to the file path and read the file header data. Extract the starting position value of the section header table from the file header data, locate and read the section header table data according to the starting position value of the section header table; Step S22: Traverse the section header table data to find the section description information whose section name field value is the PLT section identifier, extract the file offset field value from the section description information, and record it as the PLT section file offset value; Step S23: Traverse the section header table data and find the section description information where the section name field value is the dynamic symbol table identifier and the string table identifier respectively. Extract the file offset field value from these two section description information and record them as the dynamic symbol table file offset value and the string table file offset value respectively.

4. The method for dynamically instrumenting HarmonyOS NEXT Native layer functions according to claim 3, characterized in that, Step S2 also includes the following steps: Step S24: Locate the starting position of the PLT section in the file according to the PLT section file offset value and read the PLT data. Parse and identify the boundary position of each entry according to the fixed byte length of the PLT section entry and assign a sequence number value to each entry to obtain an entry list containing entry data and entry number values. Step S25: Parse the symbol table index value of the jump instruction byte sequence in the entry list; Step S26: Locate the dynamic symbol table based on the offset value of the dynamic symbol table file and use the symbol table index value to find the corresponding symbol entry data.

5. The method for dynamically instrumenting HarmonyOS NEXT Native layer functions according to claim 4, characterized in that, Step S2 also includes the following steps: Step S27: Extract the name offset field value from the symbol entry data to obtain a list of name offset values ​​for each entry; Step S28: Locate the string table based on the file offset value and name offset value list, locate each name offset value in the string table and read the string data ending with a null character to obtain the function symbol name string list corresponding to each entry; Step S29: Combine the list of function symbol name strings, the corresponding list of entries, and the PLT section file offset values ​​into an index record containing a symbol name field, an entry number field, and a file offset field, and summarize them to form an index relationship table.

6. The method for dynamically instrumenting HarmonyOS NEXT Native layer functions according to claim 5, characterized in that, Step S3 includes the following steps: Step S31: Add the load base address to the PLT section file offset to calculate the starting address of the PLT section in the target process's memory space; Step S32: Search for the index record in all index records of the index relationship table whose symbol name field value matches the string of the symbol name of the function to be intercepted, and obtain the index record data; Step S33: Extract the entry number field value from the index record data, and multiply the entry number field value with the fixed byte length value of a single PLT entry to output the offset value of the PLT entry of the function to be intercepted relative to the start position of the PLT section; Step S34: Add the starting address value and the offset value to obtain the absolute memory address value of the PLT entry of the function to be intercepted.

7. The method for dynamically instrumenting HarmonyOS NEXT Native layer functions according to claim 6, characterized in that, Step S4 includes the following steps: Step S41: Write a jump instruction to the memory location pointed to by the absolute memory address value to complete the deployment of the interception code, wherein the jump instruction points to the entry address of the pre-prepared interception processing function; Step S42: When the function to be intercepted is called, the execution flow jumps to the interception handling function. At the entry point of the interception handling function, the values ​​of all registers used by the current thread are read to obtain the register status data. Step S43: Extract the values ​​of the stack pointer register and the frame pointer register from the register status data to locate the top position of the current call stack; Step S44: Starting from the memory location pointed to by the top of the stack, traverse upwards according to the standard structure of the call frame, and read the return address value stored in each call frame in turn to obtain the return address list; Step S45: When the return address in the return address list is located in a dynamic library containing the ArkTS runtime identifier, it is identified as a bridged call and the ArkTS layer function information is extracted.

8. The method for dynamically instrumenting HarmonyOS NEXT Native layer functions according to claim 7, characterized in that, Step S45 includes the following steps: Step S451: Based on the list of return addresses, find the memory region to which the return address value belongs in the memory-mapped file, and extract the path field value from the description information of the memory region to generate a dynamic library path list; Step S452: Traverse each path character in the dynamic library path list, check whether the path string contains the characteristic keywords of ArkTS runtime, and when a path string containing the characteristic keywords is found, mark the return address corresponding to the path as the bridge call return address, and obtain the bridge call identifier and the bridge call return address value. Step S453: When a bridge call identifier exists, locate the ArkTS layer call frame in the call stack according to the bridge call return address value, read the metadata information of the ArkTS function from the memory area of ​​the call frame, and obtain the ArkTS layer function information containing the ArkTS function name string and parameter type descriptor.

9. The method for dynamically instrumenting HarmonyOS NEXT Native layer functions according to claim 8, characterized in that, Step S5 includes the following steps: Step S51: Determine the call type of the function to be intercepted based on the current distributed service status of the process; Step S52: Combine the register state and ArkTS layer function information with the call type to construct a unified call description; Step S53: When the call type is a distributed proxy call, send a tracing request containing the current function name and call timestamp to the remote device, receive the remote function execution status and parameter values ​​returned by the remote device, and complete the unified call description by aligning the local call information with the remote call information according to the timestamp. Step S54: Listen to underlying hardware events and compare the timestamps of the unified call description. When the time difference is less than a preset threshold, establish a causal relationship between the function call and the hardware event, and output a four-layer call context including the Native layer, ArkTS layer, distributed layer and hardware layer.

10. A system for dynamically instrumenting HarmonyOS NEXT Native layer functions, characterized in that, The system for executing the method of dynamically instrumenting HarmonyOS NEXT Native layer functions as described in claim 1, wherein the system for dynamically instrumenting HarmonyOS NEXT Native layer functions comprises: The process mapping resolution module is used to obtain the process identifier of the target application process, thereby reading the corresponding memory-mapped file to obtain the loading base address and file path of the Native layer ELF shared object; The ELF structure index building module is used to read the ELF file corresponding to the file path and build an index relationship table of the objective function symbol name, PLT entry, and PLT section file offset for each entry in the PLT section; The function address calculation module is used to calculate the starting address of the PLT section memory by adding the load base address to the PLT section file offset; and to calculate the absolute memory address of the target function's PLT entry based on the PLT entry of the function to be intercepted in the index table. The dynamic interception execution module is used to deploy interception code at the absolute memory address. When a function is called, it saves the register state and analyzes the call stack return address. When the return address is located in a dynamic library containing the ArkTS runtime identifier, it is identified as a bridged call and the ArkTS layer function information is extracted. The multi-layer context building module is used to obtain the distributed and hardware context summary of the function to be intercepted based on the runtime environment, and combine the register state, ArkTS layer function information and context summary to build a four-layer call context.

Images