Simulation testing methods, apparatus, equipment and storage media

Abstract

This application relates to the field of performance testing technology, providing a simulation testing method, apparatus, device, and storage medium. The method is applied to an electronic device and includes: receiving an interface call request sent by a test system, the interface call request being used to request a target service system to execute a target business function; processing the interface call request using a simulation system within the electronic device to generate simulation results, the business processing logic of the simulation system being consistent with the business processing logic of the target service system; and finally sending the simulation results to the test system. This method not only reuses the business processing logic of the target service system without relying on reverse engineering, thus effectively reducing development cycle and adaptation costs, but also effectively avoids the testing limitations caused by the closed nature of the target service system in related technologies, achieving full-process testing independent of the target service system.

Description

Technical Field

[0001] This invention relates to the field of performance testing technology, and in particular to a simulation testing method, apparatus, equipment, and storage medium. Background Technology

[0002] The core business systems of the new generation of securities and futures industry, such as exchange order placement clients and clearing and settlement systems, are generally hardware-encryption-dependent information systems. They rely on dedicated equipment such as hardware encryption machines and hardware security modules (HMS) to complete operations such as signing transaction instructions and encrypting sensitive data. Furthermore, their encryption logic must strictly comply with industry security and cryptographic application standards to ensure the compliant operation of trading business.

[0003] Currently, the mainstream testing solutions for such systems in the industry fall into two categories: one is the real hardware deployment solution, which replicates the hardware encryption device configuration of the production environment, allowing the test system to directly call the hardware software development kit (SDK) interface to complete encryption calculations, ensuring that the test results are consistent with the production environment; the other is the full algorithm reproduction solution, which uses reverse engineering to analyze the hardware encryption logic, and then reproduces and encapsulates the same-name interface based on the open-source encryption library to achieve hardware-free testing, which is suitable for hardware cost-sensitive scenarios.

[0004] However, existing solutions have many technical shortcomings and are difficult to meet industry testing needs: real hardware deployment solutions suffer from strong hardware coupling, resulting in high hardware procurement and maintenance costs, and multiple teams competing for equipment resources; full algorithm reproduction solutions rely on reverse engineering, which has a long development cycle and high costs for adapting to new hardware. In addition, both types of solutions are limited by the closed nature of the primary system and cannot complete end-to-end full-process testing outside of the real primary system. Summary of the Invention

[0005] This application provides a simulation testing method to solve the technical problems of strong hardware coupling in real hardware deployment schemes in related technologies, and the reliance on reverse engineering.

[0006] In a first aspect, embodiments of this application provide a simulation testing method applied to an electronic device. The method includes: receiving an interface call request sent by a test system, the interface call request being used to request a target service system to execute a target service; processing the interface call request using a simulation system within the electronic device to generate simulation results; the service processing logic of the simulation system being consistent with the service system's service processing logic; and sending the simulation results to the test system.

[0007] In one embodiment, before processing the interface call request using the simulation system in the electronic device, the electronic device may further determine the processing mode of the interface call request, which includes a simulation mode and a real mode. Accordingly, processing the interface call request using the simulation system in the electronic device may specifically include: processing the interface call request using the simulation system when the processing mode is simulation mode; and calling the target service system to process the interface call request when the processing mode is real mode.

[0008] In one embodiment, the aforementioned interface call request may include a first type of request and a second type of request. The first type of request is used to request the execution of encryption-related and / or signature-related services, and the second type of request is used to request the execution of interactive services of the target service system. Correspondingly, the aforementioned processing of the interface call request using a simulation system in the electronic device to generate simulation results may specifically include: when the interface call request includes the first type of request, processing the interface call request using an encryption module in the simulation system to generate a first simulation result, wherein the encryption module integrates multiple encryption algorithms and / or signature algorithms; and when the interface call request includes the second type of request, processing the interface call request using an interactive module in the simulation system to generate a second simulation result.

[0009] In one embodiment, the encryption module may also integrate encryption output formats corresponding to different manufacturers. After the first simulation result is generated, the electronic device can determine the encryption output format of the target manufacturer corresponding to the test system, and adjust the format of the first simulation result using the encryption output format of the target manufacturer to generate a first simulation result that matches the encryption output format of the target manufacturer.

[0010] In one embodiment, the above-mentioned use of the encryption module in the simulation system to process the interface call request and generate a first simulation result may specifically include: obtaining a preset rule configuration file for abnormal scenarios, the rule configuration file containing abnormal triggering conditions and abnormal results corresponding to the abnormal triggering conditions; if the interface call request meets the abnormal triggering conditions, returning the abnormal result corresponding to the abnormal triggering conditions; if the interface call request does not meet the abnormal triggering conditions, using the encryption module to process the interface call request and generate a first simulation result.

[0011] In one embodiment, before receiving the interface call request sent by the test system, the validity of the simulation test environment of the electronic device can also be verified.

[0012] In one embodiment, the above-mentioned legality verification of the simulation test environment of the electronic device may specifically include: obtaining the identification information of the electronic device, and determining that the simulation test environment of the electronic device passes the legality verification if the identification information of the electronic device matches the preset identification information.

[0013] In one embodiment, the identification information of the electronic device includes at least one of the following: system variables of the electronic device, Media Access Control Address (MAC) address, or occupancy status of a test dedicated port.

[0014] Secondly, embodiments of this application provide a simulation testing device located in an electronic device, the simulation testing device comprising: The receiving module is used to receive interface call requests sent by the test system. The interface call requests are used to request the target service system to execute the target business.

[0015] The processing module is used to process interface call requests using a simulation system in an electronic device and generate simulation results. The business processing logic of the simulation system is consistent with the business processing logic of the target service system.

[0016] The sending module is used to send simulation results to the test system.

[0017] Thirdly, embodiments of this application provide an electronic device, including a processor and a memory storing a computer program, wherein the processor executes the program to implement the steps of the simulation testing method described in the first aspect.

[0018] Fourthly, embodiments of this application provide a non-transitory computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the simulation testing method described in the first aspect.

[0019] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the steps of the simulation testing method described in the first aspect.

[0020] The simulation testing method described in this application replaces the business processing logic of the target service system with a simulation system, severing the physical dependency between the testing system and the target service system. The testing team does not need to purchase and deploy the hardware equipment for the target service system, nor does it need to replicate the hardware configuration of the production environment, significantly reducing hardware procurement, data center deployment, and long-term operation and maintenance costs. Simultaneously, the simulation system supports parallel access testing by multiple teams, eliminating the problem of physical equipment resource contention and significantly improving test resource utilization and parallel testing efficiency. Furthermore, the business processing logic of the simulation system is completely consistent with that of the target service system. Therefore, the simulation system can reuse the business processing logic of the target service system without relying on reverse engineering, thereby effectively reducing development cycle and adaptation costs.

[0021] Furthermore, in the simulation testing method provided in this application, the testing system does not need to be connected to the target service system. The test can be completed through interaction with the simulation system. In this way, the testing limitations caused by the closed nature of the target service system (such as a primary system) in related technologies can be effectively avoided, and the whole process testing can be achieved without the target service system. Attached Figure Description

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

[0023] Figure 1 A flowchart illustrating a simulation testing method provided in an embodiment of this application; Figure 2 This is a structural framework diagram of a simulation testing method provided in an embodiment of this application; Figure 3 This is a schematic diagram illustrating the steps for developing a dynamic API hijacking module according to an embodiment of this application; Figure 4 This is a schematic diagram of the interaction flow of a simulation testing method provided in an embodiment of this application; Figure 5 This is a schematic diagram of the simulation testing device provided in the embodiments of this application; Figure 6 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

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

[0025] In the description of this invention, it should be understood that the terms "center," "lateral," "length," "width," "thickness," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicating orientation or positional relationships based on the orientation or positional relationships shown in the accompanying drawings, are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined with "first," "second," and "third" may explicitly or implicitly include one or more of the stated features. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0026] In the securities and futures industry, core business processes such as trading instruction transmission, client position and fund data storage, clearing key distribution, real-time market data push, and third-party access verification directly affect market stability, investor asset security, and industry compliance. Therefore, extremely high requirements are placed on data security and trading compliance. These core businesses require dedicated business systems with hardware encryption logic, including key systems such as exchange order placement clients, trading matching systems, clearing and settlement systems, market data publishing systems, and third-party access gateways. Specifically, the exchange order placement client must digitally sign trading instructions using the SM2 algorithm to ensure tamper-proof instructions; the trading matching system must encrypt and store sensitive data such as client positions and funds using the SM4 algorithm; the clearing and settlement system must rely on hardware encryption to securely distribute and store clearing keys; the market data publishing system must use hardware encryption to ensure the confidentiality and integrity of real-time market data transmission; and the third-party access gateway must verify the legitimacy of the accessing institution and the non-repudiation of instructions using an HSM hardware security module.

[0027] To ensure the authenticity and effectiveness of the aforementioned core business systems (i.e., secondary business systems), the validity verification of the hardware encryption verification logic must be completed first. This ensures that core aspects such as encryption operations, signature verification, and key management strictly comply with industry standards and business security standards, thereby facilitating the testing of various core business logics within the secondary business systems. In practice, the entire process testing and verification of critical business scenarios, such as the reporting of trading instructions in the exchange's order book client, the confirmation of fund transfers in the clearing and settlement system, and the sensitive market data pushes in the market data publishing system, all require successful hardware encryption verification as a prerequisite.

[0028] Test cases for such hardware encryption-dependent business systems must meet the dual core requirements specific to the securities and futures industry: First, the test execution process must rely on real and compliant hardware encryption devices (including nationally certified HSMs, encryption gateways, etc.), and complete core operations such as encryption calculations and signature verification by directly calling the hardware SDK interface. This ensures that the encryption logic, algorithm implementation, and key storage method in the test environment are completely consistent with the production environment, thereby meeting industry compliance requirements. Second, test cases must comprehensively cover various encryption-related sub-scenarios in securities and futures business scenarios. This includes conventional scenarios such as "normal trading instruction signing / sensitive data encryption," as well as abnormal scenarios such as "abnormal keys (key length error, key call failure due to insufficient trading permissions, key expiration)," "hardware failures (encryption machine offline, encryption calculation timeout under peak trading conditions, calculation failure due to encryption chip malfunction)," and "compliance verification anomalies (algorithm does not conform to national cryptographic standards, signature format does not conform to industry specifications)," ensuring the comprehensiveness of the test.

[0029] Practice has shown that only when the secondary business system functions correctly and the hardware encryption verification logic passes can the functional integrity, trading security, and fault tolerance of a securities and futures system be fully verified, thus supporting the normal progress of core business logic testing of the secondary business system. Conversely, if the encryption verification process fails or is non-compliant, it will not only lead to the interruption of trading business testing and the distortion of test results, but may also trigger data security risks and compliance penalties in the subsequent production environment. Therefore, the securities and futures industry urgently needs a simulation testing process suitable for hardware encryption-dependent information systems, with controllable costs and rapid iteration capabilities, to address the pain points in existing testing practices.

[0030] Currently, the mainstream technical solutions for testing "hardware encryption-dependent information systems" in the industry can be mainly divided into the following two categories: The first category is real hardware deployment solutions.

[0031] The core logic of this solution is to "replicate the hardware configuration of the production environment." By deploying hardware encryption devices identical to those in the production environment in the test environment, such as a Level 2 Chinese cryptographic machine, a Peripheral Component Interconnect Express (PCI-E) encryption card, and an HSM module, the test system can directly utilize the hardware's encryption capabilities to complete functional verification. Essentially, it uses real hardware as the core to ensure the consistency of test results with the production environment, making it suitable for core securities and futures business testing scenarios where the security and accuracy of test results are extremely critical.

[0032] This solution requires four core steps: hardware deployment, software configuration, security management, and testing and verification. The specific steps are as follows: 1. Hardware Procurement and Server Room Deployment: The testing party needs to procure hardware encryption machines compatible with the production environment, such as SM4PCI-E encryption cards, and deploy them in a dedicated test server room. This server room must meet stringent physical security requirements, such as biometric access control, 24-hour video surveillance, environmental stability requirements (e.g., temperature 20-25℃, humidity 40%-60%), and power redundancy requirements (equipped with an uninterruptible power supply (UPS) for uninterrupted power supply) to prevent hardware testing interruptions due to environmental fluctuations.

[0033] 2. Driver and SDK Installation and Configuration: Install the driver program for the hardware encryption machine on the test server, and deploy the encryption SDK provided by the device manufacturer. Configure system environment variables and specify the SDK library path to ensure that the test system can call core interfaces such as encryption, signing, and key verification normally.

[0034] 3. Network and Access Security Configuration: Configure a static Internet Protocol (IP), subnet mask, and gateway for the hardware encryption machine; open the communication port between the test server and the encryption machine; and restrict access to the test network segment only through firewall policies. Create a dedicated test account on the encryption machine's network (Web) management platform, assign "encryption / signature operation permissions," and bind a test key index to strictly isolate production keys from test keys to avoid key cross-contamination issues.

[0035] 4. Test Case Execution and Result Verification: The test system sends a test request to the hardware encryption machine through the SDK interface, inputting plaintext data, key index and other parameters; the hardware encryption machine performs encryption / signature operations and returns the result; the test system compares the returned result with the preset Known Answer Test (KAT) vector. If the results are consistent, the test case is deemed to have passed; otherwise, the problem is located in the hardware configuration or interface call process.

[0036] This solution has become the mainstream choice in the securities and futures industry due to its ability to ensure consistency between test results and the production environment. It is widely used in core business scenarios such as trading and order placement system testing, clearing and settlement system testing, and market data transmission system testing. In terms of cost and efficiency, the basic configuration of a single test environment requires investment in hardware procurement costs, primarily covering nationally compliant encryption equipment, dedicated server racks, uninterruptible power supplies, and other basic data center facilities. The environment setup cycle is relatively short, mainly involving hardware deployment and driver development, SDK debugging, and other aspects. Regarding maintenance, a single environment does not require dedicated maintenance personnel; part-time maintenance personnel can manage multiple similar test environments, responsible for routine maintenance tasks such as driver version upgrades, key resets, and hardware fault diagnosis. Annual maintenance costs mainly include original manufacturer hardware maintenance services, basic data center energy consumption, and the allocation of maintenance personnel costs; overall, maintenance costs are within a controllable range.

[0037] The second category is the full algorithm reproduction scheme (a software-simulated hardware testing scheme).

[0038] The core logic of this solution is to "completely reproduce the operational logic of the hardware encryption machine using software." This involves reverse engineering the encryption algorithms of the hardware encryption machine (such as SM2 elliptic curve signature and SM4 block cipher) and the vendor's proprietary optimization rules (such as salting strategies for key derivation and hash algorithm variants for signatures). Then, based on open-source encryption libraries, such as the Open Source Secure Sockets Layer Library (OpenSSL), the above logic is reproduced and encapsulated into an interface with the same name as the original hardware SDK. Ultimately, this achieves the effect of "the test system can call the simulated encryption function without hardware dependency," thereby avoiding the cost of purchasing and deploying real hardware.

[0039] This solution requires four core steps: algorithm analysis, logic reproduction, interface encapsulation, and verification and optimization. The specific steps are as follows: 1. Hardware Encryption Machine Algorithm Reverse Engineering: Professional reverse engineering tools are used to decompile the hardware encryption machine's SDK, analyze the call flow of core functions, and extract algorithm parameters. If the SDK is protected by packers such as UltimatePacker for eXecutables (UPX) or Virtual Machine Protect (VMProtect), debugging tools must be used to unpack the packers before further analysis of the instruction logic. For vendor-specific rules, the details of the rules must be deduced through a "fixed input - multiple sets of output comparison" method.

[0040] 2. Algorithm Reproduction Based on Open Source Libraries: Select open source libraries that support national cryptographic algorithms and write reproduction code based on reverse analysis results; for example, when reproducing the encryption function, first call the initialization key process, then perform the block encryption operation, and at the same time embed the reverse-obtained "device serial number salting logic" to ensure that the operation logic of the software reproduction is consistent with the hardware.

[0041] 3. Interface compatibility encapsulation: The reproduction code is encapsulated strictly according to the function signature of the original hardware SDK. The reproduced interface must completely retain the original function signature. If the original SDK depends on hardware handles, the handle management mechanism is simulated in the software through a hash table to ensure that the test system can reproduce the interface "without being aware of it" and without modifying its own code.

[0042] 4. Compatibility Testing and Iterative Optimization: Verify the correctness of the reproduced interface using test datasets generated by a real hardware encryption machine; if the reproduced results are inconsistent with the hardware calculation results, reverse debugging and correction of the algorithm logic are required; usually, multiple iterative optimizations and manual verification of each test case are required to ensure that the consistency between the reproduced results and the hardware calculation results meets the testing requirements.

[0043] This solution is primarily applied to scenarios in the securities and futures industry that are "hardware cost-sensitive and have high testing frequency," such as testing the encryption functions of trading systems in small and medium-sized securities firms, conducting national cryptographic compliance testing for securities and futures related software service providers, and verifying core business modules of regional securities firms. In terms of cost and efficiency, a single solution requires dedicated development costs, mainly covering reverse engineering, professional development, and related human resource costs. Solution development requires a complete technical development cycle, involving core aspects such as encryption logic parsing and simulation function implementation. Furthermore, if the encryption machine model is changed during testing, reverse engineering of the encryption logic and function reproduction must be carried out again for the new model, requiring a dedicated adaptation period. In the long term, as the number of compatible hardware models increases, the maintenance cost of the solution will rise accordingly, and the maintenance complexity will gradually increase.

[0044] In summary, both the real-hardware deployment solution and the full-scale algorithm reproduction solution have numerous technical shortcomings, making it difficult to meet industry testing needs: the real-hardware deployment solution suffers from strong hardware coupling, resulting in high hardware procurement and maintenance costs, and competition for equipment resources among multiple teams; the full-scale algorithm reproduction solution relies on reverse engineering, leading to long development cycles and high costs for adapting to new hardware. Furthermore, both solutions are limited by the closed nature of the primary system, making it impossible to complete end-to-end full-process testing independently of the real primary system.

[0045] To address the aforementioned technical issues, this application provides a simulation testing method for electronic devices. This method receives interface call requests from a test system, processes the interface call requests using a simulation system within the electronic device, generates simulation results, and sends the simulation results back to the test system. The interface call request is used to request the execution of a target service system's target business logic, and the business processing logic of the simulation system is consistent with that of the target service system.

[0046] The simulation testing method described in this application replaces the business processing logic of the target service system with a simulation system, severing the physical dependency between the testing system and the target service system. The testing team does not need to purchase and deploy the hardware equipment for the target service system, nor does it need to replicate the hardware configuration of the production environment, significantly reducing hardware procurement, data center deployment, and long-term operation and maintenance costs. Simultaneously, the simulation system supports parallel access testing by multiple teams, eliminating the problem of physical equipment resource contention and significantly improving test resource utilization and parallel testing efficiency. Furthermore, the business processing logic of the simulation system is completely consistent with that of the target service system. Therefore, the simulation system can reuse the business processing logic of the target service system without relying on reverse engineering, thereby effectively reducing development cycle and adaptation costs.

[0047] Furthermore, in the simulation testing method provided in this application, the testing system does not need to be connected to the target service system. The test can be completed through interaction with the simulation system. In this way, the testing limitations caused by the closed nature of the target service system (such as a primary system) in related technologies can be effectively avoided, and the whole process testing can be achieved without the target service system.

[0048] The following is combined Figures 1-6 The simulation testing method provided in the embodiments of this application will be described in detail.

[0049] Figure 1 This is a flowchart illustrating a simulation testing method provided in an embodiment of this application, applied to electronic devices. (Refer to...) Figure 1 As shown, the method includes the following steps S101-S103.

[0050] S101 receives interface call requests sent by the test system.

[0051] An API call request is used to request the target service system to execute the target business.

[0052] The target service system can be a service system deployed in hardware encryption devices (such as hardware encryption machines, HSM modules, PCI-E encryption cards), or it can be a primary system (such as the exchange core system, clearing and settlement primary system).

[0053] A testing system refers to a testing system in the securities and futures industry that relies on hardware encryption equipment to complete core business operations. Specifically, it can include hardware encryption-dependent information systems such as exchange order placement clients, clearing and settlement systems, market data publishing systems, trading matching systems, and third-party access gateways.

[0054] When testing is required, testers can send interface call requests to electronic devices through the testing system without modifying the code.

[0055] For example, taking the test requirement as verifying the transaction instruction signature function, and the target service system as a service system deployed in a hardware encryption device, the test system can send a request to the electronic device to call the SM2_Sign interface. This request can include parameters such as plaintext transaction instructions and key indexes, which are used to request the target service system deployed in the hardware encryption device to perform SM2 signature calculation.

[0056] S102, the simulation system in the electronic device is used to process the interface call request and generate simulation results.

[0057] The business processing logic of the simulation system is consistent with that of the target service system.

[0058] Specifically, an electronic device can be equipped with a simulation system, which is developed according to the business processing logic of the target service system. After receiving an interface call request from the test system, the electronic device can send an interface call request to the simulation system. The simulation system can then process the interface call request and obtain the simulation results.

[0059] In one example, the test system and the simulation system can be deployed on the same device.

[0060] S103 sends the simulation results to the test system.

[0061] After receiving the simulation results from the simulation system's processing of the interface call request, the electronic device can send the simulation results to the test system.

[0062] The simulation testing method described in this application replaces the business processing logic of the target service system with a simulation system, severing the physical dependency between the testing system and the target service system. The testing team does not need to purchase and deploy the hardware equipment for the target service system, nor does it need to replicate the hardware configuration of the production environment, significantly reducing hardware procurement, data center deployment, and long-term operation and maintenance costs. Simultaneously, the simulation system supports parallel access testing by multiple teams, eliminating the problem of physical equipment resource contention and significantly improving test resource utilization and parallel testing efficiency. Furthermore, the business processing logic of the simulation system is completely consistent with that of the target service system. Therefore, the simulation system can reuse the business processing logic of the target service system without relying on reverse engineering, thereby effectively reducing development cycle and adaptation costs.

[0063] Furthermore, in the simulation testing method provided in this application, the testing system does not need to be connected to the target service system. The test can be completed through interaction with the simulation system. In this way, the testing limitations caused by the closed nature of the target service system (such as a primary system) in related technologies can be effectively avoided, and the whole process testing can be achieved without the target service system.

[0064] In one optional implementation, before processing the interface call request using the simulation system in the electronic device, the processing mode of the interface call request can be determined, and this processing mode includes simulation mode and real mode. Based on this, the processing of the interface call request using the simulation system in the electronic device can be specifically implemented as follows: when the processing mode of the interface call request is simulation mode, the simulation system processes the interface call request; when the processing mode of the interface call request is real mode, the target service system is invoked to process the interface call request.

[0065] Specifically, the electronic device can be configured with an Application Programming Interface (API) mapping rule configuration file, which can include the correspondence between interface identifiers and processing modes. Correspondingly, the interface call request can contain the interface identifier of the interface to be called. After receiving the interface call request, the electronic device can parse it to obtain the interface identifier of the interface to be called. Based on the interface identifier of the interface to be called and its own stored API mapping rule configuration file, the electronic device can determine the processing mode corresponding to the interface to be called. If the processing mode corresponding to the interface to be called is simulation mode, the electronic device can send the interface call request to the simulation system. If the processing mode corresponding to the interface to be called is real mode, the electronic device can send the interface call request to the target service system through a function pointer.

[0066] In order not to affect the testing efficiency, in one example, the electronic device determines the processing mode corresponding to the interface to be called, and the time for sending the interface call request to the simulation system or the target service system is less than the preset time. The preset time can be 10ms, 15ms, longer or shorter.

[0067] In one example, the API mapping rule configuration file can be a JSON-formatted API mapping rule configuration file.

[0068] In one example, the electronic device may include a dynamic API hijacking module (also known as an interception layer). This module determines the processing mode of an API call request and, if the processing mode is emulation mode, processes the request using a simulation system. If the processing mode is real mode, it invokes the target service system to process the request.

[0069] In one example, the electronic device may include a visual configuration center. Accordingly, before determining the processing mode for an interface call request, the user (developer) can configure the corresponding processing mode for different interfaces in an API mapping rule configuration file through this visual configuration center. For example, configuring the SM4_Encrypt interface as emulation mode and the SM2_Verify interface as real mode. Correspondingly, the API mapping rule configuration file may store the mapping between the interface identifier of the SM4_Encrypt interface and the emulation mode, and the mapping between the interface identifier of the SM2_Verify interface and the real mode.

[0070] In one optional implementation, the aforementioned interface call request may include a first type of request and a second type of request. The first type of request is used to request the execution of encryption-related and / or signature-related services, while the second type of request is used to request the execution of interactive services of the target service system. Correspondingly, the aforementioned processing of the interface call request using a simulation system in the electronic device to generate simulation results may specifically include: when the interface call request includes the first type of request, processing the interface call request using an encryption module (also referred to as a software simulation module or replacement layer) in the simulation system to generate a first simulation result; the encryption module integrates multiple encryption algorithms and / or signature algorithms. When the interface call request includes the second type of request, processing the interface call request using an interactive module (also referred to as a first-level system sluice or simulation layer) in the simulation system to generate a second simulation result.

[0071] The first type of request can also be called hardware encryption-related instructions, including but not limited to instructions such as encryption (e.g., SM4 data encryption, AES block encryption), signature (e.g., SM2 elliptic curve signature, RSA digital signature), key verification (e.g., signature verification, key validity verification), and key management (e.g., key generation, key update, key destruction).

[0072] The second type of request can also be called system interaction instructions, including but not limited to instructions such as reporting encrypted instructions (e.g., encrypting a trading instruction and reporting it to the exchange system), receiving processing results (e.g., receiving an encrypted instruction processing receipt returned by the primary system), and querying connection status (e.g., querying whether the communication link with the primary system is normal).

[0073] The encryption algorithms integrated in the encryption module may include, but are not limited to, multiple national cryptographic algorithms (such as SM2, SM3, SM4, GMSSL) or international algorithms (such as RSA, AES, SHA, OpenSSL).

[0074] A Level 1 system slug program is a customized simulation program developed for the communication protocols and interaction logic of a Level 1 system (such as an exchange's core system). The core functions of a Level 1 system slug program may include, but are not limited to, protocol parsing, interaction simulation, and version adaptation, in order to accurately reproduce the business processing behavior of the Level 1 system.

[0075] In terms of interactive simulation, the Level 1 system slug program can reproduce the core business logic of the Level 1 system. The specific process can include "receiving encryption instructions, verifying signature validity, checking data format, and returning processing results," while also supporting the simulation of both normal and abnormal responses from the Level 1 system. For example, upon receiving an interactive instruction, the Level 1 system slug program can call the signature verification interface of the software simulation module to verify the validity of the signature contained in the data body. If the signature verification passes, the Level 1 system slug program can further check whether the data format of the interactive instruction conforms to the Level 1 system specifications (such as whether the field length and encoding format are correct). If the format conforms to the specifications, the Level 1 system slug program can return a normal response result. If the signature verification fails, the Level 1 system slug program can return an invalid signature exception response; if the format does not conform to the specifications, the Level 1 system slug program can return a format error exception response.

[0076] The second type of request mentioned above will be sent to the primary system blocker in the form of a message. This message may include a 16-byte header field, a 4-byte length field, a checksum (such as a CRC32 checksum), and a data body field consisting of encryption instructions and a signature value. To enable the primary system blocker to parse the message, it can support multiple transport protocols, such as TCP or UDP, to facilitate message parsing.

[0077] Considering the continuous updates and iterations of transmission protocol versions, to ensure the Level 1 system interface program can flexibly adapt to different protocol versions, users can directly add or edit configuration information for the corresponding protocol version through the visual configuration center of the electronic device, without modifying the core program code. For example, when the TCP transmission protocol of the Level 1 system is upgraded from V1.0 to V2.0, users only need to add adaptation parameters such as the offset of the packet header field corresponding to the V2.0 version, the added response code definition, and the data body field extension rules to the configuration file. The Level 1 system interface program will automatically load the new configuration and parse the packets and process the interaction according to the corresponding rules, without modifying the core packet parsing logic and business processing code, thus quickly achieving compatibility and adaptation with the new version protocol.

[0078] As described above, the electronic device can be configured with an API mapping rule configuration file, which can also include the correspondence between interface identifiers and request types. Accordingly, after receiving an interface call request, the electronic device can parse the request to obtain the interface identifier of the interface to be called. Based on the interface identifier and its stored API mapping rule configuration file, the electronic device can determine the request type corresponding to the interface to be called. If the request type is a first-type request, the electronic device can use the software simulation module in the simulation system to process the first-type request and obtain a first simulation result. If the request type is a second-type request, the electronic device can use the first-level system blocker program in the simulation system to process the first-type request and obtain a second simulation result.

[0079] In one example, when the electronic device includes a dynamic API hijacking module, the dynamic API hijacking module is also used to determine the request type corresponding to the interface to be called. If the request type corresponding to the interface to be called includes a first type of request, the module sends an interface call request to the software simulation module. If the request type corresponding to the interface to be called includes a second type of request, the module sends an interface call request to the first-level system baffle program.

[0080] In one example, the electronic device may include a visual configuration center through which users (developers) can configure the corresponding request types for different interfaces in the API mapping rule configuration file.

[0081] In one optional implementation, the encryption module may also integrate encryption output formats corresponding to different manufacturers. Accordingly, after generating the first simulation result, the electronic device may also determine the encryption output format of the target manufacturer corresponding to the test system, adjust the format of the first simulation result using the encryption output format of the target manufacturer, and generate a first simulation result that matches the encryption output format of the target manufacturer.

[0082] The encrypted output format can include, but is not limited to, various parameters such as padding methods (e.g., PKCS#7, ZeroPadding), output encoding formats (e.g., hex, base64), signature encoding formats (e.g., ASN.1, raw), and hash algorithms (e.g., SM3, SHA256).

[0083] Specifically, the encryption module of an electronic device can be configured with a hardware adaptation configuration file, which can store encryption output formats from different manufacturers. After processing the interface call request and outputting the first simulation result, the encryption module of the electronic device can obtain the encryption output format of the target manufacturer corresponding to the test system. Then, according to the encryption output format of the target manufacturer, the first simulation result output by the encryption module is converted to obtain a first simulation result that matches the encryption output format of the target manufacturer.

[0084] In one example, the hardware adapter configuration file can be a JSON format configuration file.

[0085] In one example, the target vendor for the aforementioned test system can be pre-configured by the user (tester). Specifically, the user (tester) can select the target vendor for the test system through the visual configuration center of the electronic device. Correspondingly, the electronic device can determine the target vendor based on the user's configuration, obtain the target vendor's encrypted output format, and convert the first simulation result output by the encryption module according to the target vendor's encrypted output format to obtain a first simulation result matching the target vendor's encrypted output format.

[0086] In one optional implementation, the encryption module in the simulation system processes the interface call request to generate a first simulation result. Specifically, this can be achieved by: obtaining a preset rule configuration file for abnormal scenarios, which may contain abnormal triggering conditions and corresponding abnormal results. If the interface call request meets the abnormal triggering conditions, the abnormal result corresponding to the abnormal triggering conditions is returned; if the interface call request does not meet the abnormal triggering conditions, the encryption module processes the interface call request to generate the first simulation result.

[0087] In one example, the default rule configuration file for abnormal scenarios can be a JSON-formatted rule configuration file.

[0088] In one example, the pre-defined rule configuration file for abnormal scenarios can be integrated with the aforementioned hardware adaptation configuration file.

[0089] Abnormal scenarios may include, but are not limited to, key errors (insufficient length / permissions), hardware timeouts, and device offline scenarios.

[0090] The abnormal triggering conditions may include, but are not limited to, at least one of the following: parameter triggering conditions (such as plaintext length greater than the preset length threshold, key index error, etc.) or probability triggering conditions (such as 20% probability of triggering encryption timeout, etc.). The abnormal results may include, but are not limited to, error codes, error messages, and response delays. For example, the abnormal rules that can be set in the rule configuration file for abnormal scenarios for the SM4_Encrypt interface include: (1) When the plaintext length is greater than 1024 bytes (preset length threshold), trigger the plaintext length greater than the preset length threshold abnormality and return error code 102. (2) Trigger the encryption timeout abnormality according to a random probability of 0.2, return error code 107, and the response delay is 500 milliseconds (ms). Accordingly, when the encryption module processes the interface call request of the SM4_Encrypt interface, it can check whether the plaintext length is greater than 1024 bytes. If the plaintext length is greater than 1024 bytes, it will directly return error code 102. If the plaintext length is less than 1024 bytes, it will determine whether to trigger the encryption timeout abnormality. If the encryption timeout abnormality is triggered, it will return error code 107 after a delay of 500ms. If the plaintext length is less than 1024 bytes and no encryption timeout exception is triggered, the encryption operation will be executed normally to generate the first simulation result.

[0091] In the above technical solution, the function of the hardware encryption machine is implemented based on standard algorithms, and lightweight software logic equivalent to the function of the hardware encryption machine is achieved without relying on reverse engineering.

[0092] In one alternative implementation, the validity of the simulation test environment of the electronic device can be verified before receiving the interface call request sent by the test system.

[0093] Verifying the legitimacy of the simulation testing environment for electronic devices can prevent unauthorized environments from calling the simulation interface, ensuring the security and compliance of the testing process.

[0094] In one example, the identification information of the electronic device can be obtained, and if the identification information of the electronic device matches the preset identification information, the simulation test environment of the electronic device is determined to have passed the legality verification.

[0095] The identification information of an electronic device may include at least one of the following: system variables of the electronic device, MAC address, or occupancy status of a dedicated test port.

[0096] System variables are preset environment variables in the operating system of an electronic device, used to identify the legitimacy of the test environment. For example, in Linux systems, they are set via `export TEST_ENV=1`, while in Windows systems, they are configured through the registry or system properties. A MAC address is the physical address of the network interface of an electronic device; it is unique and used to distinguish different test devices. A dedicated test port is a network port specified by the user for simulation testing only, such as TCP 8081 or UDP 5001. The occupancy status of a dedicated test port refers to whether this port is being used by other programs. In one example, the user (tester) can predefine a dedicated test port (e.g., select TCP8081 as the dedicated test port) through the visual configuration center of the electronic device. Then, the electronic device can determine the occupancy status of the user-defined dedicated test port, that is, determine whether the dedicated test port is occupied by other programs.

[0097] Specifically, if the electronic device's system variables are set to preset values, its local MAC address is included in a preset list of authorized MAC addresses, and the occupancy status of the dedicated test port indicates that the dedicated test port is not occupied by other programs, then the electronic device's simulation test environment can be deemed to have passed the legality check.

[0098] For example, taking the system variable TEST_ENV with a default value of 1, the dedicated test port as TCP port 8081, and the default list of authorized MAC addresses including "00:1B:44:11:3A:B7" and "00:1B:44:11:3A:B8" as an example, the electronic device can obtain the value of TEST_ENV through the getenv function, obtain the local MAC address through a network interface query tool, and obtain the occupancy status of TCP port 8081 through a port detection tool. When "TEST_ENV=1", the local MAC address is "00:1B:44:11:3A:B7" or "00:1B:44:11:3A:B8", and the occupancy status of TCP port 8081 indicates that TCP port 8081 is not occupied by other programs, the simulation test environment of the electronic device passes the legality verification.

[0099] In one example, the default values ​​of system variables and the MAC addresses included in the default list of authorized MAC addresses may be configured and stored in advance by the user (such as a developer) in the electronic device's visual configuration center.

[0100] In one example, the electronic device may include a configuration and security interaction module (also known as a control layer), which is used to verify the legitimacy of the simulation test environment of the electronic device.

[0101] In one example, the system can also support retrieving historical test messages, facilitating troubleshooting in case of failures during testing.

[0102] In one example, the test system and the simulation system may be connected before the simulation test method provided in the embodiments of this application is executed.

[0103] In one example, the system can also enable an automatic reconnection function, which automatically re-establishes the connection between the test system and the simulation system after a disconnection. Afterward, the test system and the simulation system can transmit any unfinished commands or data sent before the disconnection, preventing interruptions during the test.

[0104] In one example, users (developers) can also customize the corresponding business operation interface in the visual configuration center of the electronic device according to the specific test scenario. Taking the testing of a securities and futures order placement system as an example, users (developers) can deploy a transaction strategy configuration module and an order information query module in the visual configuration center of the electronic device. This allows users (testers) to set the upper and lower limits of prices, the maximum number of trades, and the rules triggered when prices hit the daily limit up or down through the transaction strategy configuration module. Users (testers) can also query order information in the order information query module by order number, transaction time, or stock code, and check whether the order was successful or failed, the value of the encrypted signature, and whether the primary system has responded, to match the business testing needs of the securities and futures industry.

[0105] The following description, in conjunction with the above embodiments, takes an electronic device including a dynamic API hijacking module, a software simulation module, a first-level system blocker program, and a configuration and security interaction module as an example. Figure 2 This is a structural framework diagram of a simulation testing method provided in an embodiment of this application. (Refer to...) Figure 2 As shown, the test system sends interface call requests to the dynamic API hijacking module according to test requirements. The dynamic API hijacking module can read the API mapping rule configuration file from the configuration and security interaction module to determine the processing mode of the interface to be called.

[0106] When the processing mode corresponding to the interface to be called is simulation mode, the dynamic API hijacking module can determine the request type of the interface to be called. When the request type corresponding to the interface to be called is a hardware encryption-related instruction, the dynamic API hijacking module can send an interface call request to the software simulation module. The software simulation module can generate a first simulation result based on its configured encryption algorithms and / or signature algorithms. The software simulation module can also determine the encryption output format of the target vendor corresponding to the test system, adjust the format of the first simulation result according to the target vendor's encryption output format, and generate a first simulation result that matches the target vendor's encryption output format. When the request type corresponding to the interface to be called is a system interaction instruction, the dynamic API hijacking module can send an interface call request to the first-level system blocker program. The first-level system blocker program can reuse the first simulation result output by the software simulation module to complete the legality verification and generate a second simulation result. Afterwards, the electronic device can send the first simulation result output by the software simulation module and the second simulation result output by the first-level system blocker program to the test system to support subsequent business logic judgment.

[0107] When the processing mode corresponding to the interface to be called is real mode, the dynamic API hijacking module can send an interface call request to the target service system through a function pointer. The target service system can then process the interface call request and obtain the actual response.

[0108] In one example, during the simulation system testing phase, to ensure the accuracy of the simulation system's output, for the same interface call request, both the simulation system (which generates the simulation result) and the target service system (which generates the actual response) can be invoked. The simulation results and the actual response results can be stored in logs so that users (developers or testers) can verify the accuracy of the simulation results based on the actual response.

[0109] The following describes how developers can implement a dynamic API hijacking module to switch between the simulation system and the target service system. Specifically, this may include... Figure 3 The process involves three steps: interface list organization and mapping rule configuration, proxy module development, and proxy module priority loading configuration.

[0110] Interface list review and mapping rule configuration: Developers can first review the key information of the interfaces that the test system depends on (such as the encryption or signature interface of the hardware encryption machine SDK, the interaction interface of the first-level system, etc.), including but not limited to function name, parameter type, parameter order, return value, calling convention (such as cdecl or stdcall), etc.

[0111] After reviewing the key information of the interfaces that the test system depends on, developers can write API mapping rule configuration files to configure the corresponding processing mode (simulation mode or real mode) and the corresponding request type (such as hardware encryption related instructions or system interaction instructions) for each interface.

[0112] In one example, if the API mapping rules configuration file is in JSON format, the pseudocode in the API mapping rules configuration file may include: { "hardware_apis":[ { "api_name":"SM4_Encrypt", "param_types":["unsignedchar*","unsignedchar*","int"], "return_type":"int", "mode":"simulate", "target_module":"software_simulation" }, { "api_name":"SM2_Sign", "param_types":["unsignedchar*","unsignedchar*","int"], "return_type":"int", "mode":"simulate", "target_module":"software_simulation" } ], "primary_system_apis":[ { "api_name":"Report_EncryptedData", "param_types":["unsignedchar*","int"], "return_type":"int", "mode":"simulate", "target_module":"primary_system_stub" } ] } Proxy module development: Developers can develop proxy modules with the same name as the dynamic link libraries of the target service system that the test system runs on (such as Linux or Windows) to achieve seamless interception and traffic redirection of the API calls.

[0113] In one example, if the test system runs on a Linux operating system and the dynamic link library corresponding to the target service system it depends on is an SO file (such as libcrypto.so), then the developers need to develop a proxy module with the same name as the SO file (i.e., the proxy module name is also libcrypto.so). If the test system runs on a Windows operating system and the dynamic link library corresponding to the target service system it depends on is a DLL file (such as CryptoSDK.dll), then the developers need to develop a proxy module with the same name as the DLL file (i.e., the proxy module name is also CryptoSDK.dll).

[0114] Developers can define function signatures in the proxy module that are completely identical to the interface to be called, ensuring that when the test system calls the interface, it cannot distinguish between the dynamic link library corresponding to the target service system and the proxy module. For example, taking the interface to be called as the hardware encryption interception interface SM4_Encrypt, developers can write the following pseudocode example in the proxy module: / / Completely consistent with the function signature of the original hardware SDK extern"C"intSM4_Encrypt(unsignedchar*plaintext,unsignedchar*ciphertext,intlen){ / / Read API mapping rules std::stringmode=getApiMode("SM4_Encrypt"); if(mode=="simulate"){ / / Forwarded to software simulation module returnsoftware_simulation::sm4_encrypt(plaintext,ciphertext,len); }else{ / / Load the original SDK and call the real hardware typedefint(*SM4_Encrypt_Func)(unsignedchar*,unsignedchar*,int); SM4_Encrypt_Funcreal_func=(SM4_Encrypt_Func)dlsym(RTLD_NEXT,"SM4_Encrypt"); returnreal_func(plaintext,ciphertext,len); } } Proxy module priority loading configuration: To ensure that when the test system calls the interface to be called, the interception logic of the proxy module is triggered first, rather than directly calling the dynamic link library corresponding to the target service system, developers need to configure the loading priority for different systems. The following explanation uses Linux and Windows systems as examples.

[0115] On Linux systems: The path to the proxy SO file can be specified by setting the LD_PRELOAD environment variable. For example, execute the command: `export LD_PRELOAD= / test directory / proxy module / libcrypto.so:$LD_PRELOAD`. This environment variable will force the Linux system to load the proxy module first.

[0116] For Windows systems: There are two methods. The first is to add the proxy module's path through the "AppInit_DLLs" registry key (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Windows). The second is to place the proxy module directly in the same directory as the executable program on the test system, leveraging Windows' proximity-based loading rule to ensure that the Windows system loads the proxy module first.

[0117] With the above configuration, the test system code does not need to be modified throughout the process, and the dynamic API hijacking module can be flexibly switched between the simulation system and the target service system.

[0118] The core objective of the software simulation module is to reproduce the encryption / signature logic of the hardware encryption machine in pure software, while being compatible with the format differences of hardware from different manufacturers, simulating various abnormal scenarios, and ensuring the consistency of simulation results with those of the real hardware. The following describes how developers can implement the software simulation module to replace the encryption operation logic of the hardware encryption machine. The core is to achieve software-based replication of the hardware encryption logic based on an algorithm library, specifically including the following three steps: integration of standard algorithm libraries and encapsulation of basic functions, configuration of hardware adaptation parameters and definition of abnormal rules, and result consistency verification mechanism.

[0119] Standard Algorithm Library Integration and Basic Function Encapsulation: Developers need to integrate the GMSSL 2.0 and OpenSSL 3.0 algorithm libraries. GMSSL 2.0 supports Chinese cryptographic algorithms such as SM2 / SM3 / SM4, while OpenSSL 3.0 supports international algorithms such as RSA / ECC / AES. Developers can also encapsulate basic encryption / signature interfaces based on the GMSSL 2.0 and OpenSSL 3.0 algorithm libraries, ensuring consistency with the original hardware's SDK interface logic and allowing dynamic API hijacking modules to call them.

[0120] In one example, using SM4 encryption encapsulation, developers can write the following pseudocode in the software simulation module: namespace software_simulation{ intsm4_encrypt(unsignedchar*plaintext,unsignedchar*ciphertext,intlen){ / / Read parameters such as padding method and key from the configuration file std::stringpadding=getConfig("SM4_Encrypt.padding"); / / such as "PKCS#7" unsignedchar* key = getDynamicKey("SM4_KEY"); / / Dynamically generate the key, not hard-coded. / / Initialize SM4 context GMSSL_SM4_CTXctx; gmssl_sm4_setkey(&ctx,key,GMSSL_SM4_ENCRYPT); / / Perform encryption according to the configured filling method if(padding=="PKCS#7"){ returngmssl_sm4_cbc_encrypt(plaintext,ciphertext,len,&ctx,iv,GMSSL_SM4_PKCS7_PADDING); }else{ returngmssl_sm4_cbc_encrypt(plaintext,ciphertext,len,&ctx,iv,GMSSL_SM4_NO_PADDING); } } } In the above encapsulation logic, the interface parameters and return value types are completely consistent with the original hardware SDK's SM4 encrypted interface, ensuring that the dynamic API hijacking module can directly forward interface call requests.

[0121] Hardware adaptation parameter configuration and exception rule definition: Developers need to write hardware adaptation configuration files to define the format difference parameters of hardware encryption machines from different manufacturers, and configure the trigger rules for various exception scenarios so that the software simulation results match the output characteristics of the target hardware and can simulate abnormal situations in hardware operation.

[0122] In one example, when the hardware adapter configuration file is in JSON format, the pseudocode for the hardware adapter configuration file can be found in the following pseudocode: { "vendor_adapt":{ "vendor_A":{ "SM4_Encrypt":{"padding":"PKCS#7","output_encoding":"hex"}, "SM2_Sign":{"encoding":"ASN.1","hash_alg":"SM3"} }, "vendor_B":{ "SM4_Encrypt":{"padding":"ZeroPadding","output_encoding":"base64"}, "SM2_Sign":{"encoding":"raw","hash_alg":"SM3"} } }, "abnormal_rules":{ "SM4_Encrypt":[ {"trigger":"len>1024","error_code":-102,"msg":"plaintext length exceeded"}, {"trigger":"random(0.2)","error_code":-107,"msg":"encryption timeout","delay_ms":500} ], "SM2_Sign":[ {"trigger":"key_index==99","error_code":-203,"msg":"Insufficient key permissions"} ] } } When the software simulation module starts, it automatically loads the hardware adaptation configuration file mentioned above. Before performing encryption or signature operations, it first checks whether the input parameters match the abnormal triggering conditions. If they match, it directly returns the configured error code and error message (and adds a corresponding delay if simulation timeout is required). If they do not match, it performs normal encryption or signature operations according to the manufacturer parameters configured in "vendor_adapt" to ensure that the output format is consistent with the target manufacturer's hardware.

[0123] Consistency Verification Mechanism: To ensure consistency between the output of the software simulation module and the computation results of the real hardware encryption machine, developers can pre-define a KAT vector library. This library can include multiple sets of plaintext-key-ciphertext or signature value correspondences, covering different algorithms, key lengths, and input data scenarios. After each encryption / signature operation, the software simulation module compares the simulation result with the standard result in the KAT vector library. If the deviation rate is >2%, the software simulation module can trigger a configuration alarm and generate algorithm logic optimization suggestions (such as adjusting the padding method or encoding format). If the deviation rate is ≤2%, the software simulation module determines the simulation result is valid. This mechanism ensures a high degree of consistency between the computation results of the software simulation module and the real hardware encryption machine.

[0124] The core objective of a Level 1 system smother program is to simulate the communication protocols and business interaction logic of a Level 1 system (such as an exchange order book system) using pure software, thereby replacing the real Level 1 system to complete end-to-end interaction with the test system. The following describes how developers can implement a Level 1 system smother program to simulate the communication interaction logic of a Level 1 system, specifically including two steps: Level 1 system protocol parsing and modeling, and implementation of the interaction logic state machine.

[0125] Level 1 System Protocol Parsing and Modeling: Developers need to parse and model the communication protocol details of the Level 1 system based on the publicly available system interface documents and data specifications, and then encapsulate the protocol parsing capability through code to ensure that the Level 1 system baffle program can accurately parse the interactive commands sent by the test system.

[0126] The communication protocol details of the parsed Level 1 system may include, but are not limited to, transport layer information, message structure, and response rules. Transport layer information may include the communication protocol (e.g., TCP), the default port (e.g., port 8080), and the maximum message length (e.g., 4096 bytes). The message structure may include a 16-byte header (containing fields such as version number, instruction type, and total message length), a data body (32-byte transaction identifier, variable-length encrypted data, and a 64-byte SM2 signature), and a 4-byte CRC checksum. Response rules may include response duration and response codes. For example, after receiving an interface call instruction from the test system, a response message must be returned within 100ms (response duration), and the response code may include 0x00 (successful processing), 0x01 (message format error), 0x05 (signature verification timeout), etc.

[0127] Developers can use C++ to write a protocol parser class (ProtocolParser) that encapsulates the entire process of message parsing, field extraction, and checksum verification. This protocol parser class can receive raw messages sent by the test system, automatically split the message header, data body, and checksum, extract core fields such as transaction ID, encrypted data, and SM2 signature, and verify the validity of the CRC32 checksum to ensure that the parsing results are consistent with the parsing logic of the real Tier 1 system.

[0128] Interactive logic state machine: Developers can use the state machine model to write code to reproduce the core interactive flow of the first-level system, ensuring that the interactive behavior of the first-level system's baffle program is completely aligned with the real first-level system. The core states can include the following: link establishment state, instruction reception state, signature verification state, and result return state.

[0129] Connection establishment status: The first-level system blocker program listens on a preset TCP port (e.g., port 8080). When it receives a TCP connection request from the test system, it verifies whether the requesting source IP belongs to the preset test network segment. If the requesting source IP is within the preset test network segment, a TCP connection is established.

[0130] Command Reception Status: After the connection is established, the first-level system blocker program receives the interface call request message sent by the test system, calls the ProtocolParser class to complete the message parsing, and extracts the transaction ID, encrypted data and SM2 signature from the data body.

[0131] Signature verification status: The first-level system baffle program calls the signature verification interface of the software simulation module to verify the legality of the signature.

[0132] Result return status: The first-level system baffle program generates the corresponding response message (including core fields such as response code and transaction ID) based on the signature verification result.

[0133] The core objective of the configuration and security verification module is to provide the entire simulation system with visual and easy-to-use configuration capabilities, while verifying the legitimacy of the test environment and preventing unauthorized environments from calling simulation functions. The following describes how developers can implement the configuration and security verification module. The core is to meet the flexible configuration needs of the test system through a visual configuration center, while ensuring the compliance and security of the test environment through multi-dimensional environment security verification. Specifically, this includes two steps: the development of the visual configuration center and multi-dimensional environment security verification.

[0134] Visual configuration center development: Developers can use Java to develop a visual configuration center. All configuration changes take effect in real time without restarting the simulation system. This includes API mapping configuration and protocol configuration.

[0135] API Mapping Configuration: Testers can directly download the corresponding decoupled and encrypted dependency API packages from the visual configuration center based on the hardware dependency type of the test system. Testers can select the API package to download in the visual configuration center and bind it to the original hardware dependency API that needs to be replaced in the test system. Testers can choose the processing mode of the API (simulation mode or real mode) and specify the corresponding request type. The configuration and security verification module can automatically generate API mapping rule configuration files, eliminating the need for manual modification of the configuration file content.

[0136] Protocol Configuration: The visual configuration center provides a first-level system dropdown selection function to configure business response strategies.

[0137] Multi-dimensional environment security verification: To prevent unauthorized environments from accessing the simulation system, developers can implement environment identifier collection, authorization verification logic, and unauthorized environment handling mechanisms in the configuration and security verification module, as detailed below: Environment identification data collection: When the simulation system starts, the configuration and security verification module automatically collects system variables, MAC addresses, and the occupancy status of the test dedicated port to provide basic data for subsequent authorization verification.

[0138] Authorization verification logic: Developers write authorization verification functions to perform compliance checks on the collected environment identifiers. A pseudocode example is shown below: plaintext bool isAuthorizedEnv() { / / Verify whether the system variable is a test environment identifier if (getenv("TEST_ENV") == nullptr || strcmp(getenv("TEST_ENV"), "1") != 0) { return false; } / / Check if the host MAC address is in the authorized list std::string mac = getLocalMac(); if (std::find(authorized_macs.begin(), authorized_macs.end(),mac) == authorized_macs.end()) { return false; } / / Verify that the dedicated test port is in use (to confirm that the test environment is running normally). if (!isPortOccupied(TEST_PORT)) { return false; } return true; } Handling of Illegal Environments: If the authorization verification result indicates an illegal environment, the configuration and security verification module can switch the processing mode of the interface to be called to real mode, ensuring that only real target service systems can be called in illegal environments, thus preventing the abuse of simulation functions. Simultaneously, the configuration and security verification module can record detailed alarm logs, including identification information of the illegal environment (such as abnormal system variable values, unauthorized MAC addresses, port status) and the call time, facilitating subsequent tracing and auditing.

[0139] The following description, in conjunction with the above embodiments, will use the interaction between the test system, the dynamic API hijacking module, the software simulation module, the first-level system shield program, and the configuration and security interaction module as examples to illustrate the simulation testing method provided in this application. Figure 4 This is a schematic diagram of the interactive process of a simulation testing method provided in an embodiment of this application, referring to... Figure 4 As shown, the method includes the following steps S401-S418.

[0140] S401, the test system sends an interface call request to the dynamic API hijacking module.

[0141] S402, the dynamic API hijacking module sends an API mapping rule configuration file read request to the configuration and security interaction module.

[0142] S403, The configuration and security interaction module sends the API mapping rule configuration file to the dynamic API hijacking module.

[0143] S404, The dynamic API hijacking module determines the processing mode and request type corresponding to the interface to be called in the interface call request.

[0144] The above S402-S404 can also be implemented as follows: The dynamic API hijacking module sends the interface identifier of the interface to be called to the configuration and security interaction module. The configuration and security interaction module stores API mapping rule configuration files. Based on the interface identifier of the interface to be called, the configuration and security interaction module can determine the processing mode and request type corresponding to the interface to be called from the API mapping rule configuration file and return it to the dynamic API hijacking module.

[0145] S405, when the dynamic API hijacking module is in simulation mode and the request type is a hardware encryption-related instruction, it sends an encryption request to the software simulation module.

[0146] The encrypted request can contain plaintext and parameters.

[0147] S406, the software simulation module sends a hardware adaptation configuration file read request to the configuration and security interaction module.

[0148] S407, the configuration and security interaction module sends the hardware adaptation configuration file to the software simulation module.

[0149] S408, the software simulation module determines the encrypted output format of the target manufacturer corresponding to the test system from the hardware adaptation configuration file.

[0150] The above S406-S408 can also be implemented as follows: the software simulation module sends the target vendor's vendor identifier to the configuration and security interaction module, which stores a hardware adaptation configuration file. Based on the target vendor's vendor identifier, the configuration and security interaction module can determine the target vendor's encrypted output format from the hardware adaptation configuration file and return it to the software simulation module.

[0151] S409, the software simulation module encrypts the plaintext and parameters based on the target manufacturer's encrypted output format, and obtains the first simulation result that matches the target manufacturer's encrypted output format.

[0152] S410, the software simulation module sends the first simulation result to the dynamic API hijacking module.

[0153] S411, the dynamic API hijacking module sends the first logging request to the configuration and security interaction module.

[0154] The first log request may include plaintext, parameters, and the first simulation result.

[0155] S412, the configuration and security interaction module records plaintext, parameters, and the first simulation result.

[0156] S413, the dynamic API hijacking module sends an interaction request to the first-level system baffle program.

[0157] The interactive request contains the first simulation results.

[0158] S414, the first-level system baffle program calls the signature verification interface of the software simulation module to verify the legality of the first simulation result and obtain the verification result.

[0159] S415, the Level 1 system baffle program sends the verification result to the dynamic API hijacking module.

[0160] S416, the dynamic API hijacking module sends a second logging request to the configuration and security interaction module.

[0161] S417, the configuration and security interaction module records the verification results.

[0162] S418, the dynamic API hijacking module sends the verification results and the first simulation results to the test system.

[0163] The simulation testing apparatus provided in the embodiments of this application is described below. The simulation testing apparatus described below can be referred to in correspondence with the simulation testing method described above.

[0164] Figure 5 This example illustrates a schematic diagram of a simulation testing device located within an electronic device. The simulation testing device includes: The receiving module 501 is used to receive the interface call request sent by the test system. The interface call request is used to request the target service system to execute the target business.

[0165] The processing module 502 is used to process the interface call request using the simulation system in the electronic device and generate simulation results. The business processing logic of the simulation system is consistent with the business processing logic of the target service system.

[0166] The sending module 503 is used to send simulation results to the test system.

[0167] Figure 6 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 6 As shown, the electronic device may include: a processor 610, a communication interface 620, a memory 630, and a communication bus 640, wherein the processor 610, the communication interface 620, and the memory 630 communicate with each other via the communication bus 640. The processor 610 can call a computer program stored in the memory 630 to execute the steps of a simulation test method, such as including: The system receives an interface call request from the test system. This request instructs the target service system to execute the target business logic. A simulation system within the electronic device processes the interface call request and generates simulation results. The business logic of the simulation system is consistent with that of the target service system. The simulation results are then sent back to the test system.

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

[0169] On the other hand, this application also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can perform the steps of the simulation testing methods provided in the above embodiments, such as including: The system receives an interface call request from the test system. This request instructs the target service system to execute the target business logic. A simulation system within the electronic device processes the interface call request and generates simulation results. The business logic of the simulation system is consistent with that of the target service system. The simulation results are then sent back to the test system.

[0170] On the other hand, embodiments of this application also provide a processor-readable storage medium storing a computer program for causing a processor to execute the steps of the simulation testing methods provided in the above embodiments, such as including: The system receives an interface call request from the test system. This request instructs the target service system to execute the target business logic. A simulation system within the electronic device processes the interface call request and generates simulation results. The business logic of the simulation system is consistent with that of the target service system. The simulation results are then sent back to the test system.

[0171] The processor-readable storage medium can be any available medium or data storage device that the processor can access, including but not limited to magnetic memory (e.g., floppy disk, hard disk, magnetic tape, magneto-optical disk (MO)), optical memory (e.g., CD, DVD, BD, HVD), and semiconductor memory (e.g., ROM, EPROM, EEPROM, non-volatile memory (NAND FLASH), solid-state drive (SSD)).

[0172] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0173] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0174] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application 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 of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A simulation testing method, characterized in that, Applied to electronic devices, the method includes: Receive an interface call request sent by the test system, the interface call request being used to request the target service system to execute the target business; The simulation system in the electronic device is used to process the interface call request and generate simulation results. The business processing logic of the simulation system is consistent with the business processing logic of the target service system. The simulation results are sent to the test system.

2. The simulation testing method according to claim 1, characterized in that, Before the simulation system in the electronic device processes the interface call request, the method further includes: Determine the processing mode of the interface call request, which includes simulation mode and real mode; The step of using the simulation system in the electronic device to process the interface call request includes: When the processing mode of the interface call request is simulation mode, the simulation system is used to process the interface call request; When the processing mode of the interface call request is real mode, the target service system is invoked to process the interface call request.

3. The simulation testing method according to claim 1 or 2, characterized in that, The interface call request includes a first type of request and a second type of request. The first type of request is used to request the execution of encryption-related business and / or signature-related business, and the second type of request is used to request the execution of interactive business of the target service system. The process of using a simulation system in an electronic device to process interface call requests and generate simulation results includes: When the interface call request includes a first type of request, the encryption module in the simulation system is used to process the interface call request and generate a first simulation result. The encryption module integrates multiple encryption algorithms and / or signature algorithms. If the interface call request includes a second type of request, the interaction module in the simulation system is used to process the interface call request and generate a second simulation result.

4. The simulation testing method according to claim 3, characterized in that, The encryption module also integrates encryption output formats corresponding to different manufacturers. After generating the first simulation result, the method further includes: Determine the encryption output format of the target vendor corresponding to the test system; The format of the first simulation result is adjusted using the encrypted output format of the target manufacturer to generate the first simulation result that matches the encrypted output format of the target manufacturer.

5. The simulation testing method according to claim 3, characterized in that, The step of using the encryption module in the simulation system to process the interface call request and generate a first simulation result includes: Obtain a preset rule configuration file for abnormal scenarios. The rule configuration file contains abnormal triggering conditions and abnormal results corresponding to the abnormal triggering conditions. If the interface call request meets the exception triggering condition, return the exception result corresponding to the exception triggering condition; If the interface call request does not meet the abnormal triggering condition, the encryption module is used to process the interface call request and generate the first simulation result.

6. The simulation testing method according to claim 1, characterized in that, Before receiving the interface call request sent by the test system, the method further includes: The legality of the simulation test environment for the electronic device is verified.

7. The simulation testing method according to claim 6, characterized in that, The legality verification of the simulation test environment for the electronic device includes: Obtain the identification information of the electronic device; If the identification information of the electronic device matches the preset identification information, the simulation test environment of the electronic device is determined to have passed the legality verification.

8. A simulation testing device, characterized in that, The simulation testing device is located in the electronic device, and the simulation testing device includes: The receiving module is used to receive interface call requests sent by the test system, wherein the interface call requests are used to request the target service system to execute the target business; The processing module is used to process the interface call request using the simulation system in the electronic device and generate simulation results. The business processing logic of the simulation system is consistent with the business processing logic of the target service system. The sending module is used to send the simulation results to the test system.

9. An electronic device comprising a processor and a memory storing a computer program, characterized in that, When the processor executes the computer program, it implements the simulation test method according to any one of claims 1 to 7.

10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the simulation test method as described in any one of claims 1 to 7.

Images