Device code risk warning method, software system and computing device

Abstract

Disclosed a device code risk warning method, a software system and a computing device. The device code risk warning method comprises: collecting an updating request of a device code, according to the content of the updating request, obtaining the device code, and transmitting the device code to a device; wherein the device code comprises at least one software code; when a code analysis event corresponding to a risk code is triggered, obtaining the risk code, and comparing the risk code with the at least one software code; when the comparison result shows that the at least one software code contains at least one security risk, sending a risk warning notification. The method has the beneficial effect that no matter whether the device is offline and whether the network state is normal, risk warning can be performed on the device, such that risk prevention and control of the device code are achieved.

Description

Device code risk warning method, software system and computing device Technical Field

[0001] The present invention relates to the field of code risk warning, and in particular to a device code risk warning method, software system and computing device. Background Art

[0002] When performing vulnerability detection on a live website server, existing techniques require establishing a network connection to the live server, obtaining the source code of the web front-end system on the live server, and then comparing the obtained source code with the source code of the patch code to determine whether there are known or newly discovered vulnerabilities. The live website server itself is a hardware device, and its operating environment also executes a large amount of binary code (e.g., Linux kernel, web server, etc.).

[0003] When performing vulnerability detection on the website backend system on the online server and the hardware devices running online, since the intermediate code and binary code on the server and the binary code in the hardware devices are all codes that cannot be recognized by humans, and the server and hardware devices are already running online, the current existing technology is to send a network packet simulating an attack to the server and hardware devices based on the behavior description of a specific vulnerability through the network. After the server and hardware devices receive the network packet, the response of the server and hardware devices is monitored to see if it matches the behavior description of the specific vulnerability. If it matches, it means that the specific vulnerability exists in the online server and hardware devices, thereby providing security warnings to the operators of the server and online hardware devices.

[0004] When analyzing vulnerabilities and conducting risk detection and control for online servers and / or hardware devices, the code running on the servers and / or hardware devices is primarily intermediate or binary code. Without the source code, it's impossible to compare the patch source code with the source code of the online system. Source code comparison is impossible without the source code. Simulated packet vulnerability analysis requires network support. If the system is offline or the network isn't functioning properly, simulated packets can't be delivered to the online server and / or hardware device under test, making simulated packet vulnerability analysis and risk monitoring impossible. Furthermore, if the driver for a specific vulnerability isn't triggerable with simulated packets, that vulnerability can't be detected with simulated packets.

[0005] As can be seen from the above, in the field of information security risk prevention and control, vulnerability analysis and security warnings for hardware devices lacking source code and / or running online are important technical issues. Currently, there are no device code risk prevention and control methods, software systems, or computing devices that can provide vulnerability analysis and security warnings for devices lacking source code and / or being offline, and therefore, there is an urgent need for development.

[0006] Summary of the Invention

[0007] The present invention provides a device code risk warning method, software system, and computing device, which are implemented through the following technical solutions:

[0008] Option 1:

[0009] A device code risk early warning method comprises the following steps:

[0010] Collecting an update request for a device code, obtaining the device code according to the content of the update request, and transmitting the device code to a device; the device code includes at least one software code;

[0011] When a code analysis event corresponding to a risk code is triggered, the risk code is obtained, and component contents of the risk code and at least one of the software codes are compared;

[0012] When the comparison result shows that the at least one software code contains at least one security risk, a risk warning notification is issued.

[0013] Furthermore, issuing a risk warning notification refers to issuing a risk warning notification to at least one of the provider of the device code, the operator of the device, and the administrator through at least one network communication channel.

[0014] Furthermore, the device code is provided by a first user, the collection of update requests is received for the release and / or update of the device code; and the device is operated by a second user.

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

[0016] Furthermore, the obtaining of the device code is specifically obtained from a storage medium, including:

[0017] The device code is specified by code version information, and the device code is obtained from the storage medium according to the code version information.

[0018] Furthermore, the code version information is directly specified by the content of the update request, or the code version information required to be updated for the device is determined based on a product specification, a hardware specification, and / or a firmware specification included in the content of the update request.

[0019] Furthermore, the update request is an online update request transmitted via a network.

[0020] Furthermore, 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.

[0021] Furthermore, the risk code and the at least one software code are compared in terms of component content, including:

[0022] Retrieving at least one first component feature corresponding to the risk code;

[0023] Retrieving at least one second component feature corresponding to the at least one software code;

[0024] The at least one first component characteristic and the at least one second component characteristic are compared.

[0025] Furthermore, the first component feature is obtained by analyzing the code composition content and / or code execution results corresponding to the risk code.

[0026] Furthermore, the code composition includes the risk code and / or the first intermediate code compiled from the risk code, and the code execution result includes the semantic information revealed by the risk code and / or the first intermediate code during the simulation execution process when the risk code and / or the first intermediate code are simulated.

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

[0028] Furthermore, the at least one code composition includes at least one binary code and / or at least one second intermediate code after the at least one binary code is decompiled, and the at least one code execution result includes the semantic information revealed by the at least one binary code and / or the at least one second intermediate code during the simulation execution process when the at least one binary code and / or the at least one second intermediate code are simulated.

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

[0030] Furthermore, the types of risk codes include a patch code, a malicious program code, and / or any code used to correct or generate a software vulnerability or a software virus.

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

[0032] Furthermore, before the code analysis event is triggered, at least one code analysis event is detected based on a component list of the at least one software code, and the code analysis event corresponding to the risky code is one of the at least one code analysis event.

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

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

[0035] Furthermore, the at least one software code exists in the component composition of the device code in the form of a system kernel, a driver, an application, a component, and / or a class library.

[0036] Furthermore, the device code is a system image file, and components contained in the system image file are scanned and / or analyzed to identify the at least one software code present in the system image file, thereby obtaining the component list of the at least one software code;

[0037] Alternatively, the device code is a software code package, and the components contained in the software code package are scanned and / or analyzed to identify the at least one software code in the software code package, thereby obtaining the component list of the at least one software code.

[0038] Furthermore, the risk warning notification is accompanied by an instruction, which instructs the device and / or the user operating the device to perform the update of the risk code on the device; or the risk warning notification is accompanied by a prompt message, which provides a warning of the at least one security risk to the provider of the device code, the operator and / or the manager of the device.

[0039] Option 2:

[0040] A software system for device code risk warning includes a collection unit, a code acquisition unit, a comparison unit, and a transmission unit;

[0041] The collecting unit is used to receive a request for updating the device code;

[0042] The code acquisition unit is used to obtain the device code, and the device code includes at least one software code;

[0043] The transmission unit is used to transmit the device code to a device and issue a risk warning notification;

[0044] The comparison unit is configured to, when a code analysis event corresponding to a risk code is triggered, obtain the risk code via the code retrieval unit, and compare the risk code with the device code.

[0045] Furthermore, the comparison unit includes a first feature extraction unit, a second feature extraction unit and a feature comparison unit;

[0046] The first feature extraction unit is configured to extract at least one first component feature corresponding to the risk code;

[0047] The second feature extraction unit is configured to extract at least one second component feature corresponding to the at least one software code;

[0048] The feature comparison unit is used to compare at least one first component feature with at least one second component feature.

[0049] Furthermore, the first feature extraction unit or the second feature extraction unit includes at least one analysis unit and at least one capture unit;

[0050] The at least one analysis unit is configured to analyze the code content and / or code execution result corresponding to the risk code to obtain a first component feature, and / or analyze the code content and / or code execution result corresponding to the at least one software code to obtain a second component feature;

[0051] The at least one capturing unit is used to capture the first component feature and / or the second component feature obtained after analysis.

[0052] Furthermore, it also includes at least one detection unit,

[0053] The at least one detection unit is used to monitor the risk code login list corresponding to each software code contained in the composition list of the at least one software code, and detect code analysis events by monitoring changes in the risk code login list.

[0054] Option 3

[0055] A device code risk warning computing device includes a collection unit, a code acquisition unit, a comparison unit, and a transmission unit;

[0056] The collecting unit is used to receive a request for updating the device code;

[0057] The code acquisition unit is used to obtain the device code from a storage medium, wherein the device code includes at least one software code;

[0058] The transmission unit is used to transmit the device code to a device and issue a risk warning notification;

[0059] The comparison unit is configured to, when a code analysis event corresponding to a risk code is triggered, obtain the risk code from the storage medium and / or another storage medium by the code retrieval unit, and compare the risk code with the device code.

[0060] Such a design has the following advantages: the present invention updates the device code of an online device containing at least one software code, compares the risk code with the content of the device code components, and issues a risk warning for the device. Regardless of whether the device is offline or the network status is normal, the risk warning can be issued to the device. BRIEF DESCRIPTION OF THE DRAWINGS

[0061] FIG1 is a flow chart of a device code risk warning method according to the present invention;

[0062] FIG2 is a structural block diagram of a software system for device code risk warning according to the present invention;

[0063] FIG3 is a flow chart of comparing component contents of a risk code and at least one software code according to the present invention.

[0064] FIG4 is a flow chart of a device code risk warning method according to a component list of at least one software code in a software system before a code analysis event is triggered.

[0065] FIG5 is a structural block diagram of a computing device for device code risk warning according to the present invention;

[0066] In the figure, 1. software system; 2. collection unit; 3. code retrieval unit; 4. comparison unit; 5. transmission unit; 6. first user; 7. second user; 8. device; 9. storage medium; 80. device code; 11. computing device; 21. collection unit; 31. code retrieval unit; 41. comparison unit; 51. transmission unit. DETAILED DESCRIPTION

[0067] The present invention can be more fully understood through the following description, including the following glossary of terms and concluding examples. For the sake of brevity, the disclosures of publications, including patents, cited in this specification are incorporated herein by reference.

[0068] The following examples are provided for detailed description. These examples are non-limiting and merely represent various aspects and features of the present invention. These examples are provided for illustrative purposes only and do not limit the scope of the present invention. Furthermore, the figures in the examples omit unnecessary components or components that can be implemented using conventional techniques to clearly illustrate the technical features of the present invention.

[0069] In the most restricted technical sense, the code components of "software code" as used herein include any binary code, intermediate code, and / or any computer program code written in a computer programming language for loading and execution. "Device code" as used herein is code that runs on a device and provides logical operations and services for the device. The device code is composed of binary code, intermediate code, and / or any computer program code written in a computer programming language. That is, the device code includes at least one piece of software code, which is present in the form of a component such as a system kernel, driver, application, component, and / or class library. "Binary code" as used herein may include any code represented in binary format. "Intermediate code" as used herein may include any code represented in an intermediate language, intermediate representation, structured language, and / or structured protocol. For example, Java bytecode represented in a format defined by an intermediate representation and LLVM bitcode decompiled from binary code are both intermediate codes and may also be considered intermediate codes. The "risk code" herein includes any binary code, intermediate code, and / or any computer program code written in a computer programming language for loading and execution. Risk code includes patch code, malware code, and / or any code used to correct or generate a software vulnerability or virus. "Metadata," also known as metadata, is data describing an object or information related to that object. The "risk code registry" herein includes any list registered, registered, and / or represented according to a structure declared in a structured language and / or protocol. The list may be stored and published in the form of a file, database, and / or webpage. The list contains registry information for the risk code described herein, including the risk code itself, metadata for the risk code, and information about the software vulnerability or virus corresponding to the risk code. The Common Vulnerabilities and Exposures (CVE) repository is one embodiment of the risk code registry, but is not limited thereto. The "semantic information" described herein may include, when simulating the execution of a code, the values ​​retrieved from memory and / or intermediate variables during the execution process, the execution history of each instruction during the execution process, the output / input values ​​of the function, and / or any other numerical information that can be captured.All or part of the semantic information of the two codes can be used as component features for comparison. The similarity of the two codes is determined based on the degree of matching.

[0070] Furthermore, the "collection unit", "code acquisition unit", "transmission unit", "comparison unit", "first feature extraction unit", "second feature extraction unit", "feature comparison unit", "analysis unit", "capture unit" and "detection unit" described herein are a processing unit that provides logical operations or services. The implementation of the processing unit may include a category library, a software component, a software agent, an application, any program block that can be built-in, installed, introduced or expanded to run in the "software system or computing device that provides device code risk warning" described herein, or any integrated circuit unit designed in a hardware description language that can be embedded in the "computing device that provides device code risk warning" described herein.

[0071] The "software system for providing device code risk warnings" described herein may include system firmware, an application, a software engine, an operating system, or any other programmable software platform. In a preferred embodiment, the "software system for providing device code risk warnings" described herein can be deployed and run on a single machine. Specifically, the collection unit, code acquisition unit, transmission unit, comparison unit, first feature extraction unit, second feature extraction unit, feature comparison unit, analysis unit, capture unit, and detection unit described herein are all integrated into a single software system, which is then deployed and run on a single machine. In another preferred embodiment, the "software system for providing device code risk warning" described in this article can be implemented through the collaboration of multiple machines, 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, capture unit, detection unit and other processing units described in this article are provided to different machines, and the processing units in different machines interact with each other through online methods including the internet, WiFi, Bluetooth, etc., and are then integrated into a software system for providing device code risk warning through multiple machines.

[0072] The "computing device for providing device code risk warnings" described herein may be implemented as a network communication device, a server, or any other information and communication device with networking, data processing, or control capabilities. In a preferred embodiment, the "computing device for providing device code risk warnings" described herein may be implemented by a single machine. Specifically, the collection unit, code acquisition unit, transmission unit, comparison unit, first feature extraction unit, second feature extraction unit, feature comparison unit, analysis unit, capture unit, and detection unit described herein are all integrated into a single machine to serve as the computing device for providing device code risk warnings. In another preferred embodiment, the "computing device for providing device code risk warning" described in this article can be implemented by the collaboration of multiple machines, 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, capture unit, detection unit and other processing units described in this article are provided to different machines, and the processing units in different machines can interact with each other through online methods including the internet, WiFi, Bluetooth, etc., and then be integrated into a computing device for providing device code risk warning through multiple machines.

[0073] Continuing from the above, 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," "capture unit," and "detection unit" described herein can be implemented individually 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," "capture unit," and "detection unit" described herein can be implemented in the same processing unit.

[0074] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0075] FIG1 is a flow chart of a preferred device code risk warning calculation method of the present invention. The device code 80 risk warning method includes:

[0076] S1. Collect an update request for a device code 80, obtain the device code 80 from a storage medium 9 according to the content of the update request, and transmit the device code 80 to a device; the device code 80 includes at least one software code;

[0077] S2. When a code analysis event corresponding to a risk code is triggered, the software system 1 obtains 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 at least one software code;

[0078] S3. When the comparison result shows that the at least one software code contains at least one security risk, a risk warning notification is issued.

[0079] As shown in FIG2 , there is a structural block diagram of a software system 1 for device code 80 risk warning of the present invention. An explanation of a preferred embodiment of the device code risk warning operation in this case is provided. In which, the first user 6 is the user of the software system 1, the second user 7 is the operator or manager of the 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, an external storage device, a database, or any storage device that can store the device code 80 or the risk code; the device code 80 is a code for running on the device 8 and providing logical operations and services for the device 8 on the device 8.

[0080] In a preferred embodiment, second user 7 is a user of software system 1 and manages device 8 through software system 1 by registering device 8's metadata with software system 1. Device 8's metadata includes device 8's network location information, product specifications, hardware specifications, and / or firmware specifications. In another preferred embodiment, second user 7 is merely the operator of device 8. Device 8's metadata is registered with software system 1 by the system administrator of software system 1, who then acts as the administrator of device 8.

[0081] In a preferred embodiment, first user 6 is the developer of device 8 . First user 6 provides device code 80 to software system 1 via a human-machine interface provided by software system 1 . When providing device code 80 to software system 1 , first user 6 may enter relevant information about device code 80 on the human-machine interface and provide this information along with device code 80 to software system 1 via the human-machine interface. This relevant information includes version information of device code 80 and product specifications, hardware specifications, and / or firmware specifications of the device 8 supported by device code 80 .

[0082] In a preferred embodiment, the software system 1 stores the device code 80 and its related data (including the code version information of the device code 80 and the product specifications, hardware specifications, and / or firmware specifications of the device 8 supported by the device code 80) in the storage medium 9 to complete the registration of the device code 80 in the software system 1.

[0083] In a preferred embodiment, the collection unit 2, the code acquisition unit 3, the comparison unit 4 and the transmission unit 5 serve as processing units integrated into the software system 1. Each processing unit can provide at least one function to realize interaction with other processing units. When a processing unit needs to make a request to another processing unit, it can use the content of the request as a parameter and input the content of the request to the other processing unit in the form of a function call. After receiving the content of the request, the other processing unit can provide service for the request based on the content of the request. In another preferred embodiment, each processing unit can also interact with other processing units through a network connection or inter-process communication. When a processing unit needs to send a request to another processing unit, the processing unit can establish a TCP / UDP Socket connection to the other processing unit and transmit the content of the request to the other processing unit through a communication protocol agreed upon by both parties, or send the content of the request to the other processing unit through an inter-process communication mechanism implemented by partial memory sharing, so that the other processing unit can receive the content of the request and provide services for the request based on the content of the request. The implementation method of how to provide a request to a processing unit and how the processing unit receives the request is not limited to this. Those skilled in the art can make any equal changes in design based on actual application requirements.

[0084] After software system 1 completes registration of device code 80, in a preferred embodiment, software system 1 may search for device 8 registered in software system 1 using the product specifications, hardware specifications, and / or firmware specifications supported by device code 80. If the product specifications, hardware specifications, and / or firmware specifications of device 8 match those supported by device code 80, software system 1 may generate an update request for device 8, which is an update request for updating device code 80, and provide this update request to collection unit 2. In another preferred embodiment, when first user 6 provides device code 80 to software system 1 via a human-machine interface (HMI) of software system 1, the update request for device 8 may be directly input into the HMI and provided directly to software system 1. Upon receipt of the update request, software system 1 may provide the update request to collection unit 2. In another preferred embodiment, the collection unit 2 can receive requests via a network connection. In this case, the first user 6 can establish a TCP / UDP socket connection to the collection unit 2 through any other software system 1 and transmit the update request for the device 8 in the form of an online update request via the network connection to the collection unit 2. In another preferred embodiment, the software system 1 sends a notification to the device 8 via a network connection, notifying the device 8 that a new device code 80 has been registered to the software system 1, and includes the code version information of the device code 80 in the content of the notification. After receiving the notification, the device 8 can generate an update request containing the code version information based on the content of the notification, establish a network connection to the collection unit 2 in the form of an online update request, 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 content of the notification to the device 8. After receiving the notification, the device 8 can generate an update request, the content of the update request includes the product specifications, hardware specifications, and / or firmware specifications of the device 8, and transmit the update request to the software system 1 via the network connection. After receiving the update request, the software system 1 can determine the code version information of the device code 80 that is consistent with the product specifications, hardware specifications, and / or firmware specifications based on the content of the update request, and after adding the code version information to the content of the update request, provide the update request to the collection unit 2.

[0085] In a preferred embodiment, after completing the registration of device code 80, software system 1 does not need to issue any notification to device 8. Device 8 operated by second user 7 periodically sends online update requests to software system 1 via a network connection. The update requests include device 8's product specifications, hardware specifications, and / or firmware specifications, and are transmitted to software system 1 via the network connection. Upon receiving the update requests, software system 1 compares the update requests with the product specifications, hardware specifications, and / or firmware specifications to determine the code version information of device code 80 that matches the product specifications, hardware specifications, and / or firmware specifications. If the device code 80 is the device code 80 that device 8 needs to update, software system 1 adds the code version information to the update request and provides the update request to collection unit 2. In another preferred embodiment, the second user 7, as the operator of the device 8, can also generate an update request for the device 8 through another software system 1. The content of the update request includes the product specifications, hardware specifications, and / or firmware specifications of the device 8, and the update request is transmitted to the software system 1 via a network connection.

[0086] In summary, the generation and transmission of the update request content and the method for collecting the update request by the collection unit 2 are not limited to this. Those skilled in the art can make any equal changes in the design according to actual application requirements.

[0087] Furthermore, the device code 80 is provided by the first user 6. The device code 80 registered in the software system 1 may be a device code 80 issued for a new device 8, an updated device code 80 for an old device 8, or an updated and issued device code 80 for an existing device 8 that has just been registered with the software system 1. The at least one software code included in the device code 80 includes at least one binary code.

[0088] In a preferred embodiment, the device 8 is operated by the second user 7. The device 8 is an embedded system device, a server device, an IoT sensor device, a network communication device, or any computer device with networking capabilities.

[0089] In a preferred embodiment, the update request includes the network location information of device 8. The network location information is entered into the update request by software system 1 based on the metadata of device 8 registered with software system 1; alternatively, the update request is generated by device 8, and when device 8 generates the update request, device 8 enters its own network location information.

[0090] In a preferred embodiment, after receiving an update request for device code 80, collection unit 2 can request code retrieval unit 3 to retrieve, from storage medium 9, the device code 80 corresponding to the code version information contained in the update request, i.e., the device code 80 specified by the code version information. After obtaining device code 80, collection unit 2 can request transmission unit 5 to establish a TCP / UDP socket connection with device 8 based on the network location information of device 8 contained in the update request. Device code 80 is then transmitted to device 8 via the socket connection and an agreed-upon communication protocol. This completes the update of device code 80 on device 8, ensuring that device code 80 becomes the code executed by device 8 during online operation.

[0091] The device code risk warning calculation method described above enables a first user 6 to update the device code 80 of a device 8 operated by a second user 7 through the software system 1, so that the device code 80 becomes the code executed when the device 8 is online. Even when the device 8 is offline, the software system 1 implementing the device code risk warning calculation method can issue a risk warning for the device code 80 for the device 8. Under the above method, the software system 1 can also issue a risk warning for the device code 80 for the device 8 even when the device 8 is online, meaning that both online and offline situations are included in the device code risk warning calculation method.

[0092] The software system 1 in S1 obtains the device code 80 from the storage medium 9 according to the code version information corresponding to the device code 80;

[0093] Furthermore, the code version information is directly specified in the content of the update request, or the software system 1 determines the code version information that needs to be updated for the device 8 based on a product specification, a hardware specification, and / or a firmware specification included in the content of the update request.

[0094] As shown in Figure 2 , if the update request is issued by the first user 6, the first user 6 can clearly enter the version information of the device code 80 in the update request. Upon receiving the update request, the software system 1 can directly retrieve the device code 80 from the storage medium 9 based on the version information in the update request. However, if the update request is issued by the second user 7 or device 8, the second user 7 and device 8 will not know the latest version of the device code 80 provided by the first user 6. The second user 7 only has information about the device 8 it operates and its product specifications, hardware specifications, and / or firmware specifications.

[0095] Therefore, in the case where the update request sent by the second user 7 and device 8 includes the product specifications, hardware specifications, and / or firmware specifications of the device 8 itself, but does not include the latest version information of the device code 80, when the update request of the second user 7 and device 8 is delivered to the software system 1, the software system 1 can determine which version of the device code 80 is used by the device 8 based on the product specifications, hardware specifications, and / or firmware specifications sent by the second user 7 and device 8. If the product specifications, hardware specifications, and / or firmware specifications supported by the device code 80 are consistent with the product specifications, hardware specifications, and / or firmware specifications in the update request, it can be determined that the device code 80 is the device code 80 required by the second user 7 and device 8.

[0096] In a preferred embodiment, to enable the software system 1 to compare different versions of the device code 80 and determine which one to use, the product specifications, hardware specifications, and / or firmware specifications supported by the different versions of the device code 80 are recorded in the storage medium 9 or other database or media accessible to the software system 1 when registering the device code 80. This allows the software system 1 to compare different versions of the device code 80, determine the version information suitable for the second user 7's device 8, and then retrieve the device code 80 specified by the version information.

[0097] The update request in S1 is an online update request transmitted via the network.

[0098] In a preferred embodiment, the online update request transmitted over the network, also known as an OTA (Over-the-Air) code update, essentially involves device 8 connecting to a server, obtaining the latest code from the server, and then performing the update. The server and the software system 1 running on the server do not need to know the network location information of device 8. Specifically, device 8 establishes a network connection to software system 1 (which provides network access) based on the network location information of software system 1, issues an update request to software system 1, and then directly obtains device code 80 from software system 1 via the same network connection. Alternatively, device 8 establishes a network connection to collection unit 2 (which provides network access) based on the network location information of software system 1, issues an update request to collection unit 2, and then establishes another network connection to transmission unit 5, obtaining device code 80 from transmission unit 5 via another network connection. The method of connecting and obtaining code for OTA code updates using a network connection established by device 8 is not limited to this method, and those skilled in the art will be able to make any equivalent design changes based on actual application requirements.

[0099] Regarding the aforementioned OTA code update method, the device 8 must know the server's URL location information. Therefore, the software system 1 of this embodiment also provides the following improved methods for the OTA code update request transmitted via the network:

[0100] The content of the update request includes the network location information of the device 8 operated by the second user 7 . 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.

[0101] This improved method can be used in the following scenarios:

[0102] Device 8 does not need to know the network location information of software system 1 or its servers. Software system 1 updates device code 80 for device 8 using a push mechanism. In a preferred embodiment, device 8's network location information is obtained upon receipt of an update request from first user 6 or second user 7, or upon proactively generating an update request after a new device code 80 is registered. Software system 1 then writes the device 8's network location information into the update request based on the metadata of device 8 registered with software system 1. Transmission unit 5 then establishes a network connection to device 8 based on the network location information in the update request and transmits device code 80 to device 8 for update. This asynchronous method of updating device code 80 involves sending the update request and receiving the device code 80 via two separate connections. This differs from the traditional method where device 8 establishes a connection to software system 1 and then downloads the code via the connection between device 8 and software system 1.

[0103] In fact, the above scenario allows updating device code 80 without requiring device 8 to download the code itself. First user 6, second user 7, or other users, if authorized, can use the improved method described above to send an update request to software system 1. Software system 1 then establishes a connection to device 8 indicated by the network location information of device 8 based on the network location information of device 8, and proactively transmits device code 80 to the device to complete the update. In a preferred embodiment, the update request does not necessarily include device 8's network location information. Software system 1 queries a database to retrieve metadata about device 8 registered with software system 1. After obtaining device 8's network location information from the metadata, it can then send a request to transmission unit 5, requesting that transmission unit 5 transmit device code 80 to device 8 based on the network location information obtained from device 8's metadata.

[0104] The network location information can simply be an IP address. There is a default communication protocol between the software system 1 and the device 8 for transmitting the device code 80 (the default port supported by the device 8). In this case, the software system 1 only needs to know the IP address of the device 8 to proactively connect to it and transmit the updated device code 80. Alternatively, the network location information can be an IP address plus a port, meaning that the network location information includes information specifying the network communication protocol. In this case, the software system 1 and the device 8 do not need to have a default network communication protocol. The software system 1 can establish a connection between the devices and transmit the updated device code 80 based on the IP address (location) plus the port (communication protocol). The method of asynchronously updating the device code 80 is not limited to this method. Those skilled in the art can make any equivalent design changes based on actual application requirements.

[0105] 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 that contains 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 that contains all the software code included in the device code 80.

[0106] In a preferred embodiment, when software system 1 receives device code 80, whether in the form of a system image file or a software code package, it scans all software code contained in device code 80. First, the system image file containing device code 80 is mounted to memory or a partitioned sector from hard disk memory (if a zImage is used, its contents can be decompressed into a folder), or the software code package containing device code 80 is decompressed into a designated folder on hard disk memory. The file system then uses the file system to traverse the mounted sector or folder, scanning the components contained in the system image file and software code package. Based on the traversal results, the file and directory structure of device code 80 is determined and then compared with the file and directory structure of known operating system kernels, drivers, applications, commonly used software components, and / or class libraries to identify operating system kernels, drivers, applications, commonly used software components, and / or class libraries with matching file and directory structures. Following the above procedure, after collecting the device code 80, the software system 1 can scan and analyze the software code contained in the device code 80 to generate a component list. The component list may be composed of metadata (data describing information related to the software code, such as the name of each software code, and also information describing information such as the name of each software code, which can also be a form of metadata) for each software code in the form of an operating system kernel, driver, application, common software component, and / or class library. The component list may also include metadata (data describing information related to the device code 80) for the device code 80 itself.

[0107] In a preferred embodiment, based on the component list of the at least one software code included in the device code 80, the software system 1 can monitor the CVE list corresponding to each software code included in the component list (for example, for the Linux Kernel, that is, monitor the CVE list corresponding to the Linux Kernel), and detect code analysis events by monitoring changes in the CVE list. When a vulnerability is added to the list, a patch code corresponding to the vulnerability is provided and added to the vulnerability record, or the patch code of the vulnerability is updated, resulting in changes in the content of the list, a code analysis event can be triggered; wherein the patch code is a form of risk code, but is not limited to this. For malware code, one form of risk code, a person skilled in the art can make any equivalent change design based on actual application requirements. The code analysis event corresponding to the risk code is triggered when the risk code is added or updated, and the triggered event is received by the comparison unit 4. Among them, the CVE list is one implementation form of the risk code login list described in this article, and is not limited to this. People familiar with the art can provide any equal change design for different forms of risk code login lists based on actual application requirements.

[0108] In a preferred embodiment, after device 8 completes an update of device code 80, when a patch code is added or updated, triggering a code analysis event corresponding to the patch code, software system 1 transmits the code analysis event to comparison unit 4. Upon receiving the code analysis event, comparison unit 4 can request code retrieval unit 3 to retrieve the patch code from storage medium 9 storing the patch code. Storage medium 9 can be the same storage medium 9 as the storage medium 9 storing device code 80, or a separate storage medium 9. In another preferred embodiment, when software system 1 detects that a patch code has been added or updated, it can pre-retrieve the source code of the patch code stored in another storage medium 9 and compile it. The compiled result (binary code or intermediate code) is then stored in storage medium 9. In this case, the pre-compiled result can be considered part of the entire patch code. Comparison unit 4 then retrieves the entire patch code (including source code, binary code, and / or intermediate code) from storage medium 9 and the separate storage medium 9. The above-mentioned method of monitoring and retrieving the risk code login list is not limited to this. Those skilled in the art can make any equal change design according to actual application requirements.

[0109] In a preferred embodiment, after comparison unit 4 retrieves the patch code, it compares the patch code with the corresponding at least one piece of software code in device code 80. If the comparison results indicate that the at least one piece of software code contains at least one security risk, it requests transmission unit 5 to issue a risk warning notification regarding the security risk.

[0110] In a preferred embodiment, the issuance of the risk warning notification refers to issuing a risk warning notification to at least one person among the provider of the device code 80 (the first user 6), the operator of the device 8 (the second user 7), and the administrator (the second user 7 or the administrator of the software system 1) through at least one network communication channel, such as an email, a mobile phone push notification, a mobile phone text message notification, etc. Among them, the role of risk warning is that patch code is one type of risk code. The reason why the patch code itself exists is that there is a corresponding known or newly discovered vulnerability in the software code contained in the device code 80, and the patch code is the code that corrects the vulnerability. If the comparison result of the component content of the patch code and the software code shows that the component content of the software code does not include the patch code, it means that the vulnerability still exists in the device code 80. Unscrupulous persons can exploit the vulnerability to attack the device 8 that executes the device code 80 and is running online. In other words, the existence of the vulnerability includes the risk of the first user 6, the second user 7 or any other third party. The risk warning notification is an advance warning notification to the relevant persons regarding this risk, thereby realizing risk prevention and control of the device code 80.

[0111] In a preferred embodiment, when the risky code is malware code, the malware code represents a code with a known vulnerability. Specifically, if a comparison of the malware code and the software code components reveals that the software code components still contain the malware code, it indicates that the vulnerability still exists in device code 80 and a risk warning notification is required.

[0112] Regarding the "component content of software code" and "component content of risk code" described herein, the "component content" refers to "the program instructions contained in the code composition content of the code", "the storage structure of the code in the memory", and "the environment settings and configuration data required for executing the code"; wherein, the code composition content of the code includes any binary code (Binary Code) for loading and execution, intermediate code, and / or any computer program code written in a computer programming language. In addition, the "security risk" described herein includes the risk of the code containing vulnerabilities, viruses and / or malware, and / or any risk of causing the code to perform unpredictable logical operations. The above method of scanning a security risk by comparing the risk code with the software code is not limited to this. Those familiar with the art can make any equivalent change design based on actual application requirements.

[0113] As shown in FIG3 , the comparison of the component contents of the risk code and the at least one software code in S2 includes the following steps:

[0114] S21. Retrieving at least one first component feature corresponding to the risk code;

[0115] S22, extracting at least one second component feature corresponding to the at least one software code;

[0116] S23. Compare at least one first component feature and at least one second component feature.

[0117] Furthermore, the first component feature in S21 is obtained by analyzing the code composition content and / or the code execution result corresponding to the risk code; wherein, the code composition content includes the risk code and / or the first intermediate code after the risk code is compiled, and the code execution result includes the semantic information revealed by the risk code and / or the first intermediate code during the simulation execution process when the risk code and / or the first intermediate code are simulated.

[0118] Furthermore, the at least one second component feature described in S22 is obtained by analyzing at least one code component content and / or at least one code execution result corresponding to the at least one software code; wherein, the at least one code component content includes at least one binary code and / or at least one second intermediate code after decompilation of the at least one binary code, and the at least one code execution result includes semantic information revealed by the at least one binary code and / or the at least one second intermediate code during the simulation execution process when the at least one binary code and / or the at least one second intermediate code are simulated.

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

[0120] The types of risk codes in S2 include a patch code associated with the at least one software code, a malicious program code, and / or any code used to correct or generate a software vulnerability or software virus.

[0121] The code analysis event of the risk code in S2 is triggered when the risk code is added or updated to a risk code registration list.

[0122] As shown in FIG4 , before the code analysis event is triggered in S2, the software system 1 further detects at least one code analysis event based on a component list of the at least one software code. In S2, the code analysis event corresponding to the risky code is one of the at least one code analysis event.

[0123] As shown in Figure 2 , the components of device code 80 of device 8 may be composed of software code in various forms, including system kernels, drivers, applications, components, and / or class libraries. The code components of each software code may include scripts, binary code, and / or intermediate code. Therefore, at least one software code can be considered a portion of device code 80 , and at least one code component can be considered a portion of the at least one software code.

[0124] The at least one software code contained in a device 8 generally consists of a list, which may include, for example, components such as the Linux Kernel, OpenSSL, and SQLite. These components are constantly tested, and vulnerabilities are discovered and corresponding patches are released. These patches are then added or updated to the CVE list (CVE repository) and GIT Hub on the Internet.

[0125] When these vulnerabilities and patch codes are added or updated to the online CVE list and GIT Hub by their respective units or organizations, the software system 1 described herein is not notified. Therefore, for code analysis events to be triggered, software system 1 must monitor CVE lists and GIT Hub for Linux Kernel, OpenSSL, SQLite, and other vulnerabilities based on the device code 80 component list before triggering to detect these code analysis events.

[0126] The technical effect brought about by this is that the software system 1 can immediately complete the code security detection work of the device code 80 when a vulnerability and patch code are added or updated to the risk code registration list (such as the CVE list) on the network.

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

[0128] The device code 80 can be a single .o file (target file), .img file (system image file), .so file (program library), or a .zip or .gz compressed file (the content contains the .o and .so files required for the entire device, and the compressed file also retains the path structure of these files).

[0129] For example, the overall device code 80 of a device 8 contains numerous software code files. Each software code is organized into different components (e.g., Linux Kernel, OpenSSL, SQLite, etc.) within the device code 80. Each software code file is stored in a different path. There are different ways to obtain a list of the software code components within the device code 80. One approach is to scan the entire device code 80 based on file path information. As the software code for different components has its associated files stored in different locations, this approach can essentially determine which components are contained within the device code 80. Alternatively, the component list can be determined by reading the contents of each software code file and comparing them to see if they contain specific components. For example, when reading the code components within a code file within a software code, the code can be compared with known code snippets from known software such as Linux Kernel, OpenSSL, SQLite, etc. Based on the comparison results, the components contained within the device code 80 can be determined. The method of scanning and / or analyzing the components of the device code 80 to obtain the composition list of each software code in the device code 80 is not limited to this. Those skilled in the art can make any equal changes in design according to actual application requirements.

[0130] In a preferred embodiment, the code composition content of the patch code includes a file written in Javascript and containing Javascript code. The function of the patch code is to correct a vulnerability in a software code contained in the device code 80. The comparison unit in the software system 1 can first locate the position of the Javascript file corresponding to the file name in the code composition content of the software code by the file name of the Javascript file. After reading the contents of the Javascript file of the patch code and the corresponding Javascript file of the software code respectively, the component contents contained in the two files are compared, that is, the contents of the two files are compared to see whether they contain the corrected code fragment, and the corrected code fragment is used as the component feature of the comparison. If the comparison results match, it means that the software code does not contain the vulnerability, and if they do not match, it means that the software code contains the vulnerability.

[0131] In a preferred embodiment, in addition to using code fragments as features, component features used for comparison may also be the storage structure of the patch code and software code in memory and / or the environment settings and configuration information of the patch code and software code. For example, if a patch code's code content includes a new file whose name does not exist in the corresponding software code's code content, and / or if the patch code adds a new parameter to the environment settings and configuration that does not exist in the corresponding software code's environment settings and configuration, then the software code's component content does not include the patch code, and therefore the vulnerability corresponding to the patch code still exists in the software code.

[0132] In the above example, the code snippet, file name structure, and / or configuration content of the patch code used for comparison is the first component feature in the component content comparison. The code snippet, file name structure, and / or configuration content of the software code used for comparison is the second component feature in the component content comparison. The method of comparing component features derived from analyzing the code components is not limited to this method. Those skilled in the art can make any equivalent design changes based on actual application requirements.

[0133] In a preferred embodiment, the code composition of a software code includes a first file containing binary code, and the file name of the first file and its relative position in the storage structure can correspond to a second file written in C / C++ source code contained in a patch code. The second file contains code for correcting a vulnerability. In this case, the first file is first disassembled into a first intermediate code (code represented by LLVM's IR as the intermediate code), and the second file is compiled and then disassembled into a second intermediate code (code represented by LLVM's IR as the intermediate code). Then, simulation execution can be performed on the first intermediate code and the second intermediate code, that is, by reading the program instructions in the first intermediate code and the second intermediate code, feeding the simulation parameters, and then performing logical operations according to the read program instructions. After all program instructions have been executed, semantic information revealed during the simulated execution can be obtained based on the execution history of each instruction, the outputs, inputs, and / or execution order of function calls during the execution of the program instructions. The "semantic information" herein includes the values ​​of memory and / or intermediate variables during program execution, and / or the instructions, functions, and their output and input values ​​called during the simulated execution. The semantic information of the first intermediate code and the semantic information of the second intermediate code are compared to obtain a similarity. Based on this similarity, it can be determined whether the code fragments of the first and second intermediate codes match, and furthermore, whether the first file contains the code used to correct the vulnerability in the second file. If the component features of the entire content of the first and second intermediate code semantic information are completely contained in each other's semantic information, the similarity is 100%. If only a portion of the component features are contained in each other's semantic information, the proportion of the portion in the entire content is the similarity. Based on this, similarity results ranging from 0% to 100% can be obtained. If the similarity exceeds a set threshold, it indicates that the first file contains code from the second file. The threshold is a reference value used to determine whether the code of the second file is included in the first file. For example, if the threshold is set to 90%, it means that when the similarity is higher than 90%, the first file contains the code of the second file, otherwise it does not.

[0134] In a preferred embodiment, the code components of a software code include a first file containing intermediate code (Java bytecode). The file name of the first file and its relative location in the storage structure correspond to a second file containing Java source code contained in a patch code. The second file contains code for correcting a vulnerability. In this case, after the second file is compiled into intermediate code (Java bytecode), its semantic information is obtained through simulated execution. The semantic information, including values ​​retrieved from memory and / or intermediate variables, and / or component characteristics of instructions, functions, and their output and input values ​​called during the simulated execution, can be used to compare the first file to determine whether it contains the code for correcting the vulnerability in the second file.

[0135] The above-mentioned method of comparing component features of semantic information obtained by simulation execution is not limited thereto, and those skilled in the art can make any equivalent changes in design according to actual application requirements.

[0136] The issuance of the risk warning in S3 is accompanied by an instruction, and the instruction is used to instruct the device 8 and / or a user operating the device 8 to perform the update of the risk code on the device 8; or the risk warning notification is accompanied by a prompt message, and the prompt message is used to provide the first user 6, the second user 7, and / or the system administrator with a warning of the at least one security risk.

[0137] This technical benefit lies in the fact that the risk warning notification can include a directive. When a security risk arises on device 8, this directive directly instructs device 8 to immediately update the risk code and patch the vulnerability. Our technical solution achieves this benefit because we analyze binary code components. That is, when we detect a vulnerability in device code 80, we already have the binary code for the patch (the risk code), allowing us to notify device 8 to update the risk code immediately.

[0138] As shown in FIG5 , this embodiment further provides a device code risk warning computing device 11 , comprising a collection unit 21 , a code acquisition unit 31 , a comparison unit 41 , and a transmission unit 51 ;

[0139] The collecting unit 21 is used to receive an update request of the device code 80;

[0140] The code acquisition unit 31 is used to obtain the device code 80 from a storage medium 9. The device code 80 includes at least one software code.

[0141] The transmission unit 51 is used to transmit the device code 80 to a device 8 and issue a risk warning notification.

[0142] The comparison unit 41 is configured to, when a code analysis event corresponding to a risk code is triggered, cause the code retrieval unit 31 to retrieve the risk code from the storage medium 9 and / or another storage medium 9 and compare the risk code with the device code 80 .

[0143] If the comparison result shows that the at least one software code contains at least one security risk, the transmission unit 51 is also used to issue a warning notification. The transmission unit 51 issues a risk warning notification to at least one person among the provider of the device code 80, the operator of the device 8, and the manager through at least one network communication channel.

[0144] In a preferred embodiment, the computing device 11 is an embedded device. The collection unit 21, code acquisition unit 31, comparison unit 41, and / or transmission unit 51 are designed using a hardware description language and can be integrated into the computing device 11's integrated circuit unit or embedded system in the computing device 11 in the form of software code. The collection unit 21, code acquisition unit 31, comparison unit 41, and transmission unit 51 are driven by the embedded system running in the computing device 11.

[0145] In another preferred embodiment, the computing device 11 is a server, and the collection unit 21, the code retrieval 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 the computing device 11 for operation by means of built-in or installation, and the collection unit 21, the code retrieval unit 31, the comparison unit 41 and the transmission unit 51 are driven by the software system 1 running in the computing device 11.

[0146] In another preferred embodiment, the computing device 11 is composed of distributed servers. 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. The distributed software system 1 is deployed and executed on the distributed servers to form 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 running on the computing device 11.

[0147] The above-mentioned method of combining different forms of hardware and software to form the computing device 11 is not limited to this. Those skilled in the art can make any equal change design according to actual application requirements.

[0148] Further, in conjunction with FIG3 , the comparison unit 41 includes a first feature extraction unit, a second feature extraction unit and a feature comparison unit;

[0149] The first feature extraction unit is configured to extract at least one first component feature corresponding to the risk code;

[0150] The second feature extraction unit is configured to extract at least one second component feature corresponding to the at least one software code;

[0151] The feature comparison unit is used to compare at least one first component feature with at least one second component feature.

[0152] Furthermore, the first feature extraction unit or the second feature extraction unit includes at least one analysis unit and at least one capture unit;

[0153] At least one analysis unit, configured to analyze the code content and / or code execution result corresponding to the risk code to obtain a first component feature, and / or analyze the code content and / or code execution result corresponding to the at least one software code to obtain a second component feature;

[0154] At least one capturing unit is used to capture the first component feature or the second component feature obtained after analysis.

[0155] 4 , the device code risk warning computing device further includes at least one detection unit;

[0156] The at least one detection unit is used to monitor the risk code login list (for example, CVE list) corresponding to each software code contained in the composition list of the at least one software code included in the device code 80, and detect code analysis events by monitoring changes in the risk code login list.

[0157] In summary, the present invention discloses a device code risk warning method, a software system 1, and a computing device 11. By updating a device code 80 containing at least one software code for an online device 8, comparing the risk code with the component content of the device code 80, and issuing a risk warning for the device 8, the risk warning can be issued to the device 8 regardless of whether the device 8 is offline or the network status is normal, thereby achieving risk prevention and control of the device code 80.

[0158] The above detailed description is a specific description of the feasible embodiments of the present invention. The 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 protection of the present invention should be included in the scope of protection of the present invention.

Claims

1. A device code risk early warning method, characterized by: The following steps are involved: Collecting an update request for a device code, obtaining the device code according to the content of the update request, and transmitting the device code to a device; the device code includes at least one software code; When a code analysis event corresponding to a risk code is triggered, the risk code is obtained, and component contents of the risk code and at least one of the software codes are compared; When the comparison result shows that the at least one software code contains at least one security risk, a risk warning notification is issued.

2. The device code risk early warning method according to claim 1, characterized in that: The issuing of the risk warning notification refers to issuing a risk warning notification to at least one of the provider of the device code, the operator and the manager of the device through at least one network communication channel.

3. The device code risk early warning method according to claim 1, characterized in that: The device code is provided by a first user, and the collection of update requests is received for the release and / or update of the device code; the device is operated by a second user.

4. The device code risk early warning method according to claim 1, characterized in that: The at least one software code includes at least one binary code.

5. The device code risk early warning method according to claim 1, characterized in that: The obtaining of the device code specifically includes obtaining the device code from a storage medium, including: The device code is specified by a code version information, and the device code is obtained from the storage medium according to the code version information.

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 required to be updated for the device is determined based on a product specification, a hardware specification, and / or a firmware specification included in the content of the update request.

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

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

9. The device code risk early warning method according to claim 1, characterized in that: The risk code and the at least one software code are compared for component content, including: Retrieving at least one first component feature corresponding to the risk code; Retrieving at least one second component feature corresponding to the at least one software code; The at least one first component characteristic and the at least one second component characteristic are compared.

10. The device code risk early warning method according to claim 9, characterized in that: The first component feature is obtained by analyzing the code composition content and / or code execution result corresponding to the risk code.

11. The device code risk early warning method according to claim 10, characterized in that: The code composition content includes the risk code and / or the first intermediate code compiled from the risk code, and the code execution result includes the semantic information revealed by the risk code and / or the first intermediate code during the simulation execution process when the risk code and / or the first intermediate code are simulated.

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

13. The device code risk early warning method according to claim 12, characterized in that: The at least one code composition includes at least one binary code and / or at least one second intermediate code after the at least one binary code is deassembled, and the at least one code execution result includes the semantic information revealed by the at least one binary code and / or the at least one second intermediate code during the simulation execution process when the at least one binary code and / or the at least one second intermediate code are simulated.

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

15. The device code risk early warning method according to claim 1, characterized in that: The types of risk codes include a patch code, a malicious program code, and / or any code used to correct or generate a software vulnerability or a software virus.

16. The device code risk early warning method 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 device code risk early warning method according to claim 1, characterized in that: Before the code analysis event is triggered, at least one code analysis event is detected according to a component 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 event.

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

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

20. The device code risk warning method according to claim 19, characterized in that: The at least one software code is present in the component composition of the device code in the form of system kernel, driver, application, component, and / or class library.

21. The device code risk warning method according to claim 20, characterized in that: The device code is a system image file, and components contained in the system image file are scanned and / or analyzed to identify the at least one software code present in the system image file, thereby obtaining the component list of the at least one software code; Or the device code is a software code package, and the components contained in the software code package are The at least one software code in the software code package is scanned and / or analyzed to identify the at least one software code, thereby obtaining the component list of the at least one software code.

22. The device code risk warning method according to claim 2, characterized in that: The risk warning notification is enclosed with an instruction, which instructs the device and / or the user operating the device to perform an update of the risk code on the device; or the risk warning notification is enclosed with a prompt message, which provides a warning of the at least one security risk to the provider of the device code, the operator and / or the manager of the device.

23. A software system for early warning of device code risks, characterized in that: It includes a collection unit, a code acquisition unit, a comparison unit, and a transmission unit; The collecting unit is used to receive a request for updating the device code; The code acquisition unit is used to obtain the device code, and the device code includes at least one software code; The transmission unit is used to transmit the device code to a device and issue a risk warning notification; The comparison unit is used for, when a code analysis event corresponding to a risk code is triggered, the code acquisition unit obtains the risk code and compares the risk code with the device code.

24. The device code risk warning software system according to claim 23, characterized in that: 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 and at least one second component feature.

25. The device code risk warning software system according to claim 24, characterized in that: The first feature extraction unit or the second feature extraction unit includes at least one analysis unit and at least one capture unit; The at least one analysis unit is used to analyze the code composition content and / or the code execution result corresponding to the risk code to obtain the first component feature, and / or analyze the code composition content and / or the code execution result corresponding to the at least one software code to obtain the second component feature; The at least one capture unit is used to capture the first component feature and / or the second component feature obtained after analysis.

26. The device code risk warning software system according to claim 23, characterized in that: Also includes at least one detection unit, The at least one detection unit is used to monitor the risk code login list corresponding to each software code contained in the composition list of the at least one software code, and detect code analysis events by monitoring changes in the risk code login list.

27. A computing device for device code risk warning, characterized in that: It includes a collection unit, a code acquisition unit, a comparison unit, and a transmission unit; The collecting unit is used to receive a request for updating the device code; The code acquisition unit is used to obtain 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 a device and issue a risk warning notification; The comparison unit is used for, when a code analysis event corresponding to a risk code is triggered, the code acquisition unit obtains the risk code from the storage medium and / or another storage medium, and compares the risk code with the device code.

Images