AI-driven wireless debugging port security forwarding method and system

Abstract

This invention relates to the field of network security technology, and in particular to an AI-driven secure forwarding method and system for wireless debugging ports. By scanning debugging devices and matching protocol conversion strategies, a virtual debugging interface is created. A session identifier and a dynamic encryption key are generated. Debug data is parsed, encrypted, and used to generate encrypted debugging frames for transmission. Upon receiving an encrypted response frame, it is decrypted, converted to a different protocol format, and then transmitted to the debugging host. This achieves protocol adaptation and dynamically encrypted secure transmission of debugging data, improving the security and compatibility of the wireless debugging process.

Description

Technical Field

[0001] This invention relates to the field of network security technology, and in particular to an AI-driven secure forwarding method and system for wireless debugging ports. Background Technology

[0002] In fields such as industrial automation, embedded system development, and network equipment maintenance, technicians frequently need to perform on-site debugging of various debugging devices. Traditional debugging methods mainly rely on wired physical connections, such as directly connecting the debugging host to the target device via serial ports, JTAG, or Ethernet cables. This method requires technicians to be physically present at the equipment site to perform physical contact and wiring operations. When equipment is deployed in dispersed locations, confined spaces, or hazardous environments, this significantly reduces the efficiency and flexibility of debugging work and increases personnel safety risks.

[0003] With the popularization of wireless communication technology, a solution has emerged that uses general-purpose wireless modules for transparent transmission of debug data. This type of solution typically involves installing a wireless adapter on the debug host and integrating a corresponding wireless module on the target debug device, replacing the original wired debug link with a wireless link. However, this conventional wireless forwarding method merely achieves transparent transmission of debug data, simply converting wired signals into wireless signals for sending and receiving, lacking in-depth consideration of the security and protocol compatibility of the debug session itself.

[0004] Existing conventional practices have significant drawbacks. Firstly, their security is severely inadequate. Debug ports often carry critical control commands and sensitive internal status data of the device, while conventional wireless pass-through solutions mostly fail to encrypt debug data transmitted over the air, or only use fixed, pre-configured weak keys for simple encryption. This makes debug data extremely vulnerable to eavesdropping, interception, and even tampering in the wireless channel. Attackers could gain control of the device, steal core algorithms, or inject malicious commands, posing serious security risks. Secondly, their protocol adaptability is rigid. Different debug devices may use drastically different debug interface protocols, such as UART, SWD, and I2C, and even the electrical characteristics and data frame formats of the same protocol may differ. Conventional solutions typically require custom hardware converters or firmware for each specific device protocol, lacking a flexible, adaptive protocol conversion mechanism. This results in the need for a large amount of conversion hardware when dealing with a wide variety of debug devices, leading to poor system compatibility and deployment convenience. Summary of the Invention

[0005] This invention provides an AI-driven secure forwarding method and system for wireless debugging ports, which can solve the problems in the prior art.

[0006] A first aspect of this invention provides an AI-driven secure forwarding method for wireless debugging ports, comprising: The wireless communication module scans the surrounding debugging devices and obtains the device characteristic information of each debugging device. Based on the device characteristic information, the corresponding protocol conversion strategy is matched from the pre-stored protocol adaptation rule base. Based on the protocol conversion strategy, a virtual debugging interface corresponding to the debugging interface protocol type of the target debugging device is created on the debugging host side. When a debug session establishment request for the virtual debug interface is detected, a session identifier is generated by combining the device feature information and the current time information, and a dynamic encryption key for the debug session is generated by the key derivation function based on the session identifier. The system intercepts the raw debugging data sent by the debugging host to the virtual debugging interface, performs protocol field parsing on the raw debugging data to extract the debugging command field and data payload field, and uses the dynamic encryption key to perform encryption operations on the debugging command field and data payload field respectively to generate an encrypted debugging frame. The session identifier and encryption algorithm identifier information are encapsulated in the encrypted debugging frame, and the encapsulated encrypted debugging frame is transmitted to the target debugging device through the wireless communication module. The system receives an encrypted response frame returned by the target debugging device, extracts the session identifier from the encrypted response frame and finds the corresponding dynamic encryption key, uses the dynamic encryption key to decrypt the encrypted response frame to obtain response data, converts the response data into a protocol format recognizable by the debugging host according to the protocol conversion strategy, and transmits it to the debugging host through the virtual debugging interface.

[0007] Based on the device characteristic information, a corresponding protocol conversion strategy is matched from a pre-stored protocol adaptation rule base, and a virtual debugging interface corresponding to the debugging interface protocol type of the target debugging device is created on the debugging host side according to the protocol conversion strategy, including: The hardware architecture type, operating system type, and debugging interface protocol type of the device feature information are combined to form a multi-dimensional feature index key. The multi-dimensional feature index key is used to perform a query and match in the protocol adaptation rule base. The protocol conversion strategy corresponding to the multi-dimensional feature index key is obtained from the protocol adaptation rule base. The protocol conversion strategy includes a debugging command mapping table, data frame format conversion rules, and protocol handshake sequence template. According to the debugging interface protocol type, the corresponding virtual interface configuration parameters are extracted from the protocol conversion strategy. The virtual interface configuration parameters include interface communication rate configuration information, data bit width configuration information, and handshake timing configuration information. A virtual device driver module is registered in the operating system kernel layer of the debugging host. The virtual device driver module creates the virtual debugging interface according to the virtual interface configuration parameters, so that the virtual debugging interface is presented on the debugging host side as a physical debugging interface corresponding to the debugging interface protocol type of the target debugging device.

[0008] The process involves querying and matching the protocol adaptation rule base using the multi-dimensional feature index key, and retrieving the protocol conversion strategy corresponding to the multi-dimensional feature index key from the protocol adaptation rule base, including: Calculate the feature hash value of each technical feature dimension in the multi-dimensional feature index key, and perform a combination operation on the feature hash values ​​of each technical feature dimension to generate a composite hash index; The composite hash index is used to perform a matching search in the index structure of the protocol adaptation rule base. When a match is successful, the corresponding protocol conversion strategy is directly obtained. When the composite hash index fails to match precisely, the matching constraints of the technical feature dimension in the multi-dimensional feature index key are reduced in turn, and fuzzy matching search is performed according to the priority order of debugging interface protocol type, operating system type, and hardware architecture type. For the multiple candidate protocol conversion strategies obtained by fuzzy matching, the feature similarity score between each candidate protocol conversion strategy and the multi-dimensional feature index key is calculated, and the candidate protocol conversion strategy with the highest feature similarity score is selected as the final matching result.

[0009] Using the session identifier as the input seed of the key derivation function, and combining it with a preset salt value parameter, the key derivation function performs a key expansion operation to generate a dynamic encryption key specifically for the debugging session, including: Read the salt value parameter corresponding to the debugging interface protocol type from the pre-stored salt value parameter library. The salt value parameter includes a fixed salt value component and a random salt value component. Perform a byte-level XOR operation between the session identifier and the salt parameter to generate the initial input vector for the key derivation function; The initial input vector is input into the key derivation function, and the initial input vector is expanded through multiple rounds of iterative hashing operations inside the key derivation function. The output of each round of iterative hashing is used as the input of the next round of iterative hashing. When the iterative hashing operation reaches a preset iteration round threshold, a byte sequence of a preset length is extracted from the output of the last iteration hashing operation, and the byte sequence is used as a dynamic encryption key for the debugging session. Establish a mapping relationship between the session identifier and the dynamic encryption key, and store the mapping relationship in the session key management table.

[0010] The process involves intercepting raw debugging data sent from the debugging host to the virtual debugging interface, parsing the protocol fields of the raw debugging data to extract the debugging command field and the data payload field, and using the dynamic encryption key to perform encryption operations on the debugging command field and the data payload field respectively to generate an encrypted debugging frame, including: A data interception layer is set between the virtual debugging interface and the debugging host, and the original debugging data sent by the debugging host to the virtual debugging interface is intercepted through the data interception layer; Based on the data frame format conversion rules in the protocol conversion strategy, identify the byte boundary positions of the frame header field and check field of the original debug data; The debug command field and the data payload field are separated and extracted from the original debug data according to the byte boundary positions; The first encryption operation is performed on the debug command field using the dynamic encryption key to generate the encrypted command field, and the second encryption operation is performed on the data payload field to generate the encrypted payload field. The frame header field, the encryption command field, and the encryption payload field are sequentially encapsulated according to the predefined encrypted debugging frame structure, and the verification value of the encapsulated data is calculated and filled into the verification field to form the encrypted debugging frame.

[0011] The process includes receiving an encrypted response frame returned by the target debugging device, extracting the session identifier from the encrypted response frame and finding the corresponding dynamic encryption key, using the dynamic encryption key to decrypt the encrypted response frame to obtain response data, converting the response data into a protocol format recognizable by the debugging host according to the protocol conversion strategy, and transmitting it to the debugging host through the virtual debugging interface. The wireless communication module receives the encrypted response frame returned by the target debugging device and extracts the session identifier and encryption algorithm identifier information from a predetermined position in the encrypted response frame. Using the session identifier as the index key, the corresponding dynamic encryption key is queried in the session key management table. The decryption algorithm type is determined according to the encryption algorithm identification information. The encrypted data part in the encrypted response frame is decrypted using the dynamic encryption key and the decryption algorithm type to obtain response data containing response command field and response payload field. According to the debug command mapping table in the protocol conversion strategy, the response command field and response payload field in the response data are converted into a protocol format that the debug host can recognize, generating converted response data. The converted response data is written into the data output buffer of the virtual debug interface and transmitted to the debug host through the virtual debug interface.

[0012] A second aspect of the present invention provides an AI-driven secure forwarding system for wireless debugging ports, comprising: The device scanning unit is used to scan the surrounding debugging devices through the wireless communication module and obtain the device characteristic information of each debugging device. Based on the device characteristic information, it matches the corresponding protocol conversion strategy from the pre-stored protocol adaptation rule base, and creates a virtual debugging interface on the debugging host side that corresponds to the debugging interface protocol type of the target debugging device according to the protocol conversion strategy. The dynamic key unit is used to generate a session identifier by combining the device feature information and the current time information when a debugging session establishment request of the virtual debugging interface is detected, and to generate a dynamic encryption key for the debugging session based on the session identifier through a key derivation function. The debugging data unit is used to intercept the raw debugging data sent by the debugging host to the virtual debugging interface, perform protocol field parsing on the raw debugging data to extract the debugging command field and data payload field, and use the dynamic encryption key to perform encryption operations on the debugging command field and data payload field respectively to generate an encrypted debugging frame. An encrypted frame encapsulation unit is used to encapsulate the session identifier and encryption algorithm identification information in the encrypted debug frame, and transmit the encapsulated encrypted debug frame to the target debug device through the wireless communication module. The response decryption unit is used to receive the encrypted response frame returned by the target debugging device, extract the session identifier from the encrypted response frame and find the corresponding dynamic encryption key, use the dynamic encryption key to perform decryption operation on the encrypted response frame to obtain response data, convert the response data into a protocol format that the debugging host can recognize according to the protocol conversion strategy, and transmit it to the debugging host through the virtual debugging interface.

[0013] A third aspect of the present invention provides an electronic device, comprising: processor; Memory used to store processor-executable instructions; The processor is configured to invoke instructions stored in the memory to execute the aforementioned method.

[0014] A fourth aspect of the present invention provides a computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, implement the aforementioned method.

[0015] This method enables secure wireless access to the debugging port, effectively isolating the direct exposure risks of physical debugging interfaces. Through protocol adaptation and virtual interface technology, it is compatible with the proprietary protocols of various heterogeneous debugging devices, allowing traditional wired debugging hosts to seamlessly connect to wireless debugging environments without requiring modifications to existing host software or hardware. A dynamic session key mechanism provides independent encryption for each debugging session. The session identifier generated by combining timestamps and device characteristics ensures the uniqueness and timeliness of the key, preventing security risks associated with key reuse.

[0016] Fine-grained protocol parsing and field-level encryption are applied to debug data, enabling separate encryption protection for commands and data. This fine-grained encryption method provides targeted protection for sensitive parts of debug commands while maintaining the encapsulation of the protocol structure. Encrypted debug frames embed session and algorithm identifiers, allowing the receiver to automatically match decryption strategies, ensuring reliable connection and efficient processing of encrypted communication.

[0017] Debugging data during wireless transmission is always stored in encrypted form. Even if the signal is intercepted, it cannot be directly parsed to extract valid instructions or data content, significantly improving data confidentiality during debugging. Response data is also encrypted on the target device side before being transmitted back, forming a two-way encrypted channel that effectively resists man-in-the-middle attacks and data eavesdropping. The protocol conversion mechanism ensures that the decrypted response data can be correctly recognized by the debugging host, maintaining the integrity of the debugging logic. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating an AI-driven secure forwarding method for wireless debugging ports. Figure 2 A flowchart illustrating the process of generating encrypted debug frames. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] The technical solution of the present invention will be described in detail below with reference to specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0021] Figure 1 This is a flowchart illustrating the AI-driven secure forwarding method for wireless debugging ports according to an embodiment of the present invention. Figure 1 As shown, the AI-driven secure forwarding method for wireless debugging ports includes: The wireless communication module scans the surrounding debugging devices and obtains the device characteristic information of each debugging device. Based on the device characteristic information, the corresponding protocol conversion strategy is matched from the pre-stored protocol adaptation rule base. Based on the protocol conversion strategy, a virtual debugging interface corresponding to the debugging interface protocol type of the target debugging device is created on the debugging host side. When a debug session establishment request for the virtual debug interface is detected, a session identifier is generated by combining the device feature information and the current time information, and a dynamic encryption key for the debug session is generated by the key derivation function based on the session identifier. The system intercepts the raw debugging data sent by the debugging host to the virtual debugging interface, performs protocol field parsing on the raw debugging data to extract the debugging command field and data payload field, and uses the dynamic encryption key to perform encryption operations on the debugging command field and data payload field respectively to generate an encrypted debugging frame. The session identifier and encryption algorithm identifier information are encapsulated in the encrypted debugging frame, and the encapsulated encrypted debugging frame is transmitted to the target debugging device through the wireless communication module. The system receives an encrypted response frame returned by the target debugging device, extracts the session identifier from the encrypted response frame and finds the corresponding dynamic encryption key, uses the dynamic encryption key to decrypt the encrypted response frame to obtain response data, converts the response data into a protocol format recognizable by the debugging host according to the protocol conversion strategy, and transmits it to the debugging host through the virtual debugging interface.

[0022] For example, matching the corresponding protocol conversion strategy from a pre-stored protocol adaptation rule base based on the device feature information, and creating a virtual debugging interface on the debugging host side corresponding to the debugging interface protocol type of the target debugging device according to the protocol conversion strategy, including: The hardware architecture type, operating system type, and debugging interface protocol type of the device feature information are combined to form a multi-dimensional feature index key. The multi-dimensional feature index key is used to perform a query and match in the protocol adaptation rule base. The protocol conversion strategy corresponding to the multi-dimensional feature index key is obtained from the protocol adaptation rule base. The protocol conversion strategy includes a debugging command mapping table, data frame format conversion rules, and protocol handshake sequence template. According to the debugging interface protocol type, the corresponding virtual interface configuration parameters are extracted from the protocol conversion strategy. The virtual interface configuration parameters include interface communication rate configuration information, data bit width configuration information, and handshake timing configuration information. A virtual device driver module is registered in the operating system kernel layer of the debugging host. The virtual device driver module creates the virtual debugging interface according to the virtual interface configuration parameters, so that the virtual debugging interface is presented on the debugging host side as a physical debugging interface corresponding to the debugging interface protocol type of the target debugging device.

[0023] During actual system debugging operation, the device feature information scanned and acquired by the wireless communication module typically contains multiple dimensions of technical parameters. For this device feature information, it is necessary to accurately match the policy configuration that enables protocol conversion from the protocol adaptation rule base. Specifically, this involves extracting parameter information from three core dimensions: hardware architecture type, operating system type, and debug interface protocol type. Hardware architecture type may include different types such as ARM, x86, MIPS, or RISC-V; operating system type may cover embedded Linux, FreeRTOS, VxWorks, or bare-metal systems; and debug interface protocol type may include JTAG, SWD, UART, or SPI debug protocols. These three dimensions of parameter values ​​are combined according to predetermined format rules to form a unique multi-dimensional feature index key. For example, when the hardware architecture type is ARM Cortex-M4, the operating system type is FreeRTOS, and the debug interface protocol type is SWD, this information can be encoded as: The index key format of "ARM_CM4-FreeRTOS-SWD".

[0024] The generated multi-dimensional feature index keys are used to perform query matching operations in the protocol adaptation rule base. The protocol adaptation rule base adopts a key-value pair storage structure, with each index key corresponding to a complete protocol conversion strategy configuration. The query process first performs exact matching; if an exact match exists, the corresponding protocol conversion strategy is returned directly. If an exact match fails, a fuzzy matching mechanism is initiated, progressively relaxing the matching conditions according to the priority order of hardware architecture type, debug interface protocol type, and operating system type, selecting the protocol conversion strategy with the highest similarity from the rule base. The protocol conversion strategy, as a structured dataset, includes three key components: a debug command mapping table, data frame format conversion rules, and protocol handshake sequence templates.

[0025] The debug command mapping table defines the command conversion relationships between different debug interface protocols. Taking the conversion from JTAG to SWD as an example, the mapping table records that the JTAG IR-SCA7 command corresponds to the SWD wire protocol read / write operation, and the JTAG DR-SCA7 command corresponds to the SWD data register access sequence. The mapping table adopts a bidirectional mapping mechanism, including not only the forward mapping from the debug host-side protocol to the target device-side protocol, but also the reverse mapping rules when response data is returned, ensuring that commands and responses can be correctly converted during bidirectional communication. The data frame format conversion rules describe in detail the differences in frame structure between different protocols and the conversion methods. JTAG protocol data frames typically contain a command header, address field, data field, and parity bit, while SWD protocol data packets use a structure of start bit, APnDP flag bit, read / write flag bit, address field, parity bit, ACK response bit, data field, and parity bit. The conversion rules clearly specify how to map each field of the source protocol to the corresponding position of the target protocol, including specific operations such as field width adjustment, byte order conversion, and parity algorithm replacement.

[0026] The protocol handshake sequence template defines the necessary initialization interaction process for establishing a debug session. Different debug protocols exhibit significant differences in the handshake process during session establishment. The SWD protocol requires sending a specific line reset sequence and a JTAG-to-SWD switching sequence, while the JTAG protocol requires performing a TAP state machine reset and IDCODE read operation. The handshake sequence template records the command content, expected response, timeout time, and exception handling strategy for each step in the form of a sequence diagram, providing a standardized operating procedure for subsequent session establishment.

[0027] After obtaining the complete protocol conversion strategy, the virtual interface configuration parameters are extracted from the strategy configuration based on the debug interface protocol type of the target debug device. The debug interface protocol type serves as a key index, pointing to the specific configuration data segment stored in the protocol conversion strategy. The virtual interface configuration parameters contain three core types of configuration information. The interface communication rate configuration information specifies the clock frequency or baud rate setting when the virtual debug interface communicates with the debug host. For JTAG interfaces, this is typically set to a clock frequency in the range of 1MHz to 20MHz, and for UART interfaces, it is set to a baud rate in the range of 9600bps to 921600bps. The communication rate needs to match the actual supported rate of the target debug device to avoid communication failures due to rate mismatch. The data bit width configuration information defines the data transmission bit width parameters, including the number of bits per frame, the start bit, and the stop bit configuration. JTAG interfaces typically use serial transmission with a data bit width of 1 bit, while some parallel debug interfaces may support 8-bit or 16-bit parallel data transmission. The handshake timing configuration information describes timing parameters related to the interface's electrical characteristics, including setup time, hold time, propagation delay, and signal rise and fall times. These timing parameters directly affect signal integrity and communication reliability, and must be precisely configured according to the hardware specifications of the target device.

[0028] The virtual device driver module is registered at the operating system kernel layer of the debugging host. The operating system kernel provides a device driver framework, allowing the dynamic loading and registration of new device drivers. The virtual device driver module exists as a kernel module, declaring a new debugging device to the system through the driver registration interface provided by the kernel. The registration process requires filling in the device driver structure, including information such as device name, device type, major device number, and supported operation function set. The device type is identified as a debug interface class device, and the major device number is obtained through the kernel's dynamic allocation mechanism to avoid conflicts with existing device numbers. The operation function set defines the interface functions provided by the driver module, including functions for opening the device, closing the device, reading data, writing data, and control commands. These functions serve as the entry point for the debugging host-side application to interact with the virtual debug interface, and are responsible for receiving debug commands and transmitting debug data.

[0029] The virtual device driver module performs the creation operation of the virtual debug interface based on the extracted virtual interface configuration parameters. The creation process involves allocating necessary data structures and buffer resources in kernel space. Independent data receive and transmit buffers are allocated for the virtual debug interface; the buffer size is determined by the maximum length of the data frame in the debug interface protocol, typically set to 4KB to 16KB. Interface communication rate configuration information is written to the virtual interface's clock configuration register. For virtual interfaces simulating hardware clocks, clock signals are generated using a software timer. Data bit width configuration information determines the data packing and unpacking processing method; the virtual interface's data processing logic adjusts the data serialization and deserialization algorithms according to the bit width parameters. Handshake timing configuration information is applied to the virtual interface's state machine control logic to ensure that the virtual interface strictly adheres to timing constraints when receiving and sending data, satisfying setup and hold time requirements by inserting appropriate delay operations.

[0030] Once the virtual debug interface is created, it appears as a standard debug interface device in the debug host's device manager. Debugging software tools on the debug host side, such as the GDB debugger, OpenOCD tools, or vendor-provided dedicated debugging tools, can establish a connection with the virtual debug interface through a standard device access interface, completely unaware of the underlying wireless transmission and protocol conversion mechanisms. The virtual debug interface provides upper-layer applications with a programming interface and behavioral characteristics completely consistent with the physical debug interface. Debugging commands sent by the debug tool enter the kernel space through the virtual interface's write function, where the virtual device driver module handles the subsequent protocol conversion and wireless transmission process. Response data returned by the target debug device, after wireless reception, decryption, and protocol reverse conversion, is returned to the debug tool through the virtual interface's read function, achieving transparent end-to-end debug communication.

[0031] The protocol type of the virtual debug interface strictly corresponds to the actual interface protocol type of the target debug device. When the target device uses the SWD interface, the virtual debug interface is of type SWD, supporting all commands and operation modes specified by the SWD protocol. When the target device uses the JTAG interface, the virtual debug interface is of type JTAG, implementing the complete state machine and instruction set of the JTAG protocol. This precise correspondence of protocol types ensures that the software tools on the debug host side can use debug strategies and algorithms optimized for specific protocols, fully leveraging the technical advantages of different debug protocols and improving debug efficiency and diagnostic capabilities. The configuration parameters of the virtual interface can be dynamically adjusted according to actual debug needs. Through the control command interface, users or debug tools can modify parameters such as communication rate and data format at runtime to adapt to the performance and stability requirements under different debug scenarios.

[0032] For example, querying and matching in the protocol adaptation rule base using the multi-dimensional feature index key, and obtaining the protocol conversion strategy corresponding to the multi-dimensional feature index key from the protocol adaptation rule base, includes: Calculate the feature hash value of each technical feature dimension in the multi-dimensional feature index key, and perform a combination operation on the feature hash values ​​of each technical feature dimension to generate a composite hash index; The composite hash index is used to perform a matching search in the index structure of the protocol adaptation rule base. When a match is successful, the corresponding protocol conversion strategy is directly obtained. When the composite hash index fails to match precisely, the matching constraints of the technical feature dimension in the multi-dimensional feature index key are reduced in turn, and fuzzy matching search is performed according to the priority order of debugging interface protocol type, operating system type, and hardware architecture type. For the multiple candidate protocol conversion strategies obtained by fuzzy matching, the feature similarity score between each candidate protocol conversion strategy and the multi-dimensional feature index key is calculated, and the candidate protocol conversion strategy with the highest feature similarity score is selected as the final matching result.

[0033] To improve query efficiency and ensure matching accuracy when performing matching searches in the protocol adaptation rule base, a hierarchical matching mechanism based on feature hashing is adopted. Specifically, hash operations are performed on each technical feature dimension of the multi-dimensional feature index key. For the debug interface protocol type feature, the CRC32 algorithm is used to hash the protocol identifier string, obtaining a 32-bit hash value. Based on the operating system type characteristics, the operating system version number and kernel version information are extracted, and the first 32 bits of the MD5 algorithm are used as the feature hash value for this dimension. Based on the hardware architecture type characteristics, the processor architecture identifier, bit width information, and byte order information are concatenated to calculate the SHA-256 hash value, and the first 32 bits are used as the hash value. This multi-dimensional hashing method can reduce the impact of changes in a single dimension feature on the overall index while maintaining feature distinctiveness.

[0034] After calculating the hash values ​​of each dimension's features, a composite hash index is generated through combination operations. Specifically, a bitwise XOR combination method is used to combine the hash values ​​of the three dimensions according to... The features are combined in a specific way. This combination method ensures that each dimension of feature occupies a different bit field space in the composite index, avoiding mutual interference between feature values ​​of different dimensions. The resulting composite hash index... Use it as the primary key of the protocol adaptation rule base index structure for querying.

[0035] The protocol adaptation rule base uses a hierarchical index structure to store protocol conversion strategies. The first layer is a fast location layer based on a composite hash index, using a hash table structure to store complete matches. Each index entry in this layer contains a composite hash index value, a protocol conversion strategy identifier, the policy content storage address, and an access counter. Queries directly use the generated rules. The key is used to retrieve the entry from the hash table. When a corresponding entry exists in the hash table and the complete feature vector of that entry is exactly the same as the multi-dimensional feature index key, it is determined to be an exact match. The corresponding protocol conversion strategy content is then read directly from the storage address, and the access counter of that entry is incremented by 1 for subsequent cache optimization.

[0036] When a query using the composite hash index fails in the first-level fast location layer, a hierarchical fuzzy matching mechanism is activated. The fuzzy matching process prioritizes technical feature dimensions according to their importance. The debug interface protocol type is the highest priority dimension because different protocol types have fundamental differences in data frame format, command structure, and communication timing. The operating system type is the second priority dimension, affecting system call interfaces and debug symbol resolution methods. The hardware architecture type is the third priority dimension, primarily affecting register layout and instruction format.

[0037] During the first round of fuzzy matching, the matching constraints of the debug interface protocol type feature dimension are maintained, while the constraints of operating system type and hardware architecture type are relaxed. Specifically, in the second-level index structure of the protocol adaptation rule base, the feature hash value of the debug interface protocol type is used... An index tree is built for the key. All entries in this index tree are traversed, and these entries are used as a set of candidate protocol conversion strategies. If the candidate set obtained in this round of search is empty, the next round of constraint relaxation is performed. During the second round of fuzzy matching, the constraints are further relaxed to only retain the matching requirements for the debug interface protocol type and operating system type. In the third-level index structure, using... Range queries are performed using tuples as keys. Fuzzy matching is allowed when operating system types have the same major version number, achieved through mask operations. Only the major version number is retained for matching. This round of searching can cover matching failures caused by minor differences in operating system versions.

[0038] During the third round of fuzzy matching, only the mandatory constraints of the debug interface protocol type dimension are retained. At this point, the conversion strategies for all matching protocol types are retrieved in the fourth-level index structure, no longer restricted by operating system and hardware architecture. This round of search can obtain a general conversion strategy for that protocol type. Although runtime adaptation may be required in actual use, it can serve as a fallback matching solution.

[0039] For multiple candidate protocol conversion strategies obtained during fuzzy matching, feature similarity scores need to be calculated to select the optimal match. The feature similarity score comprehensively considers the matching degree of each technical feature dimension and adopts a weighted calculation method. The weight of the debug interface protocol type dimension is set to 0.5, the weight of the operating system type dimension is 0.3, and the weight of the hardware architecture type dimension is 0.2. For each candidate strategy, its similarity score on each dimension is calculated.

[0040] The similarity calculation for the debug interface protocol type dimension uses an exact match method. A score of 1.0 is awarded when the protocol types are completely identical, and 0 otherwise. The similarity calculation for the operating system type dimension considers version compatibility. A score of 1.0 is awarded when the operating systems are completely identical, 0.8 when the major version numbers are the same, 0.5 when they belong to the same operating system family but have different major versions, and 0 when they belong to different operating systems. The similarity calculation for the hardware architecture type dimension considers instruction set compatibility. A score of 1.0 is awarded when the architectures are completely identical, 0.7 when they belong to the same architecture family but have different bit widths, 0.4 when the instruction sets are partially compatible, and 0 when they are completely incompatible.

[0041] The comprehensive feature similarity score of the candidate strategy is obtained by multiplying the similarity scores of each dimension by their corresponding weights and then summing them. candidate The algorithm iterates through all candidate strategies, calculates their scores, and selects the strategy with the highest score as the final matching result. When multiple candidate strategies have the same highest score, it further compares the access frequency statistics of these strategies, prioritizing the strategy with higher historical usage frequency. This frequency-based selection leverages usage patterns in real-world applications to improve matching effectiveness.

[0042] After obtaining the final matched protocol conversion strategy, key configuration information such as the protocol conversion rule set, data format mapping table, command sequence conversion template, and exception handling strategy are parsed from the strategy content. This information will be used for subsequent virtual debugging interface creation, data frame format conversion, and communication flow control. Simultaneously, the association between the multi-dimensional feature index key of this successful match and the protocol conversion strategy is updated in the hash table of the first-layer fast location layer, establishing a new precise matching entry. This prevents subsequent identical feature combinations from triggering the fuzzy matching process again, thereby optimizing overall query performance.

[0043] To ensure the query efficiency of the protocol adaptation rule base, an index structure cache is dynamically maintained during system operation. For frequently accessed protocol conversion strategies, a hot data cache is established in memory. The cache employs an LRU (Least Recently Used) eviction policy, prioritizing the eviction of the least recently used entries when cache space is insufficient. Each query operation first searches the cache; if a cache hit occurs, the result can be returned directly without accessing the complete index structure, significantly reducing query latency. The cache capacity is dynamically adjusted based on available system memory, typically configured to accommodate 20 to 50 of the most frequently used protocol conversion strategies, covering the query needs of most real-world application scenarios.

[0044] For example, a session identifier is generated by combining the device feature information and the current time information, and a dynamic encryption key for the debugging session is generated based on the session identifier through a key derivation function, including: A data flow monitoring hook is set in the data input buffer of the virtual debugging interface, and the debugging data flow sent from the debugging host to the virtual debugging interface is captured in real time through the data flow monitoring hook; The captured debug data stream is subjected to protocol frame header feature recognition. When the debug data stream contains a feature field of debug session establishment request, the session identifier generation process is triggered. Extract the hardware architecture type identifier, operating system type identifier, and debug interface protocol type identifier from the device feature information, and obtain the timestamp corresponding to the current time information; The hardware architecture type identifier, operating system type identifier, debug interface protocol type identifier, and timestamp are concatenated and combined, and a hash operation is performed on the concatenated and combined data to generate the session identifier; Using the session identifier as the input seed of the key derivation function, and combining it with a preset salt value parameter, the key derivation function performs a key expansion operation to generate a dynamic encryption key specifically for the debugging session.

[0045] When setting up a data flow monitoring hook in the data input buffer of the virtual debug interface, a callback function needs to be registered at the operating system kernel layer or user-space driver layer. The implementation of the data flow monitoring hook relies on the hook mechanism provided by the target operating system. In Linux systems, packet interception can be achieved through the 7etfilter framework or kernel modules, while in Windows systems, it can be achieved using the 7DIS intermediate layer driver or user-space filter driver. Registering the data flow monitoring hook requires specifying the identifier of the monitored virtual debug interface, setting the data flow capture direction to inbound, and configuring the packet capture priority parameters. The hook function is triggered each time data is written to the input buffer of the virtual debug interface, copying the captured raw data flow to a dedicated analysis buffer for subsequent processing. To avoid delays in normal debug data transmission, the data flow monitoring hook adopts an asynchronous processing mode. The captured data flow is passed to the analysis module through a circular buffer queue; the hook function itself does not block the transmission path of the raw data flow.

[0046] When identifying protocol frame header features in captured debug data streams, the structural specifications of the protocol frames must first be determined based on the debug interface protocol type of the target debug device. For the JTAG protocol, the instruction register scan chain features in the TMS and TDI signal sequences need to be identified; for the SWD protocol, the frame header features consisting of the start bit, APnDP bit, and read / write bit need to be identified; for the UART protocol, the frame structure consisting of the start bit, data bits, parity bit, and stop bit needs to be identified. Protocol frame header feature identification employs a state machine matching algorithm, pre-defining the characteristic byte sequences corresponding to session establishment requests for various debug protocols.

[0047] Taking the JTAG protocol as an example, a session establishment request typically manifests as a series of reset sequences followed by an IDCODE instruction. The characteristic byte sequence is a continuous high-level signal maintained for at least 5 clock cycles before a specific instruction code appears. For the SWD protocol, the session establishment request manifests as a transmit line reset sequence, characterized by a JTAG to SWD switching sequence following more than 50 consecutive high-level clock cycles. After receiving the captured data stream, the state machine performs pattern matching byte by byte, maintaining a matching status register to record the current matching progress. When the state machine completely matches the predefined session establishment request characteristic field, it outputs a matching success signal and triggers the session identifier generation process. To improve recognition accuracy, the feature recognition module sets a time window limit, requiring the feature field to appear completely within a continuous time window. The time window length is dynamically adjusted according to the data transmission rate of the protocol type, typically ranging from 100 milliseconds to 1 second.

[0048] When extracting the hardware architecture type identifier from the device feature information, it is extracted based on the processor architecture field obtained from the previously scanned device feature information. The hardware architecture type identifier uses a standardized encoding method: ARM architecture is encoded as 0x01, x86 architecture as 0x02, MIPS architecture as 0x03, and RISC-V architecture as 0x04. The operating system type identifier is extracted based on the operating system field in the device feature information: embedded Linux systems are encoded as 0x10, FreeRTOS systems as 0x11, and bare-metal environments without an operating system are encoded as 0x1F. The debug interface protocol type identifier is determined based on the results of the previous protocol adaptation rule matching: JTAG protocol is encoded as 0x20, SWD protocol as 0x21, and UART protocol as 0x22.

[0049] All three types of identification information use single-byte encoding for easy subsequent concatenation. When obtaining the timestamp corresponding to the current time information, the system clock is used to retrieve the number of seconds and microseconds since the epoch time. The timestamp is represented as a 64-bit integer, with the high 32 bits storing the seconds and the low 32 bits storing the microseconds, ensuring the timestamp's precision reaches the microsecond level. Timestamp acquisition calls the high-precision clock interface provided by the operating system. In Linux systems, the `clock_gettime` function is used in conjunction with the `CLOCK_REALTIME` parameter; in Windows systems, the `QueryPerformanceCounter` function is used. The timestamp acquisition moment is strictly defined as the instant the session identifier generation process is triggered, ensuring that different debugging sessions, even if established consecutively within a short period, will obtain different timestamp values.

[0050] When concatenating the hardware architecture type identifier, operating system type identifier, debug interface protocol type identifier, and timestamp, the bytes are arranged in a fixed byte order. The concatenation order is as follows: the first byte is the hardware architecture type identifier, the second byte is the operating system type identifier, the third byte is the debug interface protocol type identifier, and the fourth to eleventh bytes are the 8-byte representation of the timestamp. The concatenation operation writes the binary data of each field sequentially into a contiguous memory buffer, forming a combined data with a total length of 11 bytes.

[0051] When performing hash operations on the concatenated data, the SHA-256 hash algorithm is selected. The SHA-256 algorithm outputs a fixed 256-bit (32-byte) hash value for input data of any length, exhibiting good collision resistance and one-wayness. The input for the hash operation is the aforementioned 11-byte combined data. The hash algorithm performs grouping, padding, and iterative compression on the input data, ultimately outputting a 32-byte hash value. To further enhance the uniqueness of the session identifier, the device MAC address or device serial number from device feature information is appended to the combined data before the hash operation. The appended field is 6 to 16 bytes long, extending the input data length for the hash operation to 17 to 27 bytes. The generated 32-byte hash value is the session identifier, which remains unchanged throughout the entire debugging session and is used to uniquely identify the current debugging session.

[0052] When using the session identifier as the input seed for the key derivation function, the PBKDF2 key derivation algorithm is selected. The PBKDF2 algorithm performs iterative operations based on a pseudo-random function, expanding the input seed data into key material of a specified length. The input seed is the aforementioned 32-byte session identifier. The preset salt value parameter is read from the security configuration file or randomly generated during system initialization. The salt value parameter is set to 16 bytes in length and is generated using a cryptographically secure random number generator to ensure the randomness and unpredictability of the salt value. During the execution of the key derivation function, the PBKDF2 algorithm combines the session identifier and salt value parameter as input, internally using HMAC-SHA256 as the pseudo-random function. The number of iterations is set to 10,000 to balance security and computational performance. Each iteration mixes the output of the previous iteration with the original input, and after 10,000 iterations, the final key material is output. The key material output from the key expansion operation is set to 32 bytes in length, corresponding to a 256-bit key strength. The generated 32-byte key material is the dynamic encryption key dedicated to the debugging session. This key corresponds one-to-one with the session identifier and is stored in the secure key cache. The key cache uses a protected memory area with access control, allowing only the encryption and decryption modules to access it. The lifecycle of the dynamic encryption key is tied to the debugging session. When the debugging session ends normally or is abnormally interrupted, the corresponding dynamic encryption key is immediately cleared from the key cache, and the memory area storing the key is securely erased to prevent key material residue.

[0053] The execution time of the entire session identifier generation and key derivation process needs to be kept within an acceptable range to avoid significant delays in debugging session establishment. On a 1GHz ARM Cortex-A series processor, the SHA-256 hash operation takes approximately 0.05 milliseconds, and the PBKDF2 algorithm takes approximately 50 milliseconds for 10,000 iterations. The overall process time is within 60 milliseconds, meeting real-time requirements. To further optimize performance, some salt parameters can be pre-generated and cached when the system is idle, reducing the overhead of random number generation during debugging session establishment. After establishing a mapping relationship between the generated session identifier and the dynamic encryption key, it is recorded in the session management table. The session management table includes fields such as session identifier, dynamic encryption key, session establishment time, and target device identifier, supporting quick retrieval of corresponding key materials for subsequent encryption and decryption operations.

[0054] For example, using the session identifier as the input seed of the key derivation function, and combining it with a preset salt value parameter, the key derivation function performs a key expansion operation to generate a dynamic encryption key specifically for the debugging session, including: Read the salt value parameter corresponding to the debugging interface protocol type from the pre-stored salt value parameter library. The salt value parameter includes a fixed salt value component and a random salt value component. Perform a byte-level XOR operation between the session identifier and the salt parameter to generate the initial input vector for the key derivation function; The initial input vector is input into the key derivation function, and the initial input vector is expanded through multiple rounds of iterative hashing operations inside the key derivation function. The output of each round of iterative hashing is used as the input of the next round of iterative hashing. When the iterative hashing operation reaches a preset iteration round threshold, a byte sequence of a preset length is extracted from the output of the last iteration hashing operation, and the byte sequence is used as a dynamic encryption key for the debugging session. Establish a mapping relationship between the session identifier and the dynamic encryption key, and store the mapping relationship in the session key management table.

[0055] Using the session identifier as the input seed for the key derivation function, and combining it with a preset salt value parameter, the key derivation function performs a key expansion operation to generate a dynamic encryption key specific to the debugging session. Before the key derivation process begins, the salt value parameter corresponding to the debugging interface protocol type needs to be read from a pre-built salt value parameter library stored in a secure storage area. This salt value parameter library is indexed and organized according to the debugging interface protocol type, and different salt value parameters are configured for JTAG, SWD, UART debugging protocols, and other custom debugging protocols.

[0056] Each salt value parameter consists of two components: a fixed salt value component and a random salt value component. The fixed salt value component is a 64-byte fixed data sequence generated during system initialization based on the device's hardware signature. This fixed data sequence remains unchanged throughout the device's lifecycle and provides basic key derivation distinctiveness. The random salt value component is a 32-byte random data sequence generated by a hardware random number generator each time the system starts. This random data sequence changes after each system restart and enhances the unpredictability of key derivation. Once the corresponding salt value parameter is indexed according to the debug interface protocol type, the system concatenates the fixed and random salt value components byte-wise to form a complete 96-byte salt value parameter.

[0057] After obtaining the complete salt value parameter, a byte-level XOR operation needs to be performed between the session identifier and the salt value parameter to generate the initial input vector for the key derivation function. Since the session identifier is typically 32 bytes long, while the salt value parameter is 96 bytes long, the session identifier needs to be expanded before performing the XOR operation.

[0058] The specific expansion method involves repeating the 32-byte session identifier three times, forming a 96-byte data sequence with the same length as the salt parameter. During the expansion process, each byte of the second repeated session identifier is circularly shifted left by 3 bits, and each byte of the third repeated session identifier is circularly shifted left by 5 bits. This shifting operation enhances the randomness of the expanded data. After expansion, an XOR operation is performed byte by byte: the first byte of the expanded session identifier is XORed with the first byte of the salt parameter, the second byte of the expanded session identifier is XORed with the second byte of the salt parameter, and so on, completing the XOR operation for all 96 bytes. The result of the XOR operation is the initial input vector of the key derivation function, which is also 96 bytes long.

[0059] After the initial input vector is input into the key derivation function, it is expanded through multiple rounds of iterative hash operations implemented within the function. The key derivation function adopts an iterative structure based on the SHA-256 hash algorithm. In the first round of iterative hash operations, the 96-byte initial input vector is used as the input to the SHA-256 hash algorithm, resulting in a 32-byte hash output value. To maintain the data length consistent with the initial input vector, this 32-byte hash output value needs to be expanded. The expansion method is to repeat the hash output value three times and perform a byte-level XOR operation. Specifically, the first 32-byte hash output value remains unchanged, each byte of the second 32-byte hash output value is XORed with its byte position index, and each byte of the third 32-byte hash output value is XORed with the square of its byte position index. Then, the three processed 32-byte data sequences are concatenated end to end to form 96 bytes of data as the final output of the first round of iterative hash operations.

[0060] The output data serves as the input for the second round of iterative hashing, repeating the same hashing and expansion processes as the first round. In each round of iterative hashing, a round constant is introduced. This round constant is a 32-byte data value calculated based on the current round number. It is calculated by repeating the round number 32 times to form a 32-byte data set, then performing a single SHA-256 hash operation on this data to obtain the round constant. Before performing the hash operation, the current round input data and the round constant are XORed byte-by-byte, and then processed using the SHA-256 hash algorithm. This method ensures that each round of iterative hashing produces a different output result.

[0061] The number of iteration rounds is determined by a preset iteration round threshold, which is configured based on security and performance requirements. In applications with high security requirements, the iteration round threshold can be set to 10,000 rounds, requiring 10,000 hash operations for key derivation, effectively resisting brute-force attacks. In applications with high performance requirements, the iteration round threshold can be set to 1,000 rounds, keeping the execution time of the key derivation process within an acceptable range. The system provides a dynamic adjustment mechanism, automatically selecting an appropriate iteration round threshold based on the security level of the debugging session. A higher iteration round threshold is automatically used when the debugging session involves core firmware modifications, while a lower threshold is used when the session only involves status queries. When the iterative hash operation reaches the preset iteration round threshold, the 96-byte data result of the last iteration hash operation is obtained.

[0062] A preset length of byte sequence is truncated from the output of the last round of iterative hashing as the dynamic encryption key. The preset length is determined based on the encryption algorithm requirements of the debugging data. When using AES-128 encryption, a 16-byte key is required, so the first 16 bytes are truncated from the beginning of the output. When using AES-256 encryption, a 32-byte key is required, so the first 32 bytes are truncated from the beginning of the output. After truncation, the truncated byte sequence undergoes key strength verification. Verification includes checking the uniformity of byte value distribution, calculating the maximum length of consecutive identical bytes to see if it exceeds a threshold, and calculating the entropy of byte values ​​to ensure it meets the minimum requirement. If the truncated byte sequence fails the key strength verification, byte sequences are truncated again from different starting positions in the output for verification until a key that meets the strength requirements is obtained. The byte sequence that passes the key strength verification is the dynamic encryption key used exclusively for the debugging session.

[0063] After generating the dynamic encryption key, a mapping relationship needs to be established between the session identifier and the dynamic encryption key, and this mapping relationship should be stored in the session key management table for unified management. The session key management table is implemented using a hash table data structure, with the session identifier as the index key and the dynamic encryption key as the associated value. When storing the mapping relationship, in addition to storing the two core data points—the session identifier and the dynamic encryption key—it also needs to store auxiliary information such as the key's derivation timestamp, the key's validity period, the key's usage counter, and the debugging interface protocol type associated with the key. The key's derivation timestamp records the exact moment the dynamic encryption key was generated, used to subsequently determine whether the key has expired.

[0064] The validity period of a key is determined by the security policy configuration of the debugging session, typically set between 30 and 120 minutes. Keys that exceed their validity period will be automatically invalidated and deleted from the management table. A key usage counter records the number of times the dynamic encryption key has been used for encryption operations. When the number of uses exceeds the preset maximum usage threshold, a key update process needs to be triggered to regenerate a new dynamic encryption key, even if the key is still valid.

[0065] The debug interface protocol type associated with the key is used to quickly confirm the applicable protocol range of the current key during encryption and decryption operations. The session key management table also implements a periodic cleanup mechanism. At fixed time intervals, it iterates through all records in the management table, checks the validity period and usage status of each dynamic encryption key, deletes expired key records from the management table, and performs a secure erase operation on the corresponding memory space to prevent expired keys from remaining in memory and being illegally accessed. Simultaneously, the session key management table supports concurrent access control. When multiple debug sessions are running concurrently, a mutex lock mechanism ensures that read and write operations on the management table do not conflict, guaranteeing that each debug session can correctly obtain and use its dedicated dynamic encryption key.

[0066] Figure 2 The flowchart for generating an encrypted debug frame illustrates the process of intercepting raw debug data sent by the debug host to the virtual debug interface, parsing the protocol fields of the raw debug data to extract debug command fields and data payload fields, and using the dynamic encryption key to perform encryption operations on the debug command fields and data payload fields respectively to generate an encrypted debug frame, including: A data interception layer is set between the virtual debugging interface and the debugging host, and the original debugging data sent by the debugging host to the virtual debugging interface is intercepted through the data interception layer; Based on the data frame format conversion rules in the protocol conversion strategy, identify the byte boundary positions of the frame header field and check field of the original debug data; The debug command field and the data payload field are separated and extracted from the original debug data according to the byte boundary positions; The first encryption operation is performed on the debug command field using the dynamic encryption key to generate the encrypted command field, and the second encryption operation is performed on the data payload field to generate the encrypted payload field. The frame header field, the encryption command field, and the encryption payload field are sequentially encapsulated according to the predefined encrypted debugging frame structure, and the verification value of the encapsulated data is calculated and filled into the verification field to form the encrypted debugging frame.

[0067] A data interception layer is set up between the virtual debug interface and the debug host. This layer, implemented using driver-level hook functions, can capture data packets before they leave the debug host's operating system network protocol stack. Specifically, the data interception layer monitors all outbound data streams on the target port by registering kernel-level packet filtering callback functions. When the debug host sends raw debug data to the virtual debug interface, the data stream first reaches the data interception layer. The data interception layer matches and verifies the target port number and target address of the data packet. After confirming that the data packet is indeed destined for the virtual debug interface, it stores a complete copy of the data packet in a pre-allocated memory buffer and prevents the data packet from continuing to be transmitted to the virtual debug interface, thereby achieving complete interception of the raw debug data.

[0068] According to the data frame format conversion rules in the protocol conversion strategy, the byte boundary positions of the frame header field and checksum field of the original debug data are identified. The protocol conversion strategy predefines the data frame format specifications for various debug protocols supported by the target debug device, including JTAG, SWD, and UART debug protocols. Taking the JTAG protocol as an example, its data frame format conversion rules record that the frame header field occupies the first 4 bytes, where the first 2 bytes are the synchronization identifier, the 3rd byte is the frame type identifier, and the 4th byte is the command length identifier. The checksum field is located in the last 2 bytes of the data frame and is generated using the CRC16 cyclic redundancy check algorithm. Based on these rules, the parsing module reads 4 bytes from the beginning of the original debug data as the frame header field, extracts the checksum field from the last 2 bytes of the data frame, and identifies the remaining middle portion as the valid data area. For some variable-length debug protocols, the command length identifier in the frame header field explicitly indicates the total number of bytes in the valid data area; the parsing module dynamically calculates the starting position of the checksum field based on this length value.

[0069] The debug command field and data payload field are extracted from the raw debug data based on byte boundaries. After determining the boundaries of the frame header and checksum fields, the valid data area typically contains two parts: the debug command field and the data payload field. The debug command field records the specific type of debug operation, such as register read command, memory write command, breakpoint setting command, etc. This field usually occupies the first few bytes of the valid data area. The data payload field contains the parameter information required for command execution, such as the target register address, the data value to be written, and breakpoint location information. Depending on the debug protocol specification, the length of the debug command field may be a fixed value or a variable value. For the JTAG protocol, the debug command field is fixed at 1 byte, and all data after this byte belongs to the data payload field.

[0070] For some custom debugging protocols, the length of the debug command field may be indicated by a specific flag bit in the frame header field. During the extraction process, the parsing module first determines the byte length of the debug command field according to the protocol specification, reads the corresponding length of byte sequence from the beginning of the valid data area as the debug command field, and then classifies the remaining byte sequence as the data payload field.

[0071] A first encryption operation is performed on the debug command field using a dynamic encryption key to generate an encrypted command field, and a second encryption operation is performed on the data payload field to generate an encrypted payload field. The first and second encryption operations can employ the same or different encryption algorithms. In one implementation, the first encryption operation uses AES-128-ECB mode, taking the debug command field as plaintext input and using the dynamic encryption key to generate an encrypted command field of the same length as the debug command field. Since debug command fields are typically short, ECB mode provides sufficient security and fast computation speed. The second encryption operation uses AES-128-CBC mode, encrypting the data payload field using the same dynamic encryption key and a randomly generated initialization vector.

[0072] The initialization vector is 16 bytes long and is generated using a true random number generator to ensure that a different initialization vector is used for each encryption operation. Before performing the second encryption operation, if the length of the data payload field is not an integer multiple of 16 bytes, the data payload field needs to be padded according to the PKCS7 padding standard, with the padding bytes equal to the number of bytes to be padded. After the encryption operation is completed, the length of the resulting encrypted payload field will be slightly larger than the original data payload field; this length difference is introduced by the padding operation.

[0073] In another implementation, both the first and second encryption operations employ the ChaCha20 stream cipher algorithm. This algorithm generates a keystream of the same length as the data to be encrypted by inputting a dynamic encryption key and a 64-bit counter value into the ChaCha20 core function. For the debug command field, the counter value is initialized to 0, and the generated keystream is XORed byte-by-byte with the debug command field to obtain the encrypted command field. For the data payload field, the counter value continues to increment from the termination value of the previous stage, generating a sufficiently long keystream which is XORed with the data payload field to obtain the encrypted payload field. The advantage of this stream cipher method is that the encryption and decryption operations are completely symmetrical, no data padding is required, and the length of the encrypted data is exactly the same as the original data length.

[0074] The encrypted debug frame is formed by sequentially encapsulating the frame header field, encrypted command field, and encrypted payload field according to a predefined encrypted debug frame structure, and then calculating a checksum and filling it into the checksum field. The predefined encrypted debug frame structure specifies the order and length requirements of each field. The specific encapsulation process is as follows: First, the frame header field extracted from the original debug data is written at the beginning of the pre-allocated output buffer, keeping the content and length of the frame header field unchanged so that the target debug device can correctly identify the basic attributes of the data frame. Then, the encrypted command field and encrypted payload field are written sequentially after the frame header field. If the second encryption operation uses CBC mode and an initialization vector, the initialization vector needs to be inserted as a separate field between the encrypted command field and the encrypted payload field so that the receiving end can correctly decrypt the data payload.

[0075] After encapsulating the above fields, calculate the checksum of all bytes from the start of the frame header field to the end of the encrypted payload field. The checksum algorithm is selected according to the requirements of the target debugging protocol; commonly used algorithms include CRC16, CRC32, or MD5 hash truncation values. Taking CRC16 as an example, all encapsulated bytes are sequentially input into the CRC16 calculation function to obtain a 2-byte checksum. This checksum is then written to the end of the output buffer as the checksum field. At this point, the complete encrypted debugging frame is constructed. This data frame retains the frame structure characteristics of the original debugging protocol while protecting the confidentiality of debugging commands and data payloads through encryption, preventing unauthorized interception or tampering of debugging data during wireless transmission.

[0076] For example, receiving an encrypted response frame returned by the target debugging device, extracting the session identifier from the encrypted response frame and finding the corresponding dynamic encryption key, using the dynamic encryption key to decrypt the encrypted response frame to obtain response data, converting the response data into a protocol format recognizable by the debugging host according to the protocol conversion strategy, and transmitting it to the debugging host through the virtual debugging interface, includes: The wireless communication module receives the encrypted response frame returned by the target debugging device and extracts the session identifier and encryption algorithm identifier information from a predetermined position in the encrypted response frame. Using the session identifier as the index key, the corresponding dynamic encryption key is queried in the session key management table. The decryption algorithm type is determined according to the encryption algorithm identification information. The encrypted data part in the encrypted response frame is decrypted using the dynamic encryption key and the decryption algorithm type to obtain response data containing response command field and response payload field. According to the debug command mapping table in the protocol conversion strategy, the response command field and response payload field in the response data are converted into a protocol format that the debug host can recognize, generating converted response data. The converted response data is written into the data output buffer of the virtual debug interface and transmitted to the debug host through the virtual debug interface.

[0077] When the wireless communication module receives the encrypted response frame from the target debugging device, it first parses the frame header. The encrypted response frame uses the same encapsulation structure as the encrypted debugging frame, storing the session identifier and encryption algorithm identification information at a predetermined position in the frame header. This predetermined position is typically located 8 bytes off the beginning of the frame header. The session identifier occupies 16 bytes of storage, followed by 2 bytes for the encryption algorithm identification information. The wireless communication module's receive buffer performs integrity checks on the received data frame, verifying whether the frame header identifier conforms to the agreed-upon magic word and checking whether the frame length field matches the actual received data length. After the integrity check passes, the session identifier and encryption algorithm identification information are extracted from the frame header according to the byte offset and temporarily stored in local variables for subsequent decryption operations.

[0078] After extracting the session identifier, a query operation is performed in the session key management table using this identifier as the index key. The session key management table is implemented using a hash table structure, with the hash value of the session identifier as the bucket index. Each bucket stores information such as the session identifier, the corresponding dynamic encryption key, the key generation timestamp, and the key validity period. During the query process, the hash value of the session identifier is first calculated to locate the corresponding bucket, and then the linked list within the bucket is traversed for exact matching. When a matching session identifier is found, the corresponding dynamic encryption key is extracted, and the key's validity period is checked. When checking the key validity period, the current system time is compared with the key generation timestamp. If the time difference exceeds a preset key validity period threshold, the key is determined to have expired, subsequent decryption operations are rejected, and a session expiration error message is returned to the debugging host. The validity period threshold is set according to the specific application scenario; for high-security debugging scenarios, it can be set to 300 seconds, and for general debugging scenarios, it can be set to 1800 seconds.

[0079] The decryption algorithm type is determined based on the encryption algorithm identifier information extracted from the frame header. The encryption algorithm identifier is a 2-byte enumeration value; different enumeration values ​​correspond to different encryption algorithm types. An identifier of 0x0001 indicates the use of the AES-256-GCM algorithm, 0x0002 indicates the use of the ChaCha20-Poly1305 algorithm, and 0x0003 indicates the use of the SM4-CBC algorithm. Based on the different algorithm identifiers, the corresponding decryption function is called to initialize the decryption context. For the AES-256-GCM algorithm, the decryption context includes a 256-bit dynamic encryption key, a 12-byte random initialization vector, and a 16-byte authentication tag for integrity verification. The initialization vector is extracted from a specific position in the frame header of the encrypted response frame, and the authentication tag is located at the end of the encrypted data portion. For the ChaCha20-Poly1305 algorithm, the decryption context includes a 256-bit dynamic encryption key, a 12-byte random number, and a 16-byte authentication code for message authentication.

[0080] The encrypted data portion of the encrypted response frame is decrypted using a defined dynamic encryption key and decryption algorithm type. The encrypted data portion is located after the frame header, its starting position specified by the frame header length field. The data length is calculated by subtracting the frame header length and authentication tag length from the total frame length. The decryption process uses a streaming approach, reading the encrypted data portion into 1024-byte blocks into a decryption buffer. For each data block, the update function of the decryption algorithm is called for decryption processing, and the decrypted data is written to the output buffer. Once all data blocks have been processed, the completion function of the decryption algorithm is called, which verifies the correctness of the authentication tag or authentication code. If authentication fails, it indicates that the data has been tampered with during transmission or an incorrect key has been used. In this case, the decryption process is terminated, and an error message indicating data integrity verification failure is returned to the debugging host. If authentication is successful, the original decrypted response data is stored in the output buffer.

[0081] The decrypted response data contains a response command field and a response payload field, which need to be parsed according to the protocol format of the target debugging device. The response command field is located at the beginning of the response data, typically occupying 1 to 4 bytes, with its specific length determined by the field length definition in the protocol conversion strategy. The response payload field follows immediately after the response command field, and its length can be calculated by subtracting the response command field length from the total response data length. For some debugging protocols, the response data may also contain a status code field, a data length field, and a checksum field; the contents of each field need to be extracted sequentially according to the field layout defined in the protocol conversion strategy. The extracted response command field and response payload field are encapsulated into a structured data object for subsequent protocol conversion processing.

[0082] Protocol format conversion is performed according to the debug command mapping table in the protocol conversion strategy. The debug command mapping table establishes a correspondence between the target debug device protocol format and the debug host protocol format. Each mapping entry contains the source protocol command encoding, the target protocol command encoding, field order adjustment rules, and data type conversion rules. The corresponding mapping entry is searched in the debug command mapping table using the response command field as the key. If a matching entry is found, it is processed according to the conversion rules defined in the mapping entry. The conversion process first converts the source protocol's response command field to the target protocol's command encoding; for example, converting the JTAG protocol's read response command 0xA2 to the GDB remote protocol's read response command g.

[0083] Then, the data in the response payload field is rearranged according to the field order adjustment rules. Some target debugging devices use big-endian byte order to store multi-byte data, while the debugging host may use little-endian byte order. In this case, byte order conversion of the multi-byte data is required. Data type conversion rules handle the differences in data representation between different protocols, such as converting binary register values ​​to hexadecimal string format, or mapping status codes to corresponding text description information.

[0084] For array-type data in the response payload field, the order and delimiters of array elements are adjusted according to the requirements of the target protocol. Some debugging protocols require commas to separate array elements, while others require spaces. The protocol conversion strategy defines formatting rules for various data structures. For complex response data containing nested structures, a recursive approach is used for layer-by-layer conversion to ensure that all levels of data are converted to a format recognizable by the debugging host. During the conversion process, the validity of the data is verified, such as checking whether the register address is within a valid range and whether the status code is a valid value defined by the protocol. Invalid data is logged with alarm information and handled according to the fault tolerance strategy.

[0085] The converted response command and payload fields are reassembled according to the requirements of the debug host protocol format to generate the converted response data. The format of the converted response data strictly adheres to the debug protocol specifications used by the debug host, including correct frame header identifiers, command fields, data length fields, and checksum fields. For some debug protocols, a sequence number field needs to be added to the response data. This sequence number must match the sequence number in the previously sent debug command to ensure the debug host can correctly match the request and response. During the generation of the converted response data, the checksum field is calculated and populated. The checksum algorithm is selected according to the target protocol's specifications; common checksum algorithms include simple summation, CRC16, and CRC32.

[0086] The generated converted response data is written to the data output buffer of the virtual debug interface. The data output buffer of the virtual debug interface is implemented using a circular buffer structure with a fixed capacity. When the buffer is full, it will overwrite the oldest written data or block the write operation until there is enough space. Before the write operation, it first checks whether the available space in the buffer is sufficient to accommodate the converted response data. If the space is insufficient, it is handled according to the configured buffering strategy. The buffering strategy can be a blocking mode, waiting for the debug host to read data and release space before performing the write; it can be a discard mode, discarding the current response data and recording the loss event; or it can be a dynamic expansion mode, temporarily increasing the buffer capacity until it reaches the set maximum value. The write process uses atomic operations to ensure data integrity and avoid data corruption caused by data contention in a multi-threaded environment.

[0087] The converted response data is transmitted to the debugging host via a virtual debug interface. As an operating system-level virtual device, the virtual debug interface provides a standard read interface for the debugging host to access. When the debugging host reads the virtual debug interface via a system call, the virtual interface driver reads available data from the data output buffer and returns it to the debugging host. The data transmission process supports both synchronous and asynchronous modes. In synchronous mode, the debugging host's read operation will block until data is available; in asynchronous mode, the virtual debug interface notifies the debugging host via a signal mechanism or callback function when data is available.

[0088] A second aspect of the present invention provides an AI-driven secure forwarding system for wireless debugging ports, comprising: The device scanning unit is used to scan the surrounding debugging devices through the wireless communication module and obtain the device characteristic information of each debugging device. Based on the device characteristic information, it matches the corresponding protocol conversion strategy from the pre-stored protocol adaptation rule base, and creates a virtual debugging interface on the debugging host side that corresponds to the debugging interface protocol type of the target debugging device according to the protocol conversion strategy. The dynamic key unit is used to generate a session identifier by combining the device feature information and the current time information when a debugging session establishment request of the virtual debugging interface is detected, and to generate a dynamic encryption key for the debugging session based on the session identifier through a key derivation function. The debugging data unit is used to intercept the raw debugging data sent by the debugging host to the virtual debugging interface, perform protocol field parsing on the raw debugging data to extract the debugging command field and data payload field, and use the dynamic encryption key to perform encryption operations on the debugging command field and data payload field respectively to generate an encrypted debugging frame. An encrypted frame encapsulation unit is used to encapsulate the session identifier and encryption algorithm identification information in the encrypted debug frame, and transmit the encapsulated encrypted debug frame to the target debug device through the wireless communication module. The response decryption unit is used to receive the encrypted response frame returned by the target debugging device, extract the session identifier from the encrypted response frame and find the corresponding dynamic encryption key, use the dynamic encryption key to perform decryption operation on the encrypted response frame to obtain response data, convert the response data into a protocol format that the debugging host can recognize according to the protocol conversion strategy, and transmit it to the debugging host through the virtual debugging interface.

[0089] A third aspect of the present invention provides an electronic device, comprising: processor; Memory used to store processor-executable instructions; The processor is configured to invoke instructions stored in the memory to execute the aforementioned method.

[0090] A fourth aspect of the present invention provides a computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, implement the aforementioned method.

[0091] This invention can be a method, apparatus, system, and / or computer program product. The computer program product may include a computer-readable storage medium having computer-readable program instructions loaded thereon for performing various aspects of the invention.

[0092] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A secure forwarding method for wireless debugging ports based on AI, characterized in that, include: The wireless communication module scans the surrounding debugging devices and obtains the device characteristic information of each debugging device. Based on the device characteristic information, the corresponding protocol conversion strategy is matched from the pre-stored protocol adaptation rule base. Based on the protocol conversion strategy, a virtual debugging interface corresponding to the debugging interface protocol type of the target debugging device is created on the debugging host side. When a debugging session establishment request for the virtual debugging interface is detected, a session identifier is generated by combining the device feature information and the current time information, and a dynamic encryption key for the debugging session is generated by the key derivation function based on the session identifier. The system intercepts the raw debugging data sent by the debugging host to the virtual debugging interface, performs protocol field parsing on the raw debugging data to extract the debugging command field and data payload field, and uses the dynamic encryption key to perform encryption operations on the debugging command field and data payload field respectively to generate an encrypted debugging frame. The session identifier and encryption algorithm identifier information are encapsulated in the encrypted debugging frame, and the encapsulated encrypted debugging frame is transmitted to the target debugging device through the wireless communication module. The system receives an encrypted response frame returned by the target debugging device, extracts the session identifier from the encrypted response frame and finds the corresponding dynamic encryption key, uses the dynamic encryption key to decrypt the encrypted response frame to obtain response data, converts the response data into a protocol format recognizable by the debugging host according to the protocol conversion strategy, and transmits it to the debugging host through the virtual debugging interface.

2. The method according to claim 1, characterized in that, Based on the device characteristic information, a corresponding protocol conversion strategy is matched from a pre-stored protocol adaptation rule base, and a virtual debugging interface corresponding to the debugging interface protocol type of the target debugging device is created on the debugging host side according to the protocol conversion strategy, including: The hardware architecture type, operating system type, and debugging interface protocol type of the device feature information are combined to form a multi-dimensional feature index key. The multi-dimensional feature index key is used to perform a query and match in the protocol adaptation rule base. The protocol conversion strategy corresponding to the multi-dimensional feature index key is obtained from the protocol adaptation rule base. The protocol conversion strategy includes a debugging command mapping table, data frame format conversion rules, and protocol handshake sequence template. According to the debugging interface protocol type, the corresponding virtual interface configuration parameters are extracted from the protocol conversion strategy. The virtual interface configuration parameters include interface communication rate configuration information, data bit width configuration information, and handshake timing configuration information. A virtual device driver module is registered in the operating system kernel layer of the debugging host. The virtual device driver module creates the virtual debugging interface according to the virtual interface configuration parameters, so that the virtual debugging interface is presented on the debugging host side as a physical debugging interface corresponding to the debugging interface protocol type of the target debugging device.

3. The method according to claim 2, characterized in that, The process involves querying and matching the protocol adaptation rule base using the multi-dimensional feature index key, and retrieving the protocol conversion strategy corresponding to the multi-dimensional feature index key from the protocol adaptation rule base, including: Calculate the feature hash value of each technical feature dimension in the multi-dimensional feature index key, and perform a combination operation on the feature hash values ​​of each technical feature dimension to generate a composite hash index; The composite hash index is used to perform a matching search in the index structure of the protocol adaptation rule base. When a match is successful, the corresponding protocol conversion strategy is directly obtained. When the composite hash index fails to match precisely, the matching constraints of the technical feature dimension in the multi-dimensional feature index key are reduced in turn, and fuzzy matching search is performed according to the priority order of debugging interface protocol type, operating system type, and hardware architecture type. For the multiple candidate protocol conversion strategies obtained by fuzzy matching, the feature similarity score between each candidate protocol conversion strategy and the multi-dimensional feature index key is calculated, and the candidate protocol conversion strategy with the highest feature similarity score is selected as the final matching result.

4. The method according to claim 1, wherein a session identifier is generated by combining the device feature information and the current time information, and a dynamic encryption key for the debugging session is generated based on the session identifier through a key derivation function, comprising: A data flow monitoring hook is set in the data input buffer of the virtual debugging interface, and the debugging data flow sent from the debugging host to the virtual debugging interface is captured in real time through the data flow monitoring hook; The captured debug data stream is subjected to protocol frame header feature recognition. When the debug data stream contains a feature field of debug session establishment request, the session identifier generation process is triggered. Extract the hardware architecture type identifier, operating system type identifier, and debug interface protocol type identifier from the device feature information, and obtain the timestamp corresponding to the current time information; The hardware architecture type identifier, operating system type identifier, debug interface protocol type identifier, and timestamp are concatenated and combined, and a hash operation is performed on the concatenated and combined data to generate the session identifier; Using the session identifier as the input seed of the key derivation function, and combining it with a preset salt value parameter, the key derivation function performs a key expansion operation to generate a dynamic encryption key specifically for the debugging session.

5. The method according to claim 4, characterized in that, Using the session identifier as the input seed of the key derivation function, and combining it with a preset salt value parameter, the key derivation function performs a key expansion operation to generate a dynamic encryption key specifically for the debugging session, including: Read the salt value parameter corresponding to the debugging interface protocol type from the pre-stored salt value parameter library. The salt value parameter includes a fixed salt value component and a random salt value component. Perform a byte-level XOR operation between the session identifier and the salt parameter to generate the initial input vector for the key derivation function; The initial input vector is input into the key derivation function, and the initial input vector is expanded through multiple rounds of iterative hashing operations inside the key derivation function. The output of each round of iterative hashing is used as the input of the next round of iterative hashing. When the iterative hash operation reaches a preset iteration round threshold, a byte sequence of a preset length is extracted from the output of the last iteration hash operation, and the byte sequence is used as a dynamic encryption key for the debugging session. Establish a mapping relationship between the session identifier and the dynamic encryption key, and store the mapping relationship in the session key management table.

6. The method according to claim 1, characterized in that, The process involves intercepting raw debugging data sent from the debugging host to the virtual debugging interface, parsing the protocol fields of the raw debugging data to extract the debugging command field and the data payload field, and using the dynamic encryption key to perform encryption operations on the debugging command field and the data payload field respectively to generate an encrypted debugging frame, including: A data interception layer is set between the virtual debugging interface and the debugging host, and the original debugging data sent by the debugging host to the virtual debugging interface is intercepted through the data interception layer; Based on the data frame format conversion rules in the protocol conversion strategy, identify the byte boundary positions of the frame header field and check field of the original debug data; The debug command field and the data payload field are separated and extracted from the original debug data according to the byte boundary positions; The first encryption operation is performed on the debug command field using the dynamic encryption key to generate the encrypted command field, and the second encryption operation is performed on the data payload field to generate the encrypted payload field. The frame header field, the encryption command field, and the encryption payload field are sequentially encapsulated according to the predefined encrypted debugging frame structure, and the verification value of the encapsulated data is calculated and filled into the verification field to form the encrypted debugging frame.

7. The method according to claim 1, characterized in that, The process includes receiving an encrypted response frame returned by the target debugging device, extracting the session identifier from the encrypted response frame and finding the corresponding dynamic encryption key, using the dynamic encryption key to decrypt the encrypted response frame to obtain response data, converting the response data into a protocol format recognizable by the debugging host according to the protocol conversion strategy, and transmitting it to the debugging host through the virtual debugging interface. The wireless communication module receives the encrypted response frame returned by the target debugging device and extracts the session identifier and encryption algorithm identifier information from a predetermined position in the encrypted response frame. Using the session identifier as the index key, the corresponding dynamic encryption key is queried in the session key management table. The decryption algorithm type is determined according to the encryption algorithm identification information. The encrypted data part in the encrypted response frame is decrypted using the dynamic encryption key and the decryption algorithm type to obtain response data containing response command field and response payload field. According to the debug command mapping table in the protocol conversion strategy, the response command field and response payload field in the response data are converted into a protocol format that the debug host can recognize, generating converted response data. The converted response data is written into the data output buffer of the virtual debug interface and transmitted to the debug host through the virtual debug interface.

8. An AI-driven secure forwarding system for wireless debugging ports, used to implement the method as described in any one of claims 1-7, characterized in that, include: The device scanning unit is used to scan the surrounding debugging devices through the wireless communication module and obtain the device characteristic information of each debugging device. Based on the device characteristic information, it matches the corresponding protocol conversion strategy from the pre-stored protocol adaptation rule base, and creates a virtual debugging interface on the debugging host side that corresponds to the debugging interface protocol type of the target debugging device according to the protocol conversion strategy. The dynamic key unit is used to generate a session identifier by combining the device feature information and the current time information when a debugging session establishment request of the virtual debugging interface is detected, and to generate a dynamic encryption key for the debugging session based on the session identifier through a key derivation function. The debugging data unit is used to intercept the raw debugging data sent by the debugging host to the virtual debugging interface, perform protocol field parsing on the raw debugging data to extract the debugging command field and data payload field, and use the dynamic encryption key to perform encryption operations on the debugging command field and data payload field respectively to generate an encrypted debugging frame. An encrypted frame encapsulation unit is used to encapsulate the session identifier and encryption algorithm identification information in the encrypted debug frame, and transmit the encapsulated encrypted debug frame to the target debug device through the wireless communication module. The response decryption unit is used to receive the encrypted response frame returned by the target debugging device, extract the session identifier from the encrypted response frame and find the corresponding dynamic encryption key, use the dynamic encryption key to perform decryption operation on the encrypted response frame to obtain response data, convert the response data into a protocol format that the debugging host can recognize according to the protocol conversion strategy, and transmit it to the debugging host through the virtual debugging interface.

9. An electronic device, characterized in that, include: processor; Memory used to store processor-executable instructions; The processor is configured to invoke instructions stored in the memory to execute the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having computer program instructions stored thereon, characterized in that, When the computer program instructions are executed by the processor, they implement the method described in any one of claims 1 to 7.

Images