Decoding method and decoding apparatus

Abstract

The application provides a decoding method and a decoding device. The method comprises the following steps: determining a plurality of packet stream boundary packets from processor tracking data, wherein the processor tracking data comprises the plurality of packet stream boundary packets and a plurality of data packets; determining M data packet groups according to the plurality of packet stream boundary packets, wherein the M data packet groups comprise the plurality of data packets, one data packet group comprises data packets located between two different packet stream boundary packets, and different data packet groups comprise different data packets, wherein M is greater than or equal to 2 and M is an integer; and decoding the M data packet groups by using N decoding threads, wherein each decoding thread in the N decoding threads decodes at least one data packet group in the M data packet groups, and different decoding threads in the N decoding threads decode different data packet groups, wherein N is greater than or equal to 2 and N is an integer. According to the application, the decoding efficiency of the processor tracking data can be improved.

Description

Technical Field

[0001] This application relates to the field of communications, and more specifically, to a decoding method and decoding apparatus. Background Technology

[0002] A key approach to countering code attacks is control flow integrity (CFI). Two prerequisites for applying CFI are: 1) the ability to obtain an accurate execution instruction stream; and 2) the ability to quickly obtain the execution instruction stream.

[0003] To facilitate the application of CFI (Complete Processing Flow), Intel processor trace (PT) hardware was developed. Intel PT hardware's efficient processor tracing mechanism can accurately record the complete processor execution instruction flow with an additional performance overhead of no more than 5%. This makes fine-grained (full path detection), difficult to bypass (no false negatives), and reliable (no false positives) offline detection of exploits targeting code reuse attacks possible. Offline detection involves recording the complete execution flow and then performing post-event detection by replaying the execution process.

[0004] However, Intel PT hardware only addresses the challenge of fast recording. Decoding highly compressed PT data incurs significant overhead, and greatly reducing the decoding overhead remains a huge challenge. Summary of the Invention

[0005] This application provides a decoding method that can improve decoding efficiency.

[0006] In a first aspect, a decoding method is provided, comprising: determining multiple packet flow boundary packets from processor tracking data, the processor tracking data including the multiple packet flow boundary packets and multiple data packets; determining M data packet groups based on the multiple packet flow boundary packets, the M data packet groups including the multiple data packets, wherein the data packets in a data packet group are located between two different packet flow boundary packets, and different data packet groups include different data packets, wherein M≥2 and M is an integer; and using N decoding threads to decode the M data packet groups, each of the N decoding threads decoding at least one data packet group in the M data packet groups, and different decoding threads of the N decoding threads decoding different data packet groups, wherein N≥2 and N is an integer.

[0007] Based on the above technical solution, processor tracing data is divided into multiple data packet groups according to the packet flow boundary packets. This allows multiple decoding threads to decode the data packet groups, thereby improving the decoding speed of processor tracing data. Furthermore, since the packet flow boundary packets can be used to identify the boundaries of fixed-length data packets, grouping processor tracing data according to the packet flow boundary packets is easier to implement and results in higher processing efficiency for processor tracing data grouping.

[0008] For example, a packet group may include packets located between two adjacent packets from different packet stream boundaries.

[0009] In conjunction with the first aspect, in some implementations of the first aspect, the method further includes: during the process of the target program obtaining the processor tracing data by rendering a file, collecting additional information to assist in decoding the processor tracing data, the additional information including one or more of the following information loaded by the process of the target program: dynamic library metadata, the modified memory portion of the modified dynamic library, and data memory with execution permissions; the method of using N decoding threads to decode the M data packet groups includes: using the N decoding threads to decode the M data packet groups in conjunction with the additional information.

[0010] The dynamic library metadata includes both unmodified dynamic library metadata and modified dynamic library metadata.

[0011] Based on the above technical solution, during the process of obtaining processor tracking data, additional information for assisting decoding is collected, and the processor tracking data is decoded in combination with this additional information, thereby ensuring that the processor tracking data is correctly decoded.

[0012] Specifically, in conjunction with this additional information, the N decoding threads are used to decode the M data packet groups, including: combining the additional information and the target program's library binary file to determine the binary file corresponding to the target program's loading process; and using the N decoding threads to decode the M data packet groups based on the binary file.

[0013] It's understandable that when a target program runs on different operating systems, the operating system's mechanisms may cause some bytes of the dynamic library to be replaced, or new dynamic libraries to be loaded. In this case, if processor trace data is still decoded based on the target program's library binary file, correct decoding of the processor trace data cannot be guaranteed. Therefore, by combining additional information to determine the binary file corresponding to the target program's loading process, correct decoding of the processor trace data can be guaranteed.

[0014] In conjunction with the first aspect, in some implementations of the first aspect, the process of each decoding thread decoding a data packet group includes: determining at least one segment based on the target instruction pointer packet in the data packet group, the at least one segment including a first type segment, the first data packet of the first type segment being a target instruction pointer packet, and the number of target instruction pointer packets in the first type segment being 1; calculating the initial instruction pointer of the first type segment based on the target instruction pointer packet in the first type segment; and determining whether to perform block-level decoding or instruction-level decoding on the first type segment based on the initial instruction pointer of the first type segment.

[0015] For example, if the initial instruction pointer of the first type segment is within the decoding range, then the first type segment is subjected to block-level decoding or instruction-level decoding; if the initial instruction pointer of the first type segment is not within the decoding range, then the first type segment is not subjected to block-level decoding or instruction-level decoding.

[0016] Optionally, if there are data packets of other types besides the target instruction pointer packet before the first target instruction pointer packet of the data packet group, the at least one segment further includes a second type segment, which includes the data packets preceding the first target instruction pointer packet; the method further includes: calculating an initial instruction pointer for the second type segment based on the packet flow boundary packet preceding and adjacent to the second type segment; and determining whether to perform block-level decoding or instruction-level decoding on the second type segment based on the initial instruction pointer of the second type segment.

[0017] For example, if the initial instruction pointer of the second type segment is within the decoding range, then the second type segment is subjected to block-level decoding or instruction-level decoding; if the initial instruction pointer of the second type segment is not within the decoding range, then the second type segment is not subjected to block-level decoding or instruction-level decoding.

[0018] Based on the above technical solution, in the process of each decoding thread decoding a data packet group, by dividing the data packet group into at least one segment and determining whether to perform block-level decoding or instruction-level decoding on the segment according to the initial instruction pointer of each segment, selective decoding of processor trace data can be achieved, thereby further improving the decoding speed of processor trace data.

[0019] In conjunction with the first aspect, in some implementations of the first aspect, the decoding range is determined based on a dynamic library used by the target program in the process of obtaining the processor trace data by rendering a file.

[0020] Based on the above technical solution, determining the decoding range according to the dynamic library used when the target program renders the file can narrow down the decoding range of the processor's trace data. With a narrowed decoding range, the number of segments within the initial instruction pointer's decoding range will also decrease, and the number of segments that need to be decoded will also decrease, thereby improving the decoding speed of the processor's trace data.

[0021] In conjunction with the first aspect, in some implementations of the first aspect, the method further includes: merging the decoded data obtained by the N decoding threads from decoding the M data packet groups.

[0022] Secondly, a decoding method is provided, which may include: determining multiple target instruction pointer packets from processor trace data; dividing the processor trace data into at least one segment based on the multiple target instruction pointer packets, the at least one segment including a first type segment, the first data packet of the first type segment being a target instruction pointer packet, and the number of target instruction pointer packets in the first type segment being 1; calculating an initial instruction pointer for the first type segment based on the target instruction pointer packets in the first type segment; and determining whether to perform block-level decoding or instruction-level decoding on the first type segment based on the initial instruction pointer of the first type segment.

[0023] For example, if the initial instruction pointer of the first type segment is within the decoding range, then the first type segment is subjected to block-level decoding or instruction-level decoding; if the initial instruction pointer of the first type segment is not within the decoding range, then the first type segment is not subjected to block-level decoding or instruction-level decoding.

[0024] Optionally, if there are data packets of other types besides the target instruction pointer packet before the first target instruction pointer packet of the processor tracking data, the at least one segment further includes a second type segment, which includes data packets preceding the first target instruction pointer packet; the method further includes: calculating an initial instruction pointer for the second type segment based on a packet stream boundary packet preceding and adjacent to the second type segment; and determining whether to perform block-level decoding or instruction-level decoding on the second type segment based on the initial instruction pointer of the second type segment.

[0025] For example, if the initial instruction pointer of the second type segment is within the decoding range, then the second type segment is subjected to block-level decoding or instruction-level decoding; if the initial instruction pointer of the second type segment is not within the decoding range, then the second type segment is not subjected to block-level decoding or instruction-level decoding.

[0026] Based on the above technical solution, in the process of decoding processor trace data, by dividing the processor trace data into at least one segment and determining whether to perform block-level decoding or instruction-level decoding on the segment according to the initial instruction pointer of each segment, selective decoding of processor trace data can be achieved, thereby improving the decoding speed of processor trace data.

[0027] In conjunction with the second aspect, in some implementations of the second aspect, the method further includes: during the process of the target program obtaining the processor tracing data by rendering a file, collecting additional information to assist in decoding the processor tracing data, the additional information including one or more of the following information loaded by the process of the target program: dynamic library metadata, the modified memory portion of the modified dynamic library, and data memory with execution permissions; and, if it is determined that the first type segment is to be decoded at the block level or the instruction level, performing block-level decoding or instruction-level decoding on the first type segment in conjunction with the additional information.

[0028] The dynamic library metadata includes both unmodified dynamic library metadata and modified dynamic library metadata.

[0029] Specifically, decoding the first type segment in conjunction with this additional information includes: determining the binary file corresponding to the target program loading process by combining the additional information and the target program's library binary file; and decoding the first type segment based on the binary file.

[0030] In conjunction with the second aspect, in some implementations of the second aspect, the method further includes: when it is determined that the second type segment is to be block-level decoded or instruction-level decoded, performing block-level decoded or instruction-level decoded on the second type segment in conjunction with the additional information.

[0031] Specifically, the second type segment is decoded in conjunction with this additional information, including: determining the binary file corresponding to the target program loading process by combining the additional information and the target program's library binary file; and decoding the second type segment based on the binary file.

[0032] Based on the above technical solution, during the process of obtaining processor tracking data, additional information for assisting decoding is collected, and the processor tracking data is decoded in combination with this additional information, thereby ensuring that the processor tracking data is correctly decoded.

[0033] It's understandable that when a target program runs on different operating systems, the operating system's mechanisms may cause some bytes of the dynamic library to be replaced, or new dynamic libraries to be loaded. In this case, if processor trace data is still decoded based on the target program's library binary file, correct decoding of the processor trace data cannot be guaranteed. Therefore, by combining additional information to determine the binary file corresponding to the target program's loading process, correct decoding of the processor trace data can be guaranteed.

[0034] In conjunction with the second aspect, in some implementations of the second aspect, the decoding range is determined based on a dynamic library used by the target program in the process of obtaining the processor trace data by rendering a file.

[0035] Based on the above technical solution, determining the decoding range according to the dynamic library used when the target program renders the file can narrow down the decoding range of the processor's trace data. With a narrowed decoding range, the number of segments within the initial instruction pointer's decoding range will also decrease, and the number of segments that need to be decoded will also decrease, thereby improving the decoding speed of the processor's trace data.

[0036] Thirdly, a decoding method is provided, which may include: during the process of a target program obtaining processor tracing data by rendering a file, collecting additional information to assist in decoding the processor tracing data, the additional information including one or more of the following information loaded by the target program: dynamic library metadata, the modified memory portion of the modified dynamic library, and data memory with execution permissions; and decoding the processor tracing data in combination with the additional information.

[0037] The dynamic library metadata includes both unmodified dynamic library metadata and modified dynamic library metadata.

[0038] Based on the above technical solution, during the process of obtaining processor tracking data, additional information for assisting decoding is collected, and the processor tracking data is decoded in combination with this additional information, thereby ensuring that the processor tracking data is correctly decoded.

[0039] Specifically, the processor tracing data is decoded using this additional information, including: determining the binary file corresponding to the target program loading process by combining the additional information with the target program's library binary file; and decoding the processor tracing data based on the binary file.

[0040] It's understandable that when a target program runs on different operating systems, the operating system's mechanisms may cause some bytes of the dynamic library to be replaced, or new dynamic libraries to be loaded. In this case, if processor trace data is still decoded based on the target program's library binary file, correct decoding of the processor trace data cannot be guaranteed. Therefore, by combining additional information to determine the binary file corresponding to the target program's loading process, correct decoding of the processor trace data can be guaranteed.

[0041] Fourthly, a decoding apparatus is provided, comprising a processing unit and a decoding unit. The processing unit is configured to: determine multiple packet flow boundary packets from processor tracking data, the processor tracking data including the multiple packet flow boundary packets and multiple data packets; determine M data packet groups based on the multiple packet flow boundary packets, the M data packet groups including the multiple data packets, wherein the data packets in a data packet group are located between two different packet flow boundary packets, and different data packet groups include different data packets, wherein M≥2 and M is an integer; and the decoding unit is configured to: decode the M data packet groups using N decoding threads, each of the N decoding threads decoding at least one data packet group in the M data packet groups, and different decoding threads of the N decoding threads decoding different data packet groups, wherein N≥2 and N is an integer.

[0042] For example, a packet group may include packets located between two adjacent packets from different packet stream boundaries.

[0043] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the decoding device further includes a collection unit, which is used to: collect additional information to assist in decoding the processor tracking data during the process of the target program obtaining the processor tracking data by rendering a file. The additional information includes one or more of the following information loaded by the process of the target program: dynamic library metadata, the modified memory portion of the modified dynamic library, and data memory with execution permissions; the decoding unit is specifically used to: combine the additional information and use the N decoding threads to decode the M data packet groups.

[0044] The dynamic library metadata includes both unmodified dynamic library metadata and modified dynamic library metadata.

[0045] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the decoding unit is specifically used to: combine the additional information and the library binary file of the target program to determine the binary file corresponding to the loading process of the target program; and, based on the binary file, use the N decoding threads to decode the M data packet groups.

[0046] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the decoding unit is specifically used to: determine at least one segment based on the target instruction pointer packet in the data packet group, the at least one segment including a first type segment, the first data packet of the first type segment being a target instruction pointer packet, and the number of target instruction pointer packets in the first type segment being 1; calculate the initial instruction pointer of the first type segment based on the target instruction pointer packet in the first type segment; and determine whether to perform block-level decoding or instruction-level decoding on the first type segment based on the initial instruction pointer of the first type segment.

[0047] For example, if the initial instruction pointer of the first type segment is within the decoding range, then the first type segment is subjected to block-level decoding or instruction-level decoding; if the initial instruction pointer of the first type segment is not within the decoding range, then the first type segment is not subjected to block-level decoding or instruction-level decoding.

[0048] Optionally, if there are data packets of other types besides the target instruction pointer packet before the first target instruction pointer packet of the data packet group, the at least one segment further includes a second type segment, which includes the data packets preceding the first target instruction pointer packet; the decoding unit is further configured to: calculate the initial instruction pointer of the second type segment based on the packet stream boundary packet preceding and adjacent to the second type segment; and determine whether to perform block-level decoding or instruction-level decoding on the second type segment based on the initial instruction pointer of the second type segment.

[0049] For example, if the initial instruction pointer of the second type segment is within the decoding range, then the second type segment is subjected to block-level decoding or instruction-level decoding; if the initial instruction pointer of the second type segment is not within the decoding range, then the second type segment is not subjected to block-level decoding or instruction-level decoding.

[0050] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the decoding range is determined based on a dynamic library used by the target program in the process of obtaining the processor trace data by rendering a file.

[0051] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the decoding device further includes a merging unit, which is used to merge the decoded data obtained by the N decoding threads from decoding the M data packet groups.

[0052] Fifthly, a decoding apparatus is provided, which may include a decoding unit configured to: determine a plurality of target instruction pointer packets from processor trace data; divide the processor trace data into at least one segment based on the plurality of target instruction pointer packets, the at least one segment including a first type segment, the first data packet of the first type segment being a target instruction pointer packet, and the number of target instruction pointer packets in the first type segment being 1; calculate an initial instruction pointer for the first type segment based on the target instruction pointer packets in the first type segment; and determine whether to perform block-level decoding or instruction-level decoding on the first type segment based on the initial instruction pointer of the first type segment.

[0053] For example, if the initial instruction pointer of the first type segment is within the decoding range, then the first type segment is subjected to block-level decoding or instruction-level decoding; if the initial instruction pointer of the first type segment is not within the decoding range, then the first type segment is not subjected to block-level decoding or instruction-level decoding.

[0054] Optionally, if there are data packets of other types besides the target instruction pointer packet before the first target instruction pointer packet of the processor tracking data, the at least one segment further includes a second type segment, which includes data packets preceding the first target instruction pointer packet; the decoding unit is further configured to: calculate the initial instruction pointer of the second type segment based on the packet stream boundary packet preceding and adjacent to the second type segment; and determine whether to perform block-level decoding or instruction-level decoding on the second type segment based on the initial instruction pointer of the second type segment.

[0055] For example, if the initial instruction pointer of the second type segment is within the decoding range, then the second type segment is subjected to block-level decoding or instruction-level decoding; if the initial instruction pointer of the second type segment is not within the decoding range, then the second type segment is not subjected to block-level decoding or instruction-level decoding.

[0056] In conjunction with the fifth aspect, in some implementations of the fifth aspect, the decoding apparatus further includes a collection unit, which is configured to: collect additional information assisting in the decoding of the processor tracking data during the process of the target program obtaining the processor tracking data by rendering a file; the additional information includes one or more of the following information loaded by the process of the target program: dynamic library metadata, the modified memory portion of the modified dynamic library, and data memory with execution permissions; the decoding unit is further configured to: perform block-level decoding or instruction-level decoding on the first type segment in conjunction with the additional information, if it is determined that block-level decoding or instruction-level decoding is to be performed on the first type segment.

[0057] The dynamic library metadata includes both unmodified dynamic library metadata and modified dynamic library metadata.

[0058] In conjunction with the fifth aspect, in some implementations of the fifth aspect, the decoding unit is specifically used to: combine the additional information and the library binary file of the target program to determine the binary file corresponding to the loading process of the target program; and perform block-level decoding or instruction-level decoding on the first type segment based on the binary file.

[0059] In conjunction with the fifth aspect, in some implementations of the fifth aspect, the decoding unit is further configured to: perform block-level decoding or instruction-level decoding on the second type segment in conjunction with the additional information, if it is determined that block-level decoding or instruction-level decoding is to be performed on the second type segment.

[0060] In conjunction with the fifth aspect, in some implementations of the fifth aspect, the decoding unit is specifically used to: combine the additional information and the library binary file of the target program to determine the binary file corresponding to the loading process of the target program; and perform block-level decoding or instruction-level decoding on the second type segment based on the binary file.

[0061] In conjunction with the fifth aspect, in some implementations of the fifth aspect, the decoding range is determined based on a dynamic library used by the target program in the process of obtaining the processor trace data by rendering a file.

[0062] In a sixth aspect, a decoding apparatus is provided, which may include a collection unit and a decoding unit. The collection unit is configured to: collect additional information to assist in the decoding of processor tracking data during the process of a target program obtaining processor tracking data by rendering a file. The additional information includes one or more of the following information loaded by the target program: dynamic library metadata, modified memory portion of a modified dynamic library, and data memory with execution permissions. The decoding unit is configured to: decode the processor tracking data in conjunction with the additional information.

[0063] The dynamic library metadata includes both unmodified dynamic library metadata and modified dynamic library metadata.

[0064] In conjunction with the sixth aspect, in some implementations of the sixth aspect, the decoding unit is specifically used to: combine the additional information and the library binary file of the target program to determine the binary file corresponding to the loading process of the target program; and decode the processor trace data according to the binary file.

[0065] In a seventh aspect, a decoding apparatus is provided, comprising: a memory for storing a program; and a processor for executing the program stored in the memory, wherein when the program stored in the memory is executed, the processor executes the method described in the first aspect and any implementation thereof.

[0066] Eighthly, a decoding apparatus is provided, comprising: a memory for storing a program; and a processor for executing the program stored in the memory, wherein when the program stored in the memory is executed, the processor executes the method described in the second aspect and any implementation thereof.

[0067] A ninth aspect provides a decoding apparatus, the apparatus comprising: a memory for storing a program; and a processor for executing the program stored in the memory, wherein when the program stored in the memory is executed, the processor is configured to execute the method of the third aspect and any implementation thereof.

[0068] In a tenth aspect, a computer-readable medium is provided that stores program code for execution by a device, the program code including methods for performing any of the implementations of the foregoing aspects.

[0069] Eleventhly, a computer program product containing instructions is provided, which, when run on a computer, causes the computer to perform the method in any of the above-mentioned implementations.

[0070] In a twelfth aspect, a chip is provided, the chip including a processor and a data interface, the processor reading instructions stored in a memory through the data interface and executing the method in any of the above-mentioned implementations.

[0071] Optionally, as one implementation, the chip may further include a memory storing instructions, and the processor is used to execute the instructions stored in the memory. When the instructions are executed, the processor is used to perform the method in any of the above-described aspects.

[0072] The aforementioned chip can be a field-programmable gate array (FPGA) or an application-specific integrated circuit (ASIC). Attached Figure Description

[0073] Figure 1 A schematic diagram of a code attack is shown.

[0074] Figure 2 A functional block diagram of a system including circuitry for controlling flow integrity is shown.

[0075] Figure 3 A schematic block diagram of the PT-CFI system is shown.

[0076] Figure 4A schematic structural diagram of the communication system provided in an embodiment of this application is shown.

[0077] Figure 5 A schematic structural diagram of the device provided in the embodiments of this application is shown.

[0078] Figure 6 A schematic diagram of the sub-decoding task is shown.

[0079] Figure 7 A schematic diagram of segmenting the decoding task is shown.

[0080] Figure 8 The flowchart of the Intel processor trace (IPT) decoding module 504 is shown.

[0081] Figure 9 A schematic flowchart of the decoding method provided in an embodiment of this application is shown.

[0082] Figure 10 A schematic diagram of segmenting PT data is shown.

[0083] Figure 11 A schematic flowchart is shown to illustrate the acquisition of PT data and the collection of additional information to aid in the decoding of PT data.

[0084] Figure 12 A schematic flowchart of the decoding method provided in an embodiment of this application is shown.

[0085] Figure 13 A schematic flowchart of the decoding method provided in an embodiment of this application is shown.

[0086] Figure 14 A schematic diagram is shown showing how PT data is divided into data packet groups.

[0087] Figure 15 A schematic flowchart of the decoding method provided in an embodiment of this application is shown.

[0088] Figure 16 A schematic flowchart illustrating the merging and decoding of data provided in an embodiment of this application is shown.

[0089] Figure 17 A schematic flowchart of the decoding method provided in an embodiment of this application is shown.

[0090] Figure 18 A schematic diagram of data packet segmentation is shown.

[0091] Figure 19 A schematic flowchart of the decoding method provided in an embodiment of this application is shown.

[0092] Figure 20 A schematic block diagram of a decoding apparatus provided in an embodiment of this application is shown.

[0093] Figure 21 A schematic block diagram of a decoding apparatus provided in an embodiment of this application is shown.

[0094] Figure 22 A schematic block diagram of a decoding apparatus provided in an embodiment of this application is shown. Detailed Implementation

[0095] The technical solutions in this application will now be described with reference to the accompanying drawings.

[0096] Enterprises often receive a large number of document files (portable document format (PDF), document (DOC(X)) etc.) or program files from unknown sources. Before using these files securely, it is necessary to confirm that these files do not contain malicious content (such as exploitation behavior).

[0097] Currently, vulnerability exploitation methods have shifted from code injection attacks to code reuse attacks. Code injection attacks involve attackers injecting carefully crafted data into the target user process or operating system kernel, then triggering a vulnerability to cause the computer processor to mistakenly interpret the attacker's crafted data as code and execute it, thereby controlling the execution of the user process or operating system kernel. Extensive research has been conducted in industry and academia to combat code injection attacks, and ultimately, data non-executability protection has made code injection attacks difficult to succeed.

[0098] Attackers have been forced to develop new exploitation methods, among which code reuse attacks reuse only the original code of the attacked process without injecting any code (only injecting data that controls the execution flow). Therefore, code reuse attacks have gradually become the mainstream exploitation method. For example... Figure 1 As shown, the normal execution flow has only three types: 1→2→4, 1→3→5, and 1→3→6. With the help of code reuse attacks, attackers can control the execution of unexpected malicious execution flows: 1→3→4→1.

[0099] Code reuse attacks do not change the process memory image, but only the process execution flow, which poses a huge challenge to the detection and protection against vulnerability exploitation. This is mainly because detection and protection can only be carried out at the level of basic blocks or execution instruction streams.

[0100] Control flow integrity (CFI) is a primary approach to combating code attacks. However, two prerequisites limit its application to online methods: 1) the ability to obtain accurate execution instruction flow; and 2) the ability to quickly obtain the execution instruction flow. Furthermore, CFI-based online detection (detecting during code execution, requiring near real-time low latency) code reuse attack protection mechanisms, due to performance considerations, are typically coarse-grained and may miss numerous code reuse attacks, rendering detection and protection ineffective.

[0101] Ideally, a valid control flow graph (CFG) for the program (process) should be pre-constructed, or heuristic rules for normal process execution should be preset. During program runtime, the execution flow should be monitored and compared with the valid CFG or heuristic rules to determine if an attack has occurred. However, in reality, this is difficult to implement due to excessive performance overhead. Therefore, a coarse-grained Control Flow Indicator (CFI) mechanism that only detects indirect calls / jumps and not function returns can be used. It may even be insensitive to the function call context, making it easily bypassable by attackers.

[0102] Intel's processor trace (PT) hardware boasts a highly efficient processor tracing mechanism that accurately records the complete processor execution instruction flow with an additional performance overhead of no more than 5%. This makes fine-grained (full path detection), difficult-to-bypass (no false negatives), and reliable (no false positives) offline detection of exploits targeting code reuse attacks possible. Offline detection involves recording the complete execution flow and then performing post-event detection by replaying the execution process.

[0103] However, Intel PT hardware only addresses the challenge of fast recording. Decoding highly compressed PT data incurs significant overhead, and greatly reducing the decoding overhead remains a huge challenge.

[0104] To facilitate the promotion and use of PT hardware, Intel has provided a reference software development kit (SDK) for its PT hardware. This library offers decoding capabilities at the packet, block, and instruction (inst) levels. The packet layer decodes PT data into recognizable data packets; the block layer decodes PT data into sequences of execution blocks; and the inst layer decodes to obtain a sequence of assembly instructions that is completely consistent with the execution instruction stream. The information obtained from these three levels of decoding becomes increasingly detailed, but the additional performance overhead also increases. PT data refers to the highly compressed data recorded by the PT hardware, directly saved to a file. Execution blocks are a concept distinct from basic blocks, with two key differences: first, execution blocks do not end during direct jumps; and second, basic blocks are segmented when events are encountered during decoding.

[0105] The main problem with the above scheme is that it requires judging each execution instruction one by one. Since the number of execution instructions is huge, the additional performance overhead of decoding is enormous.

[0106] Another PT data decoding scheme is based on the control flow graph of the target instruction pointer (TIP) and the target application and its used libraries, and judges control flow tampering behavior according to a predefined strategy. Its system functional block diagram is as follows: Figure 2 As shown, the hardware components include: a memory 112, a processor 110, a PT circuit 124 embedded in the processor, a communication interface 114 for cooperating with other systems, a CFG memory 122 for storing CFG, and a policy memory 136 for storing policies; the software components include: an operating system 116 on which the target application is based, a disassembler 121, a CFG generation tool 120, a PT driver 126, a PT control program 130, and a control flow verification program 134; the analysis objects include: the target application 118 and the libraries used by the target application 119.

[0107] The basic decoding process is as follows: 1) The target application 118 and its used libraries 119 are disassembled using disassembler 121 to obtain assembly instructions. CFG generator 120 uses the disassembler instructions to construct CFG graphs (128 and 129) of the target application and libraries, and stores them in CFG memory 122. Predefined strategies are stored in strategy memory 136. 2) PT control program 130 configures PT driver 126 and obtains PT data from PT driver 126 (in fact, PT circuit 124 stores PT packets in memory 112 according to the instructions of PT driver 126, and PT driver 126 obtains PT packets from memory 112). 3) PT decoding program 132 obtains PT data from PT control program 130, performs decoding at the packet level, and analyzes only the TIP packets to obtain the PT target address. 4) Finally, control flow verification program 134 determines whether there are control flow violations based on each PT target address and the CFG graph of the target application 128 and its used libraries 129, according to the predefined strategy. And output the results.

[0108] Another PT data decoding scheme is PT-CFI. The goal of PT-CFI is to detect control flow hijacking by implementing a lightweight CFI model. Its basic idea is to determine control flow tampering behavior based on TIP sequence diagrams and system calls. The basic framework diagram of the PT-CFI system is as follows: Figure 3 As shown: When generating PT packets for the monitored process, the first component, packet parsing, parses each packet and generates TIP sequences. These sequences are then provided to the second component, TIP graph matching. If the TIP sequence stream matches the TIP graph, execution continues; otherwise, the third component, deep inspection, is invoked to decode the packets and construct a shadow stack. If the decoded return addresses match in the shadow stack, the new TIP sequence is considered valid and added to the TIP graph; otherwise, the last component, syscall hooking, is notified to terminate the monitored process's execution due to a control flow violation.

[0109] While the two schemes mentioned above improve decoding speed to some extent, they are not granular enough because they only process TIP packets and not taken-not-taken (TNT) packets. They cannot detect exploit behavior at the basic block or execution instruction level and cannot guarantee that the exploit will not be bypassed. Hackers may still be able to successfully tamper with the control flow by carefully constructing gadge sequences.

[0110] In view of this, this application provides a decoding method to improve the efficiency of PT data decoding.

[0111] Figure 4 A schematic structural diagram of a device 400 to which the decoding method provided in this application can be applied is shown. Figure 4 As shown, device 400 may include a host and peripherals. The host includes a processor and memory (RAM), the processor being an Intel PT-enabled processor with embedded PT hardware. Peripherals include external devices for input / output, including but not limited to hard drives, network storage, etc.

[0112] Figure 5 A schematic structural diagram of the apparatus 500 provided in an embodiment of this application is shown. Figure 5 As shown, the device 500 includes: a control module 501, an Intel processor trace (IPT) recording module 502, an additional information recording module for auxiliary decoding 503, and an IPT decoding module 504.

[0113] Specifically, the control module 501 controls the IPT recording module 502 to record the PT data generated when the tracked process parses a sample file (which may be a normal sample or an exploit sample). The input to the IPT recording module 502 is the handle of the tracked process, and the output is the PT data file.

[0114] The control module 501 is also used to control the auxiliary decoding additional information recording module 503 to record additional information for auxiliary decoding. Exemplarily, the auxiliary decoding additional information recording module 503 includes: a dynamic library metadata recording module 5031, a modified dynamic library information export module 5032, and an executable data memory information export module 5033. Specifically, the input of the auxiliary decoding additional information recording module 503 is the handle of the traced process, and the output is the additional information for auxiliary decoding.

[0115] Specifically, the control module 501 is used to control the dynamic library metadata recording module 5031 to record metadata such as the dynamic library loading base address in the traced process; the control module 501 is also used to control the modified dynamic library information export module 5032 to record the modified memory image of the modified part in the modified dynamic library in the traced process; the control module 501 is also used to control the executable data memory information export module 5033 to record the executable data memory region image in the traced process.

[0116] It should be understood that Figure 5This application only uses the auxiliary decoding additional information recording module 503, which includes a dynamic library metadata recording module 5031, a modified dynamic library information export module 5032, and an executable data memory information export module 5033, as an example. The specific structure of the auxiliary decoding additional information recording module 503 is not limited. For example, the additional information required for auxiliary decoding differs for different operating systems, and correspondingly, the specific structure of the auxiliary decoding additional information recording module 503 will also differ.

[0117] The control module 501 is also used to control the IPT decoding module 504 to decode the PT data. Specifically, the inputs of the IPT decoding module 504 are the PT data, the parser, the library file, and additional information for auxiliary decoding, and the output is a basic block or an execution instruction stream. For example, the IPT decoding module 504 includes: a task decomposition module 5041, an instruction pointer (IP) filtering and decoding module 5042, and a task result merging module 5043.

[0118] The task decomposition module 5041 is used to decompose the decoding of PT data into multiple sub-decoding tasks based on packet stream boundary (PSB) packets. Each sub-decoding task is used to decode data packets between two different PSB packets in the PT data. Specifically, the task decomposition module 5041 decomposes the decoding of PT data into multiple sub-decoding tasks based on each [PSB][PSB+][PSBEND] type packet combination in the PT data file as the boundary. [PSB][PSB+][PSBEND] represents a complete PSB packet, [PSB] represents the PSB header, [PSBEND] represents the PSB trailer, and [PSB+] represents the data packet between the PSB header and PSB trailer. For example, [PSB+] includes one or more of the following types of data packets: time-stamp counter (TSC), paging information packet (PIP), virtual machine control structure (VMSC) packet, flow update packet (FUP), and TIP.

[0119] Figure 6 An example of a sub-decoding task is shown, such as Figure 6 As shown, the sub-decoding task includes decoding the data packets between PSB packet 1 and PSB packet 2. These data packets include TIP packet 1, TNT packet 1, TNT packet 2, TIP packet 2, and TNT packet 3. It should be understood that... Figure 6This example only illustrates the interaction between PSB packet 1 and PSB 2, which involves two types of data packets. However, the interaction between PSB packet 1 and PSB packet 2 may include other types of data packets besides [PSB] and [PSBEND]. For example, the interaction between PSB packet 1 and PSB packet 2 may include one or more of the following types of data packets: TSC, PIP, TIP, TNT, FUP, etc.

[0120] The task decomposition module 5041 is also used to create decoding threads based on the number of processor cores. These decoding threads are used to execute sub-decoding tasks. For example, if the number of processor cores is 2, the task decomposition module 5041 can create 1 or 2 decoding threads. As another example, if the number of processor cores is 4, the task decomposition module 5041 can create 1 / 2 / 3 / 4 decoding threads. Exemplarily, the task decomposition module 5041 creates IP-based decoding threads based on the number of processor cores.

[0121] The IP filtering decoding module 5042 is responsible for IP filtering-based IPT decoding. Specifically, the IP filtering decoding module 5042 performs IP filtering-based IPT decoding in a decoding thread. For example, if the task decomposition module 5041 creates N IP filtering-based decoding threads, then each of the N IP filtering decoding modules 5042 performs IP filtering-based IPT decoding.

[0122] The IP filtering and decoding module 5042 first acquires the decoding task. If the decoding task is successfully acquired, the IP filtering and decoding module 5042 divides the acquired decoding task into at least one segment based on the TIP packet. This at least one segment includes a first type segment, where the first data packet in the first type segment is a TIP packet, and the first type segment contains only one TIP packet. Optionally, if other types of data packets (e.g., TNT packets) exist before the first TIP packet included in the decoding task, then the at least one segment also includes a second type segment, which includes all data packets preceding the first TIP packet of the decoding task.

[0123] For example Figure 7 As shown in (a), if the IP filtering decoding module 5042 obtains decoding task #1, then the IP filtering decoding module 5042 divides decoding task #1 into three segments, which include: a second type segment, a first type segment #1, and a second type segment #2. The first data packet of both the first type segment #1 and the second type segment #2 is a TIP packet, and both the first type segment #1 and the second type segment #2 contain only one TIP packet. Since TNT packet 1 and TNT packet 2 exist before the first TIP packet (TIP packet 1) included in this decoding task, the three segments also include a second type segment, which includes all data packets before TIP packet 1, i.e., the second type segment includes TNT packet 1 and TNT packet 2.

[0124] For example Figure 7 As shown in (b), if the IP filtering decoding module 5042 obtains decoding task #2, then the IP filtering decoding module 5042 divides decoding task #2 into three segments, which include: first type segment #3, first type segment #4, and first type segment #5. Since the first data packet of decoding task #2 is a TIP packet (TIP packet 3), the three segments into which decoding task #2 is divided do not include the second type segment.

[0125] Furthermore, the IP filtering and decoding module 5042 is also used to calculate the initial IP of each segment in at least one segment. For a first type segment in the at least one segment, the IP filtering and decoding module 5042 is used to calculate the initial IP of the first type segment based on the TIP packet included in the first type segment. For a second type segment in the at least one segment, the IP filtering and decoding module 5042 is used to calculate the initial IP of the second type segment based on the PSB packet preceding and adjacent to the second type segment. Specifically, the IP filtering and decoding module 5042 is used to calculate the initial IP of the second type segment based on the [PSB+] of the PSB packet, that is, to calculate the initial IP of the second type segment based on the data between the PSB header and PSB trailer of the PSB packet.

[0126] Furthermore, the IP filtering and decoding module 5042 is also used to sequentially determine whether the initial IP of each segment in the at least one segment is within the decoding range. If the initial IP of any segment in the at least one segment is within the decoding range, the IP filtering and decoding module 5042 is used to perform block layer or instant layer decoding on the segment; if the initial IP of any segment in the at least one segment is not within the decoding range, the IP filtering and decoding module 5042 does not perform block layer or instant layer decoding on the segment.

[0127] The task result merging module 5043 is responsible for merging the results of each decoding subtask. Specifically, the task result merging module 5043 determines whether there are any decoding results that need to be merged. If there are decoding results that need to be merged, the task result merging module 5043 merges the decoding results; if there are no decoding results that need to be merged, the task result merging module does not need to merge the decoding results.

[0128] Figure 8 A schematic diagram illustrating the processing flow of the task decomposition module 5041, the IP filtering and decoding module 5042, and the task result merging module 5043 is shown. Figure 8As shown, the task decomposition module 5041 takes PT data as input and outputs a PSB task queue, which includes multiple sub-decoding tasks. The IP filtering decoding module 5042 can create N decoding threads. Each decoding thread, in conjunction with the parser and library files, executes a sub-decoding task and outputs the decoded data obtained from the sub-decoding task to the task result merging module 5043. The task merging module 5043 merges and outputs the decoded data from each decoding thread.

[0129] It should be understood that Figure 5 This application uses the IPT decoding module 504, which includes a task decomposition module 5041, an IP filtering decoding module 5042, and a task result merging module 5043, as an example only. The specific structure of the IPT decoding module 504 is not limited. For example, the IPT decoding module 504 may include the task decomposition module 5041 and the task result merging module 5043, but not the IP filtering decoding module 5042. As another example, the IPT decoding module 504 may include the IP filtering decoding module 5042, but not the task decomposition module 5041 and the task result merging module 5043.

[0130] Figure 9 A schematic flowchart of the decoding method provided in an embodiment of this application is shown. Figure 9 As shown, method 900 may include steps S910 to S940, each of which is described in detail below.

[0131] S910 identifies multiple TIP packets from PT data.

[0132] S920, PT data is divided into at least one segment based on multiple TIP packets, the at least one segment including a first type segment, the first data packet of the first type segment being a TIP packet, and the number of TIP packets included in the first type segment being 1.

[0133] Specifically, the PT data is decoded at the packet layer, and then the PT data is divided into at least one segment according to the TIP type packet in the PT data.

[0134] Since each first-type segment includes 1 TIP packet, it can be deduced that the number of first-type segments included in this at least one segment is equal to the number of TIP packets included in the PT data. For example Figure 10 As shown in (a), PT data #1 includes three TIP packets (TIP packet 1, TIP packet 2, and TIP packet 3), therefore PT data #1 can be divided into three first-type segments. First-type segment #1 includes TIP packet 1 and TNT packet 1; first-type segment #2 includes TIP packet 2, TNT packet 2, and TNT packet 3; first-type segment #3 includes TIP packet 3 and TNT packet 4.

[0135] Optionally, if there are other types of data packets besides the TIP packet before the first TIP packet of the PT data, then the at least one segment also includes a second type segment, which includes all data packets before the first TIP packet. The other types of data packets besides the TIP packet include one or more of the following types: TSC, PIP, FUP, PSB, etc.

[0136] For example Figure 10 As shown in (b), before the first TIP packet (TIP packet 1) of PT data #2, there are TNT packet 1 and TNT packet 2. Therefore, after segmenting PT data #2, at least one segment will also include a second type segment, which includes TNT packet 1 and TNT packet 2. It should be understood that PSB packets in the PT data are not considered when segmenting the PT data. Figure 10 The second type segment shown in (b) does not include the PSB packet, but only includes TNT packet 1 and TNT packet 2 preceding TIP packet 1. Furthermore, this PT data #2 also includes two TIP packets, therefore this at least one segment also includes two first type segments. Specifically, first type segment #4 includes TIP packet 1, TNT packet 3, and TNT packet 4; first type segment #5 includes TIP packet 2 and TNT packet 5.

[0137] It should be understood that in the embodiments of this application, PSB packets in the PT data are not considered when segmenting the PT data. For example, the data packets of other types besides TIP packets mentioned above refer to data packets of other types besides TIP packets and PSB packets; all data packets before the first TIP packet mentioned above refer to data packets before the first TIP packet except for PSB packets.

[0138] It should also be understood that Figure 10 This example only uses PT data, which includes two types of data packets. PT data may also include one or more of the following types of data packets: TSC, PIP, FUP, PSB, etc.

[0139] Prior to S910, method 900 also includes S950: acquiring PT data. That is, enabling IPT recording for the target program (process) to acquire PT data generated by the IPT hardware. Specifically, the PT data can be obtained by the target program through rendering a file. In other words, when the target program opens a file, the IPT hardware can record the PT data generated by the target program rendering the file.

[0140] Optionally, S950 also includes collecting additional information for instruction stream recovery. This additional information for instruction stream recovery may also be referred to as additional information for assisting PT data decoding. It should be understood that the additional information collected in S950 for recovering the instruction stream may differ for different operating systems. For example, for the Windows operating system, the additional information collected in S950 for recovering the instruction stream includes one or more of the following information loaded by the target program's process: data memory with execution permissions (execdata), the modified memory portion of modified dynamic libraries, and dynamic library metadata (e.g., unmodified dynamic library metadata and modified dynamic library metadata). Dynamic library metadata includes the dynamic library name, load base address, etc.

[0141] For example, S950 includes as follows Figure 11 The sub-steps shown.

[0142] S951: Start the target program and obtain its process ID. Start IPT recording for the target program's process and open a preset test file. After the preset test file is successfully opened, start a timer. After the timer expires, execute S952.

[0143] S952 determines whether the process has loaded a new dynamic library. If the process has loaded a new dynamic library, the name of the new dynamic library and its load base address are stored in the data structure.

[0144] S953 checks if the process has execdata. If the process has execdata, it outputs execdata to a binary file and records the address.

[0145] S954 determines whether the process has caused partial bytes of a dynamic library to be replaced due to operating system mechanisms (such as the Shim mechanism in Windows). If the process has caused partial bytes of a dynamic library to be replaced due to operating system mechanisms, then the executable portion of that dynamic library is exported. If the executable portion of that dynamic library has already been exported, then it is ignored.

[0146] S955: Determine if the process has terminated. If the process has not terminated, return to S952; if the process has terminated, continue to S956.

[0147] S956 outputs dynamic libraries, execdata, and modified dynamic libraries.

[0148] S930, calculate the initial IP of the first type segment based on the TIP packet in the first type segment.

[0149] For example Figure 10In (a), for the first type segment #1, the initial IP of the first type segment #1 is calculated based on TIP packet 1 in the first type segment #1; for the first type segment #2, the initial IP of the first type segment #2 is calculated based on TIP packet 2 in the first type segment #2; for the first type segment #3, the initial IP of the first type segment #3 is calculated based on TIP packet 3 in the first type segment #3.

[0150] Optionally, if the at least one segment further includes a second type segment, then S930 further includes: calculating the initial IP of the second type segment based on the PSB packet preceding and adjacent to the second type segment. Specifically, the initial IP of the second type segment is calculated based on the [PSB+] of the PSB packet, that is, based on the data packet between [PSB] and [PSBEND] of the PSB packet.

[0151] For example Figure 10 In (b), for the second type segment, the initial IP of the second type segment is calculated based on [PSB+] in the PSB packet preceding TNT packet 1 in the second type segment; for the first type segment #4, the initial IP of the first type segment #4 is calculated based on TIP packet 1 in the first type segment #4; for the first type segment #5, the initial IP of the first type segment #5 is calculated based on TIP packet 2 included in the first type segment #5.

[0152] S940 determines whether to perform block layer or inst layer decoding on the first type segment based on the initial IP of the first type segment.

[0153] Specifically, it is determined whether the initial IP of the first type segment is within the decoding range. If the initial IP of the first type segment is within the decoding range, the first type segment is decoded at the block layer or the instant layer. If the initial IP of the first type segment is not within the decoding range, the first type segment is not decoded at the block layer or the instant layer.

[0154] Optionally, the decoding range is determined based on the dynamic libraries used by the target program to render the file. For example, for the PDF parsing tool Adobe Reader, the dynamic libraries that assist in PDF parsing are basically only AcroRd32.dll (handles most PDF-supported element objects), EScript.api (handles scripts), CoolType.dll (handles fonts), AcroForm.api (handles editable forms), and JP2Klib.dll (handles images). Therefore, the decoding range can be determined based on one or more of these five dynamic libraries. For example, if the file does not contain images, EScript.api can be ignored when determining the decoding range. Or, if the file only contains images, the decoding range can be determined solely based on EScript.api.

[0155] Optionally, if the at least one segment further includes a second type segment, then S940 further includes: determining whether to perform block layer or inst layer decoding on the second type segment based on the initial IP of the second type segment.

[0156] Specifically, it is determined whether the initial IP of the second type segment is within the decoding range. If the initial IP of the second type segment is within the decoding range, the second type segment is decoded at the block layer or the instant layer. If the initial IP of the second type segment is not within the decoding range, the second type segment is not decoded at the block layer or the instant layer.

[0157] For example, S940 includes as follows Figure 12 The sub-steps shown.

[0158] First, the next segment is retrieved. If retrieving the next segment fails, the decoding process exits. If a segment is successfully retrieved, the initial IP of that segment is further checked to see if it is within the decoding range. If the initial IP of the segment is not within the decoding range, the process proceeds to retrieve the next segment. If the initial IP of the segment is within the decoding range, the block / inst decoder is initialized. Next, the next block / inst is retrieved. If retrieving the next block / inst fails, the block / instruction decoder exits, and the process proceeds to retrieve the next segment. If a block / inst is successfully retrieved, block / inst decoding is performed. After block / inst decoding is complete, the process continues to retrieve the next block / inst.

[0159] by Figure 10Taking PT data #1 as an example, in S940, the first type segment #1 is first obtained, and then it is determined whether the initial IP of the first type segment #1 is within the decoding range. If the initial IP of the first type segment #1 is not within the decoding range, the process moves to obtaining the next segment. Since there is a second type segment #2 after the first type segment #1, the second type segment #2 can be successfully obtained. The process then checks whether the initial IP of the first type segment #2 is within the decoding range. If the initial IP of the first type segment #2 is within the decoding range, the block / inst decoder is initialized, and the next block / inst is obtained. If block1 is successfully obtained, block decoding is performed on block1. After decoding block1, the process continues to obtain the next block / inst. If there are no other blocks or insts after block1, obtaining the next block / inst fails. The block / inst decoder then exits, and the process moves to obtaining the next segment. Since there is a first type segment #3 after the first type segment #2, the first type segment #3 can be successfully obtained. The next step is to determine if the initial IP of segment #3 of type 1 is within the decoding range. If the initial IP of segment #3 of type 1 is not within the decoding range, the process proceeds to retrieve the next segment. Since segment #3 of type 1 is the last segment, retrieving the next segment fails. Therefore, the decoding process exits.

[0160] Optionally, if additional information for instruction stream recovery is collected in S950, then method 900 further includes loading additional information for auxiliary PT data decoding before performing block / inst decoding. The additional information for auxiliary PT data decoding includes one or more of the following information loaded by the target program's process: execdata, the modified memory portion of the modified dynamic library, and dynamic library metadata (e.g., unmodified dynamic library metadata and modified dynamic library metadata). Specifically, all necessary content is loaded in the order of execdata, the modified memory portion of the modified dynamic library, and other dynamic library metadata. Here, execdata and the modified dynamic library export the executable segments, while for other dynamic libraries, executable segments need to be extracted.

[0161] Furthermore, during the block / inst decoding process, additional information from the loaded auxiliary decoding is incorporated into the block / inst decoding. Specifically, the block / inst decoding process includes: determining the binary file corresponding to the target program's loading process by combining the additional information and the target program's library binary file; and performing block / inst decoding based on this binary file.

[0162] In this embodiment, by dividing PT data into at least one segment and determining whether to perform block-level decoding or INS decoding on that segment based on its initial IP, selective decoding of PT data can be achieved, thereby improving the decoding speed. Compared to existing schemes that only process TIP packets, this embodiment targets an entire segment, and a segment can include not only TIP packets but also TNT packets. In other words, the decoding method provided by this embodiment can decode not only TIP packets but also TNT packets.

[0163] Furthermore, according to embodiments of this application, additional information for instruction stream recovery can be collected, thereby ensuring correct decoding of PT data. It is understood that when the target program runs on different operating systems, the operating system's mechanisms may cause some bytes of the dynamic library to be replaced, or new dynamic libraries to be loaded. In this case, if the processor trace data is still decoded based on the target program's library binary file, correct decoding of the processor trace data cannot be guaranteed. Therefore, by combining additional information to determine the binary file corresponding to the target program's loading process, correct decoding of the processor trace data can be guaranteed.

[0164] Furthermore, according to embodiments of this application, the decoding range used to determine whether decoding is required can be determined based on the dynamic libraries used by the target program to render the file, thereby further limiting the decoding range of selective decoding. Although a process typically loads hundreds of dynamic libraries, the vast majority of these dynamic libraries are provided by the operating system and are shared by all user processes, while process-specific dynamic libraries generally account for less than 10%. For example, the dynamic libraries used to implement PDF parsing functions are only 5. Therefore, focusing only on the recording and decoding of program execution flow in dynamic libraries related to the target process, and not on the execution flow in dynamic libraries provided by the operating system for use by all processes, can further improve decoding performance and input / output (IO) overhead.

[0165] Under the experimental conditions shown in Table 1, the decoding method provided in this application embodiment yields the experimental results shown in Table 2. As shown in Table 2, compared with full decoding, the decoding method provided in this application embodiment can achieve a speed improvement of 10 to 60 times, and reduce IO to less than 1 / 40.

[0166] Table 1

[0167] Table 2

[0168] Figure 13A schematic flowchart of a decoding method provided in another embodiment of this application is shown. Figure 13 As shown, method 1300 may include steps S1310 to S1330, each of which is described in detail below.

[0169] S1310, Identify multiple PSB packets from PT data.

[0170] S1320, determine M data packet groups based on multiple PSB packets. Where M≥2 and M is an integer.

[0171] The PT data includes multiple PSB packets and multiple data packets. These multiple data packets are other types of data packets besides the multiple PSB packets. For example, these multiple data packets include one or more of the following types: TIP, TNT, TSC, PIP, FUP, PSB, etc.

[0172] The M packet groups comprise the multiple data packets. In other words, in S1320, the multiple data packets included in the PT data are divided into M packet groups based on the multiple PSB packets. The data packets in any one of the M packet groups are located between two different PSB packets, and the data packets included in different packet groups are different. For example... Figure 14 As shown, data packet group 1 contains data packets located between PSB packet 1 and PSB packet 2, while data packet group 2 contains data packets located between PSB packet 2 and PSB packet 4. Furthermore, data packets contained in data packet group 1 and data packet group 2 are different.

[0173] Specifically, in S1320, M data packet groups are determined by using packet combinations of type [PSB][PSB+][PSBEND] as boundaries. [PSB][PSB+][PSBEND] represents a complete PSB packet, for example... Figure 14 The PSB packet shown is 1. [PSB] represents the PSB header, [PSBEND] represents the PSB trailer, and [PSB+] represents the data packet between the PSB header and PSB trailer.

[0174] For example, a packet group may include packets located between two adjacent PSB packets, or packets located between two non-adjacent PSB packets. For example Figure 14 As shown, data packet group 1 contains data packets located between two adjacent data packets, while data packet group 2 contains data packets located between two non-adjacent data packets.

[0175] In embodiments of this application, a data packet group and a PSB packet preceding and adjacent to the data packets included in the data packet group can also be collectively referred to as a PT data block. For example Figure 14As shown, PSB packet 1 is adjacent to and precedes TIP packet 1 included in data packet group 1. Therefore, PSB packet 1 and data packet group 1 can be collectively referred to as a PT data block. PSB packet 2 precedes and is adjacent to TNT packet 3 included in data packet group 1. PSB packet 3 precedes and is adjacent to TNT packet 5 included in data packet group 2. Therefore, PSB packet 2, PSB packet 3, and data packet group 2 can be collectively referred to as a PT data block. Based on this, S1320 can be replaced by: dividing the PT data into M PT data blocks according to multiple PSB packets, where each PT data block includes one or more PSB packets, and each PT data block also includes data packets between the first PSB packet included in it and the first PSB packet included in the next PT data block.

[0176] Furthermore, M data packet groups are added to the queue to be decoded.

[0177] Before S1310, method 1300 also includes S1340: acquiring PT data. That is, enabling IPT recording for the target program (process) to acquire PT data generated by the IPT hardware. Specifically, the PT data can be obtained by the target program through rendering a file. In other words, when the target program opens a file, the IPT hardware can record the PT data generated by the target program rendering the file.

[0178] Optionally, S1340 also includes collecting additional information for performing instruction stream recovery. For a more detailed description of collecting additional information for performing instruction stream recovery, please refer to S950 above; for brevity, it will not be elaborated here.

[0179] S1330, N decoding threads are used to decode the M data packets.

[0180] Where N is a positive integer greater than 1, and N is determined based on the maximum number of cores in the processor. For example, N is equal to the maximum number of cores in the processor.

[0181] Each of the N decoding threads decodes at least one of the M data packet groups, and different decoding threads among the N decoding threads decode different data packet groups.

[0182] For example, N decoding threads work in parallel to decode at least one of M packet groups. The parallel operation of N decoding threads means that their working times overlap. For instance, the N decoding threads can start working simultaneously. Another example is that L of the N decoding threads work simultaneously, with thread NL starting before the other L threads finish, where 1 ≤ L < N, and L is an integer.

[0183] If decoding PT data is considered as a single decoding task, then decoding a group of data packets can be considered as a sub-decoding task. Therefore, S1320 can be replaced by: decomposing the decoding of PT data into M sub-decoding tasks based on multiple PSB packets, each sub-decoding task including decoding data packets between two different PSBs. Further, S1330 can be replaced by: linearly executing the M sub-decoding tasks using N decoders, with each of the N decoder threads executing at least one of the M sub-decoding tasks, and different decoder threads executing different sub-decoding tasks.

[0184] For example, N minimum unit decoding threads are started, and each minimum unit full decoding thread resumes the execution instruction stream.

[0185] For example, the process of each decoding thread decoding a group of data packets is as follows: Figure 15 As shown.

[0186] First, the auxiliary information required for decoding PT data is loaded. This additional information includes one or more of the following: execdata, the modified memory portion of the modified dynamic library, and dynamic library metadata (e.g., unmodified dynamic library metadata and modified dynamic library metadata). Specifically, all necessary content is loaded in the order of execdata, the modified memory portion of the modified dynamic library, and other dynamic library metadata. The execdata and modified dynamic library metadata export the executable segments, while for other dynamic libraries, the executable segments need to be extracted. Then, based on the auxiliary information and the target program's library binaries, the corresponding binary file for the target program's loading process is determined.

[0187] Further, determine if the queue to be decoded is empty. If the queue is empty, wait for all decoding threads to finish running. If the queue is not empty, obtain the offset range of the m-th data packet group pointed to by the head pointer of the queue, and set the decoding start offset and decoding end offset accordingly. Further, perform full decoding on the m-th data packet group, which includes performing block-level decoding or instant-level decoding on the data packets included in the m-th data packet group. Further, save the decoded data and the offset range of the m-th data packet group. Then, return to the step of determining if the queue to be decoded is empty. 1 ≤ m ≤ M.

[0188] Optionally, determining whether the queue to be decoded is empty can be replaced by determining whether a decoding task (sub-decoding task) for decoding a group of data packets has been obtained. If a sub-decoding task is obtained, the decoding thread executes the sub-decoding task; if no sub-decoding task is obtained, the thread waits for all decoding threads to finish running.

[0189] Optionally, after decoding the M data packet groups, method 1300 further includes S1350: merging the decoded data. That is, merging the decoded data obtained by N decoding threads decoding the M data packet groups.

[0190] For example, the decoded data stored by N decoding threads are merged according to a preset merging rule. The preset merging rule includes: merging the decoded data in the decoding order, or merging the decoded data in a random order.

[0191] Specifically, S1350 includes, for example, Figure 16 The sub-steps shown: Add the decoded data and packet group offset ranges saved by N decoding threads to the queue to be merged; check if the queue to be merged is empty. If the queue to be merged is empty, save or output the merged decoded data and receive the decoded data merging program; if the queue to be merged is not empty, merge the decoded data pointed to by the queue head pointer according to the preset merging rules. After that, return to the step of checking if the queue to be merged is empty.

[0192] In this embodiment, the PT data is segmented into multiple data packet groups based on the PSB packet, and N decoding threads are used to decode these multiple data packet groups, which can improve the decoding speed of the PT data. Since the packet flow boundary packet can be used to identify the boundaries of fixed-length data packets, it is easier to implement the method of grouping processor tracing data based on the packet flow boundary packet, and the processing efficiency of processing processor tracing data grouping is higher.

[0193] Furthermore, according to embodiments of this application, additional information for instruction stream recovery can be collected, thereby ensuring correct decoding of PT data. It is understood that when the target program runs on different operating systems, the operating system's mechanisms may cause some bytes of the dynamic library to be replaced, or new dynamic libraries to be loaded. In this case, if the processor trace data is still decoded based on the target program's library binary file, correct decoding of the processor trace data cannot be guaranteed. Therefore, by combining additional information to determine the binary file corresponding to the target program's loading process, correct decoding of the processor trace data can be guaranteed.

[0194] Under the experimental conditions shown in Table 3, the decoding method provided in this application embodiment yields the experimental results shown in Table 4. As shown in Table 4, compared with single-threaded full decoding, the decoding method provided in this application embodiment can achieve a speed improvement of 5 to 6 times.

[0195] Table 3

[0196] Table 4

[0197] Figure 17 A schematic flowchart of a decoding method provided in another embodiment of this application is shown. Figure 17 As shown, method 1700 may include steps S1710 to S1730, each of which is described in detail below.

[0198] S1710, Identify multiple PSB packets from PT data.

[0199] S1720, determine M data packet groups based on the PSB packet. Where M≥2 and M is an integer.

[0200] Specifically, for a description of S1710 and S1720, please refer to S1310 and S1320 above.

[0201] Prior to S1710, method 1300 also includes S1740: acquiring PT data. That is, enabling IPT recording for the target program (process) to acquire PT data generated by the IPT hardware. Specifically, the PT data can be obtained by the target program through rendering a file. In other words, when the target program opens a file, the IPT hardware can record the PT data generated by the target program rendering the file.

[0202] Optionally, S1740 also includes collecting additional information for performing instruction stream recovery. For a more detailed description of collecting additional information for performing instruction stream recovery, please refer to S950 above; for brevity, it will not be elaborated upon here.

[0203] S1730 uses N decoding threads to decode M data packet groups.

[0204] Where N is a positive integer greater than 1, and N is determined based on the maximum number of cores in the processor. For example, N is equal to the maximum number of cores in the processor.

[0205] Each of the N decoding threads decodes at least one of the M packet groups, and different decoding threads decode different packet groups. Specifically, each decoding thread uses IP filtering to decode the packet groups. That is, N minimum unit decoding threads are started, and each minimum unit full decoding thread uses IP filtering to restore the execution instruction flow.

[0206] For example, the process of each decoding thread executing a sub-decoding task using IP filtering includes S1731 to S1733: S1731, the data packet group is divided into at least one segment according to the TIP packets in the data packet group, the at least one segment includes a first type segment, the first data packet of the first type segment is a TIP packet, and the number of TIP packets included in the first type segment is 1.

[0207] For example Figure 18 In (a) of the diagram, packet group 1 is divided into three first-type segments. First-type segment #1 includes TIP packet 1 and TNT packet 1; first-type segment #2 includes TIP packet 2, TNT packet 2 and TNT packet 3; and first-type segment #3 includes TIP packet 3 and TNT packet 4.

[0208] Optionally, if there are other types of data packets besides the TIP packet before the first TIP packet in the data packet group, then the at least one segment also includes a second type segment, which includes all data packets before the first TIP packet.

[0209] For example Figure 18 As shown in (b), before the first TIP packet (TIP packet 1) of data packet group 2, there are TNT packet 1 and TNT packet 2. Therefore, after segmenting PT data #2, at least one segment obtained also includes a second type segment, which includes TNT packet 1 and TNT packet 2. In addition, this at least one segment also includes two first type segments. Among them, first type segment #4 includes TIP packet 1, TNT packet 3, and TNT packet 4; first type segment #5 includes TIP packet 2 and TNT packet 5.

[0210] It should be understood that Figure 18 This example only uses two types of data packets as an example. Data packets may also include one or more of the following types of data packets: TSC, PIP, FUP, etc.

[0211] S1732, Calculate the initial IP of the first type segment based on the TIP packet in the first type segment.

[0212] For example Figure 18 In (a), for the first type segment #1, the initial IP of the first type segment #1 is calculated based on TIP packet 1 in the first type segment #1; for the first type segment #2, the initial IP of the first type segment #2 is calculated based on TIP packet 2 in the first type segment #2; for the first type segment #3, the initial IP of the first type segment #3 is calculated based on TIP packet 3 in the first type segment #3.

[0213] Optionally, if the at least one segment further includes a second type segment, then S1732 further includes: calculating the initial IP of the second type segment based on the PSB packet preceding and adjacent to the second type segment. Specifically, the initial IP of the second type segment is calculated based on the [PSB+] of the PSB packet, that is, the initial IP of the second type segment is calculated based on the data between the PSB header and PSB trailer of the PSB packet.

[0214] For example Figure 18In (b), for the second type segment, the initial IP of the second type segment is calculated based on [PSB+]; for the first type segment #4, the initial IP of the first type segment #4 is calculated based on TIP packet 1 in the first type segment #4; for the first type segment #5, the initial IP of the first type segment #5 is calculated based on TIP packet 2 included in the first type segment #5.

[0215] S1733, determine whether to perform block layer or inst layer decoding on the first type segment based on the initial IP of the first type segment.

[0216] Specifically, it is determined whether the initial IP of the first type segment is within the decoding range. If the initial IP of the first type segment is within the decoding range, the first type segment is decoded at the block layer or the instant layer. If the initial IP of the first type segment is not within the decoding range, the first type segment is not decoded at the block layer or the instant layer.

[0217] Optionally, if the at least one segment further includes a second type segment, then S1733 further includes: determining whether to perform block layer or inst layer decoding on the second type segment based on the initial IP of the second type segment.

[0218] Specifically, it is determined whether the initial IP of the second type segment is within the decoding range. If the initial IP of the second type segment is within the decoding range, the second type segment is decoded at the block layer or the instant layer. If the initial IP of the second type segment is not within the decoding range, the second type segment is not decoded at the block layer or the instant layer.

[0219] For example, in the entire process of decoding M data packet groups using N decoding threads, the processing flow of a single decoding thread is as follows: Figure 19 As shown.

[0220] First, a sub-decoding task is acquired, which involves decoding a single packet group. If acquiring a sub-decoding task fails, the decoding program exits and waits for all decoding threads to complete. If acquiring a sub-decoding task succeeds, the packet decoder is initialized, the head pointer of the queue to be decoded is obtained pointing to the offset range of the packet group, and the decoder's decoding start and end offsets are set accordingly. Further, the packet group is divided into at least one segment, and the initial IP address of each segment is calculated. Then, the packet decoder exits.

[0221] Then, the next segment is acquired. If acquiring the next segment fails, the process returns to acquiring the next sub-decoding task; if a segment is successfully acquired, it is further determined whether the initial IP of the segment is within the decoding range. If the initial IP of the segment is not within the decoding range, the process proceeds to acquire the next segment; if the initial IP of the segment is within the decoding range, the block / inst decoder is initialized. Next, the next block / inst is acquired. If acquiring the next block / inst fails, the block / instruction decoder exits, and the process proceeds to acquire the next segment; if a block / inst is successfully acquired, block / inst decoding is performed, and the decoded data and the offset range of the PT data block are saved. After block / inst decoding is complete, the process continues to acquire the next block / inst.

[0222] Optionally, if additional information for instruction stream recovery is collected, method 1700 further includes loading additional information for auxiliary PT data decoding before performing block / inst decoding. The additional information for auxiliary decoding includes one or more of the following information loaded by the target program's process: execdata, the modified memory portion of the modified dynamic library, and dynamic library metadata (e.g., unmodified dynamic library metadata and modified dynamic library metadata). Specifically, all necessary content is loaded in the order of execdata, the modified memory portion of the modified dynamic library, and other dynamic library metadata. Here, execdata and the modified dynamic library export the executable segments, while for other dynamic libraries, executable segments need to be extracted.

[0223] Furthermore, during the block / inst decoding process, additional information from the loaded auxiliary decoding is incorporated into the block / inst decoding. Specifically, the block / inst decoding process includes: determining the binary file corresponding to the target program's loading process by combining the additional information and the target program's library binary file; and performing block / inst decoding based on this binary file.

[0224] Optionally, after decoding the M data packet groups, method 1700 further includes S1750: decoding data merging. This involves merging the decoded data obtained from the sub-decoding tasks executed by the N decoding threads. For a detailed description of S1750, please refer to S1350 above.

[0225] In this embodiment, PT data is segmented into multiple packet groups based on the PSB, and N decoding threads are used to decode these packet groups, which improves the decoding speed of PT data. Since the packet flow boundary packet can be used to identify the boundaries of fixed-length packet segments, grouping processor tracing data based on the packet flow boundary packet is easier to implement and more efficient. Furthermore, during the decoding process of each packet group by each decoding thread, by dividing the packet group into at least one segment and determining whether to perform block-level decoding or instant decoding on that segment based on its initial IP, selective decoding of PT data can be achieved, further improving the decoding speed of PT data.

[0226] Under the experimental conditions shown in Table 5, the decoding method provided in this application yields the experimental results shown in Table 6. As shown in Table 6, compared with single-threaded full decoding, single-threaded selective decoding can achieve a speed improvement of 10 to 60 times. With four decoding threads, a further speed improvement of 2 to 3 times can be achieved.

[0227] Table 5

[0228] Table 6

[0229] The various embodiments described herein can be independent solutions or combinations thereof based on their inherent logic, and all such solutions fall within the protection scope of this application.

[0230] The above, combined with Figures 9 to 19 The decoding method provided in the embodiments of this application is described in detail below. Figures 20 to 22 The decoding device provided in the embodiments of this application is described in detail.

[0231] Figure 20 This is a schematic block diagram of the decoding device 2000 provided in the embodiments of this application.

[0232] Figure 20 The decoding device 2000 shown includes a decoding unit 2010.

[0233] The decoding unit 2010 can be used to execute the decoding method 900 of the embodiments of this application.

[0234] The decoding unit 2010 is used to: determine multiple TIP packets from PT data; divide the PT data into at least one segment based on the multiple TIP packets, the at least one segment including a first type segment, the first data packet of the first type segment being a TIP packet, and the number of TIP packets in the first type segment being 1; calculate the initial IP of the first type segment based on the TIP packets in the first type segment; and determine whether to perform block-level decoding or instruction-level decoding on the first type segment based on the initial IP of the first type segment.

[0235] Optionally, as an embodiment, if the initial IP of the first type segment is within the decoding range, the decoding unit 2010 is used to: perform block-level decoding or instruction-level decoding on the first type segment; if the initial IP of the first type segment is not within the decoding range, the decoding unit 2010 does not perform block-level decoding or instruction-level decoding on the first type segment.

[0236] Optionally, as an embodiment, the decoding device 2000 further includes a collection unit 2020, which is used to: collect additional information to assist in the decoding of PT data during the process of the target program obtaining PT data by rendering files. The additional information includes one or more of the following information loaded by the process of the target program: dynamic library metadata, the modified memory portion of the modified dynamic library, and data memory with execution permissions. The decoding unit 2010 is specifically used to: perform block-level decoding or instruction-level decoding on the first type segment in combination with the additional information.

[0237] Optionally, as an embodiment, the decoding unit 2020 is specifically used to: combine the additional information and the library binary file of the target program to determine the binary file corresponding to the loading process of the target program; and perform block-level decoding or instruction-level decoding on the first type segment according to the binary file.

[0238] Optionally, as an embodiment, if there are data packets of other types besides the TIP packet before the first TIP packet of the PT data, then at least one segment also includes a second type segment, the second type segment including the data packets before the first TIP packet; the decoding unit 2010 is further configured to: calculate the initial IP of the second type segment based on the PSB packet before and adjacent to the second type segment; and determine whether to perform block-level decoding or instruction-level decoding on the second type segment based on the initial IP of the second type segment.

[0239] Optionally, as an embodiment, if the initial IP of the second type segment is within the decoding range, the decoding unit 2010 is used to perform block-level decoding or instruction-level decoding on the second type segment; if the initial IP of the second type segment is not within the decoding range, the decoding unit 2010 does not perform block-level decoding or instruction-level decoding on the second type segment.

[0240] Optionally, as an embodiment, the decoding unit 2010 is specifically used to: perform block-level decoding or instruction-level decoding of the second type segment in conjunction with additional information.

[0241] Optionally, as an embodiment, the decoding unit 2020 is specifically used to: combine the additional information and the library binary file of the target program to determine the binary file corresponding to the loading process of the target program; and perform block-level decoding or instruction-level decoding on the second type segment according to the binary file.

[0242] Alternatively, as an example, the decoding range is determined based on a dynamic library used by the target program in the process of obtaining PT data by rendering files.

[0243] For example, the decoding unit 2010 may correspond to the above. Figure 5 The IP filtering and decoding module 5042 in the middle. The collection unit 2020 can correspond to the above. Figure 5 Additional information recording module 503 for auxiliary decoding.

[0244] Figure 21 This is a schematic block diagram of the decoding device 2100 provided in the embodiments of this application.

[0245] Figure 21 The decoding device 2100 shown includes a processing unit 2110 and a decoding unit 2120.

[0246] The processing unit 2110 and the decoding unit 2120 can be used to execute the decoding methods 1300 and 1700 of the embodiments of this application.

[0247] The processing unit 2110 is used to: determine multiple PSB packets from PT data, the PT data including multiple PSB packets and multiple data packets; determine M data packet groups based on the multiple PSB packets, the M data packet groups including multiple data packets, the data packets included in a data packet group are located between two different PSB packets, and the data packets included in different data packet groups are different, where M≥2, and M is an integer.

[0248] The decoding unit 2120 is used to: decode M data packet groups using N decoding threads, where each of the N decoding threads decodes at least one data packet group among the M data packet groups, and different decoding threads among the N decoding threads decode different data packet groups, where N≥2 and N is an integer.

[0249] Alternatively, as an embodiment, a packet group may include packets located between two adjacent PSB packets.

[0250] Optionally, as an embodiment, the decoding device 2100 further includes a collection unit 2130, which is used to: collect additional information to assist in the decoding of PT data during the process of the target program obtaining PT data by rendering files. The additional information includes one or more of the following information loaded by the process of the target program: dynamic library metadata, the modified memory portion of the modified dynamic library, and data memory with execution permissions; the decoding unit 2120 is specifically used to: combine the additional information and use N decoding threads to decode M data packet groups.

[0251] Optionally, as an embodiment, the decoding unit 2120 is specifically used to: combine the additional information and the library binary file of the target program to determine the binary file corresponding to the loading process of the target program; and according to the binary file, use N decoding threads to decode M data packet groups.

[0252] Optionally, as an embodiment, the decoding unit 2120 is specifically configured to: determine at least one segment based on the TIP packets in the data packet group, wherein the at least one segment includes a first type segment, the first data packet of the first type segment is a TIP packet, and the number of TIP packets in the first type segment is 1; calculate the initial IP of the first type segment based on the TIP packets in the first type segment; and determine whether to perform block-level decoding or instruction-level decoding on the first type segment based on the initial IP of the first type segment.

[0253] Optionally, as an embodiment, if the initial IP of the first type segment is within the decoding range, the decoding unit 2120 is used to: perform block-level decoding or instruction-level decoding on the first type segment; if the initial IP of the first type segment is not within the decoding range, the decoding unit 2120 does not perform block-level decoding or instruction-level decoding on the first type segment.

[0254] Optionally, as an embodiment, if there are data packets of other types besides the TIP packet before the first TIP packet of the PT data, then at least one segment also includes a second type segment, the second type segment including the data packets before the first TIP packet; the decoding unit 2120 is further configured to: calculate the initial IP of the second type segment based on the PSB packet before and adjacent to the second type segment; and determine whether to perform block-level decoding or instruction-level decoding on the second type segment based on the initial IP of the second type segment.

[0255] Optionally, as an embodiment, if the initial IP of the second type segment is within the decoding range, the decoding unit 2120 is used to perform block-level decoding or instruction-level decoding on the second type segment; if the initial IP of the second type segment is not within the decoding range, the decoding unit 2120 does not perform block-level decoding or instruction-level decoding on the second type segment.

[0256] Alternatively, as an example, the decoding range is determined based on a dynamic library used by the target program in the process of obtaining PT data by rendering files.

[0257] Optionally, as an embodiment, the decoding device 2100 further includes a merging unit 2140, which is used to merge the decoded data obtained by N decoding threads decoding M data packet groups.

[0258] For example, the processing unit 2110 may correspond to the above. Figure 5 The task decomposition module 5041 and decoding unit 2120 in the above text can correspond to the above. Figure 5 The IP filtering and decoding module 5042 in the middle. The collection unit 2130 can correspond to the above. Figure 5 The auxiliary decoding additional information recording module 503. The merging unit 2140 can correspond to the above. Figure 5 The task result merging module 5043 in the middle.

[0259] It should be noted that the aforementioned devices 2000 and 2100 are embodied in the form of functional units. The term "unit" here can be implemented in software and / or hardware, without specific limitations.

[0260] For example, a "unit" can be a software program, a hardware circuit, or a combination of both that implements the above functions. The hardware circuit may include an application-specific integrated circuit (ASIC), electronic circuitry, a processor (e.g., a shared processor, a proprietary processor, or a group processor) and memory for executing one or more software or firmware programs, integrated logic circuitry, and / or other suitable components that support the described functions.

[0261] Therefore, the units of the various examples described in the embodiments of this application can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0262] Figure 22 This is a schematic diagram of the hardware structure of the decoding device provided in the embodiments of this application. Figure 22The decoding device 2200 shown (which may specifically be a computer device) includes a memory 2201, a processor 2202, a communication interface 2203, and a bus 2204. The memory 2201, processor 2202, and communication interface 2203 are interconnected via the bus 2204.

[0263] The memory 2201 may be a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 2201 may store a program, and when the program stored in the memory 2201 is executed by the processor 2202, the processor 2202 and the communication interface 2203 are used to execute the various steps of the decoding method of the embodiments of this application.

[0264] The processor 2202 may be a general-purpose central processing unit (CPU), microprocessor, application-specific integrated circuit (ASIC), graphics processing unit (GPU), or one or more integrated circuits, used to execute related programs to achieve the functions required by the units in the apparatus of this application embodiment, or to execute the decoding method of this application method embodiment.

[0265] The processor 2202 can also be an integrated circuit chip with signal processing capabilities. In implementation, each step of the decoding method of this application can be completed by the integrated logic circuits in the hardware of the processor 2202 or by instructions in software form. The processor 2202 described above can also be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of this application can be directly embodied in the execution of the hardware decoding processor, or can be executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 2201. Processor 2202 reads the information in memory 2201 and, in conjunction with its hardware, performs the functions required by the units included in the decoding device of this application embodiment, or executes the decoding method of this application method embodiment.

[0266] Communication interface 2203 uses transceiver devices, such as, but not limited to, transceivers, to enable communication between device 2200 and other devices or communication networks. For example, communication interface 2203 can receive PT data.

[0267] Bus 2204 may include a pathway for transmitting information between various components of device 2200 (e.g., memory 2201, processor 2202, communication interface 2203).

[0268] It should be understood that the decoding unit 2010 in the decoding device 2000 is equivalent to the processor 2202 in the decoding device 2200; the collection unit 2020 can be equivalent to the communication interface 2202.

[0269] It should be understood that the processing unit 2110 and the decoding unit 2120 in the decoding device 2100 are equivalent to the processor 2202 in the decoding device 2200; the collection unit 2130 can be equivalent to the communication interface 2202.

[0270] It should be noted that, although Figure 22The illustrated device only shows the memory, processor, and communication interface. However, those skilled in the art should understand that in specific implementations, device 2200 may also include other devices necessary for normal operation. Furthermore, depending on specific needs, those skilled in the art should understand that device 2200 may also include hardware devices for implementing other additional functions. Moreover, those skilled in the art should understand that device 2200 may only include the devices necessary for implementing the embodiments of this application, and may not necessarily include... Figure 22 All the devices shown.

[0271] Those skilled in the art will 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.

[0272] It should be understood that the processor in the embodiments of this application can be a central processing unit (CPU), or it can be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc.

[0273] It should also be understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous DRAM (DDR SDRAM), enhanced synchronous DRAM (ESDRAM), synchronous linked DRAM (SLDRAM), and direct rambus RAM (DR RAM).

[0274] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0275] It should be understood that the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. A and B can be singular or plural. Additionally, the character " / " in this article generally indicates an "or" relationship between the preceding and following related objects, but it can also represent an "and / or" relationship. Please refer to the context for a more accurate understanding.

[0276] In this application, "at least one" means one or more, and "more than one" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or multiple items. For example, at least one of a, b, or c can mean: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0277] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0278] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0279] Those skilled in the art will 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.

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

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

[0282] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0283] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0284] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A decoding method, characterized in that, include: Multiple packet flow boundary packets are determined from processor trace data, which includes the multiple packet flow boundary packets and multiple data packets; M data packet groups are determined based on the plurality of packet flow boundary packets. The M data packet groups include the plurality of data packets. The data packets included in a data packet group are located between two different packet flow boundary packets, and the data packets included in different data packet groups are different. Here, M≥2, and M is an integer. N decoding threads are used to decode the M data packet groups. Each of the N decoding threads decodes at least one data packet group in the M data packet groups, and different decoding threads decode different data packet groups. The decoding includes block-level decoding or instruction-level decoding of at least a portion of the data packets included in at least a portion of the data packet groups in the M data packet groups, where N≥2 and N is an integer.

2. The method according to claim 1, characterized in that, A packet group consists of packets located between two adjacent packets from different packet stream boundaries.

3. The method according to claim 1 or 2, characterized in that, The method further includes: During the process of the target program obtaining the processor tracing data by rendering files, additional information to assist in decoding the processor tracing data is collected. The additional information includes one or more of the following information loaded by the process of the target program: dynamic library metadata, the modified memory portion of the modified dynamic library, and data memory with execution permissions. The process of using N decoding threads to decode the M data packet groups includes: Based on the additional information, the N decoding threads are used to decode the M data packet groups.

4. The method according to claim 1 or 2, characterized in that, The process of each decoding thread decoding a packet group includes: At least one segment is determined based on the target instruction pointer packet in the data packet group, the at least one segment includes a first type segment, the first data packet of the first type segment is a target instruction pointer packet, and the number of target instruction pointer packets in the first type segment is 1; Calculate the initial instruction pointer of the first type segment based on the target instruction pointer packet in the first type segment; Whether to perform block-level decoding or instruction-level decoding on the first type segment is determined based on the initial instruction pointer of the first type segment.

5. The method according to claim 4, characterized in that, The step of determining whether to perform block-level decoding or instruction-level decoding on the first type segment based on the initial instruction pointer of the first type segment includes: If the initial instruction pointer of the first type segment is within the decoding range, then the first type segment is subjected to block-level decoding or instruction-level decoding. If the initial instruction pointer of the first type segment is not within the decoding range, then the first type segment will not be decoded at the block level or instruction level.

6. The method according to claim 4, characterized in that, If there are data packets of other types besides the target instruction pointer packet before the first target instruction pointer packet in the data packet group, then the at least one segment also includes a second type segment, which includes the data packets preceding the first target instruction pointer packet; The method further includes: The initial instruction pointer of the second type segment is calculated based on the packet flow boundary packet that precedes and is adjacent to the second type segment. Whether to perform block-level decoding or instruction-level decoding on the second type segment is determined based on the initial instruction pointer of the second type segment.

7. The method according to claim 6, characterized in that, The step of determining whether to perform block-level decoding or instruction-level decoding on the second type segment based on the initial instruction pointer of the second type segment includes: If the initial instruction pointer of the second type segment is within the decoding range, then the second type segment is decoded at the block level or the instruction level. If the initial instruction pointer of the second type segment is not within the decoding range, then the second type segment will not be decoded at the block level or instruction level.

8. The method according to claim 5, characterized in that, The decoding range is determined based on a dynamic library used by the target program to obtain the processor tracking data by rendering files.

9. The method according to claim 1 or 2, characterized in that, The method further includes: The decoded data obtained by the N decoding threads decoding the M data packet groups is combined.

10. A decoding device, characterized in that, Includes a processing unit and a decoding unit. The processing unit is configured to: determine multiple packet flow boundary packets from processor tracking data, wherein the processor tracking data includes the multiple packet flow boundary packets and multiple data packets; The processing unit is further configured to: determine M data packet groups based on the plurality of packet flow boundary packets, wherein the M data packet groups include the plurality of data packets, and the data packets included in a data packet group are located between two different packet flow boundary packets, and the data packets included in different data packet groups are different, wherein M≥2, and M is an integer; The decoding unit is configured to: use N decoding threads to decode the M data packet groups, each of the N decoding threads decoding at least one data packet group in the M data packet groups, and different decoding threads in the N decoding threads decoding different data packet groups, the decoding including block-level decoding or instruction-level decoding of at least a portion of the data packets included in at least a portion of the data packet groups in the M data packet groups, where N≥2 and N is an integer.

11. The decoding device according to claim 10, characterized in that, A packet group consists of packets located between two adjacent packets from different packet stream boundaries.

12. The decoding apparatus according to claim 10 or 11, characterized in that, The decoding device further includes a collection unit, which is used to: collect additional information to assist in decoding the processor tracking data during the process of the target program obtaining the processor tracking data by rendering files. The additional information includes one or more of the following information loaded by the process of the target program: dynamic library metadata, the modified memory portion of the modified dynamic library, and data memory with execution permissions. The decoding unit is specifically used for: Based on the additional information, the N decoding threads are used to decode the M data packet groups.

13. The decoding apparatus according to claim 10 or 11, characterized in that, During the decoding process of each decoding thread for a group of data packets, the decoding unit is specifically used for: At least one segment is determined based on the target instruction pointer packet in the data packet group, the at least one segment includes a first type segment, the first data packet of the first type segment is a target instruction pointer packet, and the number of target instruction pointer packets in the first type segment is 1; Calculate the initial instruction pointer of the first type segment based on the target instruction pointer packet in the first type segment; Whether to perform block-level decoding or instruction-level decoding on the first type segment is determined based on the initial instruction pointer of the first type segment.

14. The decoding apparatus according to claim 13, characterized in that, The decoding unit is specifically used for: If the initial instruction pointer of the first type segment is within the decoding range, then the first type segment is subjected to block-level decoding or instruction-level decoding. If the initial instruction pointer of the first type segment is not within the decoding range, then the first type segment will not be decoded at the block level or instruction level.

15. The decoding apparatus according to claim 13, characterized in that, If there are data packets of other types besides the target instruction pointer packet before the first target instruction pointer packet in the data packet group, then the at least one segment also includes a second type segment, which includes the data packets preceding the first target instruction pointer packet; The decoding unit is also used for: The initial instruction pointer of the second type segment is calculated based on the packet flow boundary packet that precedes and is adjacent to the second type segment. Whether to perform block-level decoding or instruction-level decoding on the second type segment is determined based on the initial instruction pointer of the second type segment.

16. The decoding apparatus according to claim 15, characterized in that, The decoding unit is specifically used for: If the initial instruction pointer of the second type segment is within the decoding range, then the second type segment is decoded at the block level or the instruction level. If the initial instruction pointer of the second type segment is not within the decoding range, then the second type segment will not be decoded at the block level or instruction level.

17. The decoding apparatus according to claim 14, characterized in that, The decoding range is determined based on a dynamic library used by the target program to obtain the processor tracking data by rendering files.

18. The decoding apparatus according to claim 10 or 11, characterized in that, The decoding device further includes a merging unit, the merging unit being used for: The decoded data obtained by the N decoding threads decoding the M data packet groups is combined.

19. A decoding device, characterized in that, It includes a processor and a memory, the memory being used to store program instructions, and the processor being used to invoke the program instructions to perform the method of any one of claims 1 to 9.

20. A computer-readable storage medium, characterized in that, The computer-readable medium stores program code for execution by the device, the program code including methods for performing any one of claims 1 to 9.

21. A computer program product, characterized in that, Includes a program or instructions that, when run on a computer, cause the computer to perform the method as described in any one of claims 1 to 9.

22. A chip, characterized in that, The chip includes a processor and a data interface. The processor reads instructions stored in the memory through the data interface to execute the method as described in any one of claims 1 to 9.

Images