Method and system for protecting radio frequency test programs with segment dynamic decryption and multithread offloading

Abstract

The application provides a radio frequency test program protection method and system with section dynamic decryption and multi-thread offloading, which comprises the following steps: dividing a radio frequency test program into multiple test sections according to a test flow, encrypting to obtain encrypted sections and form an encrypted section set; performing key derivation processing according to the hardware identification information of a test device to obtain a dynamic decryption key; when the test flow runs to a target test item and the target test item matches a preset trigger condition, locating a target encrypted section from the encrypted section set, decrypting to obtain corresponding plaintext executable code by using the dynamic decryption key, loading the plaintext executable code to a temporary execution buffer and running, performing a radio frequency measurement operation corresponding to the target test item to obtain measurement data, and transmitting the measurement data to an external processing unit for operation by using multi-thread; and after the radio frequency measurement operation is completed, safely clearing the plaintext executable code in the temporary execution buffer. The problems of security defects, performance contradictions, architecture load imbalance, and the inability to balance security and performance are solved.

Description

Technical Field

[0001] This invention relates to the fields of radio frequency testing and information security technology, specifically to a method and system for protecting radio frequency test programs with segment dynamic decryption and multi-threaded offloading. Background Technology

[0002] In radio frequency (RF) testing systems, automated test equipment (ATE) or integrated test platforms control instruments through test programs to generate, receive, and measure RF signals. The corresponding test algorithms and measurement control programs constitute the core technological assets of the test equipment and possess significant commercial value. However, these test programs are typically deployed in the test equipment as executable files or dynamic link libraries (DLLs), making them highly vulnerable to reverse engineering and unauthorized copying attacks.

[0003] Currently, existing technologies mostly protect program content by setting encryption methods, such as using Advanced Encryption Standard (AES) for encryption, to prevent test programs from being reverse-engineered and illegally copied. However, when applied to RF test equipment, the following limitations still exist.

[0004] Specifically, one issue is security flaws. While existing software protection schemes can protect program content through encryption, the decrypted test program needs to reside in system memory for an extended period for repeated access. During this process, attackers can extract the complete decrypted program code through memory dumps, thereby cracking the test algorithm. Furthermore, the authorization and verification mechanism is independent of the device hardware, allowing the encrypted program to be directly copied and run on other devices, lacking deep integration.

[0005] Secondly, there is a performance conflict. RF test equipment (especially ATE) has stringent real-time requirements for test execution, needing to complete signal acquisition, data reading, and subsequent processing within microseconds. If the entire test program is encrypted and decrypted as a whole, the entire program must be decrypted every time it is invoked, introducing significant computational latency and resource overhead. Especially when the test program is large, the overall decryption time directly impacts the test rhythm. Existing on-demand decryption solutions are not adapted to segmented processes such as RF test calibration, scanning, and power measurement, and redundant decryption still exists.

[0006] Thirdly, there is an imbalance in the architectural load. Existing test equipment (such as FPGAs or ATE controllers) is responsible for both RF signal acquisition and a large amount of high-load signal analysis operations (such as Fast Fourier Transform, error vector amplitude demodulation analysis, etc.). This tight coupling mode limits the overall test throughput. Although there are solutions to transmit test data to the outside, they mainly focus on encryption security during data transmission and do not achieve true decoupling between acquisition and operation.

[0007] Fourthly, security and performance are mutually exclusive. The aforementioned issues combined lead existing solutions into a dilemma where "high security and high real-time performance are difficult to achieve simultaneously." Strong protection hinders RF testing efficiency, while pursuing efficiency exposes risks. None of the solutions have organically integrated program security protection mechanisms with test data collaborative processing mechanisms at the system architecture level, making it difficult to form a systematic solution.

[0008] Therefore, there is an urgent need for a program protection method and system that can simultaneously overcome security defects, performance contradictions, and architectural load imbalances, and ultimately break through the dilemma of not being able to achieve both security and performance, so as to ensure high real-time performance and high throughput while ensuring the security of RF test programs. Summary of the Invention

[0009] The present invention provides a method and system for protecting radio frequency test programs with segment dynamic decryption and multi-threaded offloading, which at least solves the problems of security defects, performance contradictions, architectural load imbalance, and the inability to achieve both security and performance.

[0010] According to one aspect of the present invention, a method for protecting radio frequency test programs with segment dynamic decryption and multi-threaded offloading is provided, comprising: The radio frequency test procedure is divided into multiple test sections according to the test process, and each test section is encrypted to obtain the corresponding encrypted sections, forming an encrypted section set. Start the test equipment, read the hardware identification information of the test equipment, and perform key derivation processing based on the hardware identification information to obtain the dynamic decryption key; When the test process reaches the target test project and the target test project meets the pre-configured preset trigger conditions, the target encrypted segment is located from the encrypted segment set, and the target encrypted segment is decrypted using the dynamic decryption key to obtain the corresponding plaintext executable code. The plaintext executable code is loaded into a temporary execution buffer and run to perform the radio frequency measurement operation corresponding to the target test item, obtain measurement data, and use multi-threading to transmit the measurement data to an external processing unit for calculation. After the radio frequency measurement operation corresponding to the target test item is completed, the plaintext executable code in the temporary execution buffer is securely cleared.

[0011] As an optional approach, the radio frequency test procedure is divided into multiple test segments according to the test flow, and each test segment is encrypted separately to obtain encrypted segments, forming an encrypted segment set, including: The radio frequency test procedure is divided into multiple test sections according to the test process; wherein, the test section includes at least a calibration section, a frequency scanning section, a power measurement section, and a modulation quality analysis section; Each test segment is configured with an independent segment identifier, memory offset address, checksum, and preset trigger conditions, and these are collected and organized into a metadata set; wherein, the preset trigger conditions include the target test item identifier information corresponding to each test segment; Each test segment is encrypted using the AES-128 encryption algorithm to obtain the corresponding encrypted segments, forming a set of encrypted segments; The metadata set and the encrypted segment set are embedded in a dynamic link library.

[0012] As an optional solution, the step of starting the test device, reading the hardware identification information of the test device, and performing key derivation processing based on the hardware identification information to obtain a dynamic decryption key includes: Start the test equipment and read the hardware identification information of the test equipment; wherein, the hardware identification information includes at least one of the following: device identifier, FPGA unique identifier, MAC address and driver serial number; The hardware identification information described above is spliced ​​together to obtain spliced ​​information; Perform a SHA256 hash operation on the concatenated information to obtain the hash result; The first 128 bits of the hash operation result are extracted to obtain the dynamic decryption key.

[0013] As an optional solution, when the test process reaches the target test project and the target test project meets the pre-configured preset trigger conditions, the target encrypted segment is located from the encrypted segment set, and the target encrypted segment is decrypted using the dynamic decryption key to obtain the corresponding plaintext executable code, including: Monitor the progress of the test process and determine whether the test has reached the target test item. When the test process reaches the target test project, read the metadata set in the dynamic link library; Based on the preset triggering conditions, the target encrypted segment corresponding to the target test item is matched and located from the encrypted segment set; The target encrypted section is decrypted using the dynamic decryption key to obtain the corresponding plaintext executable code.

[0014] As an optional approach, the method of using multiple threads to transmit the measurement data to an external processing unit for computation includes: The measurement data is acquired using the raw data acquisition thread; The measurement data is processed by a packet processing thread, which performs packetization and checksum encapsulation. The encapsulated measurement data is asynchronously sent to an external processing unit using a network transmission thread; The received measurement data is demodulated and mathematically processed using a signal analysis process located in the external processing unit.

[0015] As an optional approach, the plaintext executable code in the temporary execution buffer is securely cleaned up, including: The temporary execution buffer is overwritten with a fixed value; The temporary execution buffer is overwritten again with random values; Perform a CPU cache refresh operation; Perform virtual memory release operation.

[0016] As an optional solution, an anomaly monitoring and processing step is also included; the anomaly monitoring and processing step includes: Detect abnormal events during the decryption and test operation process; wherein, the abnormal events include at least one of the following: device identification mismatch, verification value verification failure, segment header abnormality, and decryption failure; If an abnormal event is detected, the current test process is aborted, the temporary execution buffer is safely cleared, the driver session is locked, and a security event log is recorded.

[0017] According to another aspect of the present invention, a radio frequency test procedure protection system with segment dynamic decryption and multi-threaded offloading is also provided, comprising: The segmented encryption module is used to divide the radio frequency test program into multiple test segments according to the test process, and encrypt each test segment separately to obtain encrypted segments, forming an encrypted segment set; The dynamic key derivation module is used to start the test equipment, read the hardware identification information of the test equipment, and perform key derivation processing based on the hardware identification information to obtain a dynamic decryption key. The on-demand decryption execution module is connected to the segmented encryption module and the dynamic key derivation module. When the test process runs to the target test project and the target test project meets the pre-configured preset trigger conditions, it locates the target encrypted segment from the encrypted segment set and decrypts the target encrypted segment using the dynamic decryption key to obtain the corresponding plaintext executable code. A multi-threaded data transmission module, connected to the on-demand decryption and execution module, is used to load the plaintext executable code into a temporary execution buffer and run it to perform the radio frequency measurement operation corresponding to the target test item and obtain measurement data; and the multi-threaded transmission module is connected to an external processing unit to use multi-threading to transmit the measurement data to the external processing unit for calculation. The security clearing module, connected to the multi-threaded data transmission module, is used to perform security clearing of plaintext executable code in the temporary execution buffer after the RF measurement operation corresponding to the target test item is completed. The exception handling module, connected to the on-demand decryption execution module and the security clearing module, is used to terminate the current test process, securely clear the temporary execution buffer, lock the driver session, and record the security event log when a device identifier mismatch, check value verification failure, segment header abnormality, or decryption failure is detected.

[0018] According to another aspect of the present invention, an electronic device is also provided, the electronic device including a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the method as described above.

[0019] According to another aspect of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described above.

[0020] The beneficial effects of this invention are as follows: 1. This invention segments and encrypts each section of the test program, decrypting each section only when the test flow reaches the corresponding test item. The decrypted plaintext executable code is only temporarily stored in the execution buffer and is securely cleared after execution. This ensures the decrypted code resides in memory for an extremely short time, making it difficult for attackers to extract the complete test program code through memory dumping, effectively resisting static reverse engineering and dynamic memory attacks. Furthermore, the decryption key is dynamically derived based on the hardware identification information of the test device. Different devices generate different keys. Even if the encrypted section set is copied to other devices, the hardware differences will prevent the generation of the correct decryption key, thus preventing unauthorized cross-device copying and execution, achieving a deep binding between the test program and the device.

[0021] 2. This invention adopts a segmented on-demand decryption mechanism. During the test, only the single encrypted segment corresponding to the current target test item is decrypted, rather than the entire test program is decrypted. The amount of data decrypted in a single operation is greatly reduced, and the calculation delay is significantly reduced. This can meet the stringent real-time requirements of radio frequency testing for microsecond-level response, avoid the test rhythm delay caused by overall encryption and decryption, ensure that the throughput of high-frequency testing on the production line is not affected, and ensure the real-time performance of the test.

[0022] 3. This invention uses a multi-threaded mechanism to asynchronously transmit measurement data to an external processing unit for computation, offloading time-consuming signal demodulation and mathematical operations from the test equipment (such as an FPGA or ATE main controller) to an external processing unit (such as an industrial control computer). This allows the test equipment to focus solely on accurate RF signal acquisition and real-time hardware control, decoupling data acquisition from complex computations. This effectively reduces the computational burden on the test equipment, and the overall test throughput is no longer limited by the single computing resources of the equipment. The system's scalability and testing efficiency are significantly improved.

[0023] 4. This invention ensures program security without introducing global decryption delay through segmented encryption and on-demand decryption mechanisms, prevents cross-device copying without increasing runtime overhead through hardware information binding key derivation, and improves test throughput without reducing security level through multi-threaded external unloading. It organically integrates program security protection mechanisms and test data collaborative processing mechanisms at the system architecture level, eliminating the mutual constraints between security assurance and test efficiency improvement, and achieving a balance between high security and high real-time performance. Attached Figure Description

[0024] To more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are merely some embodiments of the present invention, and those skilled in the art can obtain other embodiments based on these drawings without creative effort.

[0025] Figure 1 This is a flowchart of a radio frequency test program protection method for segment dynamic decryption and multi-threaded offloading, as described in an embodiment of the present invention.

[0026] Figure 2 This is a schematic diagram of the system structure in an embodiment of the present invention.

[0027] Figure 3 This is a schematic diagram of the structure of the electronic device created by this invention. Detailed Implementation

[0028] Embodiments of the present invention will now be described in more detail with reference to the accompanying drawings. While some embodiments of the present invention are shown in the drawings, it should be understood that the present invention can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of the present invention. It should be understood that the drawings and embodiments of the present invention are for illustrative purposes only and are not intended to limit the scope of protection of the present invention.

[0029] Example 1 Figure 1 This illustrates a segmented dynamic decryption and multi-threaded offloading method for protecting RF test procedures, including: Step S11: Divide the radio frequency test program into multiple test segments according to the test process, and encrypt each test segment separately to obtain the corresponding encrypted segments, forming an encrypted segment set.

[0030] The aforementioned test segment refers to an independent program unit obtained by logically dividing a complete RF test program according to the functional modules or execution timing in the test process. Each test segment corresponds to one or more test items (such as calibration, frequency scanning, power measurement, modulation quality analysis, etc.) and has an independent segment identifier, memory offset address, check value, and trigger condition. The test segment is the basic granularity unit for realizing on-demand decryption in this invention.

[0031] The aforementioned encrypted segment set refers to the collection of encrypted data units obtained by independently encrypting each test segment using a separate encryption algorithm. Each encrypted segment corresponds one-to-one with the original test segment, and the encrypted segment set is deployed in the test equipment as the storage format of the test program.

[0032] By segmenting and encrypting the test program into sections, the test program no longer exists in complete plaintext form on the storage medium. Even if an attacker obtains the program file on the storage medium, they cannot directly obtain the complete test algorithm logic, thus providing a basis for subsequent on-demand decryption. Furthermore, since each test section is encrypted independently, cracking a single section will not affect the security of other sections, creating a prerequisite for subsequent on-demand decryption of only the currently needed section.

[0033] Step S12: Start the test device, read the hardware identification information of the test device, and perform key derivation processing based on the hardware identification information to obtain the dynamic decryption key.

[0034] The aforementioned hardware identification information refers to a set of unique and non-replicable hardware characteristic parameters in RF test equipment. This includes, but is not limited to, device identifiers, FPGA unique identifiers, MAC addresses, and driver serial numbers, which together constitute the inherent characteristics of the device.

[0035] The aforementioned key derivation process refers to the process of taking hardware identification information as input and performing operations using a one-way cryptographic function to derive the decryption key from that information. This process is one-way, meaning that the original hardware identification information cannot be deduced from the derived key.

[0036] The aforementioned dynamic decryption key refers to a decryption key generated in real time based on the hardware identification information of the current test device. This key is not stored in the storage medium for a long period of time, but is calculated temporarily when the device starts up or during operation. Different hardware devices generate different keys, realizing a one-to-one correspondence between devices and keys.

[0037] By deriving dynamic decryption keys from hardware identification information, the decryption keys are deeply bound to the hardware of the test device. Since different devices have different hardware identification information, the derived decryption keys also differ. Even if the entire encrypted segment set is copied to another device, the device will be unable to derive the correct decryption key due to the difference in hardware identification information, thus failing to decrypt and execute the test program. This effectively prevents unauthorized cross-device copying and execution. Furthermore, the keys are not stored permanently on storage media, reducing the risk of key leakage.

[0038] Step S13: When the test process reaches the target test project and the target test project meets the pre-configured preset trigger conditions, the target encrypted section is located from the encrypted section set, and the target encrypted section is decrypted using the dynamic decryption key to obtain the corresponding plaintext executable code.

[0039] The aforementioned target test items refer to the specific test tasks currently being performed or about to be performed in the RF test process. The RF test process typically consists of multiple test items arranged sequentially, including frequency scanning test items, power measurement test items, modulation quality analysis test items, etc. Each target test item corresponds to one or more test segments.

[0040] The aforementioned preset triggering conditions refer to the pre-set rules used to determine the matching relationship between the target test item and the test segment. That is, when the test process runs to a certain target test item, the driver searches for and locates the target encrypted segment corresponding to the target test item from the encrypted segment set according to the rules.

[0041] The aforementioned plaintext executable code refers to the original program code obtained after decrypting the target encrypted section using a dynamic decryption key, which can be directly loaded and run by the processor. This code is in plaintext form and only exists temporarily in the temporary execution buffer during the execution of the current test project.

[0042] Precise on-demand decryption is achieved by pre-setting trigger conditions. This means that only the single encrypted segment corresponding to the current target test item is decrypted during the test, rather than the entire test program. This significantly reduces the amount of data decrypted per run and reduces computational latency, meeting the stringent real-time requirements of microsecond-level response in RF testing. Furthermore, the decrypted plaintext executable code exists only during the execution of the current test item; segments not currently needed remain encrypted, minimizing the time window during which plaintext code is exposed in memory.

[0043] Step S14: Load the plaintext executable code into the temporary execution buffer and run it to perform the RF measurement operation corresponding to the target test item, obtain the measurement data, and use multi-threading to transmit the measurement data to the external processing unit for calculation.

[0044] The aforementioned temporary execution buffer refers to a specially allocated temporary executable memory area in system memory used to store the decrypted plaintext executable code of the current test segment. This temporary execution buffer is temporary and exclusive; it is only used to store the decrypted code of the current test segment during its execution and is cleared after execution is complete. Unlike the traditional method of keeping the entire test program resident in memory, this buffer only stores the code of the currently needed segment at any given time.

[0045] The aforementioned multithreading refers to a technical mechanism that executes multiple execution flows in parallel. This decouples measurement data acquisition, packet processing, network transmission, and signal analysis into different threads for parallel execution, preventing a single execution flow from blocking the testing process due to waiting for data or performing calculations. Multithreading includes a raw data acquisition thread, a packet processing thread, a network transmission thread, and a signal analysis process located in an external processing unit.

[0046] The aforementioned external processing unit refers to an external computing device independent of the RF test equipment (such as an ATE or FPGA main controller), used to receive measurement data collected by the test equipment and perform high-load signal analysis operations. This external processing unit can be an Industrial Personal Computer (IPC), and the operations it performs include, but are not limited to, Fast Fourier Transform (FFT) and Error Vector Magnitude (EVM) analysis.

[0047] By loading plaintext executable code into a temporary execution buffer instead of residing it permanently in system memory, attackers find it difficult to obtain code from other memory areas using conventional memory read methods. By utilizing a multi-threaded mechanism to asynchronously transmit measurement data to an external processing unit for computation, time-consuming signal demodulation and mathematical operations are offloaded from the test device to the external processing unit. This allows the test device to focus solely on precise RF signal acquisition and real-time hardware control, decoupling data acquisition from complex computations. This effectively reduces the computational burden on the test device, and the overall test throughput is no longer limited by the single computing resources of the device.

[0048] Step S15: After the RF measurement operation corresponding to the target test item is completed, the plaintext executable code in the temporary execution buffer is safely cleared.

[0049] The aforementioned secure cleanup process refers to a complete and irreversible destruction of the plaintext executable code in the temporary execution buffer, rather than simply releasing memory or marking it as overwriteable. This secure cleanup process includes multiple overwrite operations and cache synchronization to ensure that all copies of the plaintext executable code are completely destroyed and cannot be recovered through memory dumps or cache analysis.

[0050] By securely clearing the temporary execution buffer after execution, the decrypted code resides in memory for an extremely short time, preventing attackers from extracting the complete test program code through memory dumping. Even if an attacker obtains a memory snapshot during test execution, the complete test program is difficult to obtain because only a portion of the current test segment's code exists in memory at any given time, and the execution window is extremely short. This mechanism, combined with the on-demand decryption in step S13, ensures that the test program is not completely present in memory throughout its entire runtime lifecycle, effectively resisting static reverse engineering and dynamic memory attacks.

[0051] The execution entity for the above steps is a computing device deployed in the RF testing scenario, including but not limited to at least one of the following: an automatic test equipment (ATE) main control computer, an RF test system integration server, a test data centralized analysis platform, a local test controller deployed at a production line test site, or an RF signal analysis workstation deployed in a laboratory or R&D facility. This invention does not limit itself to a single physical entity; any computing device capable of implementing the data processing logic and deployed in an RF testing scenario can serve as the execution entity.

[0052] Specifically, in step S11, the radio frequency test procedure is divided into multiple test segments according to the test flow, and each test segment is encrypted separately to obtain encrypted segments, forming an encrypted segment set, including: Step S111: Divide the RF test procedure into multiple test segments according to the test process.

[0053] In this embodiment, the radio frequency test program is divided into multiple test segments according to the functional modules and execution sequence in the test process.

[0054] In this embodiment, the test segment includes at least a calibration segment, a frequency scanning segment, a power measurement segment, and a modulation quality analysis segment. Each test segment corresponds to one or more test items, and the test segment serves as the basic unit of granularity for subsequent decryption.

[0055] Step S112: Configure an independent segment identifier, memory offset address, check value and preset trigger conditions for each test segment, and collect and organize them to form a metadata set.

[0056] In this embodiment, the segment ID is used to uniquely identify the current test segment; the memory offset address is used to indicate the starting position of the current test segment in the memory; the checksum is used to verify the integrity and authenticity of the test segment data before decryption; and the preset trigger condition is used to define the test item or runtime corresponding to the current test segment, including the target test item identification information corresponding to each test segment.

[0057] The attribute information of each test segment is collected and organized into a metadata set, which is used by the driver to perform segment matching and location during test execution.

[0058] In a preferred embodiment, the metadata set is a segment table.

[0059] Step S113: Encrypt each test segment using the AES-128 encryption algorithm to obtain the corresponding encrypted segments, forming an encrypted segment set.

[0060] In this embodiment, the AES-128 algorithm is a symmetric encryption algorithm with a key length of 128 bits in the Advanced Encryption Standard. After each test segment is encrypted independently, each test segment corresponds to an encrypted segment, and all encrypted segments together constitute an encrypted segment set.

[0061] It should be noted that each test segment is encrypted independently, which isolates the test segments from each other. Cracking a single segment does not affect the security of other segments.

[0062] Step S114: Embed the metadata set and the encrypted segment set into the dynamic link library.

[0063] In this embodiment, the metadata set and the encrypted segment set are embedded together in a dynamic link library (DLL) as the deployment form of the test program.

[0064] It should be noted that the encrypted sections in the dynamic link library exist in ciphertext form. Each encrypted section remains encrypted during the deployment and loading phases of the test program. It is only dynamically decrypted by the driver and loaded into a temporary execution buffer for execution when the test is executed to the corresponding test item.

[0065] Specifically, in step S12, the test device is started, its hardware identification information is read, and key derivation processing is performed based on the hardware identification information to obtain a dynamic decryption key, including: Step S121: Start the test equipment and read the hardware identification information of the test equipment.

[0066] In this embodiment, the testing equipment is an automated test equipment (ATE).

[0067] In this embodiment, the hardware identification information includes at least one of the following: Device ID, FPGA Unique Identifier (FPGAUID), MAC Address, and Driver Serial Number. Specifically, the Device ID serves as a unique device identifier for the test equipment, used to uniquely identify the test machine; the FPGA Unique Identifier is a unique, unchangeable number programmed into the FPGA chip at the factory; the MAC Address is the physical address of the test equipment's network interface card; and the Driver Serial Number is the authorized serial number for the test equipment's driver software.

[0068] Step S122: The various hardware identification information are spliced ​​together to obtain spliced ​​information.

[0069] In this embodiment, the various hardware identification information are concatenated into strings in a predetermined order to form concatenated information.

[0070] In a preferred embodiment, the device identifier, FPGA unique identifier, MAC address and driver serial number are concatenated in the order of "Device_ID+FPGA_UID+MAC_Address+Driver_Serial" to form a string in the format of "Device_ID+FPGA_UID+MAC_Address+Driver_Serial", which is used as the input for subsequent hash operations.

[0071] It should be noted that when only one item of hardware identification information is read from the test equipment, the current item of hardware identification information is used as the subsequent splicing information; when multiple items of hardware identification information are read from the test equipment, the multiple items of hardware identification information are spliced ​​together.

[0072] Step S123: Perform SHA256 hash operation on the concatenated information to obtain the hash operation result.

[0073] In this embodiment, SHA256 is a cryptographic hash function with an output length of 256 bits in the secure hash algorithm family, which has one-way and collision resistance.

[0074] Specifically, after performing a SHA256 hash operation on the concatenated information input, a 256-bit hash result is obtained.

[0075] Step S124: Extract the first 128 bits of the hash operation result to obtain the dynamic decryption key.

[0076] In this embodiment, the first 128 bits of the hash operation result are extracted to obtain a 128-bit dynamic decryption key (AES_Key).

[0077] Specifically, the key derivation processing method can be expressed as: AES_Key=SHA256(Device_ID+FPGA_UID+MAC_Address+Driver_Serial)[0:127bit]; In the formula, SHA256() represents the SHA256 hash operation; + represents the string concatenation operation; [0:127bit] represents extracting the first 128 bits of the hash result.

[0078] Specifically, in step S13, when the test process reaches the target test item and the target test item meets the pre-configured preset trigger conditions, the target encrypted section is located from the encrypted section set, and the target encrypted section is decrypted using the dynamic decryption key to obtain the corresponding plaintext executable code, including: Step S131: Detect the progress of the test process and determine whether the current test has reached the target test item.

[0079] In this embodiment, the driver monitors the progress of the RF test process in real time and determines whether the current test process has reached the target test item. The RF test process consists of multiple test items executed sequentially according to a predetermined order, with each test item corresponding to one or more test segments. By monitoring and comparing the currently executing test item identifier with the preset test item sequence, it is determined whether the target test item requiring decryption has been reached.

[0080] Step S132: When the test process reaches the target test project, read the metadata set in the dynamic link library.

[0081] In this embodiment, when the test process reaches the target test item, the driver reads the metadata set in the dynamic link library (DLL) to obtain the metadata information of each encrypted segment, providing a basis for subsequent segment matching and location.

[0082] Step S133: Based on the preset triggering conditions, locate the target encrypted segment corresponding to the target test item from the encrypted segment set.

[0083] Specifically, the driver compares the project identifier of the current target test project with the trigger conditions of each test segment in the metadata set. When the trigger condition of a certain test segment matches that of the current target test project, the current test segment is identified as the target test segment corresponding to the current test project, and its corresponding encrypted segment is the target encrypted segment. Through the matching and positioning operation, the target encrypted segment required by the current target test project is accurately obtained.

[0084] Step S134: Decrypt the target encrypted section using the dynamic decryption key to obtain the corresponding plaintext executable code.

[0085] Specifically, the driver uses a dynamic decryption key (AES_Key) to decrypt the target encrypted section. After AES-128 decryption, it is restored to the original executable program code, i.e. plaintext executable code, which serves as the original program code for the test section corresponding to the current target test item, and is directly loaded and run by the processor.

[0086] It should be noted that the encrypted sections of non-target test items remain encrypted and are not decrypted.

[0087] Specifically, in step S14, plaintext executable code is loaded into a temporary execution buffer and run to perform the RF measurement operation corresponding to the target test item, obtain measurement data, and use multi-threading to transmit the measurement data to an external processing unit for calculation, including: Step S141: Load the plaintext executable code into the temporary execution buffer and run it to perform the RF measurement operation corresponding to the target test item and obtain the measurement data.

[0088] In this embodiment, the RF measurement operations include, but are not limited to, frequency scanning, power measurement, and modulation quality analysis. After performing the RF measurement operations, the raw RF test data is obtained.

[0089] It should be noted that the decrypted plaintext executable code is only temporarily stored in the Temporary Execution Buffer during the execution of the current target test project, and is safely cleared after the current target test project has finished executing, in order to minimize the time window during which the plaintext executable code is exposed in memory.

[0090] Step S142: Use multithreading to transmit the measurement data to an external processing unit for calculation.

[0091] In this embodiment, the multithreading includes a raw data acquisition thread, a packet processing thread, a network transmission thread, and a signal analysis process. The signal analysis process is located in an external processing unit.

[0092] Specifically, multithreading is used to transmit measurement data to an external processing unit for computation, including: Step S1421: Obtain measurement data using the raw data acquisition thread.

[0093] In this embodiment, the raw data acquisition thread (RF Raw Data Capture) is used to acquire raw measurement data of the radio frequency test from the hardware register via direct memory access (DMA), and the acquired data is written to the DMA buffer.

[0094] In this embodiment, the raw data acquisition thread is executed by the test device driver layer or FPGA, which is responsible for efficiently moving the test data from the hardware registers to the system memory, ensuring the real-time and high-speed nature of data acquisition, and avoiding the occupation of processor computing resources.

[0095] Step S1422: The measurement data is divided into packets and encapsulated with checksums using the packet processing thread.

[0096] In this embodiment, the measurement data in the DMA buffer is divided into multiple data packets using a packet formatting thread, and a checksum is added to each data packet to ensure the integrity and reliability of data transmission.

[0097] In this embodiment, the packet processing thread is executed by the main CPU of the test device to format the raw waveform data and encapsulate the raw measurement data into a data packet format suitable for network transmission.

[0098] In this embodiment, the checksum is CRC32; in practical applications, checksum, hash and other verification methods can also be used.

[0099] Step S1423: The encapsulated measurement data is asynchronously sent to the external processing unit using a network transmission thread.

[0100] In this embodiment, the encapsulated data packets are asynchronously sent to the external processing unit via high-speed Ethernet using the TCP / IP Transmission thread.

[0101] In this embodiment, the network transmission thread is executed by the network interface card (NIC), and data transmission is performed via the TCP / IP Socket protocol. The asynchronous sending mechanism allows the test device to continue executing subsequent acquisition tasks without waiting for data packet transmission to complete, effectively avoiding network transmission delays from blocking the test process and enabling parallel execution of data acquisition and data transmission.

[0102] Step S1424: The received measurement data is demodulated and mathematically processed using a signal analysis process located in an external processing unit.

[0103] In this embodiment, after the external processing unit receives the data packet, the signal analysis process (FFT / EVM Analysis) set in the external processing unit performs signal demodulation and mathematical operations on the received data packet. The signal demodulation and mathematical operations include, but are not limited to, Fast Fourier Transform (FFT) and Error Vector Magnitude (EVM) demodulation analysis.

[0104] In a preferred embodiment, the external processing unit is an industrial control computer (IPC).

[0105] It should be noted that in practical applications, the signal demodulation and mathematical processing can be adjusted according to the requirements of the test project, and may include RF-related operations such as power calculation, signal-to-noise ratio calculation, and spectrum analysis.

[0106] It should be noted that the test judgment result of the target test item is determined based on the calculation result obtained after signal demodulation and mathematical operation processing, which is used to decide whether to continue to execute the next test item.

[0107] Specifically, in step S15, after the RF measurement operation corresponding to the target test item is completed, the plaintext executable code in the temporary execution buffer is securely cleared, including: Step S151: Overwrite the temporary execution buffer with a fixed value.

[0108] In this embodiment, the temporary execution buffer is overwritten with a fixed value of 0x00.

[0109] Specifically, all bytes in the temporary execution buffer are written to 0x00 to overwrite the plaintext executable code originally stored in the buffer, so that the plaintext executable code originally stored in the temporary execution buffer is completely overwritten and cannot be recovered by conventional memory reading methods.

[0110] Step S152: The temporary execution buffer is overwritten again with a random value.

[0111] Specifically, after overwriting the fixed value 0x00, a string of random values ​​is generated and written to the Temporary Execution Buffer, overwriting the written fixed value 0x00. This ensures that all data traces of the original plaintext executable code are completely destroyed, and the original data cannot be recovered even with advanced memory analysis techniques.

[0112] Step S153: Perform a CPU cache refresh operation.

[0113] Because the processor may cache some code or data in the CPU's L1, L2, or L3 cache during the execution of plaintext executable code, simply clearing the code from system memory (RAM) is insufficient to completely destroy all code copies. Therefore, by performing a CPU cache flush operation, all remaining plaintext executable code copies in the processor cache are written back and cleared, ensuring that all copies of the plaintext executable code are completely destroyed and cannot be recovered through cache analysis.

[0114] Step S154: Perform virtual memory release operation.

[0115] Specifically, the operating system's memory management interface is invoked to unmap the virtual memory corresponding to the temporary execution buffer, releasing the physical memory pages it occupies. By releasing the virtual memory, the operating system can reclaim this portion of physical memory and reallocate it to other processes, further ensuring that plaintext executable code cannot be obtained through memory dumping.

[0116] It should be noted that the security cleanup process ensures that all copies of the plaintext executable code in the system memory, processor cache, and virtual memory are completely destroyed, so that the test program never exists in the test device in complete plaintext form at any time, effectively resisting static reverse engineering and dynamic memory attacks.

[0117] In this embodiment, an anomaly monitoring and processing step is also included. This anomaly monitoring and processing step includes: Step S161: Detect abnormal events during the decryption and test run.

[0118] In this embodiment, the abnormal event includes at least one of the following: device identification mismatch, check value verification failure, segment header abnormality, and decryption failure.

[0119] Specifically, a device ID mismatch occurs when the device ID of the current test device does not match the expected value, indicating that the test program may have been copied to an unauthorized device for execution, or that the device identity cannot pass the legitimacy verification; a checksum verification failure occurs when the checksum before decryption of the target encrypted segment is inconsistent with the expected value, indicating that the encrypted segment data may have been tampered with, damaged, or abnormal during storage or transmission; an abnormal segment header occurs when the segment header information of the encrypted segment cannot be correctly parsed or does not conform to the predetermined format, indicating that the segment data may have been corrupted or unauthorized modified; and a decryption failure occurs when an error occurs when using the dynamic decryption key to decrypt the target encrypted segment, indicating that the decryption key does not match the encrypted segment, or that the encrypted segment data has been tampered with.

[0120] Step S162: If an abnormal event is detected, the current test process is terminated, the temporary execution buffer is safely cleared, the driver session is locked, and a security event log is recorded.

[0121] Specifically, when an abnormal event occurs, the ongoing RF testing process is suspended to prevent the test program from continuing to execute under abnormal conditions, which could lead to further security risks or equipment damage. All data in the temporary execution buffer is immediately cleared to prevent plaintext executable code from being illegally exported or reused under abnormal conditions. The current driver session is locked to prevent continuous attacks, and relevant information about this abnormal event is recorded in the security event log. The security event log includes, but is not limited to, the type of abnormal event, the time of occurrence, the identifier of the target test item or encrypted section that triggered the abnormality, and the hardware identification information of the current test device, for subsequent auditing, troubleshooting, and attack tracing analysis.

[0122] It should be noted that locked driver sessions require administrator authorization or a restart of the test device to be restored.

[0123] Example 2 Based on the same design concept, such as Figure 2 As shown, this embodiment provides a radio frequency test program protection system with segment dynamic decryption and multi-threaded offloading, including: The segmented encryption module is used to divide the radio frequency test program into multiple test segments according to the test process, and encrypt each test segment separately to obtain the corresponding encrypted segments, forming an encrypted segment set.

[0124] The dynamic key derivation module is used to start the test equipment, read the hardware identification information of the test equipment, and perform key derivation processing based on the hardware identification information to obtain the dynamic decryption key.

[0125] The on-demand decryption execution module, connected to the segmented encryption module and the dynamic key derivation module, is used to locate the target encrypted segment from the encrypted segment set when the test process runs to the target test project and the target test project meets the pre-configured preset trigger conditions, and to decrypt the target encrypted segment using the dynamic decryption key to obtain the corresponding plaintext executable code.

[0126] The multi-threaded data transmission module, connected to the on-demand decryption and execution module, is used to load plaintext executable code into a temporary execution buffer and run it to perform the RF measurement operation corresponding to the target test item, obtain measurement data, and use multi-threading to transmit the measurement data to an external processing unit for calculation.

[0127] In this embodiment, the multi-threaded data transmission module is connected to an external processing unit to receive measurement data and perform signal demodulation and mathematical operations.

[0128] The security clearing module, connected to the on-demand decryption execution module, is used to securely clear the plaintext executable code in the temporary execution buffer after the RF measurement operation corresponding to the target test item is completed.

[0129] The exception handling module, connected to the on-demand decryption execution module and the security clearing module, is used to terminate the current test process, securely clear the temporary execution buffer, lock the driver session, and record the security event log when a device identifier mismatch, check value verification failure, segment header abnormality, or decryption failure is detected.

[0130] In a preferred embodiment, the external processing unit may be an industrial computer (IPC).

[0131] Example 3 Embodiments of the present invention also provide a non-transitory machine-readable medium storing a computer program, wherein the computer program, when executed by a computer's processor, is used to cause the computer to perform a method according to an embodiment of the present invention.

[0132] Example 4 Embodiments of the present invention also provide a computer program product, including a computer program, wherein the computer program, when executed by a computer's processor, is used to cause the computer to perform the method of an embodiment of the present invention.

[0133] Example 5 An embodiment of the present invention also provides an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor. The memory stores a computer program executable by the at least one processor, which, when executed by the at least one processor, causes the electronic device to perform the method of the embodiment of the present invention.

[0134] refer to Figure 3 The present invention will now describe a structural block diagram of an electronic device that can serve as an embodiment of the present invention, serving as an example of a hardware device applicable to various aspects of the present invention. The electronic device is intended to represent various forms of digital electronic computer devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present invention described and / or claimed herein.

[0135] like Figure 3 As shown, the electronic device includes a computing unit 301, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) 302 or a computer program loaded from a storage unit 308 into a random access memory (RAM) 303. The RAM 303 may also store various programs and data required for the operation of the electronic device. The computing unit 301, ROM 302, and RAM 303 are interconnected via a bus 304. An input / output (I / O) interface 305 is also connected to the bus 304.

[0136] Multiple components in the electronic device are connected to I / O interface 305, including: input unit 306, output unit 307, storage unit 308, and communication unit 309. Input unit 306 can be any type of device capable of inputting information into the electronic device. Input unit 306 can receive input digital or character information and generate key signal inputs related to user settings and / or function control of the electronic device. Output unit 307 can be any type of device capable of presenting information and may include, but is not limited to, a display, speaker, video / audio output terminal, vibrator, and / or printer. Storage unit 308 may include, but is not limited to, disks and optical discs. Communication unit 309 allows the electronic device to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks, and may include, but is not limited to, modems, network cards, infrared communication devices, and / or wireless communication transceivers, such as Bluetooth devices, WiFi devices, WiMax devices, cellular communication devices, and / or the like.

[0137] The computing unit 301 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 301 include, but are not limited to, CPUs, graphics processing units (GPUs), various special-purpose artificial intelligence (AI) computing units, various computing units running machine learning model algorithms, digital signal processors (DSPs), and any suitable processors, controllers, microcontrollers, etc. The computing unit 301 performs the various methods and processes described above. For example, in some embodiments, the method embodiments of the present invention can be implemented as computer programs tangibly contained in a machine-readable medium, such as storage unit 308. In some embodiments, part or all of the computer program can be loaded and / or installed on an electronic device via ROM 302 and / or communication unit 309. In some embodiments, the computing unit 301 can be configured to perform the methods described above by any other suitable means (e.g., by means of firmware).

[0138] Computer programs for implementing the methods of embodiments of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0139] In the context of embodiments of this invention, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable signal medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, or infrared systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0140] It should be noted that the term "comprising" and its variations used in the embodiments of this invention are open-ended, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". The modifications of "one" and "a plurality" mentioned in the embodiments of this invention are illustrative and not restrictive, and those skilled in the art should understand that unless explicitly indicated otherwise in the context, they should be understood as "one or more".

[0141] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in the embodiments of this invention are subject to strict compliance with relevant laws, regulations, and regulatory requirements in their collection, storage, use, processing, transmission, provision, and disclosure, and adhere to the principles of legality, legitimacy, necessity, and good faith. The acquisition of relevant information and data is premised on the user's explicit consent or other legitimate reasons, and a clear and convenient authorization management approach is provided to the user, allowing the user to independently choose to consent, withdraw consent, or refuse to provide relevant information. For functions that rely on user information, if the user does not authorize or withdraws authorization, the corresponding technical function cannot be implemented, and the technical solution of this invention is not applicable in this scenario. The steps described in the method implementation embodiments provided by the embodiments of this invention can be executed in different orders and / or in parallel. Furthermore, the method implementation embodiments may include additional steps and / or omit the steps shown. The scope of protection of this invention is not limited in this respect.

[0142] The term "embodiment" in this specification refers to a specific feature, structure, or characteristic described in connection with an embodiment that may be included in at least one embodiment of the invention. The appearance of this phrase in various places throughout the specification does not necessarily imply the same embodiment, nor does it imply independence or alternativeity from other embodiments. The various embodiments in this specification are described in a related manner, with reference to each other for similar or identical parts. In particular, for apparatus, device, and system embodiments, since they are substantially similar to method embodiments, the description is relatively simple, and relevant details are referred to in the description of the method embodiments.

[0143] The above-described embodiments are merely illustrative of several implementations of the present invention, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of protection. It should be noted that those skilled in the art can make various modifications and improvements without departing from the inventive concept of the present invention, and these modifications and improvements all fall within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the appended claims.

Claims

1. A method for protecting radio frequency test programs with segmented dynamic decryption and multi-threaded offloading, characterized in that, include: The radio frequency test procedure is divided into multiple test sections according to the test process, and each test section is encrypted to obtain the corresponding encrypted sections, forming an encrypted section set. Start the test equipment, read the hardware identification information of the test equipment, and perform key derivation processing based on the hardware identification information to obtain the dynamic decryption key; When the test process reaches the target test project and the target test project meets the pre-configured preset trigger conditions, the target encrypted section is located from the encrypted section set, and the target encrypted section is decrypted using the dynamic decryption key to obtain the corresponding plaintext executable code. The plaintext executable code is loaded into a temporary execution buffer and run to perform the radio frequency measurement operation corresponding to the target test item, obtain measurement data, and use multi-threading to transmit the measurement data to an external processing unit for calculation. After the radio frequency measurement operation corresponding to the target test item is completed, the plaintext executable code in the temporary execution buffer is securely cleared.

2. The RF test program protection method with segment dynamic decryption and multi-threaded offloading according to claim 1, characterized in that, The radio frequency test procedure is divided into multiple test segments according to the test process, and each test segment is encrypted to obtain encrypted segments, forming an encrypted segment set, including: The radio frequency test procedure is divided into multiple test sections according to the test process; wherein, the test section includes at least a calibration section, a frequency scanning section, a power measurement section, and a modulation quality analysis section; Each test segment is configured with an independent segment identifier, memory offset address, checksum, and preset trigger conditions, and these are collected and organized into a metadata set; wherein, the preset trigger conditions include the target test item identifier information corresponding to each test segment; Each test segment is encrypted using the AES-128 encryption algorithm to obtain the corresponding encrypted segments, forming a set of encrypted segments; The metadata set and the encrypted segment set are embedded in a dynamic link library.

3. The radio frequency test program protection method with segment dynamic decryption and multi-threaded offloading according to claim 1, characterized in that, The process of starting the test device involves reading the hardware identification information of the test device and performing key derivation processing based on the hardware identification information to obtain a dynamic decryption key, including: Start the test equipment and read the hardware identification information of the test equipment; wherein, the hardware identification information includes at least one of the following: device identifier, FPGA unique identifier, MAC address and driver serial number; The hardware identification information described above is spliced ​​together to obtain spliced ​​information; Perform a SHA256 hash operation on the concatenated information to obtain the hash result; The first 128 bits of the hash operation result are extracted to obtain the dynamic decryption key.

4. The RF test program protection method with segment dynamic decryption and multi-threaded offloading according to claim 2, characterized in that, When the test process reaches the target test project and the target test project meets the pre-configured preset trigger conditions, the target encrypted segment is located from the encrypted segment set, and the target encrypted segment is decrypted using the dynamic decryption key to obtain the corresponding plaintext executable code, including: Monitor the progress of the test process and determine whether the test has reached the target test item. When the test process reaches the target test project, read the metadata set in the dynamic link library; Based on the preset triggering conditions, the target encrypted segment corresponding to the target test item is matched and located from the encrypted segment set; The target encrypted section is decrypted using the dynamic decryption key to obtain the corresponding plaintext executable code.

5. The RF test program protection method with segment dynamic decryption and multi-threaded offloading according to claim 1, characterized in that, The step of using multi-threading to transmit the measurement data to an external processing unit for computation includes: The measurement data is acquired using the raw data acquisition thread; The measurement data is processed by a packet processing thread, which performs packetization and checksum encapsulation. The encapsulated measurement data is asynchronously sent to an external processing unit using a network transmission thread; The received measurement data is demodulated and mathematically processed using a signal analysis process located in the external processing unit.

6. The radio frequency test program protection method with segment dynamic decryption and multi-threaded offloading according to claim 1, characterized in that, The plaintext executable code in the temporary execution buffer is securely cleaned up, including: The temporary execution buffer is overwritten with a fixed value; The temporary execution buffer is overwritten again with random values; Perform a CPU cache refresh operation; Perform virtual memory release operation.

7. The radio frequency test program protection method with segment dynamic decryption and multi-threaded offloading according to claim 1, characterized in that, It also includes anomaly monitoring and handling steps; The anomaly monitoring and processing steps include: Detect abnormal events during the decryption and test operation process; wherein, the abnormal events include at least one of the following: device identification mismatch, verification value verification failure, segment header abnormality, and decryption failure; If an abnormal event is detected, the current test process is aborted, the temporary execution buffer is safely cleared, the driver session is locked, and a security event log is recorded.

8. A radio frequency test program protection system with segmented dynamic decryption and multi-threaded offloading, characterized in that, include: The segmented encryption module is used to divide the radio frequency test program into multiple test segments according to the test process, and encrypt each test segment separately to obtain encrypted segments, forming an encrypted segment set; The dynamic key derivation module is used to start the test equipment, read the hardware identification information of the test equipment, and perform key derivation processing based on the hardware identification information to obtain a dynamic decryption key. The on-demand decryption execution module is connected to the segmented encryption module and the dynamic key derivation module. When the test process runs to the target test project and the target test project meets the pre-configured preset trigger conditions, it locates the target encrypted segment from the encrypted segment set and decrypts the target encrypted segment using the dynamic decryption key to obtain the corresponding plaintext executable code. A multi-threaded data transmission module, connected to the on-demand decryption and execution module, is used to load the plaintext executable code into a temporary execution buffer and run it to perform the radio frequency measurement operation corresponding to the target test item and obtain measurement data. The multi-threaded transmission module is connected to an external processing unit and is used to transmit the measurement data to the external processing unit for calculation using multiple threads. The security clearing module, connected to the multi-threaded data transmission module, is used to perform security clearing of plaintext executable code in the temporary execution buffer after the RF measurement operation corresponding to the target test item is completed. The exception handling module, connected to the on-demand decryption execution module and the security clearing module, is used to terminate the current test process, securely clear the temporary execution buffer, lock the driver session, and record the security event log when a device identifier mismatch, check value verification failure, segment header abnormality, or decryption failure is detected.

9. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method according to any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 7.

Images