A semantic-level embedded system vulnerability detection method and device based on LLM

Abstract

The application discloses a semantic-level embedded system vulnerability detection method and device based on LLM, and aims at the characteristics of an embedded firmware system, and effectively covers the input processing code of a Web interface and a configuration interface by means of a mixed source point identification method to deeply identify semantic input sources based on a uniform resource identifier and a key value mapping in a back-end binary file; the called functions which have no influence on a data stream are marked and processed by means of a function-independent analysis strategy, and the strategy has higher analysis efficiency compared with the strategy of combining a basic flow insensitivity with a key path flow sensitivity in the prior art; the analysis range is strictly limited on the code path directly related to potential vulnerabilities by means of reverse backtracking analysis from a sink point to a source point, and the path explosion problem is avoided; and the precise taint propagation analysis and vulnerability verification are realized by means of session-based interactive judgment and constraint consistency checking, the false positive rate is greatly reduced, and the accuracy and comprehensiveness of vulnerability detection are improved.

Description

Technical Field

[0001] This invention relates to the field of embedded firmware system security technology, and in particular to a semantic-level embedded system vulnerability detection method and apparatus based on LLM. Background Technology

[0002] With the proliferation of IoT devices, embedded firmware system security has become a critical issue. Unlike general-purpose binary programs, embedded firmware systems typically contain multiple interrelated binary files and interact with the outside world through web interfaces or configuration interfaces. Vulnerabilities in firmware, especially tainted vulnerabilities that can be triggered by external input, such as command injection or buffer overflows, can lead to remote control of the device, posing a serious security threat.

[0003] Existing firmware vulnerability analysis techniques are mainly divided into dynamic analysis and static analysis. Dynamic analysis is limited by the low success rate of firmware emulation and insufficient code coverage. Static analysis techniques do not require running firmware and have a wider coverage, but they face serious challenges: First, existing techniques mostly analyze single general binary files, making it difficult to handle cross-process data flows between multiple binary files in embedded firmware systems; second, the need to explore all possible program paths through which user input data may flow results in extremely high computational costs for analysis paths. Existing techniques typically employ a strategy of being insensitive to basic flows combined with being sensitive to critical path flows to mitigate the path explosion problem, but efficiency bottlenecks still exist; furthermore, existing techniques have a relatively generalized identification of input sources, making it difficult to identify semantic input sources specific to embedded firmware systems based on Uniform Resource Identifiers and key-value mappings, leading to the omission of a large amount of hidden Web interface input processing code and resulting in a large number of false negatives; finally, security analysts must manually customize and maintain a large number of rule bases. This reliance on human expertise makes it difficult for analysis tools to be extended to new firmware systems. Summary of the Invention

[0004] The technical problem to be solved by this invention is to provide a semantic-level embedded system vulnerability detection method and apparatus based on LLM. Taking into account the characteristics of embedded firmware systems containing multiple binary files and interacting with the outside world through Web interfaces and configuration interfaces, this invention can deeply identify semantic input sources based on Uniform Resource Identifiers and key-value mappings. It overcomes the path explosion problem of traditional static analysis by using an inter-function independence analysis strategy, thereby achieving efficient and accurate automated detection of embedded firmware system vulnerabilities.

[0005] To address the aforementioned technical problems, a first aspect of this invention discloses a semantic-level embedded system vulnerability detection method based on LLM, the method comprising: S1, acquire firmware binary data information, perform source point identification processing on the firmware binary data information, and obtain a semantic source point data information set; S2, process the firmware binary data information and the semantic source point data information set to obtain the dangerous flow data information set; S3, perform conversational interactive judgment processing on the dangerous flow data information set to obtain target vulnerability detection result information.

[0006] A second aspect of this invention discloses a semantic-level embedded system vulnerability detection device based on LLM, the device comprising: The acquisition module is used to acquire firmware binary data information, perform source point identification processing on the firmware binary data information, and obtain a semantic source point data information set. The first calculation module is used to process the firmware binary data information and the semantic source point data information set to obtain the dangerous flow data information set; The second calculation module is used to perform conversational interactive judgment processing on the dangerous flow data information set to obtain target vulnerability detection result information.

[0007] A third aspect of this invention discloses another semantic-level embedded system vulnerability detection device based on LLM, the device comprising: processor; A memory coupled to the processor stores executable program code; The processor calls the executable program code stored in the memory to execute some or all of the steps of the LLM-based semantic-level embedded system vulnerability detection method disclosed in the first aspect of the present invention.

[0008] The fourth aspect of this invention discloses a computer-readable storage medium storing computer instructions, which, when invoked, are used to execute some or all of the steps of the LLM-based semantic-level embedded system vulnerability detection method disclosed in the first aspect of this invention.

[0009] Compared with the prior art, the embodiments of the present invention have the following beneficial effects: In this embodiment of the invention, firmware binary data information is acquired, and source point identification processing is performed on the firmware binary data information to obtain a semantic source point data information set; the firmware binary data information and the semantic source point data information set are processed to obtain a dangerous flow data information set; the dangerous flow data information set is subjected to conversational interactive judgment processing to obtain target vulnerability detection result information. It is evident that this application, targeting the characteristics of embedded firmware systems, deeply identifies semantic input sources based on Uniform Resource Identifiers and key-value mappings in backend binary files through a hybrid source point identification method, effectively covering the input processing code of Web interfaces and configuration interfaces; it performs unaffected marking processing on called functions that have no impact on the data flow through a function-independent analysis strategy, which has higher analysis efficiency compared to the basic flow insensitivity combined with critical path flow sensitivity strategy used in the prior art; through reverse backtracking analysis from the ingress point to the source point, the analysis scope is strictly limited to code paths directly related to potential vulnerabilities, avoiding path explosion problems; through conversational interactive judgment and constraint consistency checks, accurate taint propagation analysis and vulnerability verification are achieved, significantly reducing the false positive rate and improving the accuracy and comprehensiveness of vulnerability detection. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a flowchart illustrating a semantic-level embedded system vulnerability detection method based on LLM disclosed in an embodiment of the present invention. Figure 2 This is a schematic diagram of the structure of a semantic-level embedded system vulnerability detection device based on LLM disclosed in an embodiment of the present invention; Figure 3 This is a schematic diagram of another semantic-level embedded system vulnerability detection device based on LLM disclosed in an embodiment of the present invention. Detailed Implementation

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

[0013] The terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion.

[0014] Specific features, structures, or characteristics described in connection with the embodiments may be included in at least one embodiment of the invention. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment that is mutually exclusive with other embodiments.

[0015] Example 1 Please see Figure 1 , Figure 1 This is a flowchart illustrating a semantic-level embedded system vulnerability detection method based on LLM disclosed in an embodiment of the present invention. Wherein, Figure 1 The described LLM-based semantic-level embedded system vulnerability detection method is applied in vulnerability detection devices, such as local servers or cloud servers used for firmware security analysis, etc., and the embodiments of this invention are not limited thereto. Figure 1 As shown, the method includes: S1, acquire firmware binary data information, perform source point identification processing on the firmware binary data information, and obtain a semantic source point data information set.

[0016] It should be noted that the firmware binary data information refers to the collection of firmware program files in the embedded firmware system, including but not limited to router firmware, industrial control equipment firmware, etc. Unlike general binary files, the embedded firmware system contains several interrelated binary files that work together through inter-process communication mechanisms to achieve device functions.

[0017] It should be noted that the semantic source point data information set includes several semantic source point data information sets, each containing a function identifier and a sensitive parameter identifier. The function identifier represents the name or address of a function in the firmware binary file that receives external input, such as a Web interface processing function or a configuration parameter parsing function. The sensitive parameter identifier represents the position or name of a parameter in the function that receives external input data, such as HTTP request parameters or configuration key-value pair parameters. The semantic source point data information refers to the entry point information where external data enters the program. This includes not only general network input sources and file input sources, but also, in particular, semantic input sources based on Uniform Resource Identifiers / key-value mappings. These semantic input sources are the main data entry points for Web interfaces and configuration interfaces in embedded firmware systems.

[0018] S2, process the firmware binary data information and the semantic source point data information set to obtain the dangerous flow data information set.

[0019] It should be noted that the dangerous flow data information set includes several dangerous flow data information, and each dangerous flow data information represents a potential attack path from semantic source point data information to vulnerability sink point data information.

[0020] S3, perform conversational interactive judgment processing on the dangerous flow data information set to obtain target vulnerability detection result information.

[0021] It should be noted that the aforementioned conversational interactive judgment processing refers to constructing the dangerous flow data information into a structured prompt sequence, engaging in multi-turn conversational interaction with the large language model, and guiding the large language model to perform taint propagation analysis, cleanup analysis, and constraint consistency checks. The target vulnerability detection result information includes information such as vulnerability type, vulnerability location, attack path, and risk level.

[0022] As can be seen, the semantic-level embedded system vulnerability detection method based on LLM described in this embodiment of the invention, tailored to the characteristics of embedded firmware systems, deeply identifies semantic input sources in the backend binary files based on Uniform Resource Identifiers and key-value mappings through source point identification; it performs reverse backtracking and function call chain data information generation through sink point identification and combined with inter-function irrelevance analysis strategies, limiting the analysis scope to code paths related to potential vulnerabilities; and it achieves accurate vulnerability verification through conversational interactive judgment, significantly improving the efficiency and accuracy of embedded firmware system vulnerability detection.

[0023] In an optional embodiment, the source point identification processing of the firmware binary data information to obtain a semantic source point data information set includes: S11, perform general source point identification processing on the external functions in the firmware binary data information to obtain a general source point data information set.

[0024] It should be noted that the external functions refer to external library functions or system call functions called in the firmware binary file. These functions are not functions defined by the firmware itself, but come from external linked libraries, such as the libc standard library function recv, and system call functions read and write. The general source point data information refers to general, non-semantic external input source information, such as the source point information corresponding to the network receiving function recv and the file reading function fread. The representation of the general source point data information set is as follows: ,in This is a function identifier, representing the name or address of a function in the firmware binary file that receives external input; The sensitive parameter identifier indicates the position or name of the parameter in the function that receives external input data.

[0025] It should be noted that the above-mentioned general source point identification processing can be performed using DeepSeek, GPT, etc., but the specific implementation of this invention is not limited.

[0026] S12, perform semantic pattern analysis on the firmware binary data information to obtain a set of semantic source point candidate data information.

[0027] It should be noted that the semantic pattern analysis processing described herein is a deep analysis of the Web interface and configuration interface specific to embedded firmware systems. Specifically, this semantic pattern analysis processing refers to simulating human expert perception of code semantics, searching for Uniform Resource Identifier (URI) strings and key-value strings in the backend binary file, and identifying their binding code. The URI string refers to the string used in the embedded firmware system to identify the location of Web interface resources, such as " / api / login". The key-value string refers to the key name string used for passing configuration parameters, such as "username" and "password". The binding code includes three categories: the first category is registration functions, used to bind URIs to processing functions; the second category is constant data, used to store URIs and key-value strings in data areas; and the third category is process creation-related code, used to start child processes that handle specific requests.

[0028] It should be noted that the above semantic pattern analysis and processing can be performed using large language models such as DeepSeek and GPT. Specifically, the embodiments of the present invention do not limit the specifics.

[0029] S13, perform intersection processing on the general source point data information set and the semantic source point candidate data information set to obtain the semantic source point data information set.

[0030] It should be noted that the intersection processing effectively eliminates false alarms, ultimately generating a high-precision semantic source point data information set. Through intersection processing, it can be ensured that the identified semantic source point data information is both universal and semantically relevant. Unlike source point identification methods targeting single general binary files, the hybrid source point identification method of this invention can deeply identify semantic input sources based on Uniform Resource Identifiers and key-value mappings in embedded firmware systems, effectively covering the input processing code of Web interfaces and configuration interfaces.

[0031] It should be noted that the above intersection processing can be performed using set operation libraries, data processing tools, or set operation functions built into programming languages. Specifically, the embodiments of the present invention do not limit this.

[0032] As can be seen, the LLM-based semantic-level embedded system vulnerability detection method described in this embodiment of the invention, through a hybrid source identification method, combines general source data information identification with semantic pattern analysis for embedded firmware systems, and can comprehensively identify external input sources in the firmware, especially semantic input sources related to Web interfaces and configuration interfaces, thereby improving the coverage and accuracy of source identification.

[0033] In another optional embodiment, the semantic pattern analysis processing of the firmware binary data information to obtain a set of semantic source point candidate data information includes: S121, perform string scanning processing on the backend binary file in the firmware binary data information to obtain a set of Uniform Resource Identifier string data information and a set of key-value string data information.

[0034] It should be noted that the backend binary file refers to the binary file in the embedded firmware system responsible for receiving and processing external network requests, typically including web server processes, CGI handlers, etc. The Uniform Resource Identifier (URI) string refers to the string used in the embedded firmware system to identify the location of web interface resources, such as " / api / login". The key-value string refers to the key name string used for passing configuration parameters, such as "username" and "password". Unlike general binary file analysis, this invention focuses on the strings related to the web interface and configuration interface in the backend binary file, specifically tailored to the characteristics of embedded firmware systems.

[0035] It should be noted that the above string scanning process can use the KMP algorithm, the string extraction function of IDA Pro, etc., and the specific implementation of this invention is not limited.

[0036] S122, perform binding code recognition processing on the Uniform Resource Identifier string data information set and the key-value string data information set to obtain a binding code data information set.

[0037] It should be noted that the binding code refers to program code associated with a Uniform Resource Identifier (URI) or key-value string. The binding code identification and processing specifically includes three aspects: First, identifying registration functions, i.e., identifying the code that binds the URI to a processing function, such as the function call code for `formDefine` commonly found in router firmware; second, identifying constant data, i.e., identifying the data area storing the URI and key-value string and its reference code; and third, identifying process creation-related code, i.e., identifying the code that starts a child process to handle a specific request through system calls such as `fork` and `exec`.

[0038] It should be noted that the above-mentioned binding code recognition processing can be performed using large language models such as DeepSeek and Kimi K2. Specifically, the embodiments of the present invention do not limit this.

[0039] S123, perform semantic source point extraction processing on the binding code data information set to obtain a semantic source point candidate data information set.

[0040] It should be noted that the semantic source point extraction process refers to extracting the functions that receive external input and their sensitive parameters from the binding code. By analyzing the data flow of the binding code, the specific location and parameters of the external input data entering the program can be determined.

[0041] It should be noted that the above semantic source point extraction process can be processed using data flow analysis algorithms, static analysis tools, etc., and the specific implementation of this invention is not limited thereto.

[0042] As can be seen, the semantic-level embedded system vulnerability detection method based on LLM described in the embodiments of the present invention can deeply identify semantic source data information based on Uniform Resource Identifier and key-value mapping in the backend binary file through semantic pattern analysis of the embedded firmware system, effectively covering the input processing code of Web interface and configuration interface. Compared with the source identification method for general binary file, it significantly improves the depth and coverage of source identification.

[0043] In another optional embodiment, the processing of the firmware binary data information and the semantic source data information set to obtain the dangerous flow data information set includes: S21, perform sink point identification processing on the firmware binary data information to obtain a vulnerability sink point data information set.

[0044] It should be noted that the vulnerability repositories data information set includes several vulnerability repositories data information, and each vulnerability repositories data information includes the call location, repository function, and actual parameters.

[0045] S22, the semantic source data information set and the vulnerability sink data information set are processed to obtain the danger flow data information set.

[0046] It should be noted that the reverse backtracking process refers to the analysis process of tracing the data source backward from the vulnerability sink data information along the data dependency relationship. The function call chain data information refers to the sequence of function calls from the semantic source data information to the vulnerability sink data information.

[0047] As can be seen, the semantic-level embedded system vulnerability detection method based on LLM described in the embodiments of the present invention, by identifying sinks and combining reverse backtracking and function call chain data information generation, limits the analysis scope to code paths directly related to potential vulnerabilities, avoids the path explosion problem, and significantly improves analysis efficiency.

[0048] In an optional embodiment, the process of performing sink point identification on the firmware binary data information to obtain a vulnerability sink point data information set includes: S211, the firmware binary data information is preprocessed to obtain the external link function list data information.

[0049] S212, perform sink point identification processing on the external link function list data information to obtain the sink point function data information set.

[0050] It should be noted that the sink point identification process employs role assignment and single-sample learning strategies to construct prompts, guiding the large language model to determine whether each external function is potential vulnerability sink point data information. The representation of the sink function data information set is as follows: , where f is a function identifier, representing the name or address of a dangerous function in the firmware binary file that may be exploited by malicious input, such as command execution functions system, execve, popen, etc., file operation functions fopen, fwrite, etc., and format string functions printf, sprintf, etc.; This serves as a sensitive parameter identifier, indicating the position or name of the parameter that receives external input data within the function. Examples include the first parameter `command` (command string) of the `system` function and the second parameter `argv` (parameter array) of the `execve` function. This set can be cached and reused to improve analysis efficiency.

[0051] It should be noted that the above sink identification process can be performed using DeepSeek, Kimi K2, or other large language models with code analysis capabilities. Specifically, the embodiments of the present invention do not limit this.

[0052] S213, perform call point location processing on the firmware binary data information and the sink function data information set to obtain the vulnerability sink data information set.

[0053] It should be noted that the call point location processing refers to traversing the firmware code, searching for the call points of all aggregate functions in the aggregate function data set, and generating a list of vulnerable targets. The representation of the vulnerability aggregate data set is as follows: Where Loc is the call location, representing the call address or code location of the sink function in the firmware binary file, such as the address of the function call instruction, the line number of the source code, etc.; sink is the sink function, representing the name or address of a dangerous function that may be exploited by malicious input, such as the command execution functions system, execve, etc.; Arg is the actual parameter passed to the sink function, representing the variables or expressions passed when calling the sink function. These parameters may contain data from external input, such as the command string variable passed when calling the system function, the parameter array passed when calling the execve function, etc.

[0054] It should be noted that the above-mentioned call point location processing can be performed using disassemblers, static analysis tools, control flow analysis algorithms, or function call graph analysis tools. Specifically, this embodiment of the invention does not limit the specific methods used.

[0055] As can be seen, the semantic-level embedded system vulnerability detection method based on LLM described in the embodiments of the present invention can automatically identify potential vulnerability sink data information and its sensitive parameters through automated sink identification based on a large language model, without the need for manual customization of rule base, thereby improving the degree of automation of analysis.

[0056] In another optional embodiment, the preprocessing of the firmware binary data information to obtain the external link function list data information includes: S2111, the firmware binary data information is disassembled to obtain assembly code data information.

[0057] It should be noted that the above disassembly processing can be performed using disassembly tools such as IDA Pro and Ghidra. Specifically, the embodiments of the present invention do not limit the scope of the disassembly process.

[0058] S2112, the assembly code data information is decompiled to obtain decompiled code data information.

[0059] It should be noted that the decompilation process involves converting assembly code into high-level language pseudocode to facilitate subsequent semantic analysis. It should also be noted that the above decompilation process can be performed using decompilation tools such as RetDec, Ghidra, and Hex-Rays; however, this embodiment of the invention does not impose specific limitations.

[0060] S2113, perform external function extraction processing on the decompiled code data information to obtain external link function list data information.

[0061] It should be noted that the external functions referred to are external library functions or system call functions called in the firmware binary file. These functions are not functions defined by the firmware itself, but come from external linked libraries. Specifically, the external functions include, but are not limited to: the first category being libc standard library functions, file operation functions fread and fwrite, string processing functions strcpy and strcat, and memory operation functions malloc and memcpy; the second category being system call functions, such as Linux system calls open, execve, and fork; and the third category being other external library functions, such as network library functions and SSL library functions. It should be noted that the above-mentioned external function extraction process can be performed using static analysis tools such as Ghidra, IDA Pro, or angr. Specifically, this embodiment of the invention does not limit the specific methods used.

[0062] As can be seen, the LLM-based semantic-level embedded system vulnerability detection method described in the embodiments of the present invention provides an analyzable code foundation for subsequent sink identification by disassembling and decompiling the firmware binary file.

[0063] In another optional embodiment, the processing of the semantic source data information set and the vulnerability sink data information set to obtain the danger flow data information set includes: S221, perform reverse data dependency slicing on each vulnerability sink data information in the vulnerability sink data information set to obtain a function call chain data information set; the function call chain data information set includes several function call chain data information; It should be noted that the reverse data dependency slicing process refers to starting from the vulnerability sink data information, first performing flow-insensitive and path-insensitive intra-function data dependency analysis to trace the actual parameters of the vulnerability sink data information. When the parameters depend on the parameters of the current function, inter-function analysis is performed, recursively tracing back to the caller to construct function call chain data information. Unlike existing analysis methods targeting a single general binary file, this invention addresses the characteristic of embedded firmware systems containing multiple binary files, enabling data dependency analysis across multiple binary files and tracing cross-process data flows.

[0064] S222, perform matching processing on the function call chain data information set and the semantic source point data information set to obtain a candidate dangerous flow data information set; the candidate dangerous flow data information set includes several candidate dangerous flow data information; It should be noted that the matching process refers to checking whether the functions in the function call chain data information call any semantic source point data information identified in the semantic source point library. If a function call chain data information contains both semantic source point data information and vulnerability sink data information, and reverse slicing analysis confirms that there is a data dependency between the two, it is marked as a candidate dangerous flow data information.

[0065] S223, perform deduplication processing on the candidate hazardous flow data information set to obtain the hazardous flow data information set.

[0066] It should be noted that the deduplication process includes operations such as removing subchains to avoid repeatedly analyzing the same attack paths. It should also be noted that the above deduplication process can use set deduplication methods, graph matching algorithms, or path matching methods; specifically, this embodiment of the invention does not limit the specific methods used. Specifically, the subchain removal operation means that if all functions in a function call chain are contained within another, longer function call chain, the shorter function call chain (subchain) is removed, and only the longer function call chain (parent chain) is retained, thus avoiding repeated analysis of the same attack paths.

[0067] As can be seen, the LLM-based semantic embedded system vulnerability detection method described in this embodiment of the invention, by tracing back from the ingress point and generating function call chain data information, limits the analysis scope to code paths directly related to potential vulnerabilities, avoids the path explosion problem, and significantly improves analysis efficiency.

[0068] In an optional embodiment, the step of performing reverse data dependency slicing on each vulnerability sink data information in the vulnerability sink data information set to obtain a function call chain data information set includes: S2211, Perform intra-function data dependency analysis on the vulnerability sink data information to obtain intra-function dependency data information.

[0069] S2212, determine whether the dependent data information within the function depends on the parameters of the current function, and obtain the first determination result; When the first judgment result is yes, the function dependency data information is processed by inter-function recursive backtracking to obtain function call chain data information. When the first judgment result is negative, the current function is processed to construct the call chain, and the function call chain data information is obtained.

[0070] It should be noted that the "current function" refers to the function being analyzed, i.e., the function containing vulnerability endpoint data information. In the reverse data dependency slicing analysis process, starting from the vulnerability endpoint data information, data dependency analysis is first performed within the function containing that vulnerability endpoint data information; this function is the "current function." The parameters of the current function refer to its formal parameters, i.e., its input parameters.

[0071] It should be noted that determining whether the dependent data information within the function depends on the parameters of the current function refers to using data flow analysis techniques to check whether the data source of the dependent data information within the function directly or indirectly comes from the input parameters of the current function. Specific determination methods include: tracing the data flow of the dependent data information within the function and checking whether it has a data dependency relationship with the formal parameters of the current function. If a data dependency relationship exists (e.g., the dependent data information within the function is a direct use of formal parameters, the assignment target of formal parameters, or a variable calculated through formal parameters), it is determined to be dependent on the parameters of the current function; if no data dependency relationship exists (e.g., the dependent data information within the function originates from local variable initialization, global variable reading, constant values, etc.), it is determined to be independent of the parameters of the current function.

[0072] It should be noted that the aforementioned call chain construction process refers to the process of constructing function call chain data information that contains only the current function. When the dependent data information within a function does not depend on the parameters of the current function, it indicates that the data source is within the current function (such as local variables, global variables, constants, etc.), and there is no need for backtracking between functions. In this case, a function call chain data information containing only the current function is created, and the current function is the endpoint of the function call chain data information.

[0073] It should be noted that when the dependent data information within the function depends on the parameters of the current function, it means that the data source is in the input parameters of the current function. This requires inter-function analysis, recursively tracing back to the caller, and continuing to track the data source until the semantic source data information is found or the analysis boundary is reached.

[0074] As can be seen, by implementing the LLM-based semantic embedded system vulnerability detection method described in this embodiment of the invention, the function call chain data information from vulnerability sink data information to semantic source data information can be accurately constructed through data dependency analysis within and between functions.

[0075] In another optional embodiment, the step of performing inter-function recursive backtracking processing on the function dependency data information to obtain function call chain data information includes: S22121, preset backtracking depth k=1.

[0076] S22122, the dependent data information within the function is processed to obtain the called function data information of the kth called function.

[0077] It should be noted that the process of obtaining the called functions refers to identifying and extracting information about all called functions from the decompiled code of the current function using a static analysis algorithm. This process can be performed using static analysis tools such as Ghidra, IDA Pro, angr, or Radare2; however, this embodiment of the invention does not impose specific limitations. The called function data information refers to the relevant information of the function called by the current function, including function identifiers, function parameters, and function call locations.

[0078] It should be noted that, in a vulnerability detection scenario, the data flow refers to the data transmission path from external input (semantic source data information) to a dangerous operation (vulnerability sink data information). By tracing the data flow, it is possible to determine whether the external input can reach the dangerous operation point, thereby identifying potential security vulnerabilities.

[0079] S22123, determine whether the data information of the kth called function affects the data stream, and obtain the second judgment result; When the second judgment result is yes, the data information of the kth called function is analyzed and processed in depth to obtain the kth analysis result data information; When the second judgment result is negative, the data information of the kth called function is marked as having no impact, and the kth unaffected marked data information is determined to be the kth analysis result data information.

[0080] It should be noted that the above determination of whether the data information of the k-th called function affects the data flow refers to checking two conditions: first, whether a pointer to the currently tracked value is passed as a parameter to the called function; second, whether the return value of the called function is ultimately used by the vulnerability repository data information. If at least one condition is met, it is determined that it affects the data flow, and the judgment result is yes; otherwise, the judgment result is no. The in-depth analysis processing refers to performing internal data flow analysis on the called function, tracing the propagation path of data within the function, and the k-th analysis result data information includes the function identifier of the called function, data dependencies, and caller information. The no-impact marking processing refers to directly marking the function as having no impact on the data flow without analyzing the internal logic of the called function. The k-th no-impact marking data information includes the function identifier of the called function and the no-impact mark, and the no-impact mark is used to indicate that the function is determined to have no impact on the data flow in the data flow analysis.

[0081] S22124, determine whether the kth analysis result data information has reached the backtracking boundary, and obtain the third judgment result; When the third judgment result is negative, increment k by 1 and execute S22122; When the third judgment result is yes, the call chain construction process is performed on the first analysis result data information to the kth analysis result data information to obtain the function call chain data information.

[0082] It should be noted that the backtracking boundary refers to one of the following situations: semantic source point data information has been found, the program entry function has been reached, or the current function has no caller. The call chain construction process refers to organizing all functions recorded during the backtracking process into function call chain data information according to the calling order.

[0083] It should be noted that the function independence analysis strategy employed in this invention differs from the existing strategy of combining basic flow insensitivity with critical path flow sensitivity. Existing technologies typically perform basic flow insensitivity analysis on all code paths, followed by flow-sensitive analysis on the identified critical paths. This strategy still faces efficiency bottlenecks when processing large numbers of binary files in embedded firmware systems. The function independence analysis strategy of this invention quickly determines whether a called function affects the data flow, marking irrelevant functions as having no impact without in-depth analysis, thus avoiding the exploration of irrelevant code paths and significantly improving analysis efficiency while maintaining analysis accuracy.

[0084] As can be seen, the semantic-level embedded system vulnerability detection method based on LLM described in this embodiment of the invention can quickly identify called functions that have no impact on the data flow and perform non-impact marking processing through the function independence analysis strategy, effectively reducing unnecessary analysis overhead. Compared with the basic flow insensitivity combined with critical path flow sensitivity strategy used in the prior art, it has higher analysis efficiency when processing embedded firmware systems.

[0085] In another optional embodiment, the matching process of the function call chain data information set and the semantic source point data information set to obtain the candidate dangerous flow data information set includes: S2221, perform source point matching processing on any function call chain data information in the function call chain data information set to obtain the source point matching result data information of the function call chain data information.

[0086] S2222, perform confidence calculation on the function call chain data information and the source point matching result data information of the function call chain data information to obtain the dangerous flow confidence value.

[0087] It should be noted that the above calculation and processing can be performed using a hazard flow confidence calculation model, or using support vector machines, random forests, Bayesian inference, confidence interval estimation, etc. The specific implementation of this invention is not limited.

[0088] The confidence calculation model for the hazardous flow is as follows: ; ; ; In the formula, CF is the confidence value of the dangerous flow. The number of semantic source point data information matched. This represents the total number of functions contained in the function call chain data. For data dependency depth, This is the length of the function call chain data. For call hierarchy depth, As the attenuation factor, , and These are the first weight parameter, the second weight parameter, and the third weight parameter, respectively. , , .

[0089] It should be noted that the above It is the number of functions identified in the function call chain data information that match the semantic source point data information set. This refers to the total number of functions contained in the function call chain data information. This refers to the depth of data dependency between vulnerability sink data and semantic source data, i.e., the number of variable assignments or calculations performed on the data during its propagation. This refers to the length of the function call chain data information, that is, the number of functions in the call chain. This refers to the call hierarchy depth from the program's entry function to the function containing the vulnerability's data.

[0090] It should be noted that the aforementioned hazard flow confidence calculation model comprehensively considers three factors: source point matching rate, data dependency density, and call depth. Source point matching rate ( The higher the data dependency density (), the stronger the correlation between the function call chain data information and the known semantic source point data information; A higher value indicates better data flow continuity; a shallower call depth indicates a more direct attack path. The attenuation factor is used to penalize deep calls, and its value is generally between 0.1 and 0.5. The first, second, and third weight parameters can be set according to actual needs. Generally, the first weight parameter ranges from 0.3 to 0.5, the second weight parameter ranges from 0.2 to 0.4, and the third weight parameter ranges from 0.2 to 0.3.

[0091] S2223, determine whether the confidence value of the dangerous flow is greater than the preset confidence threshold, and obtain the fourth judgment result; When the fourth judgment result is yes, the function call chain data information is determined as candidate dangerous flow data information; If the fourth judgment result is negative, the function call chain data information is discarded.

[0092] It should be noted that the preset confidence threshold can be set according to actual needs, and the value is generally between 0.4 and 0.8.

[0093] As can be seen, the semantic-level embedded system vulnerability detection method based on LLM described in the embodiments of the present invention can effectively filter low-confidence function call chain data information by screening candidate dangerous flow data information through dangerous flow confidence calculation model, thereby reducing the workload of subsequent analysis.

[0094] In another optional embodiment, the step of performing conversational interactive judgment processing on the dangerous flow data information set to obtain target vulnerability detection result information includes: S31, perform prompt sequence construction processing on each hazard flow data information in the hazard flow data information set to obtain a prompt sequence data information set.

[0095] It should be noted that the prompt sequence data information set includes several prompt sequence data information, each of which corresponds to a danger flow data information and contains several prompt data information arranged in sequence.

[0096] It should be noted that the aforementioned prompt sequence construction process is a process of decomposing a single hazard flow data information into a prompt sequence of multiple interactive confirmations, specifically including the following steps: First, extracting function call chain data information, semantic source point data information, and vulnerability sink data information from the hazard flow data information; Second, generating code analysis prompts for each key function according to the function order in the function call chain data information; Third, generating taint propagation analysis prompts to trace the propagation path of data from semantic source point data information to vulnerability sink data information; Fourth, generating constraint consistency check prompts to compare front-end constraints and back-end constraints; Fifth, organizing the above prompts into prompt sequence data information according to the execution order.

[0097] It should be noted that the above-mentioned prompt sequence construction process can be processed using GPT, Claude, or other large language models. Specifically, the embodiments of the present invention do not limit this.

[0098] S32, perform conversational analysis processing on the prompt sequence data information set to obtain preliminary analysis result data information.

[0099] S33, perform secondary verification processing on the preliminary analysis result data information and the dangerous flow data information set to obtain the target vulnerability detection result information.

[0100] It should be noted that the secondary verification process confirms and refines the preliminary analysis results, and finally outputs a detection report containing vulnerability type, attack path and risk level.

[0101] As can be seen, the semantic-level embedded system vulnerability detection method based on LLM described in the embodiments of the present invention can guide a large language model to perform accurate taint propagation analysis and vulnerability verification through conversational interaction based on prompt sequences, thereby significantly reducing the false positive rate.

[0102] In another optional embodiment, the step of performing conversational analysis processing on the prompt sequence data information set to obtain preliminary analysis result data information includes: S321, perform taint propagation analysis processing on the prompt sequence data information set to obtain taint propagation path data information.

[0103] It should be noted that the aforementioned taint propagation analysis refers to tracing the propagation path of external input data in the program and marking contaminated variables and expressions.

[0104] It should be noted that the taint propagation path data information includes four fields: taint source identifier, taint sink identifier, propagation path node list, and taint status marker. Specifically, the taint source identifier indicates the location where external input data enters the program, corresponding to the semantic source point data information; the taint sink identifier indicates the location of the dangerous operation that the tainted data ultimately reaches, corresponding to the vulnerability sink data information; the propagation path node list includes all variables, function parameters, and return values ​​that the tainted data passes through during propagation, with each node containing the variable name, its associated function, and code location; and the taint status marker indicates the state of the tainted data at each node, including three states: contaminated, partially contaminated, and uncontaminated.

[0105] It should be noted that the above-mentioned taint propagation analysis and processing can be performed using large language models such as GPT and DeepSeek. Specifically, the embodiments of this invention are not limited to this.

[0106] S322, perform purification analysis on the contamination propagation path data information to obtain purification status data information.

[0107] It should be noted that the purification analysis refers to the security processing of tainted data in the identification program, such as input validation, escape processing, and length checking.

[0108] It should be noted that the purification status data information includes three fields: purification operation list, purification coverage, and residual risk identifier. The purification operation list includes all security processing operations identified in the taint propagation path data information. Each purification operation includes operation type, operation location, operation object, and operation effect. The operation type includes input validation, character escaping, length truncation, type checking, and whitelist filtering, etc. The purification coverage represents the ratio of the number of taint propagation path nodes covered by purification operations to the total number of nodes. The residual risk identifier indicates potential risk points that still exist after purification processing, including unpurified path branches, incomplete purification operations, and circumventable purification logic, etc.

[0109] It should be noted that the above purification analysis and processing can be performed using large language models such as GPT and DeepSeek. Specifically, the embodiments of the present invention do not limit the scope of the analysis.

[0110] S323, The contamination propagation path data and the purification status data are processed to obtain preliminary analysis results data.

[0111] It should be noted that the above constraint consistency check can be performed using rule matching algorithms, constraint solvers, formal verification methods, etc. The specific implementation of this invention is not limited.

[0112] As can be seen, the semantic-level embedded system vulnerability detection method based on LLM described in the embodiments of the present invention can accurately distinguish between the original input that truly constitutes a threat and the input that has been processed for security purposes by combining taint propagation analysis, purification analysis and constraint consistency checks, thereby significantly reducing the false alarm rate.

[0113] In an optional embodiment, the processing of the contamination propagation path data and the purification status data to obtain preliminary analysis result data includes: S3231, Based on the purification status data information, obtain the front-end constraint data information and the back-end constraint data information.

[0114] It should be noted that the front-end constraint data information refers to the constraints on input data at the user interface or interface level, such as input format, length limits, character type limits, etc. The back-end constraint data information refers to the input validation and filtering operations actually executed in the program code.

[0115] It should be noted that the aforementioned front-end constraint data information can be obtained using an HTML parser or a JavaScript static analysis tool; the aforementioned back-end constraint data information can be obtained using abstract syntax tree analysis, data flow analysis, or symbolic execution tools. Specifically, this embodiment of the invention does not limit the specific methods used.

[0116] S3232, Perform constraint inconsistency measurement processing on the front-end constraint data information and the back-end constraint data information to obtain constraint inconsistency measurement value.

[0117] It should be noted that the above-mentioned constraint inconsistency measurement processing can be carried out using a vulnerability risk assessment calculation model, or using an information entropy measurement method, a similarity matching algorithm, or a weighted scoring method. Specifically, the embodiments of the present invention do not limit the specific methods.

[0118] The vulnerability risk assessment calculation model is as follows: ; ; ; In the formula, VR is the constraint inconsistency metric. This refers to the constraint set corresponding to the aforementioned front-end constraint data information. This refers to the constraint set corresponding to the backend constraint data information. The number of elements in the front-end constraint set. The number of elements in the backend constraint set. The difference between the front-end constraint set and the back-end constraint set is the size. The number of front-end constraints not covered by the back-end. Where TP represents the total number of front-end constraints, and TP is the normalized value of the taint propagation path length. , and These are the fourth, fifth, and sixth weight parameters, respectively. To correct the parameters, , , .

[0119] It should be noted that, It is the set of constraint rules in the front-end constraint data information, such as input length limit, character type limit, format requirements, etc. This refers to the set of constraint rules in the backend constraint data information, such as the input validation and filtering operations actually executed in the backend code. This represents the number of constraint rules that exist in the front-end constraint set but not in the back-end constraint set. This refers to the number of constraints in the front-end that are not fully covered or implemented by the back-end code. TP is the normalized length value of the taint propagation path data information, calculated as follows: ,in The length of the list of propagation path nodes in the taint propagation path data information is the number of nodes that the taint data passes through from the semantic source data information to the vulnerability sink data information. The preset maximum path length threshold is 20, for example. The correction parameter... The value is typically between 0.001 and 0.01.

[0120] It should be noted that the above The calculation process is as follows: Iterate through each constraint rule in the front-end constraint set, and check if there is a corresponding implementation or override in the back-end constraint set. If a front-end constraint does not have corresponding validation logic, filtering operations, or security checks in the back-end code, then the constraint is considered not covered. The number of all uncovered front-end constraints is the result. .

[0121] It should be noted that the vulnerability risk assessment calculation model comprehensively considers three factors: constraint difference, constraint coverage, and taint propagation path length. Constraint difference ( The larger the constraint coverage ratio, the more severe the inconsistency between the front-end constraint data and the back-end constraint data; The lower the value, the less complete the backend's implementation of frontend constraints; the larger the taint propagation path length normalized value TP, the larger the attack surface. The fourth, fifth, and sixth weight parameters can be set according to actual needs. Generally, the fourth weight parameter ranges from 0.3 to 0.5, the fifth weight parameter ranges from 0.3 to 0.4, and the sixth weight parameter ranges from 0.1 to 0.3.

[0122] S3233, determine whether the constraint inconsistency metric value is greater than a preset risk threshold, and obtain the fifth judgment result; When the fifth judgment result is yes, preliminary analysis result data information is generated based on the taint propagation path data information, the purification status data information, and the constraint inconsistency metric, and the vulnerability existence identification information in the preliminary analysis result data information is determined to be a potential vulnerability. When the fifth judgment result is negative, preliminary analysis result data information is generated based on the taint propagation path data information, the purification status data information, and the constraint inconsistency metric, and the vulnerability existence identifier information in the preliminary analysis result data information is determined to be non-existent potential vulnerability.

[0123] It should be noted that the preliminary analysis results include five fields: vulnerability presence identifier, taint propagation path summary, cleanup status summary, constraint inconsistency details, and risk level. Specifically, the vulnerability presence identifier indicates the existence of a potential vulnerability; the taint propagation path summary is a key information extraction from the taint propagation path data obtained in S321, including the taint source location, taint sink location, and key propagation nodes; the cleanup status summary is a key information extraction from the cleanup status data obtained in S322, including the number of cleanup operations, cleanup coverage, and residual risk points; and the constraint inconsistency details include the constraint inconsistency metric and a specific list of constraint differences.

[0124] It should be noted that the preset risk threshold can be set according to actual security needs, and the value is generally between 0.3 and 0.7.

[0125] As can be seen, the LLM-based semantic-level embedded system vulnerability detection method described in this embodiment of the invention can objectively assess the vulnerability risk level and improve the accuracy of vulnerability detection by quantifying constraint inconsistencies through a vulnerability risk assessment calculation model.

[0126] In another optional embodiment, the secondary verification processing of the preliminary analysis result data information and the dangerous flow data information set to obtain the target vulnerability detection result information includes: S331, The preliminary analysis result data information is processed to construct a verification prompt, and the verification prompt data information is obtained.

[0127] It should be noted that the verification prompt construction process refers to constructing structured prompt information to guide the large language model to perform secondary verification based on the content of each field in the preliminary analysis results data. The specific processing flow includes: Extracting vulnerability context: Extracting taint propagation path summary and cleanup status summary from the preliminary analysis results data information as vulnerability context information; Code snippet suggestions: Based on the key propagation nodes in the taint propagation path summary, extract the corresponding decompiled code snippets and construct code analysis suggestions; Construct constraint comparison prompts: Based on the list of constraint differences in the constraint inconsistency details, construct comparison prompts between front-end constraints and back-end constraints; Build verification question prompts: Based on the vulnerability identification information and the risk level, build targeted verification questions, requiring the large language model to confirm whether the vulnerability actually exists, analyze the cause of the vulnerability, and assess the severity of the vulnerability.

[0128] It should be noted that the verification prompt data information includes four parts: vulnerability context prompts, code snippet prompts, constraint comparison prompts, and verification question prompts. Specifically, the vulnerability context prompts include background information such as the location of the taint source, the location of the taint sink, the propagation path length, and the cleanup coverage; the code snippet prompts include the decompiled code of key functions related to the vulnerability; the constraint comparison prompts include a list of front-end constraint rules, a list of back-end constraint rules, and explanations of their differences; and the verification question prompts include specific verification questions that require a large language model to answer, such as "Can this taint propagation path be exploited by an attacker?" or "Are existing cleanup measures sufficient to defend against this vulnerability?"

[0129] It should be noted that the above verification prompt construction process can be processed using template filling methods or rule engines. Specifically, the embodiments of the present invention do not limit the specifics.

[0130] S332, perform vulnerability type classification processing on the verification prompt data information to obtain vulnerability type data information.

[0131] It should be noted that the vulnerability type data information is classified according to the general vulnerability enumeration standard, including but not limited to command injection (CWE-77), operating system command injection (CWE-78), buffer overflow (CWE-119), format string vulnerability (CWE-134), etc.

[0132] It should be noted that the above-mentioned vulnerability type classification and processing can be carried out using GPT series, Claude series, or other large language models with code analysis capabilities. Specifically, the embodiments of the present invention do not limit this.

[0133] S333, using a vulnerability comprehensive scoring calculation model, performs comprehensive scoring processing on the vulnerability type data information, the preliminary analysis result data information, and the danger flow data information set to obtain a vulnerability comprehensive score value.

[0134] The vulnerability comprehensive scoring calculation model is as follows: ; ; ; In the formula, VS is the comprehensive vulnerability score, and VR is the constraint inconsistency metric in the preliminary analysis results data. Assign a severity score to the general vulnerability enumeration corresponding to the vulnerability type data information. The highest severity score, For availability scoring, The highest availability score, The number of purification operations is defined in the purification status data information within the preliminary analysis results data information. The total number of operations in the taint propagation path data information within the preliminary analysis results data information. , , and These are the seventh, eighth, ninth, and tenth weight parameters, respectively. , , .

[0135] It should be noted that the above This refers to the severity score given to vulnerability types according to the Common Weakness Enumeration (CWE) standard. For example, command injection (CWE-78) typically has a severity score of 9.8, while buffer overflow (CWE-119) typically has a severity score of 9.0. This is the highest severity score in the general vulnerability enumeration standard, typically set to 10.0. This refers to the exploitability score of a vulnerability, calculated based on factors such as attack vector, attack complexity, and required privileges. Typical exploitability scores range as follows: 9.0 to 10.0 for remote, unauthenticated exploits; 7.0 to 8.0 for remotely authenticated exploits; 5.0 to 6.0 for locally authenticated exploits; and 3.0 to 4.0 for vulnerabilities requiring special conditions. The highest availability score is typically 10.0. The cleanup process typically includes input validation, escape sequences, and length checks. This refers to the total number of operations involved in the aforementioned taint propagation path data information.

[0136] It should be noted that the vulnerability comprehensive scoring calculation model comprehensively considers four factors: constraint inconsistency metric, vulnerability type severity, exploitability, and remediation level. A higher constraint inconsistency metric (VR) indicates a greater vulnerability risk; the vulnerability type severity ratio (VR)... The higher the exploitability ratio, the greater the vulnerability's harm; The higher the level of cleanliness ( ), the easier it is for the vulnerability to be exploited; The lower the value, the less effective the protective measures. The seventh, eighth, ninth, and tenth weighting parameters can be set according to actual needs. Generally, the seventh weighting parameter ranges from 0.2 to 0.3, the eighth weighting parameter ranges from 0.2 to 0.3, the ninth weighting parameter ranges from 0.2 to 0.3, and the tenth weighting parameter ranges from 0.2 to 0.3.

[0137] S334. Based on the comprehensive vulnerability score, the vulnerability type data information, the preliminary analysis result data information, and the danger flow data information set, generate the target vulnerability detection result information.

[0138] It should be noted that the specific processing flow for generating the target vulnerability detection result information includes: Extract basic vulnerability information: Extract vulnerability type identifier (e.g., CWE-78) and vulnerability type name (e.g., operating system command injection) from the vulnerability type data information, and extract vulnerability existence identifier information and risk level from the preliminary analysis result data information; Extract vulnerability location information: Extract the call location of the corresponding semantic source point data information and the call location of the vulnerability sink point data information from the dangerous flow data information set, as the vulnerability location information; Constructing attack path information: Extract the taint source location, taint sink location, and propagation path node list from the taint propagation path data information to construct complete attack path information; Calculate the final risk level: The final risk level is determined based on the comprehensive vulnerability score. When the comprehensive vulnerability score is greater than 0.7, it is considered high risk; when the comprehensive vulnerability score is greater than 0.4 and less than or equal to 0.7, it is considered medium risk; and when the comprehensive vulnerability score is less than or equal to 0.4, it is considered low risk. Generate remediation recommendations: Based on the vulnerability type data, the cleanup status data, and the constraint inconsistency details in the preliminary analysis results data, generate targeted remediation recommendations, including suggested cleanup operation types and constraint checkpoints that need to be strengthened.

[0139] It should be noted that the target vulnerability detection result information includes six fields: vulnerability identifier, vulnerability type, vulnerability location, attack path, risk level, and remediation suggestions. The vulnerability identifier is a unique number identifying the vulnerability, consisting of a vulnerability type identifier and a detection timestamp. The vulnerability type includes a vulnerability type identifier (e.g., CWE-78) and a vulnerability type name (e.g., operating system command injection). The vulnerability location includes the semantic source point location (where external data enters the program) and the vulnerability sink point location (where dangerous function calls are made). The attack path is a complete data flow path from the semantic source point data information to the vulnerability sink point data information, including all functions and variables passed through. The risk level is divided into three levels—high risk, medium risk, and low risk—based on the vulnerability's comprehensive score. The remediation suggestions include suggested cleanup operations (e.g., input validation, character escaping, length checks, etc.), constraint checkpoints that need strengthening (e.g., consistency checks between front-end and back-end constraints), and code modification suggestions (e.g., replacing dangerous functions, adding security checks, etc.).

[0140] As can be seen, the LLM-based semantic-level embedded system vulnerability detection method described in the embodiments of the present invention comprehensively evaluates vulnerabilities through a vulnerability comprehensive scoring calculation model, providing security analysts with comprehensive vulnerability information and risk ratings, and facilitating the prioritization of vulnerability remediation work.

[0141] It should be noted that the effectiveness and efficiency of the method of the present invention are verified through the following experiments: The evaluation metrics include the number of alerts, the number of actual vulnerabilities, the analysis time, and the average analysis time.

[0142] Number of alerts — the number of potential vulnerabilities reported (not the actual number of vulnerabilities).

[0143] Real vulnerability count – The number of real vulnerabilities that have been verified and reported.

[0144] Analysis time — The time required to analyze all firmware for the dataset.

[0145] First, the datasets were selected. This invention chose the Karonte and Juliet datasets. The Karonte dataset contains 49 firmware samples from four different vendors (Netgear, D-Link, TP-Link, and Tenda). For the Juliet dataset, the source code was compiled and analyzed, with comparisons made on two vulnerability type datasets: CWE-78 and CWE-134. In the Karonte evaluation, comparisons were made with Karonte and Arbiter (two static firmware analysis methods) on the Karonte dataset. In the Juliet dataset, comparisons were made only with Arbiter, because Karonte is not suitable for standalone binary firmware analysis.

[0146] Table 1. Results of this invention on the Karonte dataset. Table 2 Results of this invention on the Juliet CWE-78 subset dataset Table 3. Results of this invention on the Juliet CWE-134 subset dataset. The results in Tables 1-3 show that the method of this invention significantly reduces the false alarm rate when the number of alarms is close to or low, while also discovering more vulnerabilities on real firmware. It is worth noting that while increasing the number of vulnerabilities verified, the efficiency of this method in analyzing files is far superior to other methods, demonstrating its superiority in both accuracy and efficiency.

[0147] Example 2 Please see Figure 2 , Figure 2 This is a schematic diagram of the structure of a semantic-level embedded system vulnerability detection device based on LLM disclosed in an embodiment of the present invention. Figure 2 The described LLM-based semantic-level embedded system vulnerability detection device is applied to embedded firmware system security analysis systems, such as local servers or cloud servers used for embedded firmware vulnerability detection. This invention does not limit the application to such applications. Figure 2 As shown, this semantic-level embedded system vulnerability detection device based on LLM includes: The acquisition module 201 is used to acquire firmware binary data information, perform source point identification processing on the firmware binary data information, and obtain a semantic source point data information set. The first calculation module 202 is used to process the firmware binary data information and the semantic source point data information set to obtain the dangerous flow data information set; The second calculation module 203 is used to perform conversational interactive judgment processing on the dangerous flow data information set to obtain target vulnerability detection result information.

[0148] As can be seen, the semantic-level embedded system vulnerability detection device based on LLM described in the embodiments of the present invention can accurately detect security vulnerabilities in embedded firmware systems and reduce false alarm rates by using hybrid source identification, function irrelevance analysis strategy and conversational interactive judgment.

[0149] Example 3 Please see Figure 3 , Figure 3 This is a schematic diagram of another semantic-level embedded system vulnerability detection device based on LLM disclosed in an embodiment of the present invention. Figure 3 The described LLM-based semantic-level embedded system vulnerability detection device is applied to embedded firmware system security analysis systems, such as local servers or cloud servers used for embedded firmware vulnerability detection. This invention does not limit the application to such applications. Figure 3 As shown, this semantic-level embedded system vulnerability detection device based on LLM includes: Processor 301; A memory 302 containing executable program code is coupled to the processor 301; The processor 301 calls the executable program code stored in the memory 302 to execute some or all of the steps of the semantic-level embedded system vulnerability detection method based on LLM described in Embodiment 1.

[0150] As can be seen, the LLM-based semantic-level embedded system vulnerability detection device described in the embodiments of the present invention can accurately detect security vulnerabilities in embedded firmware systems and reduce false alarm rates by using hybrid source identification, inter-function irrelevance analysis strategies, and conversational interactive judgment.

[0151] Example 4 This invention discloses a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements some or all of the steps of a semantic-level embedded system vulnerability detection method based on LLM according to Embodiment 1.

[0152] The computer-readable storage medium includes read-only memory (ROM), random access memory (RAM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electronically erasable rewritable read-only memory (EEPROM), read-only optical disc (CD-ROM) or other optical disc storage, disk storage, magnetic tape storage, or any other computer-readable medium capable of carrying or storing data.

[0153] Example 5 This invention discloses a computer program product, which includes a computer program stored on a computer-readable storage medium. The computer program includes program instructions, which, when executed by a computer, cause the computer to perform some or all of the steps of a semantic-level embedded system vulnerability detection method based on LLM according to Embodiment 1.

[0154] The system embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separate, and the components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0155] Through the detailed description of the above embodiments, those skilled in the art can clearly understand that each implementation method can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, including read-only memory (ROM), random access memory (RAM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electronically erasable rewritable read-only memory (EEPROM), read-only optical disc (CD-ROM) or other optical disc storage, disk storage, magnetic tape storage, or any other computer-readable medium that can be used to carry or store data.

[0156] Finally, it should be noted that the semantic-level embedded system vulnerability detection method based on LLM disclosed in the embodiments of the present invention is only a preferred embodiment of the present invention and is only used to illustrate the technical solution of the present invention, not to limit it. 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. Such 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.

Claims

1. A semantic-level embedded system vulnerability detection method based on LLM, characterized in that, The method includes: S1, acquire firmware binary data information, perform source point identification processing on the firmware binary data information, and obtain a semantic source point data information set; S2, process the firmware binary data information and the semantic source point data information set to obtain the dangerous flow data information set; S3, perform conversational interactive judgment processing on the dangerous flow data information set to obtain target vulnerability detection result information.

2. The LLM-based semantic-level embedded system vulnerability detection method according to claim 1, characterized in that, The source point identification processing of the firmware binary data information to obtain a semantic source point data information set includes: S11, Perform general source point identification processing on the external functions in the firmware binary data information to obtain a general source point data information set; S12, perform semantic pattern analysis on the firmware binary data information to obtain a set of semantic source point candidate data information; S13, perform intersection processing on the general source point data information set and the semantic source point candidate data information set to obtain the semantic source point data information set.

3. The semantic-level embedded system vulnerability detection method based on LLM according to claim 1, characterized in that, The process of processing the firmware binary data information and the semantic source data information set to obtain the dangerous flow data information set includes: S21, perform sink point identification processing on the firmware binary data information to obtain a vulnerability sink point data information set; S22, the semantic source data information set and the vulnerability sink data information set are processed to obtain the danger flow data information set.

4. The LLM-based semantic-level embedded system vulnerability detection method according to claim 3, characterized in that, The process of performing sink point identification on the firmware binary data information to obtain a vulnerability sink point data information set includes: S211, preprocess the firmware binary data information to obtain external link function list data information; S212, perform sink point identification processing on the external link function list data information to obtain a sink point function data information set; S213, perform call point location processing on the firmware binary data information and the sink function data information set to obtain the vulnerability sink data information set.

5. The semantic-level embedded system vulnerability detection method based on LLM according to claim 3, characterized in that, The process of processing the semantic source data information set and the vulnerability sink data information set to obtain the danger flow data information set includes: S221, Perform reverse data dependency slicing on each vulnerability sink data information in the vulnerability sink data information set to obtain a function call chain data information set; S222, perform matching processing on the function call chain data information set and the semantic source point data information set to obtain a candidate dangerous flow data information set; S223, perform deduplication processing on the candidate hazardous flow data information set to obtain the hazardous flow data information set.

6. The semantic-level embedded system vulnerability detection method based on LLM according to claim 1, characterized in that, The process of performing conversational interactive judgment on the dangerous flow data information set to obtain target vulnerability detection result information includes: S31, Perform prompt sequence construction processing on each hazard flow data information in the hazard flow data information set to obtain a prompt sequence data information set; S32, perform conversational analysis processing on the prompt sequence data information set to obtain preliminary analysis result data information; S33, perform secondary verification processing on the preliminary analysis result data information and the dangerous flow data information set to obtain the target vulnerability detection result information.

7. The semantic-level embedded system vulnerability detection method based on LLM according to claim 6, characterized in that, The secondary verification process of the preliminary analysis results data information and the dangerous flow data information set yields the target vulnerability detection results information, including: S331, Perform verification prompt construction processing on the preliminary analysis result data information to obtain verification prompt data information; S332, perform vulnerability type classification processing on the verification prompt data information to obtain vulnerability type data information; S333, using a vulnerability comprehensive scoring calculation model, the vulnerability type data information, the preliminary analysis result data information, and the danger flow data information set are comprehensively scored to obtain a vulnerability comprehensive score value; The vulnerability comprehensive scoring calculation model is as follows: ; ; ; In the formula, VS is the comprehensive vulnerability score, and VR is the constraint inconsistency metric in the preliminary analysis results data. Assign a severity score to the general vulnerability enumeration corresponding to the vulnerability type data information. The highest severity score, For availability scoring, The highest availability score, The number of purification operations is defined in the purification status data information within the preliminary analysis results data information. The total number of operations in the taint propagation path data information within the preliminary analysis results data information. , , and These are the seventh, eighth, ninth, and tenth weight parameters, respectively. , , ; S334. Based on the comprehensive vulnerability score, the vulnerability type data information, the preliminary analysis result data information, and the danger flow data information set, generate the target vulnerability detection result information.

8. A semantic-level embedded system vulnerability detection device based on LLM, characterized in that, The device includes: The acquisition module is used to acquire firmware binary data information, perform source point identification processing on the firmware binary data information, and obtain a semantic source point data information set. The first calculation module is used to process the firmware binary data information and the semantic source point data information set to obtain the dangerous flow data information set; The second calculation module is used to perform conversational interactive judgment processing on the dangerous flow data information set to obtain target vulnerability detection result information.

9. A semantic-level embedded system vulnerability detection device based on LLM, characterized in that, The device includes: processor; A memory coupled to the processor stores executable program code; The processor calls the executable program code stored in the memory to execute the LLM-based semantic-level embedded system vulnerability detection method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions, which, when invoked, are used to execute the LLM-based semantic-level embedded system vulnerability detection method as described in any one of claims 1-7.

Images