An AI-based game vulnerability automatic detection method and system
By using an AI-based automatic game vulnerability detection method, player action sequences are analyzed in real time to identify and fix game vulnerabilities, solving the problem of inaccurate vulnerability detection in existing technologies and improving the stability and security of game operations.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- SHANGHAI XUANJI NETWORK TECH CO LTD
- Filing Date
- 2025-12-25
- Publication Date
- 2026-07-31
AI Technical Summary
Existing technologies are insufficient to effectively detect and fix vulnerabilities triggered by players in games, leading to instability in game operations and disruption of game balance.
An AI-based automatic vulnerability detection method for games is adopted. By collecting error information, analyzing the error time and type, retrieving operation sequences and comparing them with historical sequences, the conditions that trigger vulnerabilities are identified, and vulnerability warning information or blocking patches are generated to fix the vulnerabilities.
It improves the accuracy of vulnerability detection and the stability of game operation, reduces the frequency of vulnerability triggering, and enhances the game's balance and security.
Smart Images
Figure CN121902158B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of game management, and in particular to an AI-based method and system for automatic detection of game vulnerabilities. Background Technology
[0002] Game vulnerabilities refer to defects that occur during the design, development, testing, or deployment of a game, which may lead to abnormal game logic, functional failure, data leakage, security risks, or unfairness, ultimately affecting the player experience or the security of game operations.
[0003] In existing technologies, tools or scripts are generally used to quickly scan large amounts of code, resources, or runtime data for automatic verification to identify vulnerabilities that are "highly repetitive and have clearly defined rules." In addition, manual verification is performed by testers or experts to identify vulnerabilities that are "logically complex and dependent on specific scenarios," thereby reducing the number of vulnerabilities in the game.
[0004] Everyone has different gaming habits, and players are prone to triggering vulnerabilities that are not automatically or manually verified during gameplay. As a result, vulnerabilities appear as the game progresses, which in turn disrupts the game's balance. Summary of the Invention
[0005] To improve the stability of game operation and detect vulnerabilities triggered by players in a timely manner, this invention provides an AI-based automatic game vulnerability detection method and system.
[0006] Firstly, the present invention provides an AI-based automatic detection method for game vulnerabilities, employing the following technical solution: An AI-based automatic detection method for game vulnerabilities includes: Step 100: Collect error information; Step 101: Determine the error time in response to the error message, and determine the error type in response to the error message; Step 102: Select the error duration according to the error type; Step 103: Determine the error reporting period based on the error reporting time and duration; Step 104: Retrieve the operation sequence based on the error reporting period and retrieve the historical sequence based on the error reporting type; Step 105: Determine the error sequence based on the operation sequence and the historical sequence, and define the operation sequence as the historical sequence; Step 106: In response to the error sequence, generate and display vulnerability warning information.
[0007] By adopting the above technical solution, game vulnerability error messages can be detected in real time. When a vulnerability error occurs in the game, the player's operation process before the error occurs can be retrieved and compared with the operation process of other players at the same time. This identifies the operations that are likely to trigger the error message, i.e. the conditions that trigger the player to trigger the vulnerability, thereby improving the accuracy of vulnerability detection and improving the stability of game operation.
[0008] Optional, also includes: Step 107: Determine the error coordinates in response to the error message; Step 108: Retrieve the comparison sequence based on the reported error coordinates; Step 109: Determine the overlapping sequence by combining the comparison sequence and the error sequence; Step 110: Delete the overlapping sequences contained in the error sequence.
[0009] By adopting the above technical solution, when the game reports an error, the operation process of other players in the same position who did not trigger the error is retrieved, and then compared with the operation process that triggered the vulnerability, so as to extract the key operation steps that triggered the vulnerability, thereby improving the accuracy of vulnerability detection.
[0010] Optional, also includes: Step 111: Determine the verification process by combining the error coordinates and error sequence; Step 112: Perform verification at the error coordinates according to the verification process and collect verification information; Step 113: When the verification information and the error information are inconsistent, a verification sequence is generated in response to the overlapping sequence and the error sequence; Step 114: Update the verification process based on the verification sequence.
[0011] By adopting the above technical solution, once the conditions for triggering the vulnerability are identified, the operation is performed according to the conditions to simulate the player's triggering of the vulnerability, thereby verifying whether the conditions for triggering the vulnerability are accurate. If the vulnerability is not triggered according to the operation, the operation steps are added one by one according to the player's operation process to verify the accurate conditions for triggering the vulnerability and improve the accuracy of vulnerability detection.
[0012] Optionally, it also includes a vulnerability handling method, which includes: Step 200: When the verification information matches the error information, determine the operation area based on the verification sequence and the error coordinates; Step 201: Determine the blocking area in response to the operating area; Step 202: Generate a blocking patch based on the blocked area; Step 203: Fix the game according to the blocking patch to prevent players from approaching the vulnerability, and generate and display vulnerability patching information according to the blocking patch.
[0013] By adopting the above technical solution, when a vulnerability is triggered after operating according to the conditions for triggering the vulnerability, it is determined that the vulnerability can be triggered stably. At this time, a patch is generated to prevent players from entering the area where the vulnerability can be triggered, thereby reducing the possibility of the vulnerability being triggered again and improving the stability of game operation.
[0014] Optionally, the vulnerability handling method further includes: Step 204: When the verification information matches the error message, retrieve the player information based on the error message; Step 205: Determine the number of errors based on the player information and error type; Step 206: If the number of error reports is greater than a preset high-frequency threshold, determine the player's coordinates based on the player information; Step 207: Determine the vulnerability distance based on the player's coordinates and the error report coordinates; Step 208: Generate and display vulnerability trigger warnings based on the vulnerability distance and the number of error reports.
[0015] By adopting the above technical solution, when a player frequently triggers the same vulnerability, it is determined that the player's gameplay is more likely to trigger the vulnerability. At this time, the distance between the player and the location where the vulnerability is triggered is detected, and the player is reminded to move away when he gets close to the location where the vulnerability is triggered, so as to reduce the situation where the player repeatedly triggers the vulnerability.
[0016] Optionally, the vulnerability handling method further includes: Step 209: If the number of error reports exceeds a preset high-frequency threshold, retrieve the game sequence from the player information; Step 210: Determine the repetition frequency based on the verification sequence and the game sequence, and determine the number of times the vulnerability is traversed based on the vulnerability distance; Step 211: Calculate the quotient of the number of errors and the number of passes, and define it as the pass frequency; Step 212: Calculate the difference between the passing frequency and the repetition frequency, and define it as the frequency difference value; Step 213: When the frequency difference is higher than a preset active threshold, determine the amplification factor in response to the frequency difference; Step 214: Determine the expansion area based on the expansion coefficient and the blocking area; Step 215: Update the blocking patch based on the expanded area.
[0017] By adopting the above technical solution, when a player frequently triggers the same vulnerability, the system compares the player's normal gameplay with their actions near the vulnerability's location to determine if the player is intentionally triggering the vulnerability. If the player frequently performs actions that trigger the vulnerability near its location, it is determined that the player is intentionally triggering the vulnerability. In this case, the patch's scope is expanded to prevent the player from approaching the vulnerability's area, thereby reducing the likelihood of players intentionally triggering the vulnerability and improving the stability of game operations.
[0018] Optionally, the vulnerability handling method further includes: Step 216: When the frequency difference is higher than a preset active threshold, determine the playtime based on the player information; Step 217: Determine the player group in response to the stated playtime; Step 218: Determine the base frequency based on the player group; Step 219: If the passing frequency is higher than the reference frequency, update the blocking patch based on the expanded area.
[0019] By adopting the above technical solution, players' operations tend to change with the length of playtime. The longer the playtime, the more stable the operation becomes. When players frequently trigger conditions near the location of the vulnerability, the player's playtime is detected. Thus, when the player's playtime is short, it is determined that the vulnerability is caused by the player's operation habits. In this case, no patch is used to block new players with short playtime.
[0020] Optionally, a similar vulnerability detection method may also be included, wherein the similar vulnerability detection method includes: Step 300: When the verification information matches the error information, acquire the error image based on the error coordinates, and retrieve the historical image based on the error coordinates; Step 301: Compare the reported error image with historical images to determine the error characteristics; Step 302: Determine the feature similarity by combining the error report features and the preset game model; Step 303: Determine the error probability based on feature similarity; Step 304: In response to the error probability, generate and display a vulnerability risk warning.
[0021] By adopting the above technical solution, when the vulnerability can be triggered reliably, the images before and after the vulnerability are compared to determine the changes in appearance after the vulnerability is triggered. This allows us to check if there are similar locations in the game, and if the similarity is high, we can determine that there may be a vulnerability in that location and promptly notify staff to check if there is a vulnerability.
[0022] Optionally, the similar vulnerability detection method further includes: Step 305: When the error probability is greater than the preset risk threshold, retrieve the verification log based on the verification process, and determine the risk coordinates based on the error probability; Step 306: Determine the risk process by combining the risk coordinates and verification sequence; Step 307: Verify the risk process at the risk coordinates and retrieve the risk log based on the risk coordinates; Step 308: Determine the logical similarity by combining the verification log and the risk log; Step 309: If the logical similarity is greater than the preset vulnerability threshold, update the vulnerability warning information in response to the risk coordinates.
[0023] By adopting the above technical solution, when there may be vulnerabilities in other locations, the system will operate according to the conditions that trigger the vulnerability and compare the game logs. If the game logs are similar, it will be determined that there is a vulnerability in that location, and staff will be notified in a timely manner to reduce vulnerabilities.
[0024] Secondly, this application provides an AI-based automatic game vulnerability detection system, which adopts the following technical solution: An AI-based automatic game vulnerability detection system includes: The data acquisition module is used to collect error messages, verification information, and error images. The memory is used to store the program for any of the above-mentioned AI-based automatic game vulnerability detection methods; The processor is the unit of memory that allows programs to be loaded and executed by the processor.
[0025] By adopting the above technical solution, game vulnerability error messages can be detected in real time. When a vulnerability error occurs in the game, the player's operation process before the error occurs can be retrieved and compared with the operation process of other players at the same time. This identifies the operations that are likely to trigger the error message, i.e. the conditions that trigger the player to trigger the vulnerability, thereby improving the accuracy of vulnerability detection and improving the stability of game operation.
[0026] In summary, this application includes at least one of the following beneficial technical effects: 1. Real-time detection of game vulnerability error messages allows for the retrieval of player actions prior to the error message when a vulnerability occurs, and comparison with the actions of other players at the same time. This identifies actions that are likely to trigger the error message, i.e., the conditions that trigger a player to exploit the vulnerability, thereby improving the accuracy of vulnerability detection and enhancing the stability of game operation. 2. When the game reports an error, retrieve the operation process of other players in the same location who did not trigger the error, compare it with the operation process that triggered the vulnerability, extract the key operation steps that triggered the vulnerability, and thus improve the accuracy of vulnerability detection; 3. Once the conditions for triggering the vulnerability are identified, the system simulates the player's vulnerability triggering scenario by performing actions according to those conditions. This verifies the accuracy of the vulnerability triggering conditions. If the vulnerability is not triggered by performing the actions, the system adds steps according to the player's actions to verify the accurate triggering conditions and improve the accuracy of vulnerability detection. Attached Figure Description
[0027] Figure 1 This is a flowchart of an AI-based automatic game vulnerability detection method; Figure 2 This is a flowchart of the vulnerability handling method; Figure 3 This is a flowchart of a similar vulnerability detection method. Detailed Implementation
[0028] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.
[0029] Reference Figure 1 This application discloses an AI-based automatic detection method for game vulnerabilities, including: Step 100: Collect error information.
[0030] Error messages refer to information generated by the system when a player triggers a vulnerability in the game. Generally, the type and effect of the vulnerability are determined by the error message. Error messages can be retrieved from the game's operating system. The method for collecting error messages is selected by the staff based on the actual situation, and will not be elaborated here.
[0031] Step 101: Determine the error time in response to the error message, and determine the error type in response to the error message.
[0032] Error reporting time refers to the moment when the system issues an error message, that is, the moment when the player triggers the vulnerability. The method for determining error reporting time is common knowledge among those in the field and will not be elaborated here.
[0033] Error type refers to the type of vulnerability, such as functional logic vulnerability, security vulnerability, fairness vulnerability, and performance and compatibility vulnerability. The method for determining the error type is common knowledge to those in the field and will not be elaborated here.
[0034] Step 102: Select the error duration according to the error type.
[0035] Error duration refers to the shortest time after a vulnerability is triggered to take effect. For example, functional logic vulnerabilities such as abnormal skill damage calculation are generally triggered immediately. The error duration corresponding to the error type can be found in the duration correspondence table, which is a data table that records different error types and their corresponding error durations.
[0036] Step 103: Determine the error reporting period based on the error reporting time and error reporting duration.
[0037] The error reporting period refers to the time period during which a player performs an action that triggers the vulnerability. That is, the time period ending at the error reporting time and the length of the error reporting duration. The method for determining the error reporting period is common knowledge among those in the field and will not be elaborated here.
[0038] Step 104: Retrieve the operation sequence based on the error reporting period and retrieve the historical sequence based on the error reporting type.
[0039] The operation sequence refers to the order in which a player performs actions within the error reporting time, such as the order of skill release and movement. The operation sequence can be retrieved from the game system. The method of retrieving the operation sequence is common knowledge to those in the field and will not be elaborated here.
[0040] The historical sequence refers to the sequence of actions taken by other players when they triggered vulnerabilities of the same error type. The historical sequence corresponding to the error type can be retrieved from the historical data table, which is a data table that records different error types and their corresponding historical sequences.
[0041] Step 105: Determine the error sequence based on the operation sequence and the historical sequence, and define the operation sequence as the historical sequence.
[0042] Error sequence refers to the possible sequence of operations that triggers a vulnerability, that is, the same sequence of operations in the operation sequence and the historical sequence. When there are multiple identical operation sequences, the longest one is selected as the historical sequence. The method for determining the historical sequence is common knowledge to those in the field and will not be elaborated here.
[0043] Step 106: In response to the error sequence, generate and display vulnerability warning information.
[0044] Vulnerability alerts are information used to notify staff of the reasons for triggering vulnerabilities. The methods for generating vulnerability alerts are common knowledge in the field and will not be elaborated here.
[0045] Real-time detection of game vulnerability error messages allows for the retrieval of player actions prior to the error and comparison with the actions of other players at the same time. This identifies actions that are likely to trigger the error message, i.e., the conditions that trigger a player to exploit the vulnerability, thereby improving the accuracy of vulnerability detection and enhancing the stability of game operations.
[0046] An AI-based automatic game vulnerability detection method also includes: Step 107: Determine the error coordinates in response to the error message.
[0047] Error coordinates refer to the player's location in the game when the vulnerability is triggered. The method for determining error coordinates is common knowledge among those in the field and will not be elaborated here.
[0048] Step 108: Retrieve the comparison sequence based on the reported error coordinates.
[0049] The comparison sequence refers to the sequence of actions performed by other players who have not triggered the vulnerability near the error coordinates. The sequence of actions performed by players who have not triggered the vulnerability within a certain area near the error coordinates can be retrieved as the comparison sequence. The method for retrieving the comparison sequence is common knowledge to those in the field and will not be elaborated here.
[0050] Step 109: Determine the overlapping sequence by combining the comparison sequence and the error sequence.
[0051] Overlapping sequences refer to the same operation order in the comparison sequence and the error sequence. When there are multiple identical operation orders, the longest operation order is selected as the overlapping sequence. The method for determining overlapping sequences is common knowledge in the field and will not be elaborated here.
[0052] Step 110: Delete the overlapping sequences contained in the error sequence.
[0053] When a game error occurs, the system retrieves the actions of other players in the same location who did not trigger the error. This process is then compared with the actions that triggered the vulnerability to extract the key steps that triggered it, thereby improving the accuracy of vulnerability detection.
[0054] An AI-based automatic game vulnerability detection method also includes: Step 111: Determine the verification process by combining the error coordinates and error sequence.
[0055] The verification process refers to the process of performing operations according to the error sequence at the error coordinates to verify the vulnerability. The method for determining the verification process is common knowledge to those in the field and will not be elaborated here.
[0056] Step 112: Perform verification at the error coordinates according to the verification process and collect verification information.
[0057] Verification information refers to the error messages generated by the system after the operation is performed according to the verification process. The method for collecting verification information can refer to the error message collection method in step 100 above, and will not be repeated here.
[0058] Step 113: When the verification information is inconsistent with the error information, a verification sequence is generated in response to the overlapping sequence and the error sequence.
[0059] Inconsistency between verification information and error messages indicates that the corresponding vulnerability cannot be triggered according to the error sequence, meaning the error sequence is inaccurate. The verification sequence refers to the order of operations formed by restoring the error sequence one by one from the overlapping sequences. Generally, the error sequence is restored starting from a few steps. That is, first, one operation step from the overlapping sequence is selected and restored to its original position in the error sequence, and then two operation steps from the overlapping sequence are selected and restored to their original positions in the error sequence. The method for determining the verification sequence is common knowledge to those in the field and will not be elaborated here.
[0060] Step 114: Update the verification process based on the verification sequence.
[0061] Once the conditions for triggering a vulnerability are identified, actions are performed according to these conditions to simulate a player triggering the vulnerability, thereby verifying the accuracy of the triggering conditions. If the vulnerability is not triggered by following the actions, additional steps are added according to the player's actions to verify the accurate triggering conditions and improve the accuracy of vulnerability detection.
[0062] Reference Figure 2 Vulnerability handling methods include: Step 200: When the verification information matches the error information, determine the operation area based on the verification sequence and the error coordinates.
[0063] If the verification information and the error message are consistent, it means that the vulnerability can be triggered reliably in a fixed operation sequence. At this time, it is necessary to prevent the player from continuing to trigger the vulnerability. The operation area is the area that the player passes through when triggering the vulnerability by operating according to the verification sequence. The method for determining the operation area is common knowledge to those in the field and will not be elaborated here.
[0064] Step 201: Determine the blocking area in response to the operating area.
[0065] The blocking area refers to the area where players are prevented from entering in order to reduce the occurrence of vulnerabilities. Generally, the smallest circumscribed cuboid of the operating area is used as the blocking area. The method for determining the blocking area is common knowledge among those in the field and will not be elaborated here.
[0066] Step 202: Generate a blocking patch based on the blocking area.
[0067] A blocking patch is a command in the game to set a blocked area that players cannot enter, or even a "visible wall". The method for generating blocking patches is chosen by the staff based on the actual situation, and will not be elaborated here.
[0068] Step 203: Fix the game according to the blocking patch to prevent players from approaching the vulnerability, and generate and display vulnerability patching information according to the blocking patch.
[0069] Vulnerability patching information refers to information used to notify staff to block patches. The method for generating vulnerability patching information is common knowledge to those in the field and will not be elaborated here.
[0070] When a vulnerability is triggered by following the conditions for triggering it, it is determined that the vulnerability can be triggered reliably. At this time, a patch is generated to prevent players from entering areas where the vulnerability can be triggered, thereby reducing the possibility of the vulnerability being triggered again and improving the stability of game operation.
[0071] Vulnerability handling methods also include: Step 204: When the verification information matches the error message, retrieve the player information based on the error message.
[0072] Player information refers to the in-game activity records of the player who triggered the vulnerability. Player information generally includes the sequence of actions, vulnerability triggering information, the player's coordinates in the game, and the player's playtime. The method for retrieving player information is selected by the staff based on the actual situation and will not be elaborated here.
[0073] Step 205: Determine the number of errors based on the player information and error type.
[0074] The number of error reports refers to the number of times a player triggers the same vulnerability. The method for determining the number of error reports is selected by the staff based on the actual situation, and will not be elaborated here.
[0075] Step 206: If the number of error reports is greater than a preset high-frequency threshold, determine the player's coordinates based on the player information.
[0076] The high-frequency threshold refers to the minimum number of times a player can repeatedly trigger a vulnerability. A value of 5 is typically used. The high-frequency threshold is selected by staff based on actual circumstances and will not be elaborated upon here. An error count exceeding the high-frequency threshold indicates that the player is frequently triggering the same vulnerability, suggesting the player is likely to exploit it. Player coordinates refer to the player's location within the game. The method for determining player coordinates is common knowledge within this field and will not be elaborated upon here.
[0077] Step 207: Determine the vulnerability distance based on the player's coordinates and the error report coordinates.
[0078] Vulnerability distance refers to the distance between a player and the location where a vulnerability is triggered. The method for determining vulnerability distance is common knowledge among those in the field and will not be elaborated here.
[0079] Step 208: Generate and display vulnerability trigger warnings based on the vulnerability distance and the number of error reports.
[0080] A vulnerability trigger warning is a message used to warn players that they are approaching a vulnerability trigger location. The method for determining a vulnerability trigger warning is common knowledge in the field and will not be elaborated here.
[0081] When a player frequently triggers the same vulnerability, it is determined that the player's gameplay is more likely to trigger the vulnerability. At this time, the distance between the player and the location where the vulnerability is triggered is detected, and the player is reminded to move away when he gets close to the location where the vulnerability is triggered in order to reduce the situation where the player repeatedly triggers the vulnerability.
[0082] Vulnerability handling methods also include: Step 209: If the number of error reports is greater than a preset high-frequency threshold, retrieve the game sequence from the player information.
[0083] The game sequence refers to the order in which a player performs all their actions in the game. The game sequence can be obtained by retrieving the player's action sequence from the player's information over the past week. The method for determining the game sequence is selected by the staff based on the actual situation and will not be elaborated here.
[0084] Step 210: Determine the repetition frequency based on the verification sequence and the game sequence, and determine the number of times the vulnerability is passed based on the vulnerability distance.
[0085] The repetition frequency refers to the frequency of the verification sequence appearing in the game sequence. It is calculated by counting the number of times the verification sequence is repeated in the game sequence, and then calculating the repetition coefficient and the quotient of the playtime in the most recent week. The calculation method of the repetition frequency is selected by the staff according to the actual situation, and will not be elaborated here.
[0086] The number of times a player passes through an error-reported coordinate refers to the number of times the player passes through the coordinates. All the player's vulnerability distances can be retrieved, and a passing count is added when the vulnerability distance is lower than the proximity threshold. The method for determining the number of passings and the proximity threshold can be selected by the staff according to the actual situation, which will not be elaborated here.
[0087] Step 211: Calculate the quotient of the number of errors and the number of passes, and define it as the pass frequency.
[0088] Passage frequency refers to the percentage of times a player triggers a vulnerability when passing through the error-reporting coordinates. The calculation method for passage frequency is common knowledge among those in the field and will not be elaborated here.
[0089] Step 212: Calculate the difference between the passing frequency and the repetition frequency, and define it as the frequency difference value.
[0090] Frequency difference is a value used to show the player's initiative in triggering the vulnerability. The higher the frequency, the more likely the player is to trigger the vulnerability when passing through the error coordinate. The lower the repetition frequency, the less often the player performs verification sequences during gameplay. Therefore, the higher the frequency difference, the more actively the player performs verification sequences to trigger the vulnerability when passing through the error coordinate.
[0091] Step 213: When the frequency difference is higher than a preset active threshold, determine the amplification coefficient in response to the frequency difference.
[0092] The active threshold refers to the frequency difference used to determine the player's initiative in triggering the vulnerability. The active threshold is selected by the staff based on the actual situation and will not be elaborated here. A frequency difference higher than the active threshold indicates that the player has actively triggered the vulnerability, and the player is suspected of exploiting the vulnerability. The amplification factor refers to the multiplier used to amplify the blocked area. The larger the frequency difference, the larger the amplification factor is used. The amplification factor corresponding to the frequency difference can be found in the amplification correspondence table, which is a data table that records different frequency differences and their corresponding amplification factors.
[0093] Step 214: Determine the expansion area based on the expansion coefficient and the blocking area.
[0094] The expanded region refers to the region after the blocking region is enlarged according to the expansion factor. The method for determining the expanded region is common knowledge among those in the field and will not be elaborated here.
[0095] Step 215: Update the blocking patch based on the expanded area.
[0096] When a player frequently triggers the same vulnerability, the system compares the player's normal gameplay with their actions near the vulnerability's location to determine if the player is intentionally triggering the vulnerability. If the player frequently triggers the vulnerability near its location, it is determined that the player is intentionally triggering the vulnerability. In this case, the patch's scope is expanded to prevent the player from approaching the vulnerability-triggered area, thereby reducing the likelihood of players intentionally triggering the vulnerability and improving the stability of game operations.
[0097] Vulnerability handling methods also include: Step 216: When the frequency difference is higher than the preset active threshold, determine the playtime based on the player information.
[0098] Playtime refers to the total time a player spends playing a game. The method for determining playtime is common knowledge among those in the field and will not be elaborated here.
[0099] Step 217: Determine the player group in response to the stated playtime.
[0100] Player groups refer to categories of players based on their playtime. For example, players with less than 20 hours of playtime are classified as new players, players with 20 to 50 hours of playtime are classified as regular players, and players with more than 50 hours of playtime are classified as veteran players. The longer the playtime, the more similar the players' actions tend to be. The method for determining player groups is chosen by the staff based on the actual situation and will not be elaborated here.
[0101] Step 218: Determine the base frequency based on the player group.
[0102] The baseline frequency refers to the maximum frequency at which players within a player group trigger vulnerabilities. The baseline frequency corresponding to a player group can be found in the baseline correspondence table, which is a data table that records different player groups and their corresponding baseline frequencies.
[0103] Step 219: If the passing frequency is higher than the reference frequency, update the blocking patch based on the expanded area.
[0104] A frequency higher than the baseline frequency indicates that the player is triggering the vulnerability more frequently. In this case, it is necessary to prevent the player from approaching the error coordinates to reduce the chances of the vulnerability being triggered.
[0105] Players' actions tend to change with playtime; the longer the playtime, the more stable the actions become. When a player frequently triggers conditions near the location where a vulnerability is triggered, the player's playtime is checked. If a player's playtime is short, the vulnerability is determined to be caused by the player's playtime habits. In this case, no patch is used to block new players with short playtime.
[0106] Reference Figure 3 Similar vulnerability detection methods include: Step 300: When the verification information matches the error information, acquire the error image based on the error coordinates, and retrieve the historical image based on the error coordinates.
[0107] Error images refer to the visual images showing the coordinates of the error when the vulnerability is triggered. The method for collecting error images is selected by the staff based on the actual situation and will not be elaborated here.
[0108] Historical images refer to the appearance images of the error coordinates when the vulnerability is not triggered. The historical images corresponding to the error coordinates can be found from the image correspondence table, which is a data table that records different error coordinates and their corresponding historical images.
[0109] Step 301: Compare the error image with historical images to determine error characteristics.
[0110] Error characteristics refer to the changes in appearance after an error coordinate triggers a vulnerability. Error characteristics can be determined through image recognition technology. The method for determining error characteristics is common knowledge to those in the field and will not be elaborated here.
[0111] Step 302: Determine the feature similarity by combining the error report features and the preset game model.
[0112] Game models refer to the 3D model data within the game. Game models can be retrieved from the game's operating system. The method for retrieving game models is selected by the staff based on the actual situation and will not be elaborated here.
[0113] Feature similarity refers to the degree of similarity between the appearance of other locations in the game and the error report feature. Feature similarity can be determined through image recognition technology. The method for determining feature similarity is common knowledge to those in the field and will not be elaborated here.
[0114] Step 303: Determine the error probability based on feature similarity.
[0115] Error reporting probability refers to the probability of a vulnerability existing. The higher the feature similarity, the more likely a vulnerability is to exist. The error reporting probability corresponding to the feature similarity can be found in the probability correspondence table, which is a data table that records different feature similarities and their corresponding error reporting probabilities.
[0116] Step 304: In response to the error probability, generate and display a vulnerability risk warning.
[0117] Vulnerability risk alerts are information used to inform staff of other locations where vulnerabilities may exist. The methods for determining vulnerability risk alerts are common knowledge in this field and will not be elaborated here.
[0118] When a vulnerability can be triggered reliably, compare the images before and after the vulnerability is triggered to determine the changes in appearance after the vulnerability is triggered. This will help check if there are similar locations in the game. If the similarity is high, it will be determined that there may be a vulnerability in that location, and staff will be notified in a timely manner to check if there is a vulnerability.
[0119] Similar vulnerability detection methods also include: Step 305: When the error probability is greater than the preset risk threshold, retrieve the verification log based on the verification process, and determine the risk coordinates based on the error probability.
[0120] The risk threshold refers to the minimum probability of an error occurring when there is a high probability of a vulnerability. Generally, 50% is chosen as the risk threshold. The specific risk threshold is selected by the staff based on the actual situation and will not be elaborated here. An error probability greater than the risk threshold indicates a high probability of a vulnerability. In this case, further verification is required to confirm the existence of the vulnerability. The verification log refers to the engine logic log when the vulnerability at the error coordinate is triggered according to the verification process. Generally, BERT-encoded text logs are used as the verification log. The method for retrieving the verification log is selected by the staff based on the actual situation and will not be elaborated here.
[0121] Risk coordinates refer to positions where the probability of an error exceeds the risk threshold. The method for determining risk coordinates is selected by staff based on the actual situation and will not be elaborated here.
[0122] Step 306: Determine the risk process by combining the risk coordinates and the verification sequence.
[0123] A risk process refers to the process of verifying vulnerabilities by performing operations according to a verification sequence on a risk coordinate. The method for determining a risk process is common knowledge to those in the field and will not be elaborated here.
[0124] Step 307: Verify the risk process at the risk coordinates and retrieve the risk log based on the risk coordinates.
[0125] Risk logs refer to the engine logic logs when operations are performed at risk coordinates according to the risk process. Generally, BERT-encoded text logs are used as risk logs. The method for retrieving risk logs is selected by the staff according to the actual situation, and will not be elaborated here.
[0126] Step 308: Determine the logical similarity by combining the verification log and the risk log.
[0127] Logical similarity refers to a numerical value that shows the degree of similarity between verification logs and risk logs. Logical similarity can be obtained by comparing the text overlap rate between verification logs and risk logs. The method for determining logical similarity is common knowledge in the field and will not be elaborated here.
[0128] Step 309: If the logical similarity is greater than the preset vulnerability threshold, update the vulnerability warning information in response to the risk coordinates.
[0129] The vulnerability threshold refers to the minimum logical similarity required to trigger a vulnerability. Generally, 80% is used as the vulnerability threshold. The threshold is selected by staff based on the actual situation and will not be elaborated upon here. A logical similarity greater than the vulnerability threshold indicates that a vulnerability has been triggered at the risk coordinate. In this case, staff should be notified promptly via vulnerability alert information.
[0130] When vulnerabilities may exist in other locations, operate according to the conditions that trigger the vulnerability and compare the game logs. If the game logs are similar, determine that there is a vulnerability in that location and promptly notify the staff to reduce the vulnerability.
[0131] Based on the same inventive concept, embodiments of the present invention provide an AI-based automatic game vulnerability detection system, comprising: The data acquisition module is used to collect error messages, verification information, and error images. The memory is used to store the program for any of the above-mentioned AI-based automatic game vulnerability detection methods; The processor is the unit of memory that allows programs to be loaded and executed by the processor.
[0132] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, device, and unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.
[0133] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.
Claims
1. An AI-based automatic detection method for game vulnerabilities, characterized in that, include: Step 100: Collect error information; Step 101: Determine the error time in response to the error message, and determine the error type in response to the error message; Step 102: Select the error duration according to the error type; Step 103: Determine the error reporting period based on the error reporting time and duration; Step 104: Retrieve the operation sequence based on the error reporting period and retrieve the historical sequence based on the error reporting type. The historical sequence refers to the operation sequence when other players previously triggered vulnerabilities of the same error reporting type. Step 105: Determine the error sequence based on the operation sequence and the historical sequence, where the error sequence refers to the same operation order in the operation sequence and the historical sequence; Step 106: In response to the error sequence, generate and display vulnerability information; Also includes: Step 107: Determine the error coordinates in response to the error message; Step 108: Retrieve the comparison sequence based on the error coordinates. The comparison sequence refers to the order of actions performed by other players who have not triggered the vulnerability near the error coordinates. Step 109: Determine the overlapping sequence by combining the comparison sequence and the error sequence; Step 110: Delete the overlapping sequences contained in the error sequence; Also includes: Step 111: Determine the verification process by combining the error coordinates and error sequence; Step 112: Perform verification at the error coordinates according to the verification process and collect verification information; Step 113: When the verification information and the error information are inconsistent, a verification sequence is generated in response to the overlapping sequence and the error sequence. The verification sequence refers to the operation sequence formed by restoring the error sequence one by one from the overlapping sequence. Step 114: Update the verification process based on the verification sequence; It also includes vulnerability handling methods, which include: Step 204: When the verification information matches the error message, retrieve the player information based on the error message; Step 205: Determine the number of errors based on the player information and error type; Step 206: If the number of error reports is greater than a preset high-frequency threshold, determine the player's coordinates based on the player information; Step 207: Determine the vulnerability distance based on the player's coordinates and the error report coordinates; Step 208: Generate and display vulnerability trigger warnings based on the vulnerability distance and the number of error reports.
2. The AI-based game vulnerability automatic detection method of claim 1, wherein The vulnerability handling method also includes: Step 200: When the verification information matches the error information, determine the operation area based on the verification sequence and the error coordinates; Step 201: Determine the blocking area in response to the operating area; Step 202: Generate a blocking patch based on the blocked area; Step 203: Fix the game according to the blocking patch to prevent players from approaching the vulnerability, and generate and display vulnerability patching information according to the blocking patch.
3. The AI-based game vulnerability automatic detection method of claim 2, wherein, The vulnerability handling method also includes: Step 209: If the number of error reports exceeds a preset high-frequency threshold, retrieve the game sequence from the player information; Step 210: Determine the repetition frequency based on the verification sequence and the game sequence, and determine the number of times the vulnerability is traversed based on the vulnerability distance; Step 211: Calculate the quotient of the number of errors and the number of passes, and define it as the pass frequency; Step 212: Calculate the difference between the passing frequency and the repetition frequency, and define it as the frequency difference value; Step 213: When the frequency difference is higher than a preset active threshold, determine the amplification factor in response to the frequency difference; Step 214: Determine the expansion area based on the expansion coefficient and the blocking area; Step 215: Update the blocking patch based on the expanded area.
4. The AI-based game vulnerability automatic detection method of claim 3, wherein, The vulnerability handling method also includes: Step 216: When the frequency difference is higher than a preset active threshold, determine the playtime based on the player information; Step 217: Determine the player group in response to the stated playtime; Step 218: Determine the base frequency based on the player group; Step 219: If the passing frequency is higher than the reference frequency, update the blocking patch based on the expanded area.
5. The AI-based game vulnerability automatic detection method of claim 1, wherein, It also includes a similar vulnerability detection method, which includes: Step 300: When the verification information is consistent with the error information, collect the error image based on the error coordinates, and retrieve the historical image based on the error coordinates. The historical image refers to the appearance image of the error coordinates when the vulnerability is not triggered. Step 301: Compare the reported error image with historical images to determine the error characteristics; Step 302: Determine the feature similarity by combining the error report features and the preset game model; Step 303: Determine the error probability based on feature similarity; Step 304: In response to the error probability, generate and display a vulnerability risk warning.
6. The AI-based game vulnerability automatic detection method of claim 5, wherein, The similar vulnerability detection method also includes: Step 305: When the error probability is greater than the preset risk threshold, retrieve the verification log based on the verification process, and determine the risk coordinates based on the error probability; Step 306: Determine the risk process by combining the risk coordinates and verification sequence; Step 307: Verify the risk process at the risk coordinates and retrieve the risk log based on the risk coordinates; Step 308: Determine the logical similarity by combining the verification log and the risk log; Step 309: If the logical similarity is greater than the preset vulnerability threshold, update the vulnerability warning information in response to the risk coordinates.
7. An AI-based automatic game vulnerability detection system, characterized in that, include: The data acquisition module is used to collect error messages, verification information, and error images. A memory for storing a program of an AI-based automatic game vulnerability detection method as described in any one of claims 1 to 6; The processor is the unit of memory that allows programs to be loaded and executed by the processor.