Data detection method and device, equipment, medium and product

Abstract

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

Description

Technical Field

[0001] The present application relates to the technical field of software system modeling and analysis, and in particular to a data detection method, device, equipment, medium and product. Background Art

[0002] Rust is a programming language developed by Mozilla, aimed at building efficient and secure low-level software. Its main idea is to inherit most of the features of C and C++, thereby retaining the good runtime performance of C and C++, but at the same time passing strict compilation checks to eliminate the security issues of C and C++. Therefore, more and more developers are using Rust for program compilation.

[0003] In the prior art, for vulnerability detection of Rust programs, the static detector Rust-clippy is usually used to detect memory bugs that follow certain simple source code patterns, but Rust-clippy can only cover a small number of bug patterns. In addition, some relevant personnel have adopted the dynamic memory bug detector Miri, which can be used to interpret and execute Rust's mid-level intermediate representation (MIR), but in actual use, Miri will also produce many false positives. It can be seen that although the detector based on program analysis has advantages such as fast analysis speed, it covers a narrow range of bugs and is prone to false positives. In addition, Rust's alias model constructs a dynamic memory bug detector, which can effectively report potential uncertain behaviors and memory bugs when references are not correctly nested, and has advantages such as high precision. However, this dynamic detector relies on user-provided input to trigger memory bugs and cannot achieve timely vulnerability detection.

[0004] The above contents are only used to assist in understanding the technical solution of the present application and do not constitute an admission that the above contents are prior art. Summary of the invention

[0005] The main purpose of this application is to provide a data detection method, device, equipment, medium and product, aiming to solve the technical problem that existing vulnerability detectors cannot dynamically detect Rust programs.

[0006] To achieve the above purpose, the present application proposes a data detection method, which includes:

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

[0008] The final data model is subjected to data detection by a model analysis tool to obtain a data detection report.

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

[0010] detecting a program state of the application;

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

[0012] Mapping the dynamic tracking data into an initial data model;

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

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

[0015] Tracking the running state of the application program by using the tracking tool to obtain the first shared memory read / write operation, thread ID, memory address and operation timestamp of the thread in the application program;

[0016] Filtering the first shared memory read and write operation, thread ID, memory address, and operation timestamp to obtain initial dynamic tracking data;

[0017] Based on the 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 into an initial data model includes:

[0019] Extracting a second shared memory read and write operation in the dynamic tracking data;

[0020] Constructing a memory access graph according to the second shared memory read and write operations;

[0021] Performing semantic equivalence pruning on the memory access graph by using an optimization algorithm to obtain an optimized memory access graph;

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

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

[0024] Performing simulation operations on the initial data model to obtain a model invalid path;

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

[0026] The invalid model paths in the initial data model are deleted, the repeated model paths in the initial data model are aggregated, and concurrent semantics are introduced to obtain the final data model.

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

[0028] Performing a reachability analysis on the final data model by using the model analysis tool to obtain a data reachability analysis result;

[0029] Performing change conflict detection on the final data model by using the model analysis tool to obtain a data change conflict detection result;

[0030] Performing a tag flow analysis on the final data model by using the model analysis tool to obtain a data tag flow analysis result;

[0031] A data detection report is generated based on the reachability analysis results, data change conflict detection results, and data tag flow analysis results.

[0032] In addition, to achieve the above purpose, the present application also proposes a data detection device, the data detection device comprising:

[0033] A modeling module, used to obtain dynamic tracking data of the application program, and to perform modeling based on the dynamic tracking data to obtain a final data model;

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

[0035] In addition, to achieve the above objectives, the present application also proposes a data detection device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the data detection method described above.

[0036] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, which 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, the steps of the data detection method described above are implemented.

[0037] In addition, to achieve the above-mentioned purpose, the present application also provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, the steps of the data detection method described above are implemented.

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

[0039] The data detection method, device, equipment, medium and product proposed in the embodiment of the present application obtain the dynamic tracking data of the application program, and model the final data model according to the dynamic tracking data; the final data model is subjected to data detection by a model analysis tool to obtain a data detection report. Thus, the final Petri net model is obtained by modeling according to the dynamic tracking data of the Rust program obtained, and then the final Petri net model is subjected to data detection by a Petri net analysis tool to obtain a data detection report, which solves the problem that the existing vulnerability detector cannot dynamically detect the Rust program and improves the accuracy of data detection. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0041] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0042] Figure 1 A schematic diagram of a process flow provided for the first embodiment of the data detection method of the present application;

[0043] Figure 2 A schematic diagram of a flow chart provided for the second embodiment of the data detection method of the present application;

[0044] Figure 3 A brief flowchart of the data detection method provided in Example 2 of the present application;

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

[0046] Figure 5 Schematic diagram of the device structure of the hardware operating environment involved in the data detection method in the embodiment of the present application.

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

[0048] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not used to limit the present application.

[0049] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0050] The main solution of the embodiment of the present application is: detect the program state of the application; when the program state is program running, dynamically track the application through the tracking tool to obtain dynamic tracking data; map the dynamic tracking data to the initial data model; optimize the structure of the initial data model to obtain the final data model. Track the running state of the application through the tracking tool to obtain the first shared memory read and write operation, thread ID, memory address and operation timestamp of the thread in the application; filter the first shared memory read and write operation, thread ID, memory address and operation timestamp to obtain initial dynamic tracking data; filter the initial dynamic tracking data based on the preset data mapping requirements to obtain dynamic tracking data. Extract the second shared memory read and write operation in the dynamic tracking data; construct a memory access graph based on the second shared memory read and write operation; perform semantic equivalence trimming on the memory access graph through the optimization algorithm to obtain an optimized memory access graph; map the optimized memory access graph to the initial data model according to the data modeling rules. Perform simulation operations on the initial data model to obtain invalid model paths; analyze the aggregation positions in the initial data model to obtain repeated model paths; delete the invalid model paths in the initial data model, aggregate the repeated model paths in the initial data model, and introduce concurrent semantics to obtain the final data model. Perform reachability analysis on the final data model through the model analysis tool to obtain data reachability analysis results; perform change conflict detection on the final data model through the model analysis tool to obtain data change conflict detection results; perform tag flow analysis on the final data model through the model analysis tool to obtain data tag flow analysis results; generate a data detection report based on the reachability analysis results, data change conflict detection results, and data tag flow analysis results. This solves the problem that the existing vulnerability detector cannot dynamically detect Rust programs, realizes data detection, and improves the efficiency of data detection. Based on the scheme of the present invention, a data detection method is designed based on the problem that all Rust vulnerability detection tools in reality have their own limitations and none of them can detect concurrency bugs, thus resulting in low efficiency. The effectiveness of the data detection method of the present invention is verified when the data is detected. Finally, the efficiency of data detection performed by the method of the present invention is significantly improved.

[0051] In this embodiment, for the convenience of description, the following description is made with the data detection device as the execution subject.

[0052] Since the static detector Rust-clippy is used in the prior art to detect memory bugs that follow certain simple source code patterns, but Rust-clippy can only cover a small number of bug patterns. In addition, some relevant personnel have adopted the dynamic memory bug detector Miri, which can be used to interpret and execute Rust's mid-level intermediate representation (MIR), but in actual use, Miri will also produce many false positives. It can be seen that although the detector based on program analysis has advantages such as fast analysis speed, it covers a narrow range of bugs and is prone to false positives. In addition, Rust's alias model constructs a dynamic memory bug detector, which can effectively report potential uncertain behaviors and memory bugs when references are not correctly nested, and has advantages such as high precision. However, this dynamic detector relies on user-provided input to trigger memory bugs and cannot achieve timely vulnerability detection.

[0053] This application provides a solution to collect dynamic tracing data of Rust programs, and model the obtained data into a Petri net model. Finally, the Petri net analysis tool is used to perform data detection on the model to obtain a data detection report, thereby achieving accurate and fast data detection and providing users with better services.

[0054] From the above embodiments, it can be seen that the present application obtains the dynamic tracking data of the application program, and performs modeling based on the dynamic tracking data to obtain the final data model; the final data model is subjected to data detection by the model analysis tool to obtain a data detection report. Thus, the final Petri net model is obtained by modeling based on the dynamic tracking data of the Rust program obtained, and then the final Petri net model is subjected to data detection by the Petri net analysis tool to obtain a data detection report, which solves the problem that the existing vulnerability detector cannot dynamically detect the Rust program and improves the accuracy of data detection.

[0055] It should be noted that the execution subject of this embodiment can be a computing service device with data processing, network communication and program running functions, such as a tablet computer, a personal computer, a mobile phone, etc., or an electronic device capable of realizing the above functions, a data detection device, etc. The following takes the data detection device as an example to illustrate this embodiment and the following embodiments.

[0056] Based on this, the present application embodiment provides a data detection method, referring to Figure 1 , Figure 1This is a flow chart of the first embodiment of the data detection method of the present application.

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

[0058] Step S01, obtaining dynamic tracking data of the application, and modeling according to the dynamic tracking data to obtain a final data model;

[0059] It should be clear that the data detection in the scheme of this embodiment is for Rust programs, and Rust programs are compiled based on the Rust programming language. In more detail, Rust is a system programming language that aims to provide higher security, performance and concurrency. Rust is led 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 system programming languages ​​such as C and C++, such as memory leaks, null pointer dereferences and data competition.

[0060] In the prior art, for vulnerability detection of Rust programs, the static detector Rust-clippy is usually used to detect memory bugs that follow certain simple source code patterns, but Rust-clippy can only cover a small number of bug patterns. In addition, some relevant personnel have adopted the dynamic memory bug detector Miri, which can be used to interpret and execute Rust's mid-level intermediate representation (MIR), but in actual use, Miri will also produce many false positives. It can be seen that although the detector based on program analysis has advantages such as fast analysis speed, it covers a narrow range of bugs and is prone to false positives. In addition, Rust's alias model constructs a dynamic memory bug detector, which can effectively report potential uncertain behaviors and memory bugs when references are not correctly nested, and has advantages such as high precision. However, this dynamic detector relies on user-provided input to trigger memory bugs and cannot achieve timely vulnerability detection.

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

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

[0063] After obtaining the Petri net model corresponding to the Rust program, the model can be tested for data through the Petri net analysis tool to obtain a data test report of the Rust program. Petri Net is a mathematical modeling tool, which is usually used to describe and analyze the transition between different states in the system. Petri Net is widely used in modeling concurrent systems, distributed systems, communication protocols, production systems, etc., and is particularly suitable for describing systems with characteristics such as concurrency, synchronization, mutual exclusion and resource competition. 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 automatically perform state space analysis, reachability analysis, deadlock detection, performance analysis and other tasks. The data test report in this embodiment refers to a report generated by analyzing and testing the data structure, variables, memory usage, concurrent behavior, error handling and other aspects in the Rust code. This type of report can be used to verify the security, performance, memory management, etc. of the Rust code, and help developers find potential errors and performance bottlenecks.

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

[0065] Specifically, the above step S01, obtaining the dynamic tracking data of the application, and modeling according to the dynamic tracking data to obtain the final data model, includes:

[0066] Step S011, detecting the program status of the application;

[0067] Step S012, when the program state is program running, dynamically tracking the application program through a tracking tool to obtain dynamic tracking data;

[0068] Step S013, mapping the dynamic tracking data into an initial data model;

[0069] Step S014, optimizing the structure of the initial data model to obtain a final data model.

[0070] This embodiment is based on the Cargo tool chain, does not require rewriting compilation commands, and can be seamlessly integrated into the Rust ecosystem. It uses the Rust tool Miri as the runtime front end to capture the dynamic behavior of memory operations and maintain the integrity of the original program semantics without modifying the user code. Cargo is the official build tool and package manager of 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 and greatly simplifies the workflow of Rust developers.

[0071] In addition, this embodiment also includes data clipping and optimization when acquiring dynamic tracing data. In the processing stage of dynamic Trace, this embodiment performs semantic clipping on operations unrelated to data competition, significantly reducing the state space of the Petri net model. Through the Petri net optimization rules and transition constraints, the scale of the generated model is further reduced, and the detection speed and accuracy are improved. In Petri Nets, Trace refers to the execution sequence of a series of activities or operations in the system, and this embodiment is explained with dynamic tracing data;

[0072] The method and tool in this embodiment are based on Rust's Miri (used to run and analyze Rust code, especially to detect potential errors and unsafe behaviors during execution. It provides a method different from traditional compiler execution, which can simulate the running of code and help developers better understand the behavior of the program, especially when dealing with low-level, unsafe code). The lock model in Miri is used to describe the behavior of mutex locks in a multi-threaded environment, including the lock ownership state, lock count, waiting queue and clock. 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 the thread holding the lock repeatedly locks the lock.

[0078] lock_count:usize,

[0079] / / / Thread queue waiting to acquire the lock.

[0080] queue:VecDeque <threadid>,

[0081] / / / Lock clock, record the time of the last unlock.

[0082] clock:VClock,

[0083] }

[0084] Among them, owner refers to the thread that currently holds the lock. If it is None, it means that the lock is not held. Lock_count refers to the lock counter, which is used to track the number of times the thread reenters the lock. Queue refers to the waiting queue, which stores the IDs of all threads waiting to obtain the lock. Clock refers to the lock clock, which uses the logical clock (VectorClock) to record the unlocking time of the lock, and supports tracking the temporal causal relationship of concurrent operations. The model supports dynamic capture of the operational semantics of the lock, including the locking and unlocking behavior of the thread and the management of the waiting queue.

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

[0086] pub struct Thread<'tcx>{

[0087] / / / The status of the current thread (such as 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] / / / The callback function after the stack is cleared is used to handle subsequent operations when the thread ends.

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

[0095] / / / The top frame index of the user-related call stack for quick access.

[0096] top_user_relevant_frame:Option <usize>,

[0097] / / / The "Join" state of the thread describes the synchronization and exit status of the thread.

[0098] join_status:ThreadJoinStatus,

[0099] / / / The stack of panic information actively thrown in 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] Among them, state refers to the state of the current thread, such as running, waiting or exited, thread_name refers to the thread name, which is convenient for debugging, stack refers to the virtual call stack, which contains the function call information of the thread running, on_stack_empty refers to the callback function when the stack is cleared, which is used to handle the logic of thread termination, join_status refers to the description of the thread synchronization status (such as waiting for other threads to complete), panic_payloads refers to the storage of panic information actively thrown in the current thread, and last_error refers to the most recent operating system error address, which is convenient for tracking problems in abnormal situations.

[0105] This model provides basic support for dynamically capturing the running status and behavior of threads. Information such as thread creation, destruction, and call stack changes can be modeled through 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] It can be seen from the above embodiments that after acquiring the dynamic tracing data of Rust, this embodiment maps and models it through the Petri net to obtain the final Petri net model for analysis, thereby solving the problem of being unable to dynamically detect the Rust program.

[0110] More specifically, the step S02 of performing data detection on the final data model by using a model analysis tool to obtain a data detection report includes:

[0111] Step S021, performing reachability analysis on the final data model by using the model analysis tool to obtain a data reachability analysis result;

[0112] Step S022, performing a change conflict detection on the final data model by using the model analysis tool to obtain a data change conflict detection result;

[0113] Step S023, performing a tag flow analysis on the final data model by using the model analysis tool to obtain a data tag flow analysis result;

[0114] Step S024, generating a data detection report according to the reachability analysis result, the data change conflict detection result and the data tag flow analysis result.

[0115] This embodiment uses a Petri net analysis tool to detect data competition, that is, calling a Petri net analysis tool (such as a PIPE tool) to perform mathematical analysis on the generated Petri net model, locate potential data competition points through transition conflict detection and reachability analysis, and generate a detailed detection report, wherein the detection report in this embodiment includes a description of the competition condition, the shared memory address involved, the access thread ID, and the specific operation path of the potential competition, etc.;

[0116] Among them, reachability analysis is a method of analyzing the system state in Petri nets. 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 certain initial state. Through reachability analysis, we can understand the behavior of the system under various possible operations, and then 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 there are transitions that cannot occur at the same time. Conflict detection helps 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. It is 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 changes, and the stability of system behavior. Through marking transit analysis, it is possible to identify possible states, deadlocks, reachability problems, etc. in Petri nets.

[0119] The software tool of this embodiment uses the Petri net analysis method to reveal data competition bugs in Rust concurrent programs that cannot be discovered by existing static or dynamic detection tools, and provides more accurate dynamic detection capabilities.

[0120] This embodiment adopts the above scheme, specifically by obtaining the dynamic tracking data of the application, and modeling according to the dynamic tracking data to obtain the final data model; the final data model is tested by the model analysis tool to obtain a data test report. Thus, the final Petri net model is modeled according to the dynamic tracking data of the Rust program obtained, and then the final Petri net model is tested by the Petri net analysis tool to obtain a data test report, which solves the problem that the existing vulnerability detector cannot dynamically detect the Rust program and improves the accuracy of data detection.

[0121] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the above-mentioned embodiment 1 can be referred to the above introduction, and will not be repeated in the following. Figure 2 In step S012, the application is dynamically tracked by a tracking tool to obtain dynamic tracking data. The data detection method further includes steps S0121 to S0123:

[0122] Step S0121, tracking the running state of the application program through the tracking tool to obtain the first shared memory read / write operation, thread ID, memory address and operation timestamp of the thread in the application program;

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

[0124] Step S0123: based on a preset data mapping requirement, filtering the initial dynamic tracking data to obtain dynamic tracking data.

[0125] In this embodiment, Rust's runtime analysis tool Miri is selected to capture the dynamic behavior of the program at runtime and generate a trace (i.e., dynamic tracing data) containing multi-thread memory access information. The Miri tool can capture the read and write operations of shared memory between threads at the interpreter level, record the thread ID, memory address, operation type, and timestamp, and build a complete memory access trace. This method has the advantages of high accuracy and good coverage. An example is as follows:

[0126] thread::spawn(||{

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

[0128] });

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

[0130] The dynamic trace captured by Miri may be as follows:

[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 that is not related to data contention (such as operations on local variables). To improve detection efficiency, the trace needs to be trimmed 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 filter and trim the dynamic Trace data, eliminate local variable operations and redundant paths that are not related to data contention, and then retain only the critical paths that may affect shared memory for complex multi-threaded operations, significantly reducing modeling complexity and state space size. The dynamic Trace data supports users to specify the type of shared memory access 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, the step S013, mapping the dynamic tracking data into an initial data model, includes:

[0136] Step S0131, extracting the second shared memory read and write operation in the dynamic tracking data;

[0137] Step S0132, constructing a memory access graph according to the second shared memory read and write operations;

[0138] Step S0133, performing semantic equivalence pruning on the memory access graph by using an optimization algorithm to obtain an optimized memory access graph;

[0139] Step S0134, mapping the optimized memory access graph into an initial data model according to data modeling rules.

[0140] Map the optimized dynamic trace to a Petri net model, including mapping the shared memory location to the "Place" of the Petri net, mapping the read, write and synchronization operations to "Transition", and describing the state changes of memory access and the causal relationship between threads through the flow of marks;

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

[0142] Eliminate redundant paths in dynamic traces through semantic analysis and optimized pruning algorithms, ensuring that all key operations related to race conditions are retained.

[0143] According to the Petri net modeling rules, the optimized memory access graph is mapped to the Petri net structure. The mapping rules include the modeling rules of read-write conflicts, synchronization dependencies, and concurrent behaviors.

[0144] In addition, this embodiment can also specify the shared memory access type to be detected, that is, the user can specify the data competition type to be detected, including read operations and write operations to be detected separately, or mixed read and write access to be detected simultaneously. Different types of access modes correspond to different Petri net modeling rules;

[0145] Then, a memory access graph can be generated. According to the access type specified above, a memory access graph is constructed from the dynamic trace data. The memory access graph contains the interaction path between threads and shared memory, and combines the time sequence and operation type recorded in the trace to describe the memory access behavior of the multi-threaded program.

[0146] Finally, the memory access graph can be converted into an initial Petri net model, that is, the memory access graph is 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 the Petri net;

[0148] (2) Memory operation types (such as read, write, and synchronize) are mapped to "transitions" in the Petri net;

[0149] (3) The causal relationship between threads is described by the flow of Petri net markers to ensure that the original program semantics remain consistent;

[0150] The converted Petri net model can fully describe the memory access behavior of the Rust program and support competition 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 storing the shared memory access information between threads of dynamic trace includes an operation type record table, a thread ID mapping table and a memory address mapping table. After all memory access Petri net nodes are generated, they are automatically connected to the "library" where the program ends to indicate that the modeling is completed.

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

[0153] More specifically, the above Figure 1 In the illustrated embodiment, the step S014, optimizing the structure of the initial data model to obtain the final data model, comprises:

[0154] Step S0141, performing simulation operation on the initial data model to obtain an invalid model path;

[0155] Step S0142, analyzing the aggregation positions in the initial data model to obtain a model repetition path;

[0156] Step S0143, deleting invalid model paths in the initial data model, aggregating repeated model paths in the initial data model, and introducing concurrent semantics to obtain a final data model.

[0157] In this embodiment, the structural optimization of the initial Petri net model includes removing irrelevant paths, aggregating similar states, etc., and introducing concurrent semantic modeling extensions to capture potential competition 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, that is, the so-called "invalid paths", by simulating the state changes of the Petri net. Invalid paths usually refer to those paths that cannot be carried out normally under a given initial state, or those paths that cannot be continued due to resource conflicts, deadlocks, etc. In this embodiment, the triggering of each transition is simulated, and the mark distribution of the position is updated. After each transition is triggered: remove the mark on the input position that triggers the transition, and add a mark to the output position of the transition;

[0159] Assume that the simulation is performed: Initially, there is 1 mark on P1, and no marks on P2 and P3. That is, T1 can be triggered because there is a mark on P1. After the trigger, there is 1 mark on P2.

[0160] Then, T2 can trigger because there is a mark on P2. After triggering, there is 1 mark on P3. In this simple example, there is no invalid path because all transitions can trigger normally.

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

[0162] (1) Insufficient resources: If the mark at a certain position is not enough 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 trigger. If there is no mark on P2 (for example, T2 is not triggered), T3 cannot be triggered, thus forming an invalid path.

[0163] (2) Deadlock: If all transitions cannot be triggered at a certain moment (for example, 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 not be able to continue executing.

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

[0165] In addition to invalid paths, the optimization of the results of the initial Petri net model also includes aggregating similar states. In Petri nets, aggregating similar states (State Aggregation) is a technique used to simplify models and analysis. It reduces the size of the state space by merging similar states into an abstract state, thereby facilitating system analysis and simulation, especially when facing the problem of state space explosion. First of all, similar states usually refer to states in multiple states of the Petri net whose system behaviors, tag distributions, or certain properties of interest (such as execution flow, resource occupancy, etc.) are the same or very similar. Specifically, "similar" can be defined according to the following criteria: 1. Same tag distribution: If the number of tags in all positions in two states is exactly the same, then the two states can be regarded as similar states. 2. Same activity transitions: If the same transitions can be triggered from two different states, and these transitions have the same logical impact on the system, then the two states can also be regarded as similar. 3. Same deadlock or reachability: If two states can reach the same terminal state (for example, deadlock state or target state), these states can also be regarded as similar.

[0166] Aggregating similar states can be done in several ways:

[0167] (1) State tag aggregation: Aggregate the tag distribution of states, that is, treat states with the same tag 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 tag distribution, merging these states into an abstract state, and operating 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 tags, 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 distribution of labels, but on the structural characteristics of the states, the triggered transitions, and other aspects. For example, if the triggering conditions of transitions are the same, and the triggering order and triggering conditions of transitions are the same in different states, then these states can be considered equivalent and have the same behavioral characteristics. If the system starts from different states and eventually exhibits the same behavior and process (for example, both enter a 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 more simplified and abstract states than the original state space. These abstract states may be created by discarding some minor details (such as the number of marks at certain locations);

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

[0171] In addition, in this embodiment, concurrent semantics is introduced into the initial Petri net model. The purpose of the 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 concurrent semantics enables the Petri net to reflect system characteristics such as multi-tasking, resource sharing, competition, and synchronization. The Petri net itself is a modeling tool that is naturally suitable for describing concurrent behaviors. The place and transition in its structure allow the flow of events and resources in the system to be represented, and its concurrent 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 usually reflected in:

[0173] (1) Multiple transitions can be triggered simultaneously, that is, multiple transitions can occur at the same time. They can all be triggered in the same state, resulting in 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 at the same time.

[0174] (2) Parallel execution, that is, the transitions in the Petri net model can be executed in parallel in different threads or processes. 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 a concurrent system, multiple processes or tasks may share limited resources. In Petri nets, these resources are usually represented by positions. Multiple transitions may compete for the mark of the same position, which indicates resource competition.

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

[0177] (1) Concurrent transitions: In a Petri net, multiple transitions can occur simultaneously, provided that their input positions have sufficient mark support. For example, in the same state, multiple transitions can obtain marks from different positions and be triggered simultaneously, indicating parallel events or processes. For example, suppose there are two transitions T1 and T2, which depend on positions P1 and P2 respectively. If P1 and P2 are both marked, then T1 and T2 can be triggered at the same time, indicating 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) Synchronous 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, using transitions connecting multiple locations to ensure the order or synchronization of certain operations.

[0180] Thus, the structural optimization of the initial Petri net model is completed, and the final Petir net model is obtained, which provides a more accurate model for subsequent data detection.

[0181] This embodiment uses the above scheme, specifically by tracking the running status of the application through the tracking tool, to obtain the first shared memory read and write operation, thread ID, memory address and operation timestamp of the thread in the application; the first shared memory read and write operation, thread ID, memory address and operation timestamp are screened to obtain initial dynamic tracking data; based on the preset data mapping requirements, the initial dynamic tracking data is filtered to obtain dynamic tracking data. Thus, the final Petri net model is modeled according to the dynamic tracking data of the Rust program obtained, and then the final Petri net model is tested by the Petri net analysis tool to obtain a data detection report, which solves the problem that the existing vulnerability detector cannot dynamically detect the Rust program and improves the accuracy of data detection.

[0182] For example, to help understand the implementation process of the data detection method obtained by combining this embodiment with the above-mentioned embodiment 1, please refer to Figure 3 , Figure 3 A brief flow chart of a data detection method is provided, specifically:

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

[0184] A user interface module that calls the Cargo tool to automatically lock down the dependencies of the input package and collect all the required source files, while also supporting reading a Rust crate as input through custom subcommands, combined with user-provided shared memory access rules and instrumentation options;

[0185] Dynamic tracing module, which uses Miri tool to dynamically capture memory access behavior of Rust program during runtime and generate 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 a Petri net model for shared memory access, maps the memory address in the trace data to the Petri net place, maps the read / write operation to the transition, models the dependency between threads as a tag flow, and finally generates a model that conforms to the Petri Net Markup Language (PNML) format;

[0187] The data competition detection module calls Petri net analysis tools (such as PIPE tools) to locate potential data competition 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, and users can configure detection options and run the tool effortlessly. It is deeply integrated with other tools in the Rust ecosystem (such as Cargo and Miri), making it convenient for developers to use it directly in the existing development environment.

[0189] It should be noted that the above examples are only used to understand the present application and do not constitute a limitation on the data detection method of the present application. More simple transformations based on this technical concept are all within the scope of protection of the present application.

[0190] This application also provides a data detection device, please refer to Figure 4 , the data detection device comprises:

[0191] A modeling module 10 is used to obtain dynamic tracking data of the application program, and to perform modeling based on the dynamic tracking data to obtain a final data model;

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

[0193] The data detection device provided by the present application adopts the data detection method in the above embodiment, which can solve the technical problem that the existing vulnerability detector cannot dynamically detect the Rust program. Compared with the prior art, the beneficial effects of the data detection device provided by the present application are the same as the beneficial effects of the data detection method provided by the above embodiment, and the other technical features in the data detection device are the same as the features disclosed in the above embodiment method, which will not be repeated here.

[0194] The present 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 so that the at least one processor can execute the data detection method in the above-mentioned embodiment one.

[0195] Reference below Figure 5 , which shows a schematic diagram of the structure of a data detection device suitable for implementing the embodiment of the present application. The data detection device in the embodiment of the present application may include but is not limited to mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 5 The data detection device shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0196] like Figure 5 As shown, the data detection device may include a processing device 1001 (e.g., a central processing unit, a graphics processor, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM: Read Only Memory) 1002 or a program loaded from a storage device 1003 to a random access memory (RAM: Random Access Memory) 1004. In RAM1004, various programs and data required for the operation of the data detection device are also stored. The processing device 1001, ROM1002, and RAM1004 are connected to each other through a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Generally, the following systems can be connected to the I / O interface 1006: an input device 1007 including, for example, a touch screen, a touch pad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD: Liquid Crystal Display), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the data detection device to communicate with other devices wirelessly or by wire to exchange data. Although the data detection device with various systems is shown in the figure, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented or have alternatively.

[0197] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0198] The data detection device provided by the present application adopts the xx data detection x method in the above embodiment, which can solve the technical problem that the existing vulnerability detector cannot dynamically detect the Rust program. Compared with the prior art, the beneficial effects of the data detection device provided by the present application are the same as the beneficial effects of the data detection method provided by the above embodiment, and the other technical features in the data detection device are the same as the features disclosed in the method of the previous embodiment, which will not be repeated here.

[0199] It should be understood that the various parts disclosed in this application can be implemented by 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 one or more embodiments or examples in a suitable manner.

[0200] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0201] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, computer programs) stored thereon, wherein the computer-readable program instructions are used to execute the data detection method in the above-mentioned embodiment.

[0202] The computer-readable storage medium provided in the present application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, systems or devices, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. 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 combination with an instruction execution system, system or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination of the above.

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

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

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

[0206] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0207] The modules involved in the embodiments described in this application may be implemented by software or hardware, wherein the name of the module does not constitute a limitation on the unit itself in some cases.

[0208] The readable storage medium provided by the present application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., computer programs) for executing the above-mentioned data detection method, and can solve the technical problem that the existing vulnerability detector cannot dynamically detect Rust programs. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided by the present application are the same as the beneficial effects of the data detection method provided by the above-mentioned embodiment, and will not be repeated here.

[0209] The present application also provides a computer program product, including a computer program, which implements the steps of the above-mentioned data detection method when executed by a processor.

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

[0211] The above descriptions are only some embodiments of the present application, and are not intended to limit the patent scope of the present application. All equivalent structural changes made using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect applications in other related technical fields are included in the patent protection scope of the present application.< / usize> < / threadid> < / threadid>

Claims

1. A data detection method, characterized in that: The method comprises: Acquire dynamic tracking data of the application, and perform modeling based on the dynamic tracking data to obtain a final data model; The final data model is subjected to data detection by a model analysis tool to obtain a data detection report.

2. The method according to claim 1, characterized in that The step of obtaining the dynamic tracking data of the application and modeling according to the dynamic tracking data to obtain the final data model includes: detecting a program state of the application; When the program state is program running, dynamically tracing the application program through a tracing tool to obtain dynamic tracing data; Mapping the dynamic tracking data into an initial data model; The initial data model is structurally optimized to obtain a final data model.

3. The method according to claim 2, characterized in that The step of dynamically tracking the application program through the tracking tool to obtain dynamic tracking data includes: Tracking the running state of the application program by using the tracking tool to obtain the first shared memory read / write operation, thread ID, memory address and operation timestamp of the thread in the application program; Filtering the first shared memory read and write operation, thread ID, memory address, and operation timestamp to obtain initial dynamic tracking data; Based on the preset data mapping requirements, the initial dynamic tracking data is filtered to obtain dynamic tracking data.

4. The method according to claim 2, characterized in that The step of mapping the dynamic tracking data into an initial data model comprises: Extracting a second shared memory read and write operation in the dynamic tracking data; Constructing a memory access graph according to the second shared memory read and write operations; Performing semantic equivalence pruning on the memory access graph by using an optimization algorithm to obtain an optimized memory access graph; The optimized memory access graph is mapped to an initial data model according to data model modeling rules.

5. The method according to claim 2, characterized in that The step of optimizing the structure of the initial data model to obtain the final data model comprises: Performing simulation operations on the initial data model to obtain a model invalid path; Analyze the aggregation positions in the initial data model to obtain a model repetition path; The invalid model paths in the initial data model are deleted, the repeated model paths in the initial data model are aggregated, and concurrent semantics are introduced to obtain the final data model.

6. The method according to claim 1, characterized in that The step of performing data detection on the final data model by using a model analysis tool to obtain a data detection report comprises: Performing a reachability analysis on the final data model by using the model analysis tool to obtain a data reachability analysis result; Performing change conflict detection on the final data model by using the model analysis tool to obtain a data change conflict detection result; Performing a tag flow analysis on the final data model by using the model analysis tool to obtain a data tag flow analysis result; A data detection report is generated based on the reachability analysis results, data change conflict detection results, and data tag flow analysis results.

7. A data detection device, characterized in that: The device comprises: A modeling module, used to obtain dynamic tracking data of the application program, and to perform modeling based on the dynamic tracking data to obtain a final data model; The detection module is used to perform data detection on the final data model through a model analysis tool to obtain a data detection report.

8. A data detection device, characterized in that: The device comprises: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the data detection method according to any one of claims 1 to 6.

9. 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, the steps of the data detection method according to any one of claims 1 to 6 are implemented.

10. A computer program product, characterized in that The computer program product comprises a computer program, and when the computer program is executed by a processor, the steps of the data detection method according to any one of claims 1 to 6 are implemented.

Images