A source code vulnerability detection method and system

Abstract

The application provides a source code vulnerability detection method and system, and relates to the technical field of data processing. The method comprises the following steps: generating a semantic judgment result based on a source code file set of a smart meter; generating a light conversation starting point and a magnetic tampering prevention trigger point according to the semantic judgment result, and constructing control flow information; defining a light conversation state variable, defining a conversation opening path segment based on the light conversation state variable and the control flow information; defining a magnetic optical probe scene path based on the conversation opening path segment; generating a vulnerability record corresponding to a sensitive operation according to the magnetic optical probe scene path; and generating a source code vulnerability detection report according to the vulnerability record corresponding to the sensitive operation. The application can make the detection conclusion aggregated and presented according to the scene path and provide clear guidance for rectification.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a source code vulnerability detection method and system. Background Technology

[0002] Smart meters are typically installed at the metering site on the user's side or the distribution side to collect, measure, store, and report electrical energy parameters. During on-site operation, they need to meet the requirements of long-term stable operation and prevention of unauthorized interference. Smart meters typically include a sealed shell and a terminal cover structure. The terminal cover is used to cover the wiring terminals and screws and, together with the seal, forms an tamper-proof appearance. Inside, there is a metering chip or metering front-end and a main control chip to complete electrical energy sampling and business processing. It can also be configured with security elements to perform cryptographic operations such as key protection and signature verification. To meet the needs of meter reading and maintenance, smart meters are usually equipped with an optical interface as a local maintenance channel. External maintenance terminals achieve local data interaction, parameter maintenance, and session management by bonding the optical probe with the optical interface.

[0003] In actual maintenance operations, optical probes are often magnetically fixed near the optical interface of the meter to achieve a stable fit. The meter also has anti-magnetic tampering detection and handling logic, which is used to enter the corresponding state control and event handling process when an abnormal magnetic field or illegal interference is detected. The above maintenance method means that the meter firmware source code contains optical local maintenance session processing logic, anti-magnetic tampering detection and handling logic, as well as key operational logic such as metering parameters, rate parameters, and communication parameters. Moreover, these logics may have different execution orders and reachable paths under different operating states, which puts higher demands on the security analysis at the source code level.

[0004] Existing source code vulnerability detection methods typically rely on general rule scanning or analysis of default execution flows. These methods struggle to accurately locate and verify constraints in specific execution scenarios, such as those triggered during the optical local maintenance session in smart meter maintenance environments. They also fail to effectively identify critical operation statements that may still be executed under the anti-magnetic tampering trigger state and their corresponding code locations. Furthermore, existing methods often rely solely on identifier text matching or simply check permissions and status judgments on regular paths, easily overlooking the impact of optical local maintenance session state changes on the execution path. They also struggle to establish a clear correspondence between the optical session start point, the anti-magnetic tampering trigger point, and critical operation statements at the source code level, thus affecting the relevance, reproducibility, and engineering usability of vulnerability detection results. Summary of the Invention

[0005] In view of the shortcomings of the prior art, the purpose of this invention is to provide a source code vulnerability detection method that can solve the technical problem that the impact of optical local maintenance session state changes on the execution path is easily overlooked in the prior art.

[0006] A first aspect of this invention provides a source code vulnerability detection method, comprising:

[0007] S1: Generate semantic judgment results based on the set of source code files of smart meters;

[0008] S2: Generate the optical session start point and anti-magnetic tampering trigger point based on the semantic judgment results, and construct control flow information;

[0009] S3: Define optical session state variables, and define session initiation path segments based on optical session state variables and control flow information;

[0010] S4: Define the scene path for the magnetic optical probe based on the session initiation path segment;

[0011] S5: Generate vulnerability records corresponding to sensitive operations based on the scene path of the magnetic optical probe;

[0012] S6: Generate source code vulnerability detection reports based on vulnerability records corresponding to sensitive operations.

[0013] A second aspect of this invention provides a source code vulnerability detection system, comprising: a processor and a memory;

[0014] The memory stores programs or instructions that can run on the processor, which, when executed by the processor, implement the steps of the source code vulnerability detection method as described in the first aspect.

[0015] The beneficial effects of the technical solutions provided in the embodiments of the present invention include at least the following:

[0016] 1. By generating semantic judgment results from a set of source code files based on smart meters, and forming a list of optical-related identifiers and a list of anti-magnetic tampering-related identifiers, the code statements containing the corresponding identifiers are located in each source code file. Their line numbers are recorded as the optical session start point and the anti-magnetic tampering trigger point, respectively. This allows the optical local maintenance process and the anti-magnetic tampering process to obtain traceable and reproducible location basis at the source code level. This transforms the problem of the existing technology, which relies solely on general rule scanning and is difficult to accurately locate the key code positions in specific scenarios, into a structured analysis problem with line number positions as anchor points, thereby improving the location accuracy and consistency of the target scenario.

[0017] 2. This invention uses the session opening path segment as a judgment condition to define the magnetic optical probe scene path from the candidate execution path, so that the analysis object is upgraded from text-level code fragments to path-level objects consistent with the actual execution order. This enables constraint relationship verification for the special execution situation of anti-magnetic tampering processing triggered during the optical session opening, avoiding the defect of existing technology that ignores session state changes and causes execution path judgment distortion.

[0018] 3. This invention searches for anti-magnetic tampering state control statements and sensitive statements corresponding to sensitive operations within scene code slices. When at least one sensitive statement exists and the execution condition of the sensitive statement does not contain anti-magnetic tampering state constraints limited by the anti-magnetic tampering state control statement, a vulnerability record corresponding to the sensitive operation is generated. This transforms the problem of identifying key operation statements that may still be executed under the anti-magnetic tampering trigger state in the prior art into vulnerability generation rules that can be directly judged and recorded. Subsequently, the vulnerability records are grouped and detection result items are generated according to the path identifier of the scene path of the magnetic optical probe. Finally, a source code vulnerability detection report is formed, which enables the detection conclusions to be presented in aggregate according to the scene path and provides clear guidance for rectification, improving the pertinence and engineering usability of the detection results. Attached Figure Description

[0019] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts. Obviously, the drawings described below are merely some embodiments of the present invention, and those skilled in the art can obtain other drawings based on these drawings without any creative effort.

[0020] Figure 1 This is a flowchart illustrating a source code vulnerability detection method according to an embodiment of the present invention.

[0021] Figure 2 This is a schematic diagram of the structure of a source code vulnerability detection system provided in an embodiment of the present invention. Detailed Implementation

[0022] To enable those skilled in the art to better understand the technical solutions in the embodiments of the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. It should be understood that these descriptions are merely exemplary and are not intended to limit the scope of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0023] The following description, in conjunction with the accompanying drawings, details a source code vulnerability detection method provided by the present invention through specific embodiments and application scenarios.

[0024] Reference manual attached Figure 1 The diagram shows a flowchart of a source code vulnerability detection method provided by an embodiment of the present invention.

[0025] This invention provides a source code vulnerability detection method, which may include the following steps:

[0026] S1: Generate semantic judgment results based on the set of source code files of smart meters.

[0027] In one possible implementation, S1 specifically includes sub-steps S101 to S103:

[0028] S101: Obtain the set of source code files for the smart meter.

[0029] It should be noted that the set of source code files for a smart meter refers to the entire set of program code files used to control and manage the operation of the smart meter. These source code files correspond to the software implementation of each functional unit inside the smart meter, including metering functions, communication functions, anti-tampering detection functions, and local maintenance functions.

[0030] Specifically, the process of a computing device reading software program files used to implement smart meter functions from a storage medium or network location involves the following steps: First, the computing device receives input information indicating the location of the smart meter firmware project. Based on this input information, it accesses the corresponding file system directory or version control system repository, identifying all source code files related to the smart meter software project within the directory or repository. The computing device iterates through the files in the directory or repository one by one, determining whether a file is a source code file based on its content structure and file type. For files identified as source code files, their complete content is loaded into memory, and the file name, storage path, and content are saved as a single source code file record. Through this traversal and identification process, the computing device aggregates all source code file records belonging to the same smart meter software project into a source code file set.

[0031] S102: Perform syntax parsing on each source code file in the source code file set to obtain an identifier set, which includes variable names, macro definition names, enumerated constant names, register bit names, and interrupt service routine names.

[0032] It should be noted that parsing the source code file set refers to analyzing the program structure of each source code file to identify various identifiers used to describe the behavior and state of the smart meter. The variable names in the identifier set represent the state parameters or intermediate data of different functional units during the operation of the smart meter; macro definition names provide a unified description of hardware characteristics, function switches, or configuration options; enumerated constant names represent a set of operating states or event types with a defined value range; register bit names map specific control bits related to metering, communication, or anti-tampering in the internal hardware registers of the smart meter; and interrupt service routine names identify the processing procedures triggered when internal or external events occur in the smart meter.

[0033] Specifically, the parsing tool is activated to perform preprocessing operations on each source code file, removing single-line and multi-line comments, processing file include directives to recursively load dependent header files, and expanding conditional compilation directives to retain valid code segments. Then, lexical analysis is performed on the preprocessed files, breaking the code down into a series of words such as keywords, identifiers, constants, operators, and delimiters. Following the identifier naming conventions of the programming language, words that meet the requirements are selected, while non-identifier elements such as keywords, constants, operators, and delimiters are excluded, resulting in a candidate set of identifiers. Next, syntactic analysis is performed on this candidate set, identifying various types of identifiers one by one based on the code context and syntactic structure, including the identification of variables. When identifying names, it is necessary to locate the names after the type specifier in the variable declaration statement and distinguish between global and local variables. When identifying macro definition names, it is necessary to extract the names that start with preprocessing instructions and exclude replacement text. When identifying enumeration constant names, it is necessary to extract the names that represent specific running states or event types from the enumeration definition statement. When identifying register bit names, it is necessary to filter the names of control bits related to metering, communication, or anti-tampering in the internal hardware registers of the smart meter. When identifying interrupt service routine names, it is necessary to locate the names that identify the internal or external event triggering handlers. Finally, the identified variable names, macro definition names, enumeration constant names, register bit names, and interrupt service routine names are summarized to form an identifier set.

[0034] S103: Perform semantic judgment on the identifiers in the identifier set to obtain the semantic judgment result, wherein the semantic judgment result is an optically related identifier or an anti-magnetic-optical tampering related identifier.

[0035] It should be noted that semantic judgment of a set of identifiers refers to analyzing the usage and target of the identifiers in the program in conjunction with the functional architecture and operating scenario of the smart meter, so as to determine the functional meaning of the identifier.

[0036] It should be noted that the semantic judgment result refers to the classification result obtained by analyzing the usage scenarios and objects of the identifiers in the program after parsing the source code file of the smart meter and extracting the identifiers, combined with the functional structure and operation logic of the smart meter. This classification is used to characterize the functional semantics of each identifier in the smart meter software system. Optical-related identifiers are those identified in the semantic judgment result as describing the smart meter's local communication, data interaction, or maintenance operations with external maintenance terminals through the optical interface. These identifiers correspond to program elements in the smart meter related to the establishment of optical local maintenance sessions, session state management, and optical data processing. Anti-magnetic tampering-related identifiers are those identified in the semantic judgment result as describing the smart meter's detection, recording, or processing of abnormal magnetic fields or tampering behavior. These identifiers correspond to program elements in the smart meter related to anti-magnetic tampering detection mechanisms, anti-tampering state control, and tampering event handling logic.

[0037] Specifically, the process of obtaining optical-related identifiers or anti-magnetic tampering-related identifiers is as follows: The computing device first retrieves the functional architecture and operational scenario information of the smart meter, clarifying the core roles of the optical local maintenance interface module and the anti-magnetic tampering detection module, as well as key operational scenarios such as optical communication, local maintenance, magnetic field detection, and tampering event handling. Then, the computing device sequentially reads each identifier in the identifier set, locates all occurrences of that identifier in the source code file, extracts the corresponding code statements, functions, functional modules, and related comments for each occurrence, and analyzes the usage of the identifier in the code statements, including the data processing processes involved, function call relationships, and hardware interaction objects. Simultaneously, based on the identifier's naming characteristics, it determines whether it contains functional pointing characteristics related to the optical interface, local maintenance, and communication protocols, and whether it contains functions related to magnetic fields, tampering detection, and anti-tampering processing. The system identifies key features and associates them with the attributes of the functional modules to which the identifier belongs. It then determines whether the module belongs to either optical local maintenance or anti-magnetic tampering detection. Referring to the functional semantics described in the annotations, and considering the analysis results from multiple aspects such as naming features, usage methods, modules, and annotation information, the functional meaning of the identifier is determined. If the identifier is determined to describe the local communication, data interaction, session establishment, session state management, or optical data processing functions implemented by the smart meter through the optical interface, then the identifier is identified as an optical-related identifier. If the identifier is determined to describe the magnetic field change detection, tampering status record, tampering event response, or anti-tampering control logic functions of the smart meter, then the identifier is identified as an anti-magnetic tampering related identifier. By performing the above reading, locating, extracting, analyzing, and determining operations on each identifier in the identifier set, a set containing the semantic determination results for each identifier is finally formed.

[0038] In embodiments of the present invention, generating semantic judgment results can clearly distinguish program elements in different functional domains within the smart meter software at the source code level. This allows for clear identification and structured expression of optical communication-related logic and anti-magnetic tampering-related logic, which were originally mixed within the same code project. By establishing a mapping relationship between various identifiers and their corresponding functional semantics through semantic judgment results, it helps to accurately locate code positions related to optical local maintenance sessions and anti-magnetic tampering processing. This provides a reliable foundation for subsequent construction of control flow information, identification of key execution paths, and analysis of the coupling relationships between different functional paths.

[0039] S2: Generate the optical session start point and anti-magnetic tampering trigger point based on the semantic judgment result.

[0040] In one possible implementation, S2 specifically includes sub-steps S201 to S205:

[0041] S201: Based on the semantic judgment results, generate a list of optically related identifiers and a list of anti-magnetic tampering related identifiers.

[0042] It should be noted that the optical-related identifier list refers to a set of program identifiers selected and compiled from the source code of the smart meter. This set of identifiers corresponds to the software elements involved when the smart meter communicates locally with an external maintenance terminal through the optical interface. It reflects the control logic and state expression related to the optical communication hardware, optical data interaction process, and local maintenance operations within the smart meter. The anti-magnetic tampering related identifier list refers to another set of program identifiers selected from the same source code. This set of identifiers corresponds to the software elements involved when the smart meter detects and processes abnormal magnetic fields or illegal interference. It reflects the control logic within the smart meter used to sense changes in magnetic fields, record tampering status, and trigger anti-tampering processing procedures.

[0043] Specifically, the process involves the computing device reading and classifying the aforementioned semantic judgment results item by item. After reading the semantic judgment result corresponding to each identifier, the computing device determines the functional category of the identifier and categorizes the identifier into different identifier lists based on the functional category. When the semantic judgment result of an identifier represents the functional meaning related to local communication, data interaction, or session control between its corresponding smart meter and an external maintenance terminal via an optical interface, the computing device records the name of the identifier, its source code file, and its location in the source code file, and adds it to the optical-related identifier list. When the semantic judgment result of an identifier represents the functional meaning related to the detection, status recording, or processing of abnormal magnetic fields or tampering behavior by its corresponding smart meter, the computing device records the name of the identifier, its source code file, and its location in the source code file, and adds it to the anti-magnetic tampering related identifier list. By sequentially performing the above classification and recording process on all identifiers in the semantic judgment results, the computing device generates complete optical-related identifier lists and anti-magnetic tampering related identifier lists, clearly separating the program elements corresponding to different functional semantics at the source code level.

[0044] S202: In each source code file, find the first code statement that contains the optically related identifiers from the list of optically related identifiers.

[0045] Specifically, the computing device sequentially reads each source code file in the source code file set, performing a line-by-line scan and syntactic structure traversal of the text content of each source code file. After reading the source code file, the computing device compares the usage of identifiers in the source code file one by one based on the previously generated list of optically related identifiers. When a code statement in a source code file contains an identifier with the same name as any optically related identifier in the list, the computing device identifies the code statement as containing an optically related identifier and records the line number position of the code statement and the file name of the source code file to which it belongs. By repeating the above comparison and identification process on all code statements in the source code file, the computing device obtains all code statements in the source code file that contain optically related identifiers.

[0046] S203: The line number of the first code statement in the corresponding source code file is recorded as the starting point of the optical session.

[0047] Specifically, after analyzing the source code file and identifying code statements containing optical-related identifiers, the specific line number of each code statement in the source code file is recorded as a significant program location. This recorded line number indicates the starting point of the optical local maintenance communication processing flow in the smart meter software during execution. By marking this line number as the optical session start point, it can be used as a reference node in subsequent control flow and execution path analysis to clarify the start time of the optical local maintenance session in the program execution sequence, thus providing a clear location basis for analyzing the relationship between the optical communication flow and other functional flows.

[0048] S204: In each source code file, find the second code statement that contains the anti-magnetic tampering related identifier from the list of anti-magnetic tampering related identifiers.

[0049] Specifically, the process involves sequentially reading each source code file in the source code file set and performing sequential parsing and syntactic structure traversal on the text content of each source code file. During the parsing process, the computing device compares the usage of various identifiers appearing in the source code files with a pre-generated list of anti-magnetic tampering related identifiers. When a code statement in a source code file contains an identifier whose name matches any identifier in the list of anti-magnetic tampering related identifiers, the computing device identifies the code statement as an anti-magnetic tampering related code statement and further confirms its association with magnetic field detection, tampering status recording, or tampering processing logic. The line number position of the code statement in the corresponding source code file and the file name of the source code file to which it belongs are recorded, and the recording results are saved as the location information of the anti-magnetic tampering related code statement. By repeating the above parsing and comparison process on all code statements in the source code files, the computing device can completely identify all code statements containing anti-magnetic tampering related identifiers in each source code file.

[0050] S205: Record the line number position of the second code statement in the corresponding source code file as the anti-magnetic tampering trigger point.

[0051] It should be noted that the optical session start point refers to the code location in the source code file that first indicates the smart meter enters the optical local maintenance communication state. The corresponding code statement is used to initiate or switch to the optical local maintenance session, and its line number indicates the starting position of the optical local maintenance communication process in program execution. The anti-magnetic tampering trigger point refers to the code location in the source code file that indicates the anti-magnetic tampering detection or processing logic is triggered. The corresponding code statement indicates that the smart meter detects an abnormal magnetic field or tampering behavior and enters the corresponding processing flow, and its line number indicates the trigger position of the anti-magnetic tampering processing flow in program execution.

[0052] Specifically, the line number of the code statement in the corresponding source code file is used as the anti-magnetic tampering trigger point because the line number can uniquely and stably identify the specific location of the anti-magnetic tampering related logic in the program at the source code level, thus providing a clear location basis for subsequent analysis. By using the line number as the anti-magnetic tampering trigger point, the semantics of anti-magnetic tampering can be directly correlated with the actual program execution location, enabling subsequent function filtering, control flow construction, and execution path analysis to accurately revolve around the trigger point, avoiding ambiguity caused by relying solely on identifier names or text descriptions. This helps to clarify the triggering time and execution order of the anti-magnetic tampering processing logic during program execution, thereby supporting accurate analysis of the correlation between the optical local maintenance session flow and the anti-magnetic tampering processing flow, and improving the accuracy and reproducibility of source code vulnerability detection results.

[0053] In this embodiment of the invention, the key program locations corresponding to the optical local maintenance process and the anti-magnetic tampering process are clearly distinguished and precisely identified at the source code level, so that the related logic originally scattered in different source code files and different functions can obtain a unified location basis. By using the line number position of the code statement as the starting point of the optical session and the trigger point of the anti-magnetic tampering, the abstract functional semantics can be directly mapped to the specific program execution position, thereby providing a stable and reliable analysis anchor for subsequent function screening, control flow construction, and execution path analysis. This effectively avoids the problems of unclear path location and omission of key logic caused by relying solely on text matching or general rule scanning, enabling source code vulnerability detection to revolve around the functional processes that may actually be triggered, improving the accuracy of identifying potential security issues in specific maintenance scenarios and the reproducibility of results.

[0054] S3: Construct control flow information based on the optical session start point and the anti-magnetic tampering trigger point.

[0055] In one possible implementation, S3 specifically includes sub-steps S301 to S303:

[0056] S301: Perform syntax parsing on all source code files in the source code file set to obtain a function set.

[0057] It should be noted that the function set refers to the collection of all function program units identified and summarized from the source code files of the smart meter after performing syntax parsing. Each function corresponds to a piece of independently callable program logic in the smart meter software used to implement a specific function or handle a specific event.

[0058] Specifically, the process involves sequentially reading each source code file in the source code file set and performing structured parsing on the program text of each file. After reading the source code file, the computing device analyzes the source code content according to the syntax rules of the corresponding programming language, identifying the program structure units used to define functions within the source code file. During the parsing process, the return type, function name, parameter list, and the start and end positions of the function body are identified, and code statements belonging to the same function definition scope are grouped together to form complete function program units. For each identified function program unit, the computing device records the source code file to which the function belongs, the function name, and the position range of the function within the source code file, and saves the function program unit as an independent element. By repeatedly executing the above syntax parsing and function identification process on all source code files in the source code file set, the computing device summarizes all function program units from different source code files to form a function set.

[0059] S302: Based on the anti-magnetic tampering trigger point and the optical session start point, the functions in the function set are filtered to obtain the target function.

[0060] It should be noted that the objective function refers to the function program unit that is selected from the function set and is associated with the optical session start point or the anti-magnetic tampering trigger point. This type of function contains or directly affects the optical local maintenance communication process or the anti-magnetic tampering processing process, and its program logic plays a key functional role in the operation of the smart meter.

[0061] Specifically, the process involves sequentially reading each function unit in the function set and comparing and analyzing the source code range of each function in conjunction with the recorded location data of the anti-magnetic tampering trigger point and the optical session start point. During the analysis, the start and end line numbers of each function in its respective source code file are first obtained, and this range is compared one by one with the line number positions corresponding to the anti-magnetic tampering trigger point and the optical session start point. When the line number position of the anti-magnetic tampering trigger point or the line number position of the optical session start point falls within the line number range of a certain function, that function is determined to be associated with the anti-magnetic tampering processing flow or the optical local maintenance communication flow, and is marked as a candidate function. All marked candidate functions are summarized and recorded as target functions.

[0062] S303: Construct control flow information for the objective function.

[0063] It should be noted that control flow information refers to a data structure used to describe the execution order and jump relationships between code statements within the target function. This information reflects the changes in the execution path of the program under different conditions. By using control flow information, we can clarify the various execution paths that the function may experience during its operation, thus providing a basis for subsequent analysis of the correlation between the optical communication process and the anti-magnetic tampering processing process at the program level.

[0064] Specifically, the process involves analyzing the source code of the target function statement by statement and establishing the code execution order. The computing device first reads the complete function body of the target function in the source code file and parses each code statement within the function body according to the program's sequential structure, branching structure, and looping structure. During parsing, the sequential execution relationships between the code statements within the function body are identified, as well as the execution path changes caused by conditional statements, loop statements, or jump statements. Each code statement is mapped to an execution node, and the possible execution transfer relationships between code statements are recorded as connections between nodes. The execution nodes and their connections are then summarized and organized to form control flow information representing all possible execution paths within the target function, thereby clarifying the execution order and branching direction of the target function under different operating conditions.

[0065] In embodiments of the present invention, constructing control flow information can transform the original linear text structure of the source code in the objective function into a structured representation that clearly reflects the program's execution order and branching relationships, thus clearly depicting the program's execution path under different conditions. Through control flow information, the sequential relationships, conditional branches, and loop structures between code statements within a function can be accurately identified, providing a reliable basis for subsequent execution path traversal and critical path identification. This helps avoid the problem of relying solely on static text order for analysis while ignoring actual execution path changes, improving the accuracy of complex control logic analysis.

[0066] S4: Define optical session state variables and define session initiation path segments based on optical session state variables and control flow information.

[0067] In one possible implementation, defining the optical session state variables in S4 specifically includes sub-steps S401 to S403:

[0068] S401: Define the local communication session between the smart meter and the external maintenance terminal as an optical local maintenance session.

[0069] It should be noted that the optical local maintenance session refers to the local communication process established between the smart meter and the external maintenance terminal through its optical communication interface. This communication process is used to read and maintain the smart meter's operating status, metering data, or parameter configuration. It corresponds to the data interaction behavior completed by the smart meter through a near-field optical method without the need for a remote communication network.

[0070] S402: In the source code file corresponding to the objective function, find the target code statements of the optical related identifiers in the list of optical related identifiers.

[0071] It should be noted that the source code file corresponding to the objective function refers to the source code file containing the logic for implementing the aforementioned optical local maintenance communication functions. This file contains program statements for processing optical communication requests, maintenance instructions, and session management. The target code statements refer to the code statements in the source code file that are specifically used to implement optical communication processing or session management, and they directly participate in the establishment or maintenance of the optical local maintenance session during program execution.

[0072] Specifically, firstly, based on the correspondence between the target function and the source code file, the source code file containing the target function is located, and the corresponding source code range is extracted from the source code file. Within the source code range, each code statement is sequentially parsed and its syntax structure is traversed, and the usage of the parsed identifiers is compared one by one with the generated list of optically related identifiers. When a code statement contains an identifier that matches any optically related identifier in the list, the code statement is identified as a target code statement, and its line number position in the source code file and the target function information to which it belongs are recorded. By repeating the above parsing and comparison process for all code statements within the source code range corresponding to the target function, the computing device can completely determine all target code statements in the target function related to optical local maintenance communication.

[0073] S403: Determine the variables used to represent the optical local maintenance session from the target code statements and define them as optical session state variables.

[0074] It should be noted that the optical session state variable refers to the data variable determined from the target code statement to represent the current state of the optical local maintenance session. This variable is used to reflect whether the smart meter has entered the optical local maintenance communication state or exited the state. Its value change corresponds to the opening or closing process of the optical local maintenance session during program execution.

[0075] Specifically, the process involves analyzing each identified target code statement. During analysis, the computing device first reads the data assignment statements, conditional statements, and state update statements within the target code, and identifies the data variables that are assigned values, compared, or used to control program execution branches. Combining the execution order of the target code statements within the target function, the role of each variable in the optical local maintenance communication process is determined. When a variable is used to indicate whether the smart meter has entered or exited the optical local maintenance communication state, and its value changes directly affect the execution of optical communication-related code statements, that variable is identified as representing the optical local maintenance session.

[0076] In this embodiment of the invention, a unified state identifier is used to describe the opening and closing process of the optical local maintenance session during source code analysis, enabling a clear characterization of the state changes of optical communication-related logic in different execution paths. By clearly defining the optical session state variables, it is possible to accurately determine whether the optical local maintenance session is in an open state during execution path analysis. This provides a reliable basis for subsequently determining session opening path segments and filtering execution paths in specific scenarios, avoiding the uncertainty caused by inferring session state solely based on function call order or code location. This allows source code vulnerability detection to be conducted based on clear state determination conditions, improving the accuracy and consistency of analyzing potential security issues in specific operating scenarios.

[0077] In one possible implementation, defining the session initiation path segment based on optical session state variables and control flow information in step S4 specifically includes sub-steps S404 to S406:

[0078] S404: Perform path traversal on the control flow information to obtain a set of execution paths, wherein the set of execution paths includes multiple execution paths.

[0079] It should be noted that path traversal of control flow information refers to deriving different execution routes that a program may take during its execution based on the execution order and branching relationships. The execution path set refers to the collection of multiple execution routes obtained through the above path traversal. Each execution path corresponds to a complete execution order that the program may take during a single run. This execution path consists of several consecutive code statement positions and is used to characterize the program's execution process under specific combinations of conditions.

[0080] Specifically, based on the constructed control flow information, the process of systematically traversing and analyzing the execution structure inside the target function begins with the entry point of the target function. Based on the statement execution order and branch relationships recorded in the control flow information, different execution paths that the program may traverse during execution are gradually deduced. During the traversal, the program continues to expand along each possible branch direction, forming different execution branches when encountering conditional statements or loop structures, until the end point or execution termination point of the target function is reached. While expanding each execution path, the positions of the code statements along the way are recorded according to their execution order, thus forming a complete execution path. By repeating the above traversal and recording process for all possible branches and execution orders in the control flow information, a set of execution paths containing multiple execution paths can be obtained, where each execution path corresponds to a complete execution process that the target function may undergo under different combinations of conditions.

[0081] S405: Determine the path segment in which the optical local maintenance session is in the open state based on the assignment of the optical session state variables in the execution path set.

[0082] It should be noted that the path segment where the optical local maintenance session is in the "open" state refers to a continuous code execution interval determined by execution path analysis during program execution. Within this interval, the variables representing the optical local maintenance session state consistently maintain the "open" value, indicating that the smart meter has entered and is continuously in a state of local communication with the external maintenance terminal via the optical interface during this program execution. The set of code statements corresponding to this path segment reflects the actual execution range of the optical local maintenance communication process during program execution. By identifying and marking this path segment, the specific location of the optical communication-related logic within the complete execution path can be clearly identified, providing a foundation for subsequent analysis of the correlation between the optical local maintenance communication process and the anti-magnetic tampering processing process at the program execution level, as well as for conducting targeted source code vulnerability detection.

[0083] Specifically, the process involves sequentially reading each execution path in the execution path set and analyzing the changes in the optical session state variable along the code statements of that path. First, the location where the optical session state variable is first assigned a value indicating the entry state of the optical local maintenance session is identified within the execution path. This location is then used as the starting point for session initiation, and the process continues tracking the variable's value changes along the execution path. When a subsequent code statement detects that the optical session state variable has been reassigned a value indicating the exit state of the optical local maintenance session, this location is taken as the end point of the session initiation state. The continuous code execution interval from the starting point to the end point is determined as the path segment where the optical local maintenance session is in the initiation state. If no assignment operation indicating the exit state occurs in the execution path, the computing device determines the continuous code execution interval from the session initiation start point to the execution path end point as the path segment where the optical local maintenance session is in the initiation state. By repeating this analysis process for each execution path in the execution path set, the computing device can accurately identify all path segments where the optical local maintenance session is in the initiation state at the path level, providing a reliable basis for subsequent scene path identification based on session initiation path segments.

[0084] S406: Define the path segment in which the optical local maintenance session is in the open state as the session open path segment.

[0085] In this embodiment of the invention, the code segment in which the optical local maintenance session is actually in the open state is accurately defined at the program execution path level, thus clearly expressing the effective execution range of the optical communication process in complex control structures. By combining the value changes of optical session state variables with control flow information, it is possible to distinguish between execution segments during session initiation and non-initiation periods in a multi-branch, multi-path execution environment. This avoids mistakenly including irrelevant code statements in the analysis scope, allowing subsequent analysis of anti-magnetic tampering trigger logic and operational behavior to be limited to the actual session initiation scenario, improving the focus and analysis accuracy of source code vulnerability detection for specific maintenance scenarios.

[0086] S5: Define the scene path for the magnetic optical probe based on the session opening path segment.

[0087] In one possible implementation, S5 specifically includes sub-steps S501 and S502:

[0088] S501: Define the execution path that simultaneously contains the control flow node corresponding to the optical session start point and the control flow node corresponding to the anti-magnetic tampering trigger point as a candidate execution path.

[0089] It should be noted that a candidate execution path refers to a type of execution path selected from the execution path set after traversing the control flow information of the objective function. This type of execution path contains both the control flow node corresponding to the optical session start point and the control flow node corresponding to the anti-magnetic tampering trigger point in the same program execution order. This indicates that the program has entered the optical local maintenance session related processing flow and triggered the anti-magnetic tampering detection or processing logic under this execution path.

[0090] Specifically, execution paths that simultaneously contain control flow nodes corresponding to both the optical session initiation point and the anti-magnetic tampering trigger point are defined as candidate execution paths. This includes a process where, after completing the path traversal of the objective function's control flow information and obtaining the execution path set, the computing device performs a comparative analysis of each execution path in the execution path set. First, it checks whether each execution path contains the control flow node corresponding to the optical session initiation point, and simultaneously checks whether the execution path contains the control flow node corresponding to the anti-magnetic tampering trigger point. When both of the above conditions are met in the same execution path, it indicates that the program has entered both the optical local maintenance session related processing flow and triggered the anti-magnetic tampering processing logic in this execution order. The execution path is then marked and classified as a candidate execution path, thereby filtering out execution paths from the execution path set that may simultaneously involve the optical local maintenance communication flow and the anti-magnetic tampering processing flow.

[0091] S502: In the candidate execution path, when the path segment between the control flow node corresponding to the optical session start point and the control flow node corresponding to the anti-magnetic tampering trigger point is a session opening path segment, the candidate execution path is defined as the magnetic optical probe scene path.

[0092] It should be noted that the magnetic optical probe scenario path refers to the execution path in the candidate execution path that further satisfies the requirement that the path interval between the control flow node corresponding to the optical session start point and the control flow node corresponding to the anti-magnetic tampering trigger point is the optical local maintenance session in the open state. This execution path reflects the specific program operation scenario in which the smart meter triggers the anti-magnetic tampering processing logic during the optical local maintenance session. It is used to characterize the overlapping relationship between the optical communication process and the anti-magnetic tampering processing process at the program execution level when the magnetic optical probe is used.

[0093] Specifically, based on the determined candidate execution paths, each candidate execution path is further analyzed and processed to determine whether the execution path meets the judgment conditions of the magnetic optical probe scenario. First, the control flow node corresponding to the optical session start point and the control flow node corresponding to the anti-magnetic tampering trigger point are located in the candidate execution path, and their order in the execution path is determined. The continuous path interval between the two control flow nodes is extracted, and combined with the value change of the previously determined optical session state variables in the path interval, it is determined whether the path interval belongs to the path segment where the optical local maintenance session is in the open state. When the path interval is determined to be the session open path segment, it indicates that the program triggered the anti-magnetic tampering processing logic during the optical local maintenance session. Based on this, the corresponding candidate execution path is defined as the magnetic optical probe scenario path.

[0094] In embodiments of the present invention, defining the scenario path of the magnetic optical probe can accurately characterize the specific program execution situation at the source code level where the anti-magnetic tampering processing logic is triggered simultaneously during the optical local maintenance session of the smart meter. This effectively associates the originally dispersed optical communication process with the anti-magnetic tampering processing process on the execution path. The clear definition of this type of scenario path can focus the analysis scope of source code vulnerability detection on the execution path that may actually have functional coupling, avoiding generalization analysis of a large number of irrelevant paths, thereby improving the targeting and efficiency of vulnerability detection.

[0095] S6: Generate vulnerability records corresponding to sensitive operations based on the scene path of the magnetic optical probe.

[0096] In one possible implementation, S6 specifically includes sub-steps S601 to S604:

[0097] S601: Based on the line number position of the control flow node contained in the scene path of the magnetic optical probe, extract the code from the source code file set to obtain scene code slices.

[0098] It should be noted that the line number position corresponding to the control flow node in the magnetic optical probe scene path refers to the specific location identifier of each code statement associated with the magnetic optical probe scene path in the source code file. This position is used to accurately locate the actual range of code that the program may execute in this scenario. Scene code slices refer to the set of code statements directly related to the magnetic optical probe scene path extracted from the source code file set based on the line number position. This set of code statements reflects the actual program execution content when the smart meter starts the optical local maintenance session and triggers the anti-magnetic tampering processing logic.

[0099] Specifically, firstly, each control flow node involved in the magnetic optical probe scene path is obtained, and the line number position of each control flow node in its corresponding source code file is determined. Based on the correspondence between line number positions and source code files, the source code file containing the line number position is located in the source code file set, and the code statement corresponding to the line number position is extracted in each source code file. For multiple line number positions involved in the same magnetic optical probe scene path, the corresponding code statements are organized and collected according to their order in the source code files, and code statements from different source code files are uniformly merged. Through the above extraction and organization process, a set of code statements containing only those related to the magnetic optical probe scene path is formed. This set of code statements is the scene code slice, which reflects the source code content that the smart meter may actually execute under this specific scene path.

[0100] S602: Search for anti-magnetic tampering status control statements in the scene code slice.

[0101] It should be noted that anti-magnetic tampering state control statements refer to code statements in the scene code slice used to represent, protect against, or constrain the anti-magnetic tampering processing state. These statements reflect the state control logic applied to the program execution behavior by the smart meter when it detects an abnormal magnetic field.

[0102] Specifically, the process involves analyzing each code statement in the scene code slice in its order within the source code. First, it identifies whether the code statement contains data or status identifiers representing the anti-magnetic tampering state. Then, it analyzes whether the code statement is used to judge, update, or constrain the program execution flow regarding the anti-magnetic tampering state. Conditional statements, status assignment statements, and control statements related to the anti-magnetic tampering processing logic that contain anti-magnetic tampering-related status identifiers are marked, and their use in restricting, controlling, or influencing subsequent operations during program execution is confirmed. By repeating the above identification and analysis process on all code statements in the scene code slice, all code statements reflecting the anti-magnetic tampering state control logic are identified. These code statements are then summarized and recorded as anti-magnetic tampering state control statements, providing clear code evidence for subsequent analysis of whether operational behavior is constrained by the anti-magnetic tampering state.

[0103] S603: Find the sensitive statement corresponding to the sensitive operation from the scene code slice.

[0104] It should be noted that sensitive operations refer to code statements in the source code of a smart meter that are used to perform actions that directly affect metering data, operating parameters, communication configuration, or security status. If such operations are triggered unexpectedly, they may change the operating results or security status of the smart meter.

[0105] It should be noted that sensitive operations refer to sensitive statements in the source code of a smart meter that directly affect metering data, operating parameters, communication configurations, or security-related resources. These statements perform the actual operations during program execution. Sensitive statements typically involve writing critical data, modifying important parameters, changing device status, or calling critical function interfaces. Their execution results will have a substantial impact on the smart meter's operating or security status.

[0106] Specifically, each code statement in the scene code slice is analyzed line by line in the source code in order. First, it's identified whether the code statement involves operations that directly affect smart meter data, operating parameters, communication configurations, or security-related resources. Further, it's determined whether the code statement is used to perform operations such as data writing, parameter modification, status changes, or critical function calls. The code statements performing these operations are located, and their context within the program is used to confirm their actual role in implementing the specific operations during program execution. By repeating the above identification and confirmation process on all code statements in the scene code slice, all sensitive statements corresponding to sensitive operations are completely identified, and these sensitive statements are then summarized and recorded.

[0107] S604: When there is at least one sensitive statement in the scenario code slice, and the execution condition of the sensitive statement does not contain the anti-magnetic tampering state constraint limited by the anti-magnetic tampering state control statement, a vulnerability record corresponding to the sensitive operation is generated.

[0108] It should be noted that anti-magnetic tampering state constraints refer to the anti-magnetic tampering-related state judgment logic in the source code used to restrict or control the execution of sensitive operations. It indicates the restrictions imposed on related operational behaviors when the smart meter is in the anti-magnetic tampering triggered state. The vulnerability record corresponding to a sensitive operation refers to the record information generated when the execution conditions of a sensitive operation are found to be not subject to anti-magnetic tampering state constraints in a specific execution path or scenario code slice. This record describes the location of potential security flaws in the source code and their associated operational behaviors, providing a basis for subsequent vulnerability analysis and detection report generation.

[0109] It should be noted that the execution condition of a sensitive statement refers to the judgment logic or constraint logic in the source code used to control whether the sensitive statement corresponding to the sensitive operation is actually executed. This execution condition is usually composed of condition judgment statements, state variable comparisons, or flow control statements, and its function is to limit the execution of the sensitive statement only when a specific running state or specific scenario is met.

[0110] Specifically, based on the identified sensitive statements, the execution conditions of each sensitive statement in the source code are read one by one. Execution conditions include conditional statements, state variable comparison statements, or flow control statements directly related to the sensitive statement. The execution conditions are compared and analyzed with the identified anti-magnetic tampering state control statements to determine whether there is any judgment logic in the execution conditions used to limit the anti-magnetic tampering state. When it is confirmed that the execution conditions of a sensitive statement do not contain any control logic used to characterize the anti-magnetic tampering state or to restrict operational behavior under anti-magnetic tampering trigger conditions, it is determined that the sensitive statement may still be executed under the anti-magnetic tampering trigger state. Based on the judgment results, a vulnerability record corresponding to the sensitive statement is generated. The vulnerability record records the location of the sensitive statement in the source code file and its scene path in the magnetic optical probe, thereby clearly identifying operational behavior not constrained by the anti-magnetic tampering state in a specific scenario, providing a basis for subsequent vulnerability summarization and detection result output.

[0111] Furthermore, when at least one sensitive statement exists in the scenario code slice, and the execution condition of this sensitive statement does not include anti-magnetic tampering state constraints limited by anti-magnetic tampering state control statements, a vulnerability record corresponding to the sensitive operation is generated. This is because, in this case, the source code already contains operational behaviors that could still be executed under the anti-magnetic tampering trigger scenario. Since the anti-magnetic tampering mechanism is designed to restrict or block operations on critical data and functions when abnormal magnetic fields or tampering behavior are detected, if the execution condition of the sensitive statement is not constrained by the anti-magnetic tampering state, it indicates that in specific scenarios such as magnetic optical probes, the program may execute critical operations without effective restrictions, thus creating a potential security risk. By generating a vulnerability record under this condition, such operational behaviors not protected by the anti-magnetic tampering state can be clearly identified, enabling the source code vulnerability detection results to accurately reflect potential security flaws in smart meters during actual operation, facilitating subsequent targeted risk assessments and corrections.

[0112] In this embodiment of the invention, generating vulnerability records corresponding to sensitive operations can clearly identify potential security risks in specific scenarios at the source code level in a structured manner, thus centralizing risk points that were originally scattered across different code locations. By identifying whether the execution conditions of sensitive statements in the magnetic optical probe scene path are constrained by the anti-magnetic tampering state, and generating corresponding vulnerability records when they are not constrained, it can accurately reflect the risk situation where critical operations may still be executed under the anti-magnetic tampering trigger state. This elevates the source code vulnerability detection results from simple rule alerts to vulnerability descriptions related to actual operating scenarios, helping to improve the pertinence and understandability of vulnerability analysis, and providing clear and traceable basis for subsequent risk assessment and code remediation.

[0113] S7: Generate source code vulnerability detection reports based on vulnerability records corresponding to sensitive operations.

[0114] In one possible implementation, S7 specifically includes sub-steps S701 to S703:

[0115] S701: Based on the path identifier of the scene path of the magnetic optical probe, the vulnerability records corresponding to all sensitive operations are grouped to obtain multiple scene vulnerability groups.

[0116] It should be noted that the path identifier for the magnetic optical probe scenario path refers to the marking information used to distinguish the program execution path under different magnetic optical probe usage scenarios. This marking information is used to characterize the execution path category corresponding to the opening of a specific optical local maintenance session and the triggering of anti-magnetic tampering processing logic in the source code. Scenario vulnerability grouping refers to the grouping result formed by classifying multiple vulnerability records according to their respective magnetic optical probe scenario paths based on the path identifier. Each group corresponds to a specific scenario path.

[0117] Specifically, firstly, all generated vulnerability records are acquired, and the path identifier of the magnetic optical probe scene path associated with each vulnerability record is read. Based on the path identifier, each vulnerability record is compared and categorized. Vulnerability records with the same path identifier are grouped into the same group, while vulnerability records corresponding to different path identifiers are divided into different groups. During the grouping process, the association between each vulnerability record and its corresponding source code location and operational behavior information remains unchanged, thus forming multiple scene vulnerability groups corresponding to different magnetic optical probe scene paths. Through the above grouping process, multiple vulnerability records generated under the same scene path logically form a complete set.

[0118] S702: Generate detection result entries for scenario vulnerability groups.

[0119] It should be noted that the detection result item refers to an independent record unit formed by summarizing the vulnerability analysis results under a certain magnetic optical probe scene path during the source code vulnerability detection process. This record unit is used to describe the vulnerability situation identified under specific scene conditions. Its content includes the code location corresponding to the vulnerability, the associated execution path, and the operation behavior information that is not constrained by the anti-magnetic tampering state.

[0120] Specifically, firstly, for each scenario vulnerability group, all vulnerability records contained in that group are read, and the location of the corresponding source code file, the associated magnetic optical probe scenario path, and the operational behavior not constrained by the anti-magnetic tampering state are organized for each vulnerability record. The vulnerability records in the same scenario vulnerability group are arranged according to their position in the source code, and the arrangement result is associated with the path identifier corresponding to that scenario vulnerability group, forming a result that reflects the vulnerability distribution under that magnetic optical probe scenario path. Through the above summarization and organization process, a detection result entry is generated for each scenario vulnerability group. The detection result entry is used to centrally describe all vulnerabilities identified under a specific magnetic optical probe scenario path, thus providing a clear and structured data foundation for the subsequent generation of source code vulnerability detection reports based on the detection result entries.

[0121] S703: Generate source code vulnerability detection reports based on the detection result entries.

[0122] It should be noted that the source code vulnerability detection report refers to the output result formed by organizing and summarizing multiple detection results. It is used to systematically present the vulnerability detection conclusions of smart meter source code under different scenario paths. Through this report, the distribution of potential security risks in the source code can be intuitively reflected, thereby providing clear rectification basis and analysis reference for developers and security reviewers.

[0123] Specifically, all detection result items are first read one by one, and then sorted and organized according to the path identifiers of the magnetic optical probe scene path, so that the detection result items belonging to different scene paths are clearly distinguished in the report. The vulnerability description information, corresponding source code location, and associated operational behavior of each detection result item are sequentially written into the report content, maintaining the logical independence and integrity between the detection result items. By continuously summarizing all detection result items, a report body is formed that comprehensively reflects the vulnerability distribution of the smart meter source code under different magnetic optical probe scenarios. The report body is then formatted in a standardized way to generate a clear and complete source code vulnerability detection report, which is used to present users with the source code vulnerability detection conclusions obtained based on the magnetic optical probe scene path analysis.

[0124] In this embodiment of the invention, generating a source code vulnerability detection report can systematically summarize and clearly present the scattered detection results generated for different magnetic optical probe scenario paths, allowing the vulnerability information in the source code to be output in a structured and readable form. By using detection result items as the basic building blocks of the report, the distribution of vulnerabilities under different scenario paths can be clearly distinguished in the report, avoiding the mixing of vulnerabilities from different operating conditions and thus avoiding affecting analysis and judgment. This helps users quickly understand the location and causes of security risks in the source code in a specific maintenance scenario, improving the interpretability and applicability of vulnerability detection results, thereby providing direct support for subsequent security reviews, remediation decisions, and code optimization.

[0125] Reference manual attached Figure 2 The diagram shows a schematic representation of a source code vulnerability detection system provided in an embodiment of the present invention.

[0126] This invention provides a source code vulnerability detection system 20, comprising: a processor 201 and a memory 202;

[0127] The memory 202 stores programs or instructions that can run on the processor 201. When the program or instructions are executed by the processor 201, they implement the steps of the above-described source code vulnerability detection method and achieve the same technical effect. To avoid repetition, the present invention will not elaborate further.

[0128] It should be understood that the processor 201 in this embodiment of the invention may be a central processing unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0129] It should also be understood that the memory 202 in the embodiments of the present invention can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous DRAM (DDRSDRAM), enhanced synchronous DRAM (ESDRAM), synchronous linked DRAM (SLDRAM), and direct rambus RAM (DRRAM).

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

[0131] It should be understood that, in various embodiments of the present invention, the order of the above-mentioned process numbers does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0132] Those skilled in the art will 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, or a combination of computer software and electronic hardware. 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 implementations should not be considered beyond the scope of this invention.

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

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

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

[0136] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

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

[0138] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the embodiments of the present invention, and are not intended to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the protection scope of the present invention.

Claims

1. A source code vulnerability detection method, characterized in that, include: S1: Generate semantic judgment results based on the set of source code files of smart meters; S1 specifically includes: S101: Obtain the set of source code files for the smart meter; S102: Perform syntax parsing on each source code file in the source code file set to obtain an identifier set; S103: Perform semantic judgment on the identifiers in the identifier set to obtain the semantic judgment result, wherein the semantic judgment result is an optically related identifier or an anti-magnetic optical tampering related identifier; Among them, optical-related identifiers are used to describe the identifiers of smart meters that communicate locally, interact with data, or perform maintenance operations with external maintenance terminals through optical interfaces; anti-magnetic-optical tampering-related identifiers are used to describe the identifiers of smart meters that detect, record, or process abnormal magnetic fields or tampering behavior. S2: Generate the optical session start point and the anti-magnetic tampering trigger point based on the semantic judgment result; In the source code file, look for code statements containing optical-related identifiers and anti-magnetic tampering-related identifiers to obtain the optical session start point and anti-magnetic tampering trigger point. Among them, the optical session start point refers to the code location in the source code file that first shows the smart meter entering the optical local maintenance communication state; the anti-magnetic tampering trigger point refers to the code location in the source code file that shows the anti-magnetic tampering detection or processing logic being triggered. S3: Construct control flow information based on the optical session start point and the antimagnetic tampering trigger point; S4: Define optical session state variables, and define session initiation path segments based on the optical session state variables and the control flow information; Among them, the optical session state variable is a data variable determined from the target code statement to represent the current state of the optical local maintenance session, which is used to reflect whether the smart meter has entered or exited the optical local maintenance communication state. Defining the session initiation path segment specifically includes: S404: Perform path traversal on the control flow information to obtain an execution path set, wherein the execution path set includes multiple execution paths; S405: Based on the assignment of the optical session state variable in the execution path set, determine the path segment in which the optical local maintenance session is in the open state; S406: Define the path segment in which the optical local maintenance session is in the open state as the session open path segment; S5: Define the scene path for the magnetic optical probe based on the session initiation path segment; Among them, the magnetic optical probe scenario path refers to the execution path in which the path interval between the control flow node corresponding to the optical session start point and the control flow node corresponding to the anti-magnetic tampering trigger point is the optical local maintenance session in the open state. S6: Generate vulnerability records corresponding to sensitive operations based on the scene path of the magnetic optical probe; S6 specifically includes: S601: Based on the line number position of the control flow node contained in the scene path of the magnetic optical probe, the source code file set is extracted to obtain scene code slices; S602: Search for the anti-magnetic tampering status control statement in the scene code slice; S603: Search for the sensitive statement corresponding to the sensitive operation from the scene code slice; S604: When at least one of the sensitive statements exists in the scene code slice, and the execution condition of the sensitive statement does not contain the anti-magnetic tampering state constraint limited by the anti-magnetic tampering state control statement, a vulnerability record corresponding to the sensitive operation is generated. S7: Generate a source code vulnerability detection report based on the vulnerability records corresponding to the sensitive operations.

2. The source code vulnerability detection method according to claim 1, characterized in that, S2 specifically includes: S201: Based on the semantic judgment result, generate a list of optically related identifiers and a list of anti-magnetic tampering related identifiers; S202: In each source code file, find the first code statement that contains the optically related identifiers from the list of optically related identifiers; S203: The line number position of the first code statement in the corresponding source code file is recorded as the starting point of the optical session; S204: In each source code file, find a second code statement that contains the anti-magnetic tampering related identifier from the list of anti-magnetic tampering related identifiers; S205: The line number position of the second code statement in the corresponding source code file is recorded as the anti-magnetic tampering trigger point.

3. The source code vulnerability detection method according to claim 1, characterized in that, S3 specifically includes: S301: Perform syntax parsing on all source code files in the aforementioned source code file set to obtain a function set; S302: Based on the anti-magnetic tampering trigger point and the optical session start point, the functions in the function set are filtered to obtain the target function; S303: Construct the control flow information for the objective function.

4. The source code vulnerability detection method according to claim 3, characterized in that, The optical session state variables defined in S4 specifically include: S401: Define the local communication session between the smart meter and the external maintenance terminal as an optical local maintenance session; S402: In the source code file corresponding to the objective function, find the target code statement of the optical related identifier in the list of optical related identifiers; S403: Determine the variable used to represent the optical local maintenance session from the target code statement, and define it as the optical session state variable.

5. The source code vulnerability detection method according to claim 1, characterized in that, S5 specifically includes: S501: The execution path that simultaneously contains the control flow node corresponding to the optical session start point and the control flow node corresponding to the antimagnetic tampering trigger point is defined as a candidate execution path; S502: In the candidate execution path, when the path segment between the control flow node corresponding to the optical session start point and the control flow node corresponding to the anti-magnetic tampering trigger point is the session opening path segment, the candidate execution path is defined as the magnetic optical probe scene path.

6. The source code vulnerability detection method according to claim 1, characterized in that, Specifically, S7 includes: S701: Based on the path identifier of the scene path of the magnetic optical probe, group the vulnerability records corresponding to all sensitive operations to obtain multiple scene vulnerability groups; S702: Generate detection result entries for each of the aforementioned scenario vulnerability groups; S703: Generate the source code vulnerability detection report based on each of the aforementioned detection result entries.

7. A source code vulnerability detection system, characterized in that, include: Processor and memory; The memory stores programs or instructions that can run on the processor, which, when executed by the processor, implement the steps of the source code vulnerability detection method as described in any one of claims 1 to 6.

Images