Device code-based risk scanning method and system, and computing device

Abstract

Disclosed in the present invention are a device code-based risk scanning method and system, and a computing device. The method comprises: obtaining a device code, wherein the device code is obtained from a first device, and sending the device code from the first device to a second device; wherein the device code comprises at least one software code; generating an update record; wherein the update record comprises a relationship record between the device code and the first device and / or the second device; when it is detected that a security risk is present in the device code, according to the updating record, sending a scanning result to the first device and / or the second device. In the present invention, the scanning result can be automatically sent to the user by means of the self-generated updating record, such that the efficiency and accuracy of risk scanning are improved.

Description

A device code-based risk scanning method, system, and computing device Technical Field

[0001] The present invention relates to the field of code risk prevention and control, and in particular to a risk scanning method, system and computing device based on device code. Background Art

[0002] When performing vulnerability detection on the website backend system on an online server (e.g., a website server) and the hardware devices running online, since the intermediate code, binary code on the server, and the binary code in the hardware devices are all codes that cannot be recognized by humans (e.g., Linux Kernel, Web Server, etc.), and the server and hardware devices are already running online, the current existing technology is to send a network packet of simulated attack to the server and hardware devices through the network based on the behavior description of a specific vulnerability. 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 vulnerability scanning for the operators of the server and online hardware devices.

[0003] When analyzing vulnerabilities and performing risk scans on online servers and / or hardware devices, since the code running on the servers and / or hardware devices is primarily intermediate or binary code, it's impossible to compare the patch source code with the source code of the online system without the source code. 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 sent 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.

[0004] For IoT sensors, network communication devices (such as WiFi routers), or other embedded devices with limited computing power, code component analysis cannot be directly performed on these devices, unlike virus scanning software on personal computers. Firstly, the design of PC hardware and software specifications not only takes into account the computing power required by the operating system itself, but also reserves sufficient computing power for user-installed applications. Secondly, PCs provide a general-purpose operating platform, not dedicated to a single or specific function, allowing different applications to be installed and expanded into the operating environment. Therefore, PC virus scanning software can be installed and used on the PC. For IoT sensors, network communication devices (such as WiFi routers), or other embedded devices with limited computing power, on the one hand, they do not function as general-purpose operating platforms, but rather provide a single or specific service. They do not have the conditions for freely installing applications to expand their capabilities. On the other hand, their hardware and software specifications are primarily designed to optimize the single or specific service they provide. Therefore, code component analysis is difficult to perform on these devices.

[0005] As can be seen from the above, in the field of information security risk scanning technology, how to perform vulnerability scanning on hardware devices that lack source code, are running online, and / or whose software and hardware specifications are designed for a single or specific function is a significant technical challenge. Currently, there is no device code risk scanning method, software system, or computing device that can provide vulnerability analysis for devices in situations where the device system lacks source code, is offline, has insufficient computing power, and / or cannot expand its application. Therefore, there is an urgent need for development of a risk scanning method and system that utilizes this method.

[0006] Summary of the Invention

[0007] In response to the above technical problems, the present invention provides a risk scanning method, system and computing device based on device code, which automatically sends scanning results to users through self-generated update records, thereby improving the efficiency and accuracy of risk scanning.

[0008] Option 1:

[0009] A device code-based risk scanning method, comprising:

[0010] Obtaining a device code, the device code being obtained from a first device, and sending the device code from the first device to a second device; wherein the device code includes at least one software code;

[0011] generating an update record; wherein the update record includes a relationship record between the device code and the first device and / or the second device;

[0012] When a security risk is detected in the device code, a scan result is sent to the first device and / or the second device according to the update record.

[0013] Furthermore, the sending of the scan result refers to sending a notification of the scan result to at least one of the user, operator or administrator of the first device and the second device via at least one network communication channel.

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

[0015] Furthermore, the obtaining of the device code specifically includes:

[0016] The device code is obtained from a storage medium of the first device according to an update request.

[0017] Furthermore, the method for obtaining the device code further includes:

[0018] When the update request is obtained, a device code corresponding to a version information or a device specification information in the update request is obtained in the storage medium as the device code; wherein the device specification information includes at least one of a product specification, hardware specification, and firmware specification of a device.

[0019] Furthermore, the sending the device code to the second device specifically includes:

[0020] The device code is sent to the second device according to the network location information of the second device included in the update request.

[0021] Furthermore, the detecting that there is a security risk in the device code specifically includes:

[0022] When at least one code analysis event is triggered, the component contents of at least one risk code are compared with the at least one software code; wherein the at least one risk code includes at least one of a patch code, a malicious program code, and any computer program code written in a computer program language associated with the at least one software code.

[0023] Furthermore, the at least one risk code is pre-collected according to at least one risk code registration list, or is collected when a risk code is added or updated to the at least one risk code registration list.

[0024] Furthermore, the at least one code analysis event is triggered when a component list of the at least one software code is obtained, or when the at least one risky code is added or updated.

[0025] Furthermore, the comparing the at least one risk code with the at least one software code specifically includes:

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

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

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

[0029] Furthermore, the at least one first component feature is obtained by analyzing the code composition content and / or code execution result corresponding to the at least one risk code.

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

[0031] 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.

[0032] 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.

[0033] 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.

[0034] Furthermore, before the code analysis event is triggered, the following steps are also included:

[0035] At least one code analysis event is detected according to the component list of the at least one software code, and the code analysis event corresponding to the at least one risky code is one of the at least one code analysis event.

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

[0037] 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.

[0038] 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.

[0039] Furthermore, based on the component list, the risk code login list corresponding to each software code contained in the component list is monitored, and code analysis events are detected by monitoring changes in the risk code login list.

[0040] Furthermore, the method for obtaining the composition list specifically includes:

[0041] 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;

[0042] 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.

[0043] Furthermore, sending the scan result to the first device and / or the second device according to the update record specifically includes:

[0044] Searching the update record to obtain the related records in the update record;

[0045] A scan result is issued to at least one of a user, an operator, or a manager of the first device and the second device according to the relationship record.

[0046] Furthermore, the scanning result includes at least one of a scanning report and a scanning status notification message; wherein, the scanning report is used to display the component content comparison result of the at least one software code and the at least one risk code; the scanning status notification message is used to provide a scanning status notification to at least one of the users, operators or managers of the first device and the second device.

[0047] Option 2:

[0048] A device code-based risk scanning system includes: a code sending module, an update record generating module, and a scanning result notification module;

[0049] The code sending module is configured to obtain a device code, the device code being obtained from a first device, and send the device code from the first device to a second device; wherein the device code includes at least one software code;

[0050] The update record generation module is configured to generate an update record; wherein the update record includes a relationship record between the device code and the first device and / or the second device;

[0051] The scanning result notification module is configured to send a scanning result to the first device and / or the second device according to the update record when a security risk is detected in the device code.

[0052] Furthermore, it also includes: a first feature extraction unit, a second feature extraction unit and a feature comparison unit;

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

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

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

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

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

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

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

[0060] 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.

[0061] Option 3:

[0062] A computing device based on risk scanning of device codes, comprising: a code sending module, an update record generating module, and a scanning result notification module;

[0063] The code sending module is configured to obtain a device code, the device code being obtained from a first device, and send the device code from the first device to a second device; wherein the device code includes at least one software code;

[0064] The update record generation module is configured to generate an update record; wherein the update record includes a relationship record between the device code and the first device and / or the second device;

[0065] The scanning result notification module is configured to send a scanning result to the first device and / or the second device according to the update record when a security risk is detected in the device code. BRIEF DESCRIPTION OF THE DRAWINGS

[0066] FIG1 is a schematic flow chart of a device code-based risk scanning method according to the present invention;

[0067] FIG2 is a schematic structural diagram of a device code-based risk scanning system according to the present invention.

[0068] FIG3 is a schematic structural diagram of a device code-based risk scanning computing device according to the present invention.

[0069] In the figure, 1. risk scanning system; 2. code sending module; 3. update record generation module; 4. scan result notification module; 5. first device; 6. second device; 11. computing device; 21. code sending module; 31. update record generation module; 41. scan result notification module. DETAILED DESCRIPTION

[0070] 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.

[0071] 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.

[0072] 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.

[0073] Furthermore, the "code sending module", "update record generation module", "scanning result notification module", "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 "device code-based risk scanning system or computing device" described herein, or any integrated circuit unit designed in a hardware description language and can be embedded in the "device code-based risk scanning computing device" described herein.

[0074] The "device code-based risk scanning system" described herein may be implemented as system firmware, an application, a software engine, a website system, an operating system, or any other programmable software platform. In a preferred embodiment, the "device code-based risk scanning system" described herein can be deployed and run on a single machine. Specifically, the code sending module, update record generation module, scan result notification module, 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 system and deployed to run on a single machine. In another preferred embodiment, the "device code-based risk scanning system" described herein can be implemented through the collaboration of multiple machines, that is, the code sending module, update record generation module, scan result notification module, first feature extraction unit, second feature extraction unit, feature comparison unit, analysis unit, capture unit, detection unit and other processing units described herein 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 device code-based risk scanning system through multiple machines.

[0075] The "device code-based risk scanning computing device" 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 "device code-based risk scanning computing device" described herein may be implemented by a single machine. Specifically, the code sending module, update record generation module, scan result notification module, first feature extraction unit, second feature extraction unit, feature comparison unit, analysis unit, capture unit, and detection unit described herein are all integrated into the same machine to serve as the device code-based risk scanning computing device. In another preferred embodiment, the "device code-based risk scanning computing device" described herein can be implemented by the collaboration of multiple machines, that is, the code sending module, update record generation module, scan result notification module, first feature extraction unit, second feature extraction unit, feature comparison unit, analysis unit, capture unit, detection unit and other processing units described herein are provided to different machines. 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 device code-based risk scanning computing device through multiple machines.

[0076] Continuing from the above, in a preferred embodiment, the "code sending module," "update record generation module," "scan result notification module," "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 "code sending module," "update record generation module," "scan result notification module," "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.

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

[0078] 1 is a flow chart of a device code-based risk scanning method according to an embodiment of the present invention, which specifically includes the following steps:

[0079] S1. Obtain a device code, the device code being obtained from a first device 5 and sent from the first device 5 to a second device 6; wherein the device code is generated by the first device 5 and includes at least one software code;

[0080] S2. Generate an update record; wherein the update record includes a relationship record between the device code and the first device 5 and / or the second device 6;

[0081] S3. When a security risk is detected in the device code, a scanning result is sent to the first device 5 and / or the second device 6 according to the update record.

[0082] Figure 2 shows a block diagram of a device code risk scanning system 1 according to the present invention. This describes a preferred embodiment of the device code risk scanning method. Risk scanning system 1 is a website system that can be deployed on a first device 5, a second device 6, or any computing device 11 with networking and logical processing capabilities. Code sending module 2, update record generation module 3, and scan result notification module 4 are integrated into risk scanning system 1 as processing units.

[0083] In a preferred embodiment, the risk scanning system 1 is deployed on the second device 6. The first device 5 can then use an application programming interface (API) provided by the code sending module 2 to call the API, allowing the software system running on the first device 5 to provide a device code to the code sending module 2. This allows the code sending module 2 to obtain the device code from the first device 5 and transmit the device code from the first device 5 to the second device 6. The API can be implemented using, but not limited to, REST APIs, Web Services, and other technologies. The code sending module 2 can also be implemented as a web front-end program or a software agent program implemented in Java. The first device 5 can dynamically load the code sending module 2 implemented as a web front-end program through a browser and execute the web front-end program on the browser. Alternatively, the risk scanning system 1 can provide another API for downloading the software agent program, which the first device 5 can call to download the software agent program and dynamically load and execute in the Java virtual environment of the first device 5. After completing the dynamic loading and execution of the web front-end program or the software agent program, the web front-end program or the software agent program can retrieve the device code obtained from the first device 5 on the first device 5 and send the device code from the first device 5 to the second device 6 via the application program interface. The device code is stored in the storage medium of the first device 5. The web application or the software agent program can retrieve the device code by reading the storage medium. Alternatively, the code sending module 2 can directly establish a TCP / UDP socket connection to the first device 5. For example, it can access the first device 5 via an SSH (Secure Socket Shell) communication protocol connection with an authorized identity. After traversing the storage medium and searching for the device code using system instructions to access the storage medium, it can retrieve the required device code from the storage medium of the first device 5 via an SCP (Secure Copy Protocol) communication protocol connection and send the retrieved device code to the second device 6, thereby allowing the device code to be sent from the first device 5 to the second device 6.

[0084] In a preferred embodiment, the risk scanning system 1 is deployed on a first device 5. A device code is stored in a storage medium of the first device 5. The code sending module 2 retrieves the device code by reading the storage medium. The code sending module 2 then establishes a TCP / UDP socket connection with a second device 6. Using an agreed-upon communication protocol, the device code is sent to the second device 6, and the device code is updated to the device code running on the second device 6. For example, the code sending module 2 may establish a TCP / UDP socket connection with the second device 6, access the first device 6 using the SSH (Secure Socket Shell) communication protocol using an authorized identity, retrieve the required device code from the storage medium of the first device 5 via the SCP (Secure Copy Protocol) communication protocol, and send the retrieved device code to the second device 6. This allows the device code to be sent from the first device 5 to the second device 6, where it is updated to the second device 6, thus becoming the device code running on the second device 6.

[0085] In a preferred embodiment, the risk scanning system 1 is deployed on a computing device 11 separate from the first device 5 and the second device 6. Through implementations equivalent to the aforementioned "risk scanning system 1 on the second device 6," the risk scanning system 1 deployed on the computing device 11 can access the application program interface of the code sending module 2 via the first device 5 and / or dynamically load the web application or software agent program included in the code sending module 2 onto the first device 5. This allows the code sending module 2 to obtain a device code from the first device 5, establish a TCP / UDP socket connection to the second device 6, and transmit the device code to the second device 6 via an agreed-upon communication protocol. The device code is the device code stored on the storage medium of the first device 5.

[0086] In a preferred embodiment, an HTTP interface can be opened on the second device 6, so that the code sending module 2 can establish a TCP / UDP Socket connection to the HTTP interface and transmit the device code to the second device 6 via the HTTP communication protocol.

[0087] The above-described method of obtaining a device code from the first device 5 and transmitting it to the second device 6 is not limited thereto. Persons skilled in the art may make any equivalent design changes based on actual application requirements. The benefit of the above-described technical implementation is that when the risk scanning system 1 is deployed on the second device 6, regardless of whether the first device 5 is an online server, an IoT sensor, a network communication device (e.g., a WiFi wireless router), or another embedded device with limited computing power, the code component analysis of the device code obtained from the first device 5 does not need to be performed on the first device 5; nor does it require the installation of an additional application on the first device 5 to obtain the device code. Similarly, when the risk scanning system 1 is deployed on the first device 5, regardless of whether the second device 6 is an online server, an IoT sensor, a network communication device (e.g., a WiFi wireless router), or another embedded device with limited computing power, the code component analysis of the device code running on the second device 6 does not need to be performed on the second device 6. When the risk scanning system 1 is deployed on a computing device 11 different from the first device 5 and the second device 6, regardless of whether the first device 5 and / or the second device 6 is an online server, an IoT sensor, an Internet communication device (e.g., a WiFi wireless router), or other embedded devices with limited computing power, the computational work of analyzing the code components of the device code obtained from the first device 5 and / or the computational work of analyzing the code components of the device code running on the second device 6 does not need to be performed on the first device 5 and the second device 6.

[0088] In a preferred embodiment, the code sending module 2 in the risk scanning system 1 obtains a device code from the first device 5 in response to an update request.

[0089] In a preferred embodiment, the risk scanning system 1 is run on the second device 6 , and the update request is generated on the first device 5 . When the update request is generated, version information or device specification information is provided in the update request. In a first embodiment, the update request is generated by a software system running on the first device 5. When generating the update request, version information or device specification information is included in the update request. Based on the version information or device specification information in the update request, the software system retrieves a device code corresponding to the version information or device specification information from the storage medium of the first device 5. The software system then calls an application program interface (API) provided by the code sending module 2 and provides the device code to the code sending module 2. Alternatively, the software system calls an API provided by the risk scanning system 1 for submitting an update request and submits the update request to the code sending module 2 of the risk scanning system 1. Then, the code sending module 2 on the second device 6 accesses the first device 5 via an SSH (Secure Socket Shell) communication protocol connection using an authorized identity. Based on the version information or device specification information in the update request, the software system traverses the storage medium using system instructions for accessing the storage medium to locate the device code. Finally, the software system retrieves the required device code from the storage medium of the first device 5 via an SCP (Secure Copy Protocol) communication protocol connection. Option 2, the update request is generated when a user operates on the human-machine interface of a web front-end program or a software agent program dynamically loaded and executed on the first device 5 (for example: operating the interface for establishing and submitting an update request). When generating the update request, the user can input version information or device specification information into the update request through the human-machine interface. After submitting the update request, the dynamically loaded web front-end program or software agent program can obtain a device code corresponding to the version information or the device specification information from the storage medium of the first device 5 based on the version information or the device specification information in the update request, and send it to the second device 6.

[0090] In a preferred embodiment, the risk scanning system 1 runs on a first device 5. The update request is sent from a second device 6 to the first device 5. When generating the update request, version information or device specification information is included in the update request. In a first solution, a software system running on the second device 6 generates the update request and enters the version information of the required device code or the device specification information of the second device 6 into the update request. This update request is then sent to the code sending module 2 of the risk scanning system 1 running on the first device 5, using an application program interface (API) provided by the risk scanning system 1 for submitting update requests. After receiving the update request, the code sending module 2 retrieves the device code corresponding to the version information or device specification information from the storage medium of the first device 5 and sends it to the second device 6, where it is updated to the device code running on the second device 6. In a second solution, the update request may also be generated by the risk scanning system 1 running on the first device 5. When generating the update request, version information or device specification information is provided in the update request. The code sending module 2 obtains the device code corresponding to the version information or device specification information from the storage medium of the first device 5 based on the version information or device specification information in the update request, and then sends the device code to the second device 6 to update the device code running on the second device 6.

[0091] In a preferred embodiment, the risk scanning system 1 runs on a separate computing device 11 from the first device 5 and the second device 6. The update request is generated on the first device 5, with version information or device specification information included in the update request. Alternatively, the update request is generated by the second device 6 and sent to the first device 5, with version information or device specification information included in the update request. In a first embodiment, the update request is generated by a software system running on the first device 5, or by a web front-end program or software agent program dynamically loaded by a user through the code sending module 2. By calling an application program interface (API) provided by the risk scanning system 1 for sending device codes, the device code corresponding to the version information or device specification information is sent to the separate computing device 11. The code sending module 2 then sends the device code to the second device 6, where it is updated to the device code running on the second device 6. In a second solution, the update request is generated by a software system running on the first device 5, or by a web front-end program or software agent program dynamically loaded by a user through the code sending module 2. The update request is submitted to the code sending module 2 of the risk scanning system 1 via a call to an application program interface (API) provided by the risk scanning system 1 for submitting update requests. The code sending module 2 accesses the first device 5 via an SSH (Secure Socket Shell) communication protocol connection using an authorized identity. Based on the version information or device specification information in the update request, the code sending module 2 traverses the storage medium to locate the device code using system instructions for accessing the storage medium. The code is then retrieved from the storage medium of the first device 5 via an SCP (Secure Copy Protocol) communication protocol connection. The code sending module 2 then sends the requested device code to the second device 6, which updates the device code running on the second device 6. In a third solution, the software system running on the second device 6 generates the update request and enters the version information of the required device code or the device specification information of the second device 6 into the update request. The update request is then sent to the code sending module 2 of the risk scanning system 1 running on the first device 5 via an application program interface (API) provided by the risk scanning system 1 for submitting an update request. After receiving the update request, the code sending module 2 retrieves the device code corresponding to the version information or device specification information from the storage medium of the first device 5 and sends it to the second device 6, which then updates the code to the device code running on the second device 6.

[0092] In a preferred embodiment, the version information and the device specification information are both part of the metadata of the device code. The device specification information includes at least one of product specifications, hardware specifications, and firmware specifications of the device supported by the device code.

[0093] The benefit derived from the aforementioned update request generated by the first device 5 is that the second device 6 does not need to know the network location information of the first device 5 and / or the other computing device 11. The first device 5 and the other computing device 11 push the device code update to the second device 6. In a preferred embodiment, the network location information of the second device 6 is entered into the update request by the user through the human-machine interface of the dynamically loaded web front-end program or software agent program. Alternatively, the network location information of the second device 6 is received by the risk scanning program 1, which then writes the network location information of the second device 6 into the update request. The code sending module 2 then transmits the device code to the second device 6 for update based on the network location information in the update request. This asynchronous device code update method, in which the update request is issued and the device code is received via two separate connections, differs from traditional OTA updates, in which the second device 6 establishes a connection to a server providing the update code for download.

[0094] In fact, the above scenario eliminates the need for the second device 6 to download the device code itself. With permission granted, the first device 5 or the other computing device 11 can use the improved method to send an update request to the risk scanning system 1. Subsequently, the risk scanning system 1 establishes a connection with the second device 6 indicated by the network location information of the second device 6 and proactively transmits the device code to the second device 6 to complete the update.

[0095] The network location information can simply be an IP address. A default communication protocol (a default port supported by the device) is established between the risk scanning system 1 and the second device 6 for transmitting device codes. In this case, the risk scanning system 1 only needs to know the device's IP address to proactively connect to it and transmit the updated device code. Alternatively, the network location information can be an IP address plus a port, meaning the network location information includes information specifying a network communication protocol. In this case, the risk scanning system 1 and the second device 6 do not need to have a default network communication protocol. The risk scanning system 1 can also establish a connection between the first device 5 and the second device 5 or the other computing device 11 based on the IP address (location) plus the port (communication protocol) and transmit the updated device code. The method of asynchronously updating the device code is not limited to this method. Those skilled in the art can make any equivalent design changes based on actual application requirements.

[0096] The risk scanning system 1 can obtain the network location information of the second device 6 in a variety of ways. In one approach, the user of the second device 6 registers metadata for the second device 6 in the database of the risk scanning system 1. The metadata of the second device 6 includes the network location information of the second device 6. The risk scanning system 1 can then locate the network location information of the second device 6 by searching the database for the metadata of the second device 6. The metadata of the second device 6 can also include at least one of the product specifications, hardware specifications, and firmware specifications of the second device 6. The risk scanning system 1 can search the database using the information included in the update request (such as the product specifications, hardware specifications, and firmware specifications supported by the device code). In a second solution, the risk scanning system 1 and the second device 6 are both located in a network environment capable of exchanging multicast packets. The risk scanning system 1 can periodically send "multicast packets for device search" to the network. When the second device 6 is a device equipped with a communication protocol that supports the multicast packets, upon receiving the multicast packets, the second device 6 can write its own network location information and at least one of its product specifications, hardware specifications, and firmware specifications into a corresponding multicast packet and send it to the network environment. Upon receiving the multicast packets, the risk scanning system 1 can obtain the network location information of the second device 6 and its product specifications, hardware specifications, and firmware specifications, and log them into the database.

[0097] In a preferred embodiment, the risk scanning system 1 runs on the first device 5 or another computing device 11. When the code sending module 2 of the risk scanning system 1 receives an update request, it can obtain the required device code based on the version information and device specification information (at least one of product specifications, hardware specifications, and firmware specifications) included in the update request. Furthermore, the code sending module 2 can use the device specification information to search the aforementioned database to locate the network location information of the second device 6. The device code can then be sent to the second device 6 to update the device code running on the second device 6.

[0098] In a preferred embodiment, the code sending module 2, the update record generation module 3, and the scan result notification module 4 serve as processing units integrated into the risk scanning system 1. Each processing unit can provide at least one function to implement 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 services 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.

[0099] In another preferred embodiment, the update request is directly generated by the risk scanning system 1 and submitted to the code sending module 2. The risk scanning system 1 may generate the update request and submit it to the code sending module 2 based on the contents of a configuration file. The configuration file may include the relevant information required to obtain a device code from the first device 5 and send the device code to the second device 6. The relevant information may include, but is not limited to, network location information of the first device 5 and / or the second device 6, the authorized identity of the first device 5 and / or the second device 6, version information, and / or device specification information. The configuration file may be configured by the administrator of the risk scanning system 1 during deployment of the risk scanning system 1, or provided to the risk scanning system 1 by the administrator and / or its users through user-friendly configuration on the human-machine interface of the risk scanning system 1 while the risk scanning system 1 is already online.

[0100] In summary, the generation and transmission of the update request content and the method for the code sending module 2 to obtain the update request are not limited to this. Those skilled in the art can make any equal changes in design according to actual application requirements.

[0101] In a preferred embodiment, upon receiving the update request, code sending module 2 may not only transmit the device code from first device 5 to second device 6, but may also store the device code in a database or a file server and request update record generation module 3 to create an update record in the database of risk scanning system 1. In the first scenario, risk scanning system 1 operates on first device 5. The update record includes not only device code version information, supported device specifications, and the storage location of the device code on the file server, but also a relationship record containing metadata about second device 6. In the second scenario, risk scanning system 1 operates on second device 6. The update record includes not only device code version information, supported device specifications, and the storage location of the device code on the file server, but also a relationship record containing metadata about first device 5. In a third solution, the risk scanning system 1 is run on a computing device 11 separate from the first device 5 and the second device 6. The update record includes not only device code version information, device specifications supported by the device code, and the storage location of the device code in the file server, but also a relationship record. The relationship record includes metadata for the first device 5 and metadata for the second device 6. The metadata for the first device 5 includes network location information for the first device 5 and account information for the user, operator, and / or administrator of the first device 5.

[0102] In a preferred embodiment, the first device 5 and / or the second device 6 is an embedded system device, a server device, an IoT sensor device, a network communication device, or any computer device with networking capabilities.

[0103] Furthermore, the device code is obtained from the first device 5 , and the at least one software code included in the device code includes at least one binary code.

[0104] The device code risk scanning method described above enables risk scanning system 1 to obtain device code from first device 5 and then update the device code on second device 6, so that the device code becomes the code executed by second device 6 when it is online. When first device 5 and second device 6 are offline, risk scanning system 1 implementing the device code risk scanning method can perform risk scans on the device codes of first device 5 and second device 6, that is, by analyzing the code components of the device code stored in the file server. Under the above method, risk scanning system 1 can also perform risk scans on the device codes of first device 5 and second device 6 when they are online, thus encompassing both online and offline scenarios.

[0105] In a preferred embodiment, the device code obtained from the first device 5 is obtained in the form of a software code package, that is, the device code is packaged in a software code package. The software code package may include a compressed file that contains all the software code included in the device code. In another preferred embodiment, the device code is obtained in the form of a system image file that contains all the software code included in the device code.

[0106] In a preferred embodiment, regardless of whether the device code is in the form of a system image file or a software code package, the code sending module 2 of the risk scanning system 1 obtains the device code and scans all software code contained within it. To perform a scan, the system image file containing the device code is mounted to memory or a partitioned sector from the hard disk memory (if it is a zImage, its contents can be decompressed into a folder), or the software code package containing the device code is decompressed into a designated folder on the hard disk memory. The complete contents of the device code are then stored on a file server. Traversing the files and directories of the device code stored on the file server is equivalent to scanning the components contained in the system image file and the software code package. Based on the traversal results, the file and directory structure of the device code is determined and then compared with the file and directory structures of known operating system kernels, drivers, applications, common software components, and / or class libraries to identify operating system kernels, drivers, applications, common software components, and / or class libraries with matching file and directory structures. Following the above procedure, after collecting the device code, the risk scanning system 1 can scan and analyze the software code contained in the device code to generate a component list. This component list can be composed of metadata (data describing software code-related information, such as the name of each software code, and other descriptive information) for each software code in the form of an operating system kernel, driver, application, common software component, and / or class library. The component list can also include metadata (data describing device code-related information) for the device code itself.

[0107] In a preferred embodiment, based on the component list of the at least one software code included in the device code, the risk scanning system 1 can monitor the CVE list corresponding to each software code included in the component list (for example, for the Linux kernel, the CVE list corresponding to the Linux kernel is monitored). Code analysis events are detected 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 for the vulnerability is updated, resulting in a change in the list content, a code analysis event can be triggered. Patch code is one aspect of risk code, but is not limited to this. For malware code, one aspect of risk code, those skilled in the art can make any equivalent design changes 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 risk scanning system 1. Among them, the CVE list is an 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, when a patch code is added or updated, triggering a code analysis event corresponding to the patch code, the risk scanning system 1 retrieves the patch code from a storage medium storing the patch code. The storage medium may be the same storage medium as the file server storing the device code, or a separate storage medium. In another preferred embodiment, when the risk scanning system 1 detects a patch code addition or update, it may first retrieve the source code of the patch code stored in another storage medium (e.g., a GIT hub where the patch code is published) and compile it. The compiled result (binary code or intermediate code) is then stored on the file server. In this case, the pre-compiled result can be considered part of the entire patch code. During component comparison, the risk scanning system 1 retrieves the entire patch code (including source code, binary code, and / or intermediate code) from the file server and the separate storage medium. The above-described method for monitoring and retrieving the risk code entry list is not limited to this method. Those skilled in the art may make any equivalent design changes based on actual application requirements.

[0109] In a preferred embodiment, after the risk scanning system 1 retrieves the patch code, it compares the patch code with the corresponding at least one piece of software code in the device code. If the comparison indicates that the at least one piece of software code contains at least one security risk, the scanning result notification module 4 is requested to issue a scan result regarding the security risk.

[0110] In a preferred embodiment, the scan result includes a scan status notification message and / or a scan report. The sending of a scan result refers to sending the scan status notification message and / or the scan report to at least one user, operator, or administrator of the first device 5 and the second device 6 via at least one network communication channel, such as email, mobile phone push notification, mobile phone text message notification, web page push notification, etc.; wherein, the scan report is used to display the result of the component content comparison between at least one software code and at least one risk code. Patch code is one type of risk code. The existence of patch code itself indicates that the software code contained in the device code has a corresponding known or newly discovered vulnerability, and the patch code is the code that corrects the vulnerability. If the result of comparing the patch code with the component content of 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. Unscrupulous persons can exploit this vulnerability to attack the first device 5 and / or second device 6 that are executing the device code and are running the device code online. In other words, the existence of the vulnerability includes the risk of the first device 5 or the second device 6. Accordingly, the component content comparison results displayed in the content of the scan report may include "description information of the at least one risk code", "description information of the at least one software code", "description information of the device code", "description information of the vulnerability", "description information of the risk", "number of vulnerabilities contained in the device code and / or the at least one software code", "security level of the device code and / or the at least one software code", and / or "judgment result of whether the at least one software code contains the at least one risk code", etc., but are not limited thereto. The scan status notification information is the notification information sent to the relevant persons regarding the completion status of the scan result, that is, through at least one network communication channel, a scan status notification is provided to at least one of the users, operators or managers of the first device 5 and the second device 6 regarding the completion status of the scan result, wherein the content of the scan status notification information may include "description information of the scan report and / or its content" and / or "the complete or partial content of the scan report", etc., but are not limited thereto.

[0111] In a preferred embodiment, when the risky code is malware code, the malware code represents code with a known vulnerability. That is, 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 the device code, and a scan result is required.

[0112] In a preferred embodiment, the scan result notification module 4 retrieves the device code update record from the database of the risk scanning system 1 and searches for a relationship record within the update record. Based on the user account information of at least one of the users, operators, or administrators of the first device 5 and / or the second device 6 recorded in the relationship record, the module sends the scan result to the at least one of the users, operators, and / or administrators of the first device 5 and / or the second device 6 using the at least one user account information. Specifically, based on the at least one user account information, the module determines the email address and / or mobile phone number of the at least one of the users, operators, and / or administrators, and sends the scan result (scan report and / or scan status notification information) to the user, operator, and / or administrator via a network communication channel such as email, mobile push notification, or mobile text message notification.

[0113] In a preferred embodiment, the scanning result notification module 4 can send the scanning result backend to the web front-end program through the web front-end program when the user, operator and / or administrator scans the risk of the first device 5 or the second device 6 on the web front-end program of the system 1.

[0114] The contents of the above-mentioned scanning results, scanning reports and scanning status notification information, as well as the method of sending the scanning results, are not limited to this. Those skilled in the art can make any equal changes in design according to actual application requirements.

[0115] In a preferred embodiment, before acquiring the device code, the risk scanning system 1 can read the contents of at least one risk code log list (for example, a CVE list of different software projects), locate the release source of the patch code (for example, a GIT hub for releasing patch codes) based on the vulnerability records contained in the contents of the at least one risk code log list, retrieve the source code of the patch code from another storage medium (for example, a GIT hub for releasing patch codes), compile it, and store the compiled result (binary code or intermediate code) on the file server. By using this technical implementation method, at least one patch code corresponding to the at least one risk code log list (an implementation aspect of the risk code) is pre-collected on the file server. In this way, when the component list of the at least one software code contained in the device code is obtained by analyzing the device code, the risk scanning system 1 can locate the risk code registration list corresponding to the software code based on each software code in the component list, and then retrieve the risk code pre-collected based on the corresponding risk code registration list from the file server to compare the component content with each software code in the device code, thereby obtaining a scan result for the entire device code. As can be seen from the above, code analysis events can be triggered in different scenarios, including at least: 1) when a component list of at least one software code contained in the device code is obtained; 2) when at least one risk code is added to the corresponding risk code registration list; or 3) when at least one risk code is updated in the corresponding risk code registration list, but this is not limited to this. Those skilled in the art can make any equivalent design changes based on actual application requirements. It can also be known that the at least one risk code can be collected in advance to the file server based on at least one risk code login list, or it can be collected when a risk code is added or updated to the at least one risk code login list. However, the method of collecting risk codes is not limited to this. People familiar with the art can make any equal change design based on actual application requirements.

[0116] 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.

[0117] As shown in FIG1 , when a security risk is detected in the device code, the code component analysis before the security risk detection in S3 specifically includes the following steps:

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

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

[0120] S33. Compare at least one first component feature and at least one second component feature.

[0121] Furthermore, the first component feature in S31 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.

[0122] Furthermore, the at least one second component feature described in S32 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.

[0123] 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.

[0124] In a preferred embodiment, the types of risk codes include a patch code associated with the at least one software code, malicious program code, and / or any code used to correct or generate a software vulnerability or software virus.

[0125] In a preferred embodiment, the code analysis event of the risky code is triggered when the risky code is added or updated to a risky code registration list (eg, CVE list).

[0126] In a preferred embodiment, before the code analysis event is triggered, the risk scanning system 1 further comprises detecting at least one code analysis event based on a component list of the at least one software code. The code analysis event corresponding to the risky code is one of the at least one code analysis event.

[0127] In a preferred embodiment, the device code components may be comprised 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 component can be considered part of the device code, and at least one code component component can be considered part of the at least one software code component.

[0128] The at least one software code contained in a device is generally composed of a list of 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 online.

[0129] 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 risk scanning system 1 described in this article is not notified. Therefore, in order for code analysis events to be triggered, the risk scanning system 1 must monitor the CVE lists and GIT Hub for Linux Kernel, OpenSSL, SQLite, and other vulnerabilities based on the device code composition list before triggering to detect these code analysis events.

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

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

[0132] The device code 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).

[0133] Taking the overall device code of a device as an example, it contains numerous software code files, each of which is organized into different components (e.g., Linux Kernel, OpenSSL, SQLite, etc.). Each software code file is stored in a different path location. There are different ways to obtain a list of the software code components contained in the device code. One method is to scan the entire device code based on file path information. As the software code for different components is stored in different locations, this method can generally determine which components are contained in the device code. 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 features of a specific component. For example, when reading the code components of a code file contained in a software code, it 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 in the device code can be determined. The method of scanning and / or analyzing the component composition of the device code to obtain the composition list of each software code in the device code is not limited to this. Those skilled in the art can make any equivalent change design according to actual application requirements.

[0134] 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. The risk scanning 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 for 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 does contain the vulnerability.

[0135] 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.

[0136] 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.

[0137] 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.

[0138] 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.

[0139] 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.

[0140] As shown in FIG5 , this embodiment further provides a device code risk scanning computing device 11 , comprising a code sending module 21 , an update record generating module 31 , and a scanning result notifying module 41 ;

[0141] The code sending module 21 is used to obtain a device code, the device code is obtained by the first device 5, and send the device code from the first device 5 to the second device 6; wherein the device code includes at least one software code;

[0142] The update record generating module 31 is used to generate an update record; wherein the update record includes a relationship record between the device code and the first device 5 and / or the second device 6;

[0143] The scanning result notification module 41 is configured to send a scanning result to the first device 5 and / or the second device 6 according to the update record when a security risk is detected in the device code.

[0144] When the scan result shows that the at least one software code contains at least one security risk, the scan result notification module 41 is further configured to send the scan result to at least one of the users, operators, or administrators of the first device 5 and the second device 6 via at least one network communication channel.

[0145] In a preferred embodiment, the computing device 11 is an embedded device. The code sending module 21, update record generation module 31, and / or scan result notification module 41 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 form of software code. The embedded system running in the computing device 11 drives the code sending module 21, update record generation module 31, and scan result notification module 41.

[0146] In another preferred embodiment, the computing device 11 is a server, and the code sending module 21, update record generation module 31 and / or scan result notification module 41 are integrated into a software system in the form of software code. The software system is provided to the computing device 11 for operation through built-in or installation, and the code sending module 21, update record generation module 31 and scan result notification module 41 are driven by the software system running in the computing device 11.

[0147] In another preferred embodiment, the computing device 11 is composed of distributed servers. The code sending module 21, update record generation module 31, and / or scan result notification module 41 are integrated into a distributed software system in the form of software code. The distributed software system is deployed and executed on the distributed servers to form the computing device 11. The code sending module 21, update record generation module 31, and scan result notification module 41 are driven by the distributed software system running in the computing device 11.

[0148] 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.

[0149] Further, in conjunction with FIG2 , the risk scanning system 1 includes a first feature extraction unit, a second feature extraction unit, and a feature comparison unit;

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

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

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

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

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

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

[0156] 3 , the device code risk scanning computing device 11 further includes at least one detection unit;

[0157] 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, and detect code analysis events by monitoring changes in the risk code login list.

[0158] In summary, the present invention discloses a device code risk scanning method, system, and computing device 11. By acquiring the device code of an online device, updating the device code of an online device, comparing the risk code with the component content of the device code, and issuing scanning results for the devices, risk scanning can be performed on the devices regardless of whether the devices are offline, the network status is normal, or the computing power is insufficient, thereby achieving risk prevention and control of the device code.

[0159] 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 risk scanning method based on device code, characterized in that: include: Obtaining a device code, wherein the device code is obtained from a first device, and sending the device code from the first device to a second device; wherein the device code includes at least one software code; generating an update record; wherein the update record includes a relationship record between the device code and the first device and / or the second device; When a security risk is detected in the device code, a scan result is sent to the first device and / or the second device according to the update record.

2. The device code-based risk scanning method according to claim 1, wherein: The sending of the scan result refers to sending a notification of the scan result to at least one of the user, operator or administrator of the first device and the second device through at least one network communication channel.

3. The device code-based risk scanning method according to claim 1, characterized in that: The at least one software code includes at least one binary code.

4. The device code-based risk scanning method according to claim 1, characterized in that: The obtaining device code specifically includes: According to an update request, the device code is obtained from a storage medium of the first device.

5. The device code-based risk scanning method according to claim 4, characterized in that: The method for obtaining a device code further includes: When the update request is obtained, a device code corresponding to a version information or a device specification information in the update request is obtained in the storage medium as the device code; wherein the device specification information includes at least one of a product specification, hardware specification, and firmware specification of a device.

6. The device code-based risk scanning method according to claim 4, characterized in that: The sending the device code to the second device specifically includes: The device code is sent to the second device according to the network location information of the second device included in the update request.

7. The device code-based risk scanning method according to claim 1, characterized in that: The detecting that there is a security risk in the device code specifically includes: When at least one code analysis event is triggered, at least one risk code is compared with the at least one software code in terms of component content; wherein the at least one risk code includes at least one of a patch code, a malicious program code, and any computer program code written in a computer program language associated with the at least one software code.

8. The device code-based risk scanning method according to claim 7, wherein: The at least one risk code is pre-collected according to at least one risk code registration list, or is collected when a risk code is added or updated to the at least one risk code registration list.

9. The device code-based risk scanning method according to claim 7, wherein: The at least one code analysis event is triggered when a component list of the at least one software code is obtained, or when the at least one risk code is added or updated.

10. The device code-based risk scanning method according to claim 7, characterized in that: The comparing the at least one risk code with the at least one software code specifically includes: Retrieving at least one first component feature corresponding to the at least one 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.

11. The device code-based risk scanning method according to claim 10, wherein: The at least one first component feature is obtained by analyzing the code composition content and / or code execution result corresponding to the at least one risk code.

12. The device code-based risk scanning method according to claim 11, characterized in that: The code composition content includes the at least one risk code and / or the at least one first intermediate code compiled from the at least one risk code, and the code execution result includes the semantic information revealed by the at least one risk code and / or the at least one first intermediate code during the simulation execution process of the at least one risk code and / or the at least one first intermediate code.

13. The device code-based risk scanning method according to claim 10, wherein: 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.

14. The device code-based risk scanning method according to claim 13, wherein: 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.

15. The device code-based risk scanning method according to claim 12 or 14, 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.

16. The risk scanning method based on device code according to claim 7, characterized in that: Before the code analysis event is triggered, it also includes: At least one code analysis event is detected according to the component list of the at least one software code, and the code analysis event corresponding to the at least one risky code is one of the at least one code analysis event.

17. The device code-based risk scanning method according to claim 9, wherein: The component list is obtained after scanning and / or analyzing the component composition of the device code when the device code is obtained.

18. The device code-based risk scanning method according to claim 17, wherein: 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.

19. The device code-based risk scanning method according to claim 18, wherein: 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.

20. The device code-based risk scanning method according to claim 17, wherein: Based on the component list, the risk code login list corresponding to each software code contained in the component list is monitored, and the code analysis event is detected by monitoring the change of the risk code login list.

21. The device code-based risk scanning method according to claim 17, wherein: The method for obtaining the composition list specifically includes: 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; 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 present in the software code package, thereby obtaining the component list of the at least one software code.

22. The device code-based risk scanning method according to claim 1, characterized in that: The sending of the scan result to the first device and / or the second device according to the update record specifically includes: Searching the update record to obtain the relationship record in the update record; A scan result is issued to at least one of a user, an operator or a manager of the first device and the second device according to the relationship record.

23. The device code-based risk scanning method according to claim 22, characterized in that: The scanning result includes at least one of a scanning report and a scanning status notification message; wherein the scanning report is used to display the component content comparison result of the at least one software code and the at least one risk code; the scanning status notification message is used to provide a scanning status notification to at least one of the users, operators or managers of the first device and the second device.

24. A risk scanning system based on device code, characterized in that: include: Code sending module, update record generating module and scanning result notification module; The code sending module is used to obtain a device code, the device code is obtained from the first device, and send the device code from the first device to the second device; wherein the device code includes at least one software code; The update record generation module is used to generate an update record; wherein the update record includes a relationship record between the device code and the first device and / or the second device; The scanning result notification module is used to send the scanning result to the first device and / or the second device according to the update record when a security risk is detected in the device code.

25. The device code-based risk scanning system according to claim 24, wherein: It also 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 at least one 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.

26. The device code-based risk scanning system according to claim 25, 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 at least one risk code to obtain the at least one first component feature, and / or to analyze the code composition content and / or the code execution result corresponding to the at least one software code to obtain the at least one second component feature; The at least one capturing unit is used to capture the at least one first component feature and / or the at least one second component feature obtained after analysis.

27. The device code-based risk scanning system of claim 24, wherein: 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.

28. A computing device based on risk scanning of device codes, characterized in that: include: Code sending module, update record generating module and scanning result notification module; The code sending module is used to obtain a device code, the device code is obtained from the first device, and send the device code from the first device to the second device; wherein the device code includes at least one software code; The update record generation module is used to generate an update record; wherein the update record includes a relationship record between the device code and the first device and / or the second device; The scanning result notification module is used to send the scanning result to the first device and / or the second device according to the update record when a security risk is detected in the device code.

Images