A method and system for fuzz testing and vulnerability mining of short message service logic

Abstract

The application provides a short message service logic fuzzy testing and vulnerability mining method and system, relating to the technical field of software testing, wherein the method comprises: firstly, obtaining historical vulnerability information and first network interaction data to construct vulnerability knowledge graph and user session state data; then inputting the state data and the knowledge graph into a large language model, and guiding the generation of a test sequence through a reinforcement learning strategy; subsequently, executing the sequence in a test environment, synchronously collecting business responses and second network interaction data, updating the state data according to the second network interaction data and obtaining corresponding signaling state data; finally, comparing the first operation state in the response of the application to be tested with the second operation state in the signaling state data by using a differential testing algorithm, and determining that there is a logic vulnerability when the two are inconsistent. The application improves the mining capability of deep logic vulnerabilities of short message services.

Description

Technical Field

[0001] This application relates to the field of software testing technology, and in particular to a fuzzing test and vulnerability discovery method and system for SMS business logic. Background Technology

[0002] Fuzzy testing and vulnerability discovery methods for SMS business logic have significant application prospects in the field of mobile internet application security. This method tests business robustness by simulating abnormal requests and can effectively discover hidden security vulnerabilities such as vertical privilege escalation. As core scenarios such as online payment become increasingly reliant on SMS verification, improving the intelligence level of such testing has become a practical need.

[0003] Existing SMS service security testing methods mostly rely on fixed abnormal test case libraries or code rule-based scanning. During the testing process, random or predefined malformed messages are usually constructed first, then sent to the business interface and the response is observed. These methods can detect program anomalies to a certain extent, but the logic of generating test cases is not strongly related to the logical structure of the business process, resulting in insufficient coverage of deep state machine vulnerabilities.

[0004] Furthermore, the test case generation process in existing technologies is disconnected from the actual signaling interaction process of the business. The analysis of test results is usually based only on a single response at the application layer, lacking synchronous verification of the complete state transitions of the underlying signaling interaction. This makes it difficult for tests to discover deep logical problems where the declared state at the application layer is inconsistent with the actual state at the underlying layer in the business process. Therefore, existing technologies suffer from insufficient technical problems in discovering cross-layer logical consistency vulnerabilities in SMS services. Summary of the Invention

[0005] This application provides a fuzzing test and vulnerability discovery method and system for SMS business logic, in order to solve the problems of low test accuracy and poor ability to discover deep logic vulnerabilities in SMS business in the prior art.

[0006] To address the aforementioned technical problems, firstly, this application provides a fuzzing and vulnerability discovery method for SMS service logic, comprising: Obtain historical vulnerability information of the SMS service process and the first network interaction data in the test environment; Based on the historical vulnerability information, a vulnerability knowledge graph is constructed using a graph attention network, and the first network interaction data is parsed to construct the state data of the user session. Based on the state data and the vulnerability knowledge graph, the large language model is guided to make sequence decisions using a reinforcement learning strategy preset by the large language model, thereby generating test sequences for fuzz testing. The test sequence is executed in the test environment to obtain response data and second network interaction data returned by the business application during the execution process, and the status data is updated according to the second network interaction data to generate signaling status data corresponding to the updated status data. A differential testing algorithm is used to compare the first operation state indicated in the response data with the second operation state indicated in the signaling state data. When the comparison result shows that the first operation state and the second operation state are inconsistent, it is determined that there is a logical vulnerability in the SMS service process.

[0007] Optionally, the step of guiding the large language model to make sequence decisions based on the state data and the vulnerability knowledge graph, using a reinforcement learning strategy preset by the large language model, to generate test sequences for fuzz testing includes: Based on the state data and the vulnerability knowledge graph, descriptive information is generated; The description information is input into the large language model as the initial state. Under the guidance of the reinforcement learning strategy, the large language model makes multiple rounds of iterative decisions based on the initial state. Each round of decision includes: generating a test operation instruction based on the current state, and evaluating the degree of disturbance of the test operation instruction to the current causal logic link based on the vulnerability knowledge graph, so as to calculate the reward score. The current input information is adjusted based on the reward score to generate the input information for the next round. When the preset termination condition is met, the test operation instructions generated in each round of decision-making are combined in sequence to form a test sequence.

[0008] Optionally, the step of evaluating the degree of disturbance of the test operation instruction to the current causal logic link based on the vulnerability knowledge graph to calculate the reward score includes: Based on the vulnerability knowledge graph, the target business process triggered by the test operation instruction is determined, and at least one historical vulnerability pattern associated with the target business process is extracted from the vulnerability knowledge graph. The test operation command is simulated and deduced in relation to the current causal logic link to identify the logical breakpoints that the test operation command may cause in the current causal logic link. Calculate the first reward component based on the degree of matching between the historical vulnerability pattern and the logical breakpoint; Assess the degree of disruption caused by the logical breakpoint to the current causal logic chain as a whole, and calculate the second reward component; Based on preset weights, the first reward component and the second reward component are weighted and summed to obtain the reward score.

[0009] Optionally, the step of constructing a vulnerability knowledge graph using a graph attention network based on the historical vulnerability information and parsing the first network interaction data to construct user session state data includes: Extract multiple vulnerability patterns from the historical vulnerability information; Each vulnerability pattern is set as a knowledge node, and connections are established between relevant knowledge nodes based on the business processes associated with the vulnerability pattern to form an initial knowledge graph. The initial knowledge graph is input into a graph attention network, which calculates the connection strength between each knowledge node and integrates the information of the knowledge nodes based on the connection strength to obtain a vulnerability knowledge graph. Analyze the first network interaction data to identify signaling events belonging to the same user session; Establish causal logical links between signaling events according to the chronological order of events, and construct user session state data based on the causal logical links.

[0010] Optionally, the step of executing the test sequence in the test environment to obtain response data and second network interaction data returned by the service application during execution, and updating the status data based on the second network interaction data to generate signaling status data corresponding to the updated status data, includes: In the test environment, according to the order of the test operation instructions in the test sequence, the corresponding operation requests are sent to the business application in sequence, and the response data returned by the business application for each operation request is recorded. While executing each operation request, capture newly generated signaling messages in the test environment as secondary network interaction data; Based on the second network interaction data, new signaling events triggered by operation requests are identified, and the new signaling events are inserted into the state data of the user session to update the state data; Extract the status information corresponding to one or more key operations in the test sequence from the updated status data, and use it as signaling status data.

[0011] Optionally, the differential testing algorithm is used to compare the first operation state indicated in the response data with the second operation state indicated in the signaling state data. When the comparison result shows that the first operation state and the second operation state are inconsistent, it is determined that there is a logical vulnerability in the SMS service process, including: From the response data, the first operation state corresponding to one or more key operations in the test sequence is parsed out; From the signaling status data, the second operation status corresponding to one or more key operations at the signaling layer is parsed out; The first operation state and the second operation state are compared using a differential testing algorithm to determine whether they are consistent. If the comparison result shows that the first operation status is successful and the second operation status is unsuccessful, it is determined that the first operation status and the second operation status are inconsistent, and it is determined that there is a logical vulnerability in the SMS service process.

[0012] Optionally, after employing a differential testing algorithm to compare the first operation state indicated in the response data with the second operation state indicated in the signaling state data, and determining that a logical vulnerability exists in the SMS service process when the comparison result shows that the first operation state and the second operation state are inconsistent, the method further includes: Collect state comparison records generated due to inconsistency between the first operation state and the second operation state; The state comparison record is time-aligned with the state data of the user session, and the aligned sequence data is input into a recurrent neural network, which extracts the temporal features and contextual features of the state comparison record in the user session flow. The temporal features, the contextual features, and the node information in the vulnerability knowledge graph are fused together, and the fusion result is input into a pre-trained classification model. Based on the fusion result, the classification model calculates a risk score for each state comparison record and marks the key business link in the state data of the user session where the state comparison record is located. Based on the risk score and the key business processes, a structured vulnerability analysis report is generated.

[0013] Secondly, this application provides a fuzz testing and vulnerability discovery system for SMS business logic, including: The acquisition module is used to acquire historical vulnerability information of the SMS service process and the first network interaction data in the test environment. The construction module is used to construct a vulnerability knowledge graph using a graph attention network based on the historical vulnerability information, and to parse the first network interaction data to construct the state data of the user session; The decision module is used to guide the large language model to make sequence decisions based on the state data and the vulnerability knowledge graph, using a reinforcement learning strategy preset by the large language model, and generate a test sequence for fuzz testing. The generation module is used to execute the test sequence in the test environment to obtain response data and second network interaction data returned by the business application during the execution process, and update the status data according to the second network interaction data to generate signaling status data corresponding to the updated status data. The comparison module is used to compare the first operation state indicated in the response data with the second operation state indicated in the signaling state data using a differential testing algorithm. When the comparison result shows that the first operation state and the second operation state are inconsistent, it is determined that there is a logical vulnerability in the SMS service process.

[0014] Thirdly, this application provides an electronic device, comprising: Memory, used to store computer programs; A processor is configured to implement the steps of a fuzzing and vulnerability discovery method for SMS service logic as described in the first aspect above when executing the computer program.

[0015] Fourthly, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the steps of the fuzzing and vulnerability discovery method for SMS business logic as described in the first aspect above.

[0016] This application provides a fuzzing and vulnerability discovery method for SMS service logic, which has the following beneficial effects: First, by constructing a vulnerability knowledge graph and parsing initial network data to establish state data, subsequent tests can be designed specifically based on known vulnerability patterns and real business logic, improving the relevance of the test starting point to the business scenario, which in turn helps to improve the accuracy of the test. Second, by using a large language model combined with reinforcement learning to generate test sequences, this process can dynamically simulate abnormal paths in complex business state transitions, enabling the generated test cases to more effectively cover hidden logical defects. Then, during test execution, application responses and network signaling are collected synchronously and the status data is updated accordingly. This method enables real-time tracking and synchronization of business status at multiple levels during test execution, providing accurate and synchronous input for subsequent consistency comparison. Finally, a differential testing algorithm is used to compare the operational status of the application layer and the signaling layer. This method can accurately identify the state discrepancies between the two layers, thereby directly and reliably revealing deep logical inconsistencies in the business process.

[0017] Furthermore, this application also forms initial state information based on business state data and vulnerability knowledge graphs and inputs it into a large language model. Then, through reinforcement learning, the model is guided to generate instructions in multiple iterations and calculate reward scores based on the knowledge graph to adjust the decision direction. Finally, the instructions from each round are combined to form a test sequence. The above process dynamically guides the generation process by combining business semantics and historical vulnerability knowledge, so that the generated test sequence can be constructed more effectively to target specific weaknesses in complex business logic, thereby improving the pertinence and effectiveness of test cases in discovering deep logic vulnerabilities.

[0018] These or other aspects of this application will become more apparent in the following description of the embodiments. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 A flowchart illustrating a method for fuzz testing and vulnerability discovery of SMS service logic provided in an embodiment of this application; Figure 2 A schematic diagram illustrating a specific implementation of a fuzzing and vulnerability discovery method for SMS service logic provided in this application embodiment; Figure 3 This is a schematic diagram of the structure of a fuzz testing and vulnerability discovery system for SMS service logic provided in an embodiment of this application. Detailed Implementation

[0021] In the field of SMS service security testing, existing technical solutions typically rely on static rule bases or random mutations to generate test cases. Their generation logic is independent of the actual signaling flow of the service, making it difficult to simulate complex unauthorized operation paths. At the same time, the testing and verification process mainly relies on single return information from the application layer, without taking into account the real transaction state reflected by the underlying network signaling. This makes it difficult for testing to effectively discover deep logical defects in the process where the application layer operation results are inconsistent with the actual execution state of the signaling layer. These defects are an important source of highly concealed security vulnerabilities.

[0022] To address the aforementioned issues, this application proposes a fuzzy testing and vulnerability discovery method for SMS business logic. This method first integrates historical vulnerability data and network interaction data to construct a structured vulnerability knowledge graph and user session state data, thereby establishing an accurate characterization of business logic and known risks. Then, based on this, a large language model is introduced, combined with reinforcement learning strategies, to perform sequence decision-making on the state data and knowledge graph, intelligently generating test case sequences that can disrupt the causal chain of normal business operations. Finally, during test execution, business application responses and network signaling data are simultaneously collected, and a differential testing algorithm is used to rigorously compare the consistency between the operational states declared at the application layer and the actual states observed at the signaling layer. This scheme deeply binds the test case generation process with the actual business flow and, through cross-layer state differential verification between the application and signaling layers, effectively discovers and accurately determines deep vulnerabilities in SMS services caused by logical sequence errors or state inconsistencies, thus solving the problem of insufficient cross-layer logical consistency vulnerability discovery in existing technologies.

[0023] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments. Obviously, the described embodiments are merely some embodiments of the present application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0024] The core of this application is to provide a fuzzing and vulnerability discovery method for SMS business logic, and a flowchart of one specific implementation is shown below. Figure 1 As shown, the method includes: Step 101: Obtain historical vulnerability information of the SMS service process and the first network interaction data in the test environment.

[0025] In step 101, the SMS business process refers to the business chain that relies on SMS verification codes to complete key operations, such as payment, authorization, or binding processes, which typically involve multiple ordered steps. Historical vulnerability information refers to security flaw reports or records that have been publicly disclosed or discovered in the past and are related to SMS services, which record the triggering conditions and manifestations of the vulnerabilities. The first network interaction data refers to the raw communication data that carries SMS service requests and responses, captured by monitoring network links in a test environment. This includes signaling messages that contain operations such as user login, SMS delivery, and verification.

[0026] In this embodiment of the application, historical vulnerability information is collected and organized from security databases or public channels, and network packet capture tools are used to perform traffic mirroring in a deployed test environment to obtain initial, untested and undisturbed business interaction data as the first network interaction data.

[0027] Step 102: Based on the historical vulnerability information, construct a vulnerability knowledge graph using a graph attention network, and parse the first network interaction data to construct the state data of the user session.

[0028] Among them, the vulnerability knowledge graph is a structured knowledge representation. It stores vulnerability patterns extracted from historical vulnerabilities in knowledge nodes and expresses the correlation between different vulnerability patterns in business logic through connection relationships. After optimization by graph attention network, the graph can represent the deep semantic and logical connections between vulnerability patterns. User session state data is a structured data representation. By parsing the first network interaction data, signaling events are identified, and causal logical links between signaling events are established according to time sequence and business rules, thereby completely depicting the operations that have occurred and their logical constraints during a business interaction.

[0029] In this embodiment, step 102 includes the following process: Step 1021: Extract multiple vulnerability patterns from the historical vulnerability information.

[0030] In step 1021, a vulnerability pattern refers to a combination of core features abstracted from a single historical vulnerability instance. These multiple vulnerability patterns may include the identifier of the business process attacked by the vulnerability, the sequence of abnormal operation requests that trigger the vulnerability, and the type of privilege escalation caused by the vulnerability.

[0031] In this embodiment of the application, natural language processing technology is used to analyze historical vulnerability information in text format to identify the business steps, abnormal request parameters and security impacts described therein. Then, these elements are structured and combined according to a preset template to automatically extract an independent vulnerability pattern. This process will traverse all historical vulnerability information to extract all vulnerability patterns.

[0032] In practical applications, for example, a vulnerability pattern can be extracted from a security bulletin about a "flaw in the quick payment binding logic of a certain bank". The core of this pattern is that "sending a confirmation binding request without submitting an SMS verification code during the mobile phone number binding process can lead to vertical privilege escalation".

[0033] Step 1022: Set each vulnerability pattern as a knowledge node, and establish connections between relevant knowledge nodes according to the business processes associated with the vulnerability pattern to form an initial knowledge graph.

[0034] In step 1022, a knowledge node, or vulnerability node, is the basic unit in the vulnerability knowledge graph and is used to store all the structured information of a vulnerability pattern. The connection relationship is used to characterize the correlation between different vulnerability nodes in business logic. The initial knowledge graph is an initial network structure composed of multiple knowledge nodes and the connection relationships between nodes.

[0035] In this embodiment of the application, each vulnerability pattern extracted in step 1021 is first instantiated as an independent knowledge node. Then, the business process attributes associated with each knowledge node are analyzed. If two or more knowledge nodes are associated with the same business process or have a sequential dependency in the business process, an undirected connection edge is created between these knowledge nodes. After combining all knowledge nodes and connection edges, an initial knowledge graph depicting the vulnerability association is formed.

[0036] In practical applications, assuming three vulnerability patterns have been extracted, with pattern A associated with the "login process" and patterns B and C both associated with the "payment process", then step 1022 will create three knowledge nodes and establish a connection edge between the two knowledge nodes of pattern B and pattern C that are associated with the same "payment process", thus forming an initial knowledge graph containing three nodes and one edge.

[0037] Step 1023: Input the initial knowledge graph into the graph attention network, calculate the connection strength between each knowledge node, and integrate the information of the knowledge nodes according to the connection strength to obtain the vulnerability knowledge graph.

[0038] In step 1023, the connection strength is a learnable weight coefficient used to quantify the contribution of one knowledge node to the information update of another knowledge node.

[0039] In this embodiment of the application, the initial knowledge graph obtained in step 1022 is input into a pre-trained graph attention network. The network assigns a trainable attention weight to each connection edge in the graph as the connection strength. Then, each knowledge node updates its own feature representation by weighted aggregation based on the features of its neighboring nodes and the corresponding connection strength. Finally, the vulnerability knowledge graph after information fusion and enhancement of all knowledge nodes is output.

[0040] In practical applications, this graph attention network uses a large amount of vulnerability data during the training phase. The learning objective is to make vulnerability nodes associated with the same attack chain or the same business component have similar feature representations. After network calculation, the connection strength between pattern B and pattern C may be 0.9, while the connection strength between pattern A and pattern B, and between pattern A and pattern C, may be 0.1. Ultimately, the node features of pattern B and C will be highly fused, while the features of pattern A will differ significantly.

[0041] Step 1024: Analyze the first network interaction data and identify signaling events belonging to the same user session.

[0042] In step 1024, a user session refers to a complete, stateful service interaction process, and a signaling event is an independent and meaningful operational unit in network interaction data.

[0043] In this embodiment, the first network interaction data obtained in step 101 is first decoded according to the communication protocol specification to restore the semantics of each message. Then, based on the user identifier, session identifier, and timestamp information contained in the messages, consecutive messages belonging to the same user and within a reasonable time window are aggregated together to divide into multiple independent user sessions. Key signaling events are then identified from the message sequence of each session. Furthermore, this embodiment does not limit the content of the communication protocol specification; it can be set according to the actual situation.

[0044] In practical applications, for example, if message M1 is for user A to log in, M2 is for user A to send an SMS verification code, M3 is for user B to log in, and M4 is for user A to submit a verification code, step 1024 will identify M1, M2, and M4 as belonging to the same session of user A based on the user identifier, and identify the three signaling events "login", "send verification code", and "submit verification code" from them.

[0045] Step 1025: Establish causal logical links between signaling events according to the chronological order of events, and construct user session state data based on the causal logical links.

[0046] In step 1025, the causal logic link describes the logical relationship in which the occurrence of a previous signaling event in a user session is a necessary or precondition for triggering a subsequent signaling event.

[0047] In this embodiment of the application, for each user session identified in step 1024, all its signaling events are first strictly sorted according to timestamps, and then the dependencies between events are analyzed based on the business rule base. Directed logical links are established for continuous event pairs with causal dependencies. Finally, a user session is represented as a directed acyclic graph composed of these signaling events as nodes and causal logical links as directed edges, which serves as the state data of the user session.

[0048] In practical applications, for user A's session, step 1025 will establish a link from the "login" event to the "issue verification code" event, and a link from the "issue verification code" event to the "submit verification code" event, thereby constructing state data that reflects the business process of "login to verification issuance to verification submission".

[0049] This application transforms scattered historical vulnerabilities and raw network data into a structured vulnerability knowledge graph rich in related information and user session state data that accurately describes business process logic through step 102, thus laying a reliable data and knowledge foundation for the subsequent intelligent generation of highly targeted test cases.

[0050] Step 103: Based on the state data and the vulnerability knowledge graph, use the reinforcement learning strategy preset by the large language model to guide the large language model to make sequence decisions and generate test sequences for fuzz testing.

[0051] Among them, the large language model is a predictive model that is trained based on a deep neural network and can understand and generate natural language text. The reinforcement learning strategy is a method that guides the model to learn and make decisions through reward or punishment signals. This embodiment does not limit the structural design of the large language model or the process of the reinforcement learning strategy. The test sequence is a set of test operation instructions arranged in order, and each instruction is used to simulate a user operation in the test environment.

[0052] In this embodiment, step 103 includes the following process, such as... Figure 2 As shown: Step 1031: Based on the state data and the vulnerability knowledge graph, form descriptive information.

[0053] In step 1031, the descriptive information is a structured text used to provide a general description of the current decision-making environment to the large language model. The descriptive information includes at least key causal logic link information extracted from the state data and relevant vulnerability pattern summaries extracted from the vulnerability knowledge graph.

[0054] In this embodiment of the application, the core causal logic link of the user session is first extracted from the state data constructed in step 102 and converted into an easy-to-understand text description. Then, the vulnerability patterns related to the business links involved in the causal logic link are retrieved from the vulnerability knowledge graph constructed in step 102, and the brief descriptions of these patterns are integrated together to finally form a comprehensive description information containing business logic background and potential risk points.

[0055] In practical applications, assuming the state data describes the causal chain from "login to verification issuance to verification submission to payment," and the vulnerability knowledge graph contains a vulnerability pattern related to the "payment" stage: "skipping verification submission and directly making payment," then the description information generated in step 1031 might be: "The current business chain is: after the user logs in, a verification code is issued. After the user submits the verification code, payment can be initiated. It is known that there is a vulnerability pattern in the payment stage: sending a payment request directly without submitting a verification code may lead to unauthorized access."

[0056] Step 1032: Input the description information as the initial state into the large language model. Under the guidance of the reinforcement learning strategy, the large language model makes multiple rounds of iterative decisions based on the initial state. Each round of decision includes: generating a test operation instruction based on the current state, and evaluating the degree of disturbance of the test operation instruction to the current causal logic link based on the vulnerability knowledge graph to calculate the reward score.

[0057] Here, the current state refers to the text information input to the large language model at the beginning of each round of decision-making, which includes the generated instruction sequence and the updated environment description; the test operation instruction is a specific, executable request description, such as "send a payment request without a verification code field"; The reward score is a numerical value used to quantify the effectiveness of the generated test operation instructions in disrupting normal business logic. The higher the score, the more likely the instruction is to trigger a vulnerability.

[0058] Step 1032 may specifically include the following steps: A1: Based on the vulnerability knowledge graph, determine the target business process triggered by the test operation command, and extract at least one historical vulnerability pattern associated with the target business process from the vulnerability knowledge graph.

[0059] In step A1, the target business process refers to the business process stage that the test operation instruction intends to access or trigger, such as "payment" or "binding".

[0060] In this embodiment of the application, the semantics of the test operation instructions generated by the large language model are first analyzed to identify the specific business link intended to be operated as the target business link. Then, the target business link is used as the query condition to search in the vulnerability knowledge graph constructed in step 102 to find all vulnerability knowledge graph nodes associated with the link, and the specific content of the corresponding historical vulnerability pattern is extracted from these nodes.

[0061] In practical applications, for the test operation instruction "send payment request", step A1 determines that its target business process is "payment", and then retrieves all vulnerability patterns related to the "payment" process from the vulnerability knowledge graph. For example, it finds pattern P1 "payment without verification code" and pattern P2 "payment successful despite incorrect verification code".

[0062] A2: Simulate and deduce the test operation command with the current causal logic link to identify the logical breakpoints that the test operation command may cause in the current causal logic link.

[0063] In step A2, a logical breakpoint refers to a location or state in a normal causal logical chain where the business logic cannot be executed coherently due to the insertion of abnormal test operation instructions.

[0064] In this embodiment of the application, based on the causal logic link maintained in the current state information and modified by the generated instruction sequence, the newly generated test operation instruction is attempted to be inserted into a reasonable position of the link as a new event. The insertion of the instruction is judged by logical reasoning to determine whether it violates the predetermined event occurrence preconditions or sequence constraints in the link, and the position that violates the constraints is identified as a potential logical breakpoint.

[0065] In practical applications, assuming the current causal logic chain is "login to verification issuance" and "verification submission" has not yet been performed, if the instruction "send payment request" is inserted, step A2 will find through simulation that, according to the business rules, "payment" must be performed after "verification submission". However, the current chain lacks the prerequisite event of "verification submission". Therefore, a logical breakpoint is identified at the position where the "verification submission" event should have occurred.

[0066] A3: Calculate the first reward component based on the degree of matching between the historical vulnerability pattern and the logical breakpoint.

[0067] In step A3, the first reward component is a numerical value that reflects the similarity between the logical breakpoint caused by the test operation command and the known historical vulnerability pattern.

[0068] In this embodiment of the application, the logical breakpoints identified in step A2, such as "missing event X", are compared with the historical vulnerability patterns extracted in step A1, such as "pattern description: missing event X leads to unauthorized access". The overlap between the historical vulnerability patterns and the logical breakpoints in terms of the disrupted business process, missing preconditions, and other features is evaluated. The higher the degree of overlap, the closer the test operation instruction is to a known effective attack method, and therefore the higher the first reward component is assigned. For example, the degree of matching can be quantified by calculating the cosine similarity between feature vectors.

[0069] In practical applications, the logical breakpoint is "missing verification submission event before payment". The extracted historical vulnerability pattern P1 is described as "missing verification code payment". The two are highly matched in the core feature of "missing verification". Therefore, a higher first reward component can be calculated, such as 0.9.

[0070] A4: Assess the degree of disruption caused by the logical breakpoint to the current causal logical link as a whole, and calculate the second reward component.

[0071] In step A4, the second reward component is a numerical value used to reflect the extent to which the logical break caused by the test operation instruction disrupts the continuity and integrity of the overall business process; this application embodiment does not limit the evaluation method, evaluation process, etc.

[0072] In this application embodiment, the analysis of logical breakpoints causes which subsequent legitimate business events can no longer occur normally according to the original link, or causes the business state machine to enter an unexpected state, and assesses the number and criticality of the affected subsequent events; the more critical events affected, or the more serious errors the business enters, the greater the degree of damage is considered, and the higher the second reward weight is assigned.

[0073] In practical applications, the logical breakpoint "lack of verification submission before payment" directly causes the core business event of "payment" to become an illegal operation in logic, destroying the integrity of the entire "login-verification-payment" chain. Therefore, its degree of damage is very large, and it can be given a high second reward weight, such as 0.8.

[0074] A5: Based on preset weights, the first reward component and the second reward component are weighted and summed to obtain the reward score.

[0075] In this embodiment of the application, step A5 uses a predefined weighted summation formula to calculate the final reward score. For example, the formula is R=w1×S1+w2×S2, where R represents the reward score, w1 represents the weight of the first reward component, S1 represents the value of the first reward component, w2 represents the weight of the second reward component, and S2 represents the value of the second reward component; w1 and w2 are preset constant values, and usually satisfy w1+w2=1.

[0076] In practical applications, assuming the preset weights w1 and w2 are 0.6 and 0.4 respectively, the first reward component S1 is 0.9 and the second reward component S2 is 0.8, then the reward score R = 0.6 × 0.9 + 0.4 × 0.8 = 0.86.

[0077] Step 1033: Adjust the current input information based on the reward score to generate the input information for the next round.

[0078] In this embodiment of the application, the current state is updated according to the reward score calculated in step 1032 to form the input information for the next round; specifically, the test operation instructions generated in this round and the calculated reward score are appended to the current description information to form a new text containing decision history and effect feedback, which serves as the "current state" that the large language model relies on in the next round of decision-making.

[0079] In practical applications, assuming the current state text is "Background: ...", the command "Send payment request" has been generated and a reward of 0.86 has been received, then the input information for the next round will be adjusted to: "Background: ..., Operation performed: Send payment request, Reward: 0.86, Please continue to generate the next operation".

[0080] Step 1034: When the preset termination condition is reached, combine the test operation instructions generated in each round of decision-making in sequence to form a test sequence.

[0081] In step 1034, the preset termination condition may be that the instruction sequence reaches a preset length, or the reward score of multiple consecutive rounds of decision-making is lower than a certain threshold, or the model generates a special instruction indicating the end.

[0082] In this embodiment, the iterative decision-making process is continuously monitored. When any preset termination condition is met, the loop stops. Then, the valid test operation instructions generated by the large language model in each round are extracted strictly in the order in which they were generated and combined into an ordered list. This list is the final test sequence used for fuzz testing.

[0083] In practical applications, the preset termination condition is that the sequence length reaches 3 instructions. When the large language model generates the three instructions "skip verification after login", "directly request user information", and "send payment request" in sequence, the loop terminates and the three instructions are combined in order to form a test sequence [instruction 1, instruction 2, instruction 3].

[0084] This application utilizes the sequence generation capability of the large language model in step 103 and the guidance mechanism of reinforcement learning, combined with specific business states and vulnerability knowledge, to automatically construct a sequence of test cases that can effectively disturb normal business logic and are highly targeted, thereby improving the intelligence level of test case generation and the targeting of deep logic vulnerabilities.

[0085] Step 104: Execute the test sequence in the test environment to obtain response data and second network interaction data returned by the business application during the execution process, and update the status data according to the second network interaction data to generate signaling status data corresponding to the updated status data.

[0086] Among them, response data refers to the response information returned by the backend server of the business application after receiving the operation request corresponding to the test operation instruction. The response data usually includes a status code and response content; the second network interaction data refers to the original communication data carrying business interaction signaling captured in real time in the test environment network during the execution of the test sequence; and the signaling status data is specific information extracted from the updated status data that can characterize the execution result of signaling events associated with key test operations.

[0087] In this embodiment, step 104 includes the following process: Step 1041: In the test environment, according to the order of the test operation instructions in the test sequence, send the corresponding operation requests to the business application in sequence, and record the response data returned by the business application for each operation request.

[0088] In step 1041, the operation request is a network request that conforms to the interface specification and is constructed based on the specific description of the test operation instruction, such as an HTTP POST request.

[0089] In this embodiment of the application, an automated test execution engine is used to implement this. The engine first reads the test sequence generated in step 103, and then translates each instruction into an executable network request that the target business application can recognize, and sends it out according to the order of the instructions. After sending, the engine will synchronously listen to the response of the business application and record and store each request and its corresponding complete response content, including status code, response header and response body, as response data.

[0090] In practical applications, for the instruction "send a payment request without a verification code field" in the test sequence, the test execution engine will construct it into an HTTP request pointing to the payment interface with a request body lacking a verification code field and send it. The business application may return a response with a status code of 200 and the content "payment successful", or it may return a response with a status code of 403 and the content "verification failed". Both of these response contents will be fully recorded as the response data of this operation.

[0091] Step 1042: While executing each operation request, capture newly generated signaling messages in the test environment as second network interaction data.

[0092] In this embodiment, steps 1042 and 1041 are executed synchronously; a packet capture tool deployed on the network link of the test environment is used to mirror and capture all traffic of the specified network interface; when the test execution engine sends an operation request, the request itself and all network packets generated by the response returned by the business application, along with other signaling messages that may be generated by the internal system interaction triggered by the request, are captured and saved in real time to form the second network interaction data.

[0093] In practical applications, when the test engine sends a payment request, the packet capture tool will capture the HTTP request message, the HTTP response message returned by the server, and may also capture internal signaling such as database query requests sent by the server background to verify the user's status. All these network messages newly generated during the test execution period are classified as the second network interaction data.

[0094] Step 1043: Based on the second network interaction data, identify the new signaling event triggered by the operation request, and insert the new signaling event into the state data of the user session to update the state data.

[0095] In step 1043, the newly added signaling event is a new service operation unit that is parsed from the second network interaction data and is directly or indirectly caused by the currently executed operation request.

[0096] In this embodiment, the second network interaction data captured in step 1042 is first decoded and semantically analyzed to identify signaling messages that are strongly related to the currently executed test operation. Then, referring to the method in step 1025, these messages are parsed into specific signaling events. Next, these newly added signaling events are used as new nodes and inserted into the causal logic link graph represented by the user session state data constructed in step 102 according to their occurrence time and logical relationship, thereby dynamically updating the state data to reflect the latest business state after the test execution.

[0097] In practical applications, assuming the original state data contains two events, "login" and "verification issuance", after executing the test operation "send payment request", a "permission verification" event and a "deduction" event generated internally by the server are parsed from the second network interaction data. Step 1043 then inserts "permission verification" and "deduction" as new signaling events into the state data according to the logical relationship, forming an updated link such as "login to verification issuance to permission verification to deduction".

[0098] Step 1044: Extract the status information corresponding to one or more key operations in the test sequence from the updated status data, and use it as signaling status data.

[0099] In step 1044, the critical operation refers to the test operation instruction in the test sequence that has been pre-marked or is considered by analysis to be most likely to trigger the vulnerability, such as the instruction in the sequence that is intended to bypass the verification.

[0100] In this embodiment of the application, firstly, based on the reward score or preset rules assigned by the reinforcement learning process in step 103, one or more key operations in the test sequence are determined; then, in the state data updated in step 1043, the new signaling events corresponding to these key operations are located, and the contextual state information surrounding these events is extracted, such as whether the event was successfully executed, the state of its preceding and following related events, etc.; finally, the extracted state information is structured to form signaling state data.

[0101] In practical applications, the key operation in the test sequence is "sending a payment request". In the updated status data, the new events directly related to this operation are "permission verification" and "deduction". Step 1044 then extracts the results of the "permission verification" event, such as "success", and the results of the "deduction" event, such as "executed", as core information to form the signaling status data.

[0102] In step 104, during the dynamic execution of test cases, this application synchronously and accurately tracks the actual changes in application layer responses and underlying signaling flows, and integrates the observed signaling changes into the business state model in real time, thereby providing a real, reliable and context-related state basis for subsequent cross-layer consistency comparison.

[0103] Step 105: Using a differential testing algorithm, compare the first operation state indicated in the response data with the second operation state indicated in the signaling state data. When the comparison result shows that the first operation state and the second operation state are inconsistent, it is determined that there is a logical vulnerability in the SMS service process.

[0104] The first operational state is a declarative result of whether a critical operation was successful, interpreted from the business application layer response. The second operational state is an objective result of whether the actual transaction associated with the same critical operation was completed, derived from the signaling layer observation data. In this application, a logical vulnerability specifically refers to a security issue where, due to defects in the business process logic, the operational result claimed by the application layer is inconsistent with the actual execution state reflected by the underlying signaling layer.

[0105] In this embodiment, step 105 includes the following process: Step 1051: Parse the first operation state corresponding to one or more key operations in the test sequence from the response data.

[0106] In this embodiment of the application, one or more key operations determined in step 1044 are first located, and then the corresponding response record is found from the recorded response data according to their execution order in step 1041. Next, the response data is analyzed, and the processing result declared by the business application for the key operation is determined according to preset rules, such as checking whether the status code is 2xx, or parsing whether the response body contains specific success keywords, and the result is encoded as a unified first operation status.

[0107] In practical applications, the key operation is "sending a payment request", which corresponds to a response data status code of 200 and a response body content of "payment successful". According to preset rules, this is interpreted as the first operation status "success".

[0108] Step 1052: Parse the second operation state corresponding to one or more key operations at the signaling layer from the signaling state data.

[0109] In this embodiment of the application, the signaling status data generated in step 1044 is read. This data already contains the signaling event information and results associated with the key operation. Then, the execution flag or result field of these signaling events is analyzed, and it is determined whether they have truly and completely completed the corresponding key transactions according to the business rules. Finally, this objective completion status observed based on the underlying signaling is encoded into a unified second operation status.

[0110] In practical applications, the signaling status data corresponding to the key operation "send payment request" includes "deduction event: executed" and "authorization verification event: successful". This indicates that the payment transaction has been actually completed at the signaling level, and is therefore parsed as the second operation status "success".

[0111] Step 1053: Compare whether the first operation state and the second operation state are consistent using a differential testing algorithm.

[0112] In step 1053, the difference test algorithm can be an equivalence comparison algorithm or an algorithm with other structures. Therefore, this application does not specifically limit the application of the difference test algorithm, and can make corresponding settings according to the actual situation.

[0113] In this embodiment of the application, step 1053 takes the first operation state parsed in step 1051 and the second operation state parsed in step 1052 as inputs, and uses a simple equivalence comparison algorithm to determine whether the two are the same; specifically, the two state values ​​are compared, and if the conclusions of whether the operation they represent are the same, they are determined to be consistent, otherwise they are determined to be inconsistent.

[0114] In practical applications, if the first operation status is "success" and the second operation status is also "success", the differential testing algorithm determines that the two are consistent; if the first operation status is "success" but the second operation status is "failure", then the two are determined to be inconsistent.

[0115] Step 1054: If the comparison result shows that the first operation status is a success status and the second operation status is a failure status, then it is determined that the first operation status and the second operation status are inconsistent, and it is determined that there is a logical vulnerability in the SMS service process.

[0116] In this embodiment, step 105 further includes the following process: B1: Collect state comparison records generated due to inconsistency between the first operation state and the second operation state.

[0117] In step B1, the state comparison record is a piece of information stored in a structured manner, which includes at least the key operation content that caused the inconsistency, the first operation state value, the second operation state value, and the associated user session identifier.

[0118] In this embodiment of the application, whenever step 1054 determines that a logical vulnerability has been found, step B1 will be triggered. It will package and save all context information related to this vulnerability determination, including the test instruction that triggered the vulnerability, the first operation state parsed from the response data, the second operation state parsed from the signaling state data, and the unique identifier of the test session, as a new state comparison record.

[0119] In practical applications, after discovering an inconsistency where the application layer reports a successful payment but the signaling layer does not deduct the payment, a record is generated: {Key operation: "Send payment request", First operation status: "Success", Second operation status: "Failure", Session ID: "Sess_001"}.

[0120] B2: The state comparison record is time-aligned with the state data of the user session, and the aligned sequence data is input into a recurrent neural network, which extracts the temporal features and contextual features of the state comparison record in the user session flow.

[0121] In step B2, the temporal characteristics refer to the relative position of the state comparison record on the timeline of the complete user session state data and the regularity of the sequence of events before and after it. The contextual characteristics refer to the causal or dependency relationship between the vulnerability trigger point corresponding to the state comparison record and the signaling events before and after it.

[0122] In this embodiment, firstly, based on the session ID in the state comparison record, the original user session state data constructed in step 102 and the final state data updated in step 1043 are found; then, the vulnerability trigger time corresponding to the state comparison record is accurately located in the time series of the state data to complete the time alignment; then, with the trigger point as the center, the signaling event sequence within a certain window before and after the point in the state data is extracted, and this sequence and the state comparison record itself are used as input and fed into a pre-trained recurrent neural network; the recurrent neural network processes the sequence data through its internal memory unit and finally outputs a feature vector that integrates the time position and contextual relationship of the vulnerability point in the overall business process.

[0123] In practical applications, the vulnerability corresponding to the state comparison record is triggered in the "send payment request" operation. The "payment request" event corresponding to this operation is found in the user session state data. Its preceding event is "verification issuance", and there are no subsequent events because it is the last test operation. The event sequence "login to verification issuance to payment request" and the state comparison record are input into the recurrent neural network. After the network processes it, it outputs a feature vector that represents the specific temporal context of "the vulnerability occurred after verification and before payment".

[0124] B3: The temporal features, the contextual features, and the node information in the vulnerability knowledge graph are fused together, and the fusion result is input into a pre-trained classification model. Based on the fusion result, the classification model calculates a risk score for each state comparison record and marks the key business link in the state comparison record in the state data of the user session.

[0125] In step B3, the classification model is a machine learning model used to map input data to a specific category or value, which is used in this application to assess the risk level of the vulnerability.

[0126] In this embodiment, firstly, all vulnerability pattern nodes related to the business operations involved in the current state comparison record are retrieved from the vulnerability knowledge graph constructed in step 102, and the feature vectors of these nodes are extracted as node information. Then, the temporal and contextual feature vectors output by the recurrent neural network in step B2 are concatenated with the extracted vulnerability knowledge graph node feature vectors to form a comprehensive feature vector that integrates real-time context and static historical knowledge. Finally, this comprehensive feature vector is input into a pre-trained classification model, which outputs two results: a numerical risk score representing the potential severity of the vulnerability, and a label of the specific stage in the business process where the vulnerability is located.

[0127] In practical applications, the fused feature vector is input into the classification model, which has learned from a large number of vulnerability records and manually labeled risk levels during the training phase. The model calculates a risk score of 0.85 based on the input and outputs the label of the key business link as "core payment transaction link".

[0128] B4: Based on the risk score and the key business processes, generate a structured vulnerability analysis report.

[0129] In this embodiment of the application, the risk score and key business process labels output in step B3 are integrated with the detailed information in the status comparison record collected in step B1, and a structured vulnerability analysis report is automatically generated according to the preset report template. The report typically includes the vulnerability trigger point, details of the inconsistent status, the associated business process, the calculated risk score, and the priority of the remediation suggestions based on the score.

[0130] In practical applications, the final generated report contains the following structured content: Vulnerability title: "Payment process logic defect", Triggering operation: "Payment request bypassing verification code", Application layer status: "Success", Signaling layer status: "Deduction failed", Key business link: "Core payment transaction link", Risk score: 0.85 (high), Recommendation: "Immediate fix".

[0131] This application uses differential testing in step 105 to accurately locate cross-layer state inconsistency issues to discover core logic vulnerabilities. Furthermore, by introducing recurrent neural networks and classification models, it performs intelligent analysis on the discovered vulnerability records, thereby achieving automated risk assessment and location of vulnerabilities and improving the usability and efficiency of vulnerability discovery results.

[0132] Figure 3 A schematic diagram of the structure of a fuzzing and vulnerability discovery system for SMS service logic provided in this application embodiment is shown below. Figure 3 As shown, the system includes: The acquisition module 31 is used to acquire historical vulnerability information of the SMS service process and the first network interaction data in the test environment.

[0133] The construction module 32 is used to construct a vulnerability knowledge graph using a graph attention network based on the historical vulnerability information, and to parse the first network interaction data to construct the state data of the user session.

[0134] The decision module 33 is used to guide the large language model to make sequence decisions based on the state data and the vulnerability knowledge graph, using a reinforcement learning strategy preset by the large language model, and generate a test sequence for fuzz testing.

[0135] The generation module 34 is used to execute the test sequence in the test environment to obtain response data and second network interaction data returned by the business application during the execution process, and update the status data according to the second network interaction data to generate signaling status data corresponding to the updated status data.

[0136] The comparison module 35 is used to compare the first operation state indicated in the response data with the second operation state indicated in the signaling state data using a differential testing algorithm. When the comparison result shows that the first operation state and the second operation state are inconsistent, it is determined that there is a logical vulnerability in the SMS service process.

[0137] The SMS business logic fuzzing and vulnerability discovery system of this application embodiment is used to implement the aforementioned SMS business logic fuzzing and vulnerability discovery method. Therefore, the specific implementation of the SMS business logic fuzzing and vulnerability discovery system can be found in the embodiment section of the SMS business logic fuzzing and vulnerability discovery method above. The specific implementation can be referred to the description of the corresponding embodiment, and will not be repeated here.

[0138] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of the fuzzing and vulnerability discovery method for any of the above-described SMS service logic.

[0139] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the fuzzing and vulnerability discovery method for any of the above-described SMS service logics.

[0140] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as USB flash drives, read-only memory, random access memory, portable hard drives, magnetic disks, or optical disks.

[0141] The embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in the embodiments of the fuzzing and vulnerability mining method for any of the above-described SMS service logic.

[0142] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0143] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in one or more embodiments of this specification are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of related data must comply with relevant laws, regulations and standards, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0144] The foregoing has provided a detailed description of a fuzzing test and vulnerability discovery method and system for SMS service logic provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of this application.

Claims

1. A method for fuzz testing and vulnerability discovery of SMS service logic, characterized in that, include: Obtain historical vulnerability information of the SMS service process and the first network interaction data in the test environment; Based on the historical vulnerability information, a vulnerability knowledge graph is constructed using a graph attention network, and the first network interaction data is parsed to construct the state data of the user session. Based on the state data and the vulnerability knowledge graph, the large language model is guided to make sequence decisions using a reinforcement learning strategy preset by the large language model, thereby generating test sequences for fuzz testing. The test sequence is executed in the test environment to obtain response data and second network interaction data returned by the business application during the execution process, and the status data is updated according to the second network interaction data to generate signaling status data corresponding to the updated status data. A differential testing algorithm is used to compare the first operation state indicated in the response data with the second operation state indicated in the signaling state data. When the comparison result shows that the first operation state and the second operation state are inconsistent, it is determined that there is a logical vulnerability in the SMS service process.

2. The method according to claim 1, characterized in that, The step of using the state data and the vulnerability knowledge graph, and guiding the large language model to make sequence decisions using a pre-set reinforcement learning strategy, to generate test sequences for fuzz testing, includes: Based on the state data and the vulnerability knowledge graph, descriptive information is generated; The description information is input into the large language model as the initial state. Under the guidance of the reinforcement learning strategy, the large language model makes multiple rounds of iterative decisions based on the initial state. Each round of decision includes: generating a test operation instruction based on the current state, and evaluating the degree of disturbance of the test operation instruction to the current causal logic link based on the vulnerability knowledge graph, so as to calculate the reward score. The current input information is adjusted based on the reward score to generate the input information for the next round. When the preset termination condition is met, the test operation instructions generated in each round of decision-making are combined in sequence to form a test sequence.

3. The method according to claim 2, characterized in that, The step of evaluating the degree of disturbance of the test operation instruction to the current causal logic link based on the vulnerability knowledge graph, in order to calculate the reward score, includes: Based on the vulnerability knowledge graph, the target business process triggered by the test operation instruction is determined, and at least one historical vulnerability pattern associated with the target business process is extracted from the vulnerability knowledge graph. The test operation command is simulated and deduced in relation to the current causal logic link to identify the logical breakpoints that the test operation command may cause in the current causal logic link. Calculate the first reward component based on the degree of matching between the historical vulnerability pattern and the logical breakpoint; Assess the degree of disruption caused by the logical breakpoint to the current causal logic chain as a whole, and calculate the second reward component; Based on preset weights, the first reward component and the second reward component are weighted and summed to obtain the reward score.

4. The method according to claim 1, characterized in that, The step of constructing a vulnerability knowledge graph using a graph attention network based on the historical vulnerability information and parsing the first network interaction data to construct user session state data includes: Extract multiple vulnerability patterns from the historical vulnerability information; Each vulnerability pattern is set as a knowledge node, and connections are established between relevant knowledge nodes based on the business processes associated with the vulnerability pattern to form an initial knowledge graph. The initial knowledge graph is input into a graph attention network, which calculates the connection strength between each knowledge node and integrates the information of the knowledge nodes based on the connection strength to obtain a vulnerability knowledge graph. Analyze the first network interaction data to identify signaling events belonging to the same user session; Establish causal logical links between signaling events according to the chronological order of events, and construct user session state data based on the causal logical links.

5. The method according to claim 1, characterized in that, The step of executing the test sequence in the test environment to obtain response data and second network interaction data returned by the business application during execution, and updating the status data based on the second network interaction data to generate signaling status data corresponding to the updated status data, includes: In the test environment, according to the order of the test operation instructions in the test sequence, the corresponding operation requests are sent to the business application in sequence, and the response data returned by the business application for each operation request is recorded. While executing each operation request, capture newly generated signaling messages in the test environment as secondary network interaction data; Based on the second network interaction data, new signaling events triggered by operation requests are identified, and the new signaling events are inserted into the state data of the user session to update the state data; Extract the status information corresponding to one or more key operations in the test sequence from the updated status data, and use it as signaling status data.

6. The method according to claim 1, characterized in that, The differential testing algorithm compares the first operation state indicated in the response data with the second operation state indicated in the signaling state data. When the comparison result shows that the first operation state and the second operation state are inconsistent, a logical vulnerability is determined to exist in the SMS service process, including: From the response data, the first operation state corresponding to one or more key operations in the test sequence is parsed out; From the signaling status data, the second operation status corresponding to one or more key operations at the signaling layer is parsed out; The first operation state and the second operation state are compared using a differential testing algorithm to determine whether they are consistent. If the comparison result shows that the first operation status is successful and the second operation status is unsuccessful, it is determined that the first operation status and the second operation status are inconsistent, and it is determined that there is a logical vulnerability in the SMS service process.

7. The method according to claim 1, characterized in that, After employing a differential testing algorithm to compare the first operation state indicated in the response data with the second operation state indicated in the signaling state data, and determining that a logical vulnerability exists in the SMS service process when the comparison result shows that the first operation state and the second operation state are inconsistent, the process further includes: Collect state comparison records generated due to inconsistency between the first operation state and the second operation state; The state comparison record is time-aligned with the state data of the user session, and the aligned sequence data is input into a recurrent neural network, which extracts the temporal features and contextual features of the state comparison record in the user session flow. The temporal features, the contextual features, and the node information in the vulnerability knowledge graph are fused together, and the fusion result is input into a pre-trained classification model. Based on the fusion result, the classification model calculates a risk score for each state comparison record and marks the key business link in the state data of the user session where the state comparison record is located. Based on the risk score and the key business processes, a structured vulnerability analysis report is generated.

8. A fuzz testing and vulnerability discovery system for SMS service logic, characterized in that, include: The acquisition module is used to acquire historical vulnerability information of the SMS service process and the first network interaction data in the test environment. The construction module is used to construct a vulnerability knowledge graph using a graph attention network based on the historical vulnerability information, and to parse the first network interaction data to construct the state data of the user session; The decision module is used to guide the large language model to make sequence decisions based on the state data and the vulnerability knowledge graph, using a reinforcement learning strategy preset by the large language model, and generate a test sequence for fuzz testing. The generation module is used to execute the test sequence in the test environment to obtain response data and second network interaction data returned by the business application during the execution process, and update the status data according to the second network interaction data to generate signaling status data corresponding to the updated status data. The comparison module is used to compare the first operation state indicated in the response data with the second operation state indicated in the signaling state data using a differential testing algorithm. When the comparison result shows that the first operation state and the second operation state are inconsistent, it is determined that there is a logical vulnerability in the SMS service process.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of a fuzzing and vulnerability discovery method for SMS service logic as described in any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, enables a fuzzing and vulnerability discovery method for SMS service logic as described in any one of claims 1 to 7.

Images