A data inspection method based on a built-in virtual machine, a storage medium and a terminal

Abstract

The application discloses a data inspection method based on a built-in virtual machine, a storage medium and a terminal, acquires a target SDK in a client; establishes a built-in virtual machine, copies and generates the target SDK and an associated data structure in the built-in virtual machine, and fills the running memory of the data structure in the built-in virtual machine; in response to input data, respectively processes the input data by using the target SDK in the memory of the client and the running memory of the built-in virtual machine, and outputs a client result and a virtual machine result; compares the client result and the virtual machine result, and if they are inconsistent, it is considered that the target SDK of the client is abnormal. Since the SDK in the virtual machine runs in an independent execution environment and is not affected by potential interference factors in the memory of the client, when the inconsistency occurs, the execution process of the target SDK in the client environment can be effectively reflected to be abnormal, the detection of abnormal behaviors is realized without depending on external checking rules, and the data inspection accuracy is improved.

Description

Technical Field

[0001] This invention relates to the field of data verification technology, and in particular to a data verification method, storage medium, and terminal based on a built-in virtual machine. Background Technology

[0002] In existing software systems, SDKs (Software Development Kits) are typically integrated into client applications as functional modules to implement specific data processing, business logic, or system interaction functions. These SDKs often rely on the client's execution environment during runtime and complete corresponding operations by importing system functions or other module functions. Their execution results are directly affected by the client's memory state, runtime environment, and external call behavior.

[0003] In practical applications, SDKs are widely used in game operation, business verification, data processing, and other fields. The usage environment is complex and easily affected by abnormal input, operational interference, or malicious tampering. Current technologies for verifying SDK runtime status mostly rely on external verification rules, log analysis, or judgment based on a single execution result. These methods typically analyze client-side execution results, making it difficult to provide reliable comparison data during runtime.

[0004] Furthermore, in the client execution environment, the SDK's runtime memory is usually shared with other modules. If the client memory space is abnormally modified, injected, or interfered with, the SDK's execution process and processing results may deviate. Existing technologies have difficulty distinguishing in a timely manner whether such anomalies are caused by changes in input data or by abnormalities in the execution environment, thus affecting the accuracy of judging the SDK's running status. Summary of the Invention

[0005] The technical problem to be solved by the present invention is to provide a data verification method, storage medium and terminal based on a built-in virtual machine, which can effectively reflect the abnormality in the execution process of the target SDK in the client environment.

[0006] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: A data verification method based on a built-in virtual machine, characterized by the following steps: S1. Obtain the target SDK from the client; S2. Establish a built-in virtual machine, copy and generate the target SDK and its associated data structure in the built-in virtual machine, and fill the running memory of the data structure in the built-in virtual machine; S3. In response to the input data, the target SDK is used to process the input data in the memory of the client and the running memory of the built-in virtual machine, respectively, and the client result and the virtual machine result are output. S4. Compare the client results and the virtual machine results. If they are inconsistent, the target SDK of the client is considered to be abnormal.

[0007] To solve the above-mentioned technical problems, the present invention adopts other technical solutions as follows: A storage medium storing a computer program that, when executed by a processor, implements steps in a data verification method based on a built-in virtual machine.

[0008] A data verification terminal based on a built-in virtual machine includes a memory, a processor, and a computer program stored in the memory and running on the processor. When the processor executes the computer program, it implements the steps of a data verification method based on a built-in virtual machine.

[0009] The beneficial effects of this invention are as follows: It provides a data verification method, storage medium, and terminal based on a built-in virtual machine. By establishing a built-in virtual machine outside the client execution environment, and processing the same input data using the same target SDK in both the client memory and the virtual machine's runtime memory, the processing results are compared. This verifies the target SDK's running status from the perspective of execution result consistency. Since the SDK in the virtual machine runs in an independent execution environment, it is unaffected by potential interference factors in the client memory. Therefore, when inconsistencies occur between the client results and the virtual machine results, it can effectively reflect an anomaly in the target SDK's execution process in the client environment. This allows for the detection of abnormal behavior without relying on external verification rules, improving the reliability and accuracy of data verification. Attached Figure Description

[0010] Figure 1 This is a flowchart of a data verification method based on a built-in virtual machine according to an embodiment of the present invention; Figure 2 This is a schematic diagram of a data verification terminal based on a built-in virtual machine according to an embodiment of the present invention; Label Explanation: 1. A data verification terminal based on a built-in virtual machine; 2. Memory; 3. Processor. Detailed Implementation

[0011] To explain in detail the technical content, objectives, and effects of the present invention, the following description is provided in conjunction with the embodiments and accompanying drawings.

[0012] Before detailing the embodiments of this application, some related concepts will first be explained: An SDK (Software Development Kit) is a collection of software components used to provide predetermined functions to client applications. An SDK typically contains interface functions that can be called by external programs and relies on system functions or other module functions to complete corresponding data processing or functional operations during execution.

[0013] An import address table is a data structure used to record information about external functions that a program needs to call during execution.

[0014] The Export Address Table is a data structure used to record information about functions that a program provides to other programs and that can be called by them.

[0015] In existing software systems, SDKs (Software Development Kits) are typically integrated into client applications as functional modules to implement functions such as data processing, business logic, or system interaction. During runtime, SDKs rely on the client's execution environment and complete corresponding operations by calling system functions or other module functions. Their execution results are easily affected by the client's memory state and runtime environment.

[0016] In practical applications, SDKs are widely used in games, business validation, and data processing. Client-side operating environments are complex and may be subject to abnormal input, operational interference, or malicious tampering. Current technologies for verifying SDK operational status primarily rely on log analysis, rule validation, or judgment based on single execution results. These methods typically depend solely on client-side execution results for analysis, lacking reliable comparative evidence.

[0017] To at least solve the above problems, please refer to Figure 1 This invention provides a data verification method based on a built-in virtual machine, comprising the following steps: S1. Obtain the target SDK from the client; S2. Establish a built-in virtual machine, copy and generate the target SDK and its associated data structure in the built-in virtual machine, and fill the running memory of the data structure in the built-in virtual machine; S3. In response to the input data, the target SDK is used to process the input data in the memory of the client and the running memory of the built-in virtual machine, respectively, and the client result and the virtual machine result are output. S4. Compare the client results and the virtual machine results. If they are inconsistent, the target SDK of the client is considered to be abnormal.

[0018] As described above, the beneficial effects of this invention are as follows: By establishing a built-in virtual machine outside the client execution environment, and processing the same input data using the same target SDK in both the client memory and the virtual machine's runtime memory, and then comparing the processing results, the running status of the target SDK can be verified from the perspective of execution result consistency. Since the SDK copy in the virtual machine runs in an independent execution environment and is not affected by potential interference factors in the client memory, when the client results and virtual machine results are inconsistent, it can effectively reflect an anomaly in the execution process of the target SDK in the client environment. This allows for the detection of abnormal behavior without relying on external verification rules, improving the reliability and accuracy of data verification.

[0019] In some implementations, the associated data structure includes the data structure associated with the import address table and export address table of the target SDK.

[0020] As described above, by using the data structures associated with the target SDK's import and export address tables as the basis for copying and generating the SDK and its runtime memory within the built-in virtual machine, the SDK execution environment in the virtual machine remains consistent with the client execution environment at the function call relationship level. This method avoids the biases that may be introduced by artificially constructing a virtual execution environment, ensuring that the SDK in the virtual machine can accurately reflect the original calling logic of the target SDK. This guarantees the comparability between client results and virtual machine results, providing a stable basis for subsequent data verification.

[0021] In some implementations, step S2 specifically includes: S21. Based on the associated path of the target SDK, obtain the import address table and export address table of the target SDK; S22. Establish a built-in virtual machine, copy and generate the target SDK in the built-in virtual machine, and fill the running memory in the built-in virtual machine according to the data structure associated with the import address table and the export address table.

[0022] As described above, by obtaining the import address table and export address table of the target SDK based on its associated path during the process of building the built-in virtual machine, and filling the corresponding data structure runtime memory in the virtual machine accordingly, the execution environment in the built-in virtual machine can cover all function call relationships involved in the actual execution of the target SDK, avoiding the distortion of virtual machine execution results due to the lack of associated data structures, thereby improving the effectiveness and stability of data verification results.

[0023] In some embodiments, step S21 specifically includes: Based on the associated path of the target SDK, obtain the import address table and export address table of the target SDK; Based on the import address table, the function items associated with the target SDK during execution are determined by traversing the table. Based on the exported address table, determine the function items provided by the target SDK. The data structure is generated based on the function entries in the import address table and the export address table.

[0024] As described above, by traversing the target SDK's import address table to determine its associated function entries during execution, and combining this with the function entries provided in the export address table to construct a data structure, the runtime memory layout in the built-in virtual machine directly reflects the target SDK's actual function dependencies. This method accurately reflects the target SDK's actual execution path, effectively avoiding inconsistencies caused by simply copying code while ignoring function dependencies, thus enhancing the reliability of the virtual machine results as a benchmark.

[0025] In some embodiments, step S2 further includes: The runtime environment for the data structure is established within the built-in virtual machine.

[0026] As described above, by establishing a corresponding runtime environment for the data structure within the built-in virtual machine, the copied target SDK and its associated data structure can run in a complete execution state within the virtual machine, rather than merely existing as static data. The establishment of this runtime environment ensures the continuity and controllability of the SDK execution process within the virtual machine, providing the necessary runtime conditions for subsequent input data processing and result comparison, thereby avoiding misjudgments in data verification due to an incomplete runtime environment.

[0027] In some implementations, in step S3, the client's memory and the built-in virtual machine's runtime memory are independent of each other.

[0028] As described above, by explicitly separating client memory from the built-in virtual machine's runtime memory, the execution state of the target SDK in the client environment is isolated from its execution state in the virtual machine at the memory level. This memory isolation mechanism effectively prevents abnormal modifications, injection behaviors, or runtime interference in client memory from affecting the SDK's execution results in the virtual machine, thereby ensuring the independence and reference value of the virtual machine's results and improving the accuracy of anomaly detection.

[0029] In some implementations, step S3 specifically includes: S31. Obtain the input data; S32. In the memory of the client, the target SDK is called to process the input data to obtain the client result; S33. Copy the input data to the runtime memory of the built-in virtual machine; S34. The target SDK is called in the running memory of the built-in virtual machine to process the input data to obtain the virtual machine result.

[0030] As described above, by processing the input data separately in the client and the built-in virtual machine, and copying the input data to the virtual machine's running memory before processing, the client and the virtual machine execute based on the same source input data. This method ensures the consistency of the client's results and the virtual machine's results in terms of input conditions, avoids misjudgment caused by differences in input data, and thus enables the result comparison to truly reflect the impact of differences in the execution environment on the SDK's running results, improving the objectivity of data verification.

[0031] In some implementations, step S4 specifically includes: If the client result and the virtual machine result are inconsistent, it is considered that the target SDK of the client has an error, and subsequent processing procedures are executed based on the virtual machine result.

[0032] As described above, by identifying the target SDK as an anomaly when a discrepancy is detected between the client's result and the virtual machine's result, and continuing subsequent processing based on the virtual machine's result, the system can maintain the continuity of business processes by relying on the reliable execution results in the virtual machine even when an anomaly occurs. This mechanism not only achieves anomaly detection but also further realizes result takeover and fault tolerance handling in abnormal situations, reducing the impact of anomalies on the overall system operation and improving the system's stability and availability.

[0033] A storage medium storing a computer program that, when executed by a processor, implements steps in a data verification method based on a built-in virtual machine.

[0034] Please refer to Figure 2 A data verification terminal 1 based on a built-in virtual machine includes a memory 2, a processor 3, and a computer program stored on the memory 2 and running on the processor 3. When the processor 3 executes the computer program, it implements the steps of a data verification method based on a built-in virtual machine.

[0035] Please refer to Figure 1 Embodiment 1 of the present invention is as follows: This embodiment takes the target SDK running in the client as the object of verification and provides a data verification method based on the built-in virtual machine to verify the running status of the target SDK during the execution process on the client.

[0036] In this embodiment, the client can be any application that needs to call the target SDK, which can exist as a dynamic link library or other loadable and executable module. The built-in virtual machine is an independent execution environment established outside the client execution environment, used to run a copy of the target SDK.

[0037] First, step S1 is executed to obtain the target SDK in the client. Specifically, during client execution, the target SDK that needs to be validated is determined, and the module identifier and associated path related to the target SDK are obtained as the basis for subsequently building the virtual machine execution environment.

[0038] Next, step S2 is executed to create a built-in virtual machine. During the creation of the built-in virtual machine, the target SDK and its associated data structures are copied and generated within the virtual machine, and the runtime memory of the data structures is filled into the virtual machine.

[0039] In this embodiment, the associated data structure includes the data structures associated with the import address table and export address table of the target SDK. Specifically, based on the associated path of the target SDK, the import address table and export address table of the target SDK are obtained; based on the import address table, the function items associated with the target SDK during execution are determined by traversal; based on the export address table, the function items provided externally by the target SDK are determined; and the data structure is constructed and generated based on the function items in the import address table and export address table. On this basis, a corresponding runtime environment is established for the data structure in the built-in virtual machine, so that the copied target SDK and its associated data structure can run in a complete execution state within the virtual machine.

[0040] Subsequently, step S3 is executed, in response to the input data, the input data is processed using the target SDK in the client memory and the runtime memory of the built-in virtual machine respectively, and the client result and the virtual machine result are output.

[0041] In this embodiment, the client's memory and the built-in virtual machine's runtime memory are independent of each other. Specifically, during execution, input data is first acquired; then, the target SDK is called in the client's memory to process the input data and obtain the client's result; next, the input data is copied to the built-in virtual machine's runtime memory; finally, a copy of the target SDK is called in the built-in virtual machine's runtime memory to process the input data and obtain the virtual machine's result.

[0042] In this way, the client results and the virtual machine results are generated based on the same source input data, thus ensuring the consistency of the two in terms of input conditions.

[0043] Finally, step S4 is executed to compare the client results and the virtual machine results. If the client results and virtual machine results are inconsistent, it is considered that the target SDK in the client has encountered an anomaly. In this embodiment, after detecting an anomaly, the system executes subsequent processing based on the virtual machine results, ensuring that subsequent processing does not depend on the execution results that may have encountered an anomaly in the client.

[0044] Through the above steps, this embodiment constructs a built-in virtual machine execution environment outside the client execution environment, enabling the target SDK to run in an independent and controllable environment. By comparing the client execution results with the virtual machine execution results, the execution status of the target SDK can be effectively verified. When the client execution environment is subjected to abnormal interference, the execution results in the virtual machine can still be relied upon to ensure the continuity of the processing flow, thereby improving the reliability of data verification and the overall stability of the system operation.

[0045] Embodiment 2 of the present invention is as follows: A storage medium storing a computer program that, when executed by a processor, implements steps in a data verification method based on a built-in virtual machine.

[0046] Please refer to Figure 2 Embodiment 3 of the present invention is as follows: A data verification terminal 1 based on a built-in virtual machine includes a memory 2, a processor 3, and a computer program stored on the memory 2 and running on the processor 3. When the processor 3 executes the computer program, it implements the steps of a data verification method based on a built-in virtual machine.

[0047] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A data verification method based on a built-in virtual machine, characterized in that, Including the following steps: S1. Obtain the target SDK from the client; S2. Establish a built-in virtual machine, copy and generate the target SDK and its associated data structure in the built-in virtual machine, and fill the running memory of the data structure in the built-in virtual machine; S3. In response to the input data, the target SDK is used to process the input data in the memory of the client and the running memory of the built-in virtual machine, respectively, and the client result and the virtual machine result are output. S4. Compare the client results and the virtual machine results. If they are inconsistent, the target SDK of the client is considered to be abnormal.

2. The data verification method based on a built-in virtual machine according to claim 1, characterized in that, The associated data structures include the data structures associated with the import address table and export address table of the target SDK.

3. The data verification method based on a built-in virtual machine according to claim 2, characterized in that, Step S2 specifically includes: S21. Based on the associated path of the target SDK, obtain the import address table and export address table of the target SDK; S22. Establish a built-in virtual machine, copy and generate the target SDK in the built-in virtual machine, and fill the running memory in the built-in virtual machine according to the data structure associated with the import address table and the export address table.

4. The data verification method based on a built-in virtual machine according to claim 3, characterized in that, Step S21 specifically includes: Based on the associated path of the target SDK, obtain the import address table and export address table of the target SDK; Based on the import address table, the function items associated with the target SDK during execution are determined by traversing the table. Based on the exported address table, determine the function items provided by the target SDK. The data structure is generated based on the function entries in the import address table and the export address table.

5. The data verification method based on a built-in virtual machine according to claim 1, characterized in that, Step S2 further includes: The runtime environment for the data structure is established within the built-in virtual machine.

6. The data verification method based on a built-in virtual machine according to claim 1, characterized in that, In step S3, the client's memory and the built-in virtual machine's runtime memory are independent of each other.

7. The data verification method based on a built-in virtual machine according to claim 1, characterized in that, Step S3 specifically includes: S31. Obtain the input data; S32. In the memory of the client, the target SDK is called to process the input data to obtain the client result; S33. Copy the input data to the runtime memory of the built-in virtual machine; S34. The target SDK is called in the running memory of the built-in virtual machine to process the input data to obtain the virtual machine result.

8. The data verification method based on a built-in virtual machine according to claim 1, characterized in that, Step S4 specifically includes: If the client result and the virtual machine result are inconsistent, it is considered that the target SDK of the client has an error, and subsequent processing procedures are executed based on the virtual machine result.

9. A storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the steps of the data verification method based on a built-in virtual machine as described in any one of claims 1-8.

10. A data verification terminal based on a built-in virtual machine, comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the data verification method based on a built-in virtual machine as described in any one of claims 1-8.

Images