Abnormal software behavior remote identification method and system for multi-player game terminal

Abstract

The invention discloses an abnormal software behavior remote identification method and system oriented to a multi-player game terminal, particularly relates to the technical field of chess and card game terminal safety protection, and is used for solving the problem that in the prior art, due to terminal isomerism, behavior characteristic data collection granularity is not uniform, and then remote identification effectiveness is reduced. Collection granularity information is synchronously bound when behavior characteristic data are collected at a terminal side, a server side verifies the integrity and granularity marking validity of the data after receiving the data, then cluster classification is carried out according to terminal types, collection granularity marking probability distribution is fitted, local outlier factors are calculated accordingly, a data set conforming to a non-outlier threshold value is screened out, and the data set is subjected to data collection. Then, prior distribution is constructed based on probability distribution, correlation confidence is calculated, a data set with the confidence reaching the standard is screened out, then, a same-granularity feature data set is obtained through merging according to granularity marks, finally, quantitative calibration and correlation analysis are conducted on the data set, and therefore accurate recognition of abnormal software behaviors is achieved.

Description

Technical Field

[0001] This invention relates to the field of security protection technology for card and board game terminals, and more specifically, to a method and system for remotely identifying abnormal software behavior in multiplayer game terminals. Background Technology

[0002] Card and board games are typical multiplayer games. In the field of terminal security protection for card and board games, remote identification technology can be used to prevent security risks such as cheating caused by abnormal software behavior. The core logic is to collect behavioral characteristic data during software operation on the terminal side, transmit it remotely, and then have the server perform aggregation and analysis of multi-terminal data to identify abnormal behavior and protect the terminal. This falls within the core research scope of computer terminal security protection. Because card and board game terminals are diverse, encompassing mobile terminals, desktop terminals, emulators, and other types, the system architecture, data collection interface permissions, and data collection accuracy of different terminals naturally differ, resulting in significant differences in the granularity of the software behavioral characteristic data collected on the terminal side. In existing technologies, the terminal side only performs simple format normalization preprocessing on the collected raw behavioral characteristic data before remotely transmitting the data to the server. During the aggregation and analysis phase, the server mainly performs normalization processing on the formats of data uploaded from different terminals to complete the integration of multi-terminal data and subsequent analysis.

[0003] Existing remote identification technologies for abnormal software behavior on multiplayer game terminals lack a suitable collaborative processing mechanism to address the differences in granularity of behavioral feature collection caused by terminal heterogeneity in the entire process of terminal-side data collection and server-side aggregation and analysis. The terminal side does not uniformly label the granularity information of the collected data, and the server side does not carry out effective granularity calibration and unified quantification processing. This results in the dilution or distortion of effective features of behavioral feature data of different granularities in the same analysis system, making it impossible to accurately extract the core features of abnormal software behavior. This seriously reduces the effectiveness of remote identification and makes it difficult to reliably guarantee the security protection requirements of card and board game terminals. Summary of the Invention

[0004] In order to overcome the above-mentioned defects of the prior art, the present invention provides a method and system for remote identification of abnormal software behavior in multiplayer game terminals to solve the problems mentioned in the background art.

[0005] To achieve the above objectives, the present invention provides the following technical solution: A remote identification method for abnormal software behavior on multiplayer game terminals includes: S1. When the card and board game terminal collects software behavior feature data, it synchronously records the collection granularity information and binds it to generate a software behavior feature dataset with granularity labels. S2. Remotely transmit the software behavior feature dataset to the server, and the server verifies the data integrity and the validity of the granular labeling. S3. The server classifies the verified software behavior feature datasets by terminal type, fits the probability distribution of the collection granularity label of each type of terminal, calculates the local outlier factor of the collection granularity label of a single terminal in its own cluster, and filters out the software behavior feature datasets that meet the non-outlier threshold. S4. Construct a prior distribution based on the probability distribution of the collection granularity label of various terminals, calculate the association confidence of the granularity label of the software behavior feature dataset that meets the non-outlier threshold with the terminal type, and filter the dataset that meets the confidence standard. S5. Merge the confidence-compliant datasets according to granularity labels to obtain feature data groups of the same granularity; S6. Quantize and calibrate feature data groups of the same granularity, and identify abnormal software behavior through correlation analysis of the quantized and calibrated feature data groups of the same granularity.

[0006] Furthermore, S1 includes: Collect behavioral characteristic data generated by the software during the operation of the card and board game terminal; The granularity of data collection is determined based on the data collection environment of behavioral feature data. The collected granularity information is used as a granularity label and bound to the collected behavioral feature data to generate a software behavioral feature dataset with granularity labels.

[0007] Furthermore, S2 includes: The software behavior feature dataset with granular labels is remotely transmitted from the chess and card game terminal to the server. After receiving the software behavior feature dataset with granular labels, the server performs data integrity verification on the software behavior feature dataset with granular labels. The format and content validity of the granular tags in the software behavior feature dataset with granular tags are validated.

[0008] Furthermore, S3 includes: Based on the terminal types corresponding to the verified software behavior feature dataset, cluster classification is performed to obtain several terminal clusters. For each terminal cluster, a probability distribution of the collected granular labels is fitted based on the granular labels in all verified software behavior feature datasets within it. For each verified software behavior feature dataset, the local outlier factor is calculated based on the position of its granularity label in the probability distribution of the granularity label of the terminal cluster to which it belongs. Based on a preset non-outlier threshold, local outlier factors are compared with the non-outlier threshold to select software behavior feature datasets whose local outlier factors do not exceed the non-outlier threshold.

[0009] Furthermore, based on the position of its granularity label in the probability distribution of the acquisition granularity label of its respective terminal cluster, the local outlier factor is calculated. Specifically, this includes: determining the probability density of the granularity label of the verified software behavior feature dataset in the probability distribution of the acquisition granularity label of its respective terminal cluster based on its granularity label; and calculating the local outlier factor by comparing the probability density with the probability density of its neighboring region in the probability distribution of the acquisition granularity label.

[0010] Furthermore, S4 includes: Based on the probability distribution of collection granularity labels of various terminals, a prior distribution characterizing the relationship between granularity labels and terminal types is constructed. For each software behavior feature dataset that meets the non-outlier threshold, the association confidence is calculated based on its granularity label and terminal type, combined with the prior distribution. The association confidence level is compared with a preset confidence threshold, and the datasets whose association confidence level reaches the confidence threshold are selected as the confidence-compliant datasets.

[0011] Furthermore, S5 includes: Based on the granularity labels contained in the confidence score calibrated datasets, confidence score calibrated datasets with the same granularity labels are merged into the same set to form several feature data groups with the same granularity. Within each granularity feature data group, the software behavior feature data have the same granularity label.

[0012] Furthermore, S6 includes: Quantitative calibration processing is performed on software behavior feature data within the same granularity feature data group; Based on the quantified and calibrated feature data set of the same granularity, we conduct correlation analysis among software behavior feature data. Based on the results of correlation analysis, abnormal software behavior was identified.

[0013] Furthermore, based on the quantized and calibrated same-granularity feature data set, correlation analysis is performed between software behavior feature data. Specifically, this includes: calculating the correlation measure between different software behavior feature data within the quantized and calibrated same-granularity feature data set; and determining the results of the correlation analysis based on the distribution of the correlation measure to identify abnormal software behavior.

[0014] On the other hand, the present invention provides a remote identification system for abnormal software behavior of multiplayer game terminals, comprising: The data collection and labeling module is used to synchronously record the collection granularity information and bind and generate a software behavior feature dataset with granular labels when collecting software behavior feature data from the card and board game terminal. The transmission verification module is used to remotely transmit the software behavior feature dataset to the server, and the server verifies the data integrity and the validity of the granular labeling. The cluster filtering module is used by the server to classify the verified software behavior feature datasets by terminal type, fit the probability distribution of the collection granularity label of each type of terminal, calculate the local outlier factor of the collection granularity label of a single terminal in its own cluster, and filter out the software behavior feature datasets that meet the non-outlier threshold. The confidence filtering module is used to construct a prior distribution based on the probability distribution of the collection granularity labels of various terminals, calculate the association confidence of the granularity labels of software behavior feature datasets that meet the non-outlier threshold with the terminal type, and filter the datasets that meet the confidence threshold. The merge grouping module is used to merge confidence-compliant datasets according to granularity to obtain feature data groups of the same granularity. The calibration and identification module is used to quantize and calibrate feature data groups of the same granularity, and to identify abnormal software behavior through correlation analysis of the quantized and calibrated feature data groups of the same granularity.

[0015] Compared with the prior art, the present invention has the following beneficial effects: 1. By synchronously recording and binding the collection granularity information at the data acquisition source, the originally mixed behavioral feature data of different precisions are given distinguishable identifiers. This enables all subsequent processing links to explicitly perceive and utilize the granularity attributes of the data, and builds a granular collaborative mechanism that runs through the entire data processing chain from the terminal to the server. The server not only verifies the data itself, but also verifies the validity of the granularity tags, ensuring the authenticity and standardization of the metadata on which subsequent analysis depends. This changes the extensive mode of ignoring granularity differences and simply mixing data in the existing technology, and lays a reliable data foundation for achieving refined data analysis in heterogeneous terminal environments.

[0016] 2. By fitting the probability distribution of granular labels for different terminal types and performing outlier screening and confidence assessment accordingly, the server can intelligently filter out data noise that may be caused by abnormal or forged data collection from individual terminals. It selects high-quality data subsets with high granularity information matching terminal type and good group consistency. Subsequently, the data are merged according to the same granular label and uniformly quantified and calibrated, eliminating scale bias caused by different collection accuracy. This ensures that subsequent correlation analysis is conducted on a fair and consistent data plane, guaranteeing the coreness and accuracy of the features extracted by the abnormal behavior recognition model. As a result, the reliability and protection effectiveness of remote identification technology in dealing with complex terminal environments are significantly improved. Attached Figure Description

[0017] Figure 1 The flowchart is a method for remote identification of abnormal software behavior in multiplayer game terminals according to the present invention. Figure 2 This is a schematic diagram of the structure of the remote identification system for abnormal software behavior of multiplayer game terminals according to the present invention. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] Example 1: Figure 1 This invention presents a remote identification method for abnormal software behavior on multiplayer game terminals, comprising: S1. When the card and board game terminal collects software behavior feature data, it synchronously records the collection granularity information and binds it to generate a software behavior feature dataset with granularity labels. S2. Remotely transmit the software behavior feature dataset to the server, and the server verifies the data integrity and the validity of the granular labeling. S3. The server classifies the verified software behavior feature datasets by terminal type, fits the probability distribution of the collection granularity label of each type of terminal, calculates the local outlier factor of the collection granularity label of a single terminal in its own cluster, and filters out the software behavior feature datasets that meet the non-outlier threshold. S4. Construct a prior distribution based on the probability distribution of the collection granularity label of various terminals, calculate the association confidence of the granularity label of the software behavior feature dataset that meets the non-outlier threshold with the terminal type, and filter the dataset that meets the confidence standard. S5. Merge the confidence-compliant datasets according to granularity labels to obtain feature data groups of the same granularity; S6. Quantize and calibrate feature data groups of the same granularity, and identify abnormal software behavior through correlation analysis of the quantized and calibrated feature data groups of the same granularity.

[0020] S1. When collecting software behavior feature data from the card and board game terminal, the collection granularity information is recorded synchronously and bound to generate a software behavior feature dataset with granularity labels. The specific implementation is as follows: When executing this method on a card and board game terminal, the first step is to collect and label software behavior characteristic data. During the execution of a specified card and board game application, the terminal monitors and collects various behavior characteristic data generated by that application and other auxiliary software related to the card and board game in real time. The collected behavior characteristic data includes the software's call sequences to the system application programming interface during operation, access operations to specific files or registry entries, data packet sending and receiving behavior in network communication, process creation and destruction events, and dynamic allocation and access patterns of memory space. The collection process is implemented by calling the low-level monitoring interfaces provided by the terminal operating system. For example, on mobile terminals, the system kernel event tracing mechanism can be used to capture function call sequences, or a preset software probe can be used to intercept specific application programming interface calls; on desktop terminals, the system's built-in performance counters can be used to monitor process resource usage, or process monitoring tools can be used to record file access and network connection events.

[0021] While collecting behavioral feature data, the card and board game terminal needs to simultaneously determine and record the collection granularity information corresponding to this collection behavior. The determination of collection granularity information is based on the collection environment of the behavioral feature data. The collection environment is a comprehensive set of technical parameters, the core elements of which include the hardware architecture type of the card and board game terminal where the collection behavior occurred, the specific type and version number of the operating system, the system permission level granted to the collection program during runtime, and the technical specifications and configuration parameters of the specific data collection interface used. For example, when the collection environment is a mobile terminal with high privileges and uses a kernel-level tracing interface, it can collect behavioral feature data accurate to a single system call instruction and its parameters; the determined collection granularity information in this case can be identified as high-precision collection. Conversely, when the collection environment is an emulator with limited privileges and only uses an application-layer performance monitoring interface, it can only collect overview data such as CPU and memory usage at the process level; the determined collection granularity information in this case is identified as low-precision collection. The specific process of determining the granularity of data collection is based on a pre-established configuration mapping relationship stored locally on the card and board game terminal. This configuration mapping relationship exists in the form of a lookup table or a set of judgment rules, defining the mapping between specific combinations of data collection environment parameters and corresponding data collection granularity information identifiers. During operation, the actual parameters of the current data collection environment are compared and matched with the configuration mapping relationship, thereby outputting a specific data collection granularity information identifier that characterizes the level of data detail.

[0022] The card and board game terminal performs a binding and generation operation. The terminal associates the determined collection granularity information as independent metadata, i.e., a granularity tag, with the raw behavioral feature data collected within the same time period. The specific technical implementation of this binding involves attaching a structured data header or a dedicated metadata block to each group or individual behavioral feature data. This header or metadata block explicitly records the collection granularity information corresponding to this collection. For example, the generated dataset can adopt an encapsulation format, using the continuously collected behavioral feature data byte stream as the main content, while constructing a header structure containing specific fields. One field is specifically used to write the collection granularity information identifier. This header and the main data are tightly associated through contiguous memory addresses or logical data pointers, ensuring that the granularity tag and the behavioral feature data constitute an inseparable whole data unit both logically and physically, thus generating a software behavioral feature dataset with granularity tags. This dataset serves as the basic data unit for all subsequent processing flows.

[0023] S2. The software behavior feature dataset is remotely transmitted to the server. The server verifies the data integrity and the validity of the granular labeling. The specific implementation is as follows: After generating a granularly labeled software behavior feature dataset on the card and board game terminal, a data transmission step is performed. The terminal retrieves the generated granularly labeled software behavior feature dataset from local storage or memory via a network connection and, through its network interface, uses standard network communication protocols, such as Transmission Control Protocol (TCP) or Hypertext Transfer Protocol (HTTP), to remotely send the encapsulated granularly labeled software behavior feature dataset as the data payload to a designated server address. The entire transmission process includes necessary network handshakes, data packetization, sequential transmission, packet loss retransmission, and transmission encryption mechanisms to ensure that the data can be reliably delivered to the server over the network.

[0024] The server continuously listens on a designated network port. When it receives a network connection request and data stream from the gaming terminal, the server's network service program parses and reassembles the received data stream to restore the complete, granularly labeled software behavior feature dataset. This dataset is then stored in the server's memory or temporary storage area, completing the data reception. The server then initiates a verification process, starting with data integrity verification. The purpose of this verification is to confirm that the granularly labeled software behavior feature dataset received from the gaming terminal has not been damaged, lost, or tampered with during transmission. One specific implementation involves the server reading the received dataset and recalculating the checksum of the entire dataset or key parts of the dataset according to a pre-agreed verification algorithm consistent with that of the gaming terminal. For example, before sending, the gaming terminal can calculate the cyclic redundancy check value or a secure hash value using an algorithm such as Message Digest Algorithm Version 5 (CDE) for the entire granularly labeled software behavior feature dataset and append this checksum to the end of the data packet or in a separate checksum field before sending. Upon receiving the data, the server uses the same Cyclic Redundancy Check (CRC) algorithm or secure hash algorithm to recalculate the main body of the received dataset, obtaining a local checksum. This locally calculated checksum is then compared bit-by-bit with the checksum parsed from the data packet and sent by the gaming terminal. If the two checksums match perfectly, the data integrity check passes. If any discrepancy exists, the data integrity check fails, the dataset is marked as invalid, and an error handling process is initiated, such as logging an error and sending a data retransmission request to the gaming terminal.

[0025] After the data integrity check passes, the server then performs validity checks on the granular tags in the dataset. Validation is divided into two sub-steps: format validity check and content validity check. Format validity check examines whether the data structure, encoding method, length, etc., of the granular tags conform to the server's expected and predefined specifications. For example, the server maintains a rule base regarding granular tag format. This rule base defines that granular tags must be strings with a specific character encoding, such as Unicode, and their length must be between 8 and 64 characters, for example. They must also conform to a specific field delimiter format, such as using underscores to connect multiple fields. The server extracts the granular tag portion from the received software behavior feature dataset with granular tags and compares it one by one against the format rules in the rule base, checking whether its character set, length, delimiter position, etc., meet the requirements. Any violation of a format rule will cause the format validity check to fail.

[0026] Content validity verification, building upon successful format verification, further validates whether the specific content represented by the granularity markers is logically sound and acceptable to the system. The server maintains a set of valid granularity information value domains, containing all predefined and valid granularity information identifiers defined during system design. For example, this set might include specific text identifiers such as high-precision acquisition, medium-precision acquisition, and low-precision acquisition. The server matches the actual content of the format-validated granularity markers against each valid identifier in this set of valid granularity information value domains. If a matching item is found in the set, the content validity verification passes. If no matching item is found, meaning the content of the granularity marker is outside the predefined valid range (e.g., an undefined precision identifier), the content validity verification fails. Regardless of whether format or content verification fails, the software behavior feature dataset with granularity markers is considered invalid, and the server discards the dataset or places it in a waiting queue for manual review. Only when the data integrity check, the granularity tag format validity check, and the content validity check all pass, is the dataset marked as a valid software behavior feature dataset and allowed to proceed to the subsequent analysis and processing flow.

[0027] S3. The server classifies the verified software behavior feature datasets by terminal type, fits the probability distribution of the collection granularity label for each type of terminal, calculates the local outlier factor of the collection granularity label of a single terminal in its cluster, and filters out the software behavior feature datasets that meet the non-outlier threshold. The specific implementation is as follows: After obtaining the verified software behavior feature datasets, the server begins data preprocessing and filtering to address terminal heterogeneity. First, the server categorizes all verified software behavior feature datasets into clusters based on the terminal type information carried by each dataset. Terminal type information is metadata recorded by the game terminals during the data acquisition phase and included in the dataset; it clearly identifies the form and category of the data source terminal, such as a mobile terminal, desktop terminal, or emulator. The server reads the terminal type identifier of each verified software behavior feature dataset and merges all datasets with the same terminal type identifier into the same logical set, resulting in several terminal clusters based on terminal type. For example, all verified software behavior feature datasets labeled as mobile terminals constitute a mobile terminal cluster, and all verified software behavior feature datasets labeled as desktop terminals constitute a desktop terminal cluster. Verified software behavior feature datasets within each terminal cluster are considered to originate from a group of terminals with similar system architectures and acquisition capabilities.

[0028] After cluster classification, the server independently fits the probability distribution of the collection granularity markers for each terminal cluster. Specifically, the server iterates through all validated software behavior feature datasets within a given terminal cluster, extracting the granularity markers from each dataset. The server then counts all occurrences of each granularity marker within the terminal cluster and their respective frequencies. For example, in a mobile terminal cluster, there might be 120 validated software behavior feature datasets with high-precision collection granularity markers, 85 datasets with medium-precision collection granularity markers, and 15 datasets with low-precision collection granularity markers. Based on these frequencies, the server uses probabilistic statistical methods to fit the probability distribution of the collection granularity markers for that terminal cluster. A common fitting method is to directly use an empirical distribution, dividing the frequency of each granularity marker by the total number of validated software behavior feature datasets within the terminal cluster to obtain the empirical probability of each granularity marker in that terminal cluster. For example, the empirical probability for high-precision acquisition is 120 / 220 = 0.545, for medium-precision acquisition it is 85 / 220 = 0.386, and for low-precision acquisition it is 15 / 220 = 0.068. This mapping relationship between each granularity marker and its corresponding empirical probability is the fitted probability distribution of the acquisition granularity markers for the terminal cluster. For cases where the granularity markers are continuous values, a kernel density estimation method can be used to fit a continuous probability density function based on the values ​​of all granularity markers.

[0029] After obtaining the probability distribution of the granularity labels for each terminal cluster, the server calculates the local outlier factor of each granularity label within its respective terminal cluster for each validated software behavior feature dataset. Calculating the local outlier factor requires two core inputs: the granularity label of the validated software behavior feature dataset and the probability distribution of the granularity labels within its terminal cluster. First, based on the granularity label of the validated software behavior feature dataset, the server determines the probability density value corresponding to that granularity label within the probability distribution of the granularity labels in its respective terminal cluster. For discrete distributions, this probability density value is the empirical probability of that granularity label. For continuous distributions, the value of the granularity label needs to be substituted into the fitted probability density function to calculate the probability density value. Second, the server needs to define a neighborhood region, which refers to a local area surrounding the current granularity label on the probability distribution of the granularity label. For discrete markers, the neighboring region can be defined as a set of several other granular markers adjacent to the current granular marker. For example, in ordered discrete markers, the preceding and following granular markers of the current granular marker can be taken as the neighboring region. For continuous markers, the neighboring region can be defined as a fixed numerical interval centered on the current granular marker value, such as the interval between the current granular marker value -0.1 and the current granular marker value +0.1.

[0030] The server calculates the probability density reference value of the granularity marker within its neighborhood. One method is to calculate the average probability density of all possible granularity markers within that neighborhood. For discrete cases, this means calculating the average probability of each granularity marker in the defined set of neighboring markers. For continuous cases, it means calculating the average integral of the fitted probability density function over that numerical interval. Finally, the local outlier factor is calculated by comparing the probability density of the current granularity marker with the probability density reference value within its neighborhood. A typical calculation method is to divide the probability density reference value of the neighborhood by the probability density value of the current granularity marker; the quotient is the local outlier factor. Therefore, if a granularity marker in a validated software behavior feature dataset has a low probability of appearing in the probability distribution of granularity markers collected by its terminal cluster, while the average probability of its surrounding neighboring granularity markers is relatively high, then the calculated local outlier factor will be greater than 1, indicating that the granularity marker is a local outlier.

[0031] After calculating the local outliers for all validated software behavior feature datasets, the server filters them based on a preset outlier threshold. The outlier threshold is a pre-defined value used to determine whether a local outlier is within an acceptable normal range. The outlier threshold can be set based on historical data analysis, such as by analyzing the statistical quantiles of local outliers calculated from a large amount of historical normal data. For example, the 95th percentile value can be used as the outlier threshold after sorting historical local outliers by size. The server compares the local outliers of each validated software behavior feature dataset with the outlier threshold. The filtering rule is to retain software behavior feature datasets whose local outliers do not exceed the outlier threshold. A local outlier not exceeding the outlier threshold means that the granularity label of the validated software behavior feature dataset is within the normal sparsity range of the probability distribution of the granularity label in its respective terminal cluster, and does not belong to significant local anomalies. Conversely, if the local outlier factor is greater than the non-outlier threshold, it indicates that the data collection granularity label is too abnormal relative to its similar terminal group, and the reliability or consistency of the data may be problematic, so it is filtered out. The dataset retained after this filtering step is the software behavior feature dataset that meets the non-outlier threshold.

[0032] S4. Construct a prior distribution based on the probability distribution of the granularity labels of various terminals, calculate the association confidence between the granularity labels and terminal types of software behavior feature datasets that meet the non-outlier threshold, and filter datasets that meet the confidence threshold. The specific implementation is as follows: After obtaining a dataset of software behavior features that meets the non-outlier threshold, the server performs steps to further evaluate data reliability and filter out high-confidence data. First, based on the probability distributions of the acquisition granularity labels for various types of terminals fitted in previous steps, the server constructs a prior distribution characterizing the association between granularity labels and terminal types. These probability distributions of acquisition granularity labels for various types of terminals, such as the probability distributions for mobile terminal clusters and desktop terminal clusters, describe the probability of observing various acquisition granularity labels on specific types of terminals. The purpose of constructing the prior distribution is to formally characterize the probability knowledge of the occurrence of a specific acquisition granularity label given a certain terminal type.

[0033] One specific way to construct the prior distribution is to create a joint probability table. The rows of this joint probability table correspond to all possible terminal types, such as mobile terminals, desktop terminals, and emulators. The columns correspond to all possible acquisition granularity markers, such as high-precision acquisition, medium-precision acquisition, and low-precision acquisition. The value of each cell in the table represents the prior probability of the corresponding combination of terminal type and acquisition granularity marker. This prior probability value can be directly obtained from the acquisition granularity marker probability distributions of various terminals fitted in previous steps. Specifically, for a row in the table, i.e., a specific terminal type, the probability values ​​of each column, i.e., each acquisition granularity marker, are taken from the acquisition granularity marker probability distribution of the cluster corresponding to that terminal type. For example, in the mobile terminal row, the prior probability value of the high-precision acquisition column is equal to the empirical probability of high-precision acquisition (0.545) in the acquisition granularity marker probability distribution of the mobile terminal cluster. In this way, the independent probability distributions of each terminal cluster are integrated into a unified table structure, thus forming the required prior distribution. This prior distribution, as a whole, reflects the theoretical probability weights of combinations of different terminal types and different acquisition granularity labels within the system's observation range.

[0034] Next, for each software behavior feature dataset that meets the non-outlier threshold, the server calculates the association confidence between its granularity label and terminal type. Each software behavior feature dataset that meets the non-outlier threshold contains two key pieces of information: its own granularity label and its corresponding terminal type. The input for calculating the association confidence is these two pieces of information, along with the prior distribution constructed in the previous step. The goal of the calculation is to quantitatively evaluate the consistency between the observed combination of terminal type and granularity label in the current dataset and prior knowledge. One specific method for calculating the association confidence is that the server, based on the terminal type and granularity label of the dataset, looks up the corresponding cell in the joint probability table corresponding to the prior distribution, and directly uses the prior probability value stored in that cell as the association confidence. For example, for a software behavior feature dataset that meets the non-outlier threshold and comes from a mobile terminal with a granularity label of high-precision acquisition, its association confidence is the value of 0.545 in the cell at the intersection of the mobile terminal row and the high-precision acquisition column in the prior distribution table.

[0035] Another more refined calculation method considers relative probability. The server can calculate the ratio of the conditional probability of a specific granularity label appearing under the terminal type of the dataset to the marginal probability of that specific granularity label appearing across all terminal types, as the association confidence score. Specifically, first, from the prior distribution, the probability distribution of the row containing the terminal type of the dataset is obtained, and the conditional probability value corresponding to its granularity label is extracted, denoted as P1. Then, the arithmetic mean of all probability values ​​in the column containing the granularity label of the dataset is calculated in the prior distribution table, as the marginal probability of that granularity label appearing, denoted as P2. Finally, P1 is divided by P2, and the resulting ratio is the association confidence score. A ratio greater than 1 indicates that the probability of this combination occurring is higher than the average expectation, the closer to 1, the more consistent with the general expectation, and less than 1, the lower than the average expectation. In this way, the association confidence score reflects not only the absolute probability magnitude but also the significance relative to the global situation.

[0036] After calculating the association confidence scores for all software behavior feature datasets that meet the non-outlier threshold, the server performs a filtering process. The filtering is based on a preset confidence threshold. The confidence threshold is a critical value used to determine whether the association confidence score meets the standard. This threshold can be set based on the analysis of historical high-quality data, such as calculating a statistical quantile of historical data association confidence scores, like the 70th or 80th percentile, and setting that as the confidence threshold. Alternatively, a fixed empirical value can be set based on business experience, such as 0.3 or 0.5, depending on the strictness of data consistency requirements. The server compares the association confidence scores calculated for each software behavior feature dataset that meets the non-outlier threshold with this preset confidence threshold. The filtering rule is to retain datasets whose association confidence scores reach the confidence threshold. Reaching the confidence threshold means that the association confidence score of that dataset is greater than or equal to the confidence threshold. For example, if the confidence threshold is set to 0.4, a dataset with a correlation confidence of 0.545 will be retained, while a dataset with a correlation confidence of 0.2 will be discarded. Through this comparison operation, the server filters out all datasets whose correlation confidence reaches the confidence threshold; this set of datasets is called the confidence-reaching dataset. Each data point in the confidence-reaching dataset is considered to have high confidence in its combination of granularity label and terminal type, exhibiting good consistency with the system's prior knowledge, and is more suitable for subsequent granularity-based merging and analysis steps requiring high data consistency. Datasets that do not reach the confidence threshold may have weak or anomaly-related correlations between their granularity information and terminal type, and are therefore excluded from subsequent core analysis processes.

[0037] S5. Merge the confidence-compliant datasets according to granularity labels to obtain feature data groups of the same granularity. The specific implementation is as follows: After filtering the datasets that meet the confidence level criteria, the server obtains a collection of multiple independent datasets. Each dataset is a complete data unit, encapsulating the software behavior feature data collected from a specific card game terminal, along with associated metadata such as granularity tags and terminal type, which have been verified and evaluated in the aforementioned steps. At this point, the server needs to organize this data that has passed the reliability assessment to prepare for subsequent steps requiring comparison and analysis based on the same data precision. The purpose of this step is to group datasets with the same data collection precision together, eliminating interference that may be introduced during direct comparison due to differences in collection precision.

[0038] The server initiates the merge processing flow. First, the server reads all confidence-calibrated datasets from storage and loads them into a list or iterator structure in memory for sequential traversal. The server's processing program then visits each confidence-calibrated dataset in the list in turn. For the currently accessed confidence-calibrated dataset, the server needs to extract its key organizational basis, namely the granularity markers contained in the dataset. This extraction is performed by parsing the metadata of the dataset and reading the fields that record the collection granularity information. The value of this field is a specific granularity marker, which may be a string representing high-precision collection or a numerical code representing the precision level, such as 102. The server temporarily saves the overall content of the current dataset and the extracted granularity marker value.

[0039] To efficiently merge datasets with the same granularity label, the server typically creates and maintains an index structure in memory, such as a hash table or dictionary. In this hash table, the key is designed as the value of the granularity label, and the value is designed as a list to store all confidence-achieving datasets with the corresponding granularity label. The server's processing logic is as follows: after extracting the granularity label of the current dataset, it uses this granularity label value as the query key to query the existing hash table. If no entry with this granularity label value is found in the hash table, it means this is the first time a dataset with this granularity label has been encountered. The server creates a new entry in the hash table with the current granularity label value as the key and a newly created empty list as the value, then adds the current confidence-achieving dataset as an element to this new list. If an entry with this granularity label value is found in the hash table, the server directly retrieves the list corresponding to that key and appends the current confidence-achieving dataset to the end of this list.

[0040] After the server processes all the confidence-calibrated datasets according to this logic, the hash table structure in memory completely records the merged results of all datasets. Each key-value pair in the hash table represents a preliminary logical data group. Specifically, each key, a unique granularity tag, identifies a specific data collection precision level. Each value, a list of multiple confidence-calibrated datasets, contains all the data collected at that precision level. These lists are the prototype of the data groups with the same granularity. The server then solidifies these logical groups, for example, by assigning each list in the hash table an independent group identifier and associating all confidence-calibrated datasets in the list with that group identifier, or by serializing each list and all the datasets it contains and storing them as an independent persistent file or database record. Finally, the server outputs several data groups with the same granularity. The number of groups is equal to the number of different keys in the hash table, which is equal to the number of different granularity tags appearing in the confidence-calibrated datasets.

[0041] After the above merging operation, each resulting set of feature data with the same granularity shares a core common characteristic: every software behavior feature data point within the set has the exact same granularity label. The software behavior feature data referred to here is the original or preprocessed data body extracted from each confidence-compliant dataset, representing the actual operational behavior of the software, rather than the metadata encapsulation of the entire dataset. This commonality is guaranteed because the merging operation is based on the granularity label itself. For example, a set of feature data with the same granularity named the high-precision acquisition group might contain confidence-compliant datasets from dozens of different mobile and desktop terminals. Although the types of terminals from which these datasets originate may differ, the software behavior feature data they contain were all obtained under the specific mode of high-precision acquisition. Similarly, another set of feature data with the same granularity named the medium-precision acquisition group shares the medium-precision acquisition granularity attribute for all its software behavior feature data. This organizational approach ensures that the data used for comparison and calculation in subsequent quantitative calibration and correlation analysis steps are at a comparable accuracy scale, thus laying a consistent data foundation for accurately identifying anomalous behavior. After merging, the server outputs all generated feature data groups of the same granularity, while also recording the granularity label attributes of each group for subsequent identification and processing.

[0042] S6. Quantize and calibrate the feature data groups of the same granularity, and identify abnormal software behavior through correlation analysis of the quantized and calibrated feature data groups of the same granularity. The specific implementation is as follows: After constructing the same-granularity feature data sets, the server obtains several datasets with consistent internal data acquisition precision. Each set contains multiple software behavior feature data sets. Although these data sets have the same granularity label, they may exhibit subtle, non-essential differences in numerical range, baseline, or distribution patterns due to originating from different specific terminal devices, varying system background loads during acquisition, or minor environmental variations. To eliminate these non-essential differences that could affect the accuracy of subsequent correlation analysis, the server first performs quantization calibration on each set. The core objective of quantization calibration is to transform all software behavior feature data within each set to a unified and comparable quantization scale while maintaining the relative relationships and patterns between individuals within each set.

[0043] One specific quantitative calibration method is based on statistical feature standardization. For the current set of feature data of the same granularity to be processed, the server first needs to extract the overall statistical features of all software behavior feature data within the set. This includes traversing each piece of software behavior feature data within the set, which is typically represented as a sequence of feature vectors or a multidimensional feature matrix. The server calculates the global statistics of these feature data in each feature dimension, such as the minimum, maximum, arithmetic mean, and standard deviation of all data in a certain feature dimension. Taking the calculation of the arithmetic mean of a certain feature dimension as an example, the server sums the values ​​of all software behavior feature data in that feature dimension within the set of feature data of the same granularity, and then divides by the total number of software behavior feature data in the set to obtain the mean for that feature dimension. The standard deviation is calculated based on this mean; first, the square of the difference between each value and the mean is calculated, and then these squared values ​​are summed, averaged, and then the square root is taken.

[0044] After obtaining these statistics, the server performs a dimension-by-dimensional calibration transformation on each piece of software behavior feature data within the group. A commonly used transformation method is Z-score normalization. For the original value of a piece of software behavior feature data in a specific feature dimension, the server subtracts the previously calculated global arithmetic mean for that feature dimension from the original value. The difference is then divided by the global standard deviation for that feature dimension, and the result is the new value for that feature dimension after calibration. After this processing, the values ​​of all data in each feature dimension within the entire granularity feature data group are transformed into a distribution with a mean of 0 and a standard deviation of 1. Another method is max-min normalization, which involves subtracting the global minimum from the original value and then dividing by the difference between the global maximum and the global minimum, thus mapping the value to the interval between 0 and 1. Regardless of the specific method used, the quantization calibration process relies on and derives the transformation parameters from the data within the granularity feature data group itself, ensuring that the calibration process is adaptive. Furthermore, the calibrated data eliminates the incomparability caused by differences in the original units and scales, while preserving the pattern structure between the data. The calibrated set of features of the same granularity is called the quantized calibrated set of features of the same granularity.

[0045] The server performs correlation analysis on software behavior feature data based on a quantified and calibrated set of feature data of the same granularity. The purpose of correlation analysis is to discover connections, similarities, or anomalous deviations in behavioral patterns among multiple data sets within the same set. The server operates within a quantified and calibrated set of feature data of the same granularity. First, the server needs to calculate the correlation metric between different software behavior feature data. Here, different software behavior feature data refers to multiple independent data sets belonging to the same set but from different terminals or different time points. The correlation metric is an indicator used to quantify the strength of the linear or non-linear relationship between two sets of data.

[0046] A widely used correlation metric is the Pearson correlation coefficient. When calculating the Pearson correlation coefficient between two sets of software behavior feature data, the server treats each set of data as a multi-dimensional feature vector. The calculation process involves first calculating the covariance of the values ​​for each corresponding feature dimension of the two sets of data, which is the mean of the product of the corresponding dimension values ​​minus the product of their respective means. Since the data has been calibrated to a mean of 0, this calculation simplifies to the mean of the product of the corresponding dimension values. Then, the standard deviation of all feature values ​​for each set of data is calculated. The Pearson correlation coefficient is equal to the covariance between the two sets divided by the product of their standard deviations. The calculated correlation coefficient ranges from -1 to +1, where +1 indicates a perfect positive correlation, -1 indicates a perfect negative correlation, and 0 indicates no linear correlation. For a quantified and calibrated set of feature data of the same granularity, the server systematically calculates the Pearson correlation coefficient between every two different sets of software behavior feature data within it, thus obtaining a correlation coefficient matrix or a set of correlation coefficient values.

[0047] The server determines the results of the correlation analysis based on the distribution of a large number of calculated correlation measures. The server treats all calculated correlation measures within a group as a dataset and analyzes the statistical distribution characteristics of this dataset. For example, the server can calculate the mean and standard deviation of these correlation measures, or draw a histogram to observe the distribution shape. In a normal, undisturbed card game environment, the correlation measures of software behavior feature data from a large number of compliant terminals are expected to be concentrated around a typical value, for example, most correlation coefficients are between 0.7 and 0.9, exhibiting a relatively compact distribution. By analyzing this distribution, the server can set a threshold condition to determine whether the correlation is abnormal, i.e., the lower limit of correlation threshold. The specific method for setting this lower limit of correlation threshold can be based on the principle of statistical outlier detection. For example, the server calculates the first quartile Q1 and the third quartile Q3 of all correlation measures, and then calculates the interquartile range IQR = Q3 - Q1. The server sets the lower limit of correlation threshold to Q1 - k × IQR, where k is an adjustable multiplier factor, for example, k can be 1.5. The server compares each calculated Pearson correlation coefficient with this lower correlation threshold. Any correlation coefficient below this threshold indicates that the corresponding pair of software behavioral feature data is considered to have a significantly weaker correlation than the mainstream level within the group.

[0048] The server identifies anomalous software behavior based on the results of correlation analysis. Specifically, the correlation analysis identifies data pairs that exhibit significant anomalies in the correlation metric distribution. The server marks these anomalous data as suspicious based on predefined rules. For example, if the correlation coefficient of a data pair is below the aforementioned lower correlation threshold, the pair is marked as a weakly correlated anomalous pair. The server can further analyze this; if the correlation coefficient between a software behavior feature data and most other data within the group is below the lower correlation threshold, then that data itself is identified as a candidate for anomalous software behavior. Alternatively, the server can combine the analysis results of multiple quantitatively calibrated feature data groups of the same granularity. If a terminal exhibits anomalous correlations across multiple different granularity groups, the confidence level in determining that the terminal exhibits anomalous software behavior is higher. The server outputs all these identified data with anomalous correlation patterns, or the corresponding terminals, as anomalous software behavior identification result, and can trigger corresponding security measures, such as generating security alerts, logging, or initiating terminal control procedures. The entire identification process is based on data that has undergone strict granularity unification and quantitative calibration, ensuring the sensitivity and accuracy of the analysis results to real abnormal behaviors.

[0049] Example 2: Figure 2A schematic diagram of the abnormal software behavior remote identification system for multiplayer game terminals of the present invention is provided. The abnormal software behavior remote identification system for multiplayer game terminals includes: The data collection and labeling module is used to synchronously record the collection granularity information and bind and generate a software behavior feature dataset with granular labels when collecting software behavior feature data from the card and board game terminal. The transmission verification module is used to remotely transmit the software behavior feature dataset to the server, and the server verifies the data integrity and the validity of the granular labeling. The cluster filtering module is used by the server to classify the verified software behavior feature datasets by terminal type, fit the probability distribution of the collection granularity label of each type of terminal, calculate the local outlier factor of the collection granularity label of a single terminal in its own cluster, and filter out the software behavior feature datasets that meet the non-outlier threshold. The confidence filtering module is used to construct a prior distribution based on the probability distribution of the collection granularity labels of various terminals, calculate the association confidence of the granularity labels of software behavior feature datasets that meet the non-outlier threshold with the terminal type, and filter the datasets that meet the confidence threshold. The merge grouping module is used to merge confidence-compliant datasets according to granularity to obtain feature data groups of the same granularity. The calibration and identification module is used to quantize and calibrate feature data groups of the same granularity, and to identify abnormal software behavior through correlation analysis of the quantized and calibrated feature data groups of the same granularity.

[0050] All calculations involved in the embodiments are dimensionless numerical calculations, and the preset parameters and thresholds in the calculations are set by those skilled in the art according to the actual situation.

[0051] It should be noted that this invention can be deployed on the device itself to realize embedded applications, or it can run on a PC or other terminal with a user interface, thereby meeting various hardware environments and usage requirements.

[0052] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions according to the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. Computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wireless or wired transmission; wired transmission methods include optical fiber, twisted pair, coaxial cable, etc.; wireless transmission includes infrared, microwave, etc. Computer-readable storage media can be any available medium that a computer can access or a data storage device such as a server or data center that contains one or more sets of available media. Available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media. Semiconductor media can be solid-state drives.

[0053] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and modules described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0054] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0055] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0056] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

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

[0058] The above are merely specific embodiments 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.

[0059] In conclusion, the above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for remotely identifying abnormal software behavior in multiplayer game terminals, characterized in that: include: S1. When the card and board game terminal collects software behavior feature data, it synchronously records the collection granularity information and binds it to generate a software behavior feature dataset with granularity labels. S2. Remotely transmit the software behavior feature dataset to the server, and the server verifies the data integrity and the validity of the granular labeling. S3. The server classifies the verified software behavior feature datasets by terminal type, fits the probability distribution of the collection granularity label of each type of terminal, calculates the local outlier factor of the collection granularity label of a single terminal in its own cluster, and filters out the software behavior feature datasets that meet the non-outlier threshold. S4. Construct a prior distribution based on the probability distribution of the collection granularity label of various terminals, calculate the association confidence of the granularity label of the software behavior feature dataset that meets the non-outlier threshold with the terminal type, and filter the dataset that meets the confidence standard. S5. Merge the confidence-compliant datasets according to granularity labels to obtain feature data groups of the same granularity; S6. Quantize and calibrate feature data groups of the same granularity, and identify abnormal software behavior through correlation analysis of the quantized and calibrated feature data groups of the same granularity.

2. The method for remote identification of abnormal software behavior in multiplayer game terminals according to claim 1, characterized in that, S1 includes: Collect behavioral characteristic data generated by the software during the operation of the card and board game terminal; The granularity of data collection is determined based on the data collection environment of behavioral feature data. The collected granularity information is used as a granularity label and bound to the collected behavioral feature data to generate a software behavioral feature dataset with granularity labels.

3. The remote identification method for abnormal software behavior of multiplayer game terminals according to claim 1, characterized in that, S2 include: The software behavior feature dataset with granular labels is remotely transmitted from the chess and card game terminal to the server. After receiving the software behavior feature dataset with granular labels, the server performs data integrity verification on the software behavior feature dataset with granular labels. The format and content validity of the granular tags in the software behavior feature dataset with granular tags are validated.

4. The method for remote identification of abnormal software behavior in multiplayer game terminals according to claim 1, characterized in that, S3 includes: Based on the terminal types corresponding to the verified software behavior feature dataset, cluster classification is performed to obtain several terminal clusters. For each terminal cluster, a probability distribution of the collected granular labels is fitted based on the granular labels in all verified software behavior feature datasets within it. For each verified software behavior feature dataset, the local outlier factor is calculated based on the position of its granularity label in the probability distribution of the granularity label of the terminal cluster to which it belongs. Based on a preset non-outlier threshold, local outlier factors are compared with the non-outlier threshold to select software behavior feature datasets whose local outlier factors do not exceed the non-outlier threshold.

5. The remote identification method for abnormal software behavior of multiplayer game terminals according to claim 4, characterized in that, Based on the position of its granularity label in the probability distribution of the acquisition granularity label of its terminal cluster, the local outlier factor is calculated. Specifically, this includes: determining the probability density of the granularity label of the verified software behavior feature dataset in the probability distribution of the acquisition granularity label of its terminal cluster; and calculating the local outlier factor by comparing the probability density with the probability density of its neighboring region in the probability distribution of the acquisition granularity label.

6. The remote identification method for abnormal software behavior of multiplayer game terminals according to claim 1, characterized in that, S4 include: Based on the probability distribution of collection granularity labels of various terminals, a prior distribution characterizing the relationship between granularity labels and terminal types is constructed. For each software behavior feature dataset that meets the non-outlier threshold, the association confidence is calculated based on its granularity label and terminal type, combined with the prior distribution. The association confidence level is compared with a preset confidence threshold, and the datasets whose association confidence level reaches the confidence threshold are selected as the confidence-compliant datasets.

7. The remote identification method for abnormal software behavior of multiplayer game terminals according to claim 1, characterized in that, S5 include: Based on the granularity labels contained in the confidence score calibrated datasets, confidence score calibrated datasets with the same granularity labels are merged into the same set to form several feature data groups with the same granularity. Within each granularity feature data group, the software behavior feature data have the same granularity label.

8. The method for remote identification of abnormal software behavior in multiplayer game terminals according to claim 1, characterized in that, S6 include: Quantitative calibration processing is performed on software behavior feature data within the same granularity feature data group; Based on the quantified and calibrated feature data set of the same granularity, we conduct correlation analysis among software behavior feature data. Based on the results of correlation analysis, abnormal software behavior was identified.

9. The method for remote identification of abnormal software behavior in multiplayer game terminals according to claim 8, characterized in that, Based on the quantized and calibrated same-granularity feature data set, a correlation analysis is performed between software behavior feature data. Specifically, this includes: calculating the correlation measure between different software behavior feature data within the quantized and calibrated same-granularity feature data set; and determining the results of the correlation analysis based on the distribution of the correlation measure to identify abnormal software behavior.

10. A remote identification system for abnormal software behavior on multiplayer game terminals, used to implement the remote identification method for abnormal software behavior on multiplayer game terminals as described in any one of claims 1-9, characterized in that, include: The data collection and labeling module is used to synchronously record the collection granularity information and bind and generate a software behavior feature dataset with granular labels when collecting software behavior feature data from the card and board game terminal. The transmission verification module is used to remotely transmit the software behavior feature dataset to the server, and the server verifies the data integrity and the validity of the granular labeling. The cluster filtering module is used by the server to classify the verified software behavior feature datasets by terminal type, fit the probability distribution of the collection granularity label of each type of terminal, calculate the local outlier factor of the collection granularity label of a single terminal in its own cluster, and filter out the software behavior feature datasets that meet the non-outlier threshold. The confidence filtering module is used to construct a prior distribution based on the probability distribution of the collection granularity labels of various terminals, calculate the association confidence of the granularity labels of software behavior feature datasets that meet the non-outlier threshold with the terminal type, and filter the datasets that meet the confidence threshold. The merge grouping module is used to merge confidence-compliant datasets according to granularity to obtain feature data groups of the same granularity. The calibration and identification module is used to quantize and calibrate feature data groups of the same granularity, and to identify abnormal software behavior through correlation analysis of the quantized and calibrated feature data groups of the same granularity.

Images