Early warning method for device code risks, software system, and computing device

Abstract

The present invention discloses a device code risk early warning method, a software system, and a computing device, the device code risk early warning method comprising the steps of: collecting an update request for a device code including at least one software code; obtaining the device code based on the content of the update request; and transmitting the device code to the device; if a code analysis event corresponding to a risk code is triggered, obtaining the risk code; comparing the component content of the risk code with the component content of at least one software code; and issuing a risk early warning notification if the result of the comparison indicates that the at least one software code includes at least one security risk. The beneficial effect is that risk early warning can be performed on the device regardless of whether the device is offline or whether the network condition is normal, thereby realizing risk preventive control over device codes.

Description

Technical Field

[0001] The present invention relates to the field of early warning of code risks, and particularly to a method for early warning of risks of device codes, a software system, and an arithmetic device.

Background Art

[0002] When performing vulnerability detection on a web site server operating online, in the prior art, after establishing a network connection with the online server and obtaining the source code of the web page front-end system on the online server, it is necessary to compare the source code of the patch code with the obtained source code to determine whether there are known vulnerabilities or newly discovered vulnerabilities. The web site server (online server) operating online itself is also a hardware device, and a large amount of binary code (for example, Linux Kernel and Web Server) is executed in its working environment.

[0003] When performing vulnerability detection on the back-end system of a web site in an online server and a hardware device operating online, the intermediate code, binary code in the server, and binary code in the hardware device are all codes that cannot be identified by humans, and since the server and the hardware device are already operating online, in the prior art, based on the action description of a specific vulnerability, network packets for simulating an attack are transmitted to the server and the hardware device via the network. When the server and the hardware device receive the network packets, it is monitored whether the reactions of the server and the hardware device match the action description of the specific vulnerability. If they match, it indicates that the specific vulnerability exists in the server and the hardware device operating online, and further provides the effect of a security warning to the operators of the server and the online hardware device.

[0004] When performing vulnerability analysis, risk detection, and preventive control against online servers and / or hardware devices, the code executed on the servers and / or hardware devices is primarily intermediate or binary code, and source code is often lacking. Therefore, it is not possible to compare the source code of a patch with the source code of the online system, and source code comparison cannot be performed when source code is unavailable. Vulnerability analysis using simulation packets requires network environment support. If the system is offline or the network is not functioning properly, simulation packets cannot be sent to the target online servers and / or hardware devices, and vulnerability analysis and risk monitoring using simulation packets cannot be performed. Furthermore, if a particular vulnerability is not triggered by a simulation packet, that particular vulnerability cannot be detected using the simulation packet method.

[0005] As can be seen from the above explanation, in the field of information security risk prevention and control technology, how to perform vulnerability analysis and security warnings for hardware devices with missing source code and / or hardware devices operating online is a critical technical challenge. Currently, there are no risk prevention and control methods, software systems, and computing devices that can provide vulnerability analysis and security warnings for devices when the source code of the device system is missing and / or the network is offline, and there is an urgent need for such development. [Overview of the project] [Problems that the invention aims to solve]

[0006] The present invention provides a method for early warning of device code risks, a software system, and a computing device, which are realized by the following technical solutions. [Means for solving the problem]

[0007] Solution 1: Early warning methods for device code risks are: The steps include: collecting an update request for a device code that includes at least one piece of software code; obtaining the device code based on the content of the update request; and transmitting the device code to the device. When a code analysis event corresponding to a risk code is triggered, the steps include: obtaining the risk code and comparing the component content of the risk code with the component content of at least one of the software codes; The method includes the step of issuing an early warning notification of a risk if the results of the comparison indicate that the at least one software code contains at least one security risk.

[0008] Furthermore, the step of issuing an early risk warning notification is to send an early risk warning notification to at least one of the providers of the device code, the operators of the device, and the administrators via at least one network communication means.

[0009] Furthermore, the device code is provided by the first user, the collection of update requests is the distribution of the device code and / or the reception of updates, and the device is operated by the second user.

[0010] Furthermore, the at least one software code includes at least one binary code.

[0011] Furthermore, the step of obtaining the device code is specifically the step of obtaining the device code from the storage medium. The step includes obtaining the device code from the storage medium based on code version information that specifies the device code.

[0012] Furthermore, the code version information is either directly specified by the content of the update request, or determined based on the product specifications, hardware specifications, and / or software / firmware specifications included in the content of the update request, which specify the code version information that the device needs to be updated.

[0013] Furthermore, the aforementioned update request is an online update request transmitted over a network.

[0014] Furthermore, the content of the update request includes the network location information of the device, and based on the network location information, the device code is transmitted to the device via the network.

[0015] Furthermore, the step of comparing the component contents of the risk code with the component contents of the at least one software code is: The steps include extracting at least one first component feature corresponding to the aforementioned risk code, A step of extracting at least one second component feature corresponding to the at least one software code, The process includes the step of comparing the at least one first component feature with the at least one second component feature.

[0016] Furthermore, the first component features are obtained by analyzing the code configuration content and / or code execution results corresponding to the risk code.

[0017] Furthermore, the code configuration includes the risk code and / or the first intermediate code from which the risk code is compiled, and the code execution result includes the semantic information that the risk code and / or the first intermediate code express during the simulation execution when a simulation is performed on the risk code and / or the first intermediate code.

[0018] Furthermore, the at least one second component feature is obtained by analyzing at least one code configuration content and / or at least one code execution result corresponding to the at least one software code.

[0019] Furthermore, the at least one code configuration content includes at least one binary code and / or at least one second intermediate code obtained by reverse-assembling the at least one binary code, and the at least one code execution result includes semantic information expressed by the at least one binary code and / or the at least one second intermediate code during simulation execution when performing simulation execution on the at least one binary code and / or the at least one second intermediate code.

[0020] Furthermore, the programming language structure of the intermediate code is defined by an intermediate language, an intermediate representation, a structured language, and / or a structured protocol.

[0021] Furthermore, the types of the risk code include patch code, illegal program code, and / or any code for fixing or creating software vulnerabilities or software viruses.

[0022] Furthermore, the code analysis event corresponding to the risk code is triggered when the risk code is newly added or updated.

[0023] Furthermore, before the code analysis event is triggered, at least one code analysis event is detected based on the configuration list of the at least one software code, and the code analysis event corresponding to the risk code is one of the at least one code analysis events.

[0024] Furthermore, the configuration list is obtained by scanning and / or analyzing the component configuration of the device code when the device code is collected.

[0025] Furthermore, the configuration list includes metadata of the device code itself and / or metadata of the at least one software code included in the component configuration of the device code.

[0026] Furthermore, the at least one software code exists in the component configuration of the device code in the form of a system core, a driver, an application program, a component, and / or a category library.

[0027] Furthermore, the device code is a system image file, scans and / or analyzes the component configuration included in the system image file, identifies the at least one software code existing in the system image file, and obtains the configuration list of the at least one software code. Alternatively, the device code is a software code package, scans and / or analyzes the component configuration included in the software code package, identifies the at least one software code existing in the software code package, and obtains the configuration list of the at least one software code.

[0028] Furthermore, the early risk warning notification includes an instruction, and the instruction instructs the device and / or the user operating the device to execute an update operation of the risk code on the device. Alternatively, the early risk warning notification includes prompt information, and the prompt information provides a warning about the at least one security risk to the provider of the device code, the operator and / or the administrator of the device.

[0029] Solution 2: The software system for early risk warning of device code includes a collection unit, a code acquisition unit, a comparison unit, and a transmission unit. The collection unit is used to receive an update request for device code. The code acquisition unit is used to acquire the device code, and the device code includes at least one software code. The transmission unit is used to transmit the device code to the device and issue an early warning notification of risk. The comparison unit is used to compare the risk code with the device code after the code acquisition unit has acquired the risk code, when a code analysis event corresponding to the risk code is triggered.

[0030] Furthermore, the comparison unit includes a first feature extraction unit, a second feature extraction unit, and a feature comparison unit. The first feature extraction unit is used to extract at least one first component feature corresponding to the risk code. The second feature extraction unit is used to extract at least one second component feature corresponding to the at least one software code. The feature comparison unit is used to compare at least one first component feature with at least one second component feature.

[0031] Furthermore, the first feature extraction unit or the second feature extraction unit includes at least one analysis unit and at least one extraction unit, The at least one analysis unit is used to analyze the code structure and / or code execution results corresponding to the risk code to obtain a first component feature, and / or to analyze the code structure and / or code execution results corresponding to the at least one software code to obtain a second component feature. The at least one extraction unit is used to extract the first and / or second component features obtained through analysis.

[0032] Furthermore, the software system for early warning of risks in the device code further includes at least one detection unit. The at least one detection unit is used to detect code analysis events by monitoring a risk code registration list corresponding to each software code included in the configuration list of the at least one software code, based on the configuration list of the at least one software code, and by monitoring abnormal fluctuations in the risk code registration list.

[0033] Solution 3: The device code risk early warning calculation unit includes a collection unit, a code acquisition unit, a comparison unit, and a transmission unit. The collection unit is used to receive device code update requests. The code acquisition unit is used to acquire the device code from a storage medium, and the device code includes at least one software code. The transmission unit is used to transmit the device code to the device and issue an early warning notification of risk. The comparison unit is used to compare the risk code with the device code after the code acquisition unit has acquired the risk code from the storage medium and / or another storage medium when a code analysis event corresponding to the risk code is triggered. [Effects of the Invention]

[0034] Designed in this way, the present invention has the advantage that it can provide early risk warnings to a device regardless of whether the device is offline or whether the network status is normal, by updating a device code including at least one software code, comparing the component contents of a risk code with the component contents of the device code, and transmitting an early risk warning for the device while the device is operating online. [Brief explanation of the drawing]

[0035] [Figure 1] This is a flowchart of the early risk warning method for device codes according to the present invention. [Figure 2] This is a structural block diagram of the software system for early risk warning of device codes according to the present invention. [Figure 3] This is a flowchart illustrating the comparison between the component contents of the risk code and the component contents of at least one software code in the present invention. [Figure 4] This is a flowchart illustrating how a software system can perform early warning of device code risks based on a configuration list of at least one software code before a code analysis event is triggered. [Figure 5] This is a structural block diagram of the calculation device for early risk warning of device codes according to the present invention. [Modes for carrying out the invention]

[0036] The present invention will be better understood by the following description, which includes the following glossary and examples of conclusions. For the sake of brevity, publications cited herein (including the disclosures of patents) are incorporated herein by reference.

[0037] The following describes the invention in detail with reference to examples, but the examples of the present invention are not limiting and merely illustrate various aspects and features of the invention. The examples are used for illustrative purposes only and do not limit the scope of protection of the present invention. Furthermore, the drawings in the examples omit unnecessary components or components that can be completed by ordinary art in order to clearly illustrate the technical features of the present invention.

[0038] In its most restrictive technical sense, the code composition of “software code” as described herein includes any binary code, intermediate code, and / or any computer program code written in a computer programming language for loading and execution. “Device code” as described herein is code that runs on a device and provides logical operations and services to the device, and the device code consists of binary code, intermediate code, and / or any computer program code written in a computer programming language, i.e., the device code includes at least one software code, and the at least one software code exists in the component configuration of the device code in the form of components such as a system core, driver, application program, component, and / or category library. “Binary code” as described herein may include any code that uses binary as its representation format. The “intermediate code” as used herein may include any code expressed by an intermediate language, intermediate representation, structured language, and / or structured protocol, for example, Java Bytecode expressed according to a format defined by an intermediate representation, and LLVM bitcode obtained by disassembling binary code are both intermediate code and may be considered intermediate code. The code composition of the “risk code” as used herein includes any binary code for loading and execution, intermediate code, and / or any computer program code written in a computer programming language, and the types of risk code include patch code, malicious program code, and / or any code for correcting or creating software vulnerabilities or software viruses. The “metadata” as used herein, also called interpretive data, mediating data, or source data, is data for describing an object or related information of said object.The “risk code registration list” described herein may include any list registered, recorded and / or represented based on a structure defined by a structured language and / or structured protocol, the list may be stored and distributed in form including files, databases and / or web pages, the contents of the list include the registration information of the risk codes described herein, the registration information includes the content of the risk code itself, metadata of the risk code, and software vulnerability information or software virus information corresponding to the risk code, and the CVE (Common Vulnerabilities and Exposures) list (CVE Repository) is one embodiment of the risk code registration list described herein, but is not limited thereto. The “semantic information” described herein may include values ​​obtained from memory and / or intermediate variables during the execution process when a simulation execution is performed on the code, the execution history of each instruction during the execution process, the output / input values ​​of functions, and / or any extractable numerical information. All or part of the semantic information segments of two codes can be used as two component features for comparison to determine the similarity of the two codes according to the degree of agreement in the comparison.

[0039] Furthermore, the "collection unit," "code acquisition unit," "transmission unit," "comparison unit," "first feature extraction unit," "second feature extraction unit," "feature comparison unit," "analysis unit," "extraction unit," and "detection unit" described herein are processing units that provide logical operations or services, and embodiments of the processing units may include a category library, software components, software agent programs, application programs, any program blocks that can be built into, installed, deployed, or extended and executed in the "software system or computing device that provides early warning of device code risks" described herein, or integrated circuit units designed in a hardware description language and embedded in the "computer that provides early warning of device code risks" described herein.

[0040] Embodiments of the “Software System Providing Early Warning of Device Code Risks” described herein may include system firmware, application programs, software engines, operating systems, or any programmable software platform. In a preferred embodiment, the “Software System Providing Early Warning of Device Code Risks” described herein may be installed and run on the same device, i.e., the collection unit, code acquisition unit, transmission unit, comparison unit, first feature extraction unit, second feature extraction unit, feature comparison unit, analysis unit, extraction unit, and detection unit described herein are all integrated into the same software system, which can be installed and run on the device. In another preferred embodiment, the “software system providing early warning of device code risks” described herein may be performed by the cooperation of multiple devices, that is, processing units such as the collection unit, code acquisition unit, transmission unit, comparison unit, first feature extraction unit, second feature extraction unit, feature comparison unit, analysis unit, extraction unit, and detection unit described herein are provided to different devices, and the processing units in the different devices cooperate and interact with each other online via methods such as the Internet, Wi-Fi, or Bluetooth®, and furthermore, the multiple devices are jointly integrated to form a software system providing early warning of device code risks.

[0041] Embodiments of the "Computerized Device for Providing Early Warning of Device Code Risks" described herein may include network communication equipment, servers, or any communication equipment having network connectivity, data processing, or control functions. In a preferred embodiment, the "Computerized Device for Providing Early Warning of Device Code Risks" described herein may be implemented in a single device, that is, the collection unit, code acquisition unit, transmission unit, comparison unit, first feature extraction unit, second feature extraction unit, feature comparison unit, analysis unit, extraction unit, and detection unit described herein are all integrated into the same device to become a Computerized Device for Providing Early Warning of Device Code Risks. In another preferred embodiment, the "computer that provides early warning of device code risks" described herein may be implemented by the cooperation of multiple devices, that is, processing units such as the collection unit, code acquisition unit, transmission unit, comparison unit, first feature extraction unit, second feature extraction unit, feature comparison unit, analysis unit, extraction unit, and detection unit described herein are provided to different devices, and the processing units in the different devices cooperate and interact with each other online via methods such as the internet, WiFi, or Bluetooth®, and furthermore, the multiple devices are jointly integrated to form a computer that provides early warning of device code risks.

[0042] In a preferred embodiment, the "collection unit," "code acquisition unit," "transmission unit," "comparison unit," "first feature extraction unit," "second feature extraction unit," "feature comparison unit," "analysis unit," "extraction unit," and "detection unit" described herein may each be implemented in different processing units. In another preferred embodiment, at least two of the "collection unit," "code acquisition unit," "transmission unit," "comparison unit," "first feature extraction unit," "second feature extraction unit," "feature comparison unit," "analysis unit," "extraction unit," and "detection unit" described herein may be implemented in the same processing unit.

[0043] The contents of the present invention will be described in more detail below with reference to the drawings and specific embodiments.

[0044] Figure 1 is a preferred flowchart of the risk early warning calculation for the device code according to the present invention. The risk early warning method for device code 80 is as follows: Step S1 includes collecting an update request for a device code 80 that includes at least one software code, retrieving the device code 80 from a storage medium 9 based on the content of the update request, and transmitting the device code 80 to the device. Step S2: When a code analysis event corresponding to a risk code is triggered, the software system 1 retrieves the risk code from the storage medium 9 and / or another storage medium 9, and compares the component contents of the risk code with the component contents of at least one software code. Step S3 includes issuing an early warning notification of risk if the comparison results indicate that the at least one software code contains at least one security risk.

[0045] Figure 2 is a structural block diagram of the software system 1 for early risk warning of device code 80 according to the present invention. The calculations that provide early risk warning of device code according to the present invention will be described in a preferred embodiment. The first user 6 is a user of the software system 1, the second user 7 is the operator or administrator of device 8, the collection unit 2, the code acquisition unit 3, the comparison unit 4 and the transmission unit 5 are processing units integrated into the software system 1, the storage medium 9 is a memory, external storage device, database or any storage device capable of storing device code 80 or risk code, and the device code 80 is a code that is executed in device 8 and provides logical operations and services to device 8.

[0046] In a preferred embodiment, the second user 7 is a user of the software system 1 and manages the device 8 by recording the device 8's metadata in the software system 1. Here, the device 8's metadata includes the device 8's network location information, product specifications, hardware specifications, and / or software firmware specifications. In another preferred embodiment, the second user 7 is solely the operator of the device 8, and the device 8's metadata is recorded in the software system 1 by the system administrator of the software system 1, and the system administrator of the software system 1 acts as the administrator of the device 8.

[0047] In a preferred embodiment, the first user 6 is the developer of the device 8, and the first user 6 provides the device code 80 to the software system 1 via a human-machine interface provided by the software system 1. When the first user 6 provides the device code 80 to the software system 1, the first user 6 can input relevant data for the device code 80 into the human-machine interface and provide this relevant data along with the device code 80 to the software system 1 via the human-machine interface, where this relevant data includes code version information for the device code 80, and product specifications, hardware specifications, and / or software firmware specifications of the device 8 that the device code 80 supports updating.

[0048] In a preferred embodiment, the software system 1 stores the device code 80 and its associated data (including the code version information of the device code 80, and the product specifications, hardware specifications, and / or software firmware specifications of the device 8 that the device code 80 supports updating) in the storage medium 9, and completes the registration of the device code 80 in the software system 1.

[0049] In a preferred embodiment, the collection unit 2, the code acquisition unit 3, the comparison unit 4, and the transmission unit 5 are processing units integrated into the software system 1, each processing unit capable of providing at least one function to enable interaction with other processing units, and when one processing unit needs to send a request to another processing unit, the processing unit can input the content of the request to the other processing unit in the form of a function call, with the content of the request as a parameter, and the other processing unit, after receiving the content of the request, can provide a service for the request based on the content of the request. In another preferred embodiment, each processing unit may also interact with other processing units by means of a network connection or inter-process communication, and if one processing unit needs to send a request to another processing unit, it may establish a TCP / UDP socket connection with the other processing unit and transmit the content of the request to the other processing unit by a mutually agreed-upon communication protocol, or transmit the content of the request to the other processing unit by a mechanism that shares inter-process communication with some memory implemented, the other processing unit may receive the content of the request and provide a service for the request based on the content of the request, and the embodiments of how the request is provided to the processing unit and how the processing unit receives the request are not limited to these, and those skilled in the art can make any equivalent modifications and designs according to the actual application needs.

[0050] Here, the registration of the device code 80 in the software system 1 is completed. In a preferred embodiment, the software system 1 can retrieve the device 8 recorded in the software system 1 based on the product specifications, hardware specifications and / or software firmware specifications supported by the device code 80, and if the product specifications, hardware specifications and / or software firmware specifications of the device 8 match the specifications supported by the device code 80, the software system 1 can generate an update request to update the device code 80 for the device 8 and provide the update request to the collection unit 2. In another preferred embodiment, if a first user 6 provides the device code 80 to the software system 1 via the human-machine interface of the software system 1, the first user 6 can directly input the update request for the device 8 into the human-machine interface and provide the update request directly to the software system 1, and after receiving the update request, the software system 1 can provide the update request to the collection unit 2. In another preferred embodiment, the collection unit 2 can receive requests via a network connection, in which case the first user 6 can establish a TCP / UDP socket connection with the collection unit 2 via any other software system 1 and provide an update request to the device 8 to the collection unit 2 via the network connection in the form of an online update request. In another preferred embodiment, the software system 1 can send a notification to the device 8 via a network connection, notifying the device 8 that a new device code 80 has been registered with the software system 1, and including code version information of the device code 80 in the notification, and after receiving the notification, the device 8 can generate an update request including the code version information in the form of an online update request based on the content of the notification, establish a network connection with the collection unit 2, and provide the online update request to the collection unit 2 via network transmission.In another preferred embodiment, the software system 1 does not need to include the code version information in the notification to the device 8, and after receiving the notification, the device 8 can generate an update request including the product specifications, hardware specifications and / or software firmware specifications of the device 8, and transmit the update request to the software system 1 via a network connection. After receiving the update request, the software system 1 can determine the code version information of the device code 80 that matches the product specifications, hardware specifications and / or software firmware specifications based on the content of the update request, add the code version information to the content of the update request, and then provide the update request to the collection unit 2.

[0051] In a preferred embodiment, the software system 1 does not need to send any notification to the device 8 after completing the registration of the device code 80. The device 8 operated by the second user 7 periodically sends online update requests to the software system 1 via a network connection, and the contents of the update requests include the product specifications, hardware specifications and / or software firmware specifications of the device 8, and are sent to the software system 1 via a network connection. After receiving the update requests, the software system 1 can determine the code version information of the device code 80 that matches the product specifications, hardware specifications and / or software firmware specifications by comparing them based on the contents of the update requests. If the device code 80 is a device code 80 that needs to be updated by the device 8, the software system 1 can add the code version information to the contents of the update requests and provide the update requests to the collection unit 2. In another preferred embodiment, the second user 7, as the operator of the device 8, may also generate update requests for the device 8, including product specifications, hardware specifications and / or software firmware specifications for the device 8, via a separate software system 1, and transmit the update requests to the software system 1 via a network connection.

[0052] As described above, the methods for generating, transmitting, and receiving update requests by the collection unit 2 are not limited to these, and those skilled in the art can make any equivalent modifications and designs according to their actual application needs.

[0053] Furthermore, the device code 80 is provided by the first user 6 and, with regard to the registration of the device code 80 in the software system 1, may be a device code 80 distributed to a new device 8, an updated device code 80 for an old device 8, or an updated and distributed device code 80 for an old device 8 that has just been recorded in the software system 1. At least one software code included in the device code 80 includes at least one binary code.

[0054] In a preferred embodiment, the device 8 is operated by a second user 7. The device 8 is an embedded system device, a server device, an Internet of Things sensing device, a network communication device, or any computer device having network connectivity.

[0055] In a preferred embodiment, the content of the update request includes the network location information of the device 8. Based on the metadata of the device 8 recorded in the software system 1, the software system 1 enters the network location information into the update request, or the update request is generated by the device 8, and when the device 8 generates the update request, the device 8 enters its own network location information.

[0056] In a preferred embodiment, after receiving an update request for the device code 80, the collection unit 2 may send a request to the code acquisition unit 3 and request the code acquisition unit 3 to acquire the device code 80 that matches the code version information, i.e., the device code 80 specified by the code version information, from the storage medium 9 based on the code version information in the content of the update request. After acquiring the device code 80, the collection unit 2 may send a request to the transmission unit 5 and, based on the network location information of the device 8 included in the content of the update request, establish a TCP / UDP socket connection with the device 8, transmit the device code 80 to the device 8 via the socket connection and a mutually agreed-upon communication protocol, request the transmission unit 5 to complete the update of the device code 80 at the device 8, and make the device code 80 a code to be executed when the device 8 is online.

[0057] By performing the risk early warning calculation for the device code, the first user 6 can update the device code 80 for the device 8 operated by the second user 7 using the software system 1, making the device code 80 a code that is executed when the device 8 is online. If the device 8 is offline, the software system 1 that performs the risk early warning calculation for the device code can perform a risk early warning for the device code 80 on the device 8. In the method described above, if the device 8 is online, the software system 1 can also perform a risk early warning for the device code 80 on the device 8; that is, it is included in the risk early warning calculation for the device code in both online and offline cases.

[0058] In S1, the software system 1 obtains the device code 80 from the storage medium 9 based on the code version information corresponding to the device code 80. Furthermore, the code version information is either directly specified by the content of the update request, or the code version information that needs to be updated for the device 8 is determined by the software system 1 based on the product specifications, hardware specifications, and / or software firmware specifications included in the content of the update request.

[0059] As shown in Figure 2, when the update request is sent by the first user 6, obviously the first user 6 can directly enter the version information of the device code 80 into the update request, and the software system 1, after receiving the update request, can directly retrieve the device code 80 from the storage medium 9 based on the version information in the content of the update request. However, when the update request is sent by the second user 7 or the device 8, the second user 7 and the device 8 do not know what the latest version information of the device code 80 provided by the first user 6 is, and the second user 7 only knows the product specifications, hardware specifications and / or software firmware specifications of the device 8 operated by the second user 7 itself, as well as the device 8 itself.

[0060] Therefore, if the update request sent by the second user 7 and the device 8 includes the product specifications, hardware specifications, and / or software firmware specifications of the device 8 itself, but does not include the latest version information of the device code 80, when the update request from the second user 7 and the device 8 is sent to the software system 1, the software system 1 can determine which version of the device code 80 the device 8 should use based on the product specifications, hardware specifications, and / or software firmware specifications sent by the second user 7 and the device 8, and if the product specifications, hardware specifications, and / or software firmware specifications supported by the device code 80 match the product specifications, hardware specifications, and / or software firmware specifications in the update request, the software system 1 can determine that the device code 80 is the device code 80 required by the second user 7 and the device 8.

[0061] In a preferred embodiment, in order to enable the software system 1 to compare different versions of the device code 80 and determine which version of the device code 80 to use, the product specifications, hardware specifications, and / or software / firmware specifications supported by the different versions of the device code 80 can all be recorded in the storage medium 9 or another database or medium accessible by the software system 1 when registering the device code 80. In this way, the software system 1 can compare different versions of the device code 80, determine version information suitable for the second user 7 and the device 8, and further obtain the device code 80 specified by the version information.

[0062] In S1, an update request is an online update request sent over the network.

[0063] In a preferred embodiment, the online update request transmitted over the network is also known as an OTA online update of the code in the conventional sense, and essentially, the device 8 connects to a server, retrieves the latest code from the server, and then updates, and the server and the software system 1 running on the server do not need to know the network location information of the device 8. That is, the device 8 establishes a network connection with the software system 1 that provides network access functionality based on the network location information of the software system 1, and sends an update request to the software system 1. Subsequently, it directly retrieves the device code 80 from the software system 1 via the same network connection. Alternatively, the device 8 establishes a network connection with a collection unit 2 that provides network access functionality based on the network location information of the software system 1, sends an update request to the collection unit 2, and then establishes another network connection with a transmission unit 5 and retrieves the device code 80 from the transmission unit 5 via the other network connection. Herein, the method of performing network connection and code retrieval in an OTA online update of the code via a network connection established on the device 8 side is not limited to these, and those skilled in the art can make any equivalent modifications and designs according to the actual application needs.

[0064] In the above-described OTA online update method for the code, device 8 must know the website location information of the server. Therefore, the software system 1 according to the present invention provides the following improvement method for determining that an online update request transmitted over the network is an OTA update of the code.

[0065] The content of the update request includes network location information of the device 8 operated by the second user 7, and the software system 1 transmits the device code 80 to the device 8 operated by the second user 7 via the network based on the network location information.

[0066] These improvement methods can be used in the following scenarios.

[0067] Device 8 does not need to know the network location information of the software system 1 and its server. The software system 1 completes the update of the device code 80 to device 8 using a push method. In a preferred embodiment, regarding the network location information of device 8, after receiving an update request sent from the first user 6 or the second user 7, or after actively generating an update request after registering a new device code 80, the software system 1 writes the network location information to the update request based on the metadata of device 8 recorded in the software system 1. The transmission unit 5 establishes a network connection with device 8 based on the network location information in the update request and transmits the device code 80 to device 8 to perform the update. In this asynchronous method of completing the update of the device code 80, the transmission of the update request and the reception of the device code 80 are performed by two connections with different target devices, which differs from the prior art in that device 8 establishes a network connection with the software system 1 and then downloads the update through the connection between device 8 and the software system 1.

[0068] In practice, in the scenario described above, updating the device code 80 does not require a download by the device 8 itself. The first user 6, the second user 7, or any other user, if authorized, can send an update request to the software system 1 using the improved method described above. The software system 1 then establishes a connection with the device 8 based on the device 8's network location information, and then actively sends the device code 80 to the device 8 to complete the update. In a preferred embodiment, the update request does not need to include the network location information of the device 8. The software system 1 can query the metadata of the device 8 recorded in the software system 1 by querying a database, obtain the network location information of the device 8 from the metadata, and then send a request to the transmission unit 5, instructing the transmission unit 5 to send the device code 80 to the device 8 based on the network location information obtained from the metadata of the device 8.

[0069] The network location information may simply be an IP address, and there may be a default communication protocol (a port supported by device 8 by default) between the software system 1 and the device 8 for transmitting the device code 80. In such a case, the software system 1 can proactively connect to device 8 and transmit the updated device code 80 simply by knowing the IP address of device 8. Alternatively, the network location information may be a combination of an IP address and a port, that is, the network location information may include information specifying a network communication protocol. In this way, the software system 1 can establish a connection between devices by combining an IP address (location) and a port (communication protocol) and transmit the updated device code 80 without requiring any default network communication protocol between the software system 1 and the device 8. Hereinafter, the method for completing the asynchronous update of the device code 80 is not limited to these, and those skilled in the art can make any equivalent modifications and designs according to the actual application needs.

[0070] In a preferred embodiment, the device code 80 provided by the first user 6 is provided to the software system 1 in the form of a software code package, the software code package may include a compressed file containing all the software code included in the device code 80. In another preferred embodiment, the device code 80 provided by the first user 6 is provided to the software system 1 in the form of a system image file, the system image file containing all the software code included in the device code 80.

[0071] In a preferred embodiment, regardless of whether it is a system image file or a software code package, when the software system 1 receives the device code 80, it can scan all the software code contained in the device code 80. First, the system image file containing the device code 80 is mounted to a sector separated from memory or hard disk memory (if it is a zImage, its contents can be unzipped into a folder), or the software code package containing the device code 80 is unzipped into a designated folder in hard disk memory. Next, the file system traverses the files and directories in the mounted sector or the folder, i.e., scans the component configuration contained in the system image file and software code package. Based on the traverse results, after understanding the file and directory structure of the device code 80, it can compare it with the file and directory structures of known operating system cores, drivers, application programs, commonly used software components and / or category libraries to obtain operating system cores, drivers, application programs, commonly used software components and / or category libraries whose file and directory structures match. By following the procedure described above, after receiving the device code 80, the software system 1 can scan and analyze the configuration list of the software code contained in the device code 80. The configuration list may consist of metadata for each software code that exists in the form of an operating system core, drivers, application programs, commonly used software components and / or category libraries (the metadata is data that describes information related to the software code, and for example, descriptive information such as the name of each software code may also be in the form of metadata), and the contents of the configuration list may include metadata for the device code 80 itself (the metadata is data that describes information related to the device code 80).

[0072] In a preferred embodiment, based on the configuration list of at least one software code included in the device code 80, the software system 1 can detect code analysis events by monitoring the CVE list corresponding to each software code included in the configuration list (for example, for the Linux Kernel, monitoring the CVE list corresponding to the Linux Kernel) and monitoring any abnormal changes in the CVE list. A code analysis event can be triggered when a vulnerability is added to the list, when a patch code for the vulnerability is provided and added to the vulnerability record, or when a patch code for the vulnerability is updated and an abnormal change occurs in the contents of the list, where the patch code is a form of risk code, but is not limited thereto, and any equivalent modifications and designs can be made to malicious software code, which is a form of risk code, according to the actual application needs of a person skilled in the art. The code analysis event corresponding to the risk code is triggered when the risk code is newly added or updated, and the triggered event is received by the comparison unit 4. The CVE list is a form of risk code registration list described herein, but is not limited thereto, and any equivalent modifications and designs can be made to different forms of risk code registration lists according to the actual application needs of a person skilled in the art.

[0073] In a preferred embodiment, after the device 8 completes updating the device code 80, a patch code is newly added or updated, triggering a code analysis event corresponding to the patch code. The software system 1 transmits the code analysis event to the comparison unit 4. Upon receiving the code analysis event, the comparison unit 4 can request the code acquisition unit 3 to retrieve the patch code from the storage medium 9 where the patch code is stored, where the storage medium 9 may be the same storage medium 9 as the storage medium 9 storing the device code 80, or it may be a different storage medium 9. In another preferred embodiment, when the software system 1 monitors that a patch code has been newly added or updated, it may first retrieve and compile the source code of the patch code stored in another storage medium 9, and store the compiled result (binary code or intermediate code) in the storage medium 9. In this case, the first compiled result can be considered as part of the entire patch code, and the comparison unit 4 retrieves the entire patch code (including the source code, binary code, and / or intermediate code) from the storage medium 9 and the other storage medium 9. The methods for monitoring the risk code registration list and retrieving the codes described above are not limited to those described above, and those skilled in the art can make any equivalent modifications and designs according to their actual application needs.

[0074] In a preferred embodiment, after the patch code has been acquired, the comparison unit 4 can compare the component contents of the patch code with the component contents of at least one corresponding software code among the device codes 80. If the result of the comparison indicates that the at least one software code contains at least one security risk, the comparison unit 4 can request the transmitting unit 5 to issue an early warning notification for the security risk.

[0075] In a preferred embodiment, issuing the risk early warning notification means sending the risk early warning notification to at least one of the providers of the device code 80 (first user 6), the operator of the device 8 (second user 7), or the administrator (second user 7 or the administrator of the software system 1) via at least one network communication means such as email, mobile phone push notification, or mobile phone short message notification. Regarding the function of early risk warning, a patch code is a form of risk code, and the reason for the existence of the patch code itself is that the software code included in the device code 80 has a corresponding known vulnerability or a newly discovered vulnerability, and the patch code is code to fix that vulnerability, and if the result of a comparison between the component contents of the patch code and the component contents of the software code shows that the patch code is not included in the component contents of the software code, it indicates that the vulnerability still exists in the device code 80, and a malicious actor can use the vulnerability to attack the device 8 running online by executing the device code 80, in other words, the existence of the vulnerability is a risk to the first user 6, the second user 7, or any third party, and the early risk warning notification is a prior warning notification to the relevant parties about this risk, thereby achieving preventive control against the risk of the device code 80.

[0076] In a preferred embodiment, if one form of the risk code is malicious software code, the malicious software code indicates a known vulnerability. That is, if a comparison of the component contents of the malicious software code with the component contents of the software code indicates that the component contents of the software code still contain the malicious software code, it indicates that the vulnerability still exists in the device code 80, and a risk early warning notice should be issued.

[0077] With respect to the "component content of software code" and "component content of risk code" as described herein, the "component content" includes "program instructions included in the code structure of the code," "storage structures in the memory of the code," and "environmental settings and configuration data necessary for the execution of the code," and the code structure of the code includes any binary code, intermediate code, and / or any computer program code written in a computer programming language for loading and execution. Furthermore, the "security risk" as described herein includes the risk that the code contains vulnerabilities, viruses and / or malicious software, and / or the risk that the code will perform unexpected logical operations. The method of scanning security risks by comparing the risk code and software code as described above is not limited to these, and those skilled in the art can make any equivalent modifications and designs according to their actual application needs.

[0078] As shown in Figure 3, in S2, the step of comparing the component contents of the risk code with the component contents of the at least one software code is: Step S21 involves extracting at least one first component feature corresponding to the aforementioned risk code, Step S22 involves extracting at least one second component feature corresponding to the aforementioned at least one software code, The process includes step S23, which compares at least one first component feature with at least one second component feature.

[0079] Furthermore, in S21, the first component features are obtained by analyzing the code configuration content and / or code execution results corresponding to the risk code, the code configuration content includes the risk code and / or the first intermediate code from which the risk code is compiled, and the code execution results include the semantic information that the risk code and / or the first intermediate code express during simulation execution when a simulation is performed on the risk code and / or the first intermediate code.

[0080] Furthermore, in S22, the at least one second component feature is obtained by analyzing at least one code configuration and / or at least one code execution result corresponding to the at least one software code, wherein the at least one code configuration includes at least one binary code and / or at least one second intermediate code obtained by disassembling the at least one binary code, and the at least one code execution result includes semantic information expressed by the at least one binary code and / or the at least one second intermediate code during simulation execution when a simulation is performed on the at least one binary code and / or the at least one second intermediate code.

[0081] Furthermore, the programming language structure of the first intermediate code and / or the at least one second intermediate code is defined by an intermediate language, an intermediate presentation, a structured language, and / or a structured protocol.

[0082] In S2, the types of risk code include patch code, malicious code, and / or any code for correcting or creating a software vulnerability or software virus related to at least one software code.

[0083] In S2, the code analysis event for the risk code is triggered when the risk code is newly added to or updated in the risk code registration list.

[0084] As shown in Figure 4, before the code analysis event is triggered in S2, the software system 1 further includes the step of detecting at least one code analysis event based on the configuration list of at least one software code. In S2, the code analysis event corresponding to the risk code is one of the at least one code analysis event.

[0085] As shown in Figure 2, the component configuration of the device code 80 of device 8 may consist of software code that exists in different forms, such as a system core, drivers, application programs, components, and / or category libraries. The code configuration of each software code may include scripts, binary code, and / or intermediate code. Therefore, at least one software code may be understood as part of the device code 80. At least one code configuration may be understood as part of the said at least one software code.

[0086] The at least one piece of software code contained in one device 8 typically consists of a list that may include components such as the Linux Kernel, OpenSSL, and sqlite. As these components are constantly validated, vulnerabilities may be discovered in any of them, corresponding patch codes will be distributed, and these will then be added or updated to network CVE lists (CVE repositories) and GitHub.

[0087] When these vulnerabilities and patch codes are newly added or updated to the network's CVE list and GIT Hub by the affiliated unit or organization, the software system 1 described herein will not be notified. Therefore, a code analysis event must be triggered, that is, before it is triggered, the software system 1 must monitor the CVE list and GIT Hub, such as Linux Kernel, OpenSSL, and sqlite, based on the configuration list of device code 80, in order to detect these code analysis events.

[0088] This results in the technical benefit that the software system 1 can immediately complete the code security detection work for device code 80 when vulnerabilities and patch codes are newly added to or updated on a network risk code registration list (e.g., CVE list).

[0089] Furthermore, the configuration list is obtained by the software system 1 scanning and / or analyzing the component configuration of the device code 80 when the device code 80 is provided to the software system 1.

[0090] Device code 80 may be a single .o file (object file), .img file (system image file), or .so file (library), or it may be a .zip or .gz compressed file (containing the .o and .so files necessary for the entire device, and the compressed file retains the path structure of these files).

[0091] Taking the entire device code 80 of device 8 as an example, device code 80 contains many software code files, and each software code is combined with device code 80 in the form of different components (e.g., Linux Kernel, OpenSSL, sqlite, etc.). Each software code file has a different path location. There are several ways to obtain the configuration list of the software code contained in device code 80. One method is to scan the entire device code 80 based on the file path information and determine which components are included in device code 80 by seeing that the related files for different component software codes are located in different locations. Alternatively, the contents of each software code file can be read and compared to determine whether the contents of these files contain characteristics of a particular component and to grasp the component list. For example, when reading the code configuration contents of the code contained in the software code, it can be compared with known code segments of known software such as Linux Kernel, OpenSSL, and sqlite, and the components included in device code 80 can be determined based on the results of the comparison. The method for scanning and / or analyzing the component configuration of device code 80 to obtain a configuration list of each software code within device code 80 is not limited to these, and those skilled in the art can make any equivalent modifications and designs according to their actual application needs.

[0092] In a preferred embodiment, the code structure of the patch code includes a file containing Javascript code written in Javascript. The patch code serves to correct a vulnerability in the software code contained in the device code 80. The comparison unit in the software system 1 can first determine the position of the Javascript file corresponding to the file name in the code structure of the software code, based on the file name of the Javascript file. After reading the contents of the Javascript file of the patch code and the contents of the corresponding Javascript file of the software code, the unit compares the component contents contained in the two files, that is, compares them to see if the corrected code segment is included in the contents of the two files, uses the corrected code segment as a component feature for comparison, and if the comparison results match, it indicates that the software code does not contain the vulnerability; if they do not match, it indicates that the software code contains the vulnerability.

[0093] In a preferred embodiment, in addition to featuring segments included in the code, comparative component features may also include the memory structure of the patch code and the software code, and / or the environment settings and configuration information of the patch code and the software code. For example, if a file is added to the code configuration of the patch code, but the file name of this file does not exist in the code configuration of the corresponding software code, and / or if the patch code adds a new parameter to the environment settings and configuration, but this parameter does not exist in the environment settings and configuration of the corresponding software code, then the component content of the software code does not include the patch code, and therefore the software code still has a vulnerability corresponding to the patch code.

[0094] According to the above example, the code segments, file name structure, and / or configuration contents of the comparison patch code are the first component features in the comparison of component contents. The code segments, file name structure, and / or configuration contents of the comparison software code are the second component features in the comparison of component contents. The method for comparing component features obtained by analyzing the code configuration contents is not limited to these, and those skilled in the art can make any equivalent modifications and designs according to their actual application needs.

[0095] In a preferred embodiment, the code structure of the software code includes a first file containing binary code, and the filename of the first file and its corresponding location in the storage structure can correspond to a second file written in C / C++ source code included in the patch code. The second file contains code to fix a vulnerability. In this case, first the first file is disassembled to generate a first intermediate code (code with LLVM IR as the intermediate code representation format), and then the second file is compiled and disassembled to generate a second intermediate code (code with LLVM IR as the intermediate code representation format). Furthermore, simulation execution can be performed on the first and second intermediate codes, that is, program instructions in the first and second intermediate codes are read, simulation parameters are input, and then logical operations are performed based on the read program instructions. After all program instructions have been executed, semantic information to be represented during simulation execution can be obtained based on the execution history of each instruction during the execution of the program instructions, the output and input of function calls, and / or the execution order, where “semantic information” as described herein includes the values ​​of memory and / or intermediate variables during program execution, and / or instructions, functions and their output and input values ​​called during simulation execution. After comparing the semantic information of the first intermediate code and the semantic information of the second intermediate code to obtain similarity, it can be determined whether the code segments of the first intermediate code and the code segments of the second intermediate code match based on the similarity, and further, it can be determined whether the first file contains code in the second file to correct the vulnerability. Here, regarding the semantic information of the first intermediate code and the semantic information of the second intermediate code, if the component features consisting of all the content are completely included in the semantic information of each other, the similarity can be considered to be 100%. If the component features consisting of only a part of the content are included in the semantic information of each other, the proportion of that part to the total content becomes the similarity, and thus a similarity of 0% to 100% can be obtained. If the similarity exceeds the set threshold, it indicates that the first file contains the code of the second file.The threshold is a reference value for determining whether the code in the second file is included in the first file. For example, if the threshold is set to 90%, a similarity score exceeding 90% indicates that the first file contains the code in the second file; otherwise, it indicates that it does not.

[0096] In a preferred embodiment, the code structure of the software code includes a first file containing intermediate code (Java bytecode), and the file name of the first file and its corresponding location in the storage structure may correspond to a second file written in Java source code, which is included in the patch code. The second file contains code to fix the vulnerability. In this case, after compiling the second file into intermediate code (Java bytecode), its semantic information is obtained by running a simulation, and further, the component characteristics of the values ​​obtained from memory and / or intermediate variables, and / or instructions, functions, and their output and input values ​​called during the simulation execution, are used to compare whether the first file contains code to fix the vulnerability in the second file.

[0097] The method for comparing the component features of the semantic information obtained through the simulation execution described above is not limited to these methods, and those skilled in the art can make any equal modifications and designs according to their actual application needs.

[0098] In S3, the issued risk early warning includes an order that instructs the device 8 and / or the user operating the device 8 to perform the risk code update operation on the device 8, or the risk early warning notification includes a presentation of information that provides the first user 6, the second user 7, and / or the system administrator with a warning about the at least one security risk.

[0099] This allows the risk early warning notification to include an order, and if a security risk occurs in device 8, the technical effect is obtained that the order can directly cause device 8 to immediately update the risk code and immediately correct the vulnerability. The reason why the technical solution of the present invention can achieve such an effect is that the present invention focuses on component analysis of binary code, that is, if the present invention detects that a vulnerability has occurred in device code 80, it already possesses the binary code (risk code) of a patch corresponding to the vulnerability and can immediately notify device 8 to update the risk code.

[0100] As shown in Figure 5, the device code risk early warning calculation device 11 according to this embodiment includes a collection unit 21, a code acquisition unit 31, a comparison unit 41, and a transmission unit 51. The collection unit 21 is used to receive an update request for the device code 80. The code acquisition unit 31 is used to acquire the device code 80 from the storage medium 9, and the device code 80 includes at least one software code. The transmission unit 51 is used to transmit the device code 80 to the device 8 and issue an early risk warning notification. The comparison unit 41 is used to obtain the risk code from the storage medium 9 and / or another storage medium 9 by the code acquisition unit 31 when a code analysis event corresponding to the risk code is triggered, and to compare the risk code with the device code 80.

[0101] In the comparison described above, if the comparison results indicate that the at least one software code contains at least one security risk, the transmitting unit 51 is further used to issue a warning notification, which sends an early warning notification of the risk to at least one of the providers of the device code 80, the operators of the device 8, and the administrators via at least one network communication means.

[0102] In a preferred embodiment, the arithmetic unit 11 is an embedded device. The acquisition unit 21, code acquisition unit 31, comparison unit 41 and / or transmission unit 51 may be integrated circuit units designed in a hardware description language and embedded in the arithmetic unit 11, or they may be integrated into the embedded system of the arithmetic unit 11 in the form of software code. The acquisition unit 21, code acquisition unit 31, comparison unit 41 and transmission unit 51 are driven by an embedded system running within the arithmetic unit 11.

[0103] In another preferred embodiment, the arithmetic unit 11 is a server, the acquisition unit 21, the code acquisition unit 31, the comparison unit 41 and / or the transmission unit 51 are integrated into a software system 1 in the form of software code, the software system 1 is provided to and executed by the arithmetic unit 11 in an embedded or installable manner, and the acquisition unit 21, the code acquisition unit 31, the comparison unit 41 and the transmission unit 51 are driven by the software system 1 which is executed within the arithmetic unit 11.

[0104] In another preferred embodiment, the computing device 11 is comprised of a distributed server, and the collection unit 21, code acquisition unit 31, comparison unit 41 and / or transmission unit 51 are integrated into a distributed software system 1 in the form of software code, and the distributed software system 1 is located on and executed on the distributed server to constitute the computing device 11. The collection unit 21, code acquisition unit 31, comparison unit 41 and transmission unit 51 are driven by the distributed software system 1 executed within the computing device 11.

[0105] The methods for configuring the computing unit 11 with the different forms of hardware and software combinations described above are not limited to these, and those skilled in the art can make any equivalent modifications and designs according to their actual application needs.

[0106] Furthermore, as shown in Figure 3, the comparison unit 41 includes a first feature extraction unit, a second feature extraction unit, and a feature comparison unit. The first feature extraction unit is used to extract at least one first component feature corresponding to the risk code. The second feature extraction unit is used to extract at least one second component feature corresponding to the at least one software code. The feature comparison unit is used to compare at least one first component feature with at least one second component feature.

[0107] Furthermore, the first feature extraction unit or the second feature extraction unit includes at least one analysis unit and at least one extraction unit, The at least one analysis unit is used to analyze the code structure and / or code execution results corresponding to the risk code to obtain a first component feature, and / or to analyze the code structure and / or code execution results corresponding to the at least one software code to obtain a second component feature. The at least one extraction unit is used to extract a first component feature or a second component feature obtained through analysis.

[0108] As shown in Figure 4, the device code risk early warning calculation device further includes at least one detection unit. The at least one detection unit is used to detect code analysis events by monitoring a risk code registration list (e.g., a CVE list) corresponding to each software code included in the configuration list, based on the configuration list of the at least one software code included in the device code 80, and by monitoring abnormal fluctuations in the risk code registration list.

[0109] In summary, the present invention discloses a device code risk early warning method, a software system 1, and a computing device 11, which, by updating a device code 80 including at least one software code, comparing the component contents of a risk code with the component contents of the device code 80, and transmitting a risk early warning for the device 8, can provide a risk early warning to the device 8 regardless of whether the device 8 is offline or whether the network status is normal, thereby achieving preventive control against risks of the device code 80.

[0110] The detailed description above is a specific description of feasible embodiments of the present invention, and such embodiments are not intended to limit the scope of protection of the present invention. Any equivalent implementation or modification that does not depart from the scope of the present invention should be included within the scope of protection of the present invention. [Explanation of Symbols]

[0111] 1. Software System 2 Collection Units 3 Code Acquisition Unit 4 Comparison Units 5. Transmitter Unit 6. First User 7. Second User 8 equipment 9 Storage medium 80 Device Code 11 Arithmetic unit 21 Collection Units 31 Code Acquisition Unit 41 Comparison Units 51 Transmitter Unit

Claims

1. The steps include: collecting an update request for a device code that includes at least one piece of software code; obtaining the device code based on the content of the update request; and transmitting the device code to the device. When a code analysis event corresponding to a risk code is triggered, the steps include: obtaining the risk code and comparing the component content of the risk code with the component content of at least one of the software codes; A method for early warning of risks in device code, characterized by including the step of issuing an early warning notification of risks if the result of the comparison indicates that the at least one software code contains at least one security risk.

2. The method for early risk warning of a device code according to claim 1, characterized in that the step of issuing the aforementioned early risk warning notification is to issue the early risk warning notification to at least one of the provider of the device code, the operator of the device, and the administrator via at least one network communication means.

3. The method for early warning of risks for a device code according to claim 1, characterized in that the device code is provided by a first user, the collection of update requests is the distribution of the device code and / or the reception of updates, and the device is operated by a second user.

4. The method for early warning of risks associated with device codes according to claim 1, characterized in that the at least one software code includes at least one binary code.

5. The step of obtaining the device code is, specifically, the step of obtaining the device code from the storage medium. The method for early warning of risks for a device code according to claim 1, comprising the step of obtaining the device code from the storage medium based on code version information that specifies the device code.

6. The device code risk early warning method according to claim 5, characterized in that the code version information is directly specified by the content of the update request, or the code version information that the device needs to be updated is determined based on the product specifications, hardware specifications and / or software firmware specifications included in the content of the update request.

7. The method for early warning of risks in a device code according to claim 1, characterized in that the update request is an online update request transmitted via a network.

8. The method for early warning of risks for a device code according to claim 1, characterized in that the content of the update request includes network location information of the device, and the device code is transmitted to the device via the network based on the network location information.

9. The step of comparing the component contents of the risk code with the component contents of the at least one software code is: The steps include extracting at least one first component feature corresponding to the risk code, The steps include extracting at least one second component feature corresponding to the at least one software code, The method for early warning of risks in a device code according to claim 1, comprising the step of comparing the at least one first component feature with the at least one second component feature.

10. The method for early warning of device code risks according to claim 9, characterized in that the first component features are obtained by analyzing the code configuration content and / or code execution results corresponding to the risk code.

11. The method for early warning of risks for device codes according to claim 10, characterized in that the code configuration includes the risk code and / or a first intermediate code from which the risk code is compiled, and the code execution result includes semantic information expressed by the risk code and / or the first intermediate code during simulation execution when a simulation is performed on the risk code and / or the first intermediate code.

12. The method for early warning of device code risks according to claim 9, characterized in that the at least one second component feature is obtained by analyzing at least one code configuration and / or at least one code execution result corresponding to the at least one software code.

13. The method for early warning of risks for device codes according to claim 12, characterized in that the at least one code configuration includes at least one binary code and / or at least one second intermediate code obtained by disassembling the at least one binary code, and the execution result of the at least one code includes semantic information expressed by the at least one binary code and / or the at least one second intermediate code during simulation execution when a simulation is performed on the at least one binary code and / or the at least one second intermediate code.

14. The method for early warning of risks in device codes according to claim 11 or 13, characterized in that the programming language structure of the intermediate code is defined by an intermediate language, an intermediate representation, a structured language, and / or a structured protocol.

15. The early warning method for device code risks according to claim 1, characterized in that the types of risk codes include patch codes, malicious program code, and / or any code for correcting or creating software vulnerabilities or software viruses.

16. The method for early warning of device code risks according to claim 1, characterized in that the code analysis event corresponding to the risk code is triggered when the risk code is newly added or updated.

17. The method for early warning of device code risks according to claim 1, characterized in that, before the code analysis event is triggered, at least one code analysis event is detected based on the configuration list of at least one software code, and the code analysis event corresponding to the risk code is one of the at least one code analysis events.

18. The method for early warning of risks for a device code according to claim 17, characterized in that the configuration list is obtained by scanning and / or analyzing the component configuration of the device code when the device code is collected.

19. The method for early warning of risks for a device code according to claim 18, characterized in that the configuration list includes metadata for the device code itself and / or metadata for at least one software code included in the component configuration of the device code.

20. The method for early warning of risks for a device code according to claim 19, characterized in that the at least one software code exists in the component configuration of the device code in the form of a system core, driver, application program, component, and / or category library.

21. The device code is a system image file, and the component configuration contained in the system image file is scanned and / or analyzed, the at least one software code present in the system image file is identified, and the configuration list of the at least one software code is obtained. Alternatively, the device code is a software code package, and the method for early warning of device code risks according to claim 20 is characterized by scanning and / or analyzing the component configuration contained in the software code package, identifying the at least one software code present in the software code package, and obtaining the configuration list of the at least one software code.

22. The early risk warning notification for a device code according to claim 2, characterized in that the early risk warning notification includes an order which instructs the device and / or a user operating the device to perform the risk code update operation on the device, or the early risk warning notification includes a disclosure which in turn provides the provider of the device code, the operator of the device and / or the administrator of the device code with a warning about the at least one security risk.

23. It includes a collection unit, a code acquisition unit, a comparison unit, and a transmission unit. The collection unit is used to receive device code update requests. The code acquisition unit is used to acquire the device code, and the device code includes at least one software code. The transmission unit is used to transmit the device code to the device and issue an early warning notification of risk. A software system for early warning of device code risks, characterized in that the comparison unit is used to compare the risk code with the device code after the code acquisition unit has acquired the risk code when a code analysis event corresponding to the risk code is triggered.

24. The comparison unit includes a first feature extraction unit, a second feature extraction unit, and a feature comparison unit. The first feature extraction unit is used to extract at least one first component feature corresponding to the risk code. The second feature extraction unit is used to extract at least one second component feature corresponding to the at least one software code. The software system for early warning of device code risks according to claim 23, characterized in that the feature comparison unit is used to compare at least one first component feature with at least one second component feature.

25. The first feature extraction unit or the second feature extraction unit includes at least one analysis unit and at least one extraction unit, The at least one analysis unit is used to analyze the code structure and / or code execution results corresponding to the risk code to obtain a first component feature, and / or to analyze the code structure and / or code execution results corresponding to the at least one software code to obtain a second component feature. The software system for early warning of device code risks according to claim 24, characterized in that the at least one extraction unit is used to extract first component features and / or second component features obtained through analysis.

26. Further including at least one detection unit, The software system for early warning of device code risks according to claim 23, characterized in that the at least one detection unit is used to detect code analysis events by monitoring a risk code registration list corresponding to each software code included in the configuration list based on the configuration list of at least one software code, and by monitoring abnormal fluctuations in the risk code registration list.

27. It includes a collection unit, a code acquisition unit, a comparison unit, and a transmission unit. The collection unit is used to receive device code update requests. The code acquisition unit is used to acquire the device code from the storage medium, and the device code includes at least one software code. The transmission unit is used to transmit the device code to the device and issue an early warning notification of risk. A device code risk early warning calculation device, characterized in that the comparison unit is used to compare the risk code with the device code after the code acquisition unit has acquired the risk code from the storage medium and / or another storage medium when a code analysis event corresponding to the risk code is triggered.

Images