Terminal firmware security analysis method, device, equipment, storage medium and product

Abstract

The application discloses a terminal firmware security analysis method, device, equipment, storage medium and product. The method comprises the following steps: acquiring a terminal firmware image corresponding to a task to be executed, and parsing the terminal firmware image into structured data; running the terminal firmware image in a derived sub-agent mode according to the structured data, and constructing a dynamic topology tree based on the derived sub-agent; injecting structured evidence into the sub-agent in the dynamic topology tree, and generating an evidence graph based on the injected dynamic topology tree; and determining a security analysis result of the terminal firmware image based on the evidence graph. By dynamically running the terminal firmware image in a derived sub-agent mode, the task to be executed is decomposed to the sub-agent according to the object layer, which avoids the problem of key path breakage caused by the limitation of the context window of the large model, avoids the omission of hardcoded credentials or cross-component vulnerabilities, and improves the accuracy of terminal firmware security analysis.

Description

Technical Field

[0001] This application relates to the field of security analysis technology, and in particular to a terminal firmware security analysis method, apparatus, device, storage medium and product. Background Technology

[0002] With the rapid advancement of IoT technology and the widespread application of intelligent devices, such as routers and switches, have become crucial components of modern communication hubs. Terminal firmware is the core software of IoT terminals, responsible for their startup, operation, and management. Because terminal firmware typically runs at the lowest level of the IoT terminal and is updated infrequently, its security is easily overlooked, making it a prime target for network attacks.

[0003] With the successful application of large models (such as GPT and BERT) in natural language processing and code analysis, the demand for using large models to conduct security analysis and discover firmware vulnerabilities in terminal firmware is becoming increasingly prominent. However, when performing terminal firmware analysis, existing large model systems cannot maintain a continuous chain of evidence due to the limitations of the context window imposed by the large model, leading to breakage of the critical path and affecting the accuracy of security analysis.

[0004] Therefore, existing technologies still need to be improved and enhanced. Summary of the Invention

[0005] The technical problem to be solved by this application is to provide a terminal firmware security analysis method, apparatus, device, storage medium and product to address the shortcomings of the prior art.

[0006] To address the aforementioned technical problems, the first aspect of this application provides a terminal firmware security analysis method, wherein the terminal firmware security analysis method specifically includes: Obtain the terminal firmware image corresponding to the task to be executed, and parse the terminal firmware image into structured data; The terminal firmware image is run using a derived sub-agent approach based on the structured data, and a dynamic topology tree is constructed based on the derived sub-agent. Structured evidence is injected into the sub-agents in the dynamic topology tree, and an evidence graph is generated based on the injected dynamic topology tree. The security analysis results of the terminal firmware image are determined based on the evidence map.

[0007] In the aforementioned terminal firmware security analysis method, the nodes of the dynamic topology tree are sub-agents, and the edges of the dynamic topology tree are the delegation types when deriving sub-agents. The delegation types include chained delegation and parallel delegation.

[0008] The aforementioned terminal firmware security analysis method, wherein parsing the terminal firmware image into structured data specifically includes: Input the terminal firmware image into the firmware destructuring engine; The firmware deconstruction engine deconstructs the terminal firmware image by classifying it into targets, files, and configuration data, thereby parsing the terminal firmware image into structured data, wherein the structured data includes target structure, file set, and configuration dataset.

[0009] The aforementioned terminal firmware security analysis method, wherein the step of deconstructing the terminal firmware image using the firmware deconstruction engine by category (target, file, and configuration data) to parse the terminal firmware image into structured data specifically includes: The terminal firmware image is parsed using the firmware decomposition engine to obtain the file paths, file contents, and metadata in the terminal firmware image. The firmware destructuring engine constructs the target structure based on the file path; The firmware destructuring engine constructs a file set based on the file content; The firmware deconstruction engine constructs a configuration dataset based on metadata.

[0010] The aforementioned terminal firmware security analysis method, wherein the step of running the terminal firmware image using a derived sub-proxy method based on the structured data specifically includes: A root proxy is constructed based on the structured data, and the root proxy is used as the currently running proxy. Run the currently running agent to derive sub-agents based on the agent information of the currently running agent. Each sub-agent is configured with agent information and delegation type. The agent information includes the agent object and the task target. The delegation type is either chained delegation or parallel delegation. The sub-agent is set as the currently running agent, and the steps for running the currently running agent are executed until the terminal firmware image is finished running.

[0011] The terminal firmware security analysis method further includes, when running the currently running agent to derive sub-agents based on the agent information of the currently running agent, the method further includes: When the delegation type is chained delegation, a delegation depth is configured for the sub-delegates, and this delegation depth is used as the derivation constraint of the chained delegation. The delegation depth of the sub-delegates is the delegation depth of the parent delegate from which the sub-delegates are derived plus one. When the delegate type is parallel delegate, configure the delegate width for the sub-delegates and use this delegate width as the derivation constraint of the parallel delegate.

[0012] The terminal firmware security analysis method, wherein running the currently running agent to derive sub-agents based on the agent information of the currently running agent specifically includes: The delegation type is determined based on the delegation type of the currently running agent and the object type of the delegate object; Sub-agents are derived according to the delegate type, and the delegate targets and delegate objects of the currently running agent are decomposed according to the derived sub-agents, so as to assign task targets and delegate objects to each sub-agent.

[0013] In the aforementioned terminal firmware security analysis method, the proxy type of the sub-agents in the dynamic topology tree is a target proxy, a file proxy, or a function proxy.

[0014] The terminal firmware security analysis method, wherein injecting structured evidence into the sub-agents in the dynamic topology tree specifically includes: Obtain the sub-agents in the dynamic topology tree where an abnormal event has occurred; Obtain the abnormal information of the abnormal event and encapsulate the abnormal information into structured evidence; The structured evidence is injected into the sub-agent that experiences the anomalous event.

[0015] The terminal firmware security analysis method described above, wherein the structured evidence includes file offsets, semantic tags, and tool output hashes.

[0016] In the aforementioned terminal firmware security analysis method, the semantic tags are vulnerability chains or sensitive data.

[0017] The aforementioned terminal firmware security analysis method, wherein generating the evidence graph based on the injected dynamic topology tree specifically includes: Calculate the semantic relevance between any two structured pieces of evidence in a dynamic topology tree; Using structured evidence as nodes and semantic relevance as the basis, edges are constructed between nodes to generate an evidence graph.

[0018] The aforementioned terminal firmware security analysis method, wherein calculating the semantic relevance between any two structured pieces of evidence in the dynamic topology tree specifically includes: For any two structured pieces of evidence, obtain the keywords of the semantic tags in the two structured pieces of evidence respectively; Calculate the intersection-union ratio (CUNR) between keywords of two structured pieces of evidence to obtain the semantic relevance between the two pieces of evidence.

[0019] The aforementioned terminal firmware security analysis method, wherein the construction of edges between nodes based on semantic relevance specifically includes: Compare the semantic relevance between all two pieces of structured evidence with a preset semantic relevance threshold; When the semantic relevance between two structured pieces of evidence is greater than a preset semantic relevance threshold, an edge is constructed between the nodes formed by the two structured pieces of evidence.

[0020] The aforementioned terminal firmware security analysis method, wherein determining the security analysis result of the terminal firmware image based on the evidence graph specifically includes: Based on the evidence graph, an abnormal event chain is determined, and the structured evidence set corresponding to the abnormal event chain is obtained. For each piece of structured evidence in the structured evidence set, the tool signature and / or timestamp continuity of the structured evidence is verified; When each piece of structured evidence passes verification, the chain of anomalous events is treated as a security event to form a security analysis result.

[0021] The terminal firmware security analysis method further includes, in the step of determining the security analysis result of the terminal firmware image based on the evidence graph: Obtain abnormal information about the security event, wherein the abnormal information includes at least one of the following: number of hazard points, attack path length, or evidence verification rate; The risk value is determined based on the anomaly information, and the risk value is added to the security analysis result.

[0022] The terminal firmware security analysis method further includes, during the execution of the terminal firmware image using a derived sub-proxy method based on the structured data: Get the execution steps of each sub-agent and / or the number of execution failures of its derived sub-agents; The sub-agent terminates when the number of execution steps or the number of execution failures meets the preset termination condition.

[0023] The terminal firmware security analysis method, wherein after determining the security analysis result of the terminal firmware image based on the evidence graph, the method further includes: For each security event in the security analysis results, evidence backtracking is performed on the security event using an evidence graph. For security events in the evidence graph that have traceable evidence paths, configure a traceable identifier for the security event; For security events where there is no traceable evidence path in the evidence graph, a non-traceable flag is configured for the security event.

[0024] A second aspect of this application provides a terminal firmware security analysis device, wherein the terminal firmware security analysis device specifically includes: The acquisition module is used to acquire the terminal firmware image corresponding to the task to be executed and parse the terminal firmware image into structured data. The derived module is used to run the terminal firmware image using a derived sub-agent method based on the structured data, and to build a dynamic topology tree based on the derived sub-agent; The injection module is used to inject structured evidence into the sub-agents in the dynamic topology tree and generate an evidence graph based on the injected dynamic topology tree. The determination module is used to determine the security analysis results of the terminal firmware image based on the evidence graph.

[0025] A third aspect of this application provides a computer-readable storage medium storing one or more programs that can be executed by one or more processors to implement the steps in any of the terminal firmware security analysis methods described above.

[0026] A fourth aspect of this application provides an electronic device comprising: a processor and a memory; The memory stores a computer-readable program that can be executed by the processor; When the processor executes the computer-readable program, it implements the steps in any of the terminal firmware security analysis methods described above.

[0027] The fifth aspect of this application provides a computer program product, wherein the computer program product includes a computer program that, when executed by a processor, implements the steps of the terminal firmware security analysis method as described above.

[0028] Beneficial Effects: Compared with existing technologies, this application provides a terminal firmware security analysis method, apparatus, device, storage medium, and product. The method includes obtaining a terminal firmware image corresponding to a task to be executed and parsing the terminal firmware image into structured data; running the terminal firmware image using a derived sub-agent approach based on the structured data, and constructing a dynamic topology tree based on the derived sub-agents; injecting structured evidence into the sub-agents in the dynamic topology tree, and generating an evidence graph based on the injected dynamic topology tree; and determining the security analysis result of the terminal firmware image based on the evidence graph. This application, by dynamically running the terminal firmware image using a derived sub-agent approach, decomposes the task to be executed according to the object layer and assigns it to sub-agents for execution, avoiding the problem of critical path breakage caused by the limitation of the context window by the large model, and avoiding the omission of hard-coded credentials or cross-component vulnerabilities, thereby improving the accuracy of terminal firmware security analysis.

[0029] Meanwhile, by injecting structured evidence into the sub-agents in the dynamic topology tree and generating an evidence graph, this application can more comprehensively analyze the security status of the terminal firmware image, reduce the risk caused by attacks on terminal firmware security vulnerabilities, and ensure the stable operation and data security of IoT devices. Attached Figure Description

[0030] To more clearly illustrate the technical solutions in the embodiments of this application, 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 this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0031] Figure 1 A flowchart illustrating an application scenario of the terminal firmware security analysis method provided in this application embodiment.

[0032] Figure 2 A schematic block diagram of an electronic device provided in an embodiment of this application.

[0033] Figure 3 A flowchart of the terminal firmware security analysis method provided in the embodiments of this application.

[0034] Figure 4 This is a flowchart illustrating the process of building structured data.

[0035] Figure 5 This is a flowchart illustrating step S112.

[0036] Figure 6 A flowchart illustrating the derivation process for a derived child agent.

[0037] Figure 7 This is a flowchart illustrating step S212.

[0038] Figure 8 This is a flowchart illustrating the verification process for a sub-agent.

[0039] Figure 9 This is a flowchart illustrating the process of injecting structured evidence.

[0040] Figure 10 This is a flowchart illustrating the process of generating the evidence map.

[0041] Figure 11 This is a flowchart of step S321.

[0042] Figure 12 This is a flowchart illustrating step S322.

[0043] Figure 13 This is a flowchart illustrating step S40.

[0044] Figure 14 A schematic diagram of the terminal firmware security analysis device provided in the embodiments of this application. Detailed Implementation

[0045] This application provides a terminal firmware security analysis method, apparatus, device, storage medium, and product. To make the objectives, technical solutions, and effects of this application clearer and more explicit, the following detailed description is provided with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only for explaining this application and are not intended to limit this application.

[0046] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the term “comprising” as used in this application means the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. It should be understood that when we say an element is “connected” or “coupled” to another element, it can be directly connected or coupled to the other element, or there may be intermediate elements. Furthermore, “connected” or “coupled” as used herein can include wireless connections or wireless coupling. The term “and / or” as used herein includes all or any units and all combinations of one or more associated listed items.

[0047] It will be understood by those skilled in the art that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the same meaning as in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined as herein.

[0048] It should be understood that the sequence number and size of each step in this embodiment do not imply the order of execution. The execution sequence of each process is determined by its function and internal logic, and should not constitute any limitation on the implementation process of this application embodiment.

[0049] Research has revealed that with the rapid advancement of IoT technology and the widespread application of intelligent devices, such as routers and switches, have become crucial components of modern communication hubs. Terminal firmware is the core software of IoT terminals, responsible for their startup, operation, and management. Because terminal firmware typically runs at the lowest level of the IoT terminal and is updated infrequently, its security is easily overlooked, making it a prime target for cyberattacks.

[0050] With the successful application of large models (such as GPT and BERT) in natural language processing and code analysis, the demand for using large models to conduct security analysis and discover firmware vulnerabilities in terminal firmware is becoming increasingly prominent. However, when performing terminal firmware analysis, existing large model systems cannot maintain a continuous chain of evidence due to the limitations of the context window imposed by the large model, leading to breakage of the critical path and affecting the accuracy of security analysis.

[0051] To address the aforementioned issues, this application embodiment obtains the terminal firmware image corresponding to the task to be executed and parses the terminal firmware image into structured data. Based on the structured data, the terminal firmware image is run using a derived sub-agent approach, and a dynamic topology tree is constructed based on the derived sub-agents. Structured evidence is injected into the sub-agents in the dynamic topology tree, and an evidence graph is generated based on the injected dynamic topology tree. The security analysis result of the terminal firmware image is determined based on the evidence graph. This application, by dynamically running the terminal firmware image using a derived sub-agent approach, decomposes the task to be executed according to the object layer and assigns it to sub-agents for execution. This avoids the problem of critical path breakage caused by the limitation of the context window by a large model, and avoids the omission of hard-coded credentials or cross-component vulnerabilities, thus improving the accuracy of terminal firmware security analysis. Simultaneously, by injecting structured evidence into the sub-agents in the dynamic topology tree and generating an evidence graph, this application can more comprehensively analyze the security status of the terminal firmware image, reduce the risk of attacks due to terminal firmware security vulnerabilities, and ensure the stable operation and data security of IoT devices.

[0052] The application content will be further explained below with reference to the accompanying drawings and through the description of the embodiments.

[0053] Please see Figure 1 , Figure 1 This is an application environment diagram of the terminal firmware security analysis method provided in the embodiments of this application. For example... Figure 1As shown in the diagram, the terminal firmware security analysis system in this application environment includes a user terminal 110 and a server 120. The user terminal 110 and server 120 are connected via a network. The user terminal 110 can be a desktop user terminal 110 or a mobile user terminal 110, and the mobile user terminal 110 can be at least one of a mobile phone, tablet computer, or laptop computer. The server 120 can be implemented as a standalone server 120 or a cluster of multiple servers 120. The user terminal receives a task to be executed from the user input. The server 120 obtains the task to be executed from the user terminal 110, acquires the terminal firmware image corresponding to the task to be executed, and parses the terminal firmware image into structured data. Based on the structured data, the server runs the terminal firmware image using a derived sub-agent approach and constructs a dynamic topology tree based on the derived sub-agents. Structured evidence is injected into the sub-agents in the dynamic topology tree, and an evidence graph is generated based on the injected dynamic topology tree. The security analysis result of the terminal firmware image is determined based on the evidence graph.

[0054] It should be noted that the server is deployed with a multi-intelligent agent system. The root agent and the derived child agents are all intelligent agents of this multi-intelligent agent system. These intelligent agents can be built based on large models, such as GPT, BERT, etc.

[0055] For example, a multi-intelligent agent system may include a firmware deconstruction engine, a dynamic topology construction layer, a hierarchical evidence processing layer, and a security decision output layer. The firmware deconstruction engine obtains the terminal firmware image corresponding to the task to be executed and parses the terminal firmware image into structured data. The dynamic topology construction layer runs the terminal firmware image using a derived sub-agent approach based on the structured data and constructs a dynamic topology tree based on the derived sub-agents. The hierarchical evidence processing layer injects structured evidence into the sub-agents in the dynamic topology tree and generates an evidence graph based on the injected dynamic topology tree. The security decision output layer determines the security analysis result of the terminal firmware image based on the evidence graph. The dynamic topology construction layer may deploy a recursive delegation engine, through which sub-agents are derived.

[0056] Please see Figure 2 , Figure 2 This is a schematic block diagram of the electronic device provided in the embodiments of this application. Figure 2 As shown, the electronic device includes a processor and a memory. The processor 1001 and the memory 1002 are connected by a bus, such as an I2C (Inter-integrated Circuit) bus or a distributed soft bus.

[0057] The memory 1002 may include a non-volatile storage medium and internal memory. The non-volatile storage medium may store an operating system and a computer program. The computer program includes program instructions that, when executed, cause the processor to perform any terminal firmware security analysis method.

[0058] Processor 1001 provides computing and control capabilities to support the operation of the entire electronic device. Processor 1001 can be a Central Processing Unit (CPU), but it can also 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. A general-purpose processor can be a microprocessor or any conventional processor.

[0059] Specifically, the processor 1001 is used to run a computer program stored in memory, and when executing the computer program, it performs the following steps: Obtain the terminal firmware image corresponding to the task to be executed, and parse the terminal firmware image into structured data; The terminal firmware image is run using a derived sub-agent approach based on the structured data, and a dynamic topology tree is constructed based on the derived sub-agent. Structured evidence is injected into the sub-agents in the dynamic topology tree, and an evidence graph is generated based on the injected dynamic topology tree. The security analysis results of the terminal firmware image are determined based on the evidence map.

[0060] In some embodiments, the nodes of the dynamic topology tree are child agents, and the edges of the dynamic topology tree are the delegation types when deriving child agents. The delegation types include chained delegation and parallel delegation.

[0061] In some embodiments, when the processor 1001 parses the terminal firmware image into structured data, it is specifically configured to: Input the terminal firmware image into the firmware destructuring engine; The firmware deconstruction engine deconstructs the terminal firmware image by classifying it into targets, files, and configuration data, thereby parsing the terminal firmware image into structured data, wherein the structured data includes target structure, file set, and configuration dataset.

[0062] In some embodiments, when the processor 1001 deconstructs the terminal firmware image by category (target, file, and configuration data) using the firmware deconstruction engine to parse the terminal firmware image into structured data, it specifically implements the following: The terminal firmware image is parsed using the firmware decomposition engine to obtain the file paths, file contents, and metadata in the terminal firmware image. The firmware destructuring engine constructs the target structure based on the file path; The firmware destructuring engine constructs a file set based on the file content; The firmware deconstruction engine constructs a configuration dataset based on metadata.

[0063] In some embodiments, when the processor 1001 runs the terminal firmware image using a derived sub-agent approach based on the structured data, it is specifically configured to: A root proxy is constructed based on the structured data, and the root proxy is used as the currently running proxy. Run the currently running agent to derive sub-agents based on the agent information of the currently running agent. Each sub-agent is configured with agent information and delegation type. The agent information includes the agent object and the task target. The delegation type is either chained delegation or parallel delegation. The sub-agent is set as the currently running agent, and the steps for running the currently running agent are executed until the terminal firmware image is finished running.

[0064] In some embodiments, when running the currently running agent to derive sub-agents based on the agent information of the currently running agent, the processor 1001 is further configured to implement: When the delegation type is chained delegation, a delegation depth is configured for the sub-delegates, and this delegation depth is used as the derivation constraint of the chained delegation. The delegation depth of the sub-delegates is the delegation depth of the parent delegate from which the sub-delegates are derived plus one. When the delegate type is parallel delegate, configure the delegate width for the sub-delegates and use this delegate width as the derivation constraint of the parallel delegate.

[0065] In some embodiments, when the processor 1001 runs the currently running agent to derive sub-agents based on the agent information of the currently running agent, it is specifically configured to implement: The delegation type is determined based on the delegation type of the currently running agent and the object type of the delegate object; Sub-agents are derived according to the delegate type, and the delegate targets and delegate objects of the currently running agent are decomposed according to the derived sub-agents, so as to assign task targets and delegate objects to each sub-agent.

[0066] In some embodiments, the proxy type of the sub-agents in the dynamic topology tree is a target proxy, a file proxy, or a function proxy.

[0067] In some embodiments, when the processor 1001 injects structured evidence into the sub-agents of the dynamic topology tree, it is specifically configured to: Obtain the sub-agents in the dynamic topology tree where an abnormal event has occurred; Obtain the abnormal information of the abnormal event and encapsulate the abnormal information into structured evidence; The structured evidence is injected into the sub-agent that experiences the anomalous event.

[0068] In some embodiments, the structured evidence includes file offsets, semantic tags, and tool output hashes.

[0069] In some embodiments, the semantic tag is a vulnerability chain or sensitive data.

[0070] In some embodiments, when the processor 1001 generates an evidence graph based on the injected dynamic topology tree, it is specifically configured to: Calculate the semantic relevance between any two structured pieces of evidence in a dynamic topology tree; Using structured evidence as nodes and semantic relevance as the basis, edges are constructed between nodes to generate an evidence graph.

[0071] In some embodiments, when calculating the semantic relevance between any two structured pieces of evidence in a dynamic topology tree, the processor 1001 is specifically configured to: For any two structured pieces of evidence, obtain the keywords of the semantic tags in the two structured pieces of evidence respectively; Calculate the intersection-union ratio (CUNR) between keywords of two structured pieces of evidence to obtain the semantic relevance between the two pieces of evidence.

[0072] In some embodiments, when the processor 1001 constructs edges between nodes based on semantic relevance, it is specifically configured to: Compare the semantic relevance between all two pieces of structured evidence with a preset semantic relevance threshold; When the semantic relevance between two structured pieces of evidence is greater than a preset semantic relevance threshold, an edge is constructed between the nodes formed by the two structured pieces of evidence.

[0073] In some embodiments, when the processor 1001 determines the security analysis result of the terminal firmware image based on the evidence graph, it is specifically configured to: Based on the evidence graph, an abnormal event chain is determined, and the structured evidence set corresponding to the abnormal event chain is obtained. For each piece of structured evidence in the structured evidence set, the tool signature and / or timestamp continuity of the structured evidence is verified; When each piece of structured evidence passes verification, the chain of anomalous events is treated as a security event to form a security analysis result.

[0074] In some embodiments, when determining the security analysis result of the terminal firmware image based on the evidence graph, the processor 1001 is further configured to: Obtain abnormal information about the security event, wherein the abnormal information includes at least one of the following: number of hazard points, attack path length, or evidence verification rate; The risk value is determined based on the anomaly information, and the risk value is added to the security analysis result.

[0075] In some embodiments, during the execution of the terminal firmware image using a derived sub-proxy approach based on the structured data, the processor 1001 is further configured to implement: Get the execution steps of each sub-agent and / or the number of execution failures of its derived sub-agents; The sub-agent terminates when the number of execution steps or the number of execution failures meets the preset termination condition.

[0076] In some embodiments, after determining the security analysis result of the terminal firmware image based on the evidence graph, the processor 1001 is further configured to implement: For each security event in the security analysis results, evidence backtracking is performed on the security event using an evidence graph. For security events in the evidence graph that have traceable evidence paths, configure a traceable identifier for the security event; For security events where there is no traceable evidence path in the evidence graph, a non-traceable flag is configured for the security event.

[0077] Please see Figure 3 , Figure 3This is a flowchart of the terminal firmware security analysis method provided in this embodiment. The method includes obtaining the terminal firmware image corresponding to the task to be executed and parsing the terminal firmware image into structured data; running the terminal firmware image using a derived sub-agent approach based on the structured data, and constructing a dynamic topology tree based on the derived sub-agents; injecting structured evidence into the sub-agents in the dynamic topology tree, and generating an evidence graph based on the injected dynamic topology tree; and determining the security analysis result of the terminal firmware image based on the evidence graph. This application, by dynamically running the terminal firmware image using a derived sub-agent approach, decomposes the task to be executed according to the object layer and assigns it to sub-agents for execution, avoiding the problem of critical path breakage caused by the limitation of the context window by a large model, and avoiding the omission of hard-coded credentials or cross-component vulnerabilities, thus improving the accuracy of terminal firmware security analysis. Simultaneously, by injecting structured evidence into the sub-agents in the dynamic topology tree and generating an evidence graph, this application can more comprehensively analyze the security status of the terminal firmware image, reduce the risk caused by attacks due to terminal firmware security vulnerabilities, and ensure the stable operation and data security of IoT devices.

[0078] like Figure 3 As shown, the terminal firmware security analysis method provided in this application embodiment specifically includes: S10. Obtain the terminal firmware image corresponding to the task to be executed, and parse the terminal firmware image into structured data.

[0079] Specifically, the task to be executed is a terminal firmware security analysis task. This task includes firmware information of the terminal firmware to be analyzed, such as the terminal firmware identifier and version. Therefore, when obtaining the terminal firmware image corresponding to the task, the firmware information is first read, and then the corresponding terminal firmware image is obtained based on this information. For example, it can be read from a preset terminal firmware image database or downloaded from the network. The terminal firmware image refers to a complete copy of the firmware in the terminal device, containing all the software code and configuration information required for the terminal device to run.

[0080] Furthermore, after obtaining the terminal firmware image, it is parsed into structured data. This structured data includes the target structure, file sets, and configuration datasets. In other words, the structured data is formed by deconstructing the terminal firmware image using the target, files, and configuration data as categories.

[0081] In one embodiment, such as Figure 4 As shown, the process of parsing the terminal firmware image into structured data specifically includes: S111. Input the terminal firmware image into the firmware destructuring engine; S112. The terminal firmware image is deconstructed by the firmware deconstruction engine according to the categories of target, file and configuration data, so as to parse the terminal firmware image into structured data.

[0082] Specifically, the firmware decomposition engine is used to convert terminal firmware images into machine-processable structured data to provide environmental constraints for dynamic agent systems. The firmware decomposition engine is a deep learning-based automated parsing tool that can identify binary streams in the terminal firmware image to extract key data. Specifically, the firmware decomposition engine analyzes the terminal firmware image by category—target, file, and configuration data—to determine the directory structure, file sets, and configuration datasets within the image, and then constructs structured data based on these elements.

[0083] In one embodiment, such as Figure 5 As shown, the step of deconstructing the terminal firmware image using the firmware deconstruction engine, categorizing it by target, file, and configuration data, to parse the terminal firmware image into structured data specifically includes: S1121. The terminal firmware image is parsed using the firmware decomposition engine to obtain the file path, file content, and metadata in the terminal firmware image. S1122. Construct the target structure based on the file path using the firmware destructuring engine; S1123. Construct a file set based on the file content using the firmware destructuring engine; S1124. The configuration dataset is constructed based on the metadata using the firmware deconstruction engine.

[0084] Specifically, when parsing a terminal firmware image, the firmware decomposition engine first extracts file paths, file content, and metadata. For file paths, the engine constructs a target structure based on their hierarchical relationships and logical connections, displaying the organizational structure of various files and directories within the terminal firmware. For file collections, the engine categorizes the extracted file content. Specifically, it identifies the file type, such as executable files, configuration files, and data files, and then saves the file content according to file type to form a file collection. This facilitates subsequent targeted analysis and processing of different file types, such as performing security vulnerability detection on executable files and parameter verification on configuration files. For metadata, the engine constructs a configuration dataset based on the data information contained in the metadata. Metadata can include important information such as creation time, modification time, permission settings, and dependencies. By constructing a configuration dataset, the metadata can be presented in a structured manner.

[0085] Based on this, in a specific implementation, the firmware destructuring engine's parsing process can be represented as: , , , , in, This refers to the firmware decomposition engine. This indicates the terminal firmware image. Indicates the target structure. Represents a collection of files. Indicates the configuration dataset, Indicates the file path. Represents a set of file paths. This indicates the file content. Represents the set of file contents. Indicates the file type. Indicates an executable file. Indicates configuration file, Represents a data file. Represents metadata, A key-value set representing metadata. Represents the value of metadata. Key-value pairs representing metadata.

[0086] S20. Run the terminal firmware image using a derived sub-agent method based on the structured data, and construct a dynamic topology tree based on the derived sub-agent.

[0087] Specifically, the nodes of the dynamic topology tree are child agents, and the edges of the dynamic topology tree represent the delegation type when deriving child agents. That is, the dynamic topology tree is constructed with child agents as nodes and the delegation type when deriving child agents as edges. The delegation type of the derived child agent reflects the delegation relationship between the child agent and its parent node. This delegation type includes chained delegation and parallel delegation. Chained delegation refers to a child agent passing the result to the next child agent after completing a task, while parallel delegation involves multiple child agents executing different subtasks simultaneously. Each node in the dynamic topology tree maintains a node state, which includes the node ID, task context, and resource quota.

[0088] It's understandable that when a child proxy has a chained delegation relationship with its parent node, it has no sibling nodes; conversely, when a child proxy has a parallel delegation relationship with its parent node, it has sibling nodes. That is, when a parent node needs to derive a child proxy, the edge between the parent node and its derived child proxy is a chained delegation; when a parent node needs to derive multiple parallel child proxies, the edge between the parent node and each of its derived child proxies is a parallel delegation.

[0089] Based on this, the dynamic topology tree can be represented as: , , , in, Represents a dynamic topology tree. Represents a set of nodes. Denotes the set of edges. Represents a set of proxies. Represents a node. Represents an edge between two nodes. Indicates the type of delegation.

[0090] This application embodiment uses a derived sub-agent approach to decompose the task to be executed according to the object layer, allowing each sub-agent to focus on a specific sub-task, thus avoiding the critical path breakage problem caused by the limitation of the context window by the large model.

[0091] In one embodiment, such as Figure 6 As shown, the step of running the terminal firmware image using a derived sub-proxy method based on the structured data specifically includes: S211. Construct a root proxy based on the structured data, and use the root proxy as the currently running proxy; S212. Run the currently running agent to derive a sub-agent based on the agent information of the currently running agent; S213. The sub-agent is designated as the currently running agent, and the steps of running the currently running agent are executed until the terminal firmware image is finished running.

[0092] Specifically, the root proxy is a top-level proxy built based on structured data, carrying the initial tasks and context for the entire terminal firmware image execution. When creating the root proxy, its proxy information is determined based on the target structure, file set, and configuration dataset in the structured data. This proxy information includes the proxy object and the task target. The proxy object refers to the task data maintained by the root proxy; the proxy object can be a target, file, or function, etc. The task target is the specific task that the root proxy needs to complete, such as file parsing or data processing. Furthermore, since the root node does not have a parent node, it does not need to build edges with its parent node, and therefore, the root node does not need to be configured with a delegation type.

[0093] In one embodiment, such as Figure 7 As shown, the step of running the currently running agent to derive sub-agents based on the agent information of the currently running agent specifically includes: S2121. Determine the delegation type based on the delegation type of the currently running agent and the object type of the agent object; S2122. Derive sub-agents according to the delegate type, and decompose the agent target and agent object of the currently running agent according to the derived sub-agents, so as to assign task targets and agent objects to each sub-agent.

[0094] Specifically, the proxy type is determined based on the data type of the structured data. Proxy types include target proxy, file proxy, and function proxy. The object type of the proxy object refers to the data type of the task data required by the task target to be executed by the currently running proxy. Object types include directory type, file type, and function type. File types can include executable files, configuration files, and data files. In other words, when determining the delegate type, it is based on the proxy type of the currently running proxy and the object type of the proxy object. For example, if the currently running proxy is a directory proxy and the proxy object type is a directory type, considering that there may be multiple files or subdirectories under the directory that need to be processed in parallel, a parallel delegate type might be chosen, deriving multiple sub-proxies to process different files or subdirectories respectively. If the currently running proxy is a file proxy and the proxy object type is an executable file, since the execution of executable files is usually sequential, a chained delegate type would be chosen, processing each part of the executable file sequentially.

[0095] After determining the delegation type, sub-agents are derived according to that delegation type. For parallel delegation, multiple sub-agents are created simultaneously to execute different sub-tasks; for chained delegation, sub-agents are created sequentially, with each sub-agent passing its result to the next after completing its task. Simultaneously, the delegation target and proxy object of the currently running agent are decomposed based on the derived sub-agents. For example, if the delegation target of the currently running agent is to perform security checks on all files in a directory, and the proxy objects are the directory and its contained files, when multiple sub-agents are derived using parallel delegation, the files in that directory are assigned to different sub-agents according to certain rules (such as file type, first letter of filename, etc.). Each sub-agent is responsible for performing security checks on the assigned files; that is, each sub-agent has its own clearly defined task target and proxy object.

[0096] After deriving a sub-agent, the sub-agent is set as the currently running agent, and the step of "deriving a sub-agent from the currently running agent" is repeated until the terminal firmware image execution ends. The dynamic topology tree is built progressively during the sub-agent deriving process: first, the root agent is used as the root node; each time a sub-agent is derived, it is added as a child node of the currently running agent, which then becomes its parent node; simultaneously, the delegation type between the sub-agent and the parent node is used as the edge between them, thus dynamically constructing the topology tree structure, enabling the tree to reflect the execution order and interrelationships of each subtask during the terminal firmware image execution process.

[0097] Furthermore, when running the currently running agent to derive sub-agents based on its agent information, an excessive number of parallel sub-agents can lead to excessive consumption of system resources, affecting operational efficiency and stability. Conversely, excessively deep chained sub-agents can result in prolonged task execution time, potentially leading to stack overflows and omissions. Therefore, when running the currently running agent to derive sub-agents based on its agent information, constraints are imposed on the derived sub-agents based on the delegate type to avoid excessive system resource consumption, prolonged task execution time, and to prevent the omission of critical paths.

[0098] For example, when running the currently running agent to derive sub-agents based on the agent information of the currently running agent, the method further includes: When the delegate type is chained delegate, configure the delegate depth for the sub-delegates and use the delegate depth as the derivation constraint for the chained delegate; When the delegate type is parallel delegate, configure the delegate width for the sub-delegates and use this delegate width as the derivation constraint of the parallel delegate.

[0099] Specifically, proxy depth is used to limit the derivation depth of chained delegations, preventing issues such as excessively long task execution times and stack overflows caused by excessively deep chained sub-delegates. The proxy depth of a sub-delegate is the proxy depth of its derived parent proxy plus one. Proxy width is used to limit the derivation width of parallel delegations, preventing excessive consumption of system resources due to too many parallel sub-delegates. The proxy width is the number of sub-delegates derived from the currently running proxy.

[0100] The use of proxy depth as a derivation constraint for chained delegation means that when the proxy depth of the current sub-delegation reaches a preset upper limit, the derivation of chained sub-delegations stops. For example, if the preset upper limit for proxy depth is 10, when the root proxy's proxy depth is 0, the first chained sub-delegation derived from it has a proxy depth of 1, the second chained sub-delegation has a proxy depth of 2, and so on. When the tenth chained sub-delegation is derived, its proxy depth reaches 10, at which point the derivation of chained sub-delegations stops. This effectively avoids problems such as excessively long task execution time and stack overflow caused by excessively deep chained sub-delegations.

[0101] Using the agent width as a derivation constraint for parallel delegation means that when the number of sub-agents derived by the currently running agent reaches the preset agent width limit, the deriving of parallel sub-agents will stop. For example, if the preset agent width limit is 79, if the currently running agent needs to derive parallel sub-agents to process tasks, once 79 sub-agents have been derived, no further parallel sub-agents will be derived, even if there are still sub-tasks to process. This helps prevent excessive consumption of system resources due to too many parallel sub-agents, ensuring the efficiency and stability of system operation.

[0102] This application, by setting derivation constraints for both chained and parallel delegations, can reasonably control the number and depth of sub-agent derivations during the execution of the terminal firmware image, ensuring effective utilization of system resources and avoiding various problems caused by unreasonable sub-agent derivations. This guarantees the efficient and stable operation of the terminal firmware image. Furthermore, derivation constraints also better ensure the structural rationality of the dynamic topology tree, enabling the tree structure to accurately reflect the execution order and interrelationships of each subtask during the terminal firmware image's execution, providing a clear structural foundation for subsequent task analysis and processing. In one specific implementation, the derivation process of the sub-delegate can be executed through a recursive delegation engine, the execution process of which can be represented as follows: , in, This indicates a recursive delegation engine. Indicates that the agent is currently running. This represents the proxy object currently running. Express the task objective of the currently running agent. Indicates the number of parallel sub-agents. Express derived sub-proxies, Indicates the proxy type of the derived sub-proxy. This represents the proxy object of a derived sub-proxy. This indicates the task objective of the derived sub-agent. Indicates the upper limit of proxy depth. This indicates the proxy depth of the derived sub-proxies. This indicates the proxy depth of the currently running proxy. This indicates the maximum width of the proxy.

[0103] In one embodiment, to dynamically regulate resources and avoid resource allocation imbalances caused by agent execution anomalies, the following is implemented during the execution of the terminal firmware image using a derived sub-agent approach based on the structured data: Figure 8 As shown, the method further includes: S201. Obtain the execution steps of each sub-agent and / or the execution failures of its derived sub-agents; S202. When the number of execution steps or the number of execution failures meet the preset termination condition, the operation of the sub-agent is terminated.

[0104] Specifically, the execution steps refer to the number of operation steps performed by the sub-agent during task execution, reflecting the progress and complexity of the sub-agent task execution. The execution failure count refers to the number of times the sub-agent itself or its derived sub-agents fail during task execution, reflecting the stability and reliability of task execution. The preset termination conditions are pre-set based on performance requirements and resource availability.

[0105] For example, if a sub-agent reaches its preset execution step limit, it indicates that the sub-agent's task may be stuck in a complex loop or an abnormal execution flow. Continuing to run it may consume excessive system resources and cannot guarantee the effective completion of the task. In this case, the sub-agent should be terminated. Similarly, if the cumulative number of execution failures of a sub-agent and its derived sub-agents reaches a preset failure limit, it indicates that the task handled by that sub-agent may have intractable problems. Continuing to run it may lead to further resource waste and system instability, thus requiring its termination as well.

[0106] Furthermore, when the number of execution steps or execution failures meets the preset termination conditions, the sub-agent terminates to avoid excessive resource consumption caused by agent execution anomalies. This ensures that system resources are reasonably allocated to other normally functioning sub-agents, making the entire terminal firmware image operation process more efficient and stable. Simultaneously, by monitoring the number of execution steps or execution failures in real time, problems arising during task execution can be detected and addressed promptly, improving system reliability and maintainability.

[0107] S30. Inject structured evidence into the sub-agents in the dynamic topology tree, and generate an evidence graph based on the injected dynamic topology tree.

[0108] Specifically, the structured evidence includes file offsets, semantic tags, and tool output hashes. File offsets are used to pinpoint the exact location of the vulnerability within the firmware image; semantic tags are used to annotate the vulnerability type, such as vulnerability chains, sensitive data, buffer overflows, null pointer dereferences, etc.; and tool output hashes are used to ensure the traceability and consistency of the detection results. Structured evidence can clearly and accurately describe the security issues present in the firmware image. This structured evidence is collected during agent operation.

[0109] For example, structured evidence can be represented as: , , , , in, Representing structured evidence, Indicates file offset, Indicates semantic tags, This indicates that the tool outputs a hash. Represents the file location hash. Indicates the offset. Indicates a vulnerability chain, This indicates sensitive data. Indicates the tool output, This indicates a hash calculation.

[0110] Furthermore, the process of injecting structured evidence into the dynamic topology tree involves associating the structured evidence with the sub-agents within the dynamic topology tree. In other words, when a sub-agent in the dynamic topology tree encounters a vulnerability during runtime, the node collects the vulnerability information to form structured evidence and injects this evidence into the dynamic topology tree to associate it with the sub-agent. This association method allows the dynamic topology tree to intuitively reflect the security issues involved in the operation of each sub-agent.

[0111] In one embodiment, such as Figure 9 As shown, injecting structured evidence into the sub-agents of the dynamic topology tree specifically includes: S311. Obtain the sub-agents in the dynamic topology tree where an abnormal event has occurred; S312. Obtain the abnormal information of the abnormal event and encapsulate the abnormal information into structured evidence; S313. Inject the structured evidence into the sub-agent where the abnormal event occurs.

[0112] Specifically, a sub-agent experiencing an anomaly refers to a sub-agent that detects a security vulnerability or deviates from a preset threshold during task execution. Anomaly information refers to data related to security vulnerabilities collected by the sub-agent during operation, which may include vulnerability type, location, severity level, and related evidence.

[0113] Furthermore, when acquiring anomaly information, detailed analysis can be performed on the sub-agent's runtime data and log records. For example, if a buffer overflow vulnerability is detected, memory usage and function call stack information at the time the vulnerability occurred will be collected. After collecting the anomaly information, it will be encapsulated into structured evidence according to a predefined format, ensuring that the structured evidence includes key elements such as file offsets, semantic tags, and tool output hashes. Then, a corresponding structured evidence field will be added to the dynamic topology tree's data structure for the sub-agent, and the encapsulated structured evidence will be used as the field content of the structured evidence field to inject the structured evidence into the sub-agent where the anomaly event occurred. In this way, when analyzing the dynamic topology tree subsequently, relevant security issue information can be directly obtained from the sub-agent nodes.

[0114] In step S30, the evidence graph is a graph structure that graphically displays the relationships between structured evidence. The evidence graph is generated based on a dynamic topology tree after the injection of structured evidence, clearly showing the security issues involved in the operation of each sub-agent and the inherent connections between these issues. Through the evidence graph, security personnel can quickly understand the security status of the entire system, discover hidden security threats, and thus improve the security and reliability of the system.

[0115] The evidence graph uses structured evidence as nodes and edges representing the relationships between them. Each node represents a wealth of security information, such as file offsets indicating the specific location of a vulnerability in the firmware image, semantic tags accurately labeling the vulnerability type, and tool output hashes ensuring the traceability and consistency of detection results. Visualizing structured evidence in node form allows security personnel to quickly locate and identify vulnerabilities. The edges represent the logical connections between different vulnerabilities. For example, one vulnerability might be a prerequisite for another, or multiple vulnerabilities might form a vulnerability chain. The edges in the evidence graph provide a clear visual representation of the relationships between structured evidence, facilitating in-depth analysis of the mechanisms underlying security incidents and identifying potential security risks.

[0116] In one embodiment, such as Figure 10 As shown, the step of generating the evidence graph based on the injected dynamic topology tree specifically includes: S321. Calculate the semantic relevance between any two structured pieces of evidence in a dynamic topology tree; S322. Using structured evidence as nodes, edges are constructed between nodes based on semantic relevance to generate an evidence graph.

[0117] In step S321, semantic relevance is used to reflect the degree of similarity or logical connection between two structured pieces of evidence at the semantic level. When calculating semantic relevance, multiple factors are considered, such as the similarity of semantic tags, the proximity of file offsets, and the consistency of tool output hashes. For example, if the semantic tags of two pieces of structured evidence both point to buffer overflow vulnerabilities, their file offsets are adjacent, and their tool output hashes also have high similarity, then the semantic relevance between these two pieces of structured evidence is high.

[0118] In one embodiment, such as Figure 11 As shown, the semantic relevance between any two structured pieces of evidence in the dynamic topology tree specifically includes: S3211. For any two structured pieces of evidence, obtain the keywords of the semantic tags in the two structured pieces of evidence respectively; S3212. Calculate the intersection-union ratio (IUU) of keywords between two structured pieces of evidence to obtain the semantic relevance between the two structured pieces of evidence.

[0119] Specifically, keywords are representative words extracted from semantic tags to reflect the core characteristics of the vulnerability type. For example, for the semantic tag "buffer overflow," the keywords could be "buffer" and "overflow." By extracting keywords from the semantic tags of two structured evidences separately and then calculating the intersection-union ratio (IUGR) between these keywords, the semantic similarity between the two pieces of structured evidence can be effectively measured. The IUGR is calculated by first finding the number of elements in the intersection of the keyword sets of the two pieces of structured evidence, then finding the number of elements in the union of the two sets, and finally dividing the number of elements in the intersection by the number of elements in the union. The result is the IUGR, which gives the semantic relevance between the two pieces of structured evidence.

[0120] Furthermore, in step S322, after obtaining the semantic correlation between any two structured pieces of evidence, an evidence graph is generated by constructing edges between the nodes based on the semantic correlation, using the structured evidence as nodes. Specifically, when constructing edges between nodes based on semantic correlation, a correlation threshold is pre-set. If the semantic correlation between two pieces of structured evidence reaches the correlation threshold, it is considered that there is a connection between the two pieces of structured evidence, and an edge is constructed between the two pieces of structured evidence in the evidence graph.

[0121] Based on this, such as Figure 12 As shown, the construction of edges between nodes based on semantic relevance specifically includes: S3221. Compare the semantic relevance between all two pieces of structured evidence with a preset semantic relevance threshold; S3222. When the semantic correlation between two structured pieces of evidence is greater than a preset semantic correlation threshold, an edge is constructed between the nodes formed by the two structured pieces of evidence.

[0122] Specifically, the preset semantic relevance threshold is a pre-defined value used to determine whether there is sufficient correlation between two structured pieces of evidence to construct an edge. The setting of this preset semantic relevance threshold can comprehensively consider the actual situation of the system and security requirements. For example, if the preset semantic relevance threshold is set too high, it may result in too few edges in the evidence graph, failing to fully reflect the correlation between structured evidence and thus overlooking some potential security risks; if the preset semantic relevance threshold is set too low, it may result in too many edges in the evidence graph, leading to an overly complex graph and increasing the difficulty of analysis.

[0123] In one implementation, a default threshold and edge quantity constraint can be set first. This edge quantity constraint can be determined based on the number of structured evidence pieces. For example, the upper limit of the edge quantity constraint is *a% of the number of structured evidence pieces, and the lower limit is *b% of the number of structured evidence pieces, where a is greater than b. Then, edges are constructed based on a preset semantic relevance threshold and semantic relevance, and the number of constructed edges is obtained. If the number of edges meets the edge quantity constraint, edge construction is complete. If the number of edges does not meet the edge quantity constraint, the preset semantic relevance threshold is adjusted according to the relationship between the number of edges and the quantity constraint to obtain an adjusted threshold. This adjusted threshold is then used as the preset semantic relevance threshold, and the step of constructing edges based on the preset semantic relevance threshold and semantic relevance is repeated until the number of edges meets the edge quantity constraint. Specifically, when adjusting the preset semantic relevance threshold according to the relationship between the number of edges and the quantity constraint, if the number of edges is less than the lower limit constraint, it means the number of edges is too small, so the preset semantic relevance threshold is reduced. If the number of edges is greater than the upper limit constraint, it means the number of edges is too large, so the preset semantic relevance threshold is increased.

[0124] It should be noted that when constructing edges between nodes based on semantic relevance, semantic relevance can also be used as maintenance information for the edges, so that the edges can not only reflect the relationship between two structured pieces of evidence, but also the degree of closeness of the relationship between the two structured pieces of evidence.

[0125] This application generates an evidence graph by using structured evidence as nodes and constructing edges between nodes based on semantic relevance. This evidence graph clearly displays the relationships between various structured pieces of evidence, enabling a more comprehensive and in-depth understanding of the distribution and interrelationships of security issues within the system. For example, the evidence graph can identify which vulnerabilities are interdependent and which vulnerabilities may lead to other vulnerabilities. The distribution and interrelationships of security issues can provide a valid basis for formulating security strategies, allowing for targeted vulnerability remediation and security protection of the system. For instance, when a vulnerability is found to be a prerequisite for multiple other vulnerabilities, that vulnerability can be prioritized for remediation, eliminating security risks at their source.

[0126] S40. Determine the security analysis results of the terminal firmware image based on the evidence map.

[0127] Specifically, the security analysis results are formed by a comprehensive assessment of the security issues existing in the terminal firmware image based on the evidence graph. The security analysis results can include information such as the number, type, severity, and correlation between vulnerabilities. In other words, the security analysis results of the terminal firmware image can be determined by summarizing the security issues in the evidence graph.

[0128] However, in practical applications, vulnerabilities in the terminal firmware may not be inherent in the firmware itself, but rather arise from firmware tampering and asynchronous conflicts. Therefore, when determining the security analysis results of the terminal firmware image based on the aforementioned evidence graph, the structured evidence in the evidence graph can be verified to determine its legality and authenticity.

[0129] Based on this, such as Figure 13 As shown, the security analysis results for determining the terminal firmware image based on the evidence graph specifically include: S41. Determine the abnormal event chain based on the evidence map, and obtain the structured evidence set corresponding to the abnormal event chain; S42. For each structured piece of evidence in the structured evidence set, verify the continuity of the tool signature and / or timestamp of the structured evidence; S43. When each piece of structured evidence passes verification, the chain of anomalous events is treated as a security event to form a security analysis result.

[0130] Specifically, an anomaly event chain is a chain of logically related anomaly events in an evidence graph, representing a sequence of events that may pose a security risk. The anomaly event chain is obtained through analysis of the evidence graph. Furthermore, upon obtaining the anomaly event chain, structured evidence corresponding to each anomaly event in the chain can be extracted from the evidence graph to obtain a structured evidence set corresponding to the anomaly event chain.

[0131] The verification of tool signatures and / or timestamp continuity for structured evidence ensures its legitimacy and authenticity. The tool signature is an identifier attached to the structured evidence when it is generated, proving that the evidence was generated by the specified tool. If the tool signature verification fails, it indicates that the structured evidence may have been tampered with or generated by an untrusted tool. Timestamp continuity refers to the chronological order of events recorded in the structured evidence. Discontinuous or abnormal timestamps may indicate a problem with the structured evidence, such as malicious insertion or deletion of parts of the evidence.

[0132] When each piece of structured evidence in the structured evidence set is verified through tool signature and / or timestamp continuity, the chain of anomalies is deemed authentic and credible, and is included as a security event in the security analysis results. This approach allows for a more accurate reflection of actual security issues within the terminal firmware image, providing a reliable basis for subsequent security strategy development and vulnerability remediation. For example, if the security analysis reveals a critical security vulnerability corresponding to a chain of anomalies, and all structured evidence within that chain has been verified, the vulnerability can be immediately patched to repair the terminal firmware image and ensure system security.

[0133] In one embodiment, determining the security analysis result of the terminal firmware image based on the evidence graph further includes: Obtain the abnormal information of the security event; The risk value is determined based on the anomaly information, and the risk value is added to the security analysis result.

[0134] Specifically, the abnormal information includes at least one of the following: the number of vulnerability points, the attack path length, or the evidence verification rate. The number of vulnerability points refers to the number of locations in the abnormal event chain that may be attacked or have security issues; a higher number of vulnerability points indicates a larger potential impact of the security problem. The attack path length refers to the number of steps from the attack initiation point to the target vulnerability or security issue; a shorter attack path means it is easier for an attacker to launch an attack, and the higher the risk to the system. The evidence verification rate refers to the proportion of structured evidence in the abnormal event chain that is supported and verified by other evidence; a higher evidence verification rate indicates a stronger authenticity and reliability of the abnormal event chain.

[0135] Based on anomaly information from security incidents, a pre-defined risk assessment model can be used to determine risk values. This risk assessment model can be a machine learning model trained on historical data or a rule-based model developed based on the experience of security experts. After obtaining the risk values, they are added to the security analysis results to provide more intuitive and quantitative security risk information. This allows for the ranking and prioritization of different security incidents based on their risk values, prioritizing the handling of security incidents with higher risk values, thereby more effectively allocating security resources and improving the overall security of the system.

[0136] In one embodiment, after determining the security analysis result of the terminal firmware image based on the evidence graph, the method further includes: For each security event in the security analysis results, evidence backtracking is performed on the security event using an evidence graph. For security events in the evidence graph that have traceable evidence paths, configure a traceable identifier for the security event; For security events where there is no traceable evidence path in the evidence graph, a non-traceable flag is configured for the security event.

[0137] Specifically, evidence backtracking refers to using an evidence graph to trace back from a security incident to all relevant evidence and events that led to its occurrence. This allows for a clear understanding of the incident's process and root causes, enabling in-depth analysis of the security problem's origins. When one or more traceable evidence paths leading to the source of a security incident are found in the evidence graph, it indicates that a traceable evidence path exists, and the security incident is marked as traceable. Conversely, if no traceable evidence path is found in the evidence graph, it may be due to missing evidence, data corruption, or the complexity of the security incident itself, making it impossible to trace back to the source. In this case, the security incident is marked as non-traceable.

[0138] This application enables the effective classification and management of security events in security analysis results by configuring traceable and non-traceable identifiers for security events. This helps security personnel handle different types of security problems more efficiently and improves the overall security protection capabilities of the system.

[0139] In summary, this embodiment provides a terminal firmware security analysis method. The method includes obtaining a terminal firmware image corresponding to a task to be executed and parsing the terminal firmware image into structured data; running the terminal firmware image using a derived sub-proxy approach based on the structured data, and constructing a dynamic topology tree based on the derived sub-proxy; injecting structured evidence into the sub-proxy in the dynamic topology tree, and generating an evidence graph based on the injected dynamic topology tree; and determining the security analysis result of the terminal firmware image based on the evidence graph. This application, by dynamically running the terminal firmware image using a derived sub-proxy approach, decomposes the task to be executed according to the object layer and assigns it to sub-proxy for execution, avoiding the problem of critical path breakage caused by the limitation of the context window by the large model, and avoiding the omission of hard-coded credentials or cross-component vulnerabilities, thereby improving the accuracy of terminal firmware security analysis.

[0140] Based on the above-described terminal firmware security analysis method, this embodiment provides a terminal firmware security analysis device, such as... Figure 14 As shown, the terminal firmware security analysis device specifically includes: The acquisition module 100 is used to acquire the terminal firmware image corresponding to the task to be executed, and parse the terminal firmware image into structured data. The derived module 200 is used to run the terminal firmware image using a derived sub-agent method based on the structured data, and to construct a dynamic topology tree based on the derived sub-agent. The injection module 300 is used to inject structured evidence into the sub-agents in the dynamic topology tree and generate an evidence graph based on the injected dynamic topology tree. The determination module 400 is used to determine the security analysis results of the terminal firmware image based on the evidence map.

[0141] Based on the above-described terminal firmware security analysis method, this embodiment provides a computer-readable storage medium having computer-readable program instructions (i.e., computer programs) stored thereon, which are used to execute the terminal firmware security analysis method in the above embodiment.

[0142] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections with one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0143] The aforementioned computer-readable storage medium may be included in an electronic device or may exist independently without being assembled into an electronic device.

[0144] The aforementioned computer-readable storage medium carries one or more programs. When the aforementioned one or more programs are executed by an electronic device, the following steps are taken: First, a terminal firmware image corresponding to the task to be executed is obtained, and the terminal firmware image is parsed into structured data. Then, the terminal firmware image is run using a derived sub-agent approach based on the structured data, and a dynamic topology tree is constructed based on the derived sub-agents. Structured evidence is injected into the sub-agents in the dynamic topology tree, and an evidence graph is generated based on the injected dynamic topology tree. Finally, the security analysis result of the terminal firmware image is determined based on the evidence graph.

[0145] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0146] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0147] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0148] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the aforementioned terminal firmware security analysis method, thereby solving the technical problem of poor application performance. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the terminal firmware security analysis method provided in the above embodiments, and will not be repeated here.

[0149] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the terminal firmware security analysis method described above.

[0150] The computer program product provided in this application can solve the technical problem of poor application performance. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the terminal firmware security analysis method provided in the above embodiments, and will not be repeated here.

[0151] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application 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 this application.

Claims

1. A terminal firmware security analysis method, characterized in that, The aforementioned terminal firmware security analysis method specifically includes: Obtain the terminal firmware image corresponding to the task to be executed, and parse the terminal firmware image into structured data; The terminal firmware image is run using a derived sub-agent approach based on the structured data, and a dynamic topology tree is constructed based on the derived sub-agent. Structured evidence is injected into the sub-agents in the dynamic topology tree, and an evidence graph is generated based on the injected dynamic topology tree. The security analysis results of the terminal firmware image are determined based on the evidence map.

2. The terminal firmware security analysis method according to claim 1, characterized in that, The nodes of the dynamic topology tree are child agents, and the edges of the dynamic topology tree are the delegation types when deriving child agents. The delegation types include chained delegation and parallel delegation.

3. The terminal firmware security analysis method according to claim 1, characterized in that, The process of parsing the terminal firmware image into structured data specifically includes: Input the terminal firmware image into the firmware destructuring engine; The firmware deconstruction engine deconstructs the terminal firmware image by classifying it into targets, files, and configuration data, thereby parsing the terminal firmware image into structured data, wherein the structured data includes target structure, file set, and configuration dataset.

4. The terminal firmware security analysis method according to claim 3, characterized in that, The step of deconstructing the terminal firmware image using the firmware deconstruction engine, categorizing it by target, file, and configuration data, to parse the terminal firmware image into structured data specifically includes: The terminal firmware image is parsed using the firmware decomposition engine to obtain the file paths, file contents, and metadata in the terminal firmware image. The firmware destructuring engine constructs the target structure based on the file path; The firmware destructuring engine constructs a file set based on the file content; The firmware deconstruction engine constructs a configuration dataset based on metadata.

5. The terminal firmware security analysis method according to claim 1, characterized in that, The step of running the terminal firmware image using a derived sub-agent approach based on the structured data specifically includes: A root proxy is constructed based on the structured data, and the root proxy is used as the currently running proxy. Run the currently running agent to derive sub-agents based on the agent information of the currently running agent. Each sub-agent is configured with agent information and delegation type. The agent information includes the agent object and the task target. The delegation type is either chained delegation or parallel delegation. The sub-agent is set as the currently running agent, and the steps for running the currently running agent are executed until the terminal firmware image is finished running.

6. The terminal firmware security analysis method according to claim 5, characterized in that, When running the currently running agent to derive sub-agents based on the agent information of the currently running agent, the method further includes: When the delegation type is chained delegation, a delegation depth is configured for the sub-delegates, and this delegation depth is used as the derivation constraint of the chained delegation. The delegation depth of the sub-delegates is the delegation depth of the parent delegate from which the sub-delegates are derived plus one. When the delegate type is parallel delegate, configure the delegate width for the sub-delegates and use this delegate width as the derivation constraint of the parallel delegate.

7. The terminal firmware security analysis method according to claim 6, characterized in that, The step of running the currently running agent to derive sub-agents based on the agent information of the currently running agent specifically includes: The delegation type is determined based on the delegation type of the currently running agent and the object type of the delegate object; Sub-agents are derived according to the delegate type, and the delegate targets and delegate objects of the currently running agent are decomposed according to the derived sub-agents, so as to assign task targets and delegate objects to each sub-agent.

8. The terminal firmware security analysis method according to claim 1, characterized in that, The proxy type of the sub-agents in the dynamic topology tree is target proxy, file proxy, or function proxy.

9. The terminal firmware security analysis method according to claim 8, characterized in that, The specific steps of injecting structured evidence into the sub-agents of the dynamic topology tree include: Obtain the sub-agents in the dynamic topology tree where an abnormal event has occurred; Obtain the abnormal information of the abnormal event and encapsulate the abnormal information into structured evidence; The structured evidence is injected into the sub-agent that experiences the anomalous event.

10. The terminal firmware security analysis method according to claim 1 or 9, characterized in that, The structured evidence includes file offsets, semantic tags, and tool output hashes.

11. The terminal firmware security analysis method according to claim 10, characterized in that, The semantic tags are vulnerability chains or sensitive data.

12. The terminal firmware security analysis method according to claim 1, characterized in that, The process of generating the evidence graph based on the injected dynamic topology tree specifically includes: Calculate the semantic relevance between any two structured pieces of evidence in a dynamic topology tree; Using structured evidence as nodes and semantic relevance as the basis, edges are constructed between nodes to generate an evidence graph.

13. The terminal firmware security analysis method according to claim 12, characterized in that, The calculation of the semantic relevance between any two structured pieces of evidence in the dynamic topology tree specifically includes: For any two structured pieces of evidence, obtain the keywords of the semantic tags in the two structured pieces of evidence respectively; Calculate the intersection-union ratio (CUNR) between keywords of two structured pieces of evidence to obtain the semantic relevance between the two pieces of evidence.

14. The terminal firmware security analysis method according to claim 12, characterized in that, The construction of edges between nodes based on semantic relevance specifically includes: Compare the semantic relevance between all two pieces of structured evidence with a preset semantic relevance threshold; When the semantic relevance between two structured pieces of evidence is greater than a preset semantic relevance threshold, an edge is constructed between the nodes formed by the two structured pieces of evidence.

15. The terminal firmware security analysis method according to claim 1, characterized in that, The security analysis results for determining the terminal firmware image based on the evidence graph specifically include: Based on the evidence graph, an abnormal event chain is determined, and the structured evidence set corresponding to the abnormal event chain is obtained. For each piece of structured evidence in the structured evidence set, the tool signature and / or timestamp continuity of the structured evidence is verified; When each piece of structured evidence passes verification, the chain of anomalous events is treated as a security event to form a security analysis result.

16. The terminal firmware security analysis method according to claim 15, characterized in that, The security analysis results for determining the terminal firmware image based on the evidence graph also include: Obtain abnormal information about the security event, wherein the abnormal information includes at least one of the following: number of hazard points, attack path length, or evidence verification rate; The risk value is determined based on the anomaly information, and the risk value is added to the security analysis result.

17. The terminal firmware security analysis method according to claim 1, characterized in that, During the execution of the terminal firmware image using a derived sub-proxy approach based on the structured data, the method further includes: Get the execution steps of each sub-agent and / or the number of execution failures of its derived sub-agents; The sub-agent terminates when the number of execution steps or the number of execution failures meets the preset termination condition.

18. The terminal firmware security analysis method according to claim 1, characterized in that, After determining the security analysis result of the terminal firmware image based on the evidence graph, the method further includes: For each security event in the security analysis results, evidence backtracking is performed on the security event using an evidence graph. For security events in the evidence graph that have traceable evidence paths, configure a traceable identifier for the security event; For security events where there is no traceable evidence path in the evidence graph, a non-traceable flag is configured for the security event.

19. A terminal firmware security analysis device, characterized in that, The aforementioned terminal firmware security analysis device specifically includes: The acquisition module is used to acquire the terminal firmware image corresponding to the task to be executed and parse the terminal firmware image into structured data. The derived module is used to run the terminal firmware image using a derived sub-agent method based on the structured data, and to build a dynamic topology tree based on the derived sub-agent; The injection module is used to inject structured evidence into the sub-agents in the dynamic topology tree and generate an evidence graph based on the injected dynamic topology tree. The determination module is used to determine the security analysis results of the terminal firmware image based on the evidence graph.

20. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores one or more programs, which can be executed by one or more processors to implement the steps in the terminal firmware security analysis method as described in any one of claims 1 to 18.

21. An electronic device, characterized in that, include: Processor and memory; The memory stores a computer-readable program that can be executed by the processor; When the processor executes the computer-readable program, it implements the steps in the terminal firmware security analysis method as described in any one of claims 1 to 18.

22. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the terminal firmware security analysis method as described in any one of claims 1 to 18.

Images