Data detection method, apparatus, device, medium, and product

Abstract

The application discloses a data detection method, device, equipment, medium and product, relates to the technical field of software system modeling and analysis, and comprises the following steps: acquiring dynamic tracking data of an application program, and modeling to obtain a final data model according to the dynamic tracking data; and performing data detection on the final data model by using a model analysis tool to obtain a data detection report. Therefore, the final Petri net model is obtained by modeling according to the acquired dynamic tracking data of a Rust program, then the data detection report is obtained by performing data detection on the final Petri net model by using a Petri net analysis tool, the problem that the existing vulnerability detector cannot perform dynamic detection on the Rust program is solved, and the accuracy of data detection is improved.

Description

Technical Field

[0001] This application relates to the field of software system modeling and analysis technology, and in particular to a data detection method, device, equipment, medium and product. Background Technology

[0002] Rust is a programming language developed by Mozilla Inc., designed to build efficient and secure low-level software. Its main idea is to inherit most of the functionality of C and C++, thereby retaining the good runtime performance of C and C++, while at the same time eliminating the security issues of C and C++ through strict compilation checks. Therefore, more and more developers are using Rust to compile programs.

[0003] Existing technologies for vulnerability detection in Rust programs typically employ static detectors like Rust-clippy to detect memory bugs that follow certain simple source code patterns. However, Rust-clippy only covers a limited number of bug patterns. Additionally, some researchers have used the dynamic memory bug detector Miri, which interprets and executes Rust's Mid-level Intermediate Representation (MIR). However, in practice, Miri generates many false positives. This demonstrates that while program analysis-based detectors offer advantages such as fast analysis speed, they have a narrow scope of bug coverage and are prone to false positives. Furthermore, Rust's aliasing model has been used to build a dynamic memory bug detector, which can effectively report potential unpredictable behaviors and memory bugs caused by incorrectly nested references, and boasts high accuracy. However, this dynamic detector relies on user-provided input to trigger memory bugs, making timely vulnerability detection impossible.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main purpose of this application is to provide a data detection method, apparatus, device, medium, and product, which aims to solve the technical problem that existing vulnerability detectors cannot perform dynamic detection of Rust programs.

[0006] To achieve the above objectives, this application proposes a data detection method, the method comprising:

[0007] Acquire dynamic tracking data from the application and perform modeling based on the dynamic tracking data to obtain the final data model;

[0008] The final data model is tested using model analysis tools to obtain a data testing report.

[0009] In one embodiment, the step of acquiring dynamic tracking data of the application and modeling based on the dynamic tracking data to obtain a final data model includes:

[0010] Detect the application's program status;

[0011] When the program is in the running state, the application is dynamically tracked using a tracing tool to obtain dynamic tracing data;

[0012] Map the dynamic tracking data to an initial data model;

[0013] The initial data model is structurally optimized to obtain the final data model.

[0014] In one embodiment, the step of dynamically tracking the application using a tracking tool to obtain dynamic tracking data includes:

[0015] The tracing tool is used to track the running status of the application to obtain the first shared memory read / write operation of the thread in the application, the thread ID, the memory address, and the operation timestamp.

[0016] The initial dynamic tracking data is obtained by filtering the first shared memory read / write operations, thread IDs, memory addresses, and operation timestamps.

[0017] Based on preset data mapping requirements, the initial dynamic tracking data is filtered to obtain dynamic tracking data.

[0018] In one embodiment, the step of mapping the dynamic tracking data to an initial data model includes:

[0019] Extract the second shared memory read / write operations from the dynamic tracking data;

[0020] A memory access graph is constructed based on the second shared memory read / write operation;

[0021] The memory access graph is semantically equivalence-based by an optimization algorithm to obtain an optimized memory access graph.

[0022] The optimized memory access graph is mapped to the initial data model according to the data modeling rules.

[0023] In one embodiment, the step of structurally optimizing the initial data model to obtain the final data model includes:

[0024] The initial data model was simulated, and invalid paths in the model were obtained.

[0025] Analyze the aggregation locations in the initial data model to obtain the model repetition path;

[0026] Invalid paths in the initial data model are deleted, duplicate paths in the initial data model are aggregated, and concurrency semantics are introduced to obtain the final data model.

[0027] In one embodiment, the step of performing data testing on the final data model using a model analysis tool to obtain a data testing report includes:

[0028] The data accessibility analysis results are obtained by performing an accessibility analysis on the final data model using the model analysis tool.

[0029] The model analysis tool is used to perform transition conflict detection on the final data model to obtain the data transition conflict detection results.

[0030] The final data model is subjected to labeling and flow analysis using the model analysis tool to obtain the data labeling and flow analysis results.

[0031] A data detection report is generated based on the accessibility analysis results, data transition conflict detection results, and data tagging flow analysis results.

[0032] Furthermore, to achieve the above objectives, this application also proposes a data detection device, which includes:

[0033] The modeling module is used to acquire dynamic tracking data of the application and to perform modeling based on the dynamic tracking data to obtain the final data model;

[0034] The detection module is used to perform data detection on the final data model using model analysis tools and obtain a data detection report.

[0035] In addition, to achieve the above objectives, this application also proposes a data detection device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the data detection method as described above.

[0036] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and which, when executed by a processor, implements the steps of the data detection method described above.

[0037] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the data detection method described above.

[0038] One or more technical solutions proposed in this application have at least the following technical effects:

[0039] This application proposes a data detection method, apparatus, device, medium, and product. It acquires dynamic tracking data of an application and models the data to obtain a final data model. A model analysis tool is then used to perform data detection on the final data model to obtain a data detection report. Thus, by modeling the final Petri net model based on the acquired dynamic tracking data of a Rust program, and subsequently performing data detection on the final Petri net model using a Petri net analysis tool to obtain a data detection report, this method solves the problem that existing vulnerability detectors cannot perform dynamic detection on Rust programs, thereby improving the accuracy of data detection. Attached Figure Description

[0040] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0041] To more clearly illustrate the technical solutions in the embodiments of 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, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0042] Figure 1 This is a flowchart illustrating the data detection method of this application in Embodiment 1.

[0043] Figure 2 This is a flowchart illustrating Embodiment 2 of the data detection method of this application;

[0044] Figure 3 A simplified flowchart illustrating the data detection method provided in Embodiment 2 of this application;

[0045] Figure 4 This is a schematic diagram of the module structure of the data detection device according to an embodiment of this application;

[0046] Figure 5 This is a schematic diagram of the device structure of the hardware operating environment involved in the data detection method in the embodiments of this application.

[0047] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0048] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0049] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0050] The main solution of this application embodiment is as follows: Detect the program state of the application; when the program state is running, dynamically track the application using a tracing tool to obtain dynamic tracing data; map the dynamic tracing data to an initial data model; optimize the structure of the initial data model to obtain a final data model. The tracing tool tracks the running state of the application to obtain the first shared memory read / write operation, thread ID, memory address, and operation timestamp of the thread in the application; filters the first shared memory read / write operation, thread ID, memory address, and operation timestamp to obtain initial dynamic tracing data; based on preset data mapping requirements, filters the initial dynamic tracing data to obtain dynamic tracing data. Extract the second shared memory read / write operation from the dynamic tracing data; construct a memory access graph based on the second shared memory read / write operation; perform semantic equivalence pruning on the memory access graph using an optimization algorithm to obtain an optimized memory access graph; map the optimized memory access graph to the initial data model according to data modeling rules. The initial data model is simulated to obtain invalid paths. Aggregation locations in the initial data model are analyzed to obtain duplicate paths. Invalid paths are deleted, duplicate paths are aggregated, and concurrency semantics are introduced to obtain the final data model. Reachability analysis is performed on the final data model using the model analysis tool to obtain data reachability analysis results. Transition conflict detection is performed on the final data model using the model analysis tool to obtain data transition conflict detection results. Tag transition analysis is performed on the final data model using the model analysis tool to obtain data tag transition analysis results. A data detection report is generated based on the reachability analysis results, data transition conflict detection results, and data tag transition analysis results. This solves the problem that existing vulnerability detectors cannot dynamically detect Rust programs, enabling data detection and improving data detection efficiency. Based on the present invention, addressing the limitations of existing Rust vulnerability detection tools, none of which can detect concurrent bugs, resulting in low efficiency, a data detection method was designed. The effectiveness of the data detection method of the present invention was verified during data detection, and the efficiency of data detection using the method of the present invention was significantly improved.

[0051] In this embodiment, for ease of description, the data detection device will be used as the execution subject in the following description.

[0052] Existing technologies use static detectors like Rust-clippy to detect memory bugs that follow certain simple source code patterns. However, Rust-clippy can only cover a limited number of bug patterns. Additionally, some researchers have used the dynamic memory bug detector Miri, which can interpret and execute Rust's Mid-level Intermediate Representation (MIR). However, in practice, Miri still generates many false positives. This demonstrates that while program analysis-based detectors have advantages such as fast analysis speed, they have a narrow scope of bug coverage and are prone to false positives. Furthermore, Rust's aliasing model has built a dynamic memory bug detector that can effectively report potential unpredictable behavior and memory bugs when references are not properly nested, and it also has advantages such as high accuracy. However, this dynamic detector relies on user-provided input to trigger memory bugs, making timely vulnerability detection impossible.

[0053] This application provides a solution that collects dynamic tracking data from Rust programs, models the obtained data into a Petri net model, and finally uses a Petri net analysis tool to perform data testing on the model and obtain a data testing report. This achieves accurate and fast data testing, providing users with better services.

[0054] As can be seen from the above embodiments, this application obtains the dynamic tracking data of the application and models it to obtain a final data model; then, it uses a model analysis tool to perform data detection on the final data model to obtain a data detection report. Thus, by modeling the final Petri net model based on the obtained dynamic tracking data of the Rust program, and subsequently using a Petri net analysis tool to perform data detection on the final Petri net model to obtain a data detection report, this solves the problem that existing vulnerability detectors cannot perform dynamic detection on Rust programs, and improves the accuracy of data detection.

[0055] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or data detection device capable of performing the above functions. The following description uses a data detection device as an example to illustrate this embodiment and the subsequent embodiments.

[0056] Based on this, embodiments of this application provide a data detection method, referring to... Figure 1 , Figure 1This is a flowchart illustrating the first embodiment of the data detection method of this application.

[0057] In this embodiment, the data detection method includes steps S01-S02:

[0058] Step S01: Obtain the dynamic tracking data of the application, and perform modeling based on the dynamic tracking data to obtain the final data model;

[0059] It should be clear that the data detection in this embodiment is for Rust programs, which are compiled based on the Rust programming language. More specifically, Rust is a systems programming language designed to provide higher security, performance, and concurrency. Rust is primarily developed by Mozilla and has gradually been widely used in various scenarios. Its design goal is to ensure memory safety while avoiding common errors in traditional systems programming languages ​​such as C and C++, such as memory leaks, null pointer dereferences, and data races.

[0060] Existing technologies for vulnerability detection in Rust programs typically employ static detectors like Rust-clippy to detect memory bugs that follow certain simple source code patterns. However, Rust-clippy only covers a limited number of bug patterns. Additionally, some researchers have used the dynamic memory bug detector Miri, which interprets and executes Rust's Mid-level Intermediate Representation (MIR). However, in practice, Miri generates many false positives. This demonstrates that while program analysis-based detectors offer advantages such as fast analysis speed, they have a narrow scope of bug coverage and are prone to false positives. Furthermore, Rust's aliasing model has been used to build a dynamic memory bug detector, which can effectively report potential unpredictable behaviors and memory bugs caused by incorrectly nested references, and boasts high accuracy. However, this dynamic detector relies on user-provided input to trigger memory bugs, making timely vulnerability detection impossible.

[0061] Therefore, in this embodiment, dynamic tracing data of the Rust program is collected, and a Petri net model is obtained based on the collected dynamic tracing data. Here, the Rust program refers to the program generated after the Rust code is written and compiled by a compiler. It can be an executable file (such as .exe, .out, or .bin files) or a library file (such as .rlib or .so files). A Petri net is a mathematical model used to describe and analyze the behavior of concurrent, distributed, asynchronous, and stochastic systems. It is commonly used to model and analyze state transitions, resource management, and concurrency control in systems.

[0062] Step S02: Perform data testing on the final data model using a model analysis tool to obtain a data testing report.

[0063] After obtaining the Petri net model corresponding to the Rust program, data testing can be performed on the model using Petri net analysis tools to generate a data testing report for the Rust program. A Petri net is a mathematical modeling tool typically used to describe and analyze the transitions between different states in a system. Petri nets are widely used in modeling concurrent systems, distributed systems, communication protocols, and production systems, and are particularly suitable for describing systems with characteristics such as concurrency, synchronization, mutual exclusion, and resource contention. Petri net analysis tools are computer programs used to model, simulate, analyze, and verify Petri net models. These tools help users build Petri net models and can automate tasks such as state space analysis, reachability analysis, deadlock detection, and performance analysis. In this embodiment, the data testing report refers to the report generated by analyzing and testing the data structures, variables, memory usage, concurrency behavior, and error handling in the Rust code. This type of report can be used to verify the security, performance, and memory management of the Rust code, helping developers discover potential errors and performance bottlenecks.

[0064] In this embodiment, the process of capturing and analyzing dynamic tracking data is optimized, and Petri net modeling is performed using dynamic tracking data, which significantly reduces the state space and improves detection speed and accuracy. It is suitable for memory consistency detection and optimization scenarios in Rust concurrent programs.

[0065] Specifically, step S01 above, which involves acquiring the application's dynamic tracking data and modeling the data to obtain the final data model, includes:

[0066] Step S011: Detect the program status of the application;

[0067] Step S012: When the program is in the running state, the application is dynamically tracked using a tracking tool to obtain dynamic tracking data.

[0068] Step S013: Map the dynamic tracking data to an initial data model;

[0069] Step S014: Optimize the structure of the initial data model to obtain the final data model.

[0070] This embodiment is based on the Cargo toolchain, which does not require rewriting the compilation commands and can be seamlessly integrated into the Rust ecosystem. It uses the Rust tool Miri as a runtime front-end to capture the dynamic behavior of memory operations, maintaining the integrity of the original program semantics without modifying the user code. Cargo is the official build tool and package manager for the Rust programming language. It is used to manage the build process, dependency management and release of Rust projects. Cargo is one of the most important tools in the Rust ecosystem, which greatly simplifies the workflow of Rust developers.

[0071] Furthermore, this embodiment also includes data pruning and optimization when acquiring dynamic tracking data. In the dynamic trace processing stage, this embodiment performs semantic pruning on operations unrelated to data competition, significantly reducing the state space of the Petri net model. Through Petri net optimization rules and transition constraints, the size of the generated model is further reduced, improving detection speed and accuracy. In Petri nets, trace refers to the execution sequence of a series of activities or operations in the system. This embodiment uses dynamic tracking data for illustration.

[0072] The methods and tools in this embodiment are based on Miri (used to run and analyze Rust code, especially to detect potential errors and unsafe behaviors during execution. It provides a different way of execution than traditional compilers, simulating code execution and helping developers better understand program behavior, especially when dealing with low-level, unsafe code). The lock model in Miri is used to describe the behavior of mutexes in a multi-threaded environment, including lock ownership state, lock count, wait queue, and clock, and its definition is as follows:

[0073] #[derive(Default, Debug)]

[0074] struct Mutex {

[0075] / / / The thread currently holding the lock.

[0076] owner: Option <threadid>,

[0077] / / / The number of times a thread holding the lock repeatedly locks the lock.

[0078] lock_count: usize,

[0079] / / / A queue of threads waiting to acquire the lock.

[0080] queue: VecDeque <threadid>,

[0081] / / / Lock clock, records the time of the most recent unlock.

[0082] clock: VClock,

[0083] }

[0084] Here, owner refers to the thread currently holding the lock; if it is None, it means the lock is not held. lock_count refers to the lock counter, which tracks the number of times a thread re-enters the lock. queue refers to the waiting queue, which stores the IDs of all threads waiting to acquire the lock. clock refers to the lock clock, which uses a logical clock (VectorClock) to record the lock's unlocking time and supports tracking the temporal causality of concurrent operations. This model supports dynamically capturing the semantics of lock operations, including thread locking and unlocking behaviors and the management of the waiting queue.

[0085] This design provides the foundational data for dynamic modeling of Petri nets. For example, the state of a lock can be mapped to a place in a Petri net, and the locking and unlocking operations can be mapped to transitions. The thread model in Miri is used to describe the running state of threads, the call stack, inter-thread synchronization, and thread-related context information, and its definition is as follows:

[0086] pub struct Thread<'tcx>{

[0087] / / / The current state of the thread (e.g., running, blocked, etc.).

[0088] state: ThreadState<'tcx>,

[0089] / / / The name of the thread (optional).

[0090] thread_name: Option <Vec <u8>>,

[0091] / / / Virtual call stack.

[0092] stack: Vec <Frame<'tcx, Provenance, FrameExtra<'tcx> >>,

[0093] / / / Callback function after the stack is cleared, used to handle subsequent operations when the thread ends.

[0094] pub(crate) on_stack_empty: Option <StackEmptyCallback<'tcx> >,

[0095] / / / Top-level frame index of the user-related call stack for fast access.

[0096] top_user_relevant_frame: Option <usize>,

[0097] / / / The "Join" state of a thread, describing the synchronization and exit states of the thread.

[0098] join_status: ThreadJoinStatus,

[0099] / / / The stack of panic messages actively thrown by the current thread.

[0100] pub(crate) panic_payloads: Vec <ImmTy<'tcx> >,

[0101] / / / The address of the most recent operating system error (stored as a 32-bit integer).

[0102] pub(crate) last_error: Option <MPlaceTy<'tcx> >,

[0103] }

[0104] Here, `state` refers to the current thread's state, such as running, waiting, or exited; `thread_name` refers to the thread name, which is helpful for debugging; `stack` refers to the virtual call stack, containing information about function calls executed by the thread; `on_stack_empty` refers to the callback function when the stack is cleared, used to handle the logic of thread termination; `join_status` describes the thread's synchronization state (such as waiting for other threads to complete); `panic_payloads` stores panic information actively thrown by the current thread; and `last_error` refers to the address of the most recent operating system error, which is helpful for tracking down problems in abnormal situations.

[0105] This model provides fundamental support for dynamically capturing the running state and behavior of threads. Information such as thread creation, destruction, and call stack changes can be modeled using Petri nets. Thread states can be mapped to Petri net places, and function calls and return operations can be mapped to transitions. The specific operations are as follows:

[0106]

[0107]

[0108]

[0109] As can be seen from the above embodiments, after obtaining the dynamic tracking data of Rust, this embodiment maps and models it using Petri nets to obtain the final Petri net model for analysis, thus solving the problem of not being able to dynamically detect Rust programs.

[0110] More specifically, step S02 above, which involves using a model analysis tool to perform data testing on the final data model and obtain a data testing report, includes:

[0111] Step S021: Perform reachability analysis on the final data model using the model analysis tool to obtain the data reachability analysis results;

[0112] Step S022: Perform transition conflict detection on the final data model using the model analysis tool to obtain the data transition conflict detection result;

[0113] Step S023: Perform labeling and flow analysis on the final data model using the model analysis tool to obtain the data labeling and flow analysis results;

[0114] Step S024: Generate a data detection report based on the reachability analysis results, data transition conflict detection results, and data tag flow analysis results.

[0115] This embodiment utilizes Petri net analysis tools to detect data contention. Specifically, it calls Petri net analysis tools (such as PIPE) to perform mathematical analysis on the generated Petri net model. Through transition conflict detection and reachability analysis, it locates potential data contention points and generates a detailed detection report. In this embodiment, the detection report includes a description of the contention conditions, the shared memory addresses involved, the access thread ID, and the specific operation path of the potential contention.

[0116] Reachability analysis is a method for analyzing the state of a Petri net system. It is used to determine whether the system can reach a specific target state through a series of legal state transitions (i.e., the triggering of transitions) in a given initial state. Through reachability analysis, we can understand the behavior of the system under various possible operations and thus determine whether the system will enter certain specific states (such as deadlock, starvation, etc.).

[0117] Transition conflict detection is an important concept in Petri net analysis. It is mainly used to detect whether multiple transitions in a system will conflict, that is, whether transitions cannot occur at the same time. Conflict detection helps to identify possible resource competition, deadlock or inconsistent states in the system. Transition conflicts usually occur when multiple transitions try to access the same resource or modify the same state.

[0118] Marking Transit Analysis is an important method in Petri net analysis, mainly used to study and analyze how tokens (marking) flow in the grid structure of Petri nets. It helps to understand the evolution of system states, the triggering of transitions, and the stability of system behavior. Through marking transit analysis, potential states, deadlocks, reachability problems, etc., in Petri nets can be identified.

[0119] The software tool in this embodiment utilizes Petri net analysis to reveal data race bugs in Rust concurrent programs that existing static or dynamic detection tools have failed to detect, providing higher-precision dynamic detection capabilities.

[0120] This embodiment, following the above-described scheme, specifically obtains dynamic tracking data of the application and models it to obtain a final data model. A model analysis tool is then used to perform data detection on the final data model, generating a data detection report. Thus, by modeling the final Petri net model based on the obtained dynamic tracking data of the Rust program, and subsequently using a Petri net analysis tool to perform data detection on the final Petri net model to obtain a data detection report, this solves the problem that existing vulnerability detectors cannot perform dynamic detection on Rust programs, improving the accuracy of data detection.

[0121] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in Embodiment 1 above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 Step S012 involves dynamically tracking the application using a tracking tool to obtain dynamic tracking data. The data detection method further includes steps S0121-S0123:

[0122] Step S0121: Track the running status of the application using the tracing tool to obtain the first shared memory read / write operation of the thread in the application, the thread ID, the memory address, and the operation timestamp;

[0123] Step S0122: Filter the first shared memory read / write operation, thread ID, memory address, and operation timestamp to obtain initial dynamic tracking data;

[0124] Step S0123: Based on the preset data mapping requirements, the initial dynamic tracking data is filtered to obtain dynamic tracking data.

[0125] This embodiment selects Miri, Rust's runtime analysis tool, to capture the dynamic behavior of the program during runtime and generate a trace (i.e., dynamic trace data) containing multi-threaded memory access information. Miri can capture read and write operations on shared memory between threads at the interpreter level, recording thread ID, memory address, operation type, and timestamp to construct a complete memory access trajectory. This method has the advantages of high accuracy and good coverage, as shown in the following example:

[0126] thread::spawn(|| {

[0127] shared_var[0] = 42; / / Write operation

[0128] });

[0129] println!("{}", shared_var[0]); / / Read operation

[0130] A dynamic trace captured via Miri might look like this:

[0131] {"thread_id": 1, "operation": "Write", "address": "0x01", "timestamp": 1}

[0132] {"thread_id": 2, "operation": "Read", "address": "0x01", "timestamp":2}

[0133] The trace data generated by dynamic tracing may contain redundant information unrelated to data competition (such as operations on local variables). In order to improve detection efficiency, the trace needs to be pruned to retain the critical path related to shared memory access and filter out unnecessary inter-thread operations. The optimized trace is the basis for subsequent modeling.

[0134] The optimization process can involve filtering and pruning dynamic trace data, removing local variable operations and redundant paths that are irrelevant to data competition, and then retaining only the critical paths that may affect shared memory for complex multi-threaded operations, which significantly reduces the complexity of modeling and the size of the state space. The dynamic trace data supports user-specified shared memory access types to be detected, including read operations and write operations that can be detected separately, or mixed read and write operations and thread synchronization behaviors that can be detected simultaneously.

[0135] . Specifically, the above Figure 1 In the illustrated embodiment, step S013, mapping the dynamic tracking data to an initial data model, includes:

[0136] Step S0131: Extract the second shared memory read / write operation from the dynamic tracking data;

[0137] Step S0132: Construct a memory access graph based on the second shared memory read / write operation;

[0138] Step S0133: The memory access graph is semantically equivalence-based and pruned using an optimization algorithm to obtain an optimized memory access graph;

[0139] Step S0134: Map the optimized memory access graph to the initial data model according to the data modeling rules.

[0140] The optimized dynamic trace is mapped to a Petri net model, including mapping shared memory locations to Petri net "places" and reading, writing and synchronization operations to "transitions". The flow of the markers describes the state changes of memory access and the causal relationships between threads.

[0141] The transformation steps include: extracting shared memory access events from dynamic trace data, and constructing a memory access graph by category, including thread ID, memory address, and operation timestamp;

[0142] By using semantic analysis and optimized pruning algorithms, redundant paths in dynamic traces are eliminated, ensuring that all critical operations related to race conditions are preserved.

[0143] Based on Petri net modeling rules, the optimized memory access graph is mapped to a Petri net structure. These mapping rules include modeling rules for read-write conflicts, synchronization dependencies, and concurrency behavior.

[0144] Furthermore, this embodiment can specify the type of shared memory access to be detected, meaning the user can specify the type of data contention to be detected, including individual read operations, write operations, or simultaneous mixed read and write accesses. Different access patterns correspond to different Petri net modeling rules;

[0145] The memory access graph can then be generated. Based on the access type specified above, the memory access graph is constructed from the dynamic trace data. The memory access graph contains the interaction path between threads and shared memory, and describes the memory access behavior of the multithreaded program by combining the time sequence and operation type recorded in the trace.

[0146] Finally, the memory access graph can be converted into an initial Petri net model, that is, the memory access graph can be converted into a Petri net model through formal mapping rules. The mapping rules in this embodiment include the following points:

[0147] (1) Shared memory locations are mapped to "places" in Petri nets;

[0148] (2) Memory operation types (such as read, write, synchronization) are mapped to "transitions" in Petri nets;

[0149] (3) Causal relationships between threads are described using Petri nets to ensure that the semantics of the original program remain consistent;

[0150] The converted Petri net model can fully describe the memory access behavior of Rust programs and supports race detection using Petri net analysis tools;

[0151] The main structure of the mapping process in this embodiment is TraceToPetriNetTranslator, which is used to manage the conversion process from dynamic trace to Petri net model. The data structure that stores the inter-thread shared memory access information of dynamic trace includes an operation type record table, a thread ID mapping table, and a memory address mapping table. After all the Petri net nodes for memory access are generated, they are automatically connected to the "place" where the program ends to indicate that the modeling is complete.

[0152] In order to reduce the size and complexity of the generated Petri net, this embodiment generates an optimized Petri net based on the dynamic behavior of shared memory access. The modeling process follows user-defined access rules (such as read, write, and synchronization behaviors) and relies on formal mapping rules to ensure the equivalence of program behavior, thus achieving accurate modeling.

[0153] More specifically, the above Figure 1 In the illustrated embodiment, step S014, which involves structural optimization of the initial data model to obtain the final data model, includes:

[0154] Step S0141: Perform a simulation operation on the initial data model to obtain invalid paths in the model;

[0155] Step S0142: Analyze the aggregation positions in the initial data model to obtain the model repetition path;

[0156] Step S0143: Delete invalid paths in the initial data model, aggregate duplicate paths in the initial data model, and introduce concurrency semantics to obtain the final data model.

[0157] In this embodiment, the initial Petri net model is structurally optimized by removing irrelevant paths, aggregating similar states, and introducing a concurrent semantic modeling extension to capture potential race conditions in a multi-threaded environment.

[0158] Furthermore, the process of simulating the Petri net model to obtain invalid paths can be divided into several steps. The purpose of these steps is to identify those paths that cannot be triggered or completed by simulating the state changes of the Petri net, which are called "invalid paths". Invalid paths usually refer to those paths that cannot proceed normally under a given initial state, or those paths that cannot continue due to resource conflicts, deadlocks, etc. In this embodiment, the triggering of each transition is simulated and the distribution of the position labels is updated. After each transition is triggered: the label on the input position that triggered the transition is removed, and the label is added to the output position of the transition.

[0159] Assuming the simulation is executed: initially, there is one marker on P1, and no markers on P2 and P3, meaning T1 can be triggered because there is a marker on P1. After triggering, there is one marker on P2.

[0160] Then, T2 can be triggered because there is a marker on P2. After triggering, there is one marker on P3. In this simple example, there is no invalid path because all transitions can be triggered normally.

[0161] Invalid paths typically occur in the following situations:

[0162] (1) Insufficient resources: If the marker at a certain position is insufficient to trigger the corresponding transition, then the path starting from the current state becomes an invalid path. For example, if there is an additional transition T3, both P2 and P3 need to be marked to be triggered. If there is no marker on P2 (for example, T2 is not triggered), T3 cannot be triggered, thus forming an invalid path.

[0163] (2) Deadlock: If at some point all transitions cannot be triggered (e.g., there are not enough markers at all locations), the system enters a deadlock state and all paths become invalid. For example, if the markers of P1 and P2 are consumed, and P3 does not have enough markers to trigger T3, the system may be unable to continue execution.

[0164] (3) Duplicate paths: If there are multiple paths, but some of them cannot be activated, or are stuck in a dead loop or blocked due to an inappropriate label distribution, then these paths are also considered invalid paths.

[0165] Besides invalid paths, optimizing the initial Petri net model also includes aggregating similar states. In Petri nets, state aggregation is a technique used to simplify the model and analysis. It reduces the size of the state space by merging similar states into an abstract state, thus facilitating system analysis and simulation, especially when facing the state space explosion problem. First, similar states generally refer to states in a Petri net where the system behavior, label distribution, or certain attributes of interest (such as execution flow, resource consumption, etc.) are the same or very similar. Specifically, "similarity" can be defined according to the following criteria: 1. Same label distribution: If the number of labels at all positions is exactly the same in two states, then these two states can be considered similar states. 2. Same activity transitions: If starting from two different states can trigger the same transitions, and these transitions have the same logical impact on the system, then these two states can also be considered similar. 3. Same deadlock or reachability: If two states can reach the same terminating state (e.g., deadlock state or target state), these states can also be considered similar.

[0166] Aggregating similar states can be done using the following methods:

[0167] (1) State label aggregation: Aggregate the label distribution of states, that is, treat states with the same label distribution as a higher-level abstract state. This method is the most intuitive and common aggregation method. The specific steps include: finding all states with the same label distribution, merging these states into an abstract state, and operating on these abstract states instead of each specific state during the analysis process. For example, in a simple Petri net model, if all positions of two states have the same number of labels, then the two states can be aggregated into one state.

[0168] (2) Equivalence class aggregation: By defining equivalence relations, multiple states are divided into different equivalence classes according to certain attributes or conditions. Each equivalence class represents a group of similar states. In this method, the similarity of states is not based entirely on the label distribution, but on the structural characteristics of states, the triggered transitions, etc. For example, if the transition triggering conditions are the same, and the triggering order and triggering conditions are the same in different states, then these states can be considered equivalent. If the behavioral characteristics are the same, and the system starts from different states and ultimately exhibits the same behavior and process (for example, all enter the deadlock state), then these states can be aggregated.

[0169] (3) Abstract State Space: In some Petri net analysis tools, the abstract state space method is used to simplify the problem. The abstract state space usually contains states that are more simplified and abstract than the original state space. These abstract states may be created by discarding some minor details (such as the number of labels at certain locations);

[0170] (4) Merge states that do not affect the model behavior. Sometimes certain states do not affect the final behavior of the system. For example, if the number of labels at a certain location changes in certain states, but the change in that location does not have any effect on the final behavior of the system (e.g., it does not trigger new transitions or change the reachable state of the system), then these states can be merged.

[0171] Furthermore, this embodiment introduces concurrency semantics into the initial Petri net model. The purpose of this introduction is to better describe and simulate the situation where multiple events or processes can be executed independently at the same time. The introduction of concurrency semantics enables Petri nets to reflect system characteristics such as multi-tasking, resource sharing, competition, and synchronization. Petri nets themselves are a modeling tool that is naturally suitable for describing concurrent behavior. The places and transitions in its structure allow the flow of events and resources in the system to be represented, while its concurrency semantics can be reflected by multiple transitions being triggered simultaneously or competing with each other.

[0172] In Petri nets, the core semantics of concurrency are typically reflected in:

[0173] (1) Simultaneous triggering of multiple transitions, that is, multiple transitions can occur at the same time and can be triggered in the same state, thus leading to parallel execution of the system. For example, two transitions may depend on different resources (location markers), but they can be triggered at the same time, representing two independent events occurring simultaneously.

[0174] (2) Parallel execution, that is, the transitions in the Petri net model can be executed in parallel in different threads or processes, and the triggering of multiple transitions does not necessarily depend on each other and can be carried out independently;

[0175] (3) Resource sharing and competition: In concurrent systems, multiple processes or tasks may share limited resources. In Petri nets, these resources are usually represented by positions. Multiple transitions may compete for the same position label, which means resource competition.

[0176] In this embodiment, Petri nets implement concurrent semantics through the following mechanisms:

[0177] (1) Concurrent transitions: In Petri nets, multiple transitions can occur simultaneously, provided that their input positions have enough labels to support them. For example, in the same state, multiple transitions can simultaneously obtain labels from different positions and be triggered at the same time, representing parallel events or processes. For example, suppose there are two transitions T1 and T2, which depend on positions P1 and P2 respectively. If both P1 and P2 have labels, then T1 and T2 can be triggered at the same time, representing concurrent execution.

[0178] (2) Asynchronous concurrency: Petri nets allow different transitions to be triggered at different times without the need for a synchronization mechanism. This asynchronous behavior allows multiple processes to run in parallel without strict synchronization, which is suitable for parallel tasks in many practical applications, such as task scheduling in operating systems and assembly line operations in production lines.

[0179] (3) Synchronization and Concurrency: Sometimes the triggering of multiple transitions may need to be synchronized. Concurrency in Petri nets can not only be asynchronous, but can also be described by specific synchronization mechanisms. For example, transitions that connect multiple locations can be used to ensure the order or synchronization of certain operations.

[0180] Thus, the structure of the initial Petri net model was optimized, resulting in the final Petri net model, which provides a more accurate model for subsequent data detection.

[0181] This embodiment, through the above-described scheme, specifically tracks the running state of the application using the tracing tool to obtain the first shared memory read / write operation, thread ID, memory address, and operation timestamp of the thread in the application; it then filters the first shared memory read / write operation, thread ID, memory address, and operation timestamp to obtain initial dynamic tracing data; based on preset data mapping requirements, it further filters the initial dynamic tracing data to obtain dynamic tracing data. Therefore, a final Petri net model is obtained by modeling based on the acquired dynamic tracing data of the Rust program. Subsequently, a Petri net analysis tool is used to perform data detection on the final Petri net model to obtain a data detection report. This solves the problem that existing vulnerability detectors cannot perform dynamic detection on Rust programs, improving the accuracy of data detection.

[0182] For example, to help understand the implementation flow of the data detection method obtained by combining this embodiment with the first embodiment described above, please refer to... Figure 3 , Figure 3 A simplified flowchart of a data detection method is provided, specifically:

[0183] This embodiment illustrates a software tool for automatic modeling and data race detection using Rust language based on Petri nets, used to execute the data detection method described in the above embodiment, including:

[0184] The user interface module calls the Cargo tool to automatically lock the dependencies of the input package and collect all the necessary source files. It also supports reading a Rust crate as input through a custom subcommand, combined with user-provided shared memory access rules and detection options.

[0185] The dynamic tracing module uses the Miri tool to dynamically capture the memory access behavior of Rust programs during runtime, generating dynamic trace data of memory access. The captured events include thread creation and synchronization, as well as read and write operations on shared memory.

[0186] The Petri net modeling module dynamically generates Petri net models for shared memory access, maps memory addresses in trace data to Petri net places, maps read / write operations to transitions, models inter-thread dependencies as markup transitions, and finally generates a model conforming to the Petri Net Markup Language (PNML) format.

[0187] The data contention detection module calls Petri net analysis tools (such as PIPE) to locate potential data contentions based on transition conflict detection and state reachability analysis, and generates detailed diagnostic information.

[0188] The software tool in this embodiment includes a simple and intuitive user interface, allowing users to easily configure detection options and run the tool. It is deeply integrated with other tools in the Rust ecosystem (such as Cargo and Miri), making it convenient for developers to use directly in their existing development environments.

[0189] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the data detection method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0190] This application also provides a data detection device, please refer to... Figure 4 The data detection device includes:

[0191] Modeling module 10 is used to acquire dynamic tracking data of the application and to perform modeling based on the dynamic tracking data to obtain the final data model;

[0192] The detection module 20 is used to perform data detection on the final data model using model analysis tools and obtain a data detection report.

[0193] The data detection device provided in this application, employing the data detection method described in the above embodiments, can solve the technical problem that existing vulnerability detectors cannot dynamically detect Rust programs. Compared with the prior art, the beneficial effects of the data detection device provided in this application are the same as those of the data detection method described in the above embodiments, and other technical features in the data detection device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0194] This application provides a data detection device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the data detection method in the first embodiment described above.

[0195] The following is for reference. Figure 5 The diagram illustrates a structural schematic of a data detection device suitable for implementing embodiments of this application. The data detection device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The data detection device shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of this application.

[0196] like Figure 5 As shown, the data detection device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the data detection device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the data detection device to communicate wirelessly or wiredly with other devices to exchange data. Although the figures show data detection devices with various systems, it should be understood that implementing or having all of the systems shown is not required. More or fewer systems may be implemented alternatively.

[0197] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0198] The data detection device provided in this application, employing the data detection method described in the above embodiments, can solve the technical problem that existing vulnerability detectors cannot dynamically detect Rust programs. Compared with the prior art, the beneficial effects of the data detection device provided in this application are the same as those of the data detection method described in the above embodiments, and other technical features of this data detection device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0199] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

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

[0201] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the data detection method in the above embodiments.

[0202] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0203] The aforementioned computer-readable storage medium may be included in the data detection device; or it may exist independently and not be assembled into the data detection device.

[0204] The aforementioned computer-readable storage medium carries one or more programs. When the one or more programs are executed by the data detection device, the data detection device: acquires dynamic tracking data of the application, and models the data based on the dynamic tracking data to obtain a final data model; and performs data detection on the final data model using a model analysis tool to obtain a data detection report.

[0205] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0206] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0207] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0208] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described data detection method, thereby solving the technical problem that existing vulnerability detectors cannot dynamically detect Rust programs. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the data detection method provided in the above embodiments, and will not be repeated here.

[0209] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the data detection method described above.

[0210] The computer program product provided in this application can solve the technical problem that existing vulnerability detectors cannot dynamically detect Rust programs. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the data detection method provided in the above embodiments, and will not be repeated here.

[0211] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.< / usize> < / threadid> < / threadid>

Claims

1. A data detection method, characterized in that, The method includes: Acquire dynamic tracking data from the application and perform modeling based on the dynamic tracking data to obtain the final data model; The step of acquiring dynamic tracking data from the application and modeling based on the dynamic tracking data to obtain the final data model includes: Detect the application's program status; When the program is in the running state, the application is dynamically tracked using a tracing tool to obtain dynamic tracing data; Map the dynamic tracking data to an initial data model; The step of mapping the dynamic tracking data to the initial data model includes: Extract the second shared memory read / write operations from the dynamic tracking data; A memory access graph is constructed based on the second shared memory read / write operation; The memory access graph is semantically equivalence-based by an optimization algorithm to obtain an optimized memory access graph. The optimized memory access graph is mapped to an initial data model according to the data modeling rules. The data modeling rules include mapping the shared memory locations in the optimized memory access graph to places in Petri nets, mapping the memory operation types in the optimized memory access graph to transitions in Petri nets, and describing the causal relationships between threads in the optimized memory access graph using Petri net label transitions. The initial data model is structurally optimized to obtain the final data model; The step of optimizing the structure of the initial data model to obtain the final data model includes: The initial data model was simulated, and invalid paths in the model were obtained. Analyze the aggregation locations in the initial data model to obtain the model repetition path; The invalid paths in the initial data model are deleted, the duplicate paths in the initial data model are aggregated, and concurrency semantics are introduced to obtain the final data model. The final data model is tested using model analysis tools to obtain a data testing report.

2. The method as described in claim 1, characterized in that, The step of dynamically tracking the application using a tracking tool to obtain dynamic tracking data includes: The tracing tool is used to track the running status of the application to obtain the first shared memory read / write operation of the thread in the application, the thread ID, the memory address, and the operation timestamp. The initial dynamic tracking data is obtained by filtering the first shared memory read / write operations, thread IDs, memory addresses, and operation timestamps. Based on preset data mapping requirements, the initial dynamic tracking data is filtered to obtain dynamic tracking data.

3. The method as described in claim 1, characterized in that, The step of performing data testing on the final data model using model analysis tools and obtaining a data testing report includes: The data accessibility analysis results are obtained by performing an accessibility analysis on the final data model using the model analysis tool. The model analysis tool is used to perform transition conflict detection on the final data model to obtain the data transition conflict detection results. The final data model is subjected to labeling and flow analysis using the model analysis tool to obtain the data labeling and flow analysis results. A data detection report is generated based on the accessibility analysis results, data transition conflict detection results, and data tagging flow analysis results.

4. A data detection device, characterized in that, The device includes: The modeling module is used to acquire dynamic tracking data of the application and to perform modeling based on the dynamic tracking data to obtain the final data model; The modeling module is also used to detect the program state of the application. When the program is in the running state, the application is dynamically tracked using a tracing tool to obtain dynamic tracing data; Map the dynamic tracking data to an initial data model; Extract the second shared memory read / write operations from the dynamic tracking data; A memory access graph is constructed based on the second shared memory read / write operation; The memory access graph is semantically equivalence-based by an optimization algorithm to obtain an optimized memory access graph. The optimized memory access graph is mapped to an initial data model according to the data modeling rules. The data modeling rules include mapping the shared memory locations in the optimized memory access graph to places in Petri nets, mapping the memory operation types in the optimized memory access graph to transitions in Petri nets, and describing the causal relationships between threads in the optimized memory access graph using Petri net label transitions. The initial data model is structurally optimized to obtain the final data model; The initial data model was simulated, and invalid paths in the model were obtained. Analyze the aggregation locations in the initial data model to obtain the model repetition path; The invalid paths in the initial data model are deleted, the duplicate paths in the initial data model are aggregated, and concurrency semantics are introduced to obtain the final data model. The detection module is used to perform data detection on the final data model using model analysis tools and obtain a data detection report.

5. A data detection device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the data detection method as described in any one of claims 1 to 3.

6. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the data detection method as described in any one of claims 1 to 3.

7. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the data detection method as described in any one of claims 1 to 3.

Images